ppa archives are not signed

Bug #125103 reported by Reinhard Tartler on 2007-07-10
234
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Launchpad itself
High
Celso Providelo
Baltix
Undecided
Unassigned

Bug Description

The Package indices on the ppa archives are not signed at all, which causes warnings while installing packages.

Ideally, there should be an per user/group archive key (generated and managed by launchpad). This way, the user can trust individual packagers/teams reliably. Please read comments to see why having a single global PPA key might let a malicious attacker install arbitrary software on the user's machine by DNS spoofing.

Celso Providelo (cprov) on 2007-07-24
Changed in soyuz:
importance: Undecided → High
status: New → Confirmed
Christian Reis (kiko) wrote :

Postponing for now, because I'd like us to have a bit more feedback on what is the right thing to do here. I spoke to Reinhard today and he pointed out an interesting issue that adds to this: if the PPA is unsigned, it becomes impossible to use it in a non-interactive session, because apt will force you to acknowledge the risk by typing "yes" when you install packages. This does reduce the benefit of a PPA for situations in which you want to use it in a testbed.

Dave Walker (davewalker) wrote :

We wanted to use PPA, but host our own signed packages so we made a useful work-around which will mirror the repo, then sign the Release.

Hope it helps, feel free to comment.

dinhhuucuong (dinh-huu-cuong12) wrote :

I not use PPa

Joseph Price (pricechild) wrote :

I agree with the point that forcing the user to acknowledge the risk is quite important...

However, I believe that this risk should/could be acknowledged when the user finds the repository and adds it to their sources.list. By adding this repository line and using packages from it, you are effectively trusting the gpg key on the launchpad profile?

So I think that the ppas should be signed with a single key.

André Klitzing (misery) wrote :

Well.... I have two solutions for that. Is it really a good idea to have only ONE key for all PPAs? Does an user trust ALL PPA because he adds one PPA of his choice to his source.list? I would only trust the one that I added....

1. Upload new private key
The PPA-owner can upload a private key to his account for that and launchpad will use that key to sign his PPA. Of course the user should be warned that he should create a new key for that instead of using his standard-private-key.

2. Sign like code of conduct
The PPA-owner could download (or get it per mail) to sign it at his local computer with his key and upload it to launchpad again.
Maybe it is possible to that like signing code of conduct. .. and yes, it is a little bit annoying if an owner upload many packages. But no one needs to sign it... he could use it without it. ;-)

Dave Walker (davewalker) wrote :

I don't think there should be a general key for all PPA's. I think it is quite important for separate users/projects to have their own keys, as mentioned above - to trust one user/projects archive is different to a blanket approval.

I also think that LP could make adding of public key's easier, maybe building them into packages with a clicky "APT:" link that prior to allowing download, warns the user that they must use their judgement in adding the key, whether or not they trust the owner.

Mass roll out of PPA approval could be potentially dangerous, I have an underlying security concern that I'd rather not publish here - but could be disastrous for *many* users. Prior to implementation of this feature I would like to discus this further with the PPA dev' team

Dave Walker wrote:
> I don't think there should be a general key for all PPA's. I think it is quite important for separate users/projects to have their own keys,
> as mentioned above - to trust one user/projects archive is different to a blanket approval.

I don't see how having a single master key for all personal archives could be dangerous. GnuPG keys are used for two purposes:
  A. To verify the provenance of the source packages uploaded to the build system. The system checks the signature of the description files to tell if a source package comes from the owner (or one of the owners) of the PPA. If the signature is invalid, the package is rejected.
  B. To verify the integrity of the binary packages built by the system. This is done by signing the main release file, which contains (typically md5, sha1 and sha256) hashes of the files in the repository.

The problem, which this bug is about, is in that second purpose. This is not about trusting the owner of an archive, but about trusting the built system used by the owner. Therefore, I believe having a single master key for all PPA would be appropriate.

> Mass roll out of PPA approval could be potentially dangerous [...]

The authentication system is not used to approve a repository. If it was so, repositories couldn't be mirrored on different servers managed by different people without sharing the private key used to sign the release file. You approve a repository by adding its URL in your /etc/apt/sources.list, not by trusting the key used.

Johan Kiviniemi (ion) wrote :

Launchpad could create a new PGP key for each PPA. The private keys would never leave Launchpad.

Users would need to apt-key add a separate key for each PPA they’re using, which is a good thing IMO.

Jani Monoses (jani) wrote :

1) regarding interactivity, if apt-get install is passed --force-yes it will not ask for confirmation

2) can the user-only (non team) archives be signed with the LP users key? Existing ubuntu devs already have these in LP. For users of the archive this would be the same as existing 3rd party repos all over the net.

Jani Monoses <email address hidden> writes:

> 1) regarding interactivity, if apt-get install is passed --force-yes it
> will not ask for confirmation

That disables all security checks and disables the whole point
authentification. This is not an option in many (if not most) use cases.

> 2) can the user-only (non team) archives be signed with the LP users
> key? Existing ubuntu devs already have these in LP. For users of the
> archive this would be the same as existing 3rd party repos all over the
> net.

Only the public keys are in LP, not the private ones.

I'd imagine autogenerated keys per team/user by launchpad would be far
easier to implement.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Christian Reis (kiko) on 2007-10-25
Changed in soyuz:
milestone: 1.1.11 → 1.2.1
Changed in soyuz:
milestone: 1.2.1 → 1.2.2
Celso Providelo (cprov) on 2008-01-28
Changed in soyuz:
assignee: nobody → cprov
alsuren (alsuren) wrote :

@Alexandre Vassalotti: it would be trivial to attack any system that uses the PPA if it had a master key:
1) create a throw-away account, and get a PPA account.
2) upload a source package named kde4-core that does Bad Things to the user's machine.
3) get that package back off the server.
4) spoof the DNS records of ppa.launchpad.net, so that it points to your own server.
5) wait for someone to try upgrading kde4-core
6) watch the Bad Things happen to the user's machine.

@Dave Walker: How does your mirror and sign script verify that nobody is spoofing the PPA server when you run your script? (and therefore getting you to sign arbitrary binaries)

What would be really nice is if you could have this situation:

* I always sign all of my source packages with my private key. (call this private_alsuren).
* The PPA servers keep a different private key for me (call this ppa_alsuren). I cannot access this key myself: it is only accessible by the build service.
* When a source package is uploaded, and signed with private_alsuren, the corresponding binary package is automatically signed with ppa_alsuren.
* My PPA automatically contains a package called ppa-alsuren-keyring. (with a similar purpose to ubuntu-keyring, or debian-archive-keyring: it imports the public portion of ppa_alsuren into apt.)

This means that: I can just make all of my packages depend on ppa-alsuren-keyring, and users will only ever get an "unsigned package" warning on the first install.

For team archives, ppa-kubuntu-members-kde4-keyring imports the public portion of ppa_${developer} for each developer in the kubuntu-members-kde4 team.

The kde4 guys can make users apt-get install ppa-kubuntu-members-kde4-keyring before they install kde4-core, and users will only get one "unsigned package" warning.
The core ubuntu devs can create ppa-kubuntu-members-kde4-keyring as a signed package, and there would be no unsigned package warning.

This is both more convenient for users than the current system, and less trivial to attack than Alexandre Vassalotti's system. If anyone thinks of a possible way to attack my system (short of rooting the PPA signing server, or the developer's box) please reply here.

David.

Celso Providelo (cprov) on 2008-02-09
Changed in soyuz:
milestone: 1.2.2 → none
Martin Pool (mbp) wrote :

Perhaps we should also consider serving ppas over https (like the rest
of Launchpad) to increase the difficulty of impersonating the server.
(This is a compliment to not a substitute for signing.)

> What would be really nice is if you could have this situation:
>
> * I always sign all of my source packages with my private key. (call this private_alsuren).
> * The PPA servers keep a different private key for me (call this ppa_alsuren). I cannot access this key myself: it is only accessible by the build service.
> * When a source package is uploaded, and signed with private_alsuren, the corresponding binary package is automatically signed with ppa_alsuren.
> * My PPA automatically contains a package called ppa-alsuren-keyring. (with a similar purpose to ubuntu-keyring, or debian-archive-keyring: it imports the public portion of ppa_alsuren into apt.)

Note that the PPA (like all apt archives) is signed at the archive
level, not the individual package level. So as far as I know we can't
use different keys depending on the keys used to sign the source
upload - I'm not sure if you were requesting that or not.

Note also that PPA already verifies the source package is appropriately signed.

Putting the public key in a package in the PPA would not be very
useful in bootstrapping, as users would be getting the pubkey from an
untrusted source.

It would be more useful for the PPA web page to include a link to the
PPA signing key - either a GPG command to get it, or just the url from
which it can be fetched.

--
Martin

alsuren (alsuren) wrote :

Ah. Seems that I have misunderstood how apt signs packages. You're right: keyring packages stored inside the ppa are indeed unreliable for bootstrapping trust. They would only be useful in the same sense that ssh's server keys are useful.

I only suggested it because I know some people who have broken keychains, and just type "yes" each time they get the warning message (because that's what they did on windows). I think that this is really a bug in apt-get or aptitude though: the warning message should really contain instructions on how to import the required keys (ssh-style opportunistic cryptography is better than none at all). Doing everything from within the aptitude command would be ideal.

It would also *not* be sensible to have a central keychain repo that contains the keys for all PPAs, because that archive would be signing the keys of untrusted developers as well as trusted ones.

I still think that it would be useful to have a signed archive of keychain packages for PPAs whose maintainers *are* trusted though, as this *would* successfully bootstrap trust for these archives.

Morten Kjeldgaard (mok0) wrote :

How about this solution:

(1) The PPA owner encrypts a file with a secret passphrase encrypted with his/her own private key and Soyuz's official public key.

(2) Soyuz -- having the user's public key -- is then able to decrypt the passphrase and generate a new, user-specific key pair for PPA package signing only, protected by the user-supplied passphrase.

(3) Soyuz mails the public key to the PPA owner, who is now able to verify the packages from the PPA. The owner can distribute the public key to everyone who needs to use the PPA.

(4) The user should NOT have a copy of the secret key.

With this scheme, only Soyuz is able to decrypt the passphrase. Naturally, Soyuz's secret key must not be compromised, as well as the PPA owners'.

Colin Watson (cjwatson) wrote :
Download full text (4.1 KiB)

I sent a mail about this to the internal Launchpad list on 8 February, but there's no reason for it to be private, so I'm copying it here.

I understand that this is the most immediately straightforward solution [ed: single key for all PPAs], and I'd like to have PPAs be signed too. I'd love to be able to say "go ahead and we'll fix it later". In fact, I'm not sure it's clearly the distro team's call, as we only have a tenuous ownership of PPAs. However, I do have a serious concern with this approach, which I think I can demonstrate quite easily. (This is based on a conversation I had with Celso on IRC today.)

The only real cryptographic purpose of a single-key-for-all-PPAs signature, as far as I can think of, is to guard against DNS poisoning attacks. It clearly doesn't authenticate the uploader; it just says "this came from ppa.launchpad.net". Since that has no value in itself as to a first approximation anyone can upload to a PPA, the only thing that that says in turn is that your connection to ppa.launchpad.net was not intercepted, for example by somebody who has managed to take over your local DNS server and can cause the system of their choice to claim to be ppa.launchpad.net.

The problem is that a single-key-based signature scheme doesn't actually prevent this attack at all. All you need to do to attack this system is
to sign up for a PPA yourself, and then you can upload whatever you like (provided that it is a well-formed package) and have ppa.launchpad.net sign it for you. Now you have a repository you can simply download and substitute for the one that your victim requested, and all the signatures will pass.

The usual terminology for this is that ppa.launchpad.net is allowing itself to be used as an oracle for people trying to mount chosen-message attacks. This is not generally a good idea if you can avoid it.

The result of all this is that you have a system that *looks* fairly secure to an ordinary user, in that there are signatures on every step which all pass and which can be verified automatically by apt after a small amount of initial setup, but which is actually trivial to circumvent. I think this is worse than having no key at all.

I also have some concerns that exposing a cryptosystem to a chosen-message attack might make it much easier for an attacker to either factorise the key or come up with at least a selective forgery attack (the ability to produce a signature on the message of your choice). I'm not familiar with the state of the art here, but it should be a concern. It's always better to avoid opening this door if possible.

Finally, once we deploy a key signature scheme, we need to consider migration. I think it will be more difficult to migrate to a better scheme when the flaws in this one are publicly demonstrated, because at that point there will be the additional consideration that you're breaking users who are already using those PPAs.

With regard to per-PPA keys, Celso raised a concern that storing the per-PPA private key blobs in the Launchpad database would be a security concern. I agree. The standard fix for this is to "wrap" (i.e. encrypt) each key using a "key-encryption key" (KEK) owned by whate...

Read more...

Tomás Reyes (trcecilio) wrote :

I think the most simple solution to this is just to have a simple key for all PPAs. This would ensure that the package comes from the PPA as intended. Users should be aware that packages from PPAs are not 100% safe. If an uploader system is compromised, for example, and the personal keys and passwords are present in the system; the PPA would be compromised.

Martin Pool (mbp) wrote :

Thanks Colin, that's a very nice summary.

As I suggested above, using https for the archives would seem to be the correct tool to protect against DNS poisoning or network interception, and almost all the parts needed to do it are already there.

Martin Pool (mbp) wrote :

Today my Hardy machines are asking to do a partial distribution upgrade. Because I have packages installed from a PPA I get an error and can't continue with the upgrade.

Running dist-upgrade from a terminal works.

Colin Leroy (colin-colino) wrote :

I've got the same as Martin Pool yesterday too, with claws-mail's PPA. It seems to be an annoying side-effect of the packages being unsigned.

William Grant (wgrant) wrote :

I'm not seeing that as a bug. Upgrades with 3rd-party packages are a very bad idea. The more they're discouraged the better.

Martin Pool (mbp) wrote :

> I'm not seeing that as a bug.

I think that's a really bizarre position. You want to leave people unable to upgrade as some kind of punishment for previously installing software from a PPA?

Anyhow, this is getting offtopic for this bug, and probably a bug in synaptic.

Martin Pool (mbp) wrote :
Colin Watson (cjwatson) wrote :

Tomás Reyes: You say "This would ensure that the package comes from the PPA as intended", but actually, no, it wouldn't do that at all, it would just make people think it did that while in fact allowing trivial attacks. Please review my comment that I posted immediately before your own, in which I gave a simple demonstration of why it would ensure no such thing. You also said "If an uploader system is compromised, for example, and the personal keys and passwords are present in the system; the PPA would be compromised", and in a system with a single key for all PPAs there is no way to pass that information on to the user.

Designing cryptographic protocols (by which I mean the higher-level protocols, not just bit-banging) is not easy, and it is not wise to trust solely to instinct while doing so.

Alex Salt (holy.cheater) wrote :

IMO, PPA needs only one key for signing.
As uploader you verify your identity when you are uploading package _source_ to PPA.
PPA's signature verifies that the data you get when installing package means that it came from PPA without data loss/corruption

Signature verifies the source of data and it's integrity, but not it's reliability.
Concerning packages: No signatures and encryption won't ensure that you can't trust software you download from PPA. And it doesn't matter if it is signed or not. And you can't be sure it doesn't contain any 'badware' unless you look through the source (something unreal in most cases, and unreal to ordinary users). By downloading package you agree that you trust it. If you don't - don't download and install it.

So, signing will just ensure data integrity. It can't provide more, it isn't designed to do so. As a bonus, you will get rid of annoying messages and the bug with dist-upgrade. There's no reason for lots of keys for each PPA or some other forms of signing and encryption - they wouldn't bring you security.

alsuren (alsuren) on 2008-05-03
description: updated
alsuren (alsuren) wrote :

@Holy Cheater:
I have updated the description. Please read Colin Wilson's first comment, and if you can think how his attack would fail, outline it here. I think we would all like to go for the simplest solution that is safe. If someone can prove that using a single key is safe, it would save the developers a lot of effort.

The whole point of signed archives is for users to place their trust in developers, so they don't *have* to individually check each package. If Debian didn't consider this important, they would have opted for simple md5sums.

Alex Salt (holy.cheater) wrote :

@alsuren:
Sorry, I've missed the part about chosen-message attack.
But still, key for each PPA would localize range of vulnerability to 1 PPA.
What about Martin Pool's idea of accessing ppa through https? Would it give protection from this type of attack?

> The whole point of signed archives is for users to place their trust in developers, so they don't *have* to individually check each package. If Debian didn't > consider this important, they would have opted for simple md5sums.
I didn't use Debian, but are their repositories open for anyone to upload like ppa?
And again: signing archive with your key means you are identifying yourself to build system, and signing the whole archive(repository) by server which holds it - is identifying integrity and source of data, as mentioned earlier.
You can make your own archive on own server and sign it - still, it wouldn't give you any trust, it would just verify that you are you.

Bryan Donlan (bdonlan) wrote :

On Sun, May 04, 2008 at 04:42:16PM -0000, Holy Cheater wrote:
> @alsuren:
> Sorry, I've missed the part about chosen-message attack.
> But still, key for each PPA would localize range of vulnerability to 1 PPA.
> What about Martin Pool's idea of accessing ppa through https? Would it give protection from this type of attack?

Yes, having /different/ keys for each PPA helps prevent the attack. And
https should block this particular attack, but it won't shut up APT :)

>
> > The whole point of signed archives is for users to place their trust in developers, so they don't *have* to individually check each package. If Debian didn't > consider this important, they would have opted for simple md5sums.
> I didn't use Debian, but are their repositories open for anyone to upload like ppa?
> And again: signing archive with your key means you are identifying yourself to build system, and signing the whole archive(repository) by server which holds it - is identifying integrity and source of data, as mentioned earlier.
> You can make your own archive on own server and sign it - still, it wouldn't give you any trust, it would just verify that you are you.

Correct; however, in order to have trust, first one must have identity.
If I decide to trust you, it does no good at all unless I can verify
your packages really came from you.

For example: If the Kubuntu team decides to make a PPA for, say, the KDE
4.1 alphas, I might decide I trust them. In that case I should be able
to add their specific PPA key to my keyring so I trust their packages -
without worrying about DNS hijacking attacks. This is only possible with
seperate keys for each PPA.

alsuren (alsuren) wrote :

On Sunday 04 May 2008 17:42:16 Holy Cheater wrote:
> @alsuren:
> Sorry, I've missed the part about chosen-message attack.
> But still, key for each PPA would localize range of vulnerability to 1 PPA.
As I understand it, it would localize it to "users trusted to upload to that
PPA", which is dramatically smaller than "anyone in the world that has a
launchpad account".

> What about Martin Pool's idea of accessing ppa through https? Would it give
> protection from this type of attack?
I think so, but I don't know enough about the structure of apt. I suspect that
it might be possible to use a ppa to get an archive that's signed with a
trusted key, and then simply spoof DNS for any other archive that's not done
over https. Does apt-get warn the user if a repository's key changes from one
trusted key to another?

>still, it wouldn't give you any trust, it would just
> verify that you are you.
The concept of "trust" happens when the user adds your [archive] key to their
apt trusted keys list. They need to be able to place trust in a single person
or team, because trusting everyone on an open system would be worse than the
Windows situation of no trust at all.

Trust networks are pretty tricky to determine "this is safe". That's why you
always peer review them like this.

Martin Pool (mbp) wrote :

@holly

> What about Martin Pool's idea of accessing ppa through https? Would it give protection from this type of attack?

I did specifically say above that it's not a substitute for archive signing. It won't silence apt and it won't protect against all attacks.

My reasons for suggesting it are: it seems like most of the infrastructure is already in place and therefore it may be faster/easier than per-archive signing keys, and it gives some practical protection against network attacks.

Bryan Donlan (bdonlan) wrote :

On Sun, May 04, 2008 at 05:44:18PM -0000, alsuren wrote:

> > What about Martin Pool's idea of accessing ppa through https? Would it give
> > protection from this type of attack?
> I think so, but I don't know enough about the structure of apt. I suspect that
> it might be possible to use a ppa to get an archive that's signed with a
> trusted key, and then simply spoof DNS for any other archive that's not done
> over https. Does apt-get warn the user if a repository's key changes from one
> trusted key to another?

apt-get maintains a list of trusted keys - by default this is the ubuntu
archive key (or in debian, the debian archive key) only, but you can add
more. apt-get does not care which key a particular archive uses,
provided it's on the trusted list.

However, using https + single apt key gives no protection over pure
https. It's not good to give only an illusion of safety... :)
And APT does not take https into consideration when determining whether
to trust the origin of a package.

Toni Ruottu (toni-ruottu) wrote :

> Putting the public key in a package in the PPA would not be very
> useful in bootstrapping, as users would be getting the pubkey from an
> untrusted source.

It would be very useful because most users would then be getting something from an untrusted source only once. Even if it was this easy to install the public key, many users might still just select "yes" for each untrusted package separately instead of getting the key. Maybe the user should be forced to install that package (but that is the matter of another bug thread). It is also lot less likely that there would be someone attacking the user at the arbitrary point in time when the user decides to start using a PPA, than at the time of installing some untrusted single package. In addition this approach does not prevent anyone from getting the keys in another, more secure manner.

Bryan Donlan (bdonlan) wrote :

How about putting the key packages (ppa-key-$username, for example) all into a single shared PPA repository, signed by a key in the ubuntu keyring (or a key in a package in the main ubuntu repo)? This way one could have a trust path to follow to ensure one is really getting a key for the PPA in question.

Martin Pool (mbp) wrote :

Assuming a .deb is the best way to add keys to apt, it might be best
just for Launchpad to have a download link for that one package. Then
gdebi will come up to let the user confirm they want to install it,
and then they'll be able to access the apt repository. There's no
problem with bootstrapping an authenticated repository.

Toni Ruottu (toni-ruottu) wrote :

Maybe such a package could then also install /etc/apt/sources.list.d/ppa-$username.list
This makes adding a repository as simple as installing that one package.

phobie (phobie) wrote :

1.
A download link is not an option! Debian is good because it shows users which software can be updated and let it be updated with very simple actions. *.deb downloads are a nice extra but should never be the wanted way to go.

2.
A software-package should not be altered to fit Ubuntu-PPA! No keyring dependencies and no automatic sources.list additions! PPA-packages should be easily migrate-able to other repositories like sid or universe!

3.
https is not really needed because dns-spoofing is not an option for most attacks and the system is protected by package- and repository-signing

4.
Repository-signing should be done by launchpad with one separate key per user- and group-repository!
It would mean that we trust the launchpad distribution system. Unless you host your own repository on your own computer and mirror that on the net, you always have to trust the repository-hoster...

A less comfortable but more secure way to go would be to commit every upload, by unlocking the signing-key stored on launchpad each time a package should be committed to the repository.

I think it is enough to trust the users package-signature and let launchpad do the repository-signing-stuff without interaction...

5.
Launchpad should automatically generate a keyring-ppa-<group|user> package on every repository.

alsuren (alsuren) wrote :

@Per Hansen
1. I think a *.deb download for the keyring and sources.list.d is the best idea we've had so far. As long as the .deb is only used for bootstrapping, and can be automatically upgraded to (for example) revoke compromised keys, we should be okay. The only other reason to avoid manual *.deb downloads is that it's prone to dependency hell. We should try to make sure that the packages do not depend on anything that isn't already contained within stock ubuntu/debian.

2. is a good point. I only suggested the fake dependency for bootstrapping purposes, but a downloadable *.deb would be more elegant.

3. I agree. simple HTTP is more scalable and cacheable. We want to make it easy for people to mirror PPAs if they become very popular.

4. The separate keys issue should be taken as settled.

Regarding the manual unlocking of keys for each upload: I think we're already forced to trust the launchpad system to be secure, as we're using it for compilation. Trust in any key automatically implies trust in the machine on which the signing is done. I see no security benefit in having to manually unlock the key each time.

I agree with 5. Whether it should be a separate package from the one which installs the sources.list.d entry is an implementation detail.

@Bryan Donlan: I'm not sure whether ubuntu should really be taking responsibility for signing the PPA-keys of untrusted developers. The fact that launchpad is served over https is probably a more appropriate trust path for this application. If any PPA keys appear in trusted repos, they should only be those of trusted developers. See my comment of 2008-02-11 for details.

Toni Ruottu (toni-ruottu) wrote :

The biggest remaining problem is getting the user to understand what she is doing.
Once you have installed a package, you'd normally expect the software to work.
This is of course easy for us to figure out, but it might look awful to a grandmother.

1) gm goes to web site with knitting software (that is hosted in a ppa, but gm doesn't know that)
2) gm clicks on download and then on some Ubuntu logo
3) gm chooses downloads a package that says knitting-assistant-magical-ppa-enabler.deb
4) Ubuntu suggests gm to open the package with a gui
5) gm clicks ok
6) something happens
7) Ubuntu reports that the package has been installed
8) gm cannot find knitting assistant under "Applications" menu

9) gm revisits the download site
10) the site guides gm to select "Add/Remove..." under "Application"
11) gm does that
12) gm searches for knitting
13) nothing comes up
14) gm visits the download page again
15) the page suggests gm to choose "all available applications" from the gui
16) gm does that
17) knitting software appears
18) gm checks the check box
19) and selects "apply changes"
20) Ubuntu confirms a couple of times that gm really wants to install that stuff
21) the stuff gets installed
22) gm closes "add/remove"
23) gm selects knitting software from "applications"
24) gm is now happy

25) gm is visiting friends house
26) gm tells her friend about this ultra cool knitting software
27) gm tells the software is available from "add/remove"
28) it isn't
29) gm recalls, "You had to select some option first"
30) "oh yes" the "all available software" option
31) still doesn't work
32) "well it was available also from the knitting software website. It didn't work for me, but still"
33) friend goes through phases 1-8
...
41) they give up?

phobie (phobie) wrote :

@alsuren:
1. Ok

2. Better use a dependency-package and do NOT alter software-packages for PPA.

3. Ok

4. Ok, unlocking has been ment as an option. I do not prefer it...
Yes, we trust launchpad for compilation so we can trust launchpad for repository signing.

5. Ok, <group|user>-ppa-keyring and <group|user>-ppa-repository ?

How to install packages from my repository:
"""
wget http://ppa.launchpad.net/phobie/ubuntu/pool/main/r/phobie-ppa-repository_1_all.deb
wget http://ppa.launchpad.net/phobie/ubuntu/pool/main/r/phobie-ppa-keyring_2008.06.23_all.deb
sudo dpkg -i phobie-ppa-*_all.deb
rm -f phobie-ppa-*_all.deb
# now use your favorite packaging tool to install tvbrowser
# i.e.
apt-get update
apt-get install tvbrowser
"""

alsuren (alsuren) wrote :

We seem to agree on all points :D

5. <group|user>-ppa-keyring and <group|user>-ppa-repository and maybe also <group|user>-ppa-bootstrap this would reduce it to:

"""
wget http://ppa.launchpad.net/phobie/ubuntu/pool/main/r/phobie-ppa-bootstrap_1.deb
sudo dpkg -i phobie-ppa-bootstrap_1.deb
rm phobie-ppa-*_all.deb
# now use your favorite packaging tool to install tvbrowser
# i.e.
apt-get update
apt-get install tvbrowser
"""

or simply:
click this link (phobie-ppa-bootstrap_1.deb, should be served over https, as discussed in my previous post); let gdebi handle installation.
apt-get update; apt-get install tvbrowser

if it were possible to get gconf to request a repository refresh :P

Chuck Renner (chuckrenner) wrote :

Here is my two cents worth on the following:
> 4.
> Repository-signing should be done by launchpad with one separate key per user- and group-repository!
> It would mean that we trust the launchpad distribution system. Unless you host your own repository on your own computer and mirror that on the net, you always have to
> trust the repository-hoster...
> A less comfortable but more secure way to go would be to commit every upload, by unlocking the signing-key stored on launchpad each time a package should be committed
> to the repository.
> I think it is enough to trust the users package-signature and let launchpad do the repository-signing-stuff without interaction...

I agree that a developer should not have to generate another set of keys for launchpad. The one he uses should be the only one he has. The server should automatically generate a keypair for each developer/team, and should automatically sign the generated binary packages on behalf of the user or team that uploaded the source.

HOWEVER, I have two caveats (and I feel they are critical):

First, the launchpad user should have to sign the public key of the ppa server for his account, to acknowledge that he/she trusts it! He or she could sign the server's public key for his or her ppa, after verifying the fingerprint of the same public key. This signature should be exportable, so that the "web of trust" concept can work, and a user that places full trust in a launchpad user will effectively place trust in the server's generated files on his behalf.

Second, the launchpad user should automatically be granted revoker rights on the Private key for the server's ppa. This way, if his launchpad account has been compromised, or if the developer loses faith/trust in the server, he can revoke not only his signature on the server's key, but also actually revoke the server's public key for his PPA as well. This is fair, considering that the server is effectively signing code on his behalf (so he should have the ability to automatically stop this at any time). The user can then upload his revocation certificate to both launchpad, and if desired, to other key servers as well. It is relatively easy to grant revoker rights to a user, and launchpad does not need to reveal the private key to anyone, including the user himself.

Everything I mentioned above can either be completely automated, or mostly automated.

phobie (phobie) wrote :

Yes, someone should code that into the Launchpad software!

alsuren (alsuren) wrote :

@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.

phobie (phobie) wrote :

@alsuren
> An https site certificate is enough trust for most users to trust the server

https does not help apt-get ...
apt-get needs signed packages and signed repositories.

> so the developer should not be forced to sign the ppa key

Not needed but nice to have.

> If the user's launchpad account is compromised, [...]
> If this happens then no amount of key revocation will stem the flow of chaos that the attacker is be capable of.

A 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.

> What key removal should do to the PPA is a point for further discussion

It should only remove the signature from the repository.

> Any packages that were potentially modified by an attacker should be manually version bumped to clean them off users' systems

If a compromised package gets installed, the whole system could be compromised and needs to be reinstalled!
A updated package can not always remove all changes because a compromised package can download and execute virus-addons which can do unpredictable stuff...

alsuren (alsuren) wrote :

> 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.

Toni Ruottu (toni-ruottu) wrote :

Maybe a software repository/channel boot strapping package could have distinct file suffix and/or mime-type? Or maybe the installer application could help user understand that he is enabling a software channel and not installing a software package?

Chuck Renner (chuckrenner) wrote :

I still stand by my original two points:
* A ppa uploader should have to have the server generate a key that the server will use to sign packages created by the server specifically for his/her PPA acount.
* A ppa uploader should have the ability to revoke his signature on the server. If apt does not support revocation certificate lists, it should. This is an important and critical part of any Public Key Infrastructure (PKI) system.

This would accomplish the following:
* Each PPA uploader would have a key for their selves
* Each PPA uploader would request the server to generate a keypair for the purpose of signing automatically generated packages by the server.
* The PPA uploader would sign the generated public key of the server for their account, indicating his trust, and indicating others can rely on his signature for trust (an exportable signature).
* Using the "web of trust" model, a user that trusts the PPA uploader, would in-turn be able to automatically trust the server-signed packages
* Complete automation for installations from PPA archives is possible this way!
* It uses the fundamental design principals of PKI. This method is not new. It is identical to the "web of trust" idea that was implemented by Phillip Zimmerman in PGP many years ago, and which was used as the basis for GNU Privacy Guard (GPG).

The reason that this particular method is important to use is that end-users should not be forced to trust ALL PPA packages. Many of them are probably completely unsafe, and it is very easy for a user with malicious intent to create a PPA account. It makes no sense to me to create one key used to sign all PPA packages. This could easily be exploited by malicious scripts to download malicious PPA packages.

I would not endorse or recommend and method that uses a single key for the entire PPA server. It breaks all of the fundamental purposes of code-signing, and becomes an instant security hole for every PPA end-user. I don't know why we would even consider using a single PPA key for the entire server!

Emmet Hikory (persia) wrote :

The fundamental failure of the per-archive signing key system is that the PPA uploader does not control the secret key used to sign the packages. In the event of any compromise of launchpad, a very large number keys could be disclosed. While presumably these could all be revoked, reissueing that many keys adds significantly to key pollution in the web or trust.

Aside from possible issues with having secret keys hosted in a centralised location, traditionally each identity registered for a key has been associated with an email address, and many GPG users have developed the assumption that sending an encrypted email to a given identity will allow the recipient to read the message. In the absence of direct control of the secret key, the PPA uploader will be unable to read these messages, which may result in frustration or reduced trust for some communications.

Additionally, it is very much worth considering the case of team PPAs: how are these keys to be generated or applied? How are identities to be defined? Who would sign them?

Note that I am not advocating the case for a single key to sign all PPA archives, but rather just pointing out some of the complications with the per-archive key model. Both are suboptimal, for different reasons.

Andrew Fuchs (fuchs.andy) wrote :

On Sunday 31 August 2008 01:37:09 pm Chuck Renner wrote:

> The reason that this particular method is important to use is that end-
> users should not be forced to trust ALL PPA packages. Many of them
are
> probably completely unsafe, and it is very easy for a user with
> malicious intent to create a PPA account. It makes no sense to me to
> create one key used to sign all PPA packages. This could easily be
> exploited by malicious scripts to download malicious PPA packages.

Your point is moot. If an attacker can run a malicious script on a
machine, the machine is already compromised. Coincidently, for a
malicious package to be installed, a user (who has root access) must be
tricked into installing it, or the machine broken into. It would be just as
easy to trick a user into running a malicious script.

The only reason I can think of (and why I want it done) to sign PPAs
would be to prevent man in the middle attacks.

Changed in soyuz:
milestone: none → 2.1.10
nunogt (nunogt) wrote :

Hi, could you please provide an update on this situation? I understand there might be security concerns, but users should be granted the possibility to trust a specific PPA repo (I think we all agree a common key for the entire server would not be safe). Currently any update from ppa triggers a scary warning and breaks scripts. That's ugly and should be fixed.

Hello everyone.

A fix for this issue will be commenced very soon, watch this space.

For the curious, we'll be using one signing key per PPA which will be generated by Launchpad, including for existing PPAs. It's up to the PPA owner to sign the public part of that key.

Changed in soyuz:
milestone: 2.1.10 → 2.1.11
Celso Providelo (cprov) on 2008-11-22
Changed in soyuz:
status: Confirmed → In Progress
Emmet Hikory (persia) wrote :

This bug was recently set as "In Progress". Would it be possible to add a fuller description of the planned signing model to the bug to inform interested parties? Useful components of such a description would include information about the expected content of the per-PPA key (e.g. Name, comment, email, etc.), and a best-practice procedure recommendation for users to be able to sign a PPA public key in a manner that ensures that it is indeed the correct key.

Savvas Radevic (medigeek) wrote :

I agree, a bit more detailed about this work could be announced at http://news.launchpad.net/ or here.

Changed in soyuz:
milestone: 2.1.11 → 2.1.12
Martin Pool (mbp) wrote :

Users are complaining in dupes of bug 218086 that this prevents upgrading to intrepid.

Savvas Radevic (medigeek) wrote :

Martin, unfortunately users are always suggested to uncheck any third-party repositories before upgrading to a new release. Anything that doesn't belong to the original distribution can and probably will create problems.
But I agree that it is an issue that must be solved somehow - perhaps explaining that the users should remove/disable any third-party software repositories?

My opinion is that unsigned packages (or unsigned packages list) shouldn't be allowed to be installed, as it is a common security risk that I believe none of us wishes to take.

Celso Providelo (cprov) wrote :

RF 7399 has the last changes required to complete https://dev.launchpad.net/SoyuzSignedArchives.

Changed in soyuz:
status: In Progress → Fix Committed
Martin Pool (mbp) wrote :
Celso Providelo (cprov) wrote :

PPA signing key generation infrastructure is available in production and my PPA is already using one. We are depending on some hardware rearrangement for being able to generate all (1k8) keys needed. That will be done soon.

There was only a small issue with the signing key UID format we use, please follow up on bug #309202.

Changed in soyuz:
status: Fix Committed → Fix Released
jcfp (jcfp) wrote :

Celso, looking at your ppa (and assuming that's what it's going to look like for all of us) I see that below the apt sources.list entries it mentions the ppa being signed and provides a link to the key. So far, so good.

But it then continues with a second link saying "Follow these instructions if you want to install packages from this PPA", suggesting to the reader there's specific instructions available dealing with using a signed ppa. Instead, one gets to a generic page that is mostly about a ppa owner's side of things, with a procedure for actually adding a ppa hidden behind a second link. (Adding to that, said procedure seems to depend on having a standard graphical ubuntu install using gnome, and has only a very minor part dedicated to the key/signing stuff.)

Anything beyond mentioning the archive being signed and providing the link to the key seems unnecessary; any ppa owner that feels detailed usage instructions are necessary could add those in the ppa description?

Savvas Radevic (medigeek) wrote :

Can you estimate the time of availability of this implementation for Launchpad-edge users? :)

I see Celso's ppa is signed. What do I need to do so that my ppa is signed?

Celso Providelo (cprov) wrote :

Joshua,

We are still working on some infrastructure changes for accommodating signing-keys for all PPAs. It should happen next week.

Max Bowsher (maxb) wrote :

The above-mentioned "next week" has passed. I asked on #launchpad, apparently they are still awaiting delivery of a hardware RNG to make the large amount of crypto processing feasible.

Max Bowsher (maxb) wrote :

Keys seem to be showing up on keyserver.ubuntu.com now :-)

Some crude calculations based on the current trend and the number of active PPAs shown on https://launchpad.net/ubuntu/+ppas suggest that it will finish in the early hours of Friday morning UTC.

Changed in soyuz:
status: Fix Released → Fix Committed
Changed in soyuz:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints