OK, I've been asked once too often about "automatic" signing of  
packages:

     https://www.redhat.com/archives/rpm-list/2007-September/msg00042.html

Note that Jos Vos has an expect script that "works", and the other  
setsid
solution "works", yet the issue of rpmbuild automatic signing is re- 
asked every 6
months or so. Lord knows the $20K+ FIPS-142(iirc) certified hardware  
solutions
that SuSE and RedHat have chosen are useless for us peons.

So it's time to finish the keyutils implementation to use a persistent
key ring to pass a password to rpm imho. Keyutils is  really easy  
coding, and
a modest abstraction will generalize to Mac OS X keyrings, which means  
that the
rpm feature of automatic signing is likely reasonably portable to  
platforms without keyutils.
OTOH, loss of automatic signing on keyring challenged platforms isn't
the end-of-the-world.

The ultimate issue is where should the password come from, not how the  
password
is passed to gpg, or where rpm choses to save the password.

So I'd like to hear some ideas (and ptrs to reasonable current  
implementations)
regarding how a password should be saved persistently.

There are two classes of solutions to the well known problem of  
automatic passwords:

1) Never save a password anywhere for any reason.
      If that is the desired implementation, then I will finish the  
keyutils
      implementation by delivering a shell script with "fill-in-your- 
passwiord-here"
      slot.

2) Put password somehere and attempt restricting access to that  
location.
      If up to me, I'd likely steal what tripwire has been doing  
forever because
      tripwire has been widely deployed in UNIX. IIRC, the protection  
scheme is
      password in a file with 0600 root:root permissions. I'm sure  
that better
      can be some with SELinux policy these days.

Any other opinions or ideas? I'd like to hear ptrs to existing "known  
good"
implementations, not brain storming on Newer! Better! Bestest! ways of
caching a private password. The issues are very well known, and have  
almost
nothing to do with rpm, except that I would like a professional and  
maintainable
implementation.

73 de Jeff

On Aug 28, 2007, at 10:40 AM, Jeff Johnson wrote:

> I finally got back to figuring keyutils last week.
>
> HEAD now uses keyutils to get the cached gpg (and eventually pgp/pgp5)
> signing password out of rpm's process address space. The  
> implementation
> calls getpass(3) as always, but rather than passing back the value  
> of the password,
> the password is added to the keyutils process keyring, and the name  
> of the key
> is passed back instead. The two places where the password is needed  
> then
> use the name of the password key to retrieve the value. The name (for
> lack of better imagination atm) is "rpm:passwd".
>
> Password values are trashed-and-burned using memset immediately  
> after use.
> Which means that if rpm segfaults, there is no password to be found  
> in the core file
> except in the vanishingly small window where the password is  
> actually being used.
>
> Further development will use the keyutils keyring(s) to cache all,  
> not just the last
> used, gpg public keys, including automagically imported pubkeys from  
> servers.
> The likely name (for lack of better imagination) will likely be  
> "rpm:gpg:pubkey:0x12345678".
>
> Another usage case for keyutils will be to instantiate a pubkey/ 
> certificate after dialogue
>    OK to import pubkey/certificate/whatever (y/N)?
> using the co-routine mechanism in /etc/requestkey.conf.
>
> I'm also interested in using the Mac OS X keyring in ways similar to  
> how keyutils
> is going to be used. Does anyone have a ptr to a reasonable  
> implementation
> in some non-interpreted language?
>
> Are there any other keyring implementations in uglix  that should be  
> considered?
>
> As soon as I can see the playing field of possibly necessary  
> implementations, I
> will attempt an abstraction in rpmio/rpmkey.c
>
> 73 de Jeff
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org