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

Denis A. Altoé Falqueto denisfalqueto at gmail.com
Wed May 5 19:33:47 CEST 2010

On Wed, May 5, 2010 at 3:51 AM, Allan McRae <allan at archlinux.org> wrote:
>> 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.
> The first method is what is currently used on the gpg patches that are
> available.  The signature is made in a separate file and then is inserted in
> the repo db when the package is added.

Yes, that's what I thought too. But maybe some day we could use a
package layout that would leave a place for embedded signatures, as
.deb and .rpm do. Surely, a mid to long term concern.

>> 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.
> I believe makepkg is good to go with the patches currently available.

I was thinking about makepkg having an option to select the key used
to sign the package, with the default behavior being the main key of
the user will be used.

>> 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.
> repo-add is also mostly good to go (there are some TODOs left, e.g. aborting
> when the signature verification of the repo fails before adding the
> package).
> There needs to be discussion about signing the repo database itself and how
> that is handled.  Does the last person to add a package sign the lot?  That
> might be reasonable given the package signatures have been verified in some
> sort of chain to the initial signing.  But it does mean that developers are
> signing the entire db when they are only responsible for a small part.  I
> guess that would also require private keys be available on the server
> creating the repo dbs....   That needs thought.  How do other distros handle
> that?

Yes, this is a little troublesome right now. I don't know the workflow
of the package upload and repo.db creation, but I presume that
there'is a script to do it, right? Does repo-add run locally or
remotely? I believe that it is run remotely. In that case, is there
any synchronization scheme? Because we can have race conditions if two
developers are calling it at the same time.

I was thinking about generating the sha1 hash of the repo.db on the
server and to sign locally just the hash, so the exchange of data
between the server and the local machine is minimized. A digital
signature is basically just that anyway. We could have a script to
help the process, together with synchronization of the repo.db, to
avoid race conditions. But that depends on the workflow of the
uploading process. Could you explain it to me?

> Could the trust database be updated via pacman using post_install on some
> pacman-keychain package?

Yes, I've already adapted apt-key to do some useful tasks for us (I
named it pacman-key -- the originality prize goes to....). I think the
model of apt is very interesting. Basically, they have the main
keyring in /etc and the official package keeps the current keys in
/usr/share/apt/. There's a file for keys to be added and another for
keys to be deleted, so when a new keyring package is downloaded, the
keys marked to deletion are removed from the main keyring and the new
keys are added, if needed. Unfortunately, gpgme can't do some kinds of
operations on keyrings, so we need a shell script for that.

Aleksis already cloned your gpg branch and created a project on
gitorious. I think is easier to make the changes there, test and play
with ideans and just after that merge them to your repository. I'm
also thinking in putting this proposal in the Arch Wiki, so we can
keep up with the changes. And there are lots of details to append to
the document.

Thanks for the comments.

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

Denis A. Altoe Falqueto

More information about the pacman-dev mailing list