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 05-21-2011, 04:48 AM
Allan McRae
 
Default Finishing off the package signing issue -- call for contributors

Hi,

I'm going to point out what the current state of the package signing
code is and what is currently being worked on. As a warning I have just
got home from a stay in hospital, so I might be ever so slightly terse
in my reply. Don't take this as me being an arse... I just figured that
it was better to reply now as opposed to giving no reply (as I will be
heading back to hospital again soon).



On 21/05/11 09:07, Kerrick Staley wrote:
> As far as I can tell, there is no work going on right now on this issue.

What!!! There has there been no progress... in two weeks!!! That's
right... it has been only two weeks since the last commit to do with
package signing was pushed to the master git repo
(http://projects.archlinux.org/pacman.git/commit/?id=70cf4546). In
fact, it currently 10 days, so it was 9 days when the original emails to
this thread were sent. Shock, horror development has stalled!


If that was not enough, one way to know the current status of
development would be to look through this email lists archives. Hmm..
"trustdb locking issues" would be the last one. Seems a pretty big
issue not being able to verify a package that has a signature file
without root privileges. So that is probably a blocker that the people
working on this have not solved yet. Note there were very, very few
replies with suggestions on how to deal with that.



On 21/05/11 09:07, Kerrick Staley wrote:
> I think each developer should have their own key, that each package will
> only need one signature, and that the repolists will also be signed by
> the last dev to edit them.

Good to see you came up with the exact implementation we already have...
Pacman reads a single signature for a package (either detached for -U
or -Q operations, or in the repo db for -S operation) and the repo has a
single detached signature. How those key are distributed across
developers and what exactly is used in signing what is not a pacman
concern and so has nothing to do with the implementation in pacman.
Pacman just needs to take signatures and verify them. Note that how
Arch will deal with signing in their repos is being finalised elsewhere,
but to reiterate, that has nothing to do with the pacman implementation.



So... onwards to what the current status is:

- makepkg can build a package and sign it (using gpg)
- repo-add can add a package signature to the database and sign the database
- a key management tool call pacman-key is implemented. It still needs
work and there are a bunch of patches on the mailing list for it. I
hope to find time to finalise this in the near future...

- pacman has basic signing support. It can:
- download and verify the signature for the repo dbs
- read package and verify their signatures from repo dbs on -S operations
- read and verify detached signatures on -U operations (and -Q, but
note above the issues with trustdb locking and root privileges)


Things that need done:
- figure out the locking issues (1777 permissions on the pacman gpg
keyring directory is a workaround, but we may take the yum approach of
copying that folder to a writeable location)

...

In fact, just look at the list on my wiki page:
https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . There
is no point me replicating the list here. If you have specific queries
about any point, ask specific questions. Most should be fairly clear if
you actually take the code for a test spin.


As far as what branches to use, all the gpg signing code that I had on a
branch has been merged in to the pacman master branch (as stated on the
above wiki page...). You might find WIP patches on a gpg branch in
Dan's repo depending on what he is doing, or maybe my working branch.



I was going to go into more detail on the status of what is done and
what needs done, but the quickest way for anyone to find out is to grab
the git repo, build it and start using it. Everything for makepkg and
repo-add is documented in the man pages so hopefully that should be
clear. So you should easily be able to create a signed package and add
it to a local repo. If not, ask specific questions and we can improve
the documentation. Then you can play around with pacman to see what
appears to work and what does not. About the only thing that you need
to know is there is a VerifySig option for pacman.conf that takes the
value Always/Optional/Never and is given for each repo.


If people want further info, ask specific questions. I'm not going to
spend my time answering very basic questions about the current
implementation that can be easily seen by anyone who spends a small
amount of time doing some actual investigation by taking the code for a
spin. If you don't have time to do this, then I doubt you have time to
contribute anything...


Cheers,
Allan
 
Old 05-21-2011, 06:14 AM
Allan McRae
 
Default Finishing off the package signing issue -- call for contributors

On 21/05/11 15:53, ari edelkind wrote:

Kerrick Staley wrote:

I don't know the answers to most of the questions you have asked; I'm trying
to figure them out myself.


I didn't mean to lay all of my questions on you -- i was just making a
list of things that i'd like to see answered. I was actually just
trying to make your job easier; sorry if it didn't come off that way.


I'm going to be documenting important features of the code and other things
at https://wiki.archlinux.org/index.php/Package_signing ; please add
anything interesting you find to that page.


Excellent. Thanks for taking this on.


Also, I think the KSK idea, which AFAIK Allan was going to go with, will
make things too complicated (unless it's mostly implemented). Basically, I
think each developer should have their own key, that each package will only
need one signature, and that the repolists will also be signed by the last
dev to edit them. Also, 4 or 5 devs will keep a CD or flash drive with
revocation certs for everybody. This system is vulnerable to the compromise
of a single developer key, and even more vulnerable if one of the
aforementioned disks gets compromised, but it is much better than what we
currently have, and the KSK system is basically just as vulnerable. Once we
get this system off the ground, we can work out a more sophisticated
protocol.


I agree that a KSK implementation is unnecessarily complex. The
concept of a KSK was designed for a different purpose -- for
authorizing arbitrary numbers of certs. Unless i'm misunderstanding
some crucial part of the plan, Arch does not have arbitrary numbers of
package builders to worry about.

The revocation scheme is also unnecessarily complex. For that matter,
revocation on PGP keyservers wasn't designed for this sort of
application, and isn't secure enough for it. If we supply a keyring
of valid signing keys, and can replace this keyring when necessary,
then revocation certificates become irrelevant.

In this scenario:
- The top 3 key holders can still exist (i'll call them the Key Moguls).
- The developer generates a key pair and sends his public key to the
Key Moguls.
- Key Moguls verify the key, and add it to the list of permissible keys.
- The list of permissible keys are either retrieved separately by
pacman or retrieved as a Special Package.
- The list or Special Package (LoSP) is signed with a key from a Key
Mogul (or two).
- If it passes verification, the LoSP becomes (or already is) a
keyring, and _replaces_ the previous keyring.
- The Key Moguls' keys are in a separate keyring. This keyring can
be similarly replaced if necessary.
- If the LoSP has been updated, then users will see a notice, just
like when pacman has been updated, suggesting that they update the
LoSP before continuing. Or, it can be automatically updated, perhaps
with a command-line option for no-auto-update.

The potential security concern that i see with this scenario is if an
attacker compromises both a package signing key (dev key) and a
mirror. In this case, he can keep the new version of the LoSP from
being pushed out, and may continue using the compromised key.

Unfortunately, having the devs sign the repository doesn't help this
situation, since if both a dev key and a mirror are compromised, then
the dev key could be used to sign an altered repository, and once
again, the new LoSP could be omitted. However, if an additional "dev
key" can be used to automatically sign the repository _in addition_ to
the developer himself, then both keys would have to be compromised
simultaneously for an attack to become feasible. I'm not familiar
enough with the Arch package distribution+mirror system to comment on
whether this is a reasonable thing to implement.


If AUR submissions are ever to be signed (this isn't handled by pacman
anyway), _they_ might require a KSK. But AUR submissions are so iffy
to begin with that users should be scrutinizing them before (compiling
or) installing anyway.



All this is off-topic for this list as pacman will not care how packages
and repos are signed. It will just verify whether the package/repo can
be validated using the keychain it is provided.


Allan
 
Old 05-21-2011, 06:29 AM
Allan McRae
 
Default Finishing off the package signing issue -- call for contributors

On 21/05/11 16:14, Allan McRae wrote:

All this is off-topic for this list as pacman will not care how packages
and repos are signed. It will just verify whether the package/repo can
be validated using the keychain it is provided.


Just to clarify, I do see how the keychain is managed by a distribution
as an important issue to be discussed. However, it is also the most
political issue in this package signing business and discussing it on
this list just ends up derailing discussion on actual pacman
development. This is why it needs to be kept completely separate from
discussions about implementing signature verification work in pacman.


Allan
 
Old 05-21-2011, 10:18 PM
Allan McRae
 
Default Finishing off the package signing issue -- call for contributors

On 22/05/11 07:33, Kerrick Staley wrote:

All,


What!!! There has there been no progress... in two weeks!!!
That's right... it has been only two weeks since the last commit
to do with package signing was pushed to the master git repo
(http://projects.archlinux.org/pacman.git/commit/?id=70cf4546).
In fact, it currently 10 days, so it was 9 days when the original
emails to this thread were sent. Shock, horror development has
stalled!

Although work is happening, I think it's fair to say that it's not happening
fast enough to cause problems with duplication. Also, compared to the amount
of effort I would like to see going towards this idea, and the amount of
effort I am willing to personally put into it, the work the main pacman devs
are doing appears to be very little.


OK... I don't speak for Dan, but I will stop working on this as you are
obviously going to code all this quicker than we will so there is little
point us working on it. I look forward to reviewing your patches.


Allan
 
Old 05-21-2011, 10:41 PM
Allan McRae
 
Default Finishing off the package signing issue -- call for contributors

On 22/05/11 07:33, Kerrick Staley wrote:

If it
is necessary to attach an Arch-specific patch to Arch's GPGME package, then
that can be done.


I'll point out that this can not be done due to Arch's patching policy.
Arch does not patch software for features not provided upstream, so
any patch will be required to go to the gpgme and be accepted before it
is even considered for the Arch package.


I would also suspect, that patches for pacman that rely on unreleased
changes to gpgme would not be accepted, so we would then need to wait on
a new gpgme release...


Allan
 

Thread Tools




All times are GMT. The time now is 06:55 PM.

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