Re: CipherInputStream may not be closed
Am 08.09.23 um 17:32 schrieb axh:
Hi Anna-Katharina,
what version are you using? In the current 3.0, the stream is closed
(implicitly) by using the try-with-resources syntax
(https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html):
try (CipherInputStream cis = new CipherInputStream(data, cipher))
{
…
}
According to Git Blame, try-with-resources has been used at that point since
2017, so there should be no problem. Disclaimer: I am not a maintainer, I just
sometimes contribute code.
In PDFBox 2.0.x the stream is closed in a finally block.
I guess we are fine here.
Andreas
Axel
Am 08.09.2023 um 14:08 schrieb Anna-Katharina Wickert
:
Hei dear maintainers,
For a benchmark [1], we randomly sampled JCA usages to decide if the API usage
is a violation of any API usage constraint.
We believe we found one for the JCA class CipherInputStream.
The call to *close* is missing for the call sequence to *CipherInputStream*.
Thus, the input stream including the ressources of the stream are not released.
[More Details in the JDK 17
documentation](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/crypto/CipherInputStream.html)
The instance that we sampled is located in:
- file:
pdfbox/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java
- method: private void encryptDataAES256(InputStream data, OutputStream output,
boolean decrypt) throws IOException
- line: 379
To the best of my knowledge, this JCA usage does not result in a vulnerability
(directly). However, it violates the API constraint discussed above. Therefore,
we consider adding this usage as a violation into the benchmark.
Best,
Anna-Katharina Wickert
For the CamBench team
[1] https://github.com/CROSSINGTUD/CamBench
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: CipherInputStream may not be closed
Hei Axel,
Thanks a lot for pointing this out! We both weren’t (anymore?) aware of this
syntax!
We will adapt the respective file!
Best,
Anna
> On 8. Sep 2023, at 17:32, axh wrote:
>
> Hi Anna-Katharina,
>
> what version are you using? In the current 3.0, the stream is closed
> (implicitly) by using the try-with-resources syntax
> (https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html):
>
> try (CipherInputStream cis = new CipherInputStream(data, cipher))
> {
>…
> }
> According to Git Blame, try-with-resources has been used at that point since
> 2017, so there should be no problem. Disclaimer: I am not a maintainer, I
> just sometimes contribute code.
>
> Axel
>
>
>> Am 08.09.2023 um 14:08 schrieb Anna-Katharina Wickert
>> :
>>
>> Hei dear maintainers,
>>
>> For a benchmark [1], we randomly sampled JCA usages to decide if the API
>> usage is a violation of any API usage constraint.
>> We believe we found one for the JCA class CipherInputStream.
>> The call to *close* is missing for the call sequence to *CipherInputStream*.
>> Thus, the input stream including the ressources of the stream are not
>> released. [More Details in the JDK 17
>> documentation](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/crypto/CipherInputStream.html)
>> The instance that we sampled is located in:
>> - file:
>> pdfbox/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java
>> - method: private void encryptDataAES256(InputStream data, OutputStream
>> output, boolean decrypt) throws IOException
>> - line: 379
>>
>> To the best of my knowledge, this JCA usage does not result in a
>> vulnerability (directly). However, it violates the API constraint discussed
>> above. Therefore, we consider adding this usage as a violation into the
>> benchmark.
>>
>> Best,
>> Anna-Katharina Wickert
>> For the CamBench team
>>
>> [1] https://github.com/CROSSINGTUD/CamBench
>
signature.asc
Description: Message signed with OpenPGP
Re: CipherInputStream may not be closed
Hi Anna-Katharina,
what version are you using? In the current 3.0, the stream is closed
(implicitly) by using the try-with-resources syntax
(https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html):
try (CipherInputStream cis = new CipherInputStream(data, cipher))
{
…
}
According to Git Blame, try-with-resources has been used at that point since
2017, so there should be no problem. Disclaimer: I am not a maintainer, I just
sometimes contribute code.
Axel
> Am 08.09.2023 um 14:08 schrieb Anna-Katharina Wickert
> :
>
> Hei dear maintainers,
>
> For a benchmark [1], we randomly sampled JCA usages to decide if the API
> usage is a violation of any API usage constraint.
> We believe we found one for the JCA class CipherInputStream.
> The call to *close* is missing for the call sequence to *CipherInputStream*.
> Thus, the input stream including the ressources of the stream are not
> released. [More Details in the JDK 17
> documentation](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/crypto/CipherInputStream.html)
> The instance that we sampled is located in:
> - file:
> pdfbox/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java
> - method: private void encryptDataAES256(InputStream data, OutputStream
> output, boolean decrypt) throws IOException
> - line: 379
>
> To the best of my knowledge, this JCA usage does not result in a
> vulnerability (directly). However, it violates the API constraint discussed
> above. Therefore, we consider adding this usage as a violation into the
> benchmark.
>
> Best,
> Anna-Katharina Wickert
> For the CamBench team
>
> [1] https://github.com/CROSSINGTUD/CamBench
