3 ms·
Exactly. My key is on there because we have a shared password-store synched in a private git repo encrypted with the keys of select number of colleagues for som
by Freak_NL 3y ago
Exactly. My key is on there because we have a shared password-store synched in a private git repo encrypted with the keys of select number of colleagues for some work credentials and keys. It is useful to be able to find each other's keys automatically based on the key fingerprint.
I can probably read e-mail encrypted with it just fine as long as I use Thunderbird with my Fastmail inbox (which is most of the time), but not when using K9 Mail on a smartphone or the web UI of Fastmail.
- soraminazuki 3y agoThat's not what public keyservers are for. You're free to use it any other way, but it's unreasonable to shame people who used the keys you advertised in a way that matches general expectations. Besides, it doesn't make sense to upload keys only meant to be shared among a small number of people to a public keyserver. In your case, the keys better belong in the git repo.
- caddy 3y agoI feel like that defeats the purpose of the validation. If you're storing the keys in the same place as the code, it would be very easy if someone gained malicious access to the repo to change the key and sign it with the new key.
- soraminazuki 3y agoI thought the commenter was using the repo for a password store, not executable code? The only consequence of not validating that would be them entering invalid credentials. Even if they’re dealing with code, watching out for new commits that change keys is enough. That’s something that people should be doing when using keyservers too. Anyway, the point is public keyservers aren’t a good match for the described use case. If the key is meant to be kept private, it should be shared privately.