=== chris14_ is now known as chris14 [04:17] umm, can canonical remove unwanted keys from the ubuntu hkp server? [04:19] Hello Juest, do you maintain the hkp server? [04:21] sudhackar: i am just a user asking about the server [04:21] interesting, was that a highlight word for the right people? [04:21] sorry I was just trying to understand the rationale behind the demand [04:22] sudhackar: to answer your question, no, but i am just wondering about whatever exceptions are done with possible high risk cases of compromised keys [04:22] well i know its just public keys but yeah [04:22] is it not possible to accidentally upload private keys, correct? [04:23] excuse my stupidity, i should know this, i was just asking to double check something of my own [04:24] its a hockeypuck server - You can always read their doc [04:24] can others sync with the hkp server? i am not saying its happening right now but im wondering if its possible to have a malicious scenario where syncing would cause a wipe [04:32] I think its valid to treat it with such threat model but both hockeypuck and `gpg --keyserver .... --send-keys ....` can be checked [04:40] :) [04:41] was it thought before? [04:42] sudhackar: so they already have checks to prevent such case? [09:15] Juest: I'm not an expert on gpg keys and keyserver, but my understanding is that if there's a compromised key then the private key holder can issue a revocation, and that is then carried by keyservers. So keys are never deleted as such. On the Launchpad end, users list their keys, so to get Launchpad to stop treating a key as valid, the user can remove it. I don't know if Launchpad pays attention [09:15] to key revocations or not (I'd hope it does!) === chris14_ is now known as chris14 [17:54] rbasak: ah right, thanks for your input :) i mean, what if someone is trying to erase their existence either because of their changed threat model or being a high risk person that is harassed [19:02] if you have such a problem and if you can't remove your own keys using the protocol you can always contact Canonical directly under GDPR rules === Juesto is now known as Juest