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

John Beima interchange-users@icdevgroup.org
Fri Jun 6 17:10:01 2003


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.

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.

This situation is very easy to re-create. You simply start to encrypt a large
file, around 50-60 megs or so... Then in a second window at the exact same time
try to encryt another file using the same keys.

You will find it errors out and the second one gives you a blank file back.

We have this happen off and on with backup scripts that log onto our clients
machines, do database dumps, then bring them back and encrypt them before storage.

This is why ou are seeing it on a busy box. If a second order goes through and
hits the gpg state while a prior order is being encrypted you will see this.

Your first order will succeed, but the second one will come back blank from gpg
because there was a lock on the key from the first one being processed.

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.


John


> -- 
> Dan Browning, Kavod Technologies, <db@kavod.com> 360.843.4074x217
> 6700 NE 162nd Ave, Ste 611-210, Vancouver, WA.    Random Fortune:
> Volley Theory:
> 	It is better to have lobbed and lost than never to have lobbed at all.
> _______________________________________________
> interchange-users mailing list
> interchange-users@icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>