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

[Weijun Wang]

On Sun, 27 Nov 2022 07:57:35 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   one more
>
> 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");

> 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`.

> 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.

> 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. Of course it shouldn't (I've added a comment on it). I'll see if I can catch it inside this method and ignore it.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 99:
> 
>> 97:     }
>> 98: 
>> 99:     private void makeEncoding(byte[] s) throws InvalidKeyException {
> 
> No need for the InvalidKeyException?

`ECParameters::getAlgorithmParameters` throws it.

> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 113:
> 
>> 111:     }
>> 112: 
>> 113:     private void makeEncoding(BigInteger s) throws InvalidKeyException {
> 
> No need for the InvalidKeyException?

Same as above.

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

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