Comment 42 for bug 125103

@Chuck Renner:

I don't agree with your first point. An https site certificate is enough trust for most users to trust the server, so the developer should not be forced to sign the ppa key. If the users have the developer in question on their web of trust, their signature can be found on their homepage for verification.

It should be made clear on the launchpad site that by installing a ppa keyring package, the user is explicitly placing his trust in both the developer and the server.

If developers wish to explicitly declare their trust in the server, signing the keyring package would probably be the easiest way to export this information (having the ppa key on your personal web of trust seems pointless, unless there is some automatic way of exporting it to apt-key).

Regarding your second point, I wasn't aware that apt checked for revocation certificates(though I've already demonstrated my lack of knowledge on the inner workings of apt). The debian page on the subject (http://wiki.debian.org/SecureApt) seems to suggest that key rotation is done using updates to the keyring packages. If this is indeed the case, then it is impossible for a developer to securely revoke his trust in the server, unless he can upload a keyring package to another repository that is trusted by the user.

If the user's launchpad account is compromised, this should be reported immediately to the site administrators. If this happens then no amount of key revocation will stem the flow of chaos that the attacker is be capable of.

If the user wishes to remove a key from launchpad, it can be done from https://launchpad.net/~chuckrenner/+editpgpkeys. What key removal should do to the PPA is a point for further discussion: should it automatically delete all packages signed with that key, or should the developer do that manually? Should the server create a package that removes the repository from all users' sources.list.d? Should it also remove all packages installed from that repo(is this even possible)? How far do we go?

I suggest that if a key has been compromised, the developer should immediately get in contact with the site admins. Any packages that were potentially modified by an attacker should be manually version bumped to clean them off users' systems, and a security warning issued (possibly via debconf). This is not something that should be automated.