RFR: 8297065: DerOutputStream operations should not throw IOExceptions [v2]

Valerie Peng valeriep at openjdk.org
Tue Nov 29 05:03:08 UTC 2022


On Sun, 27 Nov 2022 16:25:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 300:
>> 
>>> 298:          * @exception CRLException on encoding errors.
>>> 299:          */
>>> 300:         public byte[] encodeInfo() throws CRLException {
>> 
>> "throws CRLException" can be removed?
>
> Inside the method there is
> 
> if ((version == 0) && (issuer.toString() == null))
>                 throw new CRLException("Null Issuer DN not allowed in v1 CRL");

I see.

>> src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 601:
>> 
>>> 599:      */
>>> 600:     public static X509CRLImpl newSigned(TBSCertList info, PrivateKey key, String algorithm, String provider)
>>> 601:             throws CRLException, NoSuchAlgorithmException, InvalidKeyException,
>> 
>> Does this method still has calls which throw CRLException?
>
> Because it calls `TBSCertList::encodeInfo`.

Ok.

>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 467:
>> 
>>> 465:      */
>>> 466:     public static X509CertImpl newSigned(X509CertInfo info, PrivateKey key, String algorithm, String provider)
>>> 467:             throws CertificateException, NoSuchAlgorithmException,
>> 
>> The javadoc above states that CertificateException is thrown on encoding errors. Will there still be encoding errors? The updated code seems not.
>
> Inside `X509CertInfo::emit`, there is
> 
>         if ((version.compare(CertificateVersion.V1) == 0) &&
>             (issuer.toString() == null))
>             throw new CertificateParsingException(
>                       "Null issuer DN not allowed in v1 certificate");
> 
> and more places where the exception might be thrown.

Ok.

>> src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java line 77:
>> 
>>> 75:     }
>>> 76: 
>>> 77:     final byte[] encode() throws GSSException {
>> 
>> Probably no need for GSSException?
>
> This is because `Oid::getDER` still throws it, and I don't want to modify a public API.

Ok.

-------------

PR: https://git.openjdk.org/jdk/pull/11302



More information about the security-dev mailing list