/usr/bin/pine (with /usr/bin/pinegpg-install) improperly requires
non-pass-phrased GPG private key
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)
Then going to use gpg-sign, we get:
[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
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
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: email@example.com
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
Do you know of any other pine plugin for pgp/gpg support that may be a
firstname.lastname@example.org 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
Closing bug WONTFIX.