[pacman-dev] Finishing off the package signing issue -- call for contributors

[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 at 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
>
>