Ari, I don't know the answers to most of the questions you have asked; I'm trying to figure them out myself. Allan's git repository ( http://projects.archlinux.org/users/allan/pacman.git/ ; see http://projects.archlinux.org/) was supposed to have the latest signing code, but the repository seems to be misconfigured. Allan, can you please put your repository back up? The master branch of pacman has some signing code that I've been reading. It might be up to date; I'm not sure. See https://wiki.archlinux.org/index.php/Pacman_Development Basically, just run git clone git://projects.archlinux.org/pacman.git master and take a look at master/lib/libalpm/signing.c . This has the actual crypto implementation. It uses GPGME ( http://www.gnupg.org/related_software/gpgme/index.en.html)*. *Presumably there is other related code scattered around the repository. I think most of the functionality should be self-explanatory, but I haven't had time to thoroughly look into the code. I'm going to be documenting important features of the code and other things at https://wiki.archlinux.org/index.php/Package_signing ; please add anything interesting you find to that page. As far as I can tell, there is no work going on right now on this issue. It will have to be implemented by myself, you (presumably), and whoever else decides to pitch in; the main pacman devs don't seem to have enough interest. Pretty much all the code that's already done should be self-explanatory, so we shouldn't wait around for Allan, etc. to explain the workings of their code. Also, I think the KSK idea, which AFAIK Allan was going to go with, will make things too complicated (unless it's mostly implemented). Basically, I think each developer should have their own key, that each package will only need one signature, and that the repolists will also be signed by the last dev to edit them. Also, 4 or 5 devs will keep a CD or flash drive with revocation certs for everybody. This system is vulnerable to the compromise of a single developer key, and even more vulnerable if one of the aforementioned disks gets compromised, but it is much better than what we currently have, and the KSK system is basically just as vulnerable. Once we get this system off the ground, we can work out a more sophisticated protocol. I'm going to get some git going, and then I'll put up some documentation on the wiki page I mentioned. It'll probably be done in 2 days or so. -Kerrick Staley On Fri, May 20, 2011 at 5:06 PM, ari edelkind < edelkind+arch-pacman@gmail.com> wrote:

Here are the questions that interest me:

- What's the current state? -> What works now? -> What dependencies does the project have? -> How can i test the current functionality?

- What's the general idea -- the program flow -- of the way it's currently being implemented? Pseudo-code would be perfect for answering this, but really, anything with system-level details will do (the "package signing proposal" is not current and does not contain system-level details).

- What's currently on the plate? I don't need specifics for everything -- some areas can be more general and delved into later, but i do need some specifics so that i can, more or less, jump right in. -> Allan mentions some ALPM interfaces on his page. * How well do they work, currently? * What's good about them? * What's bad about them? * Have new ones been written (committed or not) since that page was last edited? * What are some current ideas for more? -> What more needs to be done before developers can start using it to sign packages? -> What needs to be done before courageous users can start using it to verify packages, manually or automatically? According to Allan's TODO page, it looks like it's just about ready now, but the general consensus seems to be that this isn't the case. -> What are other people currently working on? I don't want to trod on toes or duplicate work.

Is this sufficient information for anyone else to step up and start writing patches? Chime in if you need more info.

ari

Hi, I'm going to point out what the current state of the package signing code is and what is currently being worked on. As a warning I have just got home from a stay in hospital, so I might be ever so slightly terse in my reply. Don't take this as me being an arse... I just figured that it was better to reply now as opposed to giving no reply (as I will be heading back to hospital again soon). On 21/05/11 09:07, Kerrick Staley wrote:

As far as I can tell, there is no work going on right now on this issue.

What!!! There has there been no progress... in two weeks!!! That's right... it has been only two weeks since the last commit to do with package signing was pushed to the master git repo (http://projects.archlinux.org/pacman.git/commit/?id=70cf4546). In fact, it currently 10 days, so it was 9 days when the original emails to this thread were sent. Shock, horror development has stalled! If that was not enough, one way to know the current status of development would be to look through this email lists archives. Hmm.. "trustdb locking issues" would be the last one. Seems a pretty big issue not being able to verify a package that has a signature file without root privileges. So that is probably a blocker that the people working on this have not solved yet. Note there were very, very few replies with suggestions on how to deal with that. On 21/05/11 09:07, Kerrick Staley wrote:

I think each developer should have their own key, that each package will only need one signature, and that the repolists will also be signed by the last dev to edit them.

Good to see you came up with the exact implementation we already have... Pacman reads a single signature for a package (either detached for -U or -Q operations, or in the repo db for -S operation) and the repo has a single detached signature. How those key are distributed across developers and what exactly is used in signing what is not a pacman concern and so has nothing to do with the implementation in pacman. Pacman just needs to take signatures and verify them. Note that how Arch will deal with signing in their repos is being finalised elsewhere, but to reiterate, that has nothing to do with the pacman implementation. So... onwards to what the current status is: - makepkg can build a package and sign it (using gpg) - repo-add can add a package signature to the database and sign the database - a key management tool call pacman-key is implemented. It still needs work and there are a bunch of patches on the mailing list for it. I hope to find time to finalise this in the near future... - pacman has basic signing support. It can: - download and verify the signature for the repo dbs - read package and verify their signatures from repo dbs on -S operations - read and verify detached signatures on -U operations (and -Q, but note above the issues with trustdb locking and root privileges) Things that need done: - figure out the locking issues (1777 permissions on the pacman gpg keyring directory is a workaround, but we may take the yum approach of copying that folder to a writeable location) ... In fact, just look at the list on my wiki page: https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . There is no point me replicating the list here. If you have specific queries about any point, ask specific questions. Most should be fairly clear if you actually take the code for a test spin. As far as what branches to use, all the gpg signing code that I had on a branch has been merged in to the pacman master branch (as stated on the above wiki page...). You might find WIP patches on a gpg branch in Dan's repo depending on what he is doing, or maybe my working branch. I was going to go into more detail on the status of what is done and what needs done, but the quickest way for anyone to find out is to grab the git repo, build it and start using it. Everything for makepkg and repo-add is documented in the man pages so hopefully that should be clear. So you should easily be able to create a signed package and add it to a local repo. If not, ask specific questions and we can improve the documentation. Then you can play around with pacman to see what appears to work and what does not. About the only thing that you need to know is there is a VerifySig option for pacman.conf that takes the value Always/Optional/Never and is given for each repo. If people want further info, ask specific questions. I'm not going to spend my time answering very basic questions about the current implementation that can be easily seen by anyone who spends a small amount of time doing some actual investigation by taking the code for a spin. If you don't have time to do this, then I doubt you have time to contribute anything... Cheers, Allan

All,

What!!! There has there been no progress... in two weeks!!! That's right... it has been only two weeks since the last commit to do with package signing was pushed to the master git repo (http://projects.archlinux.org/pacman.git/commit/?id=70cf4546). In fact, it currently 10 days, so it was 9 days when the original emails to this thread were sent. Shock, horror development has stalled! Although work is happening, I think it's fair to say that it's not happening fast enough to cause problems with duplication. Also, compared to the amount of effort I would like to see going towards this idea, and the amount of effort I am willing to personally put into it, the work the main pacman devs are doing appears to be very little.

Note that how Arch will deal with signing in their repos is being finalised elsewhere, but to reiterate, that has nothing to do with the pacman implementation. Where?

This is why it needs to be kept completely separate from discussions about implementing signature verification work in pacman. Eh? pacman-dev is the most relevant list I've found for discussion of this issue. The key-signing mechanism in pacman (in particular, its ease-of-use) has a direct impact on its adoption, and the two conversations should not be separated.

With regard to key schemes, the security of your system is the security of any package you install into it; in particular, if an attacker has a developer key and controls any part of the connection between you and the central archlinux.org repository, they can modify the .install of the next package you happen to update, and do whatever they want to your system, including altering your GPG install, so there's no point to any sort of specialized key scheme. There will be a list of developer keys, and anyone who can log in to the central repository can change that list, so the responsiblity of key verification will fall on whoever manages the central repository. Revocation just means deletion from this list, and, as Ari correctly points out, a complexer revocation scheme is unnecessary [1]. The security of the central repository and of its contents are hairier issues, and since I don't know how this is implemented, I ask that someone inform me of how the central repository is managed (and of who has the ability to perform this management). It's probably already secure, though. With regard to verifying packages, it should be possible to verify signatures without root privileges as long as root is not updating pacman's keyring. This should be possible without any downsides or crude hacks. If it is necessary to attach an Arch-specific patch to Arch's GPGME package, then that can be done. Ari, you can do this if you want, and if not, I'll complete the task. Also, Ari, I would recommend not spending time theorizing about solutions to small issues such as this: it's better just to code out a solution (and of course test it) and then submit a patch. Discussion about how to implement an idea in code is rarely needed: just do it. For now, let's all just publish our changes to this list so that they can be integrated into the master branch of pacman's git. If people have a lot of code that is not polished enough for pacman's master branch, but that they'd like to share anyway, I'll set up a separate git repository that we can work out of, publishing finished code as patches when necessary. If you are interested cryptography and security, I would highly recommend reading Applied Security by Bruce Schneier (the protocol-related portions can be understood without reading the sections on mathematical and algorithmic underpinnings). Happy hacking and best wishes for Allan's health, Kerrick Staley [1] If a the compromise of a key is discovered and you are informed before updating your system, then a secure channel for key revocation that is independent of the repositories (best done with revocation certificates) would be useful, but this is irrelevant for practical and theoretical reasons. Practically, most people update daily, so there is a very small window in which the discovery of a compromise will be useful. Also, compromises should be rare enough that when they do happen, a news item can be posted on the Arch homepage informing users on how to manually revoke the keys [2]. Theoretically, there's no way to tell whether a compromise happened when you think it did or sometime before. [2] The Arch homepage is insecure (no SSL), so this is a further issue. However, this is all getting to be too scenario-specific; fine-grained analysis such as this should be done only after we have a basic implementation of package signing working.

On 22/05/11 07:33, Kerrick Staley wrote:

If it is necessary to attach an Arch-specific patch to Arch's GPGME package, then that can be done.

I'll point out that this can not be done due to Arch's patching policy. Arch does not patch software for features not provided upstream, so any patch will be required to go to the gpgme and be accepted before it is even considered for the Arch package. I would also suspect, that patches for pacman that rely on unreleased changes to gpgme would not be accepted, so we would then need to wait on a new gpgme release... Allan

On 2011/5/21 Kerrick Staley wrote:

...

Note that how Arch will deal with signing in their repos is being finalised elsewhere, but to reiterate, that has nothing to do with the pacman implementation. Where?

...

This is why it needs to be kept completely separate from discussions about implementing signature verification work in pacman. Eh? pacman-dev is the most relevant list I've found for discussion of this issue. The key-signing mechanism in pacman (in particular, its ease-of-use) has a direct impact on its adoption, and the two conversations should not be separated.

Hello Kerrick, There is no such key-signing mechanism in pacman, and there no plan to have such a thing. Keys are signed using the standard GPG utilities and are completely up to the packagers and repository admins. Details about the implementation chosen by Archlinux can be discussed on arch-general@archlinux.org. You may also find discussions in archives of arch-dev-public@archlinux.org. Rémy.

On 21/05/11 15:53, ari edelkind wrote:

Kerrick Staley wrote:

...

I don't know the answers to most of the questions you have asked; I'm trying to figure them out myself.

I didn't mean to lay all of my questions on you -- i was just making a list of things that i'd like to see answered. I was actually just trying to make your job easier; sorry if it didn't come off that way.

...

I'm going to be documenting important features of the code and other things at https://wiki.archlinux.org/index.php/Package_signing ; please add anything interesting you find to that page.

Excellent. Thanks for taking this on.

...

Also, I think the KSK idea, which AFAIK Allan was going to go with, will make things too complicated (unless it's mostly implemented). Basically, I think each developer should have their own key, that each package will only need one signature, and that the repolists will also be signed by the last dev to edit them. Also, 4 or 5 devs will keep a CD or flash drive with revocation certs for everybody. This system is vulnerable to the compromise of a single developer key, and even more vulnerable if one of the aforementioned disks gets compromised, but it is much better than what we currently have, and the KSK system is basically just as vulnerable. Once we get this system off the ground, we can work out a more sophisticated protocol.

I agree that a KSK implementation is unnecessarily complex. The concept of a KSK was designed for a different purpose -- for authorizing arbitrary numbers of certs. Unless i'm misunderstanding some crucial part of the plan, Arch does not have arbitrary numbers of package builders to worry about.

The revocation scheme is also unnecessarily complex. For that matter, revocation on PGP keyservers wasn't designed for this sort of application, and isn't secure enough for it. If we supply a keyring of valid signing keys, and can replace this keyring when necessary, then revocation certificates become irrelevant.

In this scenario: - The top 3 key holders can still exist (i'll call them the Key Moguls). - The developer generates a key pair and sends his public key to the Key Moguls. - Key Moguls verify the key, and add it to the list of permissible keys. - The list of permissible keys are either retrieved separately by pacman or retrieved as a Special Package. - The list or Special Package (LoSP) is signed with a key from a Key Mogul (or two). - If it passes verification, the LoSP becomes (or already is) a keyring, and _replaces_ the previous keyring. - The Key Moguls' keys are in a separate keyring. This keyring can be similarly replaced if necessary. - If the LoSP has been updated, then users will see a notice, just like when pacman has been updated, suggesting that they update the LoSP before continuing. Or, it can be automatically updated, perhaps with a command-line option for no-auto-update.

The potential security concern that i see with this scenario is if an attacker compromises both a package signing key (dev key) and a mirror. In this case, he can keep the new version of the LoSP from being pushed out, and may continue using the compromised key.

Unfortunately, having the devs sign the repository doesn't help this situation, since if both a dev key and a mirror are compromised, then the dev key could be used to sign an altered repository, and once again, the new LoSP could be omitted. However, if an additional "dev key" can be used to automatically sign the repository _in addition_ to the developer himself, then both keys would have to be compromised simultaneously for an attack to become feasible. I'm not familiar enough with the Arch package distribution+mirror system to comment on whether this is a reasonable thing to implement.

If AUR submissions are ever to be signed (this isn't handled by pacman anyway), _they_ might require a KSK. But AUR submissions are so iffy to begin with that users should be scrutinizing them before (compiling or) installing anyway.

All this is off-topic for this list as pacman will not care how packages and repos are signed. It will just verify whether the package/repo can be validated using the keychain it is provided. Allan