[pacman-dev] Patches for review - package signing

[Dan McGee]

On Tue, Jun 29, 2010 at 3:23 PM, Denis A. Altoé Falqueto
<denisfalqueto at gmail.com> wrote:
> Guys,
>
> I'm proud to say that I've managed to reach an initial working
> implementation for the proposal for package and database signing, as
> formalized in the wiki. It works (in my tests, at least). These two
> patches are against the gpg branch from Allan's repository. They are
> not really in quality level to be merged, but I would appreciate any
> help in that direction. There are certainly problems of style, some
> bugs may be hidden, but it is a starting point for discussion over
> some real implementation.

Can you either push this to a repo on gitweb or somewhere we can add
it as a remote to our repository, or send the patches inline using
`git send-email` (preferred) so we can review them?

> The commit descriptions are terse on purpose. I didn't worry about the
> messages, because the patches are really not finished and there would
> be a lot of things to say about the implementation.
>
> If everything builds correctly, a simple way to test it is to do the following:
>
> 1. create a key to sign keys (this is not really needed, but is in
> accordance to the current proposal)
> 2. if you don't have a key for yourself, create one
> 3. sign your key with the key signing key
> 4. export both keys to a file
> 5. as root, use the script pacman-key to import the keys to pacman's
> keyring with:
>  $ sudo pacman-key add file
> 6. use pacman-key to trust the key signing key with:
>  $ sudo pacman-key trust <key id>
>  This will take you into the prompt of gpg2, which tells you about
> the fingerprint of the selected key and waits for you to type "trust"
> and press enter. After that you will need to trust the key ultimately.
> This is needed to make your key trusted too and I (as you) think this
> is not the ideal solution. Further research will be made to see if I'm
> using the wrong parameters in the verification phase. Let's move on
> for now.
> 7. now you need some packages to make a repository from. Your cache is
> a good candidate. You should copy them to a test location, so we can
> sign them as normal users (as the root user don't have access to your
> default keyring).
> 8. sign the packages with:
>  $ for i in *.pkg.tar.*z ; do gpg2 --detach-sign ${i} ; done
> 9. you can test the makepkg signing too, by having a copy of the
> makepkg.conf file and adding sign to the buildenv array.
> 10. if you want, build a new package with the test makepkg script. You
> should see the prompt for the password (if it is not cached from the
> last step) and the end result is the package and signature files. Move
> them to the repository directory.
> 11. create the repository with:
>  $ repo-add -s <repo-name>.db.tar.gz *.pkg.tar.*z
> 12. you can copy the test pacman binary to the repository and su - to
> make it more convenient for the next steps
> 13. create a copy of pacman.conf to add a new repository and enable
> the signature on it with:
> [repo-name]
> Server = file:///directory-of-your-repo
> VerifSig = Always
>  There are three options for VerifSig: Always, Optional and None.
> The pacman.conf file should point to a temporary RootDir, DBPath,
> CacheDir and LogFile, so you'll not mess up your system.
> 14. now is the time: pacman -Sy will download the repository database
> and check if it is signed and if the signature is trusted.
> 15. pacman -S <some package> will "download"  and check the signatures
> in the process of validating the files. The message for a invalid
> signature is not ideal. It is as if the package were corrupted, which
> is not necessarily the case.
>
> Well, that's it for now. Any suggestions, questions and critics are
> very much appreciated and needed.
>
> PS: I'm resending this email, as the first had problems with the size
> of the patch. The patch had some bugs too, which I've corrected now.

Please send them separately and I will let them through- they just get
blocked into a holding pattern due to them being > 40K. It would help
us greatly though to be able to review them here.

-Dan