https://www.redhat.com/archives/rpm-list/2007-September/msg00042.htmlNote 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 persistentkey 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 ofcaching 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 thenuse 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 dialogueOK 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 implementationin 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, Iwill attempt an abstraction in rpmio/rpmkey.c 73 de Jeff ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List [email protected]
smime.p7s
Description: S/MIME cryptographic signature
