[pacman-dev] Finishing off the package signing issue -- call for contributors

ari edelkind edelkind+arch-pacman at gmail.com
Sat May 21 02:48:24 EDT 2011


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


More information about the pacman-dev mailing list