[pacman-dev] [arch-general] Package signing

[Denis A. Altoé Falqueto]

On Thu, Apr 29, 2010 at 7:44 AM, Aleksis Jauntēvs
<aleksis.jauntevs at gmail.com> wrote:
> On Thursday 29 April 2010 00:37:34 Linas wrote:
>> I wrote about this topic ~1 month ago.
>> You don't need PKCis or distribute the keyrings themselves. GPG supports
>> transitive trust.
>> The pacman keyring would be installed by default trusting on whatever keys
>> a pacman root signature has signed (there could also be a different master
>> key for community developers).
>
> This idea is certainly worth a try.

Hi, guys.

I've been studying apt to see how they manage this situation and here
are my conclusions until now, together with a draft of a solution for
Arch. I would like to thank Linas for the heads up about the web of
trust of GnuPG. It is a central part of the solution proposed and is
used by Debian and Fedora (possibly for other RPM based distros).

I didn't think about the signing of the repo.db. Suggestions are
welcome, as always. This email is very long and a ask you to read it
all, because I think it is a feasible solution.

-------
A simple introduction to the Web of Trust concept

A web of trust is the concept used by OpenPGP (and GnuPG) for the
management of trust policies in its public key system. As there's no
concept of a central authoritative entity, there's the need of some
kind of verification of the public keys that we accept in our keyring.
Keys can be signed by other users, indicating that they trust in the
veracity of the key. But the verification can become cumbersome, as
the number of keys exchanged increases. To solve this, the comcept of
Web of Trust was introduced. If I trust enough in a friend, I can sign
his key in my keyring and tell to gpg that I also trust in the keys
that he signs. So, if I verify a file that was signed by a person that
my friend trusts, gpg will accept the signature as valid. When I
import the third person's public key, gpg will mark it as a valid key.

In GnuPG, there'are four levels of trus in a public key:

 - unknown: I didn't said anything about this key yet
 - none: i don't trust this public key to sign other keys (this just
affects the signature keys, not the signatures of files)
 - marginal: I have a little trust in this public key to sign other keys
 - fully: I trust completely in this public key, as if it was my own

So, GnuPG can be configured to accept a key as valid if it has 3
marginaly trusted key signatures or 1 fully trusted key signature
(this is the default). Or it can be any other combination.

The following is my suggestion for the use of GnuPG to sign and manage
the pacman's keyring, toghether with the creation of a web of trust
for the Arch Developers. It is very similar to what Debian and Fedora
do, although there'are some differences, because of our way of doing
things.

1. Pacman's keyring

Pacman will have a separated keyring, so the root's keyring will not
be affected by keys that are intended for use with package signing.
This is already implemented in Allan's pacman git branch for gpg
support. The directory will be /etc/pacman.d/gnupg/. There will be the
public key database, the trust database and a fake private key
database, because GnuPG doesn't work very well without one (according
to Debian's apt-key script).

The keyring will be populated based on the keys from the
pacman-keyring package. In this package, there will be a file for the
valid keys and one for the removed keys, so that the post-install
script can revoke keys that may not be trusted anymore (be it for
security reasons or because some developer has left the project).

2. Arch Key Signing keys

There will be 3 keys for the sole purpose of signing other developers'
keys (hereafter named KSK, Key Signing Keys). They will be created by
3 developers that will be responsible for the role of signing the
other developer's keys (and theirs own too). This procedure is very
important and must be done with the certainty that the keys being
signed are from the person they plead to be. The confirmation of the
fingerprints must be done via a secure channel (skype, phone call,
secure email or personally). For example, Debian only trust in keys
confirmed personaly (by what i could find). We can be a little lenient
because the group of developers is reduced.

The owners of the KSK must keep them secured and must choose a strong
passphrase, so that even in the event of the secret keys being stolen,
the risk of a real misuse will be little. In such case, there will be
some time for the generation of a new set of KSK and the re-signing of
the others developers' keys.

With the KSK and the signed developers' keys, the pacman-keyring
package will be created and signed with one of the KSK.

3. Package signing by developers

When a developer builds a new package, makepkg will have the options
to sign the package too, with the developer's own key (not the KSK, if
the developer owns one). At this point, there are three options (that
we should choose now) for the format of the signed/signature pair:

 - detached signature external to the package: the package will stay
unchanged and there'll be a new file for the signature.
 - detached signature internal to the package: makepkg would generate
a detached signature, but would tar the package and the signature into
a new file, so that both are always toghether (Debian and RPM based
distros do that way). This would have a bigger impact on all developer
tools and pacman itself.
 - attached signature: the signature would contain the signed file,
and pgp would be used to extract the signed file. Just like the one
above, this would require lots of changes on the tools.

The cheaper approach is obviously the first option. It will not
require lots of changes, but there'll be some. Maybe the convenience
of the latter two would compensaate for the trouble of changing the
tools? Comments very much appreciated.

3. Instalatino of KSK by the users

This is a very sensitive part and must be done with caution, at the
risk of driving all the work moot. The KSK should be manually verified
by the user before pacman can accept the pacman-keyring package. I
believe that the following would be feasible:

 - the KSK and the corresponding fingerprints would be available in
severall channels of Arch: Home page, git repository, forums, etc.
 - the user downloads the KSK and import them (with a new option of pacman)
 - pacman shows the fingerprint of each KSK and asks for the approval
of the user
 - if the user confirms, pacman imports the keys to its keyring,
setting them as fully trusted

After this, the pacman-keyring can be installed and the public keys of
the developers can be added by the post-install script. the trusdb
will be updated.

4. Package verification

When pacman downloads a package, the signature will be downloaded
together. Pacman will inform the user if the package's signature is
not valid and stop. At this point, the user can delete the package
from the cache to force a new download or he can use an option to
ignore the signature problem for a specified package. Maybe the option
--no-confirm should be ignored in this case, to avoid creating a way
to install a package whose signature is invalid without the user
actively accepting. Or we should only accept that for packages without
signature (the ones with an invalid signature should be never
installed). Comments very welcome.

5. Affected tools

5.1 Makepkg

There should be options to choose the key to sign a package. The key
will be always from the keyring of the user building the package.

5.2 devtools

I don't know them, so I can't comment. But the upload and repo.db
generation will be affected, for sure.

5.3 pacman

Pacman could have options to handle the management of the keyring:

 - approval of KSK
 - importation/exportation of new keys
 - alteration of level of trust of keys
 - removal of keys
 - update of trusdb

6. Final comments

I believe that this suggestions are feasible and will bring a new
level of quality to Arch Linux. The gpg branch of pacman git
repository of Allan is in a good position in relation of what I
suggested above. One possible problem is that gpgme is not able to
update a trusdb (or at least i couldn't fine how). Maybe we'll have to
use some script for that.
-----

Comments and criticism are very appreciated.

-- 
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------