gpg: do_plaintext(): wrote 1210414045 bytes but expected 822504068 bytes

[Werner Koch]

On Mon,  5 Feb 2018 16:41, JLightner at dsservices.com said:
> Basic questions:
> 1) Is the above message in fact an "error"?

Yes.  It may either indicate an internal error in gpg or a wrong usage
(see next).

> 2) What exactly does it mean?

When starting the encryption and if possible gpg records the lengths of
the input file.  During encryption the actually read and written bytes
are counted and compared to the size recorded at the start of the
encryption.

This is only done if the input is a regular file and its size is less
than about 4 GiB (due to the OpenPGP specs).

Are you sure that no other process is writing to the file whilst gpg is
encrypting it?  Recall that a file may already be unlinked but a process
may still write to the inode.

> 3) Why does it appear to be backwards? (i.e. Why is the first number it says it "wrote" larger than what it says it "expected"?

See above.

> 4) How can I detect when this occurs as an "error" to prevent the
> encryption so re-encryption can be re-attempted?

Pipe the data to gog and you won't get that error messages.  However, it
might be slower that working directly on a file.  That depends on a lot
of factors.

> "--exit-on-status-write-error

> That seemed to explain why it didn't actually cause our script to
> error out. On adding the above flag to my encryption it created a

You don't use the --status-fd option and thus this option does not make
a difference.  Diagnostics like the one you see won't necessary
terminate the operation immediate but set a flag to finally return a
failure exit code.

> 1) The original file size we encrypt is always extremely large so it
> is not the size that caused this issue.  As noted I re-ran the
> encryption manually severa

Weel, it is less than 4 GiB.  You should not see that diagnostic for a
file of 4 GiB or larger.  If my guess on the error is right, you won't
catch the incorrect use of gpg in this case.

> 3) The command line we used to do the encryption without the new flag was:
> /usr/bin/gpg --always-trust --armor --recipient <RECIPIENT> -o <BASEFILENAME.dat.asc> --encrypt <BASEFILENAME.dat.txfr>
> Where <BASEFILENAME.dat.asc> is the encrypted file and <BASEFILENAME.dat.txfr> is the original unencrypted file.

I have two suggestions independent of the problem

 - Use the option "--batch" to make sure that gpg will never ask the
   user. 

 - If you know that the file is already compressed you should use the
   option "-z 0" to disable gpg's internal compression.  Without that
   option gpg will guess whether to compress or not.

> 5) I can't decrypt the file created because the recipient uses the bank's public key so only the bank can decrypt it with their private key.

If you need you can encrypt to a second key by adding

  --recipient MYOWNKEY

> 7) gpg --version outputs:
> gpg (GnuPG) 2.0.14

That is pretty old (from 2009) and I hope that Redhat patched it to fix
a few security problems.  The current version is 2.0.31 but the 2.0
branch reach edn-of-life a month ago.  A quick look at the code didn't
reveal any bug fix which could be relevant to you problem, though.

> do_plaintext issue I'm seeing.  RedHat backports bug and security
> fixes into their version so it is not exactly the same as the upstream

I know that.  Thanks for answering possible questions in advance.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180206/0466b638/attachment-0001.sig>