hi,
I notice that user ssh public keys like https://meta.sr.ht/~sircmpwn.keys will expose comment to the public.
I think it's a potential privacy leak if the comment contains sensitive information, i.e. email address.
P.S.
github.com doesn't expose ssh public key comment to the public:
https://github.com/torvalds.keys
Best Regards.
vac
> I do not consider this a flaw, you can remove the comment yourself if> you so desire and your email address is not considered private on> SourceHut.
There's one issue I see with the current situation, though: it is not
obvious that the keys are visible (comments included) as this is written
on a very small line below the add-key form.
If comments are to be kept (I'm not sure what benefit it brings,
honestly), then it might be good to add some more visible disclaimer
that the whole entry will be shown to the public.
On Sat Jun 17, 2023 at 10:39 AM CEST, Tanguy Fardet wrote:
> There's one issue I see with the current situation, though: it is not > obvious that the keys are visible (comments included) as this is written > on a very small line below the add-key form.
Exactly, it's right next to where you enter it… I don't think there's
any place that would be better suited.
> If comments are to be kept (I'm not sure what benefit it brings, > honestly)
I think there should be a reason to remove them. In my eyes, it's
reasonable to assume that it has the common authorized_keys format that
one would expect. This includes these comments.
--
Moritz Poldrack
https://moritz.sh
I have removed the comments (and also the displayed titles) from my keys.
Even email address is not considered private on SourceHut, SSH public key comment can still be sensitive.
The default comment generated by `ssh-keygen` is $USER@$HOST, which means some users would expose some kind of login_user+device map without even realizing that.
I suggest adding some reminder in meta.sr.ht/keys saying the comment/title will be public.
-------- Original Message --------
On Jun 17, 2023, 16:34, Drew DeVault < sir@cmpwn.com> wrote:
> > I do not consider this a flaw, you can remove the comment yourself if you so desire and your email address is not considered private on SourceHut.
> I have removed the comments (and also the displayed titles) from my keys.>> Even email address is not considered private on SourceHut, SSH public key> comment can still be sensitive.>> The default comment generated by `ssh-keygen` is $USER@$HOST, which means> some users would expose some kind of login_user+device map without even> realizing that.
BTW, why are the public keys available publicly?
I mean, I understand it should be harmless, but I expect that srht
wouldn't expose it just because it's supposed to be harmless: there's
presumably some good reason/usecase to expose it.
Stefan
> BTW, why are the public keys available publicly?>> I mean, I understand it should be harmless, but I expect that srht> wouldn't expose it just because it's supposed to be harmless: there's> presumably some good reason/usecase to expose it.
I personally use the feature in some infrastructure tasks. I can just
curl the URL and pipe it to .ssh/authorized_keys and I know all of my
active keys will be there. This is especially useful when collaborating
with other people; I can just list some usernames in my automation and
it will create their users and fetch their keys then periodically
refresh them.
On 23/06/18 11:18AM, Stefan Monnier wrote:
> BTW, why are the public keys available publicly?
You don't seem to understand asymmetric cryptography. Public keys are called
"public" precisely because they should be shared with the general public. They
can and should be made available on the Internet publicly. It is one's
*private* keys which should be kept private.
See, for example:
https://en.wikipedia.org/wiki/Public-key_cryptography> Security of public-key cryptography depends on keeping the private key > secret; the public key can be openly distributed without compromising > security.[3]
On 18 Jun 2023, at 21:11, Страхиња Радић wrote:
> On 23/06/18 11:18AM, Stefan Monnier wrote:>> BTW, why are the public keys available publicly?>> You don't seem to understand asymmetric cryptography. Public keys are called> "public" precisely because they should be shared with the general public. They> can and should be made available on the Internet publicly. It is one's> *private* keys which should be kept private.>
Generally speaking, the existence of a public identifier can be sensitive information.
As an example, while e-mail addresses are usually assumed to be safe to share[1], that isn’t always true. A list of 4500 email adresses belonging to high school students in the Oslo area leaked a while back, and journalists found that a extremist, far-right political party made a significant effort to get this list in an effort to recruit supporters[2].
Similarly, metadata can unexpectedly pop up in places[3], causing all sorts of issues for users that weren’t expecting it to be public[4].
Seemingly innocent information can be systematised, expose attack vectors or otherwise impact you or your users.
FWIW, I like the publicly available public keys-feature.
Marcus
[1]: Continuing the asymmetric cryptography example, the security of my account doesn’t get compromised by you knowing my e-mail address.
[2]: https://filternyheter.no/kjent-for-jodehat-slik-tar-alliansen-lederen-kontakt-med-barn-og-skoleelever-for-valget/ (Following Godwin’s Law, I might just have lost this debate?)
[3]: https://twitter.com/MKBHD/status/1069246242130145280
[4]: https://www.theregister.com/2016/09/19/dark_web_drug_sellers_shutter_locationtracking_exif_data_from_photos/
On 23/06/19 12:16AM, Marcus Pettersen Irgens wrote:
> Generally speaking, the existence of a public identifier can be sensitive > information.
Using the Internet is "unsafe", per se. But specifically, the user engaging in
asymmetric cryptography is assumed to accept the fact that public keys should
(yes, should! Hence the existence of public keyservers) and will be, well,
public. The user can express disagreement by not participating in this kind of
cryptography in the first place.
> As an example, while e-mail addresses are usually assumed to be safe to > share[1], that isn’t always true. A list of 4500 email adresses belonging to > high school students in the Oslo area leaked a while back, and journalists > found that a extremist, far-right political party made a significant effort to > get this list in an effort to recruit supporters[2].
According to Google Translate, the article [2] says that the list was
mistakenly published by the county council, so the publication of the list is
their fault. It is not related to public keys.
Even so, I'd say that the mere act of email addresses being made public is
tangential in that case. Rather, the main issue is education and parental
control/guidance (if the students are minors).
> Similarly, metadata can unexpectedly pop up in places[3], causing all sorts > of issues for users that weren’t expecting it to be public[4].
The articles [3] and [4] that you linked are about device type information
(unknowingly for the user) being leaked by an application and geolocation data
leaks from digital images being used to track criminals, so they aren't related
to (supposedly consensual) sharing of public keys, and [4] is actually an
example showing a positive side of "personal data leaks".
TL;DR: Consensual sharing of public keys is not the same as data "leaking",
which is usually done without the user's knowledge and consent.