launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04145
Re: Archive deletion strategy - deletion of GPG signing key
On 05/08/10 11:33, Julian Edwards wrote:
> On Wednesday 04 August 2010 21:16:33 James Westby wrote:
>> On Tue, 3 Aug 2010 11:08:03 +0100, Julian Edwards wrote:
>>> I think that's pretty much it, although we need to examine exactly which
>>> database rows need to be deleted and under what conditions. I've added
>>> some ON DELETE CASCADEs in the past where it's a no brainer but it won't
>>> delete everything because of the multiple publication referencing
>>> package files issue.
>>
>> Ok, I've been through the schema and I think this is the set of tables
>> chained off archive:
>>
>> # Archive -> signing_key <- KEEP
>> # signing_key (GPGKey) <- ?
>
> If it's the Person's last PPA then it should be deleted (keys are shared for
> all a Person's PPAs). We should also try and revoke the key and remove it
> from the keyserver.
Some points:
1) Some users will love this feature, because it provides a get-out for
having a current GPG key with a silly user-id. However, some may find it
annoying/surprising.
Plus, the current user experience when uploading to a PPA without a
generated GPG key is very sub-optimal - your first upload is published
unsigned, and the PPA is not signed until it is republished after key
generation has finished.
Therefore, this feature ought to at least be warned about in the PPA
deletion confirm page - if not made optional.
2) Publishing a revocation is mutually contradictory with removing the
key from the keyserver :-)
3) You can't remove a key from the global keyservers network - even if
you remove it from one, they'll sync with each other, and re-propagate it.
Max.
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups
References