On Wed, Aug 12, 2015 at 11:12:05PM +0000, Anthony Towns wrote: > I'm not sure if the idea is PPAs can only be added to by DDs/DMs. If > not, can anonymous folks setup a PPA for pirated software, or try to > compromise the PPA build system or similar? If PPAs are for DDs and DMs > only, I'm presuming they can just use the existing Debian keyring to sign > the PPA Release files. There is a session about Debian PPAs at 2015-08-21 17:00..18:00 @ DebConf, so all the details there I presume, but as far as public information up to today goes (which I have seen) is that they are limited to DD/DM, on Debian infrastructure and signed by the usual archive signing key, so that trust in the archive-key isn't an issue here – the problem is just in "easily" adding PPAs to your sources which while currently bundled in this thread as well, I would like to avoid as a topic for now to focus on the archive-key part for external archives which aren't signed by Debian. > > > > - Apt will try to download it from a default location in the repository > > > > (or perhaps a location specified in the deb822 sources.list file > > > > itself). > > > What the heck is "it" in this sentence? I envision "deb822 sources.list" > > > file, but reading the location of the file from the file itself seems > > > a bit hard to pull of in practice… > > I was thinking of having apt auto-update the file which is put there, so > > that if something changes (e.g., new signatures), we pick that up. > > To use an external repo, you need a deb822 sources.list file and a pubkey. > > To get those, you contact extrepos.debian.net, and either do some sort > of search, or plug in a 6+ digit hex code. extrepos.debian.net spits > back a signed bundle of the repo's public key and a deb822 sources.list > (which includes a description of what the repo is meant to contain), both > named to match the 6+ digit hex code. That could work (see also below), you "just" need to figure out a way of registering an external repository at extrepos.debian.org now, which involves deciding who can register one and how to ensure that what I register is actually owned by me because… > > > Or did you mean that the DD signs the sources.list file directly? Well, > > > then my key isn't usable for that right now, but in exchange the DD > > > might have a slight problem in assuring the correctness of what he is > > > signing: I am the owner of example.org/debian. Trust me. > > I'm not sure this is a problem -- if you're not the owner of > example.org/debian, then the files I download from there won't have your > signature. If they do have your signature, then it's just the question > of whether I trust your random repo, and I can't figure that out just > from knowing who you are. … I was thinking man-in-the-middle here. If I can register example.org/debian with a key of my choosing I can do really bad things, especially if example.org is the domain of a Debian mirror and I manage to trick people into adding this e.g. by claiming that this is a faster mirror… Which isn't much different to how a man-in-the-middle works nowadays on the installation of an archive-keyring by man-in-the-middle the site where the instructions are written down to add the sources.list entry and the key. SSL CAs regularily mess up checking that I am really the owner of example.org I want to get a certificate for and extrepos.d.o would be basically a certificate authority, just not for SSL but for archive-keys. > > > If you are adding archive signing keys it must be hundred percent bullet > > > proof or all of apt-secure is broken. > > So you probably want to be able to say "this key is only valid for this > deb/deb-src url" before doing any of this. Is that possible already? I'm > guessing not. You will be able in apt 1.1 as noted somewhere deep down in this thread. See git for details: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=b0d408547734100bf86781615f546487ecf390d9 https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=4e03c47de15164f2656d9655edab6fb3570cb2f2 So, what you might want to do is drop the archive key "somewhere" which is not /etc/apt/trusted.gpg.d/ and declare with this option where this keyring file is. Maintain this keyring in a -archive-keyring package and you can do key transitions easily. Maintain this package not in the third-party repository but in an extrepos.debian.org archive just containing -archive-keyring packages and you can do 'revokes' of keys by no longer including it in the package, which gives you the 'ping' to the extrepos.d.o service for free in a secure way as otherwise we had to figure out a way to sign the ping, ensure it isn't a replay attack and all that stuff more or less solved for packages. > > > Sure, you are basically automating what is currently done by hand by > > > many users, but as long as they do it by hand its their own fault – if > > > you automate it to one-click they will rightly expect it to be secure. > > That's a fair enough view. I look at it more as "users will do whatever > works. if we can provide a way that works and is more secure, we should > do that, even if that means users blame us more instead of blaming > themselves". > > Unfortunately there is a lot of stuff that's not in unstable or > experimental that users want to play around with, currently users have > to run "curl|sh" or "wget;./configure;make;sudo make install" to do so, > which compared to "extrepo add mythingy-a57d45f; apt-get install mythingy" > is a loss. Maybe I am just pessimistic, but I kinda doubt this would change anything for this class as you usually have to do the 'curl|sh' and similar dance because there is no debian repository – and not few people are on the 'creating one is too much work' camp which is why I mentioned signed debs in my last response as I think is a little more realistic to replace them… in like 1 of 100 cases as the rest is too "cool and hipp" to worry about "legacy distros" now that everything can and should be done in the cloud™ where security isn't a problem… aka: That feels like overseeling. I would prefer if we stick to the problem at hand that it is hard to install an archive-signing key for a given repository in a secure way. > > > Oh, what about "add me" files which just add components? That can be > > > done already and is secure, but lets just imagine someone clicks the > > > "add me" file for Debian-main and after that the one for > > > Debian-main-contrib-nonfree. Pretty obvious that this shouldn't end up > > > creating two sources files, right? (+ the joy of detecting mirrors) > > That's not obvious to me. First because, why would you be adding "debian > main" ever -- how do you have a Debian system without main? Second > because doesn't having duplicate deb lines in your sources.list work > fine anyway? It seems to for me. And third, if this is just for extrepos > anyway, having each extrepo have a unique base url seems plausible. No it isn't fine to have e.g deb http://httpredir.debian.org/debian sid main deb http://httpredir.debian.org/debian sid main contrib If you drop the 'main' from the second (or just the complete first) line everything is fine. But yes, multiple rewrites of this paragrpah turned it into a mess: The point was: if the repository has multiple components, you will eventually need to deal with merging in the funky gui tools adding sources. And for the record: Debian derivatives haven't Debian main in their sources.list by default, but a user might add it – e.g. to get sources packages from there for rebuilding on their distro (no, I am not going to mention distro-cross-grades here because that is usually insane). Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature