I agree with you on the cryptographic point: you shouldn't (have to) expect to get cryptographic security from the secrecy of a public key, regardless of how the public key is used. My point is that there could be other reasons not to publish it, even though it's not a source of cryptographic vulnerability.
It seems to me that in crypto there are plenty of fields where the protocol designer would say "this value is nonconfidential" or "this value is not required to be kept secret" -- reasoning from the protocol's internal cryptographic security goals -- where publishing the value still has other adverse consequences. For instance, TLS session tickets per RFC 5077: "since the ticket is encrypted and the attacker does not know the secret key, a stolen ticket does not help an attacker resume a session".
But the protocol's internal security goals aren't always the only relevant security goals, and in the session tickets example, there is also a privacy sensitivity about disclosing them in some contexts because they can be used to show that a particular party was responsible for a particular TLS sessions (like if you were using Tor to access a web site but then posted the session tickets under your own name because RFC 5077 says that they don't need to be kept secret).
I think that's precisely what's happened here. If you read SSH protocol specs, they will say that public keys never need to be kept secret -- from the point of the SSH protocol's security goals. That's great, and it's a fair point. Users can still have other perfectly reasonable security reasons to request that people not publish them in particular circumstances!
> Users can still have other perfectly reasonable security reasons to request that people not publish them in particular circumstances!
Yes, but nobody has shown any compelling reasons in relation to pubkeys used for github.
And even if there were some potential small benefit it would have also be weighted against the benefit of having the whole population of pubkeys available for security research.
The OP article clearly exposes problematic practices that might have otherwise gone unnoticed.
It seems to me that in crypto there are plenty of fields where the protocol designer would say "this value is nonconfidential" or "this value is not required to be kept secret" -- reasoning from the protocol's internal cryptographic security goals -- where publishing the value still has other adverse consequences. For instance, TLS session tickets per RFC 5077: "since the ticket is encrypted and the attacker does not know the secret key, a stolen ticket does not help an attacker resume a session".
But the protocol's internal security goals aren't always the only relevant security goals, and in the session tickets example, there is also a privacy sensitivity about disclosing them in some contexts because they can be used to show that a particular party was responsible for a particular TLS sessions (like if you were using Tor to access a web site but then posted the session tickets under your own name because RFC 5077 says that they don't need to be kept secret).
I think that's precisely what's happened here. If you read SSH protocol specs, they will say that public keys never need to be kept secret -- from the point of the SSH protocol's security goals. That's great, and it's a fair point. Users can still have other perfectly reasonable security reasons to request that people not publish them in particular circumstances!