Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some files cannot be decrypted with error "premature end of stream in PartialInputStream" #46

Closed
jni- opened this issue Apr 1, 2020 · 2 comments

Comments

@jni-
Copy link

jni- commented Apr 1, 2020

Describe the bug
An error occurs when decrypting some files. It seems caused by a stream closed too early (see additional information)

To Reproduce

        encryptedStream.use { cipherTextStream ->
            FileOutputStream(decryptedFile).use { bufferedOut ->
                BouncyGPG
                    .decryptAndVerifyStream()
                    .withConfig(keyRing)
                    .andIgnoreSignatures()
                    .fromEncryptedInputStream(cipherTextStream)
                    .use { plaintextStream ->
                        Streams.pipeAll(plaintextStream, bufferedOut)
                    }
            }
        }

Expected behavior
File gets decrypted

** System (please complete the following information):**

  • Device: Laptop?
  • OS: Linux 5.5.13-arch1-1 Maven central #1 SMP PREEMPT Wed, 25 Mar 2020 16:04:40 +0000 x86_64 GNU/Linux
  • Java
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
  • Version 2.2.0 (new, 2.1.2 works)

Additional context
Stacktrace :

Caused by: java.io.EOFException: premature end of stream in PartialInputStream
	at org.bouncycastle.bcpg.BCPGInputStream$PartialInputStream.read(Unknown Source)
	at org.bouncycastle.bcpg.BCPGInputStream.read(Unknown Source)
	at org.bouncycastle.openpgp.PGPCompressedData$1.fill(Unknown Source)
	at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
	at org.bouncycastle.bcpg.BCPGInputStream.read(Unknown Source)
	at org.bouncycastle.bcpg.BCPGInputStream$PartialInputStream.read(Unknown Source)
	at org.bouncycastle.bcpg.BCPGInputStream.read(Unknown Source)
	at org.bouncycastle.util.io.Streams.pipeAll(Unknown Source)
	at [redacted, my code].decryptIntoOutputStream(BouncyCastleFileDecryptor.kt:47)

I've isolated the breaking commit : 012c3f9 (reverting to 2.1.2 works)

It seems the stream closes too soon, but I have no idea why it works with some files and not with some others.

It works well with a file I encrypted myself. However, it does not work with the file the provider creates. I have no idea why. I also have no idea how they encrypt it to be honest. I cannot share the file for privacy reasons, however if some info on it can help, let me know.

I'm sorry I can't provide more information! Let me know how I can help more

@jni-
Copy link
Author

jni- commented Apr 1, 2020

Oh, I have more info.

I've traced the code using both files. The difference is that my PGPCompressedData contains a PGPOnePassSignatureList next (that works). The buggy file is not signed, it does not contain this packet. Instead, it jumps straight the literal data, which returns the stream itself.

Not sure I understand all of it so far, but it seems that having no signature list packets break it. Not sure how to create a file to isolate this either.

Hope this helps!

@ispringer
Copy link
Contributor

I also encountered this issue. Like @jni-, I experienced it with one particular file, but not with others. The file I saw it for was a fairly small (12K) encrypted and signed CSV file. Both the encrypted file and the signer's public key were created using a very old PGP toolkit (v2 I think), which might be relevant. The files that worked were encrypted and signed by me using BouncyGPG.

#47 fixes the issue by reverting 012c3f9.

neuhalje added a commit that referenced this issue Jul 12, 2020
…to ispringer-issue-46

* 'issue-46' of https://github.com/ispringer/bouncy-gpg:
  fixes #46 by reverting 012c3f9; that commit did not make sense, as we should not close a stream that is going to be wrapped by additional streams, which haven't even been created yet; instead the wrapping streams should be responsible for closing the streams they wrap once they are fully done with them; all tests pass
neuhalje added a commit that referenced this issue Jul 12, 2020
* ispringer-issue-46:
  fixes #46 by reverting 012c3f9; that commit did not make sense, as we should not close a stream that is going to be wrapped by additional streams, which haven't even been created yet; instead the wrapping streams should be responsible for closing the streams they wrap once they are fully done with them; all tests pass
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants