[pacman-dev] Patches for review - package signing
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. 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. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Tue, Jun 29, 2010 at 3:23 PM, Denis A. Altoé Falqueto <denisfalqueto@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
On Tue, Jun 29, 2010 at 6:53 PM, Dan McGee <dpmcgee@gmail.com> wrote:
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?
I've created a temporary project on gitorious named pacman-signature-extensions (I suck at naming things, I know...). Thanks for the heads up. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Tue, Jun 29, 2010 at 9:57 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Jun 29, 2010 at 6:53 PM, Dan McGee <dpmcgee@gmail.com> wrote:
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?
I've created a temporary project on gitorious named pacman-signature-extensions (I suck at naming things, I know...). Thanks for the heads up.
Forgot the link for the repository: http://gitorious.org/pacman-signature-extensions/pacman-signature-extensions -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
participants (2)
-
Dan McGee
-
Denis A. Altoé Falqueto