On Mon, 5 Feb 2018 16:41, jlight...@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.
pgpk0_UJzTUX9.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users