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-20-2011, 10:06 PM
ari edelkind
 
Default Finishing off the package signing issue -- call for contributors

Here are the questions that interest me:

- What's the current state?
-> What works now?
-> What dependencies does the project have?
-> How can i test the current functionality?

- What's the general idea -- the program flow -- of the way it's
currently being implemented? Pseudo-code would be perfect for
answering this, but really, anything with system-level details
will do (the "package signing proposal" is not current and does
not contain system-level details).

- What's currently on the plate? I don't need specifics for
everything -- some areas can be more general and delved into
later, but i do need some specifics so that i can, more or less,
jump right in.
-> Allan mentions some ALPM interfaces on his page.
* How well do they work, currently?
* What's good about them?
* What's bad about them?
* Have new ones been written (committed or not) since that page
was last edited?
* What are some current ideas for more?
-> What more needs to be done before developers can start using it
to sign packages?
-> What needs to be done before courageous users can start using
it to verify packages, manually or automatically? According to
Allan's TODO page, it looks like it's just about ready now, but
the general consensus seems to be that this isn't the case.
-> What are other people currently working on? I don't want to
trod on toes or duplicate work.


Is this sufficient information for anyone else to step up and start
writing patches? Chime in if you need more info.

ari
 
Old 05-20-2011, 11:07 PM
Kerrick Staley
 
Default Finishing off the package signing issue -- call for contributors

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

Allan's git repository (
http://projects.archlinux.org/users/allan/pacman.git/ ; see
http://projects.archlinux.org/) was supposed to have the latest signing
code, but the repository seems to be misconfigured. Allan, can you please
put your repository back up?

The master branch of pacman has some signing code that I've been reading. It
might be up to date; I'm not sure. See
https://wiki.archlinux.org/index.php/Pacman_Development
Basically, just run
git clone git://projects.archlinux.org/pacman.git master
and take a look at master/lib/libalpm/signing.c . This has the actual crypto
implementation. It uses GPGME (
http://www.gnupg.org/related_software/gpgme/index.en.html)*. *Presumably
there is other related code scattered around the repository. I think most of
the functionality should be self-explanatory, but I haven't had time to
thoroughly look into the code.

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.

As far as I can tell, there is no work going on right now on this issue. It
will have to be implemented by myself, you (presumably), and whoever else
decides to pitch in; the main pacman devs don't seem to have enough
interest. Pretty much all the code that's already done should be
self-explanatory, so we shouldn't wait around for Allan, etc. to explain the
workings of their code.

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'm going to get some git going, and then I'll put up some documentation on
the wiki page I mentioned. It'll probably be done in 2 days or so.

-Kerrick Staley

On Fri, May 20, 2011 at 5:06 PM, ari edelkind <
edelkind+arch-pacman@gmail.com> wrote:

> Here are the questions that interest me:
>
> - What's the current state?
> -> What works now?
> -> What dependencies does the project have?
> -> How can i test the current functionality?
>
> - What's the general idea -- the program flow -- of the way it's
> currently being implemented? Pseudo-code would be perfect for
> answering this, but really, anything with system-level details
> will do (the "package signing proposal" is not current and does
> not contain system-level details).
>
> - What's currently on the plate? I don't need specifics for
> everything -- some areas can be more general and delved into
> later, but i do need some specifics so that i can, more or less,
> jump right in.
> -> Allan mentions some ALPM interfaces on his page.
> * How well do they work, currently?
> * What's good about them?
> * What's bad about them?
> * Have new ones been written (committed or not) since that page
> was last edited?
> * What are some current ideas for more?
> -> What more needs to be done before developers can start using it
> to sign packages?
> -> What needs to be done before courageous users can start using
> it to verify packages, manually or automatically? According to
> Allan's TODO page, it looks like it's just about ready now, but
> the general consensus seems to be that this isn't the case.
> -> What are other people currently working on? I don't want to
> trod on toes or duplicate work.
>
>
> Is this sufficient information for anyone else to step up and start
> writing patches? Chime in if you need more info.
>
> ari
>
>
 
Old 05-21-2011, 02:09 AM
Pang Yan Han
 
Default Finishing off the package signing issue -- call for contributors

Hi guys,

I'm interested in this too. I'll just give some of my thoughts which may be
horribly
inaccurate, so I'll apologize for them first.

I think the key issue at hand is not about code. I mean, over these past
months we
have seen the basic infrastructure for package signing being incorporated
into
libalpm. So it's not strictly a lack of code or difficulty issue.

Instead, the key issue is the how this whole package signing thing is going
to be
carried out, ie. something like:
https://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman

And this is something that only the main Arch developers, pacman developers
and
trusted users can solve and have to agree on before development can begin,
since
it has a lot of repercussions.

On Sat, May 21, 2011 at 7:07 AM, Kerrick Staley <mail@kerrickstaley.com>wrote:

> Ari,
> I don't know the answers to most of the questions you have asked; I'm
> trying
> to figure them out myself.
>
> Allan's git repository (
> http://projects.archlinux.org/users/allan/pacman.git/ ; see
> http://projects.archlinux.org/) was supposed to have the latest signing
> code, but the repository seems to be misconfigured. Allan, can you please
> put your repository back up?
>
> The master branch of pacman has some signing code that I've been reading.
> It
> might be up to date; I'm not sure. See
> https://wiki.archlinux.org/index.php/Pacman_Development
> Basically, just run
> git clone git://projects.archlinux.org/pacman.git master
> and take a look at master/lib/libalpm/signing.c . This has the actual
> crypto
> implementation. It uses GPGME (
> http://www.gnupg.org/related_software/gpgme/index.en.html)*. *Presumably
> there is other related code scattered around the repository. I think most
> of
> the functionality should be self-explanatory, but I haven't had time to
> thoroughly look into the code.
>
> 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.
>
> As far as I can tell, there is no work going on right now on this issue. It
> will have to be implemented by myself, you (presumably), and whoever else
> decides to pitch in; the main pacman devs don't seem to have enough
> interest. Pretty much all the code that's already done should be
> self-explanatory, so we shouldn't wait around for Allan, etc. to explain
> the
> workings of their code.
>
> 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'm going to get some git going, and then I'll put up some documentation on
> the wiki page I mentioned. It'll probably be done in 2 days or so.
>
> -Kerrick Staley
>
> On Fri, May 20, 2011 at 5:06 PM, ari edelkind <
> edelkind+arch-pacman@gmail.com> wrote:
>
> > Here are the questions that interest me:
> >
> > - What's the current state?
> > -> What works now?
> > -> What dependencies does the project have?
> > -> How can i test the current functionality?
> >
> > - What's the general idea -- the program flow -- of the way it's
> > currently being implemented? Pseudo-code would be perfect for
> > answering this, but really, anything with system-level details
> > will do (the "package signing proposal" is not current and does
> > not contain system-level details).
> >
> > - What's currently on the plate? I don't need specifics for
> > everything -- some areas can be more general and delved into
> > later, but i do need some specifics so that i can, more or less,
> > jump right in.
> > -> Allan mentions some ALPM interfaces on his page.
> > * How well do they work, currently?
> > * What's good about them?
> > * What's bad about them?
> > * Have new ones been written (committed or not) since that page
> > was last edited?
> > * What are some current ideas for more?
> > -> What more needs to be done before developers can start using it
> > to sign packages?
> > -> What needs to be done before courageous users can start using
> > it to verify packages, manually or automatically? According to
> > Allan's TODO page, it looks like it's just about ready now, but
> > the general consensus seems to be that this isn't the case.
> > -> What are other people currently working on? I don't want to
> > trod on toes or duplicate work.
> >
> >
> > Is this sufficient information for anyone else to step up and start
> > writing patches? Chime in if you need more info.
> >
> > ari
> >
> >
>
>
 
Old 05-21-2011, 05:53 AM
ari edelkind
 
Default Finishing off the package signing issue -- call for contributors

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.

ari
 
Old 05-21-2011, 06:48 AM
ari edelkind
 
Default Finishing off the package signing issue -- call for contributors

On Sat, May 21, 2011 at 00:48, Allan McRae wrote:
...
> *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.

I'd expect that either pacman or a helper program might need to be
involved in some way for a secure implementation (see my last reply to
Kerrick). But even if that's true, it can be addressed later.


> So... onwards to what the current status is:
...
Great info. Thanks!


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

If gpgme has no option to avoid locking when used read-only, this
sounds like a bug in gpgme. That said, here are two potential
workarounds. The first is better, but won't work if symlinks are
rejected. The latter is slightly more cumbersome, but should work.

1. symlink method:
- Create a temporary user keyring directory -- perhaps under $HOME,
or in a temporary directory under /tmp.
- ln -s $KEYRINGDIR/*.gpg $MYTMPDIR/
- Use.
- rm -rf $MYTMPDIR

2. setgid method:
- Create a new gid for pacman, named, say, 'pacman'.
- chgrp pacman $KEYRINGDIR
- chmod 1770 $KEYRINGDIR # or 0770
- chgrp pacman /usr/bin/pacman
- chmod 2711 /usr/bin/pacman

You're probably already aware, but the problem with using mode 1777
for the directory is, any user can place a lockfile there, and then no
other users can access the trustdb. Additionally (and this is
obviously true for method 2 also), no two users can run pacman at the
same time. Thirdly, if pacman is killed before unlocking the keyring,
and the calling user doesn't clean up the lock file manually, then
other users will require root intervention before they can use it
again.


...
Thanks for the rest of the info as well. I hope that what you're in
the hospital for isn't too serious.

ari
 
Old 05-21-2011, 09:33 PM
Kerrick Staley
 
Default Finishing off the package signing issue -- call for contributors

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.

> 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.
Where?

> This is why it needs to be kept completely separate from discussions about
> implementing signature verification work in pacman.
Eh? pacman-dev is the most relevant list I've found for discussion of this
issue. The key-signing mechanism in pacman (in particular, its ease-of-use)
has a direct impact on its adoption, and the two conversations should not be
separated.

With regard to key schemes, the security of your system is the security of
any package you install into it; in particular, if an attacker has a
developer key and controls any part of the connection between you and the
central archlinux.org repository, they can modify the .install of the next
package you happen to update, and do whatever they want to your system,
including altering your GPG install, so there's no point to any sort of
specialized key scheme. There will be a list of developer keys, and anyone
who can log in to the central repository can change that list, so the
responsiblity of key verification will fall on whoever manages the central
repository. Revocation just means deletion from this list, and, as Ari
correctly points out, a complexer revocation scheme is unnecessary [1].

The security of the central repository and of its contents are hairier
issues, and since I don't know how this is implemented, I ask that someone
inform me of how the central repository is managed (and of who has the
ability to perform this management). It's probably already secure, though.

With regard to verifying packages, it should be possible to verify
signatures without root privileges as long as root is not updating pacman's
keyring. This should be possible without any downsides or crude hacks. If it
is necessary to attach an Arch-specific patch to Arch's GPGME package, then
that can be done. Ari, you can do this if you want, and if not, I'll
complete the task. Also, Ari, I would recommend not spending time theorizing
about solutions to small issues such as this: it's better just to code out a
solution (and of course test it) and then submit a patch. Discussion about
how to implement an idea in code is rarely needed: just do it.

For now, let's all just publish our changes to this list so that they can be
integrated into the master branch of pacman's git. If people have a lot of
code that is not polished enough for pacman's master branch, but that they'd
like to share anyway, I'll set up a separate git repository that we can work
out of, publishing finished code as patches when necessary.

If you are interested cryptography and security, I would highly recommend
reading Applied Security by Bruce Schneier (the protocol-related portions
can be understood without reading the sections on mathematical and
algorithmic underpinnings).

Happy hacking and best wishes for Allan's health,
Kerrick Staley

[1] If a the compromise of a key is discovered and you are informed before
updating your system, then a secure channel for key revocation that is
independent of the repositories (best done with revocation certificates)
would be useful, but this is irrelevant for practical and theoretical
reasons. Practically, most people update daily, so there is a very small
window in which the discovery of a compromise will be useful. Also,
compromises should be rare enough that when they do happen, a news item can
be posted on the Arch homepage informing users on how to manually revoke the
keys [2]. Theoretically, there's no way to tell whether a compromise
happened when you think it did or sometime before.

[2] The Arch homepage is insecure (no SSL), so this is a further issue.
However, this is all getting to be too scenario-specific; fine-grained
analysis such as this should be done only after we have a basic
implementation of package signing working.
 
Old 05-22-2011, 07:22 AM
Rémy Oudompheng
 
Default Finishing off the package signing issue -- call for contributors

On 2011/5/21 Kerrick Staley <mail@kerrickstaley.com> wrote:
>> 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.
> Where?
>
>> This is why it needs to be kept completely separate from discussions about
>> implementing signature verification work in pacman.
> Eh? pacman-dev is the most relevant list I've found for discussion of this
> issue. The key-signing mechanism in pacman (in particular, its ease-of-use)
> has a direct impact on its adoption, and the two conversations should not be
> separated.

Hello Kerrick,

There is no such key-signing mechanism in pacman, and there no plan to
have such a thing. Keys are signed using the standard GPG utilities
and are completely up to the packagers and repository admins. Details
about the implementation chosen by Archlinux can be discussed on
arch-general@archlinux.org. You may also find discussions in archives
of arch-dev-public@archlinux.org.

Rémy.
 
Old 05-23-2011, 05:11 PM
Denis A. Altoé Falqueto
 
Default Finishing off the package signing issue -- call for contributors

On Sat, May 21, 2011 at 7:41 PM, Allan McRae <allan@archlinux.org> wrote:
> 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...

It's funny as I was thinking about that same issue for the last days.

Another workaround would be to call directly gpg with the option
--lock-never, so it will not try to lock the keyring before the
operation. What gpgme does is exactly that, but under the hood. Yes,
it is more cumbersome than just using gpgme.

About the lacking of a proper locking, it is not very different of
what is already done with pacman itself. There's a lock for writing
operations (/var/lib/pacman/db.lck) but it is not used for read-only
operations. We just need to be sure to use it only for checking the
signatures.

By the way, maybe I'll not reply for the next days, because I'll be
without internet connection. But I'm interested in helping too.

--
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 02:43 PM.

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