Bug 57120 - pinepgpgpg improperly requires non-pass-phrased GPG private key
Summary: pinepgpgpg improperly requires non-pass-phrased GPG private key
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: pine   
(Show other bugs)
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-05 07:24 UTC by R P Herrold
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-25 10:26:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description R P Herrold 2001-12-05 07:24:23 UTC
/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)


$ /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

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@owlriver.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 ...

Comment 1 Mike A. Harris 2002-01-23 16:40:02 UTC
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?

Comment 2 R P Herrold 2002-01-23 21:21:11 UTC
nalin@redhat.com 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?

Comment 3 Mike A. Harris 2002-01-25 10:26:38 UTC
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.

Comment 4 Mike A. Harris 2002-07-30 01:31:25 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.