[ic] [PATCH] [RFC] PGP failure workaround

John Beima interchange-users@icdevgroup.org
Fri Jun 6 22:00:00 2003


Quoting Dan Browning <db@kavod.com>:

> [A word was removed from the subject line to appease the spam filters]
> 
> * John Beima <support@affordable-web-pages.com> [2003-06-06 14:33]:
> > Quoting Dan Browning <db@kavod.com>:
> > 
> > > * John Beima <support@affordable-web-pages.com> [2003-06-04 14:44]:
> > > > Quoting Dan Browning <db@kavod.com>:
> > > > 
> > > > > I have been experiencing the "PGP hard failure" error:
> > > > > 
> > > > > 	PGP failed with error level 12, status 12:
> > > > > 	PGP hard failure, command that failed: [...]
> > > > > 
> > > > > The symptom is that on a busy system, the encryption operation will
> 
> > > > > occasionally (1 in 100 or so) fail, resulting in no credit card at
> all.
> > > > > 
> > > > > Has anyone else experienced this error?  If not, could you try the
> > > steps
> > > > > to reproduce the problem (below)?  If you have, could you try the
> > > > > patch below and let me know if it helps?
> > > > > 
> > > > >  * Software: 
> > > > >    - Interchange 4.9 CVS, 05/13 and 04/04 both affected.
> > > > >    - Interchange RPC and HIGH mode both affected.
> > > > >    - Red Hat 7.3 and 9.0 both affected
> > > > >    - GPG 1.2.1
> > > 
> > > [...]
> > > 
> > > > Actually Dan, I may just have this one for you...
> > > > 
> > > > I found that the gnugpg that ships with RedHat only allows a key to be
> in
> > > use by
> > > > one gpg client at a time.
> > > > 
> > > > So if you have two orders hitting the server at the same time, the
> second
> > > one's
> > > > gpg will fail because the "key" has a lock on it by the first one.
> > > > 
> > > > Gpg does give an error back when this happens...
> > > 
> > > Thanks a lot for the input, John.  I'm not sure that this is the case
> with 
> > > recent versions, because the only patches that Red Hat applies to gnupg
> (as
> > > 
> > > of 1.2.1-4) aren't related to what we're talking about (one is a security
> 
> > > fix, the other is a makefile path correction).
> > > 
> > > Perhaps you could try the "steps to reproduce" and see if you can
> reproduce
> > > 
> > > the problem.
> > 
> > Hello Dan,
> > 
> > I never mentioned anything about patches from RedHat.
> > 
> > What I said was:
> > 
> > I found that the gnugpg that ships with RedHat only allows a key to be in
> use by
> > one gpg client at a time.
> 
> As I'm sure you know, Red Hat simply takes the regular, distributed version
> 
> of any software product, applies a few patches (2, in this case), then 
> re-distributes it.
> 
> You said that the "gnupg that ships with RedHat" has a problem that some 
> other version doesn't.  So that is why I mentioned the two changes that Red
> 
> Hat makes to the software.  Perhaps there are other changes that Red Hat 
> makes to gnupg, that aren't part of the gnupg SRPM package?
> 
> Besides the patches that Red Hat 9 applies to gnupg, I checked out the patch
> 
> to the most recent version of gnupg, and none of them seem to be related to
> 
> file locking or performance.  So... what version are you referring to?
> 
> > I have no idea why gngpg would "lock" a key when it is encrypting. It
> even
> > creates a lock file for it, in the .gnugpg folder where the key is
> stored.
> 
> Two others have mentioned this.  Unfortunately, I did not notice any 
> improvement after trying the following:
> 
>  --lock-multiple
>  --lock-never
> 
> But thank you for the commentary.


Hey Dan,


What I ment by the version that ships with RedHat, was I ment the stock RPMS
from RedHat. Be it the original one or the 1.0.7-7 update. I wasn't actually
meaning to emply it had anything to do with patches that RedHat may be applying
to an original gnugpg.

I should of bean clearer. My appologies.

You see we had/have the exact same thing happening. Some times you get a blank
file back from gpg. Which turned out to be because the key was locked from
another process using it.

So it only made sence that, you having a busy site, would possibly see the same
thing, on occasion when you had two orders go through within seconds of each other.

Which also made total sence that if you sent it back for a second or third try,
but then the lock would be gone, and it could then gain access to the keys and
do the encryption.

Just made sence... Sorry it didn't help you...


John