BC vs. Java(SUN) handling of non-NULL empty input #2257
Unanswered
dmansfie-qti
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello!
I've NOT been keeping current with (Java) BC releases. As we align our code base atop JRE25, we have encountered a change in behavior with BC when compared to default Java (SUN) provider.
The item that is unclear is the handling of a non-NULL empty InputStream. The overall sequence is best represented by the following code-snippet that is using a CertificateFactory to generate one (X509)Certificate using an InputStream as the input resource. The setup here should assume that the
InputStream isobject is a non-NULL but emptyInputStream:With JRE25/SUN
CertificateFactory, a non-NULL emptyInputStreamwill first throw anIOException(empty input resource) and then aCertificateException(unable to be parse input - reason? empty input stream). Thus, there is an exception vs. a return from the above method.With BC 1.81 (and 1.83) these same conditions now return a NULL certificate. In other words, it appears that on the BC side, a non-NULL but empty
InputStreamno longer creates an exception and instead, now returns a NULL entity (in this case, an X509Certificate).I'm writing this generally as I suspect the underlying behavior is a more uniform handling by all BC classes that utilize a common I/O library to handle the lower-level details (i.e., CertificateFactory, KeyFactory, etc.) when an InputStream is presented as an input source.
Is the divergence of this behavior (BC will NOT throw an exception for non-NULL but empty input resource) expected, and if so, is it documented?
Tks!!
--- Dave
Beta Was this translation helpful? Give feedback.
All reactions