/usr/bin/pine (with /usr/bin/pinegpg-install) improperly requires non-pass-phrased GPG private key pine-4.43-1.src.rpm This might also be considered a GPG issue but it seems to be part of pine -- Unlike PGP, the GPG signing routine will not prompt, as shipped, for a pass-phrase to unlock the GPG private key for signing (and encrypting) content. ================================================ $ /usr/bin/pinegpg-install Then going to use gpg-sign, we get: $ pine [compose and selected to send with gpg-sign] gpg: Warning: using insecure memory! gpg: no default secret key: secret key not available gpg: [stdin]: clearsign failed: secret key not available Hit return to continue. ------------------------------------------------- that is -- it is expecting a cleartext GPG private key. [the nomenclature is also inconsistent with the more customary 'private key' term, which one would expect] ------------------------------------ I do not have an immediate solution ... A wrapper shell script might be invoked when STARTING pine to query for the passphrase, and save it to a pipe, which the gpg-sign could then query; or a 'ssh-agent' type helper (GPG has one marked experimental) could be invoked. ------------------------------------ The corresponding dialog with PHP private key under passphrase looks like this: No configuration file found. Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses. (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18 International version - not for use in the USA. Does not use RSAREF. Current time: 2001/12/05 07:21 GMT You specified no user ID to select your secret key, so the default user ID and key will be the most recently added key on your secret keyring. You need a pass phrase to unlock your RSA secret key. Key for user ID: herrold 1024-bit key, key ID 7BFB98B9, created 1998/11/25 Enter pass phrase: ... and given a good pass-phrase, it signs, encrypts, or both the data, and off it goes ...
There have been so many numerous security-ish style bug reports against pgp4pine in the last year, none of which seem to have an easy fast solution, that I am seriously considering removing pgp4pine support from pine entirely. Do you know of any other pine plugin for pgp/gpg support that may be a better alternative?
nalin needs to be involved here. It is a structural problem with the way GnuPG handles pass phrases in text mode. There is not a good wrapper solving this and the 'insecure memory' issue, and it probably needs to be addressed there, and then have a proper wrapper written. The Up2date folks will be concerned as well, in that they use considerable mode package verification. It may be that Jeff Johnson and Beecrypt, or the openssl crypto facilities need a wrapper which is well formed, to solve this one. Beecrypt needs to supplant Openssl (license issue) anyway. Shall we take this discussion off Bugzilla or continue it here?
I wont debate that your ideas are not good, as they sound like a possible solution to the problems at hand. I've Cc'd Nalin at your request in case he would like to also comment. PINE does not support crypto directly of course, and they state in their documentation that the do not plan on ever supporting crypto directly. This means that either a send filter must be used similar to what we're using right now, or someone needs to whip up proper crypto support for PINE and patch it in. Due to the horrible license of PINE, the latter is not realistic, even though IMHO it is the better solution. There are numerous pgp4pine bugs open in bugzilla currently, and also IIRC some I have deferred. Since there are so many bugs reported with this incredibly horrible hack, that leaves us with a few solutions. 1) Fix it - which would require a significant amount of engineering resources allocated to it 2) Rewrite a "proper" replacement for it which also solves all of the various problems people have reported. This also requires a serious resource investment. 3) Investigate other pre-existing solutions to drop into pine 4) Drop pgp support from PINE While #1 or #2 would be best for PINE users likely, the resources invested to accomplish this IMHO do not have a big payoff for the distribution as a whole considering the finite number of hours available. I consider #3 and #4 to be much more viable. While PINE is considered an important package, the drop in PGP support is not. If you or someone else are willing to write up support for #1 or #2, then it stands a chance of happening. In lieu of that, I probably will not touch these problems, and instead opt for #3 or #4, since I believe my available man hours are better spent more effectively on other areas of the distribution.
Realistically, we wont be making our own fork of PINE, or working on the pgp4pine code. We rely on upstream maintainers of both packages to implement this stuff in a supportable and secure manner. If they can't or wont do it, then PGP support should be dropped entirely from our PINE packages. Having PGP support that is not really secure, is not really a secure thing to do. Being unable to allocate the resources to the problem to adequately and securely fix it, makes it something that should be dropped. I'm considering doing this for future releases. Closing bug WONTFIX.