[12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject
Please review the code change at webrev: http://cr.openjdk.java.net/~weijun/8193859/webrev.00/ where JBS: https://bugs.openjdk.java.net/browse/JDK-8193859 CSR: https://bugs.openjdk.java.net/browse/JDK-8193887 Thanks Max
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
On 06/08/2018 20:11, joe darcy wrote: Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the security-libs area with a handful in RMI and JNDI: http://cr.openjdk.java.net/~darcy/8209024.0/ Patch below. I'll fix-up the copyright years before any push. Is there a follow-on patch coming to deprecate these fields? -Alan
Re: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported
> On Aug 7, 2018, at 2:50 AM, Sean Mullan wrote: > > On 8/6/18 11:14 AM, Weijun Wang wrote: >> That would be a real behavior change and I want to be safe. > > I'm not seeing how this would be a behavior change if it is a new option, can > you add more details on that? If I specify -providerName, intuitively I would > expect it would be used, at least as the first one. Before this change when "keytool -importcert" is called, KeyStore.getInstance() uses "-providername" but CertificateFactory.getInstance() *does not*. Now CertificateFactory.getInstance() is using it. If it's preferred than the default provider, then it's a behavior change. > >> -providername is now used by "keytool -importcert" to choose keystore >> implementations. I am not sure if someone already using -providername for >> this purpose might encounter any unexpected change. > > How does that relate to -printcert? Not related. In this case, it's a new option. Thanks Max > > --Sean > >> We can rethink about this decision if there is a real world problem. Maybe a >> single -providername is inadequate for complicated scenarios. >> Thanks >> Max >>> On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: >>> >>> Maybe, the specified provider should be honored firstly? >>> >>> Xuelei >>> >>> On 8/6/2018 1:53 AM, Weijun Wang wrote: Ping again. Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. Thanks Max > On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ > > Please note I didn't use srcProviderName as suggested in the bug report. > It was designed to be used by the "keytool -importkeystore" command only. > > Thanks > Max >
Re: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22
Hi Xuelei, I’ve attached a java file with a method that can be used as a test case. The caller will need to provide SSLEngines. I assume that is something you can do? As I said this is with TLS 1.2. I catch the exceptions I mentioned in my last email. Although there are comments that I do not think that these exceptions make sense. Additionally, the failing assertions are currently wrapped in if(false) {} so that the method will complete. Let me know if you have any questions. - Tim JDKSSLEngineTest.java Description: Binary data > On Aug 3, 2018, at 6:47 PM, Xuelei Fan wrote: > > Hi Tim, > > Your concerns make sense to me. Did you have a test case that I can use to > reproduce the issues? > > Thanks, > Xuelei > > On 8/3/2018 5:04 PM, Tim Brooks wrote: >> Hi Xuelei >> I pulled the JDK 11 source today and applied your patch. And then I built >> the jdk to run some tests. I hope that is the correct approach. >> It appears that this change resolved some of my prior issues. But I notice >> some other issues. This is tested with TLS 1.2. I have not really setup my >> environment yet for TLS 1.3, so I was not able to test that code path. I >> have -Djavax.net.debug=all enabled. However, I have pruned some of messages >> from this email to reduce text. If you need more let me know. >> Client: >> 1. ClientHello.java:633|Produced ClientHello handshake message >> 2. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 204 >> Server: >> 3. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 204 >> 4. ClientHello.java:788|Consuming ClientHello handshake message >> 5. ClientHello.java:818|Negotiated protocol version: TLSv1.2 >> 6. ServerHello.java:361|Produced ServerHello handshake message >> 7. CertificateMessage.java:263|Produced server Certificate handshake message >> 8. ServerHelloDone.java:97|Produced ServerHelloDone handshake message >> 9. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 1086 >> Client: >> 10. SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 1086 >> 11. ServerHello.java:862|Consuming ServerHello handshake message >> 12. ServerHello.java:958|Negotiated protocol version: TLSv1.2 >> 13. CertificateMessage.java:358|Consuming server Certificate handshake >> message >> 14. ServerHelloDone.java:142|Consuming ServerHelloDone handshake message >> 15. RSAClientKeyExchange.java:195|Produced RSA ClientKeyExchange handshake >> message >> 16. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 17. ChangeCipherSpec.java:109|Produced ChangeCipherSpec message >> 18. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 262 >> 19. SSLEngineOutputRecord.java:465|WRITE: TLS12 change_cipher_spec, length = >> 1 >> 20. SSLEngineOutputRecord.java:465|WRITE: TLS12 handshake, length = 16 >> At this point I do not send that data yet to the server. The client has >> produced the client key exchange and client finished messages. But they are >> still in transit (in this scenario). >> Server (we manually call closeOutboud() because we have decided we need to >> close this socket): >> 21. SSLEngineImpl.java:745|Closing outbound of SSLEngine >> 22. SSLEngineOutputRecord.java:465|WRITE: TLS12 alert, length = 2 >> 23. SSLEngineOutputRecord.java:465|Raw write (: 15 03 03 00 02 01 5A >> ..Z) >> - I believe this is user_canceled alert >> 24. SSLEngineOutputRecord.java:465|Raw write (: 15 03 03 00 02 01 00 >> ...) >> - I believe this is close_notify >> At this point: >> Server engine.isOutboundDone() = true >> Server engine.isInboundDone() = false >> Client: >> 24. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >> 25. Alert.java:232|Received alert message ("Alert": {"level" : "warning", >> "description": "user_canceled"}) >> 26. SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 2 >> 27. Alert.java:232|Received alert message ("Alert": {"level": "warning", >> "description": "close_notify"}) >> 28. Fatal (UNEXPECTED_MESSAGE): Received close_notify during handshake ( >> "throwable" : { >> javax.net.ssl.SSLProtocolException: Received close_notify during handshake >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:307) >> at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) >> At this point I want to note that it feels weird that this produces an >> exception. The other side said "user_canceled" and then sent "close_notify". >> That seems correct to me? So it feels weird that consumers of the SSlEngine >> have to handle this exception and then continue using the engine for a >> proper close. That's just a side note. I (think) this behavior is not new. >> But it seems odd. >> At this point: >> Client en
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
Hi Sergey, On 8/6/2018 3:39 PM, Sergey Bylokhov wrote: Hi, Joe. On 06/08/2018 14:30, joe darcy wrote: Even if currently less commonly used, I think "ineffectual" better captures the intention of what I want to convey in the comment than "ineffective." Can you please clarify this: what does it mean "ineffectual" in this context? why we need to "suppress" them and why these fields cannot be dropped? A serialVersionUID field is intended to be used to provide the serial hash of a class both to avoid the cost of its computation at runtime and to provide cross-version serial stability in the face of innocuous changes to the class. The serialVersionUID of an interface type is *not* used in the serialization machinery. The names of interfaces are used however. Therefore, a serialVersionUID field on an interface does not have the effect one would assume it has, namely altering the behavior of serialization. In that sense, these field declarations in interfaces are ineffectual. I'm working on expanding the checks done by "javac -Xlint:serial", including flagging these and other ineffectual serialization coding patterns. I've pushed a number of related cleanup fixes earlier in JDK 12 (JDK-8208060, JDK-8207751, JDK-8208782, etc.). Much of the JDK code base is compiled using "-Xlint:all -Werror", meaning that if the set of checks is expanded and new warnings are generated, the build will fail. While it would be possible to exclude the expanded serial check from the build, I'd prefer to address the serial issues instead. Since the files modified by JDK-8209024 are pre-JDK 9 interfaces, their static serialVersionUID fields are *public* fields, meaning they are part of the interfaces' contract. Therefore, the fieldscannot just be removed per our usual compatibility policy, unlike, say a private field in a class. For that reason, I think it is reasonable to suppress the (future) serial warnings for these fields, rather than to remove the fields. I wouldn't oppose the effort if someone else wanted to deprecated these fields for removal and then remove the fields in a future release, but I don't think the cost/benefit of that particular route is justified. HTH, -Joe
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
Hi, Joe. On 06/08/2018 14:30, joe darcy wrote: Even if currently less commonly used, I think "ineffectual" better captures the intention of what I want to convey in the comment than "ineffective." Can you please clarify this: what does it mean "ineffectual" in this context? why we need to "suppress" them and why these fields cannot be dropped? -- Best regards, Sergey.
Re: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized
Ok, I included Max's description for the special PBE parameter handling. Should be enough details... Filed: https://bugs.openjdk.java.net/browse/JDK-8209038 Thanks, Valerie On 8/6/2018 7:16 AM, Sean Mullan wrote: On 8/3/18 8:19 PM, Valerie Peng wrote: I can file a follow-on issue. However, I want to clarify what we want to do before filing it. Based on current exchanges: We want to update Cipher.getParameters()/CipherSpi.engineGetParameters() with similar format/wording as Signature.getParameters(), e.g. expanding the meaning when null is returned. Yes. In addition, we also need to change the part of "same parameters" due to this special PBE parameter handling behavior. Right? I think so, but can you add a bit more details on the "special PBE parameter handling behavior"? --Sean Thanks, Valerie On 7/31/2018 12:56 PM, Sean Mullan wrote: On 7/24/18 9:38 PM, Weijun Wang wrote: Something related. Cipher has a similar init(..,params) and getParameters() structure and the spec is also similar. * The returned parameters may be the same that were used to initialize * this cipher, or may contain a combination of default and random * parameter values used by the underlying cipher implementation if this * cipher requires algorithm parameters but was not initialized with any. However, one can supply an incomplete parameters object in init() and getParameters() will fill in default/random values to make it complete. For example, in PBE-based Cipher, one can only include salt and iteration count in the init params, and init() will add in a random IV, and the IV can be retrieved with getParameters(). Is this something we need to clarify? Yes, we should update the Cipher API to be consistent with Signature. I think this can wait until JDK 12 though. Valerie, can you file a follow-on issue? Thanks, Sean
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
+1 > On Aug 6, 2018, at 3:11 PM, joe darcy wrote: > > Hello, > > Various interfaces in the JDK extend Serializable and declare > serialVersionUID fields. Such fields are ineffectual and > @SuppressWarnings("serial") should be applied to such fields to suppress > future planned serial lint checks (JDK-8202056). > > Most of the affected files are in the security-libs area with a handful in > RMI and JNDI: > > http://cr.openjdk.java.net/~darcy/8209024.0/ > > Patch below. I'll fix-up the copyright years before any push. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 > 12:04:46.666000999 -0700 > +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 > 12:04:46.51999 -0700 > @@ -109,6 +109,7 @@ > * serialization compatibility with a previous > * version of the class. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = 6603384152749567654L; > > /** > --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 > 12:04:47.062000999 -0700 > +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 > 12:04:46.914000999 -0700 > @@ -64,5 +64,6 @@ > * The class fingerprint that is set to indicate serialization > * compatibility with a previous version of the class. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = 6034044314589513430L; > } > --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 > 12:04:47.454000999 -0700 > +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 > 12:04:47.306000999 -0700 > @@ -50,5 +50,6 @@ > * The class fingerprint that is set to indicate serialization > * compatibility with a previous version of the class. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = 7187392471159151072L; > } > --- > old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java > 2018-08-06 12:04:47.858000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java > 2018-08-06 12:04:47.706000999 -0700 > @@ -48,6 +48,7 @@ > * serialization compatibility with a previous > * version of the class. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = 7776497482533790279L; > > /** > --- > old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java > 2018-08-06 12:04:48.27999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java > 2018-08-06 12:04:48.114000999 -0700 > @@ -48,6 +48,7 @@ > * serialization compatibility with a previous > * version of the class. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = 1234526332779022332L; > > /** > --- > old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java > 2018-08-06 12:04:48.674000999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java > 2018-08-06 12:04:48.522000999 -0700 > @@ -43,6 +43,7 @@ > * The class fingerprint that is set to indicate > * serialization compatibility. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = -7896394956925609184L; > > /** > --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java > 2018-08-06 12:04:49.078000999 -0700 > +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java > 2018-08-06 12:04:48.926000999 -0700 > @@ -45,6 +45,7 @@ > * The class fingerprint that is set to indicate > * serialization compatibility. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = -3314988629879632826L; > > /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java > 2018-08-06 12:04:49.47999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java > 2018-08-06 12:04:49.318000999 -0700 > @@ -51,6 +51,7 @@ > * serialization compatibility with a previous > * version of the type. > */ > +@SuppressWarnings("serial") // serialVersionUID in an interface is > ineffectual > static final long serialVersionUID = 618058533534628008L; > > /** > --- > old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java > 2018-08-06 12:04:49.89999 -0700 > +++ > new/src/java.base/share/classes/java/security/interfaces
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
Hi Roger, Even if currently less commonly used, I think "ineffectual" better captures the intention of what I want to convey in the comment than "ineffective." Thanks all for the reviews; cheers, -Joe On 8/6/2018 12:44 PM, Roger Riggs wrote: Hi Joe, Looks fine. I would probably have used "ineffective" instead of "ineffectual". (Googling "define ineffective" and "define ineffectual" shows an interesting graph of the use of the term with ineffective growing and ineffectual dropping in use. Look under the more tag) Regards, Roger On 8/6/2018 3:11 PM, joe darcy wrote: Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the security-libs area with a handful in RMI and JNDI: http://cr.openjdk.java.net/~darcy/8209024.0/ Patch below. I'll fix-up the copyright years before any push. Thanks, -Joe --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700 +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.51999 -0700 @@ -109,6 +109,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6603384152749567654L; /** --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700 +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700 @@ -64,5 +64,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6034044314589513430L; } --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700 +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700 @@ -50,5 +50,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7187392471159151072L; } --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7776497482533790279L; /** --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.27999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 1234526332779022332L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700 @@ -43,6 +43,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -7896394956925609184L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700 @@ -45,6 +45,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -3314988629879632826L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.47999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700 @@ -51,6 +51,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersio
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
Looks fine to me. --Sean On 8/6/18 3:11 PM, joe darcy wrote: Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the security-libs area with a handful in RMI and JNDI: http://cr.openjdk.java.net/~darcy/8209024.0/ Patch below. I'll fix-up the copyright years before any push. Thanks, -Joe --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700 +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.51999 -0700 @@ -109,6 +109,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6603384152749567654L; /** --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700 +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700 @@ -64,5 +64,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6034044314589513430L; } --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700 +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700 @@ -50,5 +50,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7187392471159151072L; } --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7776497482533790279L; /** --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.27999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 1234526332779022332L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700 @@ -43,6 +43,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -7896394956925609184L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700 @@ -45,6 +45,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -3314988629879632826L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.47999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700 @@ -51,6 +51,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 618058533534628008L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.89999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.726000999 -0700 @@ -46,6 +46,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
Hi Joe, Looks fine. I would probably have used "ineffective" instead of "ineffectual". (Googling "define ineffective" and "define ineffectual" shows an interesting graph of the use of the term with ineffective growing and ineffectual dropping in use. Look under the more tag) Regards, Roger On 8/6/2018 3:11 PM, joe darcy wrote: Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the security-libs area with a handful in RMI and JNDI: http://cr.openjdk.java.net/~darcy/8209024.0/ Patch below. I'll fix-up the copyright years before any push. Thanks, -Joe --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700 +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.51999 -0700 @@ -109,6 +109,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6603384152749567654L; /** --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700 +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700 @@ -64,5 +64,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6034044314589513430L; } --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700 +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700 @@ -50,5 +50,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7187392471159151072L; } --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7776497482533790279L; /** --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.27999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 1234526332779022332L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700 @@ -43,6 +43,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -7896394956925609184L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700 @@ -45,6 +45,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -3314988629879632826L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.47999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700 @@ -51,6 +51,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 618058533534628008L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.89999 -0700 +++ new/src/java.b
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
Hi Joe, Looks fine. Brian On Aug 6, 2018, at 12:11 PM, joe darcy wrote: > Various interfaces in the JDK extend Serializable and declare > serialVersionUID fields. Such fields are ineffectual and > @SuppressWarnings("serial") should be applied to such fields to suppress > future planned serial lint checks (JDK-8202056). > > Most of the affected files are in the security-libs area with a handful in > RMI and JNDI: > > http://cr.openjdk.java.net/~darcy/8209024.0/ > > Patch below. I'll fix-up the copyright years before any push.
[11] RFR: 8208691: Tighten up jdk.includeInExceptions security property
After further evaluation of the new jdk.includeInExceptions security property originally introduced in JDK-8204233 [1] and further generalized in JDK-8207846 [2], I felt that a stronger warning should be added to the description of the property alerting the user to the potential risks of setting the property. I also added a test to ensure that the property was not accidentally turned on by default (mainly to catch accidental pushes where the property was left on as part of testing, etc). webrev: http://cr.openjdk.java.net/~mullan/webrevs/8208691/webrev.00/ --Sean [1] https://bugs.openjdk.java.net/browse/JDK-8204233 [2] https://bugs.openjdk.java.net/browse/JDK-8207846
JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the security-libs area with a handful in RMI and JNDI: http://cr.openjdk.java.net/~darcy/8209024.0/ Patch below. I'll fix-up the copyright years before any push. Thanks, -Joe --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700 +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.51999 -0700 @@ -109,6 +109,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6603384152749567654L; /** --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700 +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700 @@ -64,5 +64,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6034044314589513430L; } --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700 +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700 @@ -50,5 +50,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7187392471159151072L; } --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7776497482533790279L; /** --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.27999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 1234526332779022332L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700 @@ -43,6 +43,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -7896394956925609184L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700 @@ -45,6 +45,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -3314988629879632826L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.47999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700 @@ -51,6 +51,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 618058533534628008L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.89999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.726000999 -0700 @@ -46,6 +46,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -5
Re: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported
On 8/6/18 11:14 AM, Weijun Wang wrote: That would be a real behavior change and I want to be safe. I'm not seeing how this would be a behavior change if it is a new option, can you add more details on that? If I specify -providerName, intuitively I would expect it would be used, at least as the first one. -providername is now used by "keytool -importcert" to choose keystore implementations. I am not sure if someone already using -providername for this purpose might encounter any unexpected change. How does that relate to -printcert? --Sean We can rethink about this decision if there is a real world problem. Maybe a single -providername is inadequate for complicated scenarios. Thanks Max On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: Maybe, the specified provider should be honored firstly? Xuelei On 8/6/2018 1:53 AM, Weijun Wang wrote: Ping again. Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. Thanks Max On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. Thanks Max
Re: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported
OK. No more comment from me. Thanks, Xuelei On 8/6/2018 8:14 AM, Weijun Wang wrote: That would be a real behavior change and I want to be safe. -providername is now used by "keytool -importcert" to choose keystore implementations. I am not sure if someone already using -providername for this purpose might encounter any unexpected change. We can rethink about this decision if there is a real world problem. Maybe a single -providername is inadequate for complicated scenarios. Thanks Max On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: Maybe, the specified provider should be honored firstly? Xuelei On 8/6/2018 1:53 AM, Weijun Wang wrote: Ping again. Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. Thanks Max On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. Thanks Max
Re: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported
That would be a real behavior change and I want to be safe. -providername is now used by "keytool -importcert" to choose keystore implementations. I am not sure if someone already using -providername for this purpose might encounter any unexpected change. We can rethink about this decision if there is a real world problem. Maybe a single -providername is inadequate for complicated scenarios. Thanks Max > On Aug 6, 2018, at 10:38 PM, Xuelei Fan wrote: > > Maybe, the specified provider should be honored firstly? > > Xuelei > > On 8/6/2018 1:53 AM, Weijun Wang wrote: >> Ping again. >> Also please take a review at the CSR at >> https://bugs.openjdk.java.net/browse/JDK-8208689. >> Thanks >> Max >>> On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ >>> >>> Please note I didn't use srcProviderName as suggested in the bug report. It >>> was designed to be used by the "keytool -importkeystore" command only. >>> >>> Thanks >>> Max >>>
Re: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported
Maybe, the specified provider should be honored firstly? Xuelei On 8/6/2018 1:53 AM, Weijun Wang wrote: Ping again. Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. Thanks Max On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ Please note I didn't use srcProviderName as suggested in the bug report. It was designed to be used by the "keytool -importkeystore" command only. Thanks Max
Re: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized
On 8/3/18 8:19 PM, Valerie Peng wrote: I can file a follow-on issue. However, I want to clarify what we want to do before filing it. Based on current exchanges: We want to update Cipher.getParameters()/CipherSpi.engineGetParameters() with similar format/wording as Signature.getParameters(), e.g. expanding the meaning when null is returned. Yes. In addition, we also need to change the part of "same parameters" due to this special PBE parameter handling behavior. Right? I think so, but can you add a bit more details on the "special PBE parameter handling behavior"? --Sean Thanks, Valerie On 7/31/2018 12:56 PM, Sean Mullan wrote: On 7/24/18 9:38 PM, Weijun Wang wrote: Something related. Cipher has a similar init(..,params) and getParameters() structure and the spec is also similar. * The returned parameters may be the same that were used to initialize * this cipher, or may contain a combination of default and random * parameter values used by the underlying cipher implementation if this * cipher requires algorithm parameters but was not initialized with any. However, one can supply an incomplete parameters object in init() and getParameters() will fill in default/random values to make it complete. For example, in PBE-based Cipher, one can only include salt and iteration count in the init params, and init() will add in a random IV, and the IV can be retrieved with getParameters(). Is this something we need to clarify? Yes, we should update the Cipher API to be consistent with Signature. I think this can wait until JDK 12 though. Valerie, can you file a follow-on issue? Thanks, Sean
Re: RFR 8201290: keytool importcert fails with CertificateParsingException if unknown certificate algorithms should be imported
Ping again. Also please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8208689. Thanks Max > On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8201290/webrev.00/ > > Please note I didn't use srcProviderName as suggested in the bug report. It > was designed to be used by the "keytool -importkeystore" command only. > > Thanks > Max >