[pacman-dev] pacman-key imports and key trust levels
So, after a couple of days of messing around (and fixing random things here and there), I was able to go end-to-end, verifying a signed repo DB, and then installing a signed package from that repo. Very nice! I ended up testing out the failure case on verifying signatures a bit more than I wanted, though, as I something surprised me: When importing keys with pacman-key, they keys themselves are imported fine, but they are not marked as sufficiently trusted that the signatures are worth anything. I just imported my "real" GPG pubring (which has nothing in it but my own key) with "pacman-key -a ~/.gnupg/pubring.gpg", and used that same key to sign a package and add that package to a signed repo. GPGme returns "unknown key" when asked to verify these sigs, so pacman flunks them as "invalid signature". After editing the trustdb to mark this key as "ultimate" (hey, it's my own key after all), everything worked. So, my question is, where does the fault lie? Did I make some wrong assumption? Should pacman-key set high levels of trust on keys it imports? Should alpm configure GPGme with trust-level=always? While I'm talking about signing stuff - I noticed an open question on what to do with the downloaded DB if sig verification fails. I suggest it be deleted, and the sig be deleted also. These are generally small files, and it feels really wrong to keep a file "live" on my disk which has been declared untrustworthy.
On Fri, Mar 25, 2011 at 11:40 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
While I'm talking about signing stuff - I noticed an open question on what to do with the downloaded DB if sig verification fails. I suggest it be deleted, and the sig be deleted also. These are generally small files, and it feels really wrong to keep a file "live" on my disk which has been declared untrustworthy.
After a little more thought, probably it would be better to treat it like a bad package download, and ask the user if it should be deleted or not. The sig file is deleted before each download attempt anyway, so it can probably just stay there.
On Fri, Mar 25, 2011 at 11:52:28PM -0400, Ray Kohler wrote:
On Fri, Mar 25, 2011 at 11:40 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
While I'm talking about signing stuff - I noticed an open question on what to do with the downloaded DB if sig verification fails. I suggest it be deleted, and the sig be deleted also. These are generally small files, and it feels really wrong to keep a file "live" on my disk which has been declared untrustworthy.
After a little more thought, probably it would be better to treat it like a bad package download, and ask the user if it should be deleted or not. The sig file is deleted before each download attempt anyway, so it can probably just stay there.
I've got some patchwork on my working branch that addresses this. The code in lib/sync.c that downloads the signature is moved to lib/dload.c and the same function downloads both the file follow by the associated sig. The current behavior is: * file download fails: delete the file * file download is aborted (SIGINT): keep the file * sig download is aborted: keep the file, delete the sig * sig download fails: delete the file _and_ the sig This is fairly paranoid behavior, but its in the best interest of the user. We need to make sure that the file and the sig both come from the same source. Of course, to that end, I'm not sure we can support resuming transfers at all. If a file download succeeds (or is aborted) and/or the sig is aborted, we can't guarantee that the next time that sync is requested, that we're pulling from the same mirror. Do we go extra-paranoid and not even give the user the option to save the untrusted (maybe partial) file? dave
On Sat, Mar 26, 2011 at 1:21 AM, Dave Reisner <d@falconindy.com> wrote:
On Fri, Mar 25, 2011 at 11:52:28PM -0400, Ray Kohler wrote:
On Fri, Mar 25, 2011 at 11:40 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
While I'm talking about signing stuff - I noticed an open question on what to do with the downloaded DB if sig verification fails. I suggest it be deleted, and the sig be deleted also. These are generally small files, and it feels really wrong to keep a file "live" on my disk which has been declared untrustworthy.
After a little more thought, probably it would be better to treat it like a bad package download, and ask the user if it should be deleted or not. The sig file is deleted before each download attempt anyway, so it can probably just stay there.
I've got some patchwork on my working branch that addresses this. The code in lib/sync.c that downloads the signature is moved to lib/dload.c and the same function downloads both the file follow by the associated sig.
The current behavior is: * file download fails: delete the file * file download is aborted (SIGINT): keep the file * sig download is aborted: keep the file, delete the sig * sig download fails: delete the file _and_ the sig
This is fairly paranoid behavior, but its in the best interest of the user. We need to make sure that the file and the sig both come from the same source. Of course, to that end, I'm not sure we can support resuming transfers at all. If a file download succeeds (or is aborted) and/or the sig is aborted, we can't guarantee that the next time that sync is requested, that we're pulling from the same mirror. Do we go extra-paranoid and not even give the user the option to save the untrusted (maybe partial) file?
Very cool! I would suggest the use of db->pgp_verify option. It can be one of PM_PGP_VERIFY_ALWAYS, PM_PGP_VERIFY_OPTIONAL or PM_PGP_VERIFY_NEVER. So, if that option is always, a failure would mean that the user doesn't accept failures. Optional would mean that a failure should prompt the user to decide what to do. The option Never means that pacman doesn't need to check anything related to signature. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On 26/03/11 13:40, Ray Kohler wrote:
So, after a couple of days of messing around (and fixing random things here and there), I was able to go end-to-end, verifying a signed repo DB, and then installing a signed package from that repo. Very nice!
I ended up testing out the failure case on verifying signatures a bit more than I wanted, though, as I something surprised me: When importing keys with pacman-key, they keys themselves are imported fine, but they are not marked as sufficiently trusted that the signatures are worth anything.
I just imported my "real" GPG pubring (which has nothing in it but my own key) with "pacman-key -a ~/.gnupg/pubring.gpg", and used that same key to sign a package and add that package to a signed repo. GPGme returns "unknown key" when asked to verify these sigs, so pacman flunks them as "invalid signature". After editing the trustdb to mark this key as "ultimate" (hey, it's my own key after all), everything worked.
So, my question is, where does the fault lie? Did I make some wrong assumption? Should pacman-key set high levels of trust on keys it imports? Should alpm configure GPGme with trust-level=always?
I posted on the gpgme list trying to clarify what was needed for a signature to be validated. Essentially one key with ultimate trust is needed in a gpg keyring. So, the options are: 1) the user creates their own key in the pacman keyring and uses that to sign keys for the repos they want to add 2) the users imports the master key for any repo they use with ultimate trust I personally prefer option #1, but it really makes no difference given the keyring is probably only used for pacman. For Arch, I guess we will have one (or more) master keys that will sign all the developer keys. The user will have to manually import the master key and then install a pacman-keyring package (signed by that key) which contains all the developers keys. Allan
participants (4)
-
Allan McRae
-
Dave Reisner
-
Denis A. Altoé Falqueto
-
Ray Kohler