Ok this is a stupid questions

[Michael Holly]

Hello

As a follow up to my previous post,  let me emphasize the size expansion is not related to the compression that is applied during encryption.  My issue is that I have files that are being transferred to me, and for a cause that I am trying to track down, gpg begins to decrypt before the file has fully arrived.  From my perspective it appears to send gpg into a tailspin.  The process seems to be able to continue for a week or more and does not seem to complete.

>From a design perspective, I expect the usual replies of "if that is not what you want to do then don't do it".   Yes I know. What I am looking to do is to be able to understand why it goes into this race condition instead of erroring out.
My ask of the gpg listers, is has anyone ever seen this behavior?


From: Michael Holly
Sent: Monday, February 25, 2019 8:14 AM
To: gnupg-users at gnupg.org
Subject: Ok this is a stupid questions

So I completely preface this question is not a valid use case for gpg.  I know, I get it.

I have a potential issue that I'm trying to diagnose.  I'm trying to understand how gpg will react to the input file size changing during the encrypt or decrypt step.

Right now it appears that the gpg process goes a bit crazy and the 200 MB file I am decrypting becomes 1.2 TB or greater.

Here is the order of the events


1.       File lands on my system.

2.       PGP decrypt is invoked on the file.

3.       Since the file is not truly done being sent to me, the file grows in size.

4.       GPG seems to expand the decrypted file many times over.

What I suspect is that instead of erroring out, GPG starts the decrypt process over and appends the new output to the previous cycle..   I have not tested this, but will soon.

I just wanted to see if anyone else has seen this happen.

Thanks

Michael






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190226/3720ae7b/attachment-0001.html>