Comment 44 for bug 125103

> https does not help apt-get ...
> apt-get needs signed packages and signed repositories.
I propose to take the keyring(bootstrap) package from launchpad via https, and install it manually using dpkg or some graphical installer. What I was trying to show was that https *does* help this process: it lets you verify that the bootstrap package is associated with someone on your web of trust. Let me try again:

The process goes as follows(for a user's ppa):
1) Go to the developer's homepage, and check that their pgp key is in your web of trust. (over https)
2) Click the link to their ppa and download+install their archive bootstrap/keyring package. (over https)
3) Do an apt-get update (over http). Apt will be able to verify the PPA signature.
Because 1 and 2 are over https, and you trust the server, you can safely trust the keyring package.

> An attacker can not upload compromised packages unless he has the package-signing-key!
> Changing the signing-fingerprint on launchpad should only be possible if signed by the old
> key or with a email-verification-system.
Iff an attacker manages to compromise a developer's launchpad account (which is not a trivial thing to do) The following attack method can be used.
1) Change the contact email address for the account to one under the attacker's control.
2) Create a new key, and register it with the account.
3) Reply to the key verificaiton email.
4) Upload naughty packages to PPA.
This attack will compromise all systems that have already added the ppa key to their keyring, but new users will be able to check that the developer's key is in their web of trust, and avoid the attack.

One way of avoiding the above attack is the following: Whenever a key is added to the trusted keys list (and it's not on the web of trust of an existing key, like Per suggests), the PPA key should be re-created, and a new keyring package created. This will cause all existing installs to break, and force users to re-install the keyring package manually. The event should be recorded on the PPA info page, so users can know why their archive just broke.

Whether you implement this scheme or not depends on whether you trust developers to keep their launchpad accounts secure. To be honest, I would be perfectly comfortable trusting the developer to keep their launchpad account secure. Just add it to the disclaimer when you download the ppa keyring package, and the user can make an informed decision.

> > What key removal should do to the PPA is a point for further discussion
> It should only remove the signature from the repository.
If a developer believes his key has been compromised for some time, and used to upload naughy packages, what should he do? Is there any way to inform the victims of the attack? I guess if it affects a large project then it will be all over the news. My version bumping idea was just a way of getting debconf to show a warning message, but I guess this could be easily circumvented by a smart attacker.

> If a compromised package gets installed, the whole system could be compromised
> and needs to be reinstalled!
I agree. Let's hope we can avoid this happening.