Introduction
This post title is such a troll… Archlinux is my favorite Linux-based distribution, it’s already secured, blah blah blah, you got the point. Here’s the story. Questions come next.
Signing? How awesome is that!?
Security is one of my big concerns. So I started to work on packages signing, which might be the biggest lack in Archlinux for now. Thanks to toofishes, who is totally mentoring me on this, we went to a point where a nearly complete design is available. The implementation is far from finished, but it’s now possible to see where we’re going, if we keep this way. And I think it perfectly suits the Arch philosophy.
The place to start with
We started working on makepkg. Basically, we added an option in the BUILDENV array (defined in /etc/makepkg.conf) named sign, which causes makepkg to sign the package it builds using gpg, creating a binary 72 bytes detached signature file.
That’s one small step for add-repo…
Then, we need the signature to be available on the repos. Using a 72 bytes file for each package would be overkill considering the number of mirrors. So we wanted to include the signature in the repo database (this .db.tar.gz file you might have opened if you understand a few words in this post). A whole file path in the tarball for every signature would be overkill too, plus it is uncompressed in /var/lib/pacman/sync/ and each signature could take something like 8kb (depending on your fs and its options, btw) as a separate file! But for each package, there’s a desc file with fields in it. Our idea is to put the signature in it. As it is plain text, we can’t put the binary signature directly. base64 is here! With a tool to (de)code it in coreutils, it definitely was the way to go. Now we have a new field which looks like:
%GPGSIG%
iEYEABECAAYFAkhDcqcACgkQj8OreK3cj9eStwCeIjf9AWQcPE9hH+t7iQ2pVCychxwAoKBcIiYph4RzVISP6bklppdOwmkF
It’s a long line, but it is still plain ASCII and won’t interfere with the file format as there can’t be any % in it. So we tweaked repo-add. That was a one line patch in the code. Did I tell you it’s a true story?
What’s the point?
Now that everything is here to generate repos with signed packages, maybe pacman could use this brand new information…
It could embed muuuch code from GnuPG. OK, what else? It could use gpgme, which would rely on gnupg itself, but is supposed to make things easier. Here, we just have to check a signature. We can work like git! Basically, we just need to popen something like gpg --keyring $keyringfile --no-default-keyring --verify - $pkgfilename and write the binary key to it. Then check for return code 0.
That’s where the biggest design choice come. How pacman should know whether a package can be trusted or not? Let’s use (a) keyring(s)!
I’ll let the gnupg users who learnt their lesson tell you that to trust Archlinux’s packages, you need to meet Aaron Griffin himself (omg omg! RMS would be so jealous!), or someone who met him, or someone who met someone who met him, etc. as long as it seems at least a lot more than reasonable to you. And please do the same for [archlinuxfr], [eee], etc. Web of trust is a good concept.
Irrelevant throughts: Now let’s suppose you install Archlinux via FTP: you launch your installer from the USB key you’ll give to Grand’ma at her birthday next week, and you have configure gpg before installing packages. Well, I don’t know for you, but when I install a system, I want this done fast. Meaning at least a prompt to start tweaking within minutes. Dealing with a keyring like you would do for e-mails or chat sessions with your buddies at the NSA is not really adapted. Anyway, you will be able to work that way with our system!
We could have a keyring per repository in pacman.conf. I think it doesn’t make much sense: if I trust a developer to provide me binaries it seems I want to use, I don’t really care whether it’s init or vim (but I care whether it’s not emacs or still not). And I care even less if it’s in [core] or [community], because I love TUs. Did I tell you TUs are beautiful and smart young men and women who need care and love?
Now that you’re convinced pacman’s keyring should be system-wide, it would be convenient to deal with the various packagers of the repos you use. Here’s a hypothetical story:
I wake up at 10AM. I take my breakfast, a shower, and go to school. My girlfriend (yes, hypothetical) kisses my math teacher… Let’s be realistic. A year later, I install Archlinux on my brand new laptop. In [core], I keep archlinux-keyring. I add the [archlinuxfr] repository to /etc/pacman.conf, pacman -S archlinuxfr-keyring. I confirm the installation even if this package is not signed. I change Keyring /etc/pacman.d/archlinux.gpg to Keyring /etc/pacman.d/belovedlaptop.gpg, and run gpg-merge-keyrings archlinux.gpg archlinuxfr.gpg belovedlaptop.gpg. Then I add the [kdemod] repository, install its keyring and run gpg-add-keyring kdemod.gpg belovedlaptop.gpg.
Questions as promised
Why don’t the thousands of people who visit this blog put at least a dozen of comments on it? Do you think I should stop replying to my replies to my patches on pacman[dash]dev[at]archlinux[dot]org? Is packages signatures something you actually want? Do we do it completely wrong or just wrong?
Vous aussi, bénéficiez d’un accès à Internet partout en France pour pas cher ! Bien sûr, l’« illimité » de mon titre est à prendre au sens opérateur : pas d’interruption stricte du service en cas de dépassement d’un quota. Par contre, Orange vous interdit la voix sur IP, le partage de documents de pair à pair, se réserve le droit de brider (encore plus) la connexion si vous l’utilisez trop, y tutti quanti. Il faudra que je vérifie personnellement pour ce contrat précis, mais le contraire m’étonnerait.
