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

[Allan McRae]

On 01/05/10 14:27, Denis A. Altoé Falqueto wrote:
> 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.
>

Hi,

Thanks for the comments on the package signing process.  It has 
clarified a few things for me and I think we are on the right track with 
the work that has been done so far.  I have made a few comments below.


<snip>
> 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.

<snip>
> 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.

Here the default option would be not to install the package with a 
signature problem so --noconfirm would just result in pacman aborting 
the transaction.


> 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.

> 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?

The internal Arch packaging tools would need some very minor changes to 
upload the signature file but that can be handled at a later date.


> 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.

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

Allan