Hi guys,
I'm interested in this too. I'll just give some of my thoughts which may be
horribly
inaccurate, so I'll apologize for them first.
I think the key issue at hand is not about code. I mean, over these past
months we
have seen the basic infrastructure for package signing being incorporated
into
libalpm. So it's not strictly a lack of code or difficulty issue.
Instead, the key issue is the how this whole package signing thing is going
to be
carried out, ie. something like:
https://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman
And this is something that only the main Arch developers, pacman developers
and
trusted users can solve and have to agree on before development can begin,
since
it has a lot of repercussions.
On Sat, May 21, 2011 at 7:07 AM, Kerrick Staley
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