Intermittent data corruption in gpg 1.2.0 (and 2 bugs)

judy m. down
Wed Dec 18 11:25:01 2002

Werner Koch <> writes:

> On Tue, 17 Dec 2002 08:11:07 +0000, judy m down said:
> It is too long ago that I hacked on afio, but there might be a problem
> with the double compression.  gpg already compresses; you might want

Hey, thanks for the reply.

There is no double compression.  afio just calls gpg ("compression" in
afio-speak means "filtering").  The only compression happening is inside

> Of course there is still a bug somewhere:

Were there any gpg bugs in the output I posted?  I can't get afio to
produce the error unless it calls gpg.  e.g. never any error if I simply
substitute bzip2 for gpg in the call to afio.

> what happens if the compressedn data gets largers than the input -
> this is very likely when trying to compress encrypted data.

Great idea, but that file compresses well (inside gpg per normal, and there
is no compression otherwise, as I mentioned above).

But that reminded me of something very similar.  According to the man page,
afio by default discards the encryption and uses it only to get the
resulting size if the temporary results are > 2M or virtual memory is
exceeded.  Then it encrypts the same file again.  The behavior cannot be
completely disabled.  I tried it with -M 1000m (i.e. allocating a gigabyte
of memory so it doesn't do that for most files) and ... the error did not
occur for that file.  Good call.  Makes the archiving faster too.

But the bug still exists, even if this is the problem.  As soon as virtual
memory is exceeded, or a large file is processed, it will recur,

It seems to be an interaction between gpg (because bzip2 in place of gpg
doesn't cause the bug) and afio (because the partial workaround seems to
work) -- and it is intermittent, so it might be a timing issue.

Hmm, maybe gpg does some kind of timestamping thing and afio calls gpg
again so quickly that the resolution of the timestamp is underflowed?  Are
there any, say, millisecond timestamps in gpg?  Just a possibility.

gpg experts please comment if you can here.  (or if any afio developers are



P.S.  I do have some definitely gpg-only bugs (or user misunderstandings on
my part :-)) to report, in case the above seems too afio-ish:

1.  Is there a way to have gpg always trust and never check the keys via
options on the command line?  I'm encrypting from a key to itself, but it
seems to want the trust db to be updated and for the keys to be checked, no
matter what options I provide.  For these archives, I just want a fast,
simple asymmetric encryption with no keyring housekeeping (trust checks or
signature checks or whatever) at all.  I sort of feel like gpg ignores
--always-trust and similar options.  The debugging output I posted seems to
show that it does checking anyway....  Is this right?

2.  I think maybe --no-tty or the man page needs to be changed, in that
debugging output seems to go to the tty, at least in my version.

judy m. down 

Get your free email address at