FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 03-26-2011, 02:40 AM
Ray Kohler
 
Default 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.
 
Old 03-26-2011, 02:52 AM
Ray Kohler
 
Default pacman-key imports and key trust levels

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.
 
Old 03-26-2011, 03:08 AM
Allan McRae
 
Default pacman-key imports and key trust levels

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
 
Old 03-26-2011, 03:21 AM
Dave Reisner
 
Default pacman-key imports and key trust levels

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
 
Old 03-26-2011, 06:30 PM
Denis A. Altoé Falqueto
 
Default pacman-key imports and key trust levels

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

Thread Tools




All times are GMT. The time now is 01:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org