[pacman-dev] Package/database signing

[Gerhard Brauer]

(I hope i don't triple-post this mail, sorry)

Hi,
i took this mail from arch-dev-public and arch-general discussion about
"Can we trust our mirrors"


Am Mon, 1 Dec 2008 11:06:02 -0600
schrieb "Aaron Griffin" <aaronmgriffin at gmail.com>:
> 
> There's too much talk on this idea. Before we go ahead and do this,
> could someone submit this patch to the pacman-dev list, so the pacman
> developers can give it a once-over. Just make sure to let them know
> that this is a temporary solution.  

I attach my patch to repo-add and a pacman download script to explain
how things *could* be done. A proof of concept, working and tested on
my local repo.

> Additionally - where will gpg get the key from on gerolde? Shouldn't
> this be configurable, or even set via an optarg to the -s param?  

In my environment the signing key is getting from my sec-keyring, cause
i start repo-add under my UID. It's the default key in gpg.conf if you
have more than one key. And of cource: on gpg command line the key could
be selected by several criteria, also from a special keyring. Keyring
or keys must kept secure of cource, so mostly the are in $HOME/.gpg

This is only a concept for signing the package db for the repos. These
database files are created only on gerolde (?) an should be signed only
there and from the process which creates the database. This is repo-add.

#Q: Which key, where does it come from, how to prevent this key(s)?
I would assume only one secret key for database signing. AFAIK from
Pierre repo-add is under normal procedures not called directly by the
developers, only from upload/build scripts.
So one solution maybe: create a dedicated user. repo-add then is
running *only* under this UID. The secret key could be in the $HOME of
this user, so it's secured from other access. Only god mode users on
gerolde could "see" it, and maintain it (revoke, renew, etc.).
In the scripts which called repo-add (or if single users must call
repo-add directly) we could call it with su or sudo. Without special
key selecting then the key is took from $repo-add-userid's keyring and
cause it's the only keys it is automatically the default key.

#Q: How to implement this in pacman on users side?
In my test i use the pacman.conf option XferCommand and a special
download script for. I call it like this:
XferCommand = /tmp/pacsigdl %o %u
Each download is checked if this is a *.db.tar,gz. If yes, the file is
verified with the public key part from above. If verification is ok
then pacman continues with this db file as usual, if verification
failed pacman ignores the downloaded (corrupted) file and signals this
for this special repo db (but continues with the rest of a -Syu). No
new database for a repo -> no new packages to download/install.

That way with XferCommand is not a real solution:
a) It makes pacman intern downloading (libalpm) obsolete.
b) Downloads for *all** packages(incl. database files) must be handled
with wget or curl, which produces verbose or zero output which breaks
our normal pacman output.
c) The verifying part should not be delegated to the user. Ideally
pacman would handle this process itself. (I'm nor a c programmer).

#Q: Must we real use gpg command line? Must we use gpg?
My experience with other Trust-Solutions are low. Also it seems that
there are no good libraries to gpg for accessing functions from c
programs. http://www.gnupg.org/related_software/libraries.en.html
Thomas(brain0) mentions for ex. gnutls or openssl
If we could integrate gpg (command-line or by lib) better in our
framework then i think: gpg is a good, well known solution.

#Q: Signing only the database is not secure!
Yes, it would currently only secure our package hash/checksum functions
against manipulations, not the packages itself.
But IMHO it's a good starting point to get forward. Ideally we must sign
the db files also when we sometimes have a super dupper package signing
framework ;-) So let's start (and gain experience) fist with the db
files.
Currently our check-sums(md5) are only download check-sums. They could
be manipulate (and therefor easily the corresponding package) on each
station after the db leaves gerolde. From a secure view the checksums
are useless.
If we sign our db file we secure the checksums against manipulating.
Not the packages itself. But package manipulating is a lot more
difficult to do as in our current situation.
And we could switch to a better package check summing solution than
md5sum to gain more secure against package manipulation. Ideally we
come some day to a framework were also the packages are signed by
packagers/developers. Some days. Next step.

That are my thoughts on this thing. Surely not complete.
(Sorry for my not good English ;-) I attach also a tar archive with a) a
repo-add patch and b) a download script for using in pacman.conf)

Regards
	Gerhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pacman-sig.tar.gz
Type: application/x-gzip
Size: 1609 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20081202/aa8f66df/attachment.bin>