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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
