From bradford.wetmore at oracle.com Thu Dec 1 01:38:00 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 30 Nov 2016 17:38:00 -0800 Subject: RFR: 8169335: Add a crypto.policy fallback in case Security Property 'crypto.policy' does not exist In-Reply-To: <6baf8cb3-89a8-f512-121e-1eafd40f88bf@oracle.com> References: <47dffc15-3190-e65c-4257-07c76516e399@oracle.com> <61C119ED-E738-4EB6-A107-19765802C757@oracle.com> <582C6B80.4030408@oracle.com> <4f303108-514f-b049-4e5e-38a435c020e0@oracle.com> <1517C1CB-52D8-49A9-918B-C1F8C78D402C@oracle.com> <71690c51-a5e1-26b5-7474-f1e576c170f2@oracle.com> <6baf8cb3-89a8-f512-121e-1eafd40f88bf@oracle.com> Message-ID: <02493251-5f31-887a-ebbd-f769616375cc@oracle.com> I've updated to: * @run main/othervm CryptoPolicyFallback I'll have a new review out shortly. Brad On 11/23/2016 2:29 AM, Wang Weijun wrote: > Hi Brad > > I think I found a problem with the test. Before you set your local > java.security file, the system java.security file was already read (in > jtreg initialization) and limited was picked up. In fact, I modified the > java.security file of my own JDK to unlimited and the test fails. > > This seems to show that we have to set the system property on the > command line. Either we provide a modified java.security with the test > like SeanM suggested, or we create it dynamically and manually launch a > new java process. I prefer the latter. > > Thanks > Max > > On 11/18/2016 1:46 AM, Bradford Wetmore wrote: >> SeanM pointed out that we could do a: >> >> @main -Djava.security.properties=xxx >> >> but that would require storing a snapshot of java.security. I think I >> prefer it being dynamically generated. From tiantian.du at oracle.com Thu Dec 1 06:29:59 2016 From: tiantian.du at oracle.com (Tim Du) Date: Thu, 1 Dec 2016 14:29:59 +0800 Subject: [9] RFR JDK-8157529 : Remove intermittent key from javax/net/ssl/DTLS/CipherSuite.java Message-ID: Hi , Would you help to review the path for "8157529:Remove intermittent key from javax/net/ssl/DTLS/CipherSuite.java" , the intermittently failed issue was fixed by JDK-8167680 , '@key intermittent ' can be removed.Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8157529 webrev: http://cr.openjdk.java.net/~tidu/8157529/webrev.00/ Regards Tim From goetz.lindenmaier at sap.com Thu Dec 1 07:39:03 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 07:39:03 +0000 Subject: RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <1D1BCEF7-AD74-4358-8DE3-1073649A55DF@oracle.com> References: <1D1BCEF7-AD74-4358-8DE3-1073649A55DF@oracle.com> Message-ID: <5e2ca37d4f5544ae8eef65ff4aeb9f53@DEROTE13DE08.global.corp.sap> Hi Vincent, I fixed the typo and added a remark to the first line of the bug text. Best regards, Goetz. > -----Original Message----- > From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > Sent: Mittwoch, 30. November 2016 17:10 > To: Lindenmaier, Goetz > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > > Note that I have reviewed only the ECC/PKCS11 changes. > You?ll need a JDK 9 reviewer from awt-dev for your remaining changes. > > There is a minor typo in the commit message: s/ece/ECC > > Also please change the Bug Summary in JBS to indicate that ECC and PKCS11 > changes are also present. > > > > On 30 Nov 2016, at 15:41, Lindenmaier, Goetz > wrote: > > > > Hi Vincent, > > > > thanks for the quit review! > > Good catch that I lost the change to p11_mutex.c ... I had to change > > it and it fell out of my patches. > > That looks fine. > > > > I edited the Last Modified Date, and also updated the copyright messages. > > Thanks. > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > > > > Best regards, > > Goetz. > > > > (Am I correct that your openJdk name is Vinnie?) > > Yes. > > > > > >> -----Original Message----- > >> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > >> Sent: Mittwoch, 30. November 2016 14:53 > >> To: Lindenmaier, Goetz > >> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > >> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > >> > >> Hello Goetz, > >> > >> Please modify the bug summary to reference ECC too. > >> Your ECC changes look fine but the ?Last Modified Date? line in the 4 source > >> code headers will need to be updated/added. > >> > >> BTW p11_mutex.c is listed below but appears to be missing from the > webrev. > >> > >> Thanks. > >> > >> > >> > >> > >> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > >> > > wrote: > >> > >> Hi, > >> > >> I?d like to propose a row of smaller fixes where code is noted down a > >> bit questionable. > >> SAP?s quality process requires that we fix these in our internal delivery, > >> and I > >> Would like to share my fixes with openJdk. Some of these fixes are of > >> more > >> theoretical nature as how I understand the code paths never allow the > >> problematic situation, but fixing it nevertheless assures that nothing is > >> overseen if the code changes. Most changes are in libawt_xawt, some > >> are in libsunec. > >> > >> I?d appreciate a review: > >> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > >> > >> Changes in detail: > >> > >> awt_InputMethod.c: > >> > >> One might overrun the 100 byte fixed-size string statusWindow->status > >> by copying text->string.multi_byte without checking the length. > >> > >> gtk3_interface.c: > >> > >> This less-than-zero comparison of an unsigned value is never true. > >> > >> Using uninitialized value color. Field color.alpha is uninitialized. > >> E.g. used at gtk3_interface.c:2287. > >> > >> XToolkit.c > >> > >> Using uninitialized value ret_timeout. > >> E.g. in XToolkit.c:6809. > >> > >> XWindow.c > >> > >> Argument is incompatible with corresponding format string conversion. > >> > >> splashscreen_sys.c > >> > >> Overflowed or truncated value (or a value computed from an > >> overflowed or truncated value) (gdk_scale > 0) ? native_scale * > >> (double)gdk_scale : native_scale used as return value. > >> > >> ec.c > >> > >> Using uninitialized value k.dp when calling mp_clear. > >> > >> ecdecode.c > >> > >> You might overrun the 291 byte fixed-size string genenc by copying > >> curveParams->geny without checking the length. > >> Added sanity check before doing the string concatenation. > >> > >> ecl_mult.c > >> > >> Using uninitialized value kt.flag when calling *group->point_mul. (The > >> function pointer resolves to ec_GF2m_pt_mul_mont.) > >> > >> mpi.c > >> > >> Using uninitialized value s. Field s.flag is uninitialized when calling > >> s_mp_exch. > >> Using uninitialized value tmp. Field tmp.flag is uninitialized when > >> calling s_mp_exch > >> Using uninitialized value t.dp when calling mp_clear. > >> > >> p11_mutex.c > >> > >> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is > >> uninitialized when calling memcpy. > >> > >> > >> DataBufferNative.c > >> > >> Using uninitialized value lockInfo.rasBase when calling > >> BN_GetPixelPointer. > >> > >> fontpath.c > >> > >> You might overrun the 512 byte fixed-size string fontDirPath by copying > >> DirP->name[index] without checking the length. > >> > > From goetz.lindenmaier at sap.com Thu Dec 1 08:29:57 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 08:29:57 +0000 Subject: RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <9e524d4b03a14198a54c2af271c5d9eb@DEWDFE13DE03.global.corp.sap> References: <9e524d4b03a14198a54c2af271c5d9eb@DEWDFE13DE03.global.corp.sap> Message-ID: <792ae9be83a0424bbfec6bff1be5a9be@DEROTE13DE08.global.corp.sap> Hi Christoph, I changed the code in fontpath.c to use snprintf, that seems much better as the concatenated string is a literal anyways. Also, I fixed the spaces. I'll post a new webrev once I'm through all the reviews. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 30. November 2016 20:47 > To: Lindenmaier, Goetz > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net; 2d- > dev at openjdk.java.net; Vincent Ryan > Subject: RE: RFR(M): 8170525: Fix minor issues in awt coding > > Hi Goetz, > > I have some small remarks. > > src/java.desktop/unix/native/common/awt/fontpath.c: > > 247 fontDirPath[sizeof(fontDirPath)-1] = '\0'; > -> you should add spaces left and right of '-' > 248 strncat(fontDirPath, "/fonts.dir", sizeof(fontDirPath) - > strlen(fontDirPath)); > -> I think you need to subtract 1 from the 3rd parameter of strncat ('size_t n') > because man page says: > "If src contains n or more bytes, strncat() writes n+1 bytes to dest (n from src > plus the terminating null byte). Therefore, the size of dest must be at least > strlen(dest)+n+1." > > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c: > > add spaces around '-' in the array index > > The rest looks fine to me. > > Best regards > Christoph > > > -----Original Message----- > > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On > Behalf > > Of Lindenmaier, Goetz > > Sent: Mittwoch, 30. November 2016 16:41 > > To: Vincent Ryan > > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > > Subject: RE: RFR(M): 8170525: Fix minor issues in awt coding > > > > Hi Vincent, > > > > thanks for the quit review! > > Good catch that I lost the change to p11_mutex.c ... I had to change > > it and it fell out of my patches. > > I edited the Last Modified Date, and also updated the copyright messages. > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > > > > Best regards, > > Goetz. > > > > (Am I correct that your openJdk name is Vinnie?) > > > > > -----Original Message----- > > > From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > > > Sent: Mittwoch, 30. November 2016 14:53 > > > To: Lindenmaier, Goetz > > > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > > > Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > > > > > > Hello Goetz, > > > > > > Please modify the bug summary to reference ECC too. > > > Your ECC changes look fine but the ?Last Modified Date? line in the 4 source > > > code headers will need to be updated/added. > > > > > > BTW p11_mutex.c is listed below but appears to be missing from the > webrev. > > > > > > Thanks. > > > > > > > > > > > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > > > > > wrote: > > > > > > Hi, > > > > > > I?d like to propose a row of smaller fixes where code is noted down a > > > bit questionable. > > > SAP?s quality process requires that we fix these in our internal delivery, > > > and I > > > Would like to share my fixes with openJdk. Some of these fixes are of > > > more > > > theoretical nature as how I understand the code paths never allow the > > > problematic situation, but fixing it nevertheless assures that nothing is > > > overseen if the code changes. Most changes are in libawt_xawt, some > > > are in libsunec. > > > > > > I?d appreciate a review: > > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > > > > > Changes in detail: > > > > > > awt_InputMethod.c: > > > > > > One might overrun the 100 byte fixed-size string statusWindow->status > > > by copying text->string.multi_byte without checking the length. > > > > > > gtk3_interface.c: > > > > > > This less-than-zero comparison of an unsigned value is never true. > > > > > > Using uninitialized value color. Field color.alpha is uninitialized. > > > E.g. used at gtk3_interface.c:2287. > > > > > > XToolkit.c > > > > > > Using uninitialized value ret_timeout. > > > E.g. in XToolkit.c:6809. > > > > > > XWindow.c > > > > > > Argument is incompatible with corresponding format string conversion. > > > > > > splashscreen_sys.c > > > > > > Overflowed or truncated value (or a value computed from an > > > overflowed or truncated value) (gdk_scale > 0) ? native_scale * > > > (double)gdk_scale : native_scale used as return value. > > > > > > ec.c > > > > > > Using uninitialized value k.dp when calling mp_clear. > > > > > > ecdecode.c > > > > > > You might overrun the 291 byte fixed-size string genenc by copying > > > curveParams->geny without checking the length. > > > Added sanity check before doing the string concatenation. > > > > > > ecl_mult.c > > > > > > Using uninitialized value kt.flag when calling *group->point_mul. (The > > > function pointer resolves to ec_GF2m_pt_mul_mont.) > > > > > > mpi.c > > > > > > Using uninitialized value s. Field s.flag is uninitialized when calling > > > s_mp_exch. > > > Using uninitialized value tmp. Field tmp.flag is uninitialized when > > > calling s_mp_exch > > > Using uninitialized value t.dp when calling mp_clear. > > > > > > p11_mutex.c > > > > > > Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is > > > uninitialized when calling memcpy. > > > > > > > > > DataBufferNative.c > > > > > > Using uninitialized value lockInfo.rasBase when calling > > > BN_GetPixelPointer. > > > > > > fontpath.c > > > > > > You might overrun the 512 byte fixed-size string fontDirPath by copying > > > DirP->name[index] without checking the length. > > > From goetz.lindenmaier at sap.com Thu Dec 1 11:03:07 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 11:03:07 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> References: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> Message-ID: <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap> Hi Phil, > Did you actually compile this ? The variable is called "rasBase", not > "resBase". Yes, I compiled it, and I fixed the error, but that was another repo I use for the coverity checks. Somehow it did not find its way into the webrev. I don't see where ops->Lock() initializes this field. ops->GetRasInfo(env, ops, lockInfo); does so if it resolves to BufImg_GetRasInfo(). I can't look in our code scan results because the issue is gone after fixing it, that lists the path of execution that leads to the issue. If you are sure this is correct I will remove the initialization, else I will also put it into the other method. DBN_GetPixelPointer checks lockInfo->rasBase for NULL and does what looks like the error case if it's NULL. Therefore NULL seemed a good initialization to me. Best regards, Goetz. > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Mittwoch, 30. November 2016 20:59 > To: Sergey Bylokhov ; Lindenmaier, Goetz > ; Vincent Ryan > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues > in awt coding > > Hi Goetz, > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase when calling DBN_GetPixelPointer. > > 75 lockInfo.resBase = NULL; > > Did you actually compile this ? The variable is called "rasBase", not > "resBase". > > And strictly there is no problem since inside DBN_GetPixelPointer > the code calls ops->Lock which should initialise this. > A "rasBase" of 0 isn't really any better than a random one .. > > Also I don't see why there's a problem here and not in > the function immediately following since it is the exact same case. > > -phil. > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > > cc 2d-dev. > > > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: > >> Hi Vincent, > >> > >> thanks for the quit review! > >> Good catch that I lost the change to p11_mutex.c ... I had to change > >> it and it fell out of my patches. > >> I edited the Last Modified Date, and also updated the copyright > >> messages. > >> New webrev: > >> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > >> > >> Best regards, > >> Goetz. > >> > >> (Am I correct that your openJdk name is Vinnie?) > >> > >>> -----Original Message----- > >>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > >>> Sent: Mittwoch, 30. November 2016 14:53 > >>> To: Lindenmaier, Goetz > >>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > >>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > >>> > >>> Hello Goetz, > >>> > >>> Please modify the bug summary to reference ECC too. > >>> Your ECC changes look fine but the ?Last Modified Date? line in the > >>> 4 source > >>> code headers will need to be updated/added. > >>> > >>> BTW p11_mutex.c is listed below but appears to be missing from the > >>> webrev. > >>> > >>> Thanks. > >>> > >>> > >>> > >>> > >>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > >>> > > wrote: > >>> > >>> Hi, > >>> > >>> I?d like to propose a row of smaller fixes where code is noted > >>> down a > >>> bit questionable. > >>> SAP?s quality process requires that we fix these in our internal > >>> delivery, > >>> and I > >>> Would like to share my fixes with openJdk. Some of these fixes > >>> are of > >>> more > >>> theoretical nature as how I understand the code paths never > >>> allow the > >>> problematic situation, but fixing it nevertheless assures that > >>> nothing is > >>> overseen if the code changes. Most changes are in libawt_xawt, > >>> some > >>> are in libsunec. > >>> > >>> I?d appreciate a review: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > >>> > >>> Changes in detail: > >>> > >>> awt_InputMethod.c: > >>> > >>> One might overrun the 100 byte fixed-size string > >>> statusWindow->status > >>> by copying text->string.multi_byte without checking the length. > >>> > >>> gtk3_interface.c: > >>> > >>> This less-than-zero comparison of an unsigned value is never true. > >>> > >>> Using uninitialized value color. Field color.alpha is > >>> uninitialized. > >>> E.g. used at gtk3_interface.c:2287. > >>> > >>> XToolkit.c > >>> > >>> Using uninitialized value ret_timeout. > >>> E.g. in XToolkit.c:6809. > >>> > >>> XWindow.c > >>> > >>> Argument is incompatible with corresponding format string > >>> conversion. > >>> > >>> splashscreen_sys.c > >>> > >>> Overflowed or truncated value (or a value computed from an > >>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * > >>> (double)gdk_scale : native_scale used as return value. > >>> > >>> ec.c > >>> > >>> Using uninitialized value k.dp when calling mp_clear. > >>> > >>> ecdecode.c > >>> > >>> You might overrun the 291 byte fixed-size string genenc by copying > >>> curveParams->geny without checking the length. > >>> Added sanity check before doing the string concatenation. > >>> > >>> ecl_mult.c > >>> > >>> Using uninitialized value kt.flag when calling > >>> *group->point_mul. (The > >>> function pointer resolves to ec_GF2m_pt_mul_mont.) > >>> > >>> mpi.c > >>> > >>> Using uninitialized value s. Field s.flag is uninitialized when > >>> calling > >>> s_mp_exch. > >>> Using uninitialized value tmp. Field tmp.flag is uninitialized when > >>> calling s_mp_exch > >>> Using uninitialized value t.dp when calling mp_clear. > >>> > >>> p11_mutex.c > >>> > >>> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is > >>> uninitialized when calling memcpy. > >>> > >>> > >>> DataBufferNative.c > >>> > >>> Using uninitialized value lockInfo.rasBase when calling > >>> BN_GetPixelPointer. > >>> > >>> fontpath.c > >>> > >>> You might overrun the 512 byte fixed-size string fontDirPath by > >>> copying > >>> DirP->name[index] without checking the length. > >>> > >> > > > > From goetz.lindenmaier at sap.com Thu Dec 1 11:10:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 11:10:15 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> References: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Message-ID: Hi Prasanta, good point, I added that too. Best regards, Goetz. > -----Original Message----- > From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com] > Sent: Donnerstag, 1. Dezember 2016 06:05 > To: Phil Race ; Sergey Bylokhov > ; Lindenmaier, Goetz > ; Vincent Ryan > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues > in awt coding > > Also, in gtk3_interface.c, there is this change for color.alpha > > > 2219 color.alpha = 0; in gtk3_get_color_for_flags() > but it is used in > gtk3_get_color_for_state() where it is not initialized > > 2268 GdkRGBA color; > Regards > Prasanta > > On 12/1/2016 1:28 AM, Phil Race wrote: > > > Hi Goetz, > > > > DataBufferNative.c > Using uninitialized value lockInfo.rasBase when calling > DBN_GetPixelPointer. > > > > 75 lockInfo.resBase = NULL; > > Did you actually compile this ? The variable is called "rasBase", not > "resBase". > > And strictly there is no problem since inside DBN_GetPixelPointer > the code calls ops->Lock which should initialise this. > A "rasBase" of 0 isn't really any better than a random one .. > > Also I don't see why there's a problem here and not in > the function immediately following since it is the exact same case. > > -phil. > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > > > cc 2d-dev. > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: > > > Hi Vincent, > > thanks for the quit review! > Good catch that I lost the change to p11_mutex.c ... I > had to change > it and it fell out of my patches. > I edited the Last Modified Date, and also updated the > copyright messages. > New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt- > dev/ > > Best regards, > Goetz. > > (Am I correct that your openJdk name is Vinnie?) > > > > -----Original Message----- > From: Vincent Ryan > [mailto:vincent.x.ryan at oracle.com] > Sent: Mittwoch, 30. November 2016 14:53 > To: Lindenmaier, Goetz > > Cc: awt-dev at openjdk.java.net dev at openjdk.java.net> ; security-dev at openjdk.java.net dev at openjdk.java.net> > Subject: Re: RFR(M): 8170525: Fix minor issues > in awt coding > > Hello Goetz, > > Please modify the bug summary to reference > ECC too. > Your ECC changes look fine but the ?Last > Modified Date? line in the 4 source > code headers will need to be updated/added. > > BTW p11_mutex.c is listed below but appears > to be missing from the webrev. > > Thanks. > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, > Goetz > > > wrote: > > Hi, > > I?d like to propose a row of smaller fixes > where code is noted down a > bit questionable. > SAP?s quality process requires that we fix > these in our internal delivery, > and I > Would like to share my fixes with openJdk. > Some of these fixes are of > more > theoretical nature as how I understand the > code paths never allow the > problematic situation, but fixing it > nevertheless assures that nothing is > overseen if the code changes. Most changes > are in libawt_xawt, some > are in libsunec. > > I?d appreciate a review: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > Changes in detail: > > awt_InputMethod.c: > > One might overrun the 100 byte fixed-size > string statusWindow->status > by copying text->string.multi_byte without > checking the length. > > gtk3_interface.c: > > This less-than-zero comparison of an > unsigned value is never true. > > Using uninitialized value color. Field > color.alpha is uninitialized. > E.g. used at gtk3_interface.c:2287. > > XToolkit.c > > Using uninitialized value ret_timeout. > E.g. in XToolkit.c:6809. > > XWindow.c > > Argument is incompatible with > corresponding format string conversion. > > splashscreen_sys.c > > Overflowed or truncated value (or a value > computed from an > overflowed or truncated value) (gdk_scale > 0) > ? native_scale * > (double)gdk_scale : native_scale used as return > value. > > ec.c > > Using uninitialized value k.dp when calling > mp_clear. > > ecdecode.c > > You might overrun the 291 byte fixed-size > string genenc by copying > curveParams->geny without checking the > length. > Added sanity check before doing the string > concatenation. > > ecl_mult.c > > Using uninitialized value kt.flag when calling > *group->point_mul. (The > function pointer resolves to > ec_GF2m_pt_mul_mont.) > > mpi.c > > Using uninitialized value s. Field s.flag is > uninitialized when calling > s_mp_exch. > Using uninitialized value tmp. Field tmp.flag > is uninitialized when > calling s_mp_exch > Using uninitialized value t.dp when calling > mp_clear. > > p11_mutex.c > > Using uninitialized value *ckpInitArgs. Field > ckpInitArgs->flags is > uninitialized when calling memcpy. > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase > when calling > BN_GetPixelPointer. > > fontpath.c > > You might overrun the 512 byte fixed-size > string fontDirPath by copying > DirP->name[index] without checking the length. > > > > > > > From goetz.lindenmaier at sap.com Thu Dec 1 11:13:26 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 11:13:26 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding References: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Message-ID: Ah, no, that is just the field that is initialized with the Result of gtk3_get_color_for_flags() why I need to initialize it there. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 1. Dezember 2016 12:10 > To: 'Prasanta Sadhukhan' ; Phil Race > ; Sergey Bylokhov ; > Vincent Ryan > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues > in awt coding > > Hi Prasanta, > > good point, I added that too. > > Best regards, > Goetz. > > > -----Original Message----- > > From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com] > > Sent: Donnerstag, 1. Dezember 2016 06:05 > > To: Phil Race ; Sergey Bylokhov > > ; Lindenmaier, Goetz > > ; Vincent Ryan > > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > > dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor > issues > > in awt coding > > > > Also, in gtk3_interface.c, there is this change for color.alpha > > > > > > 2219 color.alpha = 0; in gtk3_get_color_for_flags() > > but it is used in > > gtk3_get_color_for_state() where it is not initialized > > > > 2268 GdkRGBA color; > > Regards > > Prasanta > > > > On 12/1/2016 1:28 AM, Phil Race wrote: > > > > > > Hi Goetz, > > > > > > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase when calling > > DBN_GetPixelPointer. > > > > > > > > 75 lockInfo.resBase = NULL; > > > > Did you actually compile this ? The variable is called "rasBase", not > > "resBase". > > > > And strictly there is no problem since inside DBN_GetPixelPointer > > the code calls ops->Lock which should initialise this. > > A "rasBase" of 0 isn't really any better than a random one .. > > > > Also I don't see why there's a problem here and not in > > the function immediately following since it is the exact same case. > > > > -phil. > > > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > > > > > > cc 2d-dev. > > > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: > > > > > > Hi Vincent, > > > > thanks for the quit review! > > Good catch that I lost the change to p11_mutex.c ... I > > had to change > > it and it fell out of my patches. > > I edited the Last Modified Date, and also updated the > > copyright messages. > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt- > > dev/ > > > > Best regards, > > Goetz. > > > > (Am I correct that your openJdk name is Vinnie?) > > > > > > > > -----Original Message----- > > From: Vincent Ryan > > [mailto:vincent.x.ryan at oracle.com] > > Sent: Mittwoch, 30. November 2016 14:53 > > To: Lindenmaier, Goetz > > > > Cc: awt-dev at openjdk.java.net > dev at openjdk.java.net> ; security-dev at openjdk.java.net > dev at openjdk.java.net> > > Subject: Re: RFR(M): 8170525: Fix minor issues > > in awt coding > > > > Hello Goetz, > > > > Please modify the bug summary to reference > > ECC too. > > Your ECC changes look fine but the ?Last > > Modified Date? line in the 4 source > > code headers will need to be updated/added. > > > > BTW p11_mutex.c is listed below but appears > > to be missing from the webrev. > > > > Thanks. > > > > > > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, > > Goetz > > > > > > wrote: > > > > Hi, > > > > I?d like to propose a row of smaller fixes > > where code is noted down a > > bit questionable. > > SAP?s quality process requires that we fix > > these in our internal delivery, > > and I > > Would like to share my fixes with openJdk. > > Some of these fixes are of > > more > > theoretical nature as how I understand the > > code paths never allow the > > problematic situation, but fixing it > > nevertheless assures that nothing is > > overseen if the code changes. Most changes > > are in libawt_xawt, some > > are in libsunec. > > > > I?d appreciate a review: > > > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > > > Changes in detail: > > > > awt_InputMethod.c: > > > > One might overrun the 100 byte fixed-size > > string statusWindow->status > > by copying text->string.multi_byte without > > checking the length. > > > > gtk3_interface.c: > > > > This less-than-zero comparison of an > > unsigned value is never true. > > > > Using uninitialized value color. Field > > color.alpha is uninitialized. > > E.g. used at gtk3_interface.c:2287. > > > > XToolkit.c > > > > Using uninitialized value ret_timeout. > > E.g. in XToolkit.c:6809. > > > > XWindow.c > > > > Argument is incompatible with > > corresponding format string conversion. > > > > splashscreen_sys.c > > > > Overflowed or truncated value (or a value > > computed from an > > overflowed or truncated value) (gdk_scale > 0) > > ? native_scale * > > (double)gdk_scale : native_scale used as return > > value. > > > > ec.c > > > > Using uninitialized value k.dp when calling > > mp_clear. > > > > ecdecode.c > > > > You might overrun the 291 byte fixed-size > > string genenc by copying > > curveParams->geny without checking the > > length. > > Added sanity check before doing the string > > concatenation. > > > > ecl_mult.c > > > > Using uninitialized value kt.flag when calling > > *group->point_mul. (The > > function pointer resolves to > > ec_GF2m_pt_mul_mont.) > > > > mpi.c > > > > Using uninitialized value s. Field s.flag is > > uninitialized when calling > > s_mp_exch. > > Using uninitialized value tmp. Field tmp.flag > > is uninitialized when > > calling s_mp_exch > > Using uninitialized value t.dp when calling > > mp_clear. > > > > p11_mutex.c > > > > Using uninitialized value *ckpInitArgs. Field > > ckpInitArgs->flags is > > uninitialized when calling memcpy. > > > > > > DataBufferNative.c > > > > Using uninitialized value lockInfo.rasBase > > when calling > > BN_GetPixelPointer. > > > > fontpath.c > > > > You might overrun the 512 byte fixed-size > > string fontDirPath by copying > > DirP->name[index] without checking the length. > > > > > > > > > > > > > > From claes.redestad at oracle.com Thu Dec 1 15:33:28 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 16:33:28 +0100 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection Message-ID: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> Hi, recent changes to FilePermissionCollection to use a lambda in place of an explicit BiFunction cause a quite noticeable startup and footprint regression on small applications due to a bootstrap dependency. Therefore I'd like to revert this particular change. Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ Thanks! /Claes From Alan.Bateman at oracle.com Thu Dec 1 17:10:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Dec 2016 17:10:01 +0000 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection In-Reply-To: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> References: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> Message-ID: <8b7a23d8-3477-a935-a3db-737d7da2cbce@oracle.com> On 01/12/2016 15:33, Claes Redestad wrote: > Hi, > > recent changes to FilePermissionCollection to use a lambda in place of > an explicit > BiFunction cause a quite noticeable startup and footprint regression > on small > applications due to a bootstrap dependency. Therefore I'd like to > revert this > particular change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 > Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ Looks okay but I hope we don't have to do too many of these. -Alan From claes.redestad at oracle.com Thu Dec 1 17:19:31 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 18:19:31 +0100 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection In-Reply-To: <8b7a23d8-3477-a935-a3db-737d7da2cbce@oracle.com> References: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> <8b7a23d8-3477-a935-a3db-737d7da2cbce@oracle.com> Message-ID: <901edb87-42ed-9ba1-4a72-144732e91fe8@oracle.com> On 2016-12-01 18:10, Alan Bateman wrote: > On 01/12/2016 15:33, Claes Redestad wrote: > >> Hi, >> >> recent changes to FilePermissionCollection to use a lambda in place >> of an explicit >> BiFunction cause a quite noticeable startup and footprint regression >> on small >> applications due to a bootstrap dependency. Therefore I'd like to >> revert this >> particular change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 >> Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ > Looks okay but I hope we don't have to do too many of these. Thanks for the review, Alan. Hope so too. We've done a lot to improve java.lang.invoke and lambda bootstrap in 9, but there are cases like this that are still too costly to have on the startup path. A few more improvements to the --generate-jli-classes jlink plugin might change things...? :-) Thanks! /Claes > > -Alan From sean.mullan at oracle.com Thu Dec 1 19:02:33 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Dec 2016 14:02:33 -0500 Subject: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property In-Reply-To: <58346B9C.7040102@oracle.com> References: <58337894.4020600@oracle.com> <58346B9C.7040102@oracle.com> Message-ID: <4be92f37-0576-499f-f6f1-54d9f2b98fec@oracle.com> I enhanced the test case to test more scenarios where MD5 is either disabled via the jdk.tls.disabledAlgorithms or the jdk.certpath.disabledAlgorithms property. Please take another look and let me know if you are ok with it: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.01/ Thanks, Sean On 11/22/16 11:00 AM, Anthony Scarpino wrote: > On 11/22/2016 05:19 AM, Sean Mullan wrote: >> On 11/21/16 5:43 PM, Anthony Scarpino wrote: >>> On 11/21/2016 01:09 PM, Sean Mullan wrote: >>>> Please review this fix for a bug where certificates were not being >>>> blocked if the algorithm is only listed in the >>>> jdk.tls.disabledAlgorithms property and not the >>>> jdk.certpath.disabledAlgorithms property. >>>> >>>> I have modified an existing regression test to test this functionality >>>> as there was no previous test for this feature. >>>> >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170131 >>>> >>>> --Sean >>> >>> Is the reason the if() is needed is >>> constraints.permit(CerttConstraintParameters) is not in the >>> SSLAlgorithmConstraints class and the method exception is suppressed? >> >> SSLAlgorithmConstraints is not an instanceof >> DisabledAlgorithmConstraints. When AlgorithmChecker.check is called, the >> previous code (on line 329) would call >> certPathDefaultConstraints.permits. This would pass, because the test >> has configured jdk.certpath.disabledAlgorithms property to be empty. The >> first time through, prevPubKey would also be null, so it would return on >> line 335. It would never call SSLAlgorithmConstraints.permits. >> >> Does that make sense? >> >> --Sean > > > Ok.. I see what's going on more.. I'm ok with this.. > > Tony > From prasanta.sadhukhan at oracle.com Thu Dec 1 05:05:28 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 1 Dec 2016 10:35:28 +0530 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> References: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> Message-ID: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Also, in gtk3_interface.c, there is this change for color.alpha 2219 color.alpha = 0; in gtk3_get_color_for_flags() but it is used in gtk3_get_color_for_state() where it is not initialized 2268 GdkRGBA color; Regards Prasanta On 12/1/2016 1:28 AM, Phil Race wrote: > Hi Goetz, > >> DataBufferNative.c >> Using uninitialized value lockInfo.rasBase when calling >> DBN_GetPixelPointer. > > 75 lockInfo.resBase = NULL; > > Did you actually compile this ? The variable is called "rasBase", not > "resBase". > > And strictly there is no problem since inside DBN_GetPixelPointer > the code calls ops->Lock which should initialise this. > A "rasBase" of 0 isn't really any better than a random one .. > > Also I don't see why there's a problem here and not in > the function immediately following since it is the exact same case. > > -phil. > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: >> cc 2d-dev. >> >> On 30.11.16 18:41, Lindenmaier, Goetz wrote: >>> Hi Vincent, >>> >>> thanks for the quit review! >>> Good catch that I lost the change to p11_mutex.c ... I had to change >>> it and it fell out of my patches. >>> I edited the Last Modified Date, and also updated the copyright >>> messages. >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ >>> >>> Best regards, >>> Goetz. >>> >>> (Am I correct that your openJdk name is Vinnie?) >>> >>>> -----Original Message----- >>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >>>> Sent: Mittwoch, 30. November 2016 14:53 >>>> To: Lindenmaier, Goetz >>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >>>> >>>> Hello Goetz, >>>> >>>> Please modify the bug summary to reference ECC too. >>>> Your ECC changes look fine but the ?Last Modified Date? line in the >>>> 4 source >>>> code headers will need to be updated/added. >>>> >>>> BTW p11_mutex.c is listed below but appears to be missing from the >>>> webrev. >>>> >>>> Thanks. >>>> >>>> >>>> >>>> >>>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >>>> > wrote: >>>> >>>> Hi, >>>> >>>> I?d like to propose a row of smaller fixes where code is noted >>>> down a >>>> bit questionable. >>>> SAP?s quality process requires that we fix these in our >>>> internal delivery, >>>> and I >>>> Would like to share my fixes with openJdk. Some of these fixes >>>> are of >>>> more >>>> theoretical nature as how I understand the code paths never >>>> allow the >>>> problematic situation, but fixing it nevertheless assures that >>>> nothing is >>>> overseen if the code changes. Most changes are in libawt_xawt, >>>> some >>>> are in libsunec. >>>> >>>> I?d appreciate a review: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >>>> >>>> Changes in detail: >>>> >>>> awt_InputMethod.c: >>>> >>>> One might overrun the 100 byte fixed-size string >>>> statusWindow->status >>>> by copying text->string.multi_byte without checking the length. >>>> >>>> gtk3_interface.c: >>>> >>>> This less-than-zero comparison of an unsigned value is never true. >>>> >>>> Using uninitialized value color. Field color.alpha is >>>> uninitialized. >>>> E.g. used at gtk3_interface.c:2287. >>>> >>>> XToolkit.c >>>> >>>> Using uninitialized value ret_timeout. >>>> E.g. in XToolkit.c:6809. >>>> >>>> XWindow.c >>>> >>>> Argument is incompatible with corresponding format string >>>> conversion. >>>> >>>> splashscreen_sys.c >>>> >>>> Overflowed or truncated value (or a value computed from an >>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >>>> (double)gdk_scale : native_scale used as return value. >>>> >>>> ec.c >>>> >>>> Using uninitialized value k.dp when calling mp_clear. >>>> >>>> ecdecode.c >>>> >>>> You might overrun the 291 byte fixed-size string genenc by copying >>>> curveParams->geny without checking the length. >>>> Added sanity check before doing the string concatenation. >>>> >>>> ecl_mult.c >>>> >>>> Using uninitialized value kt.flag when calling >>>> *group->point_mul. (The >>>> function pointer resolves to ec_GF2m_pt_mul_mont.) >>>> >>>> mpi.c >>>> >>>> Using uninitialized value s. Field s.flag is uninitialized when >>>> calling >>>> s_mp_exch. >>>> Using uninitialized value tmp. Field tmp.flag is uninitialized >>>> when >>>> calling s_mp_exch >>>> Using uninitialized value t.dp when calling mp_clear. >>>> >>>> p11_mutex.c >>>> >>>> Using uninitialized value *ckpInitArgs. Field >>>> ckpInitArgs->flags is >>>> uninitialized when calling memcpy. >>>> >>>> >>>> DataBufferNative.c >>>> >>>> Using uninitialized value lockInfo.rasBase when calling >>>> BN_GetPixelPointer. >>>> >>>> fontpath.c >>>> >>>> You might overrun the 512 byte fixed-size string fontDirPath by >>>> copying >>>> DirP->name[index] without checking the length. >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Dec 1 07:44:40 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 1 Dec 2016 10:44:40 +0300 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> References: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Message-ID: yes, this is a potential issue. But actually cases MID,FOCUS,BLACK,WHITE are never used. But the fix is wrong. It should be color.alpha = 1; --Semyon On 01.12.2016 08:05, Prasanta Sadhukhan wrote: > > Also, in gtk3_interface.c, there is this change for color.alpha > > 2219 color.alpha = 0; in gtk3_get_color_for_flags() > but it is used in > gtk3_get_color_for_state() where it is not initialized > > 2268 GdkRGBA color; > Regards > Prasanta > On 12/1/2016 1:28 AM, Phil Race wrote: >> Hi Goetz, >> >>> DataBufferNative.c >>> Using uninitialized value lockInfo.rasBase when calling >>> DBN_GetPixelPointer. >> >> 75 lockInfo.resBase = NULL; >> >> Did you actually compile this ? The variable is called "rasBase", not >> "resBase". >> >> And strictly there is no problem since inside DBN_GetPixelPointer >> the code calls ops->Lock which should initialise this. >> A "rasBase" of 0 isn't really any better than a random one .. >> >> Also I don't see why there's a problem here and not in >> the function immediately following since it is the exact same case. >> >> -phil. >> >> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: >>> cc 2d-dev. >>> >>> On 30.11.16 18:41, Lindenmaier, Goetz wrote: >>>> Hi Vincent, >>>> >>>> thanks for the quit review! >>>> Good catch that I lost the change to p11_mutex.c ... I had to change >>>> it and it fell out of my patches. >>>> I edited the Last Modified Date, and also updated the copyright >>>> messages. >>>> New webrev: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> (Am I correct that your openJdk name is Vinnie?) >>>> >>>>> -----Original Message----- >>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >>>>> Sent: Mittwoch, 30. November 2016 14:53 >>>>> To: Lindenmaier, Goetz >>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >>>>> >>>>> Hello Goetz, >>>>> >>>>> Please modify the bug summary to reference ECC too. >>>>> Your ECC changes look fine but the ?Last Modified Date? line in >>>>> the 4 source >>>>> code headers will need to be updated/added. >>>>> >>>>> BTW p11_mutex.c is listed below but appears to be missing from the >>>>> webrev. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I?d like to propose a row of smaller fixes where code is noted >>>>> down a >>>>> bit questionable. >>>>> SAP?s quality process requires that we fix these in our >>>>> internal delivery, >>>>> and I >>>>> Would like to share my fixes with openJdk. Some of these >>>>> fixes are of >>>>> more >>>>> theoretical nature as how I understand the code paths never >>>>> allow the >>>>> problematic situation, but fixing it nevertheless assures that >>>>> nothing is >>>>> overseen if the code changes. Most changes are in >>>>> libawt_xawt, some >>>>> are in libsunec. >>>>> >>>>> I?d appreciate a review: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >>>>> >>>>> Changes in detail: >>>>> >>>>> awt_InputMethod.c: >>>>> >>>>> One might overrun the 100 byte fixed-size string >>>>> statusWindow->status >>>>> by copying text->string.multi_byte without checking the length. >>>>> >>>>> gtk3_interface.c: >>>>> >>>>> This less-than-zero comparison of an unsigned value is never >>>>> true. >>>>> >>>>> Using uninitialized value color. Field color.alpha is >>>>> uninitialized. >>>>> E.g. used at gtk3_interface.c:2287. >>>>> >>>>> XToolkit.c >>>>> >>>>> Using uninitialized value ret_timeout. >>>>> E.g. in XToolkit.c:6809. >>>>> >>>>> XWindow.c >>>>> >>>>> Argument is incompatible with corresponding format string >>>>> conversion. >>>>> >>>>> splashscreen_sys.c >>>>> >>>>> Overflowed or truncated value (or a value computed from an >>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >>>>> (double)gdk_scale : native_scale used as return value. >>>>> >>>>> ec.c >>>>> >>>>> Using uninitialized value k.dp when calling mp_clear. >>>>> >>>>> ecdecode.c >>>>> >>>>> You might overrun the 291 byte fixed-size string genenc by >>>>> copying >>>>> curveParams->geny without checking the length. >>>>> Added sanity check before doing the string concatenation. >>>>> >>>>> ecl_mult.c >>>>> >>>>> Using uninitialized value kt.flag when calling >>>>> *group->point_mul. (The >>>>> function pointer resolves to ec_GF2m_pt_mul_mont.) >>>>> >>>>> mpi.c >>>>> >>>>> Using uninitialized value s. Field s.flag is uninitialized >>>>> when calling >>>>> s_mp_exch. >>>>> Using uninitialized value tmp. Field tmp.flag is uninitialized >>>>> when >>>>> calling s_mp_exch >>>>> Using uninitialized value t.dp when calling mp_clear. >>>>> >>>>> p11_mutex.c >>>>> >>>>> Using uninitialized value *ckpInitArgs. Field >>>>> ckpInitArgs->flags is >>>>> uninitialized when calling memcpy. >>>>> >>>>> >>>>> DataBufferNative.c >>>>> >>>>> Using uninitialized value lockInfo.rasBase when calling >>>>> BN_GetPixelPointer. >>>>> >>>>> fontpath.c >>>>> >>>>> You might overrun the 512 byte fixed-size string fontDirPath >>>>> by copying >>>>> DirP->name[index] without checking the length. >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Dec 1 21:30:58 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 1 Dec 2016 13:30:58 -0800 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap> References: <32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap> Message-ID: <65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com> Sorry. it is ops->GetRasInfo(env, ops, lockInfo); that initialises it .. That is still before the dereference Anyway, what was the reason for updating one function, but not the other. I don't mind the change, but the inconsistency looks odd. -phil. On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote: > Hi Phil, > >> Did you actually compile this ? The variable is called "rasBase", not >> "resBase". > Yes, I compiled it, and I fixed the error, but that was another repo > I use for the coverity checks. Somehow it did not find its way into > the webrev. > > I don't see where ops->Lock() initializes this field. > ops->GetRasInfo(env, ops, lockInfo); does so if it resolves > to BufImg_GetRasInfo(). I can't look in our code scan results > because the issue is gone after fixing it, that lists the path > of execution that leads to the issue. > If you are sure this is correct I will remove the initialization, > else I will also put it into the other method. > > DBN_GetPixelPointer checks lockInfo->rasBase for NULL and > does what looks like the error case if it's NULL. Therefore NULL > seemed a good initialization to me. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Mittwoch, 30. November 2016 20:59 >> To: Sergey Bylokhov ; Lindenmaier, Goetz >> ; Vincent Ryan >> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- >> dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues >> in awt coding >> >> Hi Goetz, >> >>> DataBufferNative.c >>> Using uninitialized value lockInfo.rasBase when calling DBN_GetPixelPointer. >> 75 lockInfo.resBase = NULL; >> >> Did you actually compile this ? The variable is called "rasBase", not >> "resBase". >> >> And strictly there is no problem since inside DBN_GetPixelPointer >> the code calls ops->Lock which should initialise this. >> A "rasBase" of 0 isn't really any better than a random one .. >> >> Also I don't see why there's a problem here and not in >> the function immediately following since it is the exact same case. >> >> -phil. >> >> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: >>> cc 2d-dev. >>> >>> On 30.11.16 18:41, Lindenmaier, Goetz wrote: >>>> Hi Vincent, >>>> >>>> thanks for the quit review! >>>> Good catch that I lost the change to p11_mutex.c ... I had to change >>>> it and it fell out of my patches. >>>> I edited the Last Modified Date, and also updated the copyright >>>> messages. >>>> New webrev: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> (Am I correct that your openJdk name is Vinnie?) >>>> >>>>> -----Original Message----- >>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >>>>> Sent: Mittwoch, 30. November 2016 14:53 >>>>> To: Lindenmaier, Goetz >>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >>>>> >>>>> Hello Goetz, >>>>> >>>>> Please modify the bug summary to reference ECC too. >>>>> Your ECC changes look fine but the ?Last Modified Date? line in the >>>>> 4 source >>>>> code headers will need to be updated/added. >>>>> >>>>> BTW p11_mutex.c is listed below but appears to be missing from the >>>>> webrev. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >>>>> > >> wrote: >>>>> Hi, >>>>> >>>>> I?d like to propose a row of smaller fixes where code is noted >>>>> down a >>>>> bit questionable. >>>>> SAP?s quality process requires that we fix these in our internal >>>>> delivery, >>>>> and I >>>>> Would like to share my fixes with openJdk. Some of these fixes >>>>> are of >>>>> more >>>>> theoretical nature as how I understand the code paths never >>>>> allow the >>>>> problematic situation, but fixing it nevertheless assures that >>>>> nothing is >>>>> overseen if the code changes. Most changes are in libawt_xawt, >>>>> some >>>>> are in libsunec. >>>>> >>>>> I?d appreciate a review: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >>>>> >>>>> Changes in detail: >>>>> >>>>> awt_InputMethod.c: >>>>> >>>>> One might overrun the 100 byte fixed-size string >>>>> statusWindow->status >>>>> by copying text->string.multi_byte without checking the length. >>>>> >>>>> gtk3_interface.c: >>>>> >>>>> This less-than-zero comparison of an unsigned value is never true. >>>>> >>>>> Using uninitialized value color. Field color.alpha is >>>>> uninitialized. >>>>> E.g. used at gtk3_interface.c:2287. >>>>> >>>>> XToolkit.c >>>>> >>>>> Using uninitialized value ret_timeout. >>>>> E.g. in XToolkit.c:6809. >>>>> >>>>> XWindow.c >>>>> >>>>> Argument is incompatible with corresponding format string >>>>> conversion. >>>>> >>>>> splashscreen_sys.c >>>>> >>>>> Overflowed or truncated value (or a value computed from an >>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >>>>> (double)gdk_scale : native_scale used as return value. >>>>> >>>>> ec.c >>>>> >>>>> Using uninitialized value k.dp when calling mp_clear. >>>>> >>>>> ecdecode.c >>>>> >>>>> You might overrun the 291 byte fixed-size string genenc by copying >>>>> curveParams->geny without checking the length. >>>>> Added sanity check before doing the string concatenation. >>>>> >>>>> ecl_mult.c >>>>> >>>>> Using uninitialized value kt.flag when calling >>>>> *group->point_mul. (The >>>>> function pointer resolves to ec_GF2m_pt_mul_mont.) >>>>> >>>>> mpi.c >>>>> >>>>> Using uninitialized value s. Field s.flag is uninitialized when >>>>> calling >>>>> s_mp_exch. >>>>> Using uninitialized value tmp. Field tmp.flag is uninitialized when >>>>> calling s_mp_exch >>>>> Using uninitialized value t.dp when calling mp_clear. >>>>> >>>>> p11_mutex.c >>>>> >>>>> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is >>>>> uninitialized when calling memcpy. >>>>> >>>>> >>>>> DataBufferNative.c >>>>> >>>>> Using uninitialized value lockInfo.rasBase when calling >>>>> BN_GetPixelPointer. >>>>> >>>>> fontpath.c >>>>> >>>>> You might overrun the 512 byte fixed-size string fontDirPath by >>>>> copying >>>>> DirP->name[index] without checking the length. >>>>> >>> From sha.jiang at oracle.com Fri Dec 2 03:32:50 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 2 Dec 2016 11:32:50 +0800 Subject: RFR[9] JDK-8170523: Some PKCS11 test cases are ignored with security manager Message-ID: <6c3ff553-9075-2a83-a42c-322e2ee2ff5a@oracle.com> Hi, Some PKCS11 tests call PKCS11Test.getDistro(), which run command "uname -v", to determine the OS distro. But if the tests enable security manager and don't grant appropriate file permission, PKCS11Test.getDistro() fails to get the distro. Then, the associated cases will be ignored since the tests think that the OS is not the target. Webrev: http://cr.openjdk.java.net/~jjiang/8170523/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8170523 Best regards, John Jiang From sibabrata.sahoo at oracle.com Fri Dec 2 13:25:41 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 2 Dec 2016 05:25:41 -0800 (PST) Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization Message-ID: Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8168423 Webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.00/ Description: This webrev address all possible cases for Classloader with SecurityManager having combination of valid/malformed policy file. This Test is going to fail until JDK-8168075 get fixed. In the mean time, it can be used to verify the fix for JDK-8168075. Here is the generic Logic behind generating all possible Test cases with different combination of policy file, class loader and module types. for(policyFile : {"NO_POLICY", "VALID", "MALFORMED"}) { for(classLoader : {"SystemClassLoader", "CustomClassLoader"}){ // It uses possible set of regular/modular jars to generate all possible Test cases in -cp and -module-path. for(clientModuletype : {"STRICT", "AUTO", "UNKNOWN"}) { for(classLoaderModuleType : {"STRICT", "AUTO", "UNKNOWN"}) { Create and run java command line for each possible Test cases and verify result. } } } } Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Fri Dec 2 16:41:11 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 2 Dec 2016 08:41:11 -0800 Subject: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property In-Reply-To: <4be92f37-0576-499f-f6f1-54d9f2b98fec@oracle.com> References: <58337894.4020600@oracle.com> <58346B9C.7040102@oracle.com> <4be92f37-0576-499f-f6f1-54d9f2b98fec@oracle.com> Message-ID: <1CBC80A2-2ED5-4084-84FE-89088CF30081@oracle.com> It looks fine. One question, line 866 of the test you print the stacktrace on a success, was that intentional? Tony > On Dec 1, 2016, at 11:02 AM, Sean Mullan wrote: > > I enhanced the test case to test more scenarios where MD5 is either disabled via the jdk.tls.disabledAlgorithms or the jdk.certpath.disabledAlgorithms property. Please take another look and let me know if you are ok with it: > > http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.01/ > > Thanks, > Sean > >> On 11/22/16 11:00 AM, Anthony Scarpino wrote: >>> On 11/22/2016 05:19 AM, Sean Mullan wrote: >>>> On 11/21/16 5:43 PM, Anthony Scarpino wrote: >>>>> On 11/21/2016 01:09 PM, Sean Mullan wrote: >>>>> Please review this fix for a bug where certificates were not being >>>>> blocked if the algorithm is only listed in the >>>>> jdk.tls.disabledAlgorithms property and not the >>>>> jdk.certpath.disabledAlgorithms property. >>>>> >>>>> I have modified an existing regression test to test this functionality >>>>> as there was no previous test for this feature. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170131 >>>>> >>>>> --Sean >>>> >>>> Is the reason the if() is needed is >>>> constraints.permit(CerttConstraintParameters) is not in the >>>> SSLAlgorithmConstraints class and the method exception is suppressed? >>> >>> SSLAlgorithmConstraints is not an instanceof >>> DisabledAlgorithmConstraints. When AlgorithmChecker.check is called, the >>> previous code (on line 329) would call >>> certPathDefaultConstraints.permits. This would pass, because the test >>> has configured jdk.certpath.disabledAlgorithms property to be empty. The >>> first time through, prevPubKey would also be null, so it would return on >>> line 335. It would never call SSLAlgorithmConstraints.permits. >>> >>> Does that make sense? >>> >>> --Sean >> >> >> Ok.. I see what's going on more.. I'm ok with this.. >> >> Tony >> From sean.mullan at oracle.com Fri Dec 2 16:45:56 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 2 Dec 2016 11:45:56 -0500 Subject: RFR: 8170131: Certificates not being blocked by jdk.tls.disabledAlgorithms property In-Reply-To: <1CBC80A2-2ED5-4084-84FE-89088CF30081@oracle.com> References: <58337894.4020600@oracle.com> <58346B9C.7040102@oracle.com> <4be92f37-0576-499f-f6f1-54d9f2b98fec@oracle.com> <1CBC80A2-2ED5-4084-84FE-89088CF30081@oracle.com> Message-ID: <3bb94cfe-90fc-a1a6-b8f3-53934d82125f@oracle.com> On 12/2/16 11:41 AM, Anthony Scarpino wrote: > It looks fine. One question, line 866 of the test you print the stacktrace on a success, was that intentional? No, good spot, it is leftover from debugging, I'll remove it before I push. --Sean > > Tony > >> On Dec 1, 2016, at 11:02 AM, Sean Mullan wrote: >> >> I enhanced the test case to test more scenarios where MD5 is either disabled via the jdk.tls.disabledAlgorithms or the jdk.certpath.disabledAlgorithms property. Please take another look and let me know if you are ok with it: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.01/ >> >> Thanks, >> Sean >> >>> On 11/22/16 11:00 AM, Anthony Scarpino wrote: >>>> On 11/22/2016 05:19 AM, Sean Mullan wrote: >>>>> On 11/21/16 5:43 PM, Anthony Scarpino wrote: >>>>>> On 11/21/2016 01:09 PM, Sean Mullan wrote: >>>>>> Please review this fix for a bug where certificates were not being >>>>>> blocked if the algorithm is only listed in the >>>>>> jdk.tls.disabledAlgorithms property and not the >>>>>> jdk.certpath.disabledAlgorithms property. >>>>>> >>>>>> I have modified an existing regression test to test this functionality >>>>>> as there was no previous test for this feature. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8170131/webrev.00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170131 >>>>>> >>>>>> --Sean >>>>> >>>>> Is the reason the if() is needed is >>>>> constraints.permit(CerttConstraintParameters) is not in the >>>>> SSLAlgorithmConstraints class and the method exception is suppressed? >>>> >>>> SSLAlgorithmConstraints is not an instanceof >>>> DisabledAlgorithmConstraints. When AlgorithmChecker.check is called, the >>>> previous code (on line 329) would call >>>> certPathDefaultConstraints.permits. This would pass, because the test >>>> has configured jdk.certpath.disabledAlgorithms property to be empty. The >>>> first time through, prevPubKey would also be null, so it would return on >>>> line 335. It would never call SSLAlgorithmConstraints.permits. >>>> >>>> Does that make sense? >>>> >>>> --Sean >>> >>> >>> Ok.. I see what's going on more.. I'm ok with this.. >>> >>> Tony >>> > From xuelei.fan at oracle.com Fri Dec 2 19:23:58 2016 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 2 Dec 2016 11:23:58 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> Message-ID: <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> On 11/29/2016 5:22 AM, Sean Mullan wrote: > On 11/27/16 7:43 AM, Xuelei Fan wrote: >> On 11/27/2016 6:04 PM, Wang Weijun wrote: >>> This is not only a test update. >>> >> No, I happened to find an implementation issue with the new test, so fix >> it altogether. The issue is that the simple validator >> (SimpleValidator.java) does not support SKID/AKID during cert path >> build. If two trusted certs has the same subject, the simple validator >> may not be able to find the right one. > > We have had issues in the PKIX CertPathBuilder with matching on > AKID/SKID when building certpaths, so we want to be careful not to > introduce a similar issue. See this bug for more information: > > https://bugs.openjdk.java.net/browse/JDK-8072463 > > I have not reviewed the fix enough to know if this issue applies here > but please double-check it. > The KID are used for best effort matching in this update. If no KIDs get matched, the previous behavior is reserved. Should be safe, I think. Xuelei > --Sean > >> >> Thanks, >> Xuelei >> >>>> On Nov 27, 2016, at 9:35 AM, Xuelei Fan wrote: >>>> >>>> Hi, >>>> >>>> Please review this test update: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/ >>>> >>>> The new template (SSLSocketTemplate.java) could be used to avoid the >>>> anti-free-port issues. By using sub-classes of it, the new one can >>>> simplify the general SSLSocket test code significantly. >>>> >>>> Thanks, >>>> Xuelei >>> From sean.mullan at oracle.com Fri Dec 2 21:02:08 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 2 Dec 2016 16:02:08 -0500 Subject: RFR[9] JDK-8170523: Some PKCS11 test cases are ignored with security manager In-Reply-To: <6c3ff553-9075-2a83-a42c-322e2ee2ff5a@oracle.com> References: <6c3ff553-9075-2a83-a42c-322e2ee2ff5a@oracle.com> Message-ID: <967faeb0-6d1d-878f-96c4-85a4140794d4@oracle.com> Hi John, I don't think we should modify the test to disable a SecurityManager and then reenable it to avoid a security check -- that seems like a pattern we should avoid. Have you tried to reorganize this code so that this setup is done before you initially enable the SecurityManager? Thanks, Sean On 12/1/16 10:32 PM, John Jiang wrote: > Hi, > Some PKCS11 tests call PKCS11Test.getDistro(), which run command "uname > -v", to determine the OS distro. > But if the tests enable security manager and don't grant appropriate > file permission, PKCS11Test.getDistro() fails to get the distro. > Then, the associated cases will be ignored since the tests think that > the OS is not the target. > > Webrev: http://cr.openjdk.java.net/~jjiang/8170523/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8170523 > > Best regards, > John Jiang > From artem.smotrakov at oracle.com Fri Dec 2 22:41:13 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 2 Dec 2016 14:41:13 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> Message-ID: <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> Hi Xuelei, I am not sure how the updates in SimpleValidator relate to the template for JSSE tests. It might be better to separate those changes if I am not missing something. This update in SimpleValidator looks okay to me, but taking into account Sean's comments below, I'll let someone who is more knowledgeable review it as well. I would prefer not to mix it with updates for SSLSocketTemplate. SSLSocketTemplate.java - Fields in ContextParameters can be final - Looks like JSSE test are supposed to extend SSLSocketTemplate. I suppose serverCondition/clientCondition should not be static then. Some JSSE test may be safely run in same JVM mode, I think it is better to make them non-static. - Why did you remove Peer and Application interfaces? I think those interfaces make SSLSocketTemplate more flexible since it allows override doServerSide/doClientSide logic if necessary - it doesn't seem to be worse. If there is no strong reason to remove those interfaces, I would prefer to keep them with default static/stateless doServerSide/doClientSide versions. - It may be better to pass a ContextParameters instance to createSSLContext() method because we may want to use more parameters while creating an SSL context. It also might make sense to make createSSLContext() a part of public API which I think would make the template more flexible. - Exceptions are printed out in startServer/startClient methods, it doesn't look necessary to use suppressed exceptions and initCause() method. What was wrong with the code in runTest() method? The code in runTest() method looks shorter and cleaner to me. ProxyAuthTest.java - line 153, I believe try-with-resources doesn't make it worse. - lines 114-123, this code is used quite often by tests, why don't we keep it in SSLSocketTemplate? Artem On 12/02/2016 11:23 AM, Xue-Lei Fan wrote: > On 11/29/2016 5:22 AM, Sean Mullan wrote: >> On 11/27/16 7:43 AM, Xuelei Fan wrote: >>> On 11/27/2016 6:04 PM, Wang Weijun wrote: >>>> This is not only a test update. >>>> >>> No, I happened to find an implementation issue with the new test, so >>> fix >>> it altogether. The issue is that the simple validator >>> (SimpleValidator.java) does not support SKID/AKID during cert path >>> build. If two trusted certs has the same subject, the simple >>> validator >>> may not be able to find the right one. >> >> We have had issues in the PKIX CertPathBuilder with matching on >> AKID/SKID when building certpaths, so we want to be careful not to >> introduce a similar issue. See this bug for more information: >> >> https://bugs.openjdk.java.net/browse/JDK-8072463 >> >> I have not reviewed the fix enough to know if this issue applies here >> but please double-check it. >> > The KID are used for best effort matching in this update. If no KIDs > get matched, the previous behavior is reserved. Should be safe, I think. > > Xuelei > >> --Sean >> >>> >>> Thanks, >>> Xuelei >>> >>>>> On Nov 27, 2016, at 9:35 AM, Xuelei Fan >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review this test update: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/ >>>>> >>>>> The new template (SSLSocketTemplate.java) could be used to avoid the >>>>> anti-free-port issues. By using sub-classes of it, the new one can >>>>> simplify the general SSLSocket test code significantly. >>>>> >>>>> Thanks, >>>>> Xuelei >>>> From xuelei.fan at oracle.com Fri Dec 2 22:41:36 2016 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 2 Dec 2016 14:41:36 -0800 Subject: [9] RFR: JDK-8170245 [TEST_BUG] Cipher tests fail when running with unlimited policy In-Reply-To: <904f38dc-f9bd-c392-7a9e-00b8d0b19ef8@oracle.com> References: <904f38dc-f9bd-c392-7a9e-00b8d0b19ef8@oracle.com> Message-ID: The update looks fine to me. Xuelei On 11/29/2016 4:58 PM, Valerie Peng wrote: > > Anyone has cycles to review this fix? > Some cipher tests fail when running against unlimited crypto policy due > to hardcoded checks and values. > > Changes are straight-forward. However, given the dependency between the > tests (as they are ported from SQE tests in the previous co-location > effort), I mostly just made the minimum changes needed for the test to > work when unlimited crypto policy is in use. > > Webrev: http://cr.openjdk.java.net/~valeriep/8170245/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170245 > > Thanks, > Valerie From bradford.wetmore at oracle.com Fri Dec 2 23:50:04 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 2 Dec 2016 15:50:04 -0800 Subject: RFR: 8170157/8169335: Unlimited Cryptography Policy Changes Message-ID: <680b5894-2ee1-dbdf-9f76-4140c1594fc3@oracle.com> Hi, I need reviewers for these related bugs: https://bugs.openjdk.java.net/browse/JDK-8170157 Enable unlimited cryptographic policy by default in OracleJDK https://bugs.openjdk.java.net/browse/JDK-8169335 Add a crypto policy fallback in case Security Property 'crypto.policy' does not exist http://cr.openjdk.java.net/~wetmore/8170157 This change enables "unlimited" cryptographic policy by default in the OpenJDK/OracleJDK builds. For those who still require the classic limited policy bundles, you will now need to use the following "configure" option: --enable-unlimited-crypto There are still distributions that require crypto policy, so simply removing that code is not an option, sorry! Brad From xuelei.fan at oracle.com Fri Dec 2 23:53:40 2016 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 2 Dec 2016 15:53:40 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> Message-ID: <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> Thanks for the review, Artem. On 12/2/2016 2:41 PM, Artem Smotrakov wrote: > Hi Xuelei, > > I am not sure how the updates in SimpleValidator relate to the template > for JSSE tests. The certificates generated for the template have the same subject and issuer for RSA, DSA and EC algorithms. If using the SimpleValidator, it cannot find the right root cert for a particular end entity certificate any more. The issue is not exposed in the past because the certs in etc directory are self-signed and version 1 certificates. It's not common to use version 1 and self-signed certs for general JSSE testing, so I move to version 3 and use end entity certificate for authentication in this update. > It might be better to separate those changes if I am not > missing something. This update in SimpleValidator looks okay to me, but > taking into account Sean's comments below, I'll let someone who is more > knowledgeable review it as well. I would prefer not to mix it with > updates for SSLSocketTemplate. > It saves time and easier to backport if using one bug. I'm OK to fix them separately. Let's whether Sean or Weijun can have free cycle for the review of this part. > SSLSocketTemplate.java > > - Fields in ContextParameters can be final Good suggestion! > - Looks like JSSE test are supposed to extend SSLSocketTemplate. I > suppose serverCondition/clientCondition should not be static then. Some > JSSE test may be safely run in same JVM mode, I think it is better to > make them non-static. Good catch! > - Why did you remove Peer and Application interfaces? I think those > interfaces make SSLSocketTemplate more flexible since it allows override > doServerSide/doClientSide logic if necessary - it doesn't seem to be > worse. If there is no strong reason to remove those interfaces, I would > prefer to keep them with default static/stateless > doServerSide/doClientSide versions. I agree with you that The Peer and Application interfaces are more flexible. I have no strong reason to remove them. For this update, I focus more on simple and minimal sub-classes. The Peer and Application interfaces need some complicated coding (condition, threading, etc) in sub-classes, so the design does not fall into the scope. I may prefer to remove them at this update and see what happens if we moving forward with more test update. We can add them back or create a more flexible one if we need the flexibility in the future. > - It may be better to pass a ContextParameters instance to > createSSLContext() method because we may want to use more parameters > while creating an SSL context. Yes. > It also might make sense to make > createSSLContext() a part of public API which I think would make the > template more flexible. We have had the protected createClient/ServerSSLContext() methods. > - Exceptions are printed out in startServer/startClient methods, it > doesn't look necessary to use suppressed exceptions and initCause() > method. What was wrong with the code in runTest() method? The code in > runTest() method looks shorter and cleaner to me. > The main issue of runTest() is that it does not throw the original exception. Exception tacks have more information for debugging. I want to keep the good side of Brad's previous hardness on this point. > ProxyAuthTest.java > > - line 153, I believe try-with-resources doesn't make it worse. Right. > - lines 114-123, this code is used quite often by tests, why don't we > keep it in SSLSocketTemplate? > Good point! I don't like it in SSLSocketTemplate as it is used for HTTP connections only, but it may be worthy to have a sub-template for HTTPS client testing. What do you think if we address this enhancement in a new bug? Thanks, Xuelei > Artem > > On 12/02/2016 11:23 AM, Xue-Lei Fan wrote: >> On 11/29/2016 5:22 AM, Sean Mullan wrote: >>> On 11/27/16 7:43 AM, Xuelei Fan wrote: >>>> On 11/27/2016 6:04 PM, Wang Weijun wrote: >>>>> This is not only a test update. >>>>> >>>> No, I happened to find an implementation issue with the new test, so >>>> fix >>>> it altogether. The issue is that the simple validator >>>> (SimpleValidator.java) does not support SKID/AKID during cert path >>>> build. If two trusted certs has the same subject, the simple >>>> validator >>>> may not be able to find the right one. >>> >>> We have had issues in the PKIX CertPathBuilder with matching on >>> AKID/SKID when building certpaths, so we want to be careful not to >>> introduce a similar issue. See this bug for more information: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8072463 >>> >>> I have not reviewed the fix enough to know if this issue applies here >>> but please double-check it. >>> >> The KID are used for best effort matching in this update. If no KIDs >> get matched, the previous behavior is reserved. Should be safe, I think. >> >> Xuelei >> >>> --Sean >>> >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>>> On Nov 27, 2016, at 9:35 AM, Xuelei Fan >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review this test update: >>>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8170329/webrev.00/ >>>>>> >>>>>> The new template (SSLSocketTemplate.java) could be used to avoid the >>>>>> anti-free-port issues. By using sub-classes of it, the new one can >>>>>> simplify the general SSLSocket test code significantly. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>> > From artem.smotrakov at oracle.com Sat Dec 3 00:34:32 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 2 Dec 2016 16:34:32 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> Message-ID: <2e55dc8a-30fd-8861-987d-bd8d21c5fe81@oracle.com> Hi Xuelei, Please see inline. On 12/02/2016 03:53 PM, Xue-Lei Fan wrote: >> Let's whether Sean or Weijun can have free cycle for the review of >> this part. Yeah, that would be great. > >> - Why did you remove Peer and Application interfaces? I think those >> interfaces make SSLSocketTemplate more flexible since it allows override >> doServerSide/doClientSide logic if necessary - it doesn't seem to be >> worse. If there is no strong reason to remove those interfaces, I would >> prefer to keep them with default static/stateless >> doServerSide/doClientSide versions. > I agree with you that The Peer and Application interfaces are more > flexible. I have no strong reason to remove them. For this update, I > focus more on simple and minimal sub-classes. The Peer and > Application interfaces need some complicated coding (condition, > threading, etc) in sub-classes, so the design does not fall into the > scope. I may prefer to remove them at this update and see what > happens if we moving forward with more test update. We can add them > back or create a more flexible one if we need the flexibility in the > future. We have a lot of JSSE tests which may need to do something else in doServerSide() and doClientSide() methods (that's what I learned from my experience working with JSSE tests). Peer and Application interfaces basically allow to override doServerSide() and doClientSide() methods. Your changes make doServerSide() and doClientSide() methods private, so that test can't add something inside it. If you think those interfaces are helpful, I think it's better to keep Peer and Application interfaces instead of removing/adding them back and forth. Another option may be providing methods which are called in doServerSide() and doClientSide(). Those methods may be overridden by a test if it needs to do extra stuff inside doServerSide() and doClientSide(). I am fine with both ways, so it's up to you. But I would like to make it clear what way we want to follow. What do you think? > >> It also might make sense to make >> createSSLContext() a part of public API which I think would make the >> template more flexible. > We have had the protected createClient/ServerSSLContext() methods. Making createSSLContext() accessible doesn't seem to be worse to me. It may be final if you don't want anyone to override it for some reason. > >> - Exceptions are printed out in startServer/startClient methods, it >> doesn't look necessary to use suppressed exceptions and initCause() >> method. What was wrong with the code in runTest() method? The code in >> runTest() method looks shorter and cleaner to me. >> > The main issue of runTest() is that it does not throw the original > exception. Exception tacks have more information for debugging. I > want to keep the good side of Brad's previous hardness on this point. It is not clear what's the original exception should be because you have client and server. If you print all exceptions in startServer/startClient (right after they occurred), then you don't hide anything helpful for debugging. IMO, suppressed exceptions may confuse here (that's just from my experience looking at JSSE test logs). The logic in lines 739-763 doesn't make it cleaner what exception was thrown on what side. It does "local.initCause(remote)", but actually "remote" is not a cause of "local". Finally, it does "exception.addSuppressed(startException)" where "startException" can be thrown either on server or client side which actually depends on test logic (an engineer needs to keep it in mind). Would it be better to have in logs something simple like the following? .... This is an unexpected exception on client side: This is an unexpected exception on server side: Test failed. ... Doesn't it look simpler? > >> - lines 114-123, this code is used quite often by tests, why don't we >> keep it in SSLSocketTemplate? >> > Good point! I don't like it in SSLSocketTemplate as it is used for > HTTP connections only, but it may be worthy to have a sub-template for > HTTPS client testing. What do you think if we address this > enhancement in a new bug? I am fine with it. My point is that SSLSocketTemplate may contain some useful static methods like this (to avoid duplicate code). Artem From xuelei.fan at oracle.com Sat Dec 3 01:25:09 2016 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 2 Dec 2016 17:25:09 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <2e55dc8a-30fd-8861-987d-bd8d21c5fe81@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> <2e55dc8a-30fd-8861-987d-bd8d21c5fe81@oracle.com> Message-ID: On 12/2/2016 4:34 PM, Artem Smotrakov wrote: > Hi Xuelei, > > Please see inline. > > On 12/02/2016 03:53 PM, Xue-Lei Fan wrote: >>> Let's whether Sean or Weijun can have free cycle for the review of >>> this part. > Yeah, that would be great. >> >>> - Why did you remove Peer and Application interfaces? I think those >>> interfaces make SSLSocketTemplate more flexible since it allows override >>> doServerSide/doClientSide logic if necessary - it doesn't seem to be >>> worse. If there is no strong reason to remove those interfaces, I would >>> prefer to keep them with default static/stateless >>> doServerSide/doClientSide versions. >> I agree with you that The Peer and Application interfaces are more >> flexible. I have no strong reason to remove them. For this update, I >> focus more on simple and minimal sub-classes. The Peer and >> Application interfaces need some complicated coding (condition, >> threading, etc) in sub-classes, so the design does not fall into the >> scope. I may prefer to remove them at this update and see what >> happens if we moving forward with more test update. We can add them >> back or create a more flexible one if we need the flexibility in the >> future. > We have a lot of JSSE tests which may need to do something else in > doServerSide() and doClientSide() methods (that's what I learned from my > experience working with JSSE tests). Peer and Application interfaces > basically allow to override doServerSide() and doClientSide() methods. > Your changes make doServerSide() and doClientSide() methods private, so > that test can't add something inside it. > > If you think those interfaces are helpful, I think it's better to keep > Peer and Application interfaces instead of removing/adding them back and > forth. > > Another option may be providing methods which are called in > doServerSide() and doClientSide(). Those methods may be overridden by a > test if it needs to do extra stuff inside doServerSide() and > doClientSide(). > > I am fine with both ways, so it's up to you. But I would like to make it > clear what way we want to follow. > > What do you think? You points above are good. When I made the update, I struggled a lot about the balance of flexible and simplicity. I was inclined to simplicity at last as we can update the template if any new feature is required in the future. I'm not sure how much this template can be used, exposing as less methods as possible will give us more flexible to make further update. So I made most of the methods private, and removed a lot of methods. Let's update the access scope if we really need them in the future. A small public footprint is easier to start. >> >>> It also might make sense to make >>> createSSLContext() a part of public API which I think would make the >>> template more flexible. >> We have had the protected createClient/ServerSSLContext() methods. > Making createSSLContext() accessible doesn't seem to be worse to me. It > may be final if you don't want anyone to override it for some reason. >> >>> - Exceptions are printed out in startServer/startClient methods, it >>> doesn't look necessary to use suppressed exceptions and initCause() >>> method. What was wrong with the code in runTest() method? The code in >>> runTest() method looks shorter and cleaner to me. >>> >> The main issue of runTest() is that it does not throw the original >> exception. Exception tacks have more information for debugging. I >> want to keep the good side of Brad's previous hardness on this point. > It is not clear what's the original exception should be because you have > client and server. If you print all exceptions in > startServer/startClient (right after they occurred), then you don't hide > anything helpful for debugging. > The exception dump may have more information than the single exception track, for example the nested cause stacks. The original exception handling was very simple, and a lot improvements were made so that the log is easier for debugging. > IMO, suppressed exceptions may confuse here (that's just from my > experience looking at JSSE test logs). The logic in lines 739-763 > doesn't make it cleaner what exception was thrown on what side. It does > "local.initCause(remote)", but actually "remote" is not a cause of > "local". Finally, it does "exception.addSuppressed(startException)" > where "startException" can be thrown either on server or client side > which actually depends on test logic (an engineer needs to keep it in > mind). > > Would it be better to have in logs something simple like the following? > > .... > This is an unexpected exception on client side: > > This is an unexpected exception on server side: > > Test failed. > ... > > Doesn't it look simpler? The purpose of suppressed exception is fully use of the exception for debugging. The above suggestion still lose some exception debugging information. I dumped the exception message (line 808/818), hopefully it can help a little bit if confusing. It's good suggestion that we'd better to tell which side (the client or server side) throws the exception. I will think more about it in the next webrev update. >> >>> - lines 114-123, this code is used quite often by tests, why don't we >>> keep it in SSLSocketTemplate? >>> >> Good point! I don't like it in SSLSocketTemplate as it is used for >> HTTP connections only, but it may be worthy to have a sub-template for >> HTTPS client testing. What do you think if we address this >> enhancement in a new bug? > I am fine with it. My point is that SSLSocketTemplate may contain some > useful static methods like this (to avoid duplicate code). > I see. I will consider it more in the next webrev. Thanks, Xuelei From artem.smotrakov at oracle.com Sat Dec 3 01:53:25 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 2 Dec 2016 17:53:25 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> <2e55dc8a-30fd-8861-987d-bd8d21c5fe81@oracle.com> Message-ID: Please see inline On 12/02/2016 05:25 PM, Xue-Lei Fan wrote: >>> >>>> - Why did you remove Peer and Application interfaces? I think those >>>> interfaces make SSLSocketTemplate more flexible since it allows >>>> override >>>> doServerSide/doClientSide logic if necessary - it doesn't seem to be >>>> worse. If there is no strong reason to remove those interfaces, I >>>> would >>>> prefer to keep them with default static/stateless >>>> doServerSide/doClientSide versions. >>> I agree with you that The Peer and Application interfaces are more >>> flexible. I have no strong reason to remove them. For this update, I >>> focus more on simple and minimal sub-classes. The Peer and >>> Application interfaces need some complicated coding (condition, >>> threading, etc) in sub-classes, so the design does not fall into the >>> scope. I may prefer to remove them at this update and see what >>> happens if we moving forward with more test update. We can add them >>> back or create a more flexible one if we need the flexibility in the >>> future. >> We have a lot of JSSE tests which may need to do something else in >> doServerSide() and doClientSide() methods (that's what I learned from my >> experience working with JSSE tests). Peer and Application interfaces >> basically allow to override doServerSide() and doClientSide() methods. >> Your changes make doServerSide() and doClientSide() methods private, so >> that test can't add something inside it. >> >> If you think those interfaces are helpful, I think it's better to keep >> Peer and Application interfaces instead of removing/adding them back and >> forth. >> >> Another option may be providing methods which are called in >> doServerSide() and doClientSide(). Those methods may be overridden by a >> test if it needs to do extra stuff inside doServerSide() and >> doClientSide(). >> >> I am fine with both ways, so it's up to you. But I would like to make it >> clear what way we want to follow. >> >> What do you think? > You points above are good. When I made the update, I struggled a lot > about the balance of flexible and simplicity. I was inclined to > simplicity at last as we can update the template if any new feature is > required in the future. I'm not sure how much this template can be used, I suspect that all JSSE tests should be updated to use this template to avoid intermittent failures which we have been seeing. > exposing as less methods as possible will give us more flexible to > make further update. So I made most of the methods private, and > removed a lot of methods. Let's update the access scope if we really > need them in the future. A small public footprint is easier to start. We already started a while ago :) Those methods which you removed were actually used by other tests which you updated. My point is that we'd better understand how we want the tests to be organized to avoid adding/removing stuff back and forth. Again, I believe that lots of tests should be updated to use this template. I am not suggesting to predict everything that the tests may need right away. If you think that Peer and Application interfaces are not good enough, it's fine to me, but we need to understand what would be a replacement for them >>>> - Exceptions are printed out in startServer/startClient methods, it >>>> doesn't look necessary to use suppressed exceptions and initCause() >>>> method. What was wrong with the code in runTest() method? The code in >>>> runTest() method looks shorter and cleaner to me. >>>> >>> The main issue of runTest() is that it does not throw the original >>> exception. Exception tacks have more information for debugging. I >>> want to keep the good side of Brad's previous hardness on this point. >> It is not clear what's the original exception should be because you have >> client and server. If you print all exceptions in >> startServer/startClient (right after they occurred), then you don't hide >> anything helpful for debugging. >> > The exception dump may have more information than the single exception > track, for example the nested cause stacks. Can't it be printed out in startServer/startClient accordingly? > The original exception handling was very simple, and a lot > improvements were made so that the log is easier for debugging. > >> IMO, suppressed exceptions may confuse here (that's just from my >> experience looking at JSSE test logs). The logic in lines 739-763 >> doesn't make it cleaner what exception was thrown on what side. It does >> "local.initCause(remote)", but actually "remote" is not a cause of >> "local". Finally, it does "exception.addSuppressed(startException)" >> where "startException" can be thrown either on server or client side >> which actually depends on test logic (an engineer needs to keep it in >> mind). >> >> Would it be better to have in logs something simple like the following? >> >> .... >> This is an unexpected exception on client side: >> >> This is an unexpected exception on server side: >> >> Test failed. >> ... >> >> Doesn't it look simpler? > The purpose of suppressed exception is fully use of the exception for > debugging. The above suggestion still lose some exception debugging > information. What kind of information is lost if you don't use suppressed exceptions? "startException" can be printed out right away when it occurs which I think would be cleaner. > I dumped the exception message (line 808/818), hopefully it can help a > little bit if confusing. I believe this is right place to dump everything out. It just needs to make sure that it exceptions traces from server/client sides don't mix up, so may be it's better to add some synchronization on System.out like it was done in print() method. > > It's good suggestion that we'd better to tell which side (the client > or server side) throws the exception. I will think more about it in > the next webrev update. Sure, thank you. Artem From xuelei.fan at oracle.com Sat Dec 3 05:48:59 2016 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 2 Dec 2016 21:48:59 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> <2e55dc8a-30fd-8861-987d-bd8d21c5fe81@oracle.com> Message-ID: <1c34313c-9b42-9afc-1c2d-fe3c33b3bc69@oracle.com> On 12/2/2016 5:53 PM, Artem Smotrakov wrote: > Please see inline > > > On 12/02/2016 05:25 PM, Xue-Lei Fan wrote: >>>> >>>>> - Why did you remove Peer and Application interfaces? I think those >>>>> interfaces make SSLSocketTemplate more flexible since it allows >>>>> override >>>>> doServerSide/doClientSide logic if necessary - it doesn't seem to be >>>>> worse. If there is no strong reason to remove those interfaces, I >>>>> would >>>>> prefer to keep them with default static/stateless >>>>> doServerSide/doClientSide versions. >>>> I agree with you that The Peer and Application interfaces are more >>>> flexible. I have no strong reason to remove them. For this update, I >>>> focus more on simple and minimal sub-classes. The Peer and >>>> Application interfaces need some complicated coding (condition, >>>> threading, etc) in sub-classes, so the design does not fall into the >>>> scope. I may prefer to remove them at this update and see what >>>> happens if we moving forward with more test update. We can add them >>>> back or create a more flexible one if we need the flexibility in the >>>> future. >>> We have a lot of JSSE tests which may need to do something else in >>> doServerSide() and doClientSide() methods (that's what I learned from my >>> experience working with JSSE tests). Peer and Application interfaces >>> basically allow to override doServerSide() and doClientSide() methods. >>> Your changes make doServerSide() and doClientSide() methods private, so >>> that test can't add something inside it. >>> >>> If you think those interfaces are helpful, I think it's better to keep >>> Peer and Application interfaces instead of removing/adding them back and >>> forth. >>> >>> Another option may be providing methods which are called in >>> doServerSide() and doClientSide(). Those methods may be overridden by a >>> test if it needs to do extra stuff inside doServerSide() and >>> doClientSide(). >>> >>> I am fine with both ways, so it's up to you. But I would like to make it >>> clear what way we want to follow. >>> >>> What do you think? >> You points above are good. When I made the update, I struggled a lot >> about the balance of flexible and simplicity. I was inclined to >> simplicity at last as we can update the template if any new feature is >> required in the future. I'm not sure how much this template can be used, > I suspect that all JSSE tests should be updated to use this template to > avoid intermittent failures which we have been seeing. IHMO, I was not that optimistic. >> exposing as less methods as possible will give us more flexible to >> make further update. So I made most of the methods private, and >> removed a lot of methods. Let's update the access scope if we really >> need them in the future. A small public footprint is easier to start. > We already started a while ago :) Those methods which you removed were > actually used by other tests which you updated. No, none of them are used any more. > My point is that we'd > better understand how we want the tests to be organized to avoid > adding/removing stuff back and forth. Sure, it's the job of the update. I see no need of those methods any more unless there are really needed in the future. > Again, I believe that lots of > tests should be updated to use this template. I am not suggesting to > predict everything that the tests may need right away. If you think that > Peer and Application interfaces are not good enough, it's fine to me, > but we need to understand what would be a replacement for them I think we don't need those methods at present. We may need some of them in the future, but I see no strong reason to keep them at present. >>>>> - Exceptions are printed out in startServer/startClient methods, it >>>>> doesn't look necessary to use suppressed exceptions and initCause() >>>>> method. What was wrong with the code in runTest() method? The code in >>>>> runTest() method looks shorter and cleaner to me. >>>>> >>>> The main issue of runTest() is that it does not throw the original >>>> exception. Exception tacks have more information for debugging. I >>>> want to keep the good side of Brad's previous hardness on this point. >>> It is not clear what's the original exception should be because you have >>> client and server. If you print all exceptions in >>> startServer/startClient (right after they occurred), then you don't hide >>> anything helpful for debugging. >>> >> The exception dump may have more information than the single exception >> track, for example the nested cause stacks. > Can't it be printed out in startServer/startClient accordingly? Throw the right exception is important even for test case. Having the Java handling the exception is more nature. Reading the debug log dump is not as straightforward as read the exception at the end of each run. Wrapping into RuntimeException is very confusing sometimes. Comparing the following two log: java.net.XXException: this is an exception message. cased by A caused by B. and java.lang.RuntimeException: xxxx caused by java.net.XXException: this is an exception message. caused by A. (cause by B may be swallowed) I don't like the later one, which introduce unnecessary exception stacks and take more time for the debugging. >> The original exception handling was very simple, and a lot >> improvements were made so that the log is easier for debugging. >> >>> IMO, suppressed exceptions may confuse here (that's just from my >>> experience looking at JSSE test logs). The logic in lines 739-763 >>> doesn't make it cleaner what exception was thrown on what side. It does >>> "local.initCause(remote)", but actually "remote" is not a cause of >>> "local". Finally, it does "exception.addSuppressed(startException)" >>> where "startException" can be thrown either on server or client side >>> which actually depends on test logic (an engineer needs to keep it in >>> mind). >>> >>> Would it be better to have in logs something simple like the following? >>> >>> .... >>> This is an unexpected exception on client side: >>> >>> This is an unexpected exception on server side: >>> >>> Test failed. >>> ... >>> >>> Doesn't it look simpler? >> The purpose of suppressed exception is fully use of the exception for >> debugging. The above suggestion still lose some exception debugging >> information. > What kind of information is lost if you don't use suppressed exceptions? > Deep causes of the exception, and the nature about how an java command dump the exception. We have to research what kind of information may be lost here. I don't want that kind of research and using the nature of the exception is easier to me. > "startException" can be printed out right away when it occurs which I > think would be cleaner. >> I dumped the exception message (line 808/818), hopefully it can help a >> little bit if confusing. > I believe this is right place to dump everything out. ;-) I don't think so. Thanks for the review. Xuelei > It just needs to > make sure that it exceptions traces from server/client sides don't mix > up, so may be it's better to add some synchronization on System.out like > it was done in print() method. >> >> It's good suggestion that we'd better to tell which side (the client >> or server side) throws the exception. I will think more about it in >> the next webrev update. > Sure, thank you. > > Artem > From sha.jiang at oracle.com Mon Dec 5 02:29:31 2016 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 5 Dec 2016 10:29:31 +0800 Subject: RFR[9] JDK-8170523: Some PKCS11 test cases are ignored with security manager In-Reply-To: <967faeb0-6d1d-878f-96c4-85a4140794d4@oracle.com> References: <6c3ff553-9075-2a83-a42c-322e2ee2ff5a@oracle.com> <967faeb0-6d1d-878f-96c4-85a4140794d4@oracle.com> Message-ID: <91c4693e-2ff9-0090-84e5-68e8a394876f@oracle.com> Hi Sean, Thanks for your comments. Please take a look at the new wevrev: http://cr.openjdk.java.net/~jjiang/8170523/webrev.01/ Best regards, John Jiang On 2016/12/3 5:02, Sean Mullan wrote: > Hi John, > > I don't think we should modify the test to disable a SecurityManager > and then reenable it to avoid a security check -- that seems like a > pattern we should avoid. Have you tried to reorganize this code so > that this setup is done before you initially enable the SecurityManager? > > Thanks, > Sean > > On 12/1/16 10:32 PM, John Jiang wrote: >> Hi, >> Some PKCS11 tests call PKCS11Test.getDistro(), which run command "uname >> -v", to determine the OS distro. >> But if the tests enable security manager and don't grant appropriate >> file permission, PKCS11Test.getDistro() fails to get the distro. >> Then, the associated cases will be ignored since the tests think that >> the OS is not the target. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8170523/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8170523 >> >> Best regards, >> John Jiang >> > From erik.joelsson at oracle.com Mon Dec 5 08:36:34 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Dec 2016 09:36:34 +0100 Subject: RFR: 8170157/8169335: Unlimited Cryptography Policy Changes In-Reply-To: <680b5894-2ee1-dbdf-9f76-4140c1594fc3@oracle.com> References: <680b5894-2ee1-dbdf-9f76-4140c1594fc3@oracle.com> Message-ID: <177d572b-8194-7af9-c693-d62f46c0993b@oracle.com> Looks good. /Erik On 2016-12-03 00:50, Bradford Wetmore wrote: > > Hi, > > I need reviewers for these related bugs: > > https://bugs.openjdk.java.net/browse/JDK-8170157 > Enable unlimited cryptographic policy by default in OracleJDK > > https://bugs.openjdk.java.net/browse/JDK-8169335 > Add a crypto policy fallback in case Security Property > 'crypto.policy' does not exist > > http://cr.openjdk.java.net/~wetmore/8170157 > > This change enables "unlimited" cryptographic policy by default in the > OpenJDK/OracleJDK builds. > > For those who still require the classic limited policy bundles, you > will now need to use the following "configure" option: > > --enable-unlimited-crypto > > There are still distributions that require crypto policy, so simply > removing that code is not an option, sorry! > > Brad From sean.coffey at oracle.com Mon Dec 5 14:57:01 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 5 Dec 2016 14:57:01 +0000 Subject: RFR: 8170157/8169335: Unlimited Cryptography Policy Changes In-Reply-To: <680b5894-2ee1-dbdf-9f76-4140c1594fc3@oracle.com> References: <680b5894-2ee1-dbdf-9f76-4140c1594fc3@oracle.com> Message-ID: <5845803D.6010504@oracle.com> looks good. You'll need to run the new CryptoPolicyFallback.java testcase in othervm mode. Regards, Sean. On 02/12/16 23:50, Bradford Wetmore wrote: > > Hi, > > I need reviewers for these related bugs: > > https://bugs.openjdk.java.net/browse/JDK-8170157 > Enable unlimited cryptographic policy by default in OracleJDK > > https://bugs.openjdk.java.net/browse/JDK-8169335 > Add a crypto policy fallback in case Security Property > 'crypto.policy' does not exist > > http://cr.openjdk.java.net/~wetmore/8170157 > > This change enables "unlimited" cryptographic policy by default in the > OpenJDK/OracleJDK builds. > > For those who still require the classic limited policy bundles, you > will now need to use the following "configure" option: > > --enable-unlimited-crypto > > There are still distributions that require crypto policy, so simply > removing that code is not an option, sorry! > > Brad From artem.smotrakov at oracle.com Mon Dec 5 18:16:16 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 5 Dec 2016 10:16:16 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <1c34313c-9b42-9afc-1c2d-fe3c33b3bc69@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> <2e55dc8a-30fd-8861-987d-bd8d21c5fe81@oracle.com> <1c34313c-9b42-9afc-1c2d-fe3c33b3bc69@oracle.com> Message-ID: <2e4a551c-a4de-4ec6-4cb5-bacd8246bce9@oracle.com> Hi Xuelei, Please see inline. On 12/02/2016 09:48 PM, Xue-Lei Fan wrote: > >>>>>> - Exceptions are printed out in startServer/startClient methods, it >>>>>> doesn't look necessary to use suppressed exceptions and initCause() >>>>>> method. What was wrong with the code in runTest() method? The >>>>>> code in >>>>>> runTest() method looks shorter and cleaner to me. >>>>>> >>>>> The main issue of runTest() is that it does not throw the original >>>>> exception. Exception tacks have more information for debugging. I >>>>> want to keep the good side of Brad's previous hardness on this point. >>>> It is not clear what's the original exception should be because you >>>> have >>>> client and server. If you print all exceptions in >>>> startServer/startClient (right after they occurred), then you don't >>>> hide >>>> anything helpful for debugging. >>>> >>> The exception dump may have more information than the single exception >>> track, for example the nested cause stacks. >> Can't it be printed out in startServer/startClient accordingly? > Throw the right exception is important even for test case. Having the > Java handling the exception is more nature. Reading the debug log > dump is not as straightforward as read the exception at the end of > each run. Wrapping into RuntimeException is very confusing sometimes. > > Comparing the following two log: > java.net.XXException: this is an exception message. > cased by A > caused by B. > and > java.lang.RuntimeException: xxxx > caused by java.net.XXException: this is an exception message. > caused by A. > (cause by B may be swallowed) > > I don't like the later one, which introduce unnecessary exception > stacks and take more time for the debugging. I am not suggesting neither #2. I am suggesting not to use initCause because it modifies the original exception, and not to use addSupressed() because it's not clear where the suppressed exception came from. Instead, I am suggesting to print all original exceptions on that sides where they occurred. I am not suggesting to wrap anything into a runtime exception. A runtime exception can be used just to indicate a test failure. > >>> The original exception handling was very simple, and a lot >>> improvements were made so that the log is easier for debugging. >>> >>>> IMO, suppressed exceptions may confuse here (that's just from my >>>> experience looking at JSSE test logs). The logic in lines 739-763 >>>> doesn't make it cleaner what exception was thrown on what side. It >>>> does >>>> "local.initCause(remote)", but actually "remote" is not a cause of >>>> "local". Finally, it does "exception.addSuppressed(startException)" >>>> where "startException" can be thrown either on server or client side >>>> which actually depends on test logic (an engineer needs to keep it in >>>> mind). >>>> >>>> Would it be better to have in logs something simple like the >>>> following? >>>> >>>> .... >>>> This is an unexpected exception on client side: >>>> >>>> This is an unexpected exception on server side: >>>> >>>> Test failed. >>>> ... >>>> >>>> Doesn't it look simpler? >>> The purpose of suppressed exception is fully use of the exception for >>> debugging. The above suggestion still lose some exception debugging >>> information. >> What kind of information is lost if you don't use suppressed exceptions? >> > Deep causes of the exception, and the nature about how an java command > dump the exception. We have to research what kind of information may > be lost here. I don't want that kind of research and using the nature > of the exception is easier to me. I don't think that anything is going to be lost if you just print an exception right away. Artem > >> "startException" can be printed out right away when it occurs which I >> think would be cleaner. >>> I dumped the exception message (line 808/818), hopefully it can help a >>> little bit if confusing. >> I believe this is right place to dump everything out. > ;-) I don't think so. > > Thanks for the review. > > Xuelei > >> It just needs to >> make sure that it exceptions traces from server/client sides don't mix >> up, so may be it's better to add some synchronization on System.out like >> it was done in print() method. >>> >>> It's good suggestion that we'd better to tell which side (the client >>> or server side) throws the exception. I will think more about it in >>> the next webrev update. >> Sure, thank you. >> >> Artem >> From sean.mullan at oracle.com Mon Dec 5 18:27:12 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 5 Dec 2016 13:27:12 -0500 Subject: RFR[9] JDK-8170523: Some PKCS11 test cases are ignored with security manager In-Reply-To: <91c4693e-2ff9-0090-84e5-68e8a394876f@oracle.com> References: <6c3ff553-9075-2a83-a42c-322e2ee2ff5a@oracle.com> <967faeb0-6d1d-878f-96c4-85a4140794d4@oracle.com> <91c4693e-2ff9-0090-84e5-68e8a394876f@oracle.com> Message-ID: <09d85fbc-2b4a-6398-be08-86eb5d80a560@oracle.com> Looks good, but don't forget to add a noreg-self label to the bug. --Sean On 12/4/16 9:29 PM, John Jiang wrote: > Hi Sean, > Thanks for your comments. > Please take a look at the new wevrev: > http://cr.openjdk.java.net/~jjiang/8170523/webrev.01/ > > Best regards, > John Jiang > > > On 2016/12/3 5:02, Sean Mullan wrote: >> Hi John, >> >> I don't think we should modify the test to disable a SecurityManager >> and then reenable it to avoid a security check -- that seems like a >> pattern we should avoid. Have you tried to reorganize this code so >> that this setup is done before you initially enable the SecurityManager? >> >> Thanks, >> Sean >> >> On 12/1/16 10:32 PM, John Jiang wrote: >>> Hi, >>> Some PKCS11 tests call PKCS11Test.getDistro(), which run command "uname >>> -v", to determine the OS distro. >>> But if the tests enable security manager and don't grant appropriate >>> file permission, PKCS11Test.getDistro() fails to get the distro. >>> Then, the associated cases will be ignored since the tests think that >>> the OS is not the target. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8170523/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8170523 >>> >>> Best regards, >>> John Jiang >>> >> > From artem.smotrakov at oracle.com Mon Dec 5 18:55:35 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 5 Dec 2016 10:55:35 -0800 Subject: [9] RFR JDK-8157529 : Remove intermittent key from javax/net/ssl/DTLS/CipherSuite.java In-Reply-To: References: Message-ID: <5c1dac94-fd78-0ac7-6b15-451e64190787@oracle.com> Looks good to me. Artem On 11/30/2016 10:29 PM, Tim Du wrote: > Hi , > > Would you help to review the path for "8157529:Remove intermittent key > from javax/net/ssl/DTLS/CipherSuite.java" , the intermittently failed > issue was fixed by JDK-8167680 , '@key intermittent ' can be > removed.Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157529 > webrev: http://cr.openjdk.java.net/~tidu/8157529/webrev.00/ > > Regards > Tim From ecki at zusammenkunft.net Mon Dec 5 19:58:18 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 5 Dec 2016 20:58:18 +0100 Subject: TLS session cache access (for FTP clients with data connection session reuse) Message-ID: <20161205205818.000012ba.ecki@zusammenkunft.net> With FTP/TLS there is a risk that data connections are guessed by attackers and there is no binding of the login credentials on the control connection and the data connection. Some FTP servers implement protection about this by requiring the data connection to resume the cached TLS session from the control connection. For example vsftpd 2.1.0 introduced the `require_ssl_reuse` option for this: http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html There is now a problem for Java implementations: if you implement a FTP client (like Apache Commons Net is doing) with SSLSocket (JSSE) you have no control over session re-use. In fact the JSSE internal session context cache is keyed by the destination address and port. The initial control connection is stored under ftp.vendor.com:20 but the additional data connections to random ports like ftp.vendor.com:12345 (or ip:port) will not re-use this cache entry. There have been some discussions in 2010 and Apache Commons Net implemented a hook method which can be used by application code to do some nasty setup. Cyberduck the FTP client for example uses reflection to poke into JSSE internals to provide the same session cache key: https://trac.cyberduck.io/ticket/5087 https://trac.cyberduck.io/changeset/10760 And there is no good solution in Commons Net either: https://issues.apache.org/jira/browse/NET-408 https://issues.apache.org/jira/browse/NET-426 (and a lot of discussions around vsftpd, filezilla, proftpd with Java all over stack exchange) Here I found a good writeup describing the reflection workaround (and the different versions needed): http://eng.wealthfront.com/2016/06/10/connecting-to-an-ftps-server-with-ssl-session-reuse-in-java-7-and-8/ I do wonder is it planned to offer a standard interface to get some more control? Has this been discussed here? The SSLContext provides getClientSessionContext() which talks about "Returns the client session context, which represents the set of SSL sessions available for use during the handshake phase of client-side SSL sockets." but does not make it clear that it uses some strict destination-port filtering. Also SSLSessionContext does not allow to add or modify a session or the cache key. Gruss Bernd From xuelei.fan at oracle.com Tue Dec 6 03:53:14 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 5 Dec 2016 19:53:14 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <2e4a551c-a4de-4ec6-4cb5-bacd8246bce9@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <3859f273-55eb-a2a0-a16b-ceee71062928@oracle.com> <93162d8f-88fc-a076-c206-e4ed40771d55@oracle.com> <2e55dc8a-30fd-8861-987d-bd8d21c5fe81@oracle.com> <1c34313c-9b42-9afc-1c2d-fe3c33b3bc69@oracle.com> <2e4a551c-a4de-4ec6-4cb5-bacd8246bce9@oracle.com> Message-ID: <2ed96914-8a66-a484-3b3e-685266c56f6f@oracle.com> New webrev: http://cr.openjdk.java.net/~xuelei/8170329/webrev.01/ On 12/5/2016 10:16 AM, Artem Smotrakov wrote: > > On 12/02/2016 09:48 PM, Xue-Lei Fan wrote: >> >>>>>>> - Exceptions are printed out in startServer/startClient methods, it >>>>>>> doesn't look necessary to use suppressed exceptions and initCause() >>>>>>> method. What was wrong with the code in runTest() method? The >>>>>>> code in >>>>>>> runTest() method looks shorter and cleaner to me. >>>>>>> >>>>>> The main issue of runTest() is that it does not throw the original >>>>>> exception. Exception tacks have more information for debugging. I >>>>>> want to keep the good side of Brad's previous hardness on this point. >>>>> It is not clear what's the original exception should be because you >>>>> have >>>>> client and server. If you print all exceptions in >>>>> startServer/startClient (right after they occurred), then you don't >>>>> hide >>>>> anything helpful for debugging. >>>>> >>>> The exception dump may have more information than the single exception >>>> track, for example the nested cause stacks. >>> Can't it be printed out in startServer/startClient accordingly? >> Throw the right exception is important even for test case. Having the >> Java handling the exception is more nature. Reading the debug log >> dump is not as straightforward as read the exception at the end of >> each run. Wrapping into RuntimeException is very confusing sometimes. >> >> Comparing the following two log: >> java.net.XXException: this is an exception message. >> cased by A >> caused by B. >> and >> java.lang.RuntimeException: xxxx >> caused by java.net.XXException: this is an exception message. >> caused by A. >> (cause by B may be swallowed) >> >> I don't like the later one, which introduce unnecessary exception >> stacks and take more time for the debugging. > I am not suggesting neither #2. > > I am suggesting not to use initCause because it modifies the original > exception, and not to use addSupressed() because it's not clear where > the suppressed exception came from. Instead, I am suggesting to print > all original exceptions on that sides where they occurred. I am not > suggesting to wrap anything into a runtime exception. A runtime > exception can be used just to indicate a test failure. I see your points. But most of the people would first read the exception stacks at first. It's a natural behavior to check the failure exception at first for developers and customers. Failure with the right exception helps a lot for debugging. The use of supressed and caused exception is also for this consideration. Xuelei From xuelei.fan at oracle.com Tue Dec 6 17:56:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Dec 2016 09:56:15 -0800 Subject: TLS session cache access (for FTP clients with data connection session reuse) In-Reply-To: <20161205205818.000012ba.ecki@zusammenkunft.net> References: <20161205205818.000012ba.ecki@zusammenkunft.net> Message-ID: <35687979-0467-6160-a9d5-2b9b605ea1f5@oracle.com> Hi Bernd, Thanks for the enhancement request. I filed a new Request For Enhancement (RFE) so that we can track the issue: https://bugs.openjdk.java.net/browse/JDK-8170813 Regards, Xuelei On 12/5/2016 11:58 AM, Bernd Eckenfels wrote: > With FTP/TLS there is a risk that data connections are guessed by > attackers and there is no binding of the login credentials on the > control connection and the data connection. > > Some FTP servers implement protection about this by requiring the data > connection to resume the cached TLS session from the control connection. > > For example vsftpd 2.1.0 introduced the `require_ssl_reuse` option for > this: > http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html > > There is now a problem for Java implementations: > > if you implement a FTP client (like Apache Commons Net is doing) with > SSLSocket (JSSE) you have no control over session re-use. > > In fact the JSSE internal session context cache is keyed by the > destination address and port. The initial control connection is stored > under ftp.vendor.com:20 but the additional data connections to random > ports like ftp.vendor.com:12345 (or ip:port) will not re-use this cache > entry. > > There have been some discussions in 2010 and Apache Commons Net > implemented a hook method which can be used by application code to do > some nasty setup. Cyberduck the FTP client for example uses > reflection to poke into JSSE internals to provide the same > session cache key: > > https://trac.cyberduck.io/ticket/5087 > https://trac.cyberduck.io/changeset/10760 > > And there is no good solution in Commons Net either: > > https://issues.apache.org/jira/browse/NET-408 > https://issues.apache.org/jira/browse/NET-426 > > (and a lot of discussions around vsftpd, filezilla, proftpd with Java > all over stack exchange) > > Here I found a good writeup describing the reflection workaround (and > the different versions needed): > > http://eng.wealthfront.com/2016/06/10/connecting-to-an-ftps-server-with-ssl-session-reuse-in-java-7-and-8/ > > I do wonder is it planned to offer a standard interface to get some > more control? Has this been discussed here? > > The SSLContext provides > getClientSessionContext() which talks about "Returns the client session > context, which represents the set of SSL sessions available for use > during the handshake phase of client-side SSL sockets." but does not > make it clear that it uses some strict destination-port filtering. Also > SSLSessionContext does not allow to add or modify a session or the > cache key. > > Gruss > Bernd > From david.lloyd at redhat.com Tue Dec 6 21:50:37 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 6 Dec 2016 15:50:37 -0600 Subject: TLS session cache access (for FTP clients with data connection session reuse) In-Reply-To: <35687979-0467-6160-a9d5-2b9b605ea1f5@oracle.com> References: <20161205205818.000012ba.ecki@zusammenkunft.net> <35687979-0467-6160-a9d5-2b9b605ea1f5@oracle.com> Message-ID: <8b83ee3c-73ee-f205-fbb5-0a9d68dcb362@redhat.com> I haven't run into this personally, but I may soon, so I have a question: did anyone try simply lying about the destination port (which is easy with SSLEngine, but might only be possible for SSLSocket if you do something funny with socket factorys - or maybe not at all)? On 12/06/2016 11:56 AM, Xuelei Fan wrote: > Hi Bernd, > > Thanks for the enhancement request. > > I filed a new Request For Enhancement (RFE) so that we can track the issue: > https://bugs.openjdk.java.net/browse/JDK-8170813 > > Regards, > Xuelei > > On 12/5/2016 11:58 AM, Bernd Eckenfels wrote: >> With FTP/TLS there is a risk that data connections are guessed by >> attackers and there is no binding of the login credentials on the >> control connection and the data connection. >> >> Some FTP servers implement protection about this by requiring the data >> connection to resume the cached TLS session from the control connection. >> >> For example vsftpd 2.1.0 introduced the `require_ssl_reuse` option for >> this: >> http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html >> >> There is now a problem for Java implementations: >> >> if you implement a FTP client (like Apache Commons Net is doing) with >> SSLSocket (JSSE) you have no control over session re-use. >> >> In fact the JSSE internal session context cache is keyed by the >> destination address and port. The initial control connection is stored >> under ftp.vendor.com:20 but the additional data connections to random >> ports like ftp.vendor.com:12345 (or ip:port) will not re-use this cache >> entry. >> >> There have been some discussions in 2010 and Apache Commons Net >> implemented a hook method which can be used by application code to do >> some nasty setup. Cyberduck the FTP client for example uses >> reflection to poke into JSSE internals to provide the same >> session cache key: >> >> https://trac.cyberduck.io/ticket/5087 >> https://trac.cyberduck.io/changeset/10760 >> >> And there is no good solution in Commons Net either: >> >> https://issues.apache.org/jira/browse/NET-408 >> https://issues.apache.org/jira/browse/NET-426 >> >> (and a lot of discussions around vsftpd, filezilla, proftpd with Java >> all over stack exchange) >> >> Here I found a good writeup describing the reflection workaround (and >> the different versions needed): >> >> http://eng.wealthfront.com/2016/06/10/connecting-to-an-ftps-server-with-ssl-session-reuse-in-java-7-and-8/ >> >> >> I do wonder is it planned to offer a standard interface to get some >> more control? Has this been discussed here? >> >> The SSLContext provides >> getClientSessionContext() which talks about "Returns the client session >> context, which represents the set of SSL sessions available for use >> during the handshake phase of client-side SSL sockets." but does not >> make it clear that it uses some strict destination-port filtering. Also >> SSLSessionContext does not allow to add or modify a session or the >> cache key. >> >> Gruss >> Bernd >> -- - DML From sean.mullan at oracle.com Tue Dec 6 22:38:04 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 6 Dec 2016 17:38:04 -0500 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> Message-ID: <5b6227f8-6822-c1f1-a33d-60f007920d5b@oracle.com> On 12/2/16 2:23 PM, Xue-Lei Fan wrote: > On 11/29/2016 5:22 AM, Sean Mullan wrote: >> On 11/27/16 7:43 AM, Xuelei Fan wrote: >>> On 11/27/2016 6:04 PM, Wang Weijun wrote: >>>> This is not only a test update. >>>> >>> No, I happened to find an implementation issue with the new test, so fix >>> it altogether. The issue is that the simple validator >>> (SimpleValidator.java) does not support SKID/AKID during cert path >>> build. If two trusted certs has the same subject, the simple validator >>> may not be able to find the right one. >> >> We have had issues in the PKIX CertPathBuilder with matching on >> AKID/SKID when building certpaths, so we want to be careful not to >> introduce a similar issue. See this bug for more information: >> >> https://bugs.openjdk.java.net/browse/JDK-8072463 >> >> I have not reviewed the fix enough to know if this issue applies here >> but please double-check it. >> > The KID are used for best effort matching in this update. If no KIDs > get matched, the previous behavior is reserved. Should be safe, I think. You only have to get the authKeyId once, so I think it would be better to get the keyids first and then pass them to the isKIDMatched method. Also I wonder if you should throw an Exception if the cert has an akid and all of the trusted certs have a skid and none of them match. Looks ok otherwise. --Sean From xuelei.fan at oracle.com Wed Dec 7 01:00:34 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Dec 2016 17:00:34 -0800 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: <5b6227f8-6822-c1f1-a33d-60f007920d5b@oracle.com> References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <5b6227f8-6822-c1f1-a33d-60f007920d5b@oracle.com> Message-ID: new webrev: http://cr.openjdk.java.net/~xuelei/8170329/webrev.02/ On 12/6/2016 2:38 PM, Sean Mullan wrote: > On 12/2/16 2:23 PM, Xue-Lei Fan wrote: >> On 11/29/2016 5:22 AM, Sean Mullan wrote: >>> On 11/27/16 7:43 AM, Xuelei Fan wrote: >>>> On 11/27/2016 6:04 PM, Wang Weijun wrote: >>>>> This is not only a test update. >>>>> >>>> No, I happened to find an implementation issue with the new test, so >>>> fix >>>> it altogether. The issue is that the simple validator >>>> (SimpleValidator.java) does not support SKID/AKID during cert path >>>> build. If two trusted certs has the same subject, the simple >>>> validator >>>> may not be able to find the right one. >>> >>> We have had issues in the PKIX CertPathBuilder with matching on >>> AKID/SKID when building certpaths, so we want to be careful not to >>> introduce a similar issue. See this bug for more information: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8072463 >>> >>> I have not reviewed the fix enough to know if this issue applies here >>> but please double-check it. >>> >> The KID are used for best effort matching in this update. If no KIDs >> get matched, the previous behavior is reserved. Should be safe, I think. > > You only have to get the authKeyId once, so I think it would be better > to get the keyids first and then pass them to the isKIDMatched method. > Good! > Also I wonder if you should throw an Exception if the cert has an akid > and all of the trusted certs have a skid and none of them match. > It can be an exception in general. I want a safe and no compatibility impact update. The following validation processes will identify the problem if the cert path is not correct. > Looks ok otherwise. > > --Sean Thanks! Xuelei From sean.mullan at oracle.com Wed Dec 7 13:39:12 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 7 Dec 2016 08:39:12 -0500 Subject: Code Review Request JDK-8170329 New SSLSocket testing template In-Reply-To: References: <6b788ac2-bdf9-3621-8444-c64ae035f8b2@oracle.com> <0d9fa27d-2cbe-2e30-3d9b-9e989f084297@oracle.com> <632e2e00-591a-542d-cadc-4d8ce45f6742@oracle.com> <89f4f290-9946-8486-7fb1-da62be041c3a@oracle.com> <5b6227f8-6822-c1f1-a33d-60f007920d5b@oracle.com> Message-ID: <24c1c739-c17d-5f42-a339-1a4c3889cafb@oracle.com> On 12/6/16 8:00 PM, Xuelei Fan wrote: > new webrev: > http://cr.openjdk.java.net/~xuelei/8170329/webrev.02/ Looks good. --Sean From adam.petcher at oracle.com Wed Dec 7 14:14:24 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 7 Dec 2016 09:14:24 -0500 Subject: [PATCH] 8158517: Minor optimizations to ISO10126PADDING Message-ID: <58481940.6020300@oracle.com> Minor improvement/optimization to ISO10126Padding. Simplifies the code a bit and requests one fewer random byte. No regression test is provided because this is a code cleanup, and the functionality is covered by existing tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8158517 Diff: diff --git a/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java b/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java --- a/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java +++ b/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java @@ -68,10 +68,10 @@ } byte paddingOctet = (byte) (len & 0xff); - byte[] padding = new byte[len]; + byte[] padding = new byte[len - 1]; SunJCE.getRandom().nextBytes(padding); - padding[len-1] = paddingOctet; - System.arraycopy(padding, 0, in, off, len); + System.arraycopy(padding, 0, in, off, len - 1); + in[off + len - 1] = paddingOctet; return; } @@ -101,7 +101,7 @@ return -1; } - int start = off + len - ((int)lastByte & 0x0ff); + int start = off + len - padValue; if (start < off) { return -1; } From sean.mullan at oracle.com Wed Dec 7 14:54:44 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 7 Dec 2016 09:54:44 -0500 Subject: [PATCH] 8158517: Minor optimizations to ISO10126PADDING In-Reply-To: <58481940.6020300@oracle.com> References: <58481940.6020300@oracle.com> Message-ID: <81407945-de4a-2a2b-f7e0-902cec02368a@oracle.com> Looks good. Minor comment - update the copyright to include 2016 as the last year it was updated, ex: * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. Send me the updated diffs and I will push it for you. --Sean On 12/7/16 9:14 AM, Adam Petcher wrote: > > Minor improvement/optimization to ISO10126Padding. Simplifies the code a > bit and requests one fewer random byte. No regression test is provided > because this is a code cleanup, and the functionality is covered by > existing tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158517 > > Diff: > > diff --git > a/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > b/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > --- > a/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > +++ > b/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > @@ -68,10 +68,10 @@ > } > > byte paddingOctet = (byte) (len & 0xff); > - byte[] padding = new byte[len]; > + byte[] padding = new byte[len - 1]; > SunJCE.getRandom().nextBytes(padding); > - padding[len-1] = paddingOctet; > - System.arraycopy(padding, 0, in, off, len); > + System.arraycopy(padding, 0, in, off, len - 1); > + in[off + len - 1] = paddingOctet; > return; > } > > @@ -101,7 +101,7 @@ > return -1; > } > > - int start = off + len - ((int)lastByte & 0x0ff); > + int start = off + len - padValue; > if (start < off) { > return -1; > } From ecki at zusammenkunft.net Wed Dec 7 20:23:30 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 7 Dec 2016 20:23:30 +0000 (UTC) Subject: [PATCH] 8158517: Minor optimizations to ISO10126PADDING In-Reply-To: <81407945-de4a-2a2b-f7e0-902cec02368a@oracle.com> References: <58481940.6020300@oracle.com> <81407945-de4a-2a2b-f7e0-902cec02368a@oracle.com> Message-ID: <57A008FAA9E6E1E3.2C449163-9406-4C2F-A32A-E180962F9359@mail.outlook.com> Thanks for committing, looks fine with me as well. Gruss Bernd On Wed, Dec 7, 2016 at 5:25 PM +0100, "Sean Mullan" wrote: Looks good. Minor comment - update the copyright to include 2016 as the last year it was updated, ex: * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. Send me the updated diffs and I will push it for you. --Sean On 12/7/16 9:14 AM, Adam Petcher wrote: > > Minor improvement/optimization to ISO10126Padding. Simplifies the code a > bit and requests one fewer random byte. No regression test is provided > because this is a code cleanup, and the functionality is covered by > existing tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158517 > > Diff: > > diff --git > a/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > b/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > --- > a/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > +++ > b/src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java > @@ -68,10 +68,10 @@ > } > > byte paddingOctet = (byte) (len & 0xff); > - byte[] padding = new byte[len]; > + byte[] padding = new byte[len - 1]; > SunJCE.getRandom().nextBytes(padding); > - padding[len-1] = paddingOctet; > - System.arraycopy(padding, 0, in, off, len); > + System.arraycopy(padding, 0, in, off, len - 1); > + in[off + len - 1] = paddingOctet; > return; > } > > @@ -101,7 +101,7 @@ > return -1; > } > > - int start = off + len - ((int)lastByte & 0x0ff); > + int start = off + len - padValue; > if (start < off) { > return -1; > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Dec 7 23:21:55 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 7 Dec 2016 15:21:55 -0800 Subject: [9] RFR 8079898: Resolve disabled warnings for libj2ucrypto Message-ID: <2d9c6832-e732-9fd0-e11c-d71cf5a3cc28@oracle.com> Anyone can help reviewing this? The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to address the E_MACRO_REDEFINED warning. In addition, I also updated the nativeCrypto.h to remove the workaround for a Solaris12-specific issue which has now been fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8079898 Webrev: http://cr.openjdk.java.net/~valeriep/8079898/webrev.00/ JPRT result looks fine. Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Wed Dec 7 23:32:38 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 7 Dec 2016 15:32:38 -0800 Subject: [9] RFR 8079898: Resolve disabled warnings for libj2ucrypto In-Reply-To: <2d9c6832-e732-9fd0-e11c-d71cf5a3cc28@oracle.com> References: <2d9c6832-e732-9fd0-e11c-d71cf5a3cc28@oracle.com> Message-ID: <58489C16.8000104@oracle.com> On 12/07/2016 03:21 PM, Valerie Peng wrote: > Anyone can help reviewing this? > > The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to > address the E_MACRO_REDEFINED warning. > In addition, I also updated the nativeCrypto.h to remove the workaround > for a Solaris12-specific issue which has now been fixed. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079898 > Webrev: http://cr.openjdk.java.net/~valeriep/8079898/webrev.00/ > > JPRT result looks fine. > > Thanks, > > Valerie > looks fine to me. Tony From magnus.ihse.bursie at oracle.com Thu Dec 8 07:14:45 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Dec 2016 08:14:45 +0100 Subject: [9] RFR 8079898: Resolve disabled warnings for libj2ucrypto In-Reply-To: <2d9c6832-e732-9fd0-e11c-d71cf5a3cc28@oracle.com> References: <2d9c6832-e732-9fd0-e11c-d71cf5a3cc28@oracle.com> Message-ID: <78ABF32B-51F9-4FF3-BD77-068AE51799AF@oracle.com> Looks good to me. /Magnus > 8 dec. 2016 kl. 00:21 skrev Valerie Peng : > > Anyone can help reviewing this? > > The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to address the E_MACRO_REDEFINED warning. > In addition, I also updated the nativeCrypto.h to remove the workaround for a Solaris12-specific issue which has now been fixed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8079898 > Webrev: http://cr.openjdk.java.net/~valeriep/8079898/webrev.00/ > > JPRT result looks fine. > > Thanks, > > Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Thu Dec 8 16:17:58 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 8 Dec 2016 11:17:58 -0500 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider Message-ID: <584987B6.6030800@oracle.com> Subclasses of Signature may have a null provider. In this case, the debug logging code will throw a NPE when attempting to call getName() on it. Since this member may be null, I would like to change its type to Optional to ensure that code checks whether it is present before using it. I have assumed that getProvider() methods (in both Signature and Service) always return non-null---if this assumption is incorrect, then I'll need to change some of the uses of Optional in/around these methods. Note that this issue of missing null checks for providers exists in several classes (e.g. Cipher, MessageDigest). Once this patch is reviewed and committed, I will apply the same solution to all other affected classes. Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 Diff: diff --git a/src/java.base/share/classes/java/security/Signature.java b/src/java.base/share/classes/java/security/Signature.java --- a/src/java.base/share/classes/java/security/Signature.java +++ b/src/java.base/share/classes/java/security/Signature.java @@ -134,7 +134,7 @@ private String algorithm; // The provider - Provider provider; + Optional provider = Optional.empty(); /** * Possible {@link #state} value, signifying that @@ -266,7 +266,7 @@ SignatureSpi spi = (SignatureSpi)instance.impl; sig = new Delegate(spi, algorithm); } - sig.provider = instance.provider; + sig.provider = Optional.of(instance.provider); return sig; } @@ -449,13 +449,17 @@ */ public final Provider getProvider() { chooseFirstProvider(); - return this.provider; + return this.provider.get(); } void chooseFirstProvider() { // empty, overridden in Delegate } + private String getProvidedByString(){ + return provider.map(x -> " from: " + x.getName()).orElse(""); + } + /** * Initializes this object for verification. If this method is called * again with a different argument, it negates the effect @@ -473,7 +477,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " verification algorithm from: " + this.provider.getName()); + " verification algorithm" + getProvidedByString()); } } @@ -522,7 +526,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " verification algorithm from: " + this.provider.getName()); + " verification algorithm" + getProvidedByString()); } } @@ -543,7 +547,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " signing algorithm from: " + this.provider.getName()); + " signing algorithm" + getProvidedByString()); } } @@ -566,7 +570,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " signing algorithm from: " + this.provider.getName()); + " signing algorithm" + getProvidedByString()); } } @@ -1087,7 +1091,7 @@ } try { sigSpi = newInstance(s); - provider = s.getProvider(); + provider = Optional.of(s.getProvider()); // not needed any more firstService = null; serviceIterator = null; @@ -1132,7 +1136,7 @@ try { SignatureSpi spi = newInstance(s); init(spi, type, key, random); - provider = s.getProvider(); + provider = Optional.of(s.getProvider()); sigSpi = spi; firstService = null; serviceIterator = null; diff --git a/test/java/security/Signature/NoProvider.java b/test/java/security/Signature/NoProvider.java new file mode 100644 --- /dev/null +++ b/test/java/security/Signature/NoProvider.java @@ -0,0 +1,99 @@ +/* + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8165751 + * @summary Verify that that a subclass of Signature that does not contain a + * provider can be used verify. + * @run main/othervm -Djava.security.debug=provider NoProvider + */ + +import java.security.*; + +public class NoProvider { + + private static class NoProviderPublicKey implements PublicKey{ + public String getAlgorithm(){ + return "NoProvider"; + } + public String getFormat(){ + return "none"; + } + public byte[] getEncoded(){ + return new byte[1]; + } + } + + private static class NoProviderSignature extends Signature{ + + public NoProviderSignature(){ + super("NoProvider"); + } + + protected void engineInitVerify(PublicKey publicKey) + throws InvalidKeyException{ + // do nothing + } + + protected void engineInitSign(PrivateKey privateKey) + throws InvalidKeyException{ + // do nothing + } + + protected void engineUpdate(byte b) throws SignatureException{ + // do nothing + } + + protected void engineUpdate(byte[] b, int off, int len) + throws SignatureException{ + // do nothing + } + + protected byte[] engineSign() throws SignatureException{ + return new byte[1]; + } + + protected boolean engineVerify(byte[] sigBytes) + throws SignatureException{ + return false; + } + + @Deprecated + protected void engineSetParameter(String param, Object value) + throws InvalidParameterException{ + // do nothing + } + + @Deprecated + protected Object engineGetParameter(String param) + throws InvalidParameterException{ + return null; + } + + } + + public static void main(String[] args) throws Exception { + new NoProviderSignature().initVerify(new NoProviderPublicKey()); + } +} From vincent.x.ryan at oracle.com Thu Dec 8 22:18:16 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 8 Dec 2016 22:18:16 +0000 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake Message-ID: The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot be easily addressed using the existing ALPN APIs. This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. Additional TLS parameters are also available for inspection in the callback function. This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. Thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ From david.lloyd at redhat.com Thu Dec 8 23:13:48 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 8 Dec 2016 17:13:48 -0600 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: References: Message-ID: <2e5b13be-8726-3395-8dca-e33d1dcf8b22@redhat.com> On 12/08/2016 04:18 PM, Vincent Ryan wrote: > The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot > be easily addressed using the existing ALPN APIs. > > This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications > to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the > TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. > Additional TLS parameters are also available for inspection in the callback function. > > This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. Wasn't the entire point of the chosen ALPN solution to make this kind of thing unnecessary? -- - DML From vincent.x.ryan at oracle.com Fri Dec 9 00:29:07 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 9 Dec 2016 00:29:07 +0000 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <2e5b13be-8726-3395-8dca-e33d1dcf8b22@redhat.com> References: <2e5b13be-8726-3395-8dca-e33d1dcf8b22@redhat.com> Message-ID: <46766406-8E9B-40AC-A999-95624B7EF700@oracle.com> We understood when we examined these issues last year that the existing ALPN API would be sufficient. However it transpired, following HTTP2 server implementation efforts, that a particular use-case was difficult to address without sacrificing performance. This new API fixes that specific problem and the existing API is still available for the common case. > On 8 Dec 2016, at 23:13, David M. Lloyd wrote: > > On 12/08/2016 04:18 PM, Vincent Ryan wrote: >> The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot >> be easily addressed using the existing ALPN APIs. >> >> This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications >> to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the >> TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. >> Additional TLS parameters are also available for inspection in the callback function. >> >> This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. > > Wasn't the entire point of the chosen ALPN solution to make this kind of thing unnecessary? > > -- > - DML From bradford.wetmore at oracle.com Fri Dec 9 01:34:07 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 8 Dec 2016 17:34:07 -0800 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: References: Message-ID: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> Hi Vinnie, On 12/8/2016 2:18 PM, Vincent Ryan wrote: > The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot > be easily addressed using the existing ALPN APIs. > > This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications > to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the > TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. > Additional TLS parameters are also available for inspection in the callback function. > > This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. Technically, the API could be used for NPN (though it's pretty much dead), so that would be a listing the options on the server side, and selection on client side. > Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 > Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ SSLEngineImpl.java/SSLSocketImpl.java ===================================== Please use the standard handshaker initialization pattern where the Handshaker is initialized with all of the data/mechanisms needed for a complete handshake. This will will ensure consistent handshake results and avoid potential strange race conditions. (There's some corresponding API comments below.) You would register your callback after the handshaker.setApplicationProtocols() calls at (currently) line 444 in the SSLEngineImpl code. SSLEngine.java/SSLSocket.java ============================= I would suggest putting an introduction to this addition in the class description section, that application values can be set using SSLParameters.setApplication...() and selected with the default algorithm, or that a more accurate selection mechanism can be created by registering the callback that could look at any Handshake in progress and make appropriate decisions. 1339: Registers the callback function that selects an application protocol value during the SSL/TLS/DTLS handshake. -> Registers a callback function that selects an application protocol value for a SSL/TLS/DTLS handshake. The function overrides any values set using {@link SSLParameters#setApplicationProtocols SSLParameters.setApplicationProtocols}. and remove the corresponding section from the return docs (in the {@code String section}). the function's first argument enables the current handshake settings to be inspected.
-> the function's first argument allows the current SSLEngine(SSLSocket) to be inspected, including the handshake session and configuration settings.
If null is returned, or a value that was not advertised then the underlying protocol will determine what action to take. (For example, ALPN will send a "no_application_protocol" alert and terminate the connection.) -> If the return value is null (no value chosen) or is a value that was not advertised by the peer, the underlying protocol will determine what action to take. (For example, ALPN will send a "no_application_protocol" alert and terminate the connection.) Also, TLS should be configured with parameters that -> Also, this SSLEngine(SSLSocket) should be configured with parameters that @param selector the callback function, or null to de-register. -> @param selector the callback function, or null to disable the callback functionality. Retrieves the callback function that selects an application protocol value during the SSL/TLS/DTLS handshake. -> Retrieves the callback function that selects an application protocol value during a SSL/TLS/DTLS handshake. This method should be called by TLS protocol implementations during the TLS handshake. The callback function should not be called until after the cipher suite has been selected. I would suggest removing this apiNote entirely. I expect only applications will call this method, so the first sentence is not necessary since it's up to the implementation how it wants to store the BiFunction. I expect that when the handshaker is initialized, the current BiFunction will be assigned to it, and thus can't be changed for the current handshake/Handshaker in progress. The second sentence ties an ordering to the selection of ciphersuite and ALPN value, and will tie our hands if we ever revisit the group protocol/ciphersuite/SNI/ALPN selection discussion. ServerHandshaker.java ===================== I was expecting that the ALPN callback logic would be an update for our current ALPN decision logic. If a callback was set, use it, else look at defined strings from the SSLParameters, else fail. e.g. ALPNExtension clientHelloALPN = (ALPNExtension) mesg.extensions.get(ExtensionType.EXT_ALPN); if (clientHelloALPN != null) { List protocols = clientHelloALPN.getPeerAPs(); if (applicationSelector != null) { applicationProtocol = selector.apply(SSLEngine/SSLSocket, peerAPs); } else if (localApl.length > 0)) { // Intersect the requested and the locally supported, // and save for later. Use server preference order for (String ap : localApl) { ...deleted... } applicationProtocol = negotiatedValue; } if (negotiatedValue == null) { fatalSE(Alerts.alert_no_application_protocol, new SSLHandshakeException( "No matching ALPN values")); } } Thanks. Brad From bradford.wetmore at oracle.com Fri Dec 9 01:34:28 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 8 Dec 2016 17:34:28 -0800 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <46766406-8E9B-40AC-A999-95624B7EF700@oracle.com> References: <2e5b13be-8726-3395-8dca-e33d1dcf8b22@redhat.com> <46766406-8E9B-40AC-A999-95624B7EF700@oracle.com> Message-ID: <78d49fc6-46a4-6ff3-3cf4-299d3162a674@oracle.com> Hi, Vinnie wrote: > We understood when we examined these issues last year that the > existing ALPN API would be sufficient. However it transpired, > following HTTP2 server implementation efforts, that a particular > use-case was difficult to address without sacrificing performance. A few more details. The discussion/decisions we had last year ended with requiring servers to inspect ClientHellos for the client's max TLS protocol/ciphersuites/SNI/ALPNs/etc, and then do any necessary configuration before actually starting the SSL/TLS/DTLS handshake on the server side. That included enabling specific SSL/TLS/DTLS protocols, ordering the ciphersuites (calling SSLParameters.setUseCipherSuitesOrder()) and ordering the ALPN values. If it turned out that the resulting selected combination was incorrect, and if you were using a SSLEngine, you could throw away the outbound handshake bytes and retry the same ClientHello with a completely new SSLEngine that is configured differently. Very awkward and would duplicate a lot of JSSE code in the application. And unfortunately, SSLSocket doesn't allow for intercept/retry, you'd have to retry using a brand new connection. The approach was ok at the time, but the Servlet folks really had a hard time when it came to actually using the API. This came up in the discussion last June, and it's been something we've been wanting to address for JDK 9. You can use the existing API as before, or if you want to examine the SSLEngine/SSLSocket mid-handshake, you can use the new one. Thanks, Brad On 12/8/2016 4:29 PM, Vincent Ryan wrote: > We understood when we examined these issues last year that the existing ALPN API would be sufficient. > However it transpired, following HTTP2 server implementation efforts, that a particular use-case was > difficult to address without sacrificing performance. > > This new API fixes that specific problem and the existing API is still available for the common case. > > >> On 8 Dec 2016, at 23:13, David M. Lloyd wrote: >> >> On 12/08/2016 04:18 PM, Vincent Ryan wrote: >>> The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot >>> be easily addressed using the existing ALPN APIs. >>> >>> This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications >>> to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the >>> TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. >>> Additional TLS parameters are also available for inspection in the callback function. >>> >>> This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. >> >> Wasn't the entire point of the chosen ALPN solution to make this kind of thing unnecessary? >> >> -- >> - DML > From david.lloyd at redhat.com Fri Dec 9 02:09:34 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 8 Dec 2016 20:09:34 -0600 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <78d49fc6-46a4-6ff3-3cf4-299d3162a674@oracle.com> References: <2e5b13be-8726-3395-8dca-e33d1dcf8b22@redhat.com> <46766406-8E9B-40AC-A999-95624B7EF700@oracle.com> <78d49fc6-46a4-6ff3-3cf4-299d3162a674@oracle.com> Message-ID: <18884d27-4ccb-544f-7d80-9ee96ebab5d0@redhat.com> On 12/08/2016 07:34 PM, Bradford Wetmore wrote: > Hi, > > Vinnie wrote: >> We understood when we examined these issues last year that the >> existing ALPN API would be sufficient. However it transpired, >> following HTTP2 server implementation efforts, that a particular >> use-case was difficult to address without sacrificing performance. > > A few more details. > > The discussion/decisions we had last year ended with requiring servers > to inspect ClientHellos for the client's max TLS > protocol/ciphersuites/SNI/ALPNs/etc, and then do any necessary > configuration before actually starting the SSL/TLS/DTLS handshake on the > server side. That included enabling specific SSL/TLS/DTLS protocols, > ordering the ciphersuites (calling > SSLParameters.setUseCipherSuitesOrder()) and ordering the ALPN values. > If it turned out that the resulting selected combination was incorrect, How could it turn out to be incorrect, when you know in advance what credentials you have, what cipher suites are available, and what protocols support which cipher suites? I'm just curious because I'm pretty sure we haven't encountered this (I'll ask our web server folks to be sure though). Also I'd hate to see a worst-case situation where a this API was introduced (which is very reminiscent of ideas which were rejected for good reasons), and it turns out that in the end it's not quite sufficient after all, leaving a bit of dead code around. I'm just wondering in case there are edge cases that we have not encountered but are lurking in a dark corner, waiting to surprise us later. > and if you were using a SSLEngine, you could throw away the outbound > handshake bytes and retry the same ClientHello with a completely new > SSLEngine that is configured differently. Very awkward and would > duplicate a lot of JSSE code in the application. And unfortunately, > SSLSocket doesn't allow for intercept/retry, you'd have to retry using a > brand new connection. > The approach was ok at the time, but the Servlet folks really had a hard > time when it came to actually using the API. This came up in the > discussion last June, and it's been something we've been wanting to > address for JDK 9. > > You can use the existing API as before, or if you want to examine the > SSLEngine/SSLSocket mid-handshake, you can use the new one. > > Thanks, > > Brad > > > On 12/8/2016 4:29 PM, Vincent Ryan wrote: >> We understood when we examined these issues last year that the >> existing ALPN API would be sufficient. >> However it transpired, following HTTP2 server implementation efforts, >> that a particular use-case was >> difficult to address without sacrificing performance. >> >> This new API fixes that specific problem and the existing API is still >> available for the common case. >> >> >>> On 8 Dec 2016, at 23:13, David M. Lloyd wrote: >>> >>> On 12/08/2016 04:18 PM, Vincent Ryan wrote: >>>> The Java Servlet Expect Group reported that they have identified a >>>> specific HTTP2 server use-case that cannot >>>> be easily addressed using the existing ALPN APIs. >>>> >>>> This changeset fixes that problem. It supports a new callback >>>> mechanism to allow TLS server applications >>>> to set an application protocol during the TLS handshake. >>>> Specifically it allows the cipher suite chosen by the >>>> TLS protocol implementation to be examined by the TLS server >>>> application before it sets the application protocol. >>>> Additional TLS parameters are also available for inspection in the >>>> callback function. >>>> >>>> This new mechanism is available only to TLS server applications. TLS >>>> clients will continue to use the existing ALPN APIs. >>> >>> Wasn't the entire point of the chosen ALPN solution to make this kind >>> of thing unnecessary? >>> >>> -- >>> - DML >> -- - DML From adam.petcher at oracle.com Fri Dec 9 15:53:31 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 9 Dec 2016 10:53:31 -0500 Subject: [PATCH] 8069128: remove deprecation warning suppression from KeychainStore Message-ID: <584AD37B.2010502@oracle.com> KeychainStore has a couple of @SuppressWarnings("deprecation") annotations that were required due to references to an overloaded equals method in ObjectIdentifier that was marked as deprecated. This method has since been removed, so these calls now resolve to a non-deprecated method. Bug: https://bugs.openjdk.java.net/browse/JDK-8069128 Diff: diff --git a/src/java.base/macosx/classes/apple/security/KeychainStore.java b/src/java.base/macosx/classes/apple/security/KeychainStore.java --- a/src/java.base/macosx/classes/apple/security/KeychainStore.java +++ b/src/java.base/macosx/classes/apple/security/KeychainStore.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -911,7 +911,6 @@ return true; } - @SuppressWarnings("deprecation") private byte[] fetchPrivateKeyFromBag(byte[] privateKeyInfo) throws IOException, NoSuchAlgorithmException, CertificateException { byte[] returnValue = null; @@ -972,7 +971,6 @@ return returnValue; } - @SuppressWarnings("deprecation") private byte[] extractKeyData(DerInputStream stream) throws IOException, NoSuchAlgorithmException, CertificateException { From simone.bordet at gmail.com Fri Dec 9 17:21:57 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 9 Dec 2016 18:21:57 +0100 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <18884d27-4ccb-544f-7d80-9ee96ebab5d0@redhat.com> References: <2e5b13be-8726-3395-8dca-e33d1dcf8b22@redhat.com> <46766406-8E9B-40AC-A999-95624B7EF700@oracle.com> <78d49fc6-46a4-6ff3-3cf4-299d3162a674@oracle.com> <18884d27-4ccb-544f-7d80-9ee96ebab5d0@redhat.com> Message-ID: Hi, On Fri, Dec 9, 2016 at 3:09 AM, David M. Lloyd wrote: > On 12/08/2016 07:34 PM, Bradford Wetmore wrote: >> >> Hi, >> >> Vinnie wrote: >>> >>> We understood when we examined these issues last year that the >>> existing ALPN API would be sufficient. However it transpired, >>> following HTTP2 server implementation efforts, that a particular >>> use-case was difficult to address without sacrificing performance. >> >> >> A few more details. >> >> The discussion/decisions we had last year ended with requiring servers >> to inspect ClientHellos for the client's max TLS >> protocol/ciphersuites/SNI/ALPNs/etc, and then do any necessary >> configuration before actually starting the SSL/TLS/DTLS handshake on the >> server side. That included enabling specific SSL/TLS/DTLS protocols, >> ordering the ciphersuites (calling >> SSLParameters.setUseCipherSuitesOrder()) and ordering the ALPN values. >> If it turned out that the resulting selected combination was incorrect, > > > How could it turn out to be incorrect, when you know in advance what > credentials you have, what cipher suites are available, and what protocols > support which cipher suites? If any logic you would run is different from JDK's, then the result may be incorrect. Say it another way, you run an old version of your code in a new JDK version: the logic that was ok long time ago may not be the same years later, and you get different results. > I'm just curious because I'm pretty sure we > haven't encountered this (I'll ask our web server folks to be sure though). That would be helpful. Apart us (Jetty), nobody has actually implemented ALPN using the new JDK9 API yet, as far as I know. > Also I'd hate to see a worst-case situation where a this API was introduced > (which is very reminiscent of ideas which were rejected for good reasons), > and it turns out that in the end it's not quite sufficient after all, > leaving a bit of dead code around. >From how I understand this change, the whole mechanism of parsing the ClientHello, running your logic, running again the ClientHello parsing and the JDK logic, resulting in calling the application callbacks (for SNI for example) twice, checking that both logics yielded the same result, and if not take recovery actions, stays there, if you want to go that way. You don't have to use the new code. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Fri Dec 9 18:04:20 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 9 Dec 2016 13:04:20 -0500 Subject: [PATCH] 8069128: remove deprecation warning suppression from KeychainStore In-Reply-To: <584AD37B.2010502@oracle.com> References: <584AD37B.2010502@oracle.com> Message-ID: <1d1c590b-bb2e-caf3-fe11-4f8d11ff5bbb@oracle.com> Looks good to me. Please add a noreg label (noreg-cleanup or noreg-trivial probably) to the bug. --Sean On 12/9/16 10:53 AM, Adam Petcher wrote: > > KeychainStore has a couple of @SuppressWarnings("deprecation") > annotations that were required due to references to an overloaded equals > method in ObjectIdentifier that was marked as deprecated. This method > has since been removed, so these calls now resolve to a non-deprecated > method. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8069128 > > Diff: > > diff --git > a/src/java.base/macosx/classes/apple/security/KeychainStore.java > b/src/java.base/macosx/classes/apple/security/KeychainStore.java > --- a/src/java.base/macosx/classes/apple/security/KeychainStore.java > +++ b/src/java.base/macosx/classes/apple/security/KeychainStore.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -911,7 +911,6 @@ > return true; > } > > - @SuppressWarnings("deprecation") > private byte[] fetchPrivateKeyFromBag(byte[] privateKeyInfo) throws > IOException, NoSuchAlgorithmException, CertificateException > { > byte[] returnValue = null; > @@ -972,7 +971,6 @@ > return returnValue; > } > > - @SuppressWarnings("deprecation") > private byte[] extractKeyData(DerInputStream stream) > throws IOException, NoSuchAlgorithmException, CertificateException > { > From xuelei.fan at oracle.com Fri Dec 9 20:54:38 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 9 Dec 2016 12:54:38 -0800 Subject: Code Review Request, JDK-8171003, A couple of JSSE tests have been failing after JDK-8170329 Message-ID: <3c54a3cf-8fda-eba6-4f9e-71311df1a159@oracle.com> Hi, Please review this typo issue introduced in JDK-8170329. $ hg diff test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java @Override - protected boolean isCustomizeClientConnection() { + protected boolean isCustomizedClientConnection() { return true; } $ hg diff test/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java @Override - protected boolean isCustomizeClientConnection() { + protected boolean isCustomizedClientConnection() { return true; } Thanks, Xuelei From vincent.x.ryan at oracle.com Fri Dec 9 21:08:28 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 9 Dec 2016 21:08:28 +0000 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> References: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> Message-ID: Thanks for your detailed review Brad. I?ve generated a new webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ > On 9 Dec 2016, at 01:34, Bradford Wetmore wrote: > > > Hi Vinnie, > > On 12/8/2016 2:18 PM, Vincent Ryan wrote: >> The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot >> be easily addressed using the existing ALPN APIs. >> >> This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications >> to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the >> TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. >> Additional TLS parameters are also available for inspection in the callback function. >> >> This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. > > Technically, the API could be used for NPN (though it's pretty much dead), so that would be a listing the options on the server side, and selection on client side. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 >> Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ > > SSLEngineImpl.java/SSLSocketImpl.java > ===================================== > Please use the standard handshaker initialization pattern where the Handshaker is initialized with all of the data/mechanisms needed for a complete handshake. This will will ensure consistent handshake results and avoid potential strange race conditions. (There's some corresponding API comments below.) > > You would register your callback after the handshaker.setApplicationProtocols() calls at (currently) line 444 in the SSLEngineImpl code. > > > SSLEngine.java/SSLSocket.java > ============================= > I would suggest putting an introduction to this addition in the class description section, that application values can be set using SSLParameters.setApplication...() and selected with the default algorithm, or that a more accurate selection mechanism can be created by registering the callback that could look at any Handshake in progress and make appropriate decisions. > > 1339: > Registers the callback function that selects an application protocol > value during the SSL/TLS/DTLS handshake. > -> > Registers a callback function that selects an application protocol > value for a SSL/TLS/DTLS handshake. The function overrides any values set using {@link SSLParameters#setApplicationProtocols SSLParameters.setApplicationProtocols}. > > and remove the corresponding section from the return docs (in the {@code String section}). > > the function's first argument enables the current > handshake settings to be inspected.
> -> > the function's first argument allows the current SSLEngine(SSLSocket) to be inspected, including the handshake session and configuration settings.
> > If null is returned, or a value that was not advertised > then the underlying protocol will determine what action > to take. > (For example, ALPN will send a "no_application_protocol" > alert and terminate the connection.) > -> > If the return value is null (no value chosen) or is a value that was not advertised by the peer, the underlying protocol will determine what action to take. (For example, ALPN will send a "no_application_protocol" alert and terminate the connection.) > > Also, TLS should be configured with parameters that > -> > Also, this SSLEngine(SSLSocket) should be configured with parameters that > > @param selector the callback function, or null to de-register. > -> > @param selector the callback function, or null to disable the callback functionality. > > Retrieves the callback function that selects an application protocol > value during the SSL/TLS/DTLS handshake. > -> > Retrieves the callback function that selects an application protocol > value during a SSL/TLS/DTLS handshake. > > This method should be called by TLS protocol implementations during > the TLS handshake. The callback function should not be called until > after the cipher suite has been selected. > > I would suggest removing this apiNote entirely. I expect only applications will call this method, so the first sentence is not necessary since it's up to the implementation how it wants to store the BiFunction. I expect that when the handshaker is initialized, the current BiFunction will be assigned to it, and thus can't be changed for the current handshake/Handshaker in progress. The second sentence ties an ordering to the selection of ciphersuite and ALPN value, and will tie our hands if we ever revisit the group protocol/ciphersuite/SNI/ALPN selection discussion. > > ServerHandshaker.java > ===================== > I was expecting that the ALPN callback logic would be an update for our current ALPN decision logic. If a callback was set, use it, else look at defined strings from the SSLParameters, else fail. e.g. > > ALPNExtension clientHelloALPN = (ALPNExtension) > mesg.extensions.get(ExtensionType.EXT_ALPN); > > if (clientHelloALPN != null) { > List protocols = clientHelloALPN.getPeerAPs(); > if (applicationSelector != null) { > applicationProtocol = > selector.apply(SSLEngine/SSLSocket, peerAPs); > } else if (localApl.length > 0)) { > // Intersect the requested and the locally supported, > // and save for later. Use server preference order > for (String ap : localApl) { > ...deleted... > } > applicationProtocol = negotiatedValue; > } > if (negotiatedValue == null) { > fatalSE(Alerts.alert_no_application_protocol, > new SSLHandshakeException( > "No matching ALPN values")); > } > } > > Thanks. > > Brad > > From sean.mullan at oracle.com Fri Dec 9 21:08:43 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 9 Dec 2016 16:08:43 -0500 Subject: Code Review Request, JDK-8171003, A couple of JSSE tests have been failing after JDK-8170329 In-Reply-To: <3c54a3cf-8fda-eba6-4f9e-71311df1a159@oracle.com> References: <3c54a3cf-8fda-eba6-4f9e-71311df1a159@oracle.com> Message-ID: Looks fine to me. --Sean On 12/9/16 3:54 PM, Xuelei Fan wrote: > Hi, > > Please review this typo issue introduced in JDK-8170329. > > $ hg diff test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java > @Override > - protected boolean isCustomizeClientConnection() { > + protected boolean isCustomizedClientConnection() { > return true; > } > > $ hg diff > test/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java > @Override > - protected boolean isCustomizeClientConnection() { > + protected boolean isCustomizedClientConnection() { > return true; > } > > Thanks, > Xuelei From anthony.scarpino at oracle.com Fri Dec 9 21:09:07 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 9 Dec 2016 13:09:07 -0800 Subject: Code Review Request, JDK-8171003, A couple of JSSE tests have been failing after JDK-8170329 In-Reply-To: <3c54a3cf-8fda-eba6-4f9e-71311df1a159@oracle.com> References: <3c54a3cf-8fda-eba6-4f9e-71311df1a159@oracle.com> Message-ID: <584B1D73.7080304@oracle.com> Looks good. Tony On 12/09/2016 12:54 PM, Xuelei Fan wrote: > Hi, > > Please review this typo issue introduced in JDK-8170329. > > $ hg diff test/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java > @Override > - protected boolean isCustomizeClientConnection() { > + protected boolean isCustomizedClientConnection() { > return true; > } > > $ hg diff > test/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java > @Override > - protected boolean isCustomizeClientConnection() { > + protected boolean isCustomizedClientConnection() { > return true; > } > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri Dec 9 23:03:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 9 Dec 2016 15:03:23 -0800 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: References: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> Message-ID: <747bc4c4-5286-5edb-c33d-4f21066d545e@oracle.com> On 12/8/2016 6:09 PM, David M. Lloyd wrote: > How could it turn out to be incorrect, ... Here is some potentials regarding the cipher suite and application protocol: C1. select cipher suite at first, and then select the application protocol. There is an issue if there is no application protocol suitable to the selected cipher suites [Problem A]. This is what JDK-8170282 wants to address. C2. select application protocol at first, and then select the cipher suite. We have the getHandshakeApplicationProtocol() APIs that can be used to detect if a cipher suite can work with the handshake application protocol. There is an issue if there is no cipher suite suitable to the selected application protocols [Problem B] C3. select application protocol and cipher suite at the same time. The application layer implementation and TLS implementation could be very complicated. We don't want it. With this update (JDK-8170282), we can provide two scenarios for applications. If applications really care about Problem B, they can use #C1; otherwise, #C2 is a more simple solution. http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ The spec part: setHandshakeApplicationProtocolSelector: --------------------------------------- Registers a callback function that selects an application protocol value for a SSL/TLS/DTLS handshake. The function overrides any values set using {@link SSLParameters#setApplicationProtocols SSLParameters.setApplicationProtocols} and it supports the following type parameters: This method would work in server side only. You mention this point in the apiNote part. I'd like to spec this point in the beginning part. The setApplicationProtocols() method is still useful for client side to configure the supported application protocols. In the 2nd paragraph, it may be nice to mention the override only impact the server side behaviors. Except the explicit client application protocols passed in as a parameter, it's no very clear how much information the callback implementation can rely on. For example, can the callback get the negotiated protocol, the negotiated cipher suites and the negotiated server name indicator? I'd like to have a implNote so as to suggest some handshake session fields settings, so that a JSSE provider can have a better sense about how to set the handshake session, and application developer know what kind of information can be retrieved from the handshake session reliably. The implementation part: ServerHandshaker.java --------------------- The current application protocol selection scenarios looks like: 1. select an application protocol independently according to the s/getetApplicationProtocols() spec. (line 536-560). 2. then select an application protocol suitable to the current session context, according to the spec of s/getHandshakeApplicationProtocolSelector() spec. (line 897-909) 3. if no application protocols was selected in #2, use the result in #1. (linr 912-919) 4. if no application protocol was selected, fatal alert (alert_no_application_protocol). (line 912) 5. if a wrong application protocol was selected, fatal alert (alert_no_application_protocol). (line 913) For #4, previous, server just don't response the ALPN extension (old code line 895-897). For better interop, I think we'd better keep this behavior although the spec suggests a fatal response (section 3.2, RFC 7301) . Application layer can handle it better if negotiated application protocol is really required. For #5, it is actually an issue of the callback implementation, I think. The callback implement should select the application protocol from the passed in arrays only. I'd like to use fatal "internal_error" alert instead. Fro #3, it is a little confusing to me, and is not strictly follow the spec. The spec say "overrides" #1 (SSLEngine spec line 1341) and if #2 result is not available or illegal, the underlying impl "will determine" (SSLEngine spec line 1354-1357). I think the spec is fine. To be more simple, I would like to choose one method only, and don't join them together. The joining may make the developer confusing about which method exactly works in the underlying black box. Another side effect is that the cipher suite selector may use the application protocol selected in #1, and then the callback part (#20 may not work unbiasedly as expected. I was thinking that the scenarios may looks like: N1. if callback is not set, select the application protocol independently according to the s/getetApplicationProtocols() spec. N2. if the callback is set, select the application protocol according to the spec of s/getHandshakeApplicationProtocolSelector() spec. N3. if no application protocol can be negotiated, don't use the ALPN extension. N4. if a wrong application protocol was selection, the server side run into an internal problem, fatal with internal_error. Xuelei On 12/9/2016 1:08 PM, Vincent Ryan wrote: > Thanks for your detailed review Brad. I?ve generated a new webrev: > http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ > > > >> On 9 Dec 2016, at 01:34, Bradford Wetmore wrote: >> >> >> Hi Vinnie, >> >> On 12/8/2016 2:18 PM, Vincent Ryan wrote: >>> The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot >>> be easily addressed using the existing ALPN APIs. >>> >>> This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications >>> to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the >>> TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. >>> Additional TLS parameters are also available for inspection in the callback function. >>> >>> This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. >> >> Technically, the API could be used for NPN (though it's pretty much dead), so that would be a listing the options on the server side, and selection on client side. >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ >> >> SSLEngineImpl.java/SSLSocketImpl.java >> ===================================== >> Please use the standard handshaker initialization pattern where the Handshaker is initialized with all of the data/mechanisms needed for a complete handshake. This will will ensure consistent handshake results and avoid potential strange race conditions. (There's some corresponding API comments below.) >> >> You would register your callback after the handshaker.setApplicationProtocols() calls at (currently) line 444 in the SSLEngineImpl code. >> >> >> SSLEngine.java/SSLSocket.java >> ============================= >> I would suggest putting an introduction to this addition in the class description section, that application values can be set using SSLParameters.setApplication...() and selected with the default algorithm, or that a more accurate selection mechanism can be created by registering the callback that could look at any Handshake in progress and make appropriate decisions. >> >> 1339: >> Registers the callback function that selects an application protocol >> value during the SSL/TLS/DTLS handshake. >> -> >> Registers a callback function that selects an application protocol >> value for a SSL/TLS/DTLS handshake. The function overrides any values set using {@link SSLParameters#setApplicationProtocols SSLParameters.setApplicationProtocols}. >> >> and remove the corresponding section from the return docs (in the {@code String section}). >> >> the function's first argument enables the current >> handshake settings to be inspected.
>> -> >> the function's first argument allows the current SSLEngine(SSLSocket) to be inspected, including the handshake session and configuration settings.
>> >> If null is returned, or a value that was not advertised >> then the underlying protocol will determine what action >> to take. >> (For example, ALPN will send a "no_application_protocol" >> alert and terminate the connection.) >> -> >> If the return value is null (no value chosen) or is a value that was not advertised by the peer, the underlying protocol will determine what action to take. (For example, ALPN will send a "no_application_protocol" alert and terminate the connection.) >> >> Also, TLS should be configured with parameters that >> -> >> Also, this SSLEngine(SSLSocket) should be configured with parameters that >> >> @param selector the callback function, or null to de-register. >> -> >> @param selector the callback function, or null to disable the callback functionality. >> >> Retrieves the callback function that selects an application protocol >> value during the SSL/TLS/DTLS handshake. >> -> >> Retrieves the callback function that selects an application protocol >> value during a SSL/TLS/DTLS handshake. >> >> This method should be called by TLS protocol implementations during >> the TLS handshake. The callback function should not be called until >> after the cipher suite has been selected. >> >> I would suggest removing this apiNote entirely. I expect only applications will call this method, so the first sentence is not necessary since it's up to the implementation how it wants to store the BiFunction. I expect that when the handshaker is initialized, the current BiFunction will be assigned to it, and thus can't be changed for the current handshake/Handshaker in progress. The second sentence ties an ordering to the selection of ciphersuite and ALPN value, and will tie our hands if we ever revisit the group protocol/ciphersuite/SNI/ALPN selection discussion. >> >> ServerHandshaker.java >> ===================== >> I was expecting that the ALPN callback logic would be an update for our current ALPN decision logic. If a callback was set, use it, else look at defined strings from the SSLParameters, else fail. e.g. >> >> ALPNExtension clientHelloALPN = (ALPNExtension) >> mesg.extensions.get(ExtensionType.EXT_ALPN); >> >> if (clientHelloALPN != null) { >> List protocols = clientHelloALPN.getPeerAPs(); >> if (applicationSelector != null) { >> applicationProtocol = >> selector.apply(SSLEngine/SSLSocket, peerAPs); >> } else if (localApl.length > 0)) { >> // Intersect the requested and the locally supported, >> // and save for later. Use server preference order >> for (String ap : localApl) { >> ...deleted... >> } >> applicationProtocol = negotiatedValue; >> } >> if (negotiatedValue == null) { >> fatalSE(Alerts.alert_no_application_protocol, >> new SSLHandshakeException( >> "No matching ALPN values")); >> } >> } >> >> Thanks. >> >> Brad >> >> > From bradford.wetmore at oracle.com Fri Dec 9 23:27:00 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 9 Dec 2016 15:27:00 -0800 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: References: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> Message-ID: API looks good. SSLEngineImpl/SSLSocketImpl.java ================================ 212/229: I might suggest a more descriptive variable name, like applicationSelector. "selector" is a bit ambiguous. 450/1379: getHandshakeApplicationProtocolSelector()); -> selector); Xuelei wrote: > This method would work in server side only. You mention this point > in the apiNote part. I'd like to spec this point in the beginning > part. If you do something like this, then you need to be careful to mention something like "application protocols such as ALPN would do this on the server side..." NPN is the reverse, where the server offers the strings, and the client selects. > and application developer know what kind of information can be > retrieved from the handshake session reliably. Whatever you put in here, make sure it can be changed later in case we are able revisit the selection mechanism. > The current application protocol selection scenarios looks like: In my previous response, I suggested a different approach where everything ALPN is done together. I think it may be similar to your N1-4. I look forward to the ServerHandshaker change next week. Brad On 12/9/2016 1:08 PM, Vincent Ryan wrote: > Thanks for your detailed review Brad. I?ve generated a new webrev: > http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ > > > >> On 9 Dec 2016, at 01:34, Bradford Wetmore wrote: >> >> >> Hi Vinnie, >> >> On 12/8/2016 2:18 PM, Vincent Ryan wrote: >>> The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot >>> be easily addressed using the existing ALPN APIs. >>> >>> This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications >>> to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the >>> TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. >>> Additional TLS parameters are also available for inspection in the callback function. >>> >>> This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. >> >> Technically, the API could be used for NPN (though it's pretty much dead), so that would be a listing the options on the server side, and selection on client side. >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ >> >> SSLEngineImpl.java/SSLSocketImpl.java >> ===================================== >> Please use the standard handshaker initialization pattern where the Handshaker is initialized with all of the data/mechanisms needed for a complete handshake. This will will ensure consistent handshake results and avoid potential strange race conditions. (There's some corresponding API comments below.) >> >> You would register your callback after the handshaker.setApplicationProtocols() calls at (currently) line 444 in the SSLEngineImpl code. >> >> >> SSLEngine.java/SSLSocket.java >> ============================= >> I would suggest putting an introduction to this addition in the class description section, that application values can be set using SSLParameters.setApplication...() and selected with the default algorithm, or that a more accurate selection mechanism can be created by registering the callback that could look at any Handshake in progress and make appropriate decisions. >> >> 1339: >> Registers the callback function that selects an application protocol >> value during the SSL/TLS/DTLS handshake. >> -> >> Registers a callback function that selects an application protocol >> value for a SSL/TLS/DTLS handshake. The function overrides any values set using {@link SSLParameters#setApplicationProtocols SSLParameters.setApplicationProtocols}. >> >> and remove the corresponding section from the return docs (in the {@code String section}). >> >> the function's first argument enables the current >> handshake settings to be inspected.
>> -> >> the function's first argument allows the current SSLEngine(SSLSocket) to be inspected, including the handshake session and configuration settings.
>> >> If null is returned, or a value that was not advertised >> then the underlying protocol will determine what action >> to take. >> (For example, ALPN will send a "no_application_protocol" >> alert and terminate the connection.) >> -> >> If the return value is null (no value chosen) or is a value that was not advertised by the peer, the underlying protocol will determine what action to take. (For example, ALPN will send a "no_application_protocol" alert and terminate the connection.) >> >> Also, TLS should be configured with parameters that >> -> >> Also, this SSLEngine(SSLSocket) should be configured with parameters that >> >> @param selector the callback function, or null to de-register. >> -> >> @param selector the callback function, or null to disable the callback functionality. >> >> Retrieves the callback function that selects an application protocol >> value during the SSL/TLS/DTLS handshake. >> -> >> Retrieves the callback function that selects an application protocol >> value during a SSL/TLS/DTLS handshake. >> >> This method should be called by TLS protocol implementations during >> the TLS handshake. The callback function should not be called until >> after the cipher suite has been selected. >> >> I would suggest removing this apiNote entirely. I expect only applications will call this method, so the first sentence is not necessary since it's up to the implementation how it wants to store the BiFunction. I expect that when the handshaker is initialized, the current BiFunction will be assigned to it, and thus can't be changed for the current handshake/Handshaker in progress. The second sentence ties an ordering to the selection of ciphersuite and ALPN value, and will tie our hands if we ever revisit the group protocol/ciphersuite/SNI/ALPN selection discussion. >> >> ServerHandshaker.java >> ===================== >> I was expecting that the ALPN callback logic would be an update for our current ALPN decision logic. If a callback was set, use it, else look at defined strings from the SSLParameters, else fail. e.g. >> >> ALPNExtension clientHelloALPN = (ALPNExtension) >> mesg.extensions.get(ExtensionType.EXT_ALPN); >> >> if (clientHelloALPN != null) { >> List protocols = clientHelloALPN.getPeerAPs(); >> if (applicationSelector != null) { >> applicationProtocol = >> selector.apply(SSLEngine/SSLSocket, peerAPs); >> } else if (localApl.length > 0)) { >> // Intersect the requested and the locally supported, >> // and save for later. Use server preference order >> for (String ap : localApl) { >> ...deleted... >> } >> applicationProtocol = negotiatedValue; >> } >> if (negotiatedValue == null) { >> fatalSE(Alerts.alert_no_application_protocol, >> new SSLHandshakeException( >> "No matching ALPN values")); >> } >> } >> >> Thanks. >> >> Brad >> >> > From sha.jiang at oracle.com Sun Dec 11 12:11:59 2016 From: sha.jiang at oracle.com (John Jiang) Date: Sun, 11 Dec 2016 20:11:59 +0800 Subject: RFR[9] JDK-8171043: ServerIdentityTest.java fails on Windows Message-ID: Hi, Please review this patch for test sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java Before the client get the response, the server may close. Webrev: http://cr.openjdk.java.net/~jjiang/8171043/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8171043 Best regards, John Jiang From weijun.wang at oracle.com Mon Dec 12 02:53:54 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 12 Dec 2016 10:53:54 +0800 Subject: RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool Message-ID: Please take a review at the release note at https://bugs.openjdk.java.net/browse/JDK-8157389 Thanks Max From joe.darcy at oracle.com Mon Dec 12 03:21:10 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 11 Dec 2016 19:21:10 -0800 Subject: JDK 9 RFR of JDK-8171062: Problem list ServerIdentityTest.java on window Message-ID: <431752c5-0345-a7a4-f392-ec175bee9fa3@oracle.com> Hello, Until JDK-8171061 is fixed, the test sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java should be problem listed on windows. Patch below. Thanks, -Joe diff -r b9cdffb87bea test/ProblemList.txt --- a/test/ProblemList.txt Wed Dec 07 10:55:13 2016 -0500 +++ b/test/ProblemList.txt Sun Dec 11 19:19:54 2016 -0800 @@ -223,6 +223,8 @@ sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 macosx-all +sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java 8171061 windows-all + ############################################################################ # jdk_sound From xuelei.fan at oracle.com Mon Dec 12 04:51:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 11 Dec 2016 20:51:37 -0800 Subject: JDK 9 RFR of JDK-8171062: Problem list ServerIdentityTest.java on window In-Reply-To: <431752c5-0345-a7a4-f392-ec175bee9fa3@oracle.com> References: <431752c5-0345-a7a4-f392-ec175bee9fa3@oracle.com> Message-ID: It's OK to me. Thanks, Xuelei On 12/11/2016 7:21 PM, joe darcy wrote: > Hello, > > Until JDK-8171061 is fixed, the test > > sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java > > should be problem listed on windows. > > Patch below. > > Thanks, > > -Joe > > diff -r b9cdffb87bea test/ProblemList.txt > --- a/test/ProblemList.txt Wed Dec 07 10:55:13 2016 -0500 > +++ b/test/ProblemList.txt Sun Dec 11 19:19:54 2016 -0800 > @@ -223,6 +223,8 @@ > > sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 macosx-all > > +sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java 8171061 > windows-all > + > ############################################################################ > > > # jdk_sound > From xuelei.fan at oracle.com Mon Dec 12 05:07:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 11 Dec 2016 21:07:23 -0800 Subject: RFR[9] JDK-8171043: ServerIdentityTest.java fails on Windows In-Reply-To: References: Message-ID: <0ab1766b-735b-4be6-ac79-0d53b1cf2784@oracle.com> Hi John, It's a good catch of the problem. Looks like the server side should read the HTTP request at first, and then write the HTTP response. That's the server call: InputStream sslIS = socket.getInputStream(); sslIS.read(); and then write the "HTTP/1.1, ...". Thanks, Xuelei On 12/11/2016 4:11 AM, John Jiang wrote: > Hi, > Please review this patch for test > sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java > Before the client get the response, the server may close. > > Webrev: http://cr.openjdk.java.net/~jjiang/8171043/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8171043 > > Best regards, > John Jiang > From felix.yang at oracle.com Mon Dec 12 05:41:45 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 12 Dec 2016 13:41:45 +0800 Subject: RFR[9] JDK-8171043: ServerIdentityTest.java fails on Windows In-Reply-To: <0ab1766b-735b-4be6-ac79-0d53b1cf2784@oracle.com> References: <0ab1766b-735b-4be6-ac79-0d53b1cf2784@oracle.com> Message-ID: <90a9246d-789c-48aa-aa43-a04957b3f9bf@oracle.com> +1, it is a good habit to read off the data before closing the connection. Otherwise this may lead to "connection reset " exception sometimes. -Felix On 2016/12/12 13:07, Xuelei Fan wrote: > Hi John, > > It's a good catch of the problem. Looks like the server side should > read the HTTP request at first, and then write the HTTP response. > That's the server call: > InputStream sslIS = socket.getInputStream(); > sslIS.read(); > and then write the "HTTP/1.1, ...". > > Thanks, > Xuelei > > On 12/11/2016 4:11 AM, John Jiang wrote: >> Hi, >> Please review this patch for test >> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java >> Before the client get the response, the server may close. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8171043/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8171043 >> >> Best regards, >> John Jiang >> From weijun.wang at oracle.com Mon Dec 12 09:01:51 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 12 Dec 2016 17:01:51 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission Message-ID: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. Thanks Max From daniel.fuchs at oracle.com Mon Dec 12 10:03:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 Dec 2016 10:03:29 +0000 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: Hi Max, Don't count me as reviewer - but I see a mismatched comment in the file: 209 /** 210 * Creates FilePermission objects with special internals. 211 * See {@link FilePermCompat#newPermPlusAltPath(Permission)} and 212 * {@link FilePermCompat#newPermUsingAltPath(Permission)}. 213 */ 214 215 private static final Path here = builtInFS.getPath( 216 GetPropertyAction.privilegedGetProperty("user.dir")); I guess the comment is a left over from some merge or previous fix? Also I noticed the following later on: 541 * invalid {@code FilePermission}. Even if two {@code FilePermission} 542 * are created with the same invalid path, one does imply the other. should this be: Even if two {@code FilePermission} are created with the same invalid path, one does *not* imply the other. best regards, -- daniel On 12/12/16 09:01, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ > > This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. > > Thanks > Max > From sha.jiang at oracle.com Mon Dec 12 10:29:09 2016 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 12 Dec 2016 18:29:09 +0800 Subject: RFR[9] JDK-8171043: ServerIdentityTest.java fails on Windows In-Reply-To: <0ab1766b-735b-4be6-ac79-0d53b1cf2784@oracle.com> References: <0ab1766b-735b-4be6-ac79-0d53b1cf2784@oracle.com> Message-ID: <7deacb33-af06-141f-fb42-6741072f282b@oracle.com> Hi Xuelei, Thanks for your comments. Please review this new webrev: http://cr.openjdk.java.net/~jjiang/8171043/webrev.01/ Best regards, John Jiang On 2016/12/12 13:07, Xuelei Fan wrote: > Hi John, > > It's a good catch of the problem. Looks like the server side should > read the HTTP request at first, and then write the HTTP response. > That's the server call: > InputStream sslIS = socket.getInputStream(); > sslIS.read(); > and then write the "HTTP/1.1, ...". > > Thanks, > Xuelei > > On 12/11/2016 4:11 AM, John Jiang wrote: >> Hi, >> Please review this patch for test >> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java >> Before the client get the response, the server may close. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8171043/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8171043 >> >> Best regards, >> John Jiang >> > From weijun.wang at oracle.com Mon Dec 12 14:07:15 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 12 Dec 2016 22:07:15 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: > On Dec 12, 2016, at 6:03 PM, Daniel Fuchs wrote: > > Hi Max, > > Don't count me as reviewer - but I see a mismatched comment > in the file: > > 209 /** > 210 * Creates FilePermission objects with special internals. > 211 * See {@link FilePermCompat#newPermPlusAltPath(Permission)} and > 212 * {@link FilePermCompat#newPermUsingAltPath(Permission)}. > 213 */ > 214 > 215 private static final Path here = builtInFS.getPath( > 216 GetPropertyAction.privilegedGetProperty("user.dir")); > > I guess the comment is a left over from some merge or previous fix? These are 2 different methods: "Plus" and "Using". > > > Also I noticed the following later on: > > 541 * invalid {@code FilePermission}. Even if two {@code FilePermission} > 542 * are created with the same invalid path, one does imply the other. > > should this be: > > Even if two {@code FilePermission} are created with the same > invalid path, one does *not* imply the other. Ah, yes. Thanks Max > > best regards, > > -- daniel > > On 12/12/16 09:01, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ >> >> This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. >> >> Thanks >> Max >> > From xuelei.fan at oracle.com Mon Dec 12 17:16:17 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 12 Dec 2016 09:16:17 -0800 Subject: RFR[9] JDK-8171043: ServerIdentityTest.java fails on Windows In-Reply-To: <7deacb33-af06-141f-fb42-6741072f282b@oracle.com> References: <0ab1766b-735b-4be6-ac79-0d53b1cf2784@oracle.com> <7deacb33-af06-141f-fb42-6741072f282b@oracle.com> Message-ID: <13b69606-a38e-1f50-8689-1c6d6ac640df@oracle.com> Looks fine to me. Thanks, Xuelei On 12/12/2016 2:29 AM, John Jiang wrote: > Hi Xuelei, > Thanks for your comments. > Please review this new webrev: > http://cr.openjdk.java.net/~jjiang/8171043/webrev.01/ > > Best regards, > John Jiang > > > On 2016/12/12 13:07, Xuelei Fan wrote: >> Hi John, >> >> It's a good catch of the problem. Looks like the server side should >> read the HTTP request at first, and then write the HTTP response. >> That's the server call: >> InputStream sslIS = socket.getInputStream(); >> sslIS.read(); >> and then write the "HTTP/1.1, ...". >> >> Thanks, >> Xuelei >> >> On 12/11/2016 4:11 AM, John Jiang wrote: >>> Hi, >>> Please review this patch for test >>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java >>> Before the client get the response, the server may close. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8171043/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8171043 >>> >>> Best regards, >>> John Jiang >>> >> > From sean.mullan at oracle.com Mon Dec 12 18:44:12 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 12 Dec 2016 13:44:12 -0500 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider In-Reply-To: <584987B6.6030800@oracle.com> References: <584987B6.6030800@oracle.com> Message-ID: <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> On 12/8/16 11:17 AM, Adam Petcher wrote: > > Subclasses of Signature may have a null provider. In this case, the > debug logging code will throw a NPE when attempting to call getName() on > it. Since this member may be null, I would like to change its type to > Optional to ensure that code checks whether it is present before using > it. I have assumed that getProvider() methods (in both Signature and > Service) always return non-null---if this assumption is incorrect, then > I'll need to change some of the uses of Optional in/around these methods. I think we would want to preserve the current behavior of getProvider returning null for one of these subclasses (even though it isn't specified that null is an acceptable return value). Better to be safe here, otherwise NoSuchElementException would be thrown which would be unexpected and not specified by getProvider. Other than that, just a minor style comment on a few lines of the test: > + private static class NoProviderPublicKey implements PublicKey{ space before "{" --Sean > Note that this issue of missing null checks for providers exists in > several classes (e.g. Cipher, MessageDigest). Once this patch is > reviewed and committed, I will apply the same solution to all other > affected classes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 > > Diff: > > diff --git a/src/java.base/share/classes/java/security/Signature.java > b/src/java.base/share/classes/java/security/Signature.java > --- a/src/java.base/share/classes/java/security/Signature.java > +++ b/src/java.base/share/classes/java/security/Signature.java > @@ -134,7 +134,7 @@ > private String algorithm; > > // The provider > - Provider provider; > + Optional provider = Optional.empty(); > > /** > * Possible {@link #state} value, signifying that > @@ -266,7 +266,7 @@ > SignatureSpi spi = (SignatureSpi)instance.impl; > sig = new Delegate(spi, algorithm); > } > - sig.provider = instance.provider; > + sig.provider = Optional.of(instance.provider); > return sig; > } > > @@ -449,13 +449,17 @@ > */ > public final Provider getProvider() { > chooseFirstProvider(); > - return this.provider; > + return this.provider.get(); > } > > void chooseFirstProvider() { > // empty, overridden in Delegate > } > > + private String getProvidedByString(){ > + return provider.map(x -> " from: " + x.getName()).orElse(""); > + } > + > /** > * Initializes this object for verification. If this method is called > * again with a different argument, it negates the effect > @@ -473,7 +477,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " verification algorithm from: " + > this.provider.getName()); > + " verification algorithm" + getProvidedByString()); > } > } > > @@ -522,7 +526,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " verification algorithm from: " + > this.provider.getName()); > + " verification algorithm" + getProvidedByString()); > } > } > > @@ -543,7 +547,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " signing algorithm from: " + this.provider.getName()); > + " signing algorithm" + getProvidedByString()); > } > } > > @@ -566,7 +570,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " signing algorithm from: " + this.provider.getName()); > + " signing algorithm" + getProvidedByString()); > } > } > > @@ -1087,7 +1091,7 @@ > } > try { > sigSpi = newInstance(s); > - provider = s.getProvider(); > + provider = Optional.of(s.getProvider()); > // not needed any more > firstService = null; > serviceIterator = null; > @@ -1132,7 +1136,7 @@ > try { > SignatureSpi spi = newInstance(s); > init(spi, type, key, random); > - provider = s.getProvider(); > + provider = Optional.of(s.getProvider()); > sigSpi = spi; > firstService = null; > serviceIterator = null; > diff --git a/test/java/security/Signature/NoProvider.java > b/test/java/security/Signature/NoProvider.java > new file mode 100644 > --- /dev/null > +++ b/test/java/security/Signature/NoProvider.java > @@ -0,0 +1,99 @@ > +/* > + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8165751 > + * @summary Verify that that a subclass of Signature that does not > contain a > + * provider can be used verify. > + * @run main/othervm -Djava.security.debug=provider NoProvider > + */ > + > +import java.security.*; > + > +public class NoProvider { > + > + private static class NoProviderPublicKey implements PublicKey{ > + public String getAlgorithm(){ > + return "NoProvider"; > + } > + public String getFormat(){ > + return "none"; > + } > + public byte[] getEncoded(){ > + return new byte[1]; > + } > + } > + > + private static class NoProviderSignature extends Signature{ > + > + public NoProviderSignature(){ > + super("NoProvider"); > + } > + > + protected void engineInitVerify(PublicKey publicKey) > + throws InvalidKeyException{ > + // do nothing > + } > + > + protected void engineInitSign(PrivateKey privateKey) > + throws InvalidKeyException{ > + // do nothing > + } > + > + protected void engineUpdate(byte b) throws SignatureException{ > + // do nothing > + } > + > + protected void engineUpdate(byte[] b, int off, int len) > + throws SignatureException{ > + // do nothing > + } > + > + protected byte[] engineSign() throws SignatureException{ > + return new byte[1]; > + } > + > + protected boolean engineVerify(byte[] sigBytes) > + throws SignatureException{ > + return false; > + } > + > + @Deprecated > + protected void engineSetParameter(String param, Object value) > + throws InvalidParameterException{ > + // do nothing > + } > + > + @Deprecated > + protected Object engineGetParameter(String param) > + throws InvalidParameterException{ > + return null; > + } > + > + } > + > + public static void main(String[] args) throws Exception { > + new NoProviderSignature().initVerify(new NoProviderPublicKey()); > + } > +} From adam.petcher at oracle.com Mon Dec 12 20:05:02 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 12 Dec 2016 15:05:02 -0500 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider In-Reply-To: <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> Message-ID: <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> Okay. I changed getProvider() to return this.provider.orElse(null), which will allow this method to return null. For consistency, I allow all other providers (in Instance and Service) to be null using Optional.ofNullable(). Hopefully, I found and fixed all the whitespace issues, too. Here is the corrected diff: diff --git a/src/java.base/share/classes/java/security/Signature.java b/src/java.base/share/classes/java/security/Signature.java --- a/src/java.base/share/classes/java/security/Signature.java +++ b/src/java.base/share/classes/java/security/Signature.java @@ -134,7 +134,7 @@ private String algorithm; // The provider - Provider provider; + Optional provider = Optional.empty(); /** * Possible {@link #state} value, signifying that @@ -266,7 +266,7 @@ SignatureSpi spi = (SignatureSpi)instance.impl; sig = new Delegate(spi, algorithm); } - sig.provider = instance.provider; + sig.provider = Optional.ofNullable(instance.provider); return sig; } @@ -449,13 +449,17 @@ */ public final Provider getProvider() { chooseFirstProvider(); - return this.provider; + return this.provider.orElse(null); } void chooseFirstProvider() { // empty, overridden in Delegate } + private String getProvidedByString() { + return provider.map(x -> " from: " + x.getName()).orElse(""); + } + /** * Initializes this object for verification. If this method is called * again with a different argument, it negates the effect @@ -473,7 +477,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " verification algorithm from: " + this.provider.getName()); + " verification algorithm" + getProvidedByString()); } } @@ -522,7 +526,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " verification algorithm from: " + this.provider.getName()); + " verification algorithm" + getProvidedByString()); } } @@ -543,7 +547,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " signing algorithm from: " + this.provider.getName()); + " signing algorithm" + getProvidedByString()); } } @@ -566,7 +570,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " signing algorithm from: " + this.provider.getName()); + " signing algorithm" + getProvidedByString()); } } @@ -1087,7 +1091,7 @@ } try { sigSpi = newInstance(s); - provider = s.getProvider(); + provider = Optional.ofNullable(s.getProvider()); // not needed any more firstService = null; serviceIterator = null; @@ -1132,7 +1136,7 @@ try { SignatureSpi spi = newInstance(s); init(spi, type, key, random); - provider = s.getProvider(); + provider = Optional.ofNullable(s.getProvider()); sigSpi = spi; firstService = null; serviceIterator = null; diff --git a/test/java/security/Signature/NoProvider.java b/test/java/security/Signature/NoProvider.java new file mode 100644 --- /dev/null +++ b/test/java/security/Signature/NoProvider.java @@ -0,0 +1,99 @@ +/* + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8165751 + * @summary Verify that that a subclass of Signature that does not contain a + * provider can be used verify. + * @run main/othervm -Djava.security.debug=provider NoProvider + */ + +import java.security.*; + +public class NoProvider { + + private static class NoProviderPublicKey implements PublicKey { + + public String getAlgorithm() { + return "NoProvider"; + } + public String getFormat() { + return "none"; + } + public byte[] getEncoded() { + return new byte[1]; + } + } + + private static class NoProviderSignature extends Signature { + + public NoProviderSignature() { + super("NoProvider"); + } + + protected void engineInitVerify(PublicKey publicKey) + throws InvalidKeyException { + // do nothing + } + + protected void engineInitSign(PrivateKey privateKey) + throws InvalidKeyException { + // do nothing + } + + protected void engineUpdate(byte b) throws SignatureException { + // do nothing + } + + protected void engineUpdate(byte[] b, int off, int len) + throws SignatureException { + // do nothing + } + + protected byte[] engineSign() throws SignatureException { + return new byte[1]; + } + + protected boolean engineVerify(byte[] sigBytes) + throws SignatureException { + return false; + } + + @Deprecated + protected void engineSetParameter(String param, Object value) + throws InvalidParameterException { + // do nothing + } + + @Deprecated + protected Object engineGetParameter(String param) + throws InvalidParameterException { + return null; + } + } + + public static void main(String[] args) throws Exception { + new NoProviderSignature().initVerify(new NoProviderPublicKey()); + } +} On 12/12/2016 1:44 PM, Sean Mullan wrote: > On 12/8/16 11:17 AM, Adam Petcher wrote: >> >> Subclasses of Signature may have a null provider. In this case, the >> debug logging code will throw a NPE when attempting to call getName() on >> it. Since this member may be null, I would like to change its type to >> Optional to ensure that code checks whether it is present before using >> it. I have assumed that getProvider() methods (in both Signature and >> Service) always return non-null---if this assumption is incorrect, then >> I'll need to change some of the uses of Optional in/around these >> methods. > > I think we would want to preserve the current behavior of getProvider > returning null for one of these subclasses (even though it isn't > specified that null is an acceptable return value). Better to be safe > here, otherwise NoSuchElementException would be thrown which would be > unexpected and not specified by getProvider. > > Other than that, just a minor style comment on a few lines of the test: > > > + private static class NoProviderPublicKey implements PublicKey{ > > space before "{" > > --Sean > >> Note that this issue of missing null checks for providers exists in >> several classes (e.g. Cipher, MessageDigest). Once this patch is >> reviewed and committed, I will apply the same solution to all other >> affected classes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 >> >> Diff: >> >> diff --git a/src/java.base/share/classes/java/security/Signature.java >> b/src/java.base/share/classes/java/security/Signature.java >> --- a/src/java.base/share/classes/java/security/Signature.java >> +++ b/src/java.base/share/classes/java/security/Signature.java >> @@ -134,7 +134,7 @@ >> private String algorithm; >> >> // The provider >> - Provider provider; >> + Optional provider = Optional.empty(); >> >> /** >> * Possible {@link #state} value, signifying that >> @@ -266,7 +266,7 @@ >> SignatureSpi spi = (SignatureSpi)instance.impl; >> sig = new Delegate(spi, algorithm); >> } >> - sig.provider = instance.provider; >> + sig.provider = Optional.of(instance.provider); >> return sig; >> } >> >> @@ -449,13 +449,17 @@ >> */ >> public final Provider getProvider() { >> chooseFirstProvider(); >> - return this.provider; >> + return this.provider.get(); >> } >> >> void chooseFirstProvider() { >> // empty, overridden in Delegate >> } >> >> + private String getProvidedByString(){ >> + return provider.map(x -> " from: " + x.getName()).orElse(""); >> + } >> + >> /** >> * Initializes this object for verification. If this method is >> called >> * again with a different argument, it negates the effect >> @@ -473,7 +477,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " verification algorithm from: " + >> this.provider.getName()); >> + " verification algorithm" + getProvidedByString()); >> } >> } >> >> @@ -522,7 +526,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " verification algorithm from: " + >> this.provider.getName()); >> + " verification algorithm" + getProvidedByString()); >> } >> } >> >> @@ -543,7 +547,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " signing algorithm from: " + this.provider.getName()); >> + " signing algorithm" + getProvidedByString()); >> } >> } >> >> @@ -566,7 +570,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " signing algorithm from: " + this.provider.getName()); >> + " signing algorithm" + getProvidedByString()); >> } >> } >> >> @@ -1087,7 +1091,7 @@ >> } >> try { >> sigSpi = newInstance(s); >> - provider = s.getProvider(); >> + provider = Optional.of(s.getProvider()); >> // not needed any more >> firstService = null; >> serviceIterator = null; >> @@ -1132,7 +1136,7 @@ >> try { >> SignatureSpi spi = newInstance(s); >> init(spi, type, key, random); >> - provider = s.getProvider(); >> + provider = Optional.of(s.getProvider()); >> sigSpi = spi; >> firstService = null; >> serviceIterator = null; >> diff --git a/test/java/security/Signature/NoProvider.java >> b/test/java/security/Signature/NoProvider.java >> new file mode 100644 >> --- /dev/null >> +++ b/test/java/security/Signature/NoProvider.java >> @@ -0,0 +1,99 @@ >> +/* >> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights >> reserved. >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> + * >> + * This code is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 only, as >> + * published by the Free Software Foundation. >> + * >> + * This code is distributed in the hope that it will be useful, but >> WITHOUT >> + * ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >> License >> + * version 2 for more details (a copy is included in the LICENSE >> file that >> + * accompanied this code). >> + * >> + * You should have received a copy of the GNU General Public License >> version >> + * 2 along with this work; if not, write to the Free Software >> Foundation, >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> + * >> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> + * or visit www.oracle.com if you need additional information or >> have any >> + * questions. >> + */ >> + >> +/* >> + * @test >> + * @bug 8165751 >> + * @summary Verify that that a subclass of Signature that does not >> contain a >> + * provider can be used verify. >> + * @run main/othervm -Djava.security.debug=provider NoProvider >> + */ >> + >> +import java.security.*; >> + >> +public class NoProvider { >> + >> + private static class NoProviderPublicKey implements PublicKey{ >> + public String getAlgorithm(){ >> + return "NoProvider"; >> + } >> + public String getFormat(){ >> + return "none"; >> + } >> + public byte[] getEncoded(){ >> + return new byte[1]; >> + } >> + } >> + >> + private static class NoProviderSignature extends Signature{ >> + >> + public NoProviderSignature(){ >> + super("NoProvider"); >> + } >> + >> + protected void engineInitVerify(PublicKey publicKey) >> + throws InvalidKeyException{ >> + // do nothing >> + } >> + >> + protected void engineInitSign(PrivateKey privateKey) >> + throws InvalidKeyException{ >> + // do nothing >> + } >> + >> + protected void engineUpdate(byte b) throws SignatureException{ >> + // do nothing >> + } >> + >> + protected void engineUpdate(byte[] b, int off, int len) >> + throws SignatureException{ >> + // do nothing >> + } >> + >> + protected byte[] engineSign() throws SignatureException{ >> + return new byte[1]; >> + } >> + >> + protected boolean engineVerify(byte[] sigBytes) >> + throws SignatureException{ >> + return false; >> + } >> + >> + @Deprecated >> + protected void engineSetParameter(String param, Object value) >> + throws InvalidParameterException{ >> + // do nothing >> + } >> + >> + @Deprecated >> + protected Object engineGetParameter(String param) >> + throws InvalidParameterException{ >> + return null; >> + } >> + >> + } >> + >> + public static void main(String[] args) throws Exception { >> + new NoProviderSignature().initVerify(new >> NoProviderPublicKey()); >> + } >> +} From amanda.jiang at oracle.com Mon Dec 12 22:43:53 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 12 Dec 2016 14:43:53 -0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar Message-ID: Hi All, Please help to review following changeset, which tests that jarsigner tool works with multi-release JAR files. Webrev: http://cr.openjdk.java.net/~amjiang/8075618/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8075618 Thanks, Amanda From paul.sandoz at oracle.com Mon Dec 12 23:37:44 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Dec 2016 15:37:44 -0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: References: Message-ID: Hi, +1 (I am not really an expert on jar signing but the basic test looks fine). Some minor comments below, no need for another review. Paul. 113 Stream.of(sourceFiles).map(Object::toString).forEach(x -> launcher.addToolArg(x)); 119 Stream.of(args).forEach(x -> launcher.addToolArg(x)); If you like you can do: launcher::addToolArg 148 private static OutputAnalyzer verify (String signedJarName) throws Throwable { Rogue ? ? between the method name and it?s parameter list. > On 12 Dec 2016, at 14:43, Amanda Jiang wrote: > > Hi All, > > Please help to review following changeset, which tests that jarsigner tool works with multi-release JAR files. > > Webrev: http://cr.openjdk.java.net/~amjiang/8075618/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8075618 > > > Thanks, > Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From artem.smotrakov at oracle.com Tue Dec 13 01:22:00 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 12 Dec 2016 17:22:00 -0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: References: Message-ID: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> You can use http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java which would simplify the code. This lib was added to be used in such tests. Note that SecurityTools addresses a couple of known issues with running security tools on machines with different locales, please see "user.language" and "user.country" system properties Artem On 12/12/2016 02:43 PM, Amanda Jiang wrote: > Hi All, > > Please help to review following changeset, which tests that jarsigner > tool works with multi-release JAR files. > > Webrev: http://cr.openjdk.java.net/~amjiang/8075618/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8075618 > > > Thanks, > Amanda From weijun.wang at oracle.com Tue Dec 13 02:20:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 13 Dec 2016 10:20:46 +0800 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider In-Reply-To: <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> Message-ID: Hi Adam The only behavior change is with the debug output, right? Is this a new pattern that internal optional fields should be defined as an Optional? And, when there is no provider the string form "from: " looks strange, I would rather make it "from nowhere". I would also move the space before "from" to where the method is called, say, " verification algorithm " + getProvidedByString(). Thanks Max > On Dec 13, 2016, at 4:05 AM, Adam Petcher wrote: > > Okay. I changed getProvider() to return this.provider.orElse(null), which will allow this method to return null. For consistency, I allow all other providers (in Instance and Service) to be null using Optional.ofNullable(). Hopefully, I found and fixed all the whitespace issues, too. Here is the corrected diff: > > diff --git a/src/java.base/share/classes/java/security/Signature.java b/src/java.base/share/classes/java/security/Signature.java > --- a/src/java.base/share/classes/java/security/Signature.java > +++ b/src/java.base/share/classes/java/security/Signature.java > @@ -134,7 +134,7 @@ > private String algorithm; > > // The provider > - Provider provider; > + Optional provider = Optional.empty(); > > /** > * Possible {@link #state} value, signifying that > @@ -266,7 +266,7 @@ > SignatureSpi spi = (SignatureSpi)instance.impl; > sig = new Delegate(spi, algorithm); > } > - sig.provider = instance.provider; > + sig.provider = Optional.ofNullable(instance.provider); > return sig; > } > > @@ -449,13 +449,17 @@ > */ > public final Provider getProvider() { > chooseFirstProvider(); > - return this.provider; > + return this.provider.orElse(null); > } > > void chooseFirstProvider() { > // empty, overridden in Delegate > } > > + private String getProvidedByString() { > + return provider.map(x -> " from: " + x.getName()).orElse(""); > + } > + > /** > * Initializes this object for verification. If this method is called > * again with a different argument, it negates the effect > @@ -473,7 +477,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " verification algorithm from: " + this.provider.getName()); > + " verification algorithm" + getProvidedByString()); > } > } > > @@ -522,7 +526,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " verification algorithm from: " + this.provider.getName()); > + " verification algorithm" + getProvidedByString()); > } > } > > @@ -543,7 +547,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " signing algorithm from: " + this.provider.getName()); > + " signing algorithm" + getProvidedByString()); > } > } > > @@ -566,7 +570,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " signing algorithm from: " + this.provider.getName()); > + " signing algorithm" + getProvidedByString()); > } > } > > @@ -1087,7 +1091,7 @@ > } > try { > sigSpi = newInstance(s); > - provider = s.getProvider(); > + provider = Optional.ofNullable(s.getProvider()); > // not needed any more > firstService = null; > serviceIterator = null; > @@ -1132,7 +1136,7 @@ > try { > SignatureSpi spi = newInstance(s); > init(spi, type, key, random); > - provider = s.getProvider(); > + provider = Optional.ofNullable(s.getProvider()); > sigSpi = spi; > firstService = null; > serviceIterator = null; > diff --git a/test/java/security/Signature/NoProvider.java b/test/java/security/Signature/NoProvider.java > new file mode 100644 > --- /dev/null > +++ b/test/java/security/Signature/NoProvider.java > @@ -0,0 +1,99 @@ > +/* > + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8165751 > + * @summary Verify that that a subclass of Signature that does not contain a > + * provider can be used verify. > + * @run main/othervm -Djava.security.debug=provider NoProvider > + */ > + > +import java.security.*; > + > +public class NoProvider { > + > + private static class NoProviderPublicKey implements PublicKey { > + > + public String getAlgorithm() { > + return "NoProvider"; > + } > + public String getFormat() { > + return "none"; > + } > + public byte[] getEncoded() { > + return new byte[1]; > + } > + } > + > + private static class NoProviderSignature extends Signature { > + > + public NoProviderSignature() { > + super("NoProvider"); > + } > + > + protected void engineInitVerify(PublicKey publicKey) > + throws InvalidKeyException { > + // do nothing > + } > + > + protected void engineInitSign(PrivateKey privateKey) > + throws InvalidKeyException { > + // do nothing > + } > + > + protected void engineUpdate(byte b) throws SignatureException { > + // do nothing > + } > + > + protected void engineUpdate(byte[] b, int off, int len) > + throws SignatureException { > + // do nothing > + } > + > + protected byte[] engineSign() throws SignatureException { > + return new byte[1]; > + } > + > + protected boolean engineVerify(byte[] sigBytes) > + throws SignatureException { > + return false; > + } > + > + @Deprecated > + protected void engineSetParameter(String param, Object value) > + throws InvalidParameterException { > + // do nothing > + } > + > + @Deprecated > + protected Object engineGetParameter(String param) > + throws InvalidParameterException { > + return null; > + } > + } > + > + public static void main(String[] args) throws Exception { > + new NoProviderSignature().initVerify(new NoProviderPublicKey()); > + } > +} > > > On 12/12/2016 1:44 PM, Sean Mullan wrote: >> On 12/8/16 11:17 AM, Adam Petcher wrote: >>> >>> Subclasses of Signature may have a null provider. In this case, the >>> debug logging code will throw a NPE when attempting to call getName() on >>> it. Since this member may be null, I would like to change its type to >>> Optional to ensure that code checks whether it is present before using >>> it. I have assumed that getProvider() methods (in both Signature and >>> Service) always return non-null---if this assumption is incorrect, then >>> I'll need to change some of the uses of Optional in/around these methods. >> >> I think we would want to preserve the current behavior of getProvider returning null for one of these subclasses (even though it isn't specified that null is an acceptable return value). Better to be safe here, otherwise NoSuchElementException would be thrown which would be unexpected and not specified by getProvider. >> >> Other than that, just a minor style comment on a few lines of the test: >> >> > + private static class NoProviderPublicKey implements PublicKey{ >> >> space before "{" >> >> --Sean >> >>> Note that this issue of missing null checks for providers exists in >>> several classes (e.g. Cipher, MessageDigest). Once this patch is >>> reviewed and committed, I will apply the same solution to all other >>> affected classes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 >>> >>> Diff: >>> >>> diff --git a/src/java.base/share/classes/java/security/Signature.java >>> b/src/java.base/share/classes/java/security/Signature.java >>> --- a/src/java.base/share/classes/java/security/Signature.java >>> +++ b/src/java.base/share/classes/java/security/Signature.java >>> @@ -134,7 +134,7 @@ >>> private String algorithm; >>> >>> // The provider >>> - Provider provider; >>> + Optional provider = Optional.empty(); >>> >>> /** >>> * Possible {@link #state} value, signifying that >>> @@ -266,7 +266,7 @@ >>> SignatureSpi spi = (SignatureSpi)instance.impl; >>> sig = new Delegate(spi, algorithm); >>> } >>> - sig.provider = instance.provider; >>> + sig.provider = Optional.of(instance.provider); >>> return sig; >>> } >>> >>> @@ -449,13 +449,17 @@ >>> */ >>> public final Provider getProvider() { >>> chooseFirstProvider(); >>> - return this.provider; >>> + return this.provider.get(); >>> } >>> >>> void chooseFirstProvider() { >>> // empty, overridden in Delegate >>> } >>> >>> + private String getProvidedByString(){ >>> + return provider.map(x -> " from: " + x.getName()).orElse(""); >>> + } >>> + >>> /** >>> * Initializes this object for verification. If this method is called >>> * again with a different argument, it negates the effect >>> @@ -473,7 +477,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " verification algorithm from: " + >>> this.provider.getName()); >>> + " verification algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -522,7 +526,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " verification algorithm from: " + >>> this.provider.getName()); >>> + " verification algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -543,7 +547,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " signing algorithm from: " + this.provider.getName()); >>> + " signing algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -566,7 +570,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " signing algorithm from: " + this.provider.getName()); >>> + " signing algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -1087,7 +1091,7 @@ >>> } >>> try { >>> sigSpi = newInstance(s); >>> - provider = s.getProvider(); >>> + provider = Optional.of(s.getProvider()); >>> // not needed any more >>> firstService = null; >>> serviceIterator = null; >>> @@ -1132,7 +1136,7 @@ >>> try { >>> SignatureSpi spi = newInstance(s); >>> init(spi, type, key, random); >>> - provider = s.getProvider(); >>> + provider = Optional.of(s.getProvider()); >>> sigSpi = spi; >>> firstService = null; >>> serviceIterator = null; >>> diff --git a/test/java/security/Signature/NoProvider.java >>> b/test/java/security/Signature/NoProvider.java >>> new file mode 100644 >>> --- /dev/null >>> +++ b/test/java/security/Signature/NoProvider.java >>> @@ -0,0 +1,99 @@ >>> +/* >>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> + * >>> + * This code is free software; you can redistribute it and/or modify it >>> + * under the terms of the GNU General Public License version 2 only, as >>> + * published by the Free Software Foundation. >>> + * >>> + * This code is distributed in the hope that it will be useful, but >>> WITHOUT >>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >>> + * version 2 for more details (a copy is included in the LICENSE file that >>> + * accompanied this code). >>> + * >>> + * You should have received a copy of the GNU General Public License >>> version >>> + * 2 along with this work; if not, write to the Free Software Foundation, >>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>> + * >>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >>> + * or visit www.oracle.com if you need additional information or have any >>> + * questions. >>> + */ >>> + >>> +/* >>> + * @test >>> + * @bug 8165751 >>> + * @summary Verify that that a subclass of Signature that does not >>> contain a >>> + * provider can be used verify. >>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>> + */ >>> + >>> +import java.security.*; >>> + >>> +public class NoProvider { >>> + >>> + private static class NoProviderPublicKey implements PublicKey{ >>> + public String getAlgorithm(){ >>> + return "NoProvider"; >>> + } >>> + public String getFormat(){ >>> + return "none"; >>> + } >>> + public byte[] getEncoded(){ >>> + return new byte[1]; >>> + } >>> + } >>> + >>> + private static class NoProviderSignature extends Signature{ >>> + >>> + public NoProviderSignature(){ >>> + super("NoProvider"); >>> + } >>> + >>> + protected void engineInitVerify(PublicKey publicKey) >>> + throws InvalidKeyException{ >>> + // do nothing >>> + } >>> + >>> + protected void engineInitSign(PrivateKey privateKey) >>> + throws InvalidKeyException{ >>> + // do nothing >>> + } >>> + >>> + protected void engineUpdate(byte b) throws SignatureException{ >>> + // do nothing >>> + } >>> + >>> + protected void engineUpdate(byte[] b, int off, int len) >>> + throws SignatureException{ >>> + // do nothing >>> + } >>> + >>> + protected byte[] engineSign() throws SignatureException{ >>> + return new byte[1]; >>> + } >>> + >>> + protected boolean engineVerify(byte[] sigBytes) >>> + throws SignatureException{ >>> + return false; >>> + } >>> + >>> + @Deprecated >>> + protected void engineSetParameter(String param, Object value) >>> + throws InvalidParameterException{ >>> + // do nothing >>> + } >>> + >>> + @Deprecated >>> + protected Object engineGetParameter(String param) >>> + throws InvalidParameterException{ >>> + return null; >>> + } >>> + >>> + } >>> + >>> + public static void main(String[] args) throws Exception { >>> + new NoProviderSignature().initVerify(new NoProviderPublicKey()); >>> + } >>> +} > From weijun.wang at oracle.com Tue Dec 13 02:31:58 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 13 Dec 2016 10:31:58 +0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> References: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> Message-ID: Hi Amanda Can you also test the new JarSigner API? http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd line 2.72 has an example on it. > On Dec 13, 2016, at 9:22 AM, Artem Smotrakov wrote: > > You can use http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java which would simplify the code. This lib was added to be used in such tests. Correct. I also wonder if there are existing methods on javac compilation. Do we have existing tests on checking if a signed multi-version jar works as expected? Say, permission granted, getCertificates() returning non-null, etc? Thanks Max From weijun.wang at oracle.com Tue Dec 13 02:50:50 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 13 Dec 2016 10:50:50 +0800 Subject: On 8171135: Include javadoc on JarSigner API in security doc Message-ID: <57547857-FBA1-4857-A954-70FDEDA64709@oracle.com> Hi All I've create a new bug to include the javadoc of the non-Java SE JarSigner API into security doc: https://bugs.openjdk.java.net/browse/JDK-8171135 If you think this is OK, I'll move the bug to doc. Thanks Max From adam.petcher at oracle.com Tue Dec 13 16:30:39 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 13 Dec 2016 11:30:39 -0500 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider In-Reply-To: References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> Message-ID: <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> Thanks for the review. After thinking about this some more, I don't like the idea of using Optional for a member variable due to the limitations of this class and the lack of support for this usage of it. I'll send out a new diff that uses a standard null check. See below for other comments. On 12/12/2016 9:20 PM, Wang Weijun wrote: > Hi Adam > > The only behavior change is with the debug output, right? Yes. This will be more obvious in my next diff. > > Is this a new pattern that internal optional fields should be defined as an Optional? > > And, when there is no provider the string form "from: " looks strange, I would rather make it "from nowhere". I would also move the space before "from" to where the method is called, say, " verification algorithm " + getProvidedByString(). It doesn't print the "from: " when there is no provider. So the string will look like "Signature.DSA verification algorithm" in this case. I don't have a strong opinion on whether we should print "from: no provider" (for example), but Sean expressed a preference for leaving this entire part blank when there is no provider (as it is in my last diff). > > Thanks > Max > >> On Dec 13, 2016, at 4:05 AM, Adam Petcher wrote: >> >> Okay. I changed getProvider() to return this.provider.orElse(null), which will allow this method to return null. For consistency, I allow all other providers (in Instance and Service) to be null using Optional.ofNullable(). Hopefully, I found and fixed all the whitespace issues, too. Here is the corrected diff: >> >> diff --git a/src/java.base/share/classes/java/security/Signature.java b/src/java.base/share/classes/java/security/Signature.java >> --- a/src/java.base/share/classes/java/security/Signature.java >> +++ b/src/java.base/share/classes/java/security/Signature.java >> @@ -134,7 +134,7 @@ >> private String algorithm; >> >> // The provider >> - Provider provider; >> + Optional provider = Optional.empty(); >> >> /** >> * Possible {@link #state} value, signifying that >> @@ -266,7 +266,7 @@ >> SignatureSpi spi = (SignatureSpi)instance.impl; >> sig = new Delegate(spi, algorithm); >> } >> - sig.provider = instance.provider; >> + sig.provider = Optional.ofNullable(instance.provider); >> return sig; >> } >> >> @@ -449,13 +449,17 @@ >> */ >> public final Provider getProvider() { >> chooseFirstProvider(); >> - return this.provider; >> + return this.provider.orElse(null); >> } >> >> void chooseFirstProvider() { >> // empty, overridden in Delegate >> } >> >> + private String getProvidedByString() { >> + return provider.map(x -> " from: " + x.getName()).orElse(""); >> + } >> + >> /** >> * Initializes this object for verification. If this method is called >> * again with a different argument, it negates the effect >> @@ -473,7 +477,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " verification algorithm from: " + this.provider.getName()); >> + " verification algorithm" + getProvidedByString()); >> } >> } >> >> @@ -522,7 +526,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " verification algorithm from: " + this.provider.getName()); >> + " verification algorithm" + getProvidedByString()); >> } >> } >> >> @@ -543,7 +547,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " signing algorithm from: " + this.provider.getName()); >> + " signing algorithm" + getProvidedByString()); >> } >> } >> >> @@ -566,7 +570,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Signature." + algorithm + >> - " signing algorithm from: " + this.provider.getName()); >> + " signing algorithm" + getProvidedByString()); >> } >> } >> >> @@ -1087,7 +1091,7 @@ >> } >> try { >> sigSpi = newInstance(s); >> - provider = s.getProvider(); >> + provider = Optional.ofNullable(s.getProvider()); >> // not needed any more >> firstService = null; >> serviceIterator = null; >> @@ -1132,7 +1136,7 @@ >> try { >> SignatureSpi spi = newInstance(s); >> init(spi, type, key, random); >> - provider = s.getProvider(); >> + provider = Optional.ofNullable(s.getProvider()); >> sigSpi = spi; >> firstService = null; >> serviceIterator = null; >> diff --git a/test/java/security/Signature/NoProvider.java b/test/java/security/Signature/NoProvider.java >> new file mode 100644 >> --- /dev/null >> +++ b/test/java/security/Signature/NoProvider.java >> @@ -0,0 +1,99 @@ >> +/* >> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> + * >> + * This code is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 only, as >> + * published by the Free Software Foundation. >> + * >> + * This code is distributed in the hope that it will be useful, but WITHOUT >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> + * version 2 for more details (a copy is included in the LICENSE file that >> + * accompanied this code). >> + * >> + * You should have received a copy of the GNU General Public License version >> + * 2 along with this work; if not, write to the Free Software Foundation, >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> + * >> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >> + * or visit www.oracle.com if you need additional information or have any >> + * questions. >> + */ >> + >> +/* >> + * @test >> + * @bug 8165751 >> + * @summary Verify that that a subclass of Signature that does not contain a >> + * provider can be used verify. >> + * @run main/othervm -Djava.security.debug=provider NoProvider >> + */ >> + >> +import java.security.*; >> + >> +public class NoProvider { >> + >> + private static class NoProviderPublicKey implements PublicKey { >> + >> + public String getAlgorithm() { >> + return "NoProvider"; >> + } >> + public String getFormat() { >> + return "none"; >> + } >> + public byte[] getEncoded() { >> + return new byte[1]; >> + } >> + } >> + >> + private static class NoProviderSignature extends Signature { >> + >> + public NoProviderSignature() { >> + super("NoProvider"); >> + } >> + >> + protected void engineInitVerify(PublicKey publicKey) >> + throws InvalidKeyException { >> + // do nothing >> + } >> + >> + protected void engineInitSign(PrivateKey privateKey) >> + throws InvalidKeyException { >> + // do nothing >> + } >> + >> + protected void engineUpdate(byte b) throws SignatureException { >> + // do nothing >> + } >> + >> + protected void engineUpdate(byte[] b, int off, int len) >> + throws SignatureException { >> + // do nothing >> + } >> + >> + protected byte[] engineSign() throws SignatureException { >> + return new byte[1]; >> + } >> + >> + protected boolean engineVerify(byte[] sigBytes) >> + throws SignatureException { >> + return false; >> + } >> + >> + @Deprecated >> + protected void engineSetParameter(String param, Object value) >> + throws InvalidParameterException { >> + // do nothing >> + } >> + >> + @Deprecated >> + protected Object engineGetParameter(String param) >> + throws InvalidParameterException { >> + return null; >> + } >> + } >> + >> + public static void main(String[] args) throws Exception { >> + new NoProviderSignature().initVerify(new NoProviderPublicKey()); >> + } >> +} >> >> >> On 12/12/2016 1:44 PM, Sean Mullan wrote: >>> On 12/8/16 11:17 AM, Adam Petcher wrote: >>>> Subclasses of Signature may have a null provider. In this case, the >>>> debug logging code will throw a NPE when attempting to call getName() on >>>> it. Since this member may be null, I would like to change its type to >>>> Optional to ensure that code checks whether it is present before using >>>> it. I have assumed that getProvider() methods (in both Signature and >>>> Service) always return non-null---if this assumption is incorrect, then >>>> I'll need to change some of the uses of Optional in/around these methods. >>> I think we would want to preserve the current behavior of getProvider returning null for one of these subclasses (even though it isn't specified that null is an acceptable return value). Better to be safe here, otherwise NoSuchElementException would be thrown which would be unexpected and not specified by getProvider. >>> >>> Other than that, just a minor style comment on a few lines of the test: >>> >>>> + private static class NoProviderPublicKey implements PublicKey{ >>> space before "{" >>> >>> --Sean >>> >>>> Note that this issue of missing null checks for providers exists in >>>> several classes (e.g. Cipher, MessageDigest). Once this patch is >>>> reviewed and committed, I will apply the same solution to all other >>>> affected classes. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 >>>> >>>> Diff: >>>> >>>> diff --git a/src/java.base/share/classes/java/security/Signature.java >>>> b/src/java.base/share/classes/java/security/Signature.java >>>> --- a/src/java.base/share/classes/java/security/Signature.java >>>> +++ b/src/java.base/share/classes/java/security/Signature.java >>>> @@ -134,7 +134,7 @@ >>>> private String algorithm; >>>> >>>> // The provider >>>> - Provider provider; >>>> + Optional provider = Optional.empty(); >>>> >>>> /** >>>> * Possible {@link #state} value, signifying that >>>> @@ -266,7 +266,7 @@ >>>> SignatureSpi spi = (SignatureSpi)instance.impl; >>>> sig = new Delegate(spi, algorithm); >>>> } >>>> - sig.provider = instance.provider; >>>> + sig.provider = Optional.of(instance.provider); >>>> return sig; >>>> } >>>> >>>> @@ -449,13 +449,17 @@ >>>> */ >>>> public final Provider getProvider() { >>>> chooseFirstProvider(); >>>> - return this.provider; >>>> + return this.provider.get(); >>>> } >>>> >>>> void chooseFirstProvider() { >>>> // empty, overridden in Delegate >>>> } >>>> >>>> + private String getProvidedByString(){ >>>> + return provider.map(x -> " from: " + x.getName()).orElse(""); >>>> + } >>>> + >>>> /** >>>> * Initializes this object for verification. If this method is called >>>> * again with a different argument, it negates the effect >>>> @@ -473,7 +477,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " verification algorithm from: " + >>>> this.provider.getName()); >>>> + " verification algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -522,7 +526,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " verification algorithm from: " + >>>> this.provider.getName()); >>>> + " verification algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -543,7 +547,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " signing algorithm from: " + this.provider.getName()); >>>> + " signing algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -566,7 +570,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " signing algorithm from: " + this.provider.getName()); >>>> + " signing algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -1087,7 +1091,7 @@ >>>> } >>>> try { >>>> sigSpi = newInstance(s); >>>> - provider = s.getProvider(); >>>> + provider = Optional.of(s.getProvider()); >>>> // not needed any more >>>> firstService = null; >>>> serviceIterator = null; >>>> @@ -1132,7 +1136,7 @@ >>>> try { >>>> SignatureSpi spi = newInstance(s); >>>> init(spi, type, key, random); >>>> - provider = s.getProvider(); >>>> + provider = Optional.of(s.getProvider()); >>>> sigSpi = spi; >>>> firstService = null; >>>> serviceIterator = null; >>>> diff --git a/test/java/security/Signature/NoProvider.java >>>> b/test/java/security/Signature/NoProvider.java >>>> new file mode 100644 >>>> --- /dev/null >>>> +++ b/test/java/security/Signature/NoProvider.java >>>> @@ -0,0 +1,99 @@ >>>> +/* >>>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> + * >>>> + * This code is free software; you can redistribute it and/or modify it >>>> + * under the terms of the GNU General Public License version 2 only, as >>>> + * published by the Free Software Foundation. >>>> + * >>>> + * This code is distributed in the hope that it will be useful, but >>>> WITHOUT >>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >>>> + * version 2 for more details (a copy is included in the LICENSE file that >>>> + * accompanied this code). >>>> + * >>>> + * You should have received a copy of the GNU General Public License >>>> version >>>> + * 2 along with this work; if not, write to the Free Software Foundation, >>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>> + * >>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >>>> + * or visit www.oracle.com if you need additional information or have any >>>> + * questions. >>>> + */ >>>> + >>>> +/* >>>> + * @test >>>> + * @bug 8165751 >>>> + * @summary Verify that that a subclass of Signature that does not >>>> contain a >>>> + * provider can be used verify. >>>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>>> + */ >>>> + >>>> +import java.security.*; >>>> + >>>> +public class NoProvider { >>>> + >>>> + private static class NoProviderPublicKey implements PublicKey{ >>>> + public String getAlgorithm(){ >>>> + return "NoProvider"; >>>> + } >>>> + public String getFormat(){ >>>> + return "none"; >>>> + } >>>> + public byte[] getEncoded(){ >>>> + return new byte[1]; >>>> + } >>>> + } >>>> + >>>> + private static class NoProviderSignature extends Signature{ >>>> + >>>> + public NoProviderSignature(){ >>>> + super("NoProvider"); >>>> + } >>>> + >>>> + protected void engineInitVerify(PublicKey publicKey) >>>> + throws InvalidKeyException{ >>>> + // do nothing >>>> + } >>>> + >>>> + protected void engineInitSign(PrivateKey privateKey) >>>> + throws InvalidKeyException{ >>>> + // do nothing >>>> + } >>>> + >>>> + protected void engineUpdate(byte b) throws SignatureException{ >>>> + // do nothing >>>> + } >>>> + >>>> + protected void engineUpdate(byte[] b, int off, int len) >>>> + throws SignatureException{ >>>> + // do nothing >>>> + } >>>> + >>>> + protected byte[] engineSign() throws SignatureException{ >>>> + return new byte[1]; >>>> + } >>>> + >>>> + protected boolean engineVerify(byte[] sigBytes) >>>> + throws SignatureException{ >>>> + return false; >>>> + } >>>> + >>>> + @Deprecated >>>> + protected void engineSetParameter(String param, Object value) >>>> + throws InvalidParameterException{ >>>> + // do nothing >>>> + } >>>> + >>>> + @Deprecated >>>> + protected Object engineGetParameter(String param) >>>> + throws InvalidParameterException{ >>>> + return null; >>>> + } >>>> + >>>> + } >>>> + >>>> + public static void main(String[] args) throws Exception { >>>> + new NoProviderSignature().initVerify(new NoProviderPublicKey()); >>>> + } >>>> +} From sean.mullan at oracle.com Tue Dec 13 16:56:29 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Dec 2016 11:56:29 -0500 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider In-Reply-To: <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> Message-ID: <9aaa8c7c-c7a9-9c79-bc6a-62f124763ec7@oracle.com> On 12/13/16 11:30 AM, Adam Petcher wrote: > Thanks for the review. > > After thinking about this some more, I don't like the idea of using > Optional for a member variable due to the limitations of this class and > the lack of support for this usage of it. I'll send out a new diff that > uses a standard null check. > > See below for other comments. > > > On 12/12/2016 9:20 PM, Wang Weijun wrote: >> Hi Adam >> >> The only behavior change is with the debug output, right? > Yes. This will be more obvious in my next diff. >> >> Is this a new pattern that internal optional fields should be defined >> as an Optional? >> >> And, when there is no provider the string form "from: " looks strange, >> I would rather make it "from nowhere". I would also move the space >> before "from" to where the method is called, say, " verification >> algorithm " + getProvidedByString(). > It doesn't print the "from: " when there is no provider. So the string > will look like "Signature.DSA verification algorithm" in this case. I > don't have a strong opinion on whether we should print "from: no > provider" (for example), but Sean expressed a preference for leaving > this entire part blank when there is no provider (as it is in my last > diff). Maybe "from: (no provider)" would be better. I think a previous version had "from: none", but thinking about it more, "from: (no provider)" is probably better than not printing anything for a null provider. --Sean >> >> Thanks >> Max >> >>> On Dec 13, 2016, at 4:05 AM, Adam Petcher >>> wrote: >>> >>> Okay. I changed getProvider() to return this.provider.orElse(null), >>> which will allow this method to return null. For consistency, I allow >>> all other providers (in Instance and Service) to be null using >>> Optional.ofNullable(). Hopefully, I found and fixed all the >>> whitespace issues, too. Here is the corrected diff: >>> >>> diff --git a/src/java.base/share/classes/java/security/Signature.java >>> b/src/java.base/share/classes/java/security/Signature.java >>> --- a/src/java.base/share/classes/java/security/Signature.java >>> +++ b/src/java.base/share/classes/java/security/Signature.java >>> @@ -134,7 +134,7 @@ >>> private String algorithm; >>> >>> // The provider >>> - Provider provider; >>> + Optional provider = Optional.empty(); >>> >>> /** >>> * Possible {@link #state} value, signifying that >>> @@ -266,7 +266,7 @@ >>> SignatureSpi spi = (SignatureSpi)instance.impl; >>> sig = new Delegate(spi, algorithm); >>> } >>> - sig.provider = instance.provider; >>> + sig.provider = Optional.ofNullable(instance.provider); >>> return sig; >>> } >>> >>> @@ -449,13 +449,17 @@ >>> */ >>> public final Provider getProvider() { >>> chooseFirstProvider(); >>> - return this.provider; >>> + return this.provider.orElse(null); >>> } >>> >>> void chooseFirstProvider() { >>> // empty, overridden in Delegate >>> } >>> >>> + private String getProvidedByString() { >>> + return provider.map(x -> " from: " + x.getName()).orElse(""); >>> + } >>> + >>> /** >>> * Initializes this object for verification. If this method is >>> called >>> * again with a different argument, it negates the effect >>> @@ -473,7 +477,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " verification algorithm from: " + >>> this.provider.getName()); >>> + " verification algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -522,7 +526,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " verification algorithm from: " + >>> this.provider.getName()); >>> + " verification algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -543,7 +547,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " signing algorithm from: " + this.provider.getName()); >>> + " signing algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -566,7 +570,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Signature." + algorithm + >>> - " signing algorithm from: " + this.provider.getName()); >>> + " signing algorithm" + getProvidedByString()); >>> } >>> } >>> >>> @@ -1087,7 +1091,7 @@ >>> } >>> try { >>> sigSpi = newInstance(s); >>> - provider = s.getProvider(); >>> + provider = >>> Optional.ofNullable(s.getProvider()); >>> // not needed any more >>> firstService = null; >>> serviceIterator = null; >>> @@ -1132,7 +1136,7 @@ >>> try { >>> SignatureSpi spi = newInstance(s); >>> init(spi, type, key, random); >>> - provider = s.getProvider(); >>> + provider = >>> Optional.ofNullable(s.getProvider()); >>> sigSpi = spi; >>> firstService = null; >>> serviceIterator = null; >>> diff --git a/test/java/security/Signature/NoProvider.java >>> b/test/java/security/Signature/NoProvider.java >>> new file mode 100644 >>> --- /dev/null >>> +++ b/test/java/security/Signature/NoProvider.java >>> @@ -0,0 +1,99 @@ >>> +/* >>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights >>> reserved. >>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> + * >>> + * This code is free software; you can redistribute it and/or modify it >>> + * under the terms of the GNU General Public License version 2 only, as >>> + * published by the Free Software Foundation. >>> + * >>> + * This code is distributed in the hope that it will be useful, but >>> WITHOUT >>> + * ANY WARRANTY; without even the implied warranty of >>> MERCHANTABILITY or >>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>> License >>> + * version 2 for more details (a copy is included in the LICENSE >>> file that >>> + * accompanied this code). >>> + * >>> + * You should have received a copy of the GNU General Public License >>> version >>> + * 2 along with this work; if not, write to the Free Software >>> Foundation, >>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>> + * >>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>> 94065 USA >>> + * or visit www.oracle.com if you need additional information or >>> have any >>> + * questions. >>> + */ >>> + >>> +/* >>> + * @test >>> + * @bug 8165751 >>> + * @summary Verify that that a subclass of Signature that does not >>> contain a >>> + * provider can be used verify. >>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>> + */ >>> + >>> +import java.security.*; >>> + >>> +public class NoProvider { >>> + >>> + private static class NoProviderPublicKey implements PublicKey { >>> + >>> + public String getAlgorithm() { >>> + return "NoProvider"; >>> + } >>> + public String getFormat() { >>> + return "none"; >>> + } >>> + public byte[] getEncoded() { >>> + return new byte[1]; >>> + } >>> + } >>> + >>> + private static class NoProviderSignature extends Signature { >>> + >>> + public NoProviderSignature() { >>> + super("NoProvider"); >>> + } >>> + >>> + protected void engineInitVerify(PublicKey publicKey) >>> + throws InvalidKeyException { >>> + // do nothing >>> + } >>> + >>> + protected void engineInitSign(PrivateKey privateKey) >>> + throws InvalidKeyException { >>> + // do nothing >>> + } >>> + >>> + protected void engineUpdate(byte b) throws SignatureException { >>> + // do nothing >>> + } >>> + >>> + protected void engineUpdate(byte[] b, int off, int len) >>> + throws SignatureException { >>> + // do nothing >>> + } >>> + >>> + protected byte[] engineSign() throws SignatureException { >>> + return new byte[1]; >>> + } >>> + >>> + protected boolean engineVerify(byte[] sigBytes) >>> + throws SignatureException { >>> + return false; >>> + } >>> + >>> + @Deprecated >>> + protected void engineSetParameter(String param, Object value) >>> + throws InvalidParameterException { >>> + // do nothing >>> + } >>> + >>> + @Deprecated >>> + protected Object engineGetParameter(String param) >>> + throws InvalidParameterException { >>> + return null; >>> + } >>> + } >>> + >>> + public static void main(String[] args) throws Exception { >>> + new NoProviderSignature().initVerify(new >>> NoProviderPublicKey()); >>> + } >>> +} >>> >>> >>> On 12/12/2016 1:44 PM, Sean Mullan wrote: >>>> On 12/8/16 11:17 AM, Adam Petcher wrote: >>>>> Subclasses of Signature may have a null provider. In this case, the >>>>> debug logging code will throw a NPE when attempting to call >>>>> getName() on >>>>> it. Since this member may be null, I would like to change its type to >>>>> Optional to ensure that code checks whether it is present before using >>>>> it. I have assumed that getProvider() methods (in both Signature and >>>>> Service) always return non-null---if this assumption is incorrect, >>>>> then >>>>> I'll need to change some of the uses of Optional in/around these >>>>> methods. >>>> I think we would want to preserve the current behavior of >>>> getProvider returning null for one of these subclasses (even though >>>> it isn't specified that null is an acceptable return value). Better >>>> to be safe here, otherwise NoSuchElementException would be thrown >>>> which would be unexpected and not specified by getProvider. >>>> >>>> Other than that, just a minor style comment on a few lines of the test: >>>> >>>>> + private static class NoProviderPublicKey implements PublicKey{ >>>> space before "{" >>>> >>>> --Sean >>>> >>>>> Note that this issue of missing null checks for providers exists in >>>>> several classes (e.g. Cipher, MessageDigest). Once this patch is >>>>> reviewed and committed, I will apply the same solution to all other >>>>> affected classes. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 >>>>> >>>>> Diff: >>>>> >>>>> diff --git a/src/java.base/share/classes/java/security/Signature.java >>>>> b/src/java.base/share/classes/java/security/Signature.java >>>>> --- a/src/java.base/share/classes/java/security/Signature.java >>>>> +++ b/src/java.base/share/classes/java/security/Signature.java >>>>> @@ -134,7 +134,7 @@ >>>>> private String algorithm; >>>>> >>>>> // The provider >>>>> - Provider provider; >>>>> + Optional provider = Optional.empty(); >>>>> >>>>> /** >>>>> * Possible {@link #state} value, signifying that >>>>> @@ -266,7 +266,7 @@ >>>>> SignatureSpi spi = (SignatureSpi)instance.impl; >>>>> sig = new Delegate(spi, algorithm); >>>>> } >>>>> - sig.provider = instance.provider; >>>>> + sig.provider = Optional.of(instance.provider); >>>>> return sig; >>>>> } >>>>> >>>>> @@ -449,13 +449,17 @@ >>>>> */ >>>>> public final Provider getProvider() { >>>>> chooseFirstProvider(); >>>>> - return this.provider; >>>>> + return this.provider.get(); >>>>> } >>>>> >>>>> void chooseFirstProvider() { >>>>> // empty, overridden in Delegate >>>>> } >>>>> >>>>> + private String getProvidedByString(){ >>>>> + return provider.map(x -> " from: " + x.getName()).orElse(""); >>>>> + } >>>>> + >>>>> /** >>>>> * Initializes this object for verification. If this method is >>>>> called >>>>> * again with a different argument, it negates the effect >>>>> @@ -473,7 +477,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " verification algorithm from: " + >>>>> this.provider.getName()); >>>>> + " verification algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -522,7 +526,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " verification algorithm from: " + >>>>> this.provider.getName()); >>>>> + " verification algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -543,7 +547,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " signing algorithm from: " + >>>>> this.provider.getName()); >>>>> + " signing algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -566,7 +570,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " signing algorithm from: " + >>>>> this.provider.getName()); >>>>> + " signing algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -1087,7 +1091,7 @@ >>>>> } >>>>> try { >>>>> sigSpi = newInstance(s); >>>>> - provider = s.getProvider(); >>>>> + provider = Optional.of(s.getProvider()); >>>>> // not needed any more >>>>> firstService = null; >>>>> serviceIterator = null; >>>>> @@ -1132,7 +1136,7 @@ >>>>> try { >>>>> SignatureSpi spi = newInstance(s); >>>>> init(spi, type, key, random); >>>>> - provider = s.getProvider(); >>>>> + provider = Optional.of(s.getProvider()); >>>>> sigSpi = spi; >>>>> firstService = null; >>>>> serviceIterator = null; >>>>> diff --git a/test/java/security/Signature/NoProvider.java >>>>> b/test/java/security/Signature/NoProvider.java >>>>> new file mode 100644 >>>>> --- /dev/null >>>>> +++ b/test/java/security/Signature/NoProvider.java >>>>> @@ -0,0 +1,99 @@ >>>>> +/* >>>>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> + * >>>>> + * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> + * under the terms of the GNU General Public License version 2 >>>>> only, as >>>>> + * published by the Free Software Foundation. >>>>> + * >>>>> + * This code is distributed in the hope that it will be useful, but >>>>> WITHOUT >>>>> + * ANY WARRANTY; without even the implied warranty of >>>>> MERCHANTABILITY or >>>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>> License >>>>> + * version 2 for more details (a copy is included in the LICENSE >>>>> file that >>>>> + * accompanied this code). >>>>> + * >>>>> + * You should have received a copy of the GNU General Public License >>>>> version >>>>> + * 2 along with this work; if not, write to the Free Software >>>>> Foundation, >>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>> + * >>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>> 94065 USA >>>>> + * or visit www.oracle.com if you need additional information or >>>>> have any >>>>> + * questions. >>>>> + */ >>>>> + >>>>> +/* >>>>> + * @test >>>>> + * @bug 8165751 >>>>> + * @summary Verify that that a subclass of Signature that does not >>>>> contain a >>>>> + * provider can be used verify. >>>>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>>>> + */ >>>>> + >>>>> +import java.security.*; >>>>> + >>>>> +public class NoProvider { >>>>> + >>>>> + private static class NoProviderPublicKey implements PublicKey{ >>>>> + public String getAlgorithm(){ >>>>> + return "NoProvider"; >>>>> + } >>>>> + public String getFormat(){ >>>>> + return "none"; >>>>> + } >>>>> + public byte[] getEncoded(){ >>>>> + return new byte[1]; >>>>> + } >>>>> + } >>>>> + >>>>> + private static class NoProviderSignature extends Signature{ >>>>> + >>>>> + public NoProviderSignature(){ >>>>> + super("NoProvider"); >>>>> + } >>>>> + >>>>> + protected void engineInitVerify(PublicKey publicKey) >>>>> + throws InvalidKeyException{ >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected void engineInitSign(PrivateKey privateKey) >>>>> + throws InvalidKeyException{ >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected void engineUpdate(byte b) throws >>>>> SignatureException{ >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected void engineUpdate(byte[] b, int off, int len) >>>>> + throws SignatureException{ >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected byte[] engineSign() throws SignatureException{ >>>>> + return new byte[1]; >>>>> + } >>>>> + >>>>> + protected boolean engineVerify(byte[] sigBytes) >>>>> + throws SignatureException{ >>>>> + return false; >>>>> + } >>>>> + >>>>> + @Deprecated >>>>> + protected void engineSetParameter(String param, Object value) >>>>> + throws InvalidParameterException{ >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + @Deprecated >>>>> + protected Object engineGetParameter(String param) >>>>> + throws InvalidParameterException{ >>>>> + return null; >>>>> + } >>>>> + >>>>> + } >>>>> + >>>>> + public static void main(String[] args) throws Exception { >>>>> + new NoProviderSignature().initVerify(new >>>>> NoProviderPublicKey()); >>>>> + } >>>>> +} > From adam.petcher at oracle.com Tue Dec 13 18:43:49 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 13 Dec 2016 13:43:49 -0500 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider In-Reply-To: <9aaa8c7c-c7a9-9c79-bc6a-62f124763ec7@oracle.com> References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> <9aaa8c7c-c7a9-9c79-bc6a-62f124763ec7@oracle.com> Message-ID: Here is the latest diff that simply adds a null check to the existing code. When the provider is null, the debug output will be "...algorithm from: (no provider)". The test code is the same as the last diff. diff --git a/src/java.base/share/classes/java/security/Signature.java b/src/java.base/share/classes/java/security/Signature.java --- a/src/java.base/share/classes/java/security/Signature.java +++ b/src/java.base/share/classes/java/security/Signature.java @@ -452,6 +452,10 @@ return this.provider; } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + void chooseFirstProvider() { // empty, overridden in Delegate } @@ -473,7 +477,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " verification algorithm from: " + this.provider.getName()); + " verification algorithm from: " + getProviderName()); } } @@ -522,7 +526,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " verification algorithm from: " + this.provider.getName()); + " verification algorithm from: " + getProviderName()); } } @@ -543,7 +547,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " signing algorithm from: " + this.provider.getName()); + " signing algorithm from: " + getProviderName()); } } @@ -566,7 +570,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Signature." + algorithm + - " signing algorithm from: " + this.provider.getName()); + " signing algorithm from: " + getProviderName()); } } diff --git a/test/java/security/Signature/NoProvider.java b/test/java/security/Signature/NoProvider.java new file mode 100644 --- /dev/null +++ b/test/java/security/Signature/NoProvider.java @@ -0,0 +1,99 @@ +/* + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8165751 + * @summary Verify that that a subclass of Signature that does not contain a + * provider can be used verify. + * @run main/othervm -Djava.security.debug=provider NoProvider + */ + +import java.security.*; + +public class NoProvider { + + private static class NoProviderPublicKey implements PublicKey { + + public String getAlgorithm() { + return "NoProvider"; + } + public String getFormat() { + return "none"; + } + public byte[] getEncoded() { + return new byte[1]; + } + } + + private static class NoProviderSignature extends Signature { + + public NoProviderSignature() { + super("NoProvider"); + } + + protected void engineInitVerify(PublicKey publicKey) + throws InvalidKeyException { + // do nothing + } + + protected void engineInitSign(PrivateKey privateKey) + throws InvalidKeyException { + // do nothing + } + + protected void engineUpdate(byte b) throws SignatureException { + // do nothing + } + + protected void engineUpdate(byte[] b, int off, int len) + throws SignatureException { + // do nothing + } + + protected byte[] engineSign() throws SignatureException { + return new byte[1]; + } + + protected boolean engineVerify(byte[] sigBytes) + throws SignatureException { + return false; + } + + @Deprecated + protected void engineSetParameter(String param, Object value) + throws InvalidParameterException { + // do nothing + } + + @Deprecated + protected Object engineGetParameter(String param) + throws InvalidParameterException { + return null; + } + } + + public static void main(String[] args) throws Exception { + new NoProviderSignature().initVerify(new NoProviderPublicKey()); + } +} On 12/13/2016 11:56 AM, Sean Mullan wrote: > On 12/13/16 11:30 AM, Adam Petcher wrote: >> Thanks for the review. >> >> After thinking about this some more, I don't like the idea of using >> Optional for a member variable due to the limitations of this class and >> the lack of support for this usage of it. I'll send out a new diff that >> uses a standard null check. >> >> See below for other comments. >> >> >> On 12/12/2016 9:20 PM, Wang Weijun wrote: >>> Hi Adam >>> >>> The only behavior change is with the debug output, right? >> Yes. This will be more obvious in my next diff. >>> >>> Is this a new pattern that internal optional fields should be defined >>> as an Optional? >>> >>> And, when there is no provider the string form "from: " looks strange, >>> I would rather make it "from nowhere". I would also move the space >>> before "from" to where the method is called, say, " verification >>> algorithm " + getProvidedByString(). >> It doesn't print the "from: " when there is no provider. So the string >> will look like "Signature.DSA verification algorithm" in this case. I >> don't have a strong opinion on whether we should print "from: no >> provider" (for example), but Sean expressed a preference for leaving >> this entire part blank when there is no provider (as it is in my last >> diff). > > Maybe "from: (no provider)" would be better. I think a previous > version had "from: none", but thinking about it more, "from: (no > provider)" is probably better than not printing anything for a null > provider. > > --Sean > >>> >>> Thanks >>> Max >>> >>>> On Dec 13, 2016, at 4:05 AM, Adam Petcher >>>> wrote: >>>> >>>> Okay. I changed getProvider() to return this.provider.orElse(null), >>>> which will allow this method to return null. For consistency, I allow >>>> all other providers (in Instance and Service) to be null using >>>> Optional.ofNullable(). Hopefully, I found and fixed all the >>>> whitespace issues, too. Here is the corrected diff: >>>> >>>> diff --git a/src/java.base/share/classes/java/security/Signature.java >>>> b/src/java.base/share/classes/java/security/Signature.java >>>> --- a/src/java.base/share/classes/java/security/Signature.java >>>> +++ b/src/java.base/share/classes/java/security/Signature.java >>>> @@ -134,7 +134,7 @@ >>>> private String algorithm; >>>> >>>> // The provider >>>> - Provider provider; >>>> + Optional provider = Optional.empty(); >>>> >>>> /** >>>> * Possible {@link #state} value, signifying that >>>> @@ -266,7 +266,7 @@ >>>> SignatureSpi spi = (SignatureSpi)instance.impl; >>>> sig = new Delegate(spi, algorithm); >>>> } >>>> - sig.provider = instance.provider; >>>> + sig.provider = Optional.ofNullable(instance.provider); >>>> return sig; >>>> } >>>> >>>> @@ -449,13 +449,17 @@ >>>> */ >>>> public final Provider getProvider() { >>>> chooseFirstProvider(); >>>> - return this.provider; >>>> + return this.provider.orElse(null); >>>> } >>>> >>>> void chooseFirstProvider() { >>>> // empty, overridden in Delegate >>>> } >>>> >>>> + private String getProvidedByString() { >>>> + return provider.map(x -> " from: " + x.getName()).orElse(""); >>>> + } >>>> + >>>> /** >>>> * Initializes this object for verification. If this method is >>>> called >>>> * again with a different argument, it negates the effect >>>> @@ -473,7 +477,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " verification algorithm from: " + >>>> this.provider.getName()); >>>> + " verification algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -522,7 +526,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " verification algorithm from: " + >>>> this.provider.getName()); >>>> + " verification algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -543,7 +547,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " signing algorithm from: " + >>>> this.provider.getName()); >>>> + " signing algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -566,7 +570,7 @@ >>>> >>>> if (!skipDebug && pdebug != null) { >>>> pdebug.println("Signature." + algorithm + >>>> - " signing algorithm from: " + >>>> this.provider.getName()); >>>> + " signing algorithm" + getProvidedByString()); >>>> } >>>> } >>>> >>>> @@ -1087,7 +1091,7 @@ >>>> } >>>> try { >>>> sigSpi = newInstance(s); >>>> - provider = s.getProvider(); >>>> + provider = >>>> Optional.ofNullable(s.getProvider()); >>>> // not needed any more >>>> firstService = null; >>>> serviceIterator = null; >>>> @@ -1132,7 +1136,7 @@ >>>> try { >>>> SignatureSpi spi = newInstance(s); >>>> init(spi, type, key, random); >>>> - provider = s.getProvider(); >>>> + provider = >>>> Optional.ofNullable(s.getProvider()); >>>> sigSpi = spi; >>>> firstService = null; >>>> serviceIterator = null; >>>> diff --git a/test/java/security/Signature/NoProvider.java >>>> b/test/java/security/Signature/NoProvider.java >>>> new file mode 100644 >>>> --- /dev/null >>>> +++ b/test/java/security/Signature/NoProvider.java >>>> @@ -0,0 +1,99 @@ >>>> +/* >>>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights >>>> reserved. >>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> + * >>>> + * This code is free software; you can redistribute it and/or >>>> modify it >>>> + * under the terms of the GNU General Public License version 2 >>>> only, as >>>> + * published by the Free Software Foundation. >>>> + * >>>> + * This code is distributed in the hope that it will be useful, but >>>> WITHOUT >>>> + * ANY WARRANTY; without even the implied warranty of >>>> MERCHANTABILITY or >>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>> License >>>> + * version 2 for more details (a copy is included in the LICENSE >>>> file that >>>> + * accompanied this code). >>>> + * >>>> + * You should have received a copy of the GNU General Public License >>>> version >>>> + * 2 along with this work; if not, write to the Free Software >>>> Foundation, >>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>> + * >>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>> 94065 USA >>>> + * or visit www.oracle.com if you need additional information or >>>> have any >>>> + * questions. >>>> + */ >>>> + >>>> +/* >>>> + * @test >>>> + * @bug 8165751 >>>> + * @summary Verify that that a subclass of Signature that does not >>>> contain a >>>> + * provider can be used verify. >>>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>>> + */ >>>> + >>>> +import java.security.*; >>>> + >>>> +public class NoProvider { >>>> + >>>> + private static class NoProviderPublicKey implements PublicKey { >>>> + >>>> + public String getAlgorithm() { >>>> + return "NoProvider"; >>>> + } >>>> + public String getFormat() { >>>> + return "none"; >>>> + } >>>> + public byte[] getEncoded() { >>>> + return new byte[1]; >>>> + } >>>> + } >>>> + >>>> + private static class NoProviderSignature extends Signature { >>>> + >>>> + public NoProviderSignature() { >>>> + super("NoProvider"); >>>> + } >>>> + >>>> + protected void engineInitVerify(PublicKey publicKey) >>>> + throws InvalidKeyException { >>>> + // do nothing >>>> + } >>>> + >>>> + protected void engineInitSign(PrivateKey privateKey) >>>> + throws InvalidKeyException { >>>> + // do nothing >>>> + } >>>> + >>>> + protected void engineUpdate(byte b) throws >>>> SignatureException { >>>> + // do nothing >>>> + } >>>> + >>>> + protected void engineUpdate(byte[] b, int off, int len) >>>> + throws SignatureException { >>>> + // do nothing >>>> + } >>>> + >>>> + protected byte[] engineSign() throws SignatureException { >>>> + return new byte[1]; >>>> + } >>>> + >>>> + protected boolean engineVerify(byte[] sigBytes) >>>> + throws SignatureException { >>>> + return false; >>>> + } >>>> + >>>> + @Deprecated >>>> + protected void engineSetParameter(String param, Object value) >>>> + throws InvalidParameterException { >>>> + // do nothing >>>> + } >>>> + >>>> + @Deprecated >>>> + protected Object engineGetParameter(String param) >>>> + throws InvalidParameterException { >>>> + return null; >>>> + } >>>> + } >>>> + >>>> + public static void main(String[] args) throws Exception { >>>> + new NoProviderSignature().initVerify(new >>>> NoProviderPublicKey()); >>>> + } >>>> +} >>>> >>>> >>>> On 12/12/2016 1:44 PM, Sean Mullan wrote: >>>>> On 12/8/16 11:17 AM, Adam Petcher wrote: >>>>>> Subclasses of Signature may have a null provider. In this case, the >>>>>> debug logging code will throw a NPE when attempting to call >>>>>> getName() on >>>>>> it. Since this member may be null, I would like to change its >>>>>> type to >>>>>> Optional to ensure that code checks whether it is present before >>>>>> using >>>>>> it. I have assumed that getProvider() methods (in both Signature and >>>>>> Service) always return non-null---if this assumption is incorrect, >>>>>> then >>>>>> I'll need to change some of the uses of Optional in/around these >>>>>> methods. >>>>> I think we would want to preserve the current behavior of >>>>> getProvider returning null for one of these subclasses (even though >>>>> it isn't specified that null is an acceptable return value). Better >>>>> to be safe here, otherwise NoSuchElementException would be thrown >>>>> which would be unexpected and not specified by getProvider. >>>>> >>>>> Other than that, just a minor style comment on a few lines of the >>>>> test: >>>>> >>>>>> + private static class NoProviderPublicKey implements PublicKey{ >>>>> space before "{" >>>>> >>>>> --Sean >>>>> >>>>>> Note that this issue of missing null checks for providers exists in >>>>>> several classes (e.g. Cipher, MessageDigest). Once this patch is >>>>>> reviewed and committed, I will apply the same solution to all other >>>>>> affected classes. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 >>>>>> >>>>>> Diff: >>>>>> >>>>>> diff --git >>>>>> a/src/java.base/share/classes/java/security/Signature.java >>>>>> b/src/java.base/share/classes/java/security/Signature.java >>>>>> --- a/src/java.base/share/classes/java/security/Signature.java >>>>>> +++ b/src/java.base/share/classes/java/security/Signature.java >>>>>> @@ -134,7 +134,7 @@ >>>>>> private String algorithm; >>>>>> >>>>>> // The provider >>>>>> - Provider provider; >>>>>> + Optional provider = Optional.empty(); >>>>>> >>>>>> /** >>>>>> * Possible {@link #state} value, signifying that >>>>>> @@ -266,7 +266,7 @@ >>>>>> SignatureSpi spi = (SignatureSpi)instance.impl; >>>>>> sig = new Delegate(spi, algorithm); >>>>>> } >>>>>> - sig.provider = instance.provider; >>>>>> + sig.provider = Optional.of(instance.provider); >>>>>> return sig; >>>>>> } >>>>>> >>>>>> @@ -449,13 +449,17 @@ >>>>>> */ >>>>>> public final Provider getProvider() { >>>>>> chooseFirstProvider(); >>>>>> - return this.provider; >>>>>> + return this.provider.get(); >>>>>> } >>>>>> >>>>>> void chooseFirstProvider() { >>>>>> // empty, overridden in Delegate >>>>>> } >>>>>> >>>>>> + private String getProvidedByString(){ >>>>>> + return provider.map(x -> " from: " + >>>>>> x.getName()).orElse(""); >>>>>> + } >>>>>> + >>>>>> /** >>>>>> * Initializes this object for verification. If this method is >>>>>> called >>>>>> * again with a different argument, it negates the effect >>>>>> @@ -473,7 +477,7 @@ >>>>>> >>>>>> if (!skipDebug && pdebug != null) { >>>>>> pdebug.println("Signature." + algorithm + >>>>>> - " verification algorithm from: " + >>>>>> this.provider.getName()); >>>>>> + " verification algorithm" + getProvidedByString()); >>>>>> } >>>>>> } >>>>>> >>>>>> @@ -522,7 +526,7 @@ >>>>>> >>>>>> if (!skipDebug && pdebug != null) { >>>>>> pdebug.println("Signature." + algorithm + >>>>>> - " verification algorithm from: " + >>>>>> this.provider.getName()); >>>>>> + " verification algorithm" + getProvidedByString()); >>>>>> } >>>>>> } >>>>>> >>>>>> @@ -543,7 +547,7 @@ >>>>>> >>>>>> if (!skipDebug && pdebug != null) { >>>>>> pdebug.println("Signature." + algorithm + >>>>>> - " signing algorithm from: " + >>>>>> this.provider.getName()); >>>>>> + " signing algorithm" + getProvidedByString()); >>>>>> } >>>>>> } >>>>>> >>>>>> @@ -566,7 +570,7 @@ >>>>>> >>>>>> if (!skipDebug && pdebug != null) { >>>>>> pdebug.println("Signature." + algorithm + >>>>>> - " signing algorithm from: " + >>>>>> this.provider.getName()); >>>>>> + " signing algorithm" + getProvidedByString()); >>>>>> } >>>>>> } >>>>>> >>>>>> @@ -1087,7 +1091,7 @@ >>>>>> } >>>>>> try { >>>>>> sigSpi = newInstance(s); >>>>>> - provider = s.getProvider(); >>>>>> + provider = Optional.of(s.getProvider()); >>>>>> // not needed any more >>>>>> firstService = null; >>>>>> serviceIterator = null; >>>>>> @@ -1132,7 +1136,7 @@ >>>>>> try { >>>>>> SignatureSpi spi = newInstance(s); >>>>>> init(spi, type, key, random); >>>>>> - provider = s.getProvider(); >>>>>> + provider = Optional.of(s.getProvider()); >>>>>> sigSpi = spi; >>>>>> firstService = null; >>>>>> serviceIterator = null; >>>>>> diff --git a/test/java/security/Signature/NoProvider.java >>>>>> b/test/java/security/Signature/NoProvider.java >>>>>> new file mode 100644 >>>>>> --- /dev/null >>>>>> +++ b/test/java/security/Signature/NoProvider.java >>>>>> @@ -0,0 +1,99 @@ >>>>>> +/* >>>>>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights >>>>>> reserved. >>>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>> + * >>>>>> + * This code is free software; you can redistribute it and/or >>>>>> modify it >>>>>> + * under the terms of the GNU General Public License version 2 >>>>>> only, as >>>>>> + * published by the Free Software Foundation. >>>>>> + * >>>>>> + * This code is distributed in the hope that it will be useful, but >>>>>> WITHOUT >>>>>> + * ANY WARRANTY; without even the implied warranty of >>>>>> MERCHANTABILITY or >>>>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>> License >>>>>> + * version 2 for more details (a copy is included in the LICENSE >>>>>> file that >>>>>> + * accompanied this code). >>>>>> + * >>>>>> + * You should have received a copy of the GNU General Public >>>>>> License >>>>>> version >>>>>> + * 2 along with this work; if not, write to the Free Software >>>>>> Foundation, >>>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>>> + * >>>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>>> 94065 USA >>>>>> + * or visit www.oracle.com if you need additional information or >>>>>> have any >>>>>> + * questions. >>>>>> + */ >>>>>> + >>>>>> +/* >>>>>> + * @test >>>>>> + * @bug 8165751 >>>>>> + * @summary Verify that that a subclass of Signature that does not >>>>>> contain a >>>>>> + * provider can be used verify. >>>>>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>>>>> + */ >>>>>> + >>>>>> +import java.security.*; >>>>>> + >>>>>> +public class NoProvider { >>>>>> + >>>>>> + private static class NoProviderPublicKey implements PublicKey{ >>>>>> + public String getAlgorithm(){ >>>>>> + return "NoProvider"; >>>>>> + } >>>>>> + public String getFormat(){ >>>>>> + return "none"; >>>>>> + } >>>>>> + public byte[] getEncoded(){ >>>>>> + return new byte[1]; >>>>>> + } >>>>>> + } >>>>>> + >>>>>> + private static class NoProviderSignature extends Signature{ >>>>>> + >>>>>> + public NoProviderSignature(){ >>>>>> + super("NoProvider"); >>>>>> + } >>>>>> + >>>>>> + protected void engineInitVerify(PublicKey publicKey) >>>>>> + throws InvalidKeyException{ >>>>>> + // do nothing >>>>>> + } >>>>>> + >>>>>> + protected void engineInitSign(PrivateKey privateKey) >>>>>> + throws InvalidKeyException{ >>>>>> + // do nothing >>>>>> + } >>>>>> + >>>>>> + protected void engineUpdate(byte b) throws >>>>>> SignatureException{ >>>>>> + // do nothing >>>>>> + } >>>>>> + >>>>>> + protected void engineUpdate(byte[] b, int off, int len) >>>>>> + throws SignatureException{ >>>>>> + // do nothing >>>>>> + } >>>>>> + >>>>>> + protected byte[] engineSign() throws SignatureException{ >>>>>> + return new byte[1]; >>>>>> + } >>>>>> + >>>>>> + protected boolean engineVerify(byte[] sigBytes) >>>>>> + throws SignatureException{ >>>>>> + return false; >>>>>> + } >>>>>> + >>>>>> + @Deprecated >>>>>> + protected void engineSetParameter(String param, Object >>>>>> value) >>>>>> + throws InvalidParameterException{ >>>>>> + // do nothing >>>>>> + } >>>>>> + >>>>>> + @Deprecated >>>>>> + protected Object engineGetParameter(String param) >>>>>> + throws InvalidParameterException{ >>>>>> + return null; >>>>>> + } >>>>>> + >>>>>> + } >>>>>> + >>>>>> + public static void main(String[] args) throws Exception { >>>>>> + new NoProviderSignature().initVerify(new >>>>>> NoProviderPublicKey()); >>>>>> + } >>>>>> +} >> From sean.mullan at oracle.com Tue Dec 13 19:27:39 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Dec 2016 14:27:39 -0500 Subject: [PATCH] 8165751: NPE in Signature with java.security.debug=provider In-Reply-To: References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> <9aaa8c7c-c7a9-9c79-bc6a-62f124763ec7@oracle.com> Message-ID: <21bb986f-912f-5fac-03c1-f16b62dc0592@oracle.com> On 12/13/16 1:43 PM, Adam Petcher wrote: > Here is the latest diff that simply adds a null check to the existing > code. When the provider is null, the debug output will be "...algorithm > from: (no provider)". The test code is the same as the last diff. Looks good to me. --Sean > > > diff --git a/src/java.base/share/classes/java/security/Signature.java > b/src/java.base/share/classes/java/security/Signature.java > --- a/src/java.base/share/classes/java/security/Signature.java > +++ b/src/java.base/share/classes/java/security/Signature.java > @@ -452,6 +452,10 @@ > return this.provider; > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > void chooseFirstProvider() { > // empty, overridden in Delegate > } > @@ -473,7 +477,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " verification algorithm from: " + > this.provider.getName()); > + " verification algorithm from: " + getProviderName()); > } > } > > @@ -522,7 +526,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " verification algorithm from: " + > this.provider.getName()); > + " verification algorithm from: " + getProviderName()); > } > } > > @@ -543,7 +547,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " signing algorithm from: " + this.provider.getName()); > + " signing algorithm from: " + getProviderName()); > } > } > > @@ -566,7 +570,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Signature." + algorithm + > - " signing algorithm from: " + this.provider.getName()); > + " signing algorithm from: " + getProviderName()); > } > } > > diff --git a/test/java/security/Signature/NoProvider.java > b/test/java/security/Signature/NoProvider.java > new file mode 100644 > --- /dev/null > +++ b/test/java/security/Signature/NoProvider.java > @@ -0,0 +1,99 @@ > +/* > + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8165751 > + * @summary Verify that that a subclass of Signature that does not > contain a > + * provider can be used verify. > + * @run main/othervm -Djava.security.debug=provider NoProvider > + */ > + > +import java.security.*; > + > +public class NoProvider { > + > + private static class NoProviderPublicKey implements PublicKey { > + > + public String getAlgorithm() { > + return "NoProvider"; > + } > + public String getFormat() { > + return "none"; > + } > + public byte[] getEncoded() { > + return new byte[1]; > + } > + } > + > + private static class NoProviderSignature extends Signature { > + > + public NoProviderSignature() { > + super("NoProvider"); > + } > + > + protected void engineInitVerify(PublicKey publicKey) > + throws InvalidKeyException { > + // do nothing > + } > + > + protected void engineInitSign(PrivateKey privateKey) > + throws InvalidKeyException { > + // do nothing > + } > + > + protected void engineUpdate(byte b) throws SignatureException { > + // do nothing > + } > + > + protected void engineUpdate(byte[] b, int off, int len) > + throws SignatureException { > + // do nothing > + } > + > + protected byte[] engineSign() throws SignatureException { > + return new byte[1]; > + } > + > + protected boolean engineVerify(byte[] sigBytes) > + throws SignatureException { > + return false; > + } > + > + @Deprecated > + protected void engineSetParameter(String param, Object value) > + throws InvalidParameterException { > + // do nothing > + } > + > + @Deprecated > + protected Object engineGetParameter(String param) > + throws InvalidParameterException { > + return null; > + } > + } > + > + public static void main(String[] args) throws Exception { > + new NoProviderSignature().initVerify(new NoProviderPublicKey()); > + } > +} > > > On 12/13/2016 11:56 AM, Sean Mullan wrote: >> On 12/13/16 11:30 AM, Adam Petcher wrote: >>> Thanks for the review. >>> >>> After thinking about this some more, I don't like the idea of using >>> Optional for a member variable due to the limitations of this class and >>> the lack of support for this usage of it. I'll send out a new diff that >>> uses a standard null check. >>> >>> See below for other comments. >>> >>> >>> On 12/12/2016 9:20 PM, Wang Weijun wrote: >>>> Hi Adam >>>> >>>> The only behavior change is with the debug output, right? >>> Yes. This will be more obvious in my next diff. >>>> >>>> Is this a new pattern that internal optional fields should be defined >>>> as an Optional? >>>> >>>> And, when there is no provider the string form "from: " looks strange, >>>> I would rather make it "from nowhere". I would also move the space >>>> before "from" to where the method is called, say, " verification >>>> algorithm " + getProvidedByString(). >>> It doesn't print the "from: " when there is no provider. So the string >>> will look like "Signature.DSA verification algorithm" in this case. I >>> don't have a strong opinion on whether we should print "from: no >>> provider" (for example), but Sean expressed a preference for leaving >>> this entire part blank when there is no provider (as it is in my last >>> diff). >> >> Maybe "from: (no provider)" would be better. I think a previous >> version had "from: none", but thinking about it more, "from: (no >> provider)" is probably better than not printing anything for a null >> provider. >> >> --Sean >> >>>> >>>> Thanks >>>> Max >>>> >>>>> On Dec 13, 2016, at 4:05 AM, Adam Petcher >>>>> wrote: >>>>> >>>>> Okay. I changed getProvider() to return this.provider.orElse(null), >>>>> which will allow this method to return null. For consistency, I allow >>>>> all other providers (in Instance and Service) to be null using >>>>> Optional.ofNullable(). Hopefully, I found and fixed all the >>>>> whitespace issues, too. Here is the corrected diff: >>>>> >>>>> diff --git a/src/java.base/share/classes/java/security/Signature.java >>>>> b/src/java.base/share/classes/java/security/Signature.java >>>>> --- a/src/java.base/share/classes/java/security/Signature.java >>>>> +++ b/src/java.base/share/classes/java/security/Signature.java >>>>> @@ -134,7 +134,7 @@ >>>>> private String algorithm; >>>>> >>>>> // The provider >>>>> - Provider provider; >>>>> + Optional provider = Optional.empty(); >>>>> >>>>> /** >>>>> * Possible {@link #state} value, signifying that >>>>> @@ -266,7 +266,7 @@ >>>>> SignatureSpi spi = (SignatureSpi)instance.impl; >>>>> sig = new Delegate(spi, algorithm); >>>>> } >>>>> - sig.provider = instance.provider; >>>>> + sig.provider = Optional.ofNullable(instance.provider); >>>>> return sig; >>>>> } >>>>> >>>>> @@ -449,13 +449,17 @@ >>>>> */ >>>>> public final Provider getProvider() { >>>>> chooseFirstProvider(); >>>>> - return this.provider; >>>>> + return this.provider.orElse(null); >>>>> } >>>>> >>>>> void chooseFirstProvider() { >>>>> // empty, overridden in Delegate >>>>> } >>>>> >>>>> + private String getProvidedByString() { >>>>> + return provider.map(x -> " from: " + x.getName()).orElse(""); >>>>> + } >>>>> + >>>>> /** >>>>> * Initializes this object for verification. If this method is >>>>> called >>>>> * again with a different argument, it negates the effect >>>>> @@ -473,7 +477,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " verification algorithm from: " + >>>>> this.provider.getName()); >>>>> + " verification algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -522,7 +526,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " verification algorithm from: " + >>>>> this.provider.getName()); >>>>> + " verification algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -543,7 +547,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " signing algorithm from: " + >>>>> this.provider.getName()); >>>>> + " signing algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -566,7 +570,7 @@ >>>>> >>>>> if (!skipDebug && pdebug != null) { >>>>> pdebug.println("Signature." + algorithm + >>>>> - " signing algorithm from: " + >>>>> this.provider.getName()); >>>>> + " signing algorithm" + getProvidedByString()); >>>>> } >>>>> } >>>>> >>>>> @@ -1087,7 +1091,7 @@ >>>>> } >>>>> try { >>>>> sigSpi = newInstance(s); >>>>> - provider = s.getProvider(); >>>>> + provider = >>>>> Optional.ofNullable(s.getProvider()); >>>>> // not needed any more >>>>> firstService = null; >>>>> serviceIterator = null; >>>>> @@ -1132,7 +1136,7 @@ >>>>> try { >>>>> SignatureSpi spi = newInstance(s); >>>>> init(spi, type, key, random); >>>>> - provider = s.getProvider(); >>>>> + provider = >>>>> Optional.ofNullable(s.getProvider()); >>>>> sigSpi = spi; >>>>> firstService = null; >>>>> serviceIterator = null; >>>>> diff --git a/test/java/security/Signature/NoProvider.java >>>>> b/test/java/security/Signature/NoProvider.java >>>>> new file mode 100644 >>>>> --- /dev/null >>>>> +++ b/test/java/security/Signature/NoProvider.java >>>>> @@ -0,0 +1,99 @@ >>>>> +/* >>>>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> + * >>>>> + * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> + * under the terms of the GNU General Public License version 2 >>>>> only, as >>>>> + * published by the Free Software Foundation. >>>>> + * >>>>> + * This code is distributed in the hope that it will be useful, but >>>>> WITHOUT >>>>> + * ANY WARRANTY; without even the implied warranty of >>>>> MERCHANTABILITY or >>>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>> License >>>>> + * version 2 for more details (a copy is included in the LICENSE >>>>> file that >>>>> + * accompanied this code). >>>>> + * >>>>> + * You should have received a copy of the GNU General Public License >>>>> version >>>>> + * 2 along with this work; if not, write to the Free Software >>>>> Foundation, >>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>> + * >>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>> 94065 USA >>>>> + * or visit www.oracle.com if you need additional information or >>>>> have any >>>>> + * questions. >>>>> + */ >>>>> + >>>>> +/* >>>>> + * @test >>>>> + * @bug 8165751 >>>>> + * @summary Verify that that a subclass of Signature that does not >>>>> contain a >>>>> + * provider can be used verify. >>>>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>>>> + */ >>>>> + >>>>> +import java.security.*; >>>>> + >>>>> +public class NoProvider { >>>>> + >>>>> + private static class NoProviderPublicKey implements PublicKey { >>>>> + >>>>> + public String getAlgorithm() { >>>>> + return "NoProvider"; >>>>> + } >>>>> + public String getFormat() { >>>>> + return "none"; >>>>> + } >>>>> + public byte[] getEncoded() { >>>>> + return new byte[1]; >>>>> + } >>>>> + } >>>>> + >>>>> + private static class NoProviderSignature extends Signature { >>>>> + >>>>> + public NoProviderSignature() { >>>>> + super("NoProvider"); >>>>> + } >>>>> + >>>>> + protected void engineInitVerify(PublicKey publicKey) >>>>> + throws InvalidKeyException { >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected void engineInitSign(PrivateKey privateKey) >>>>> + throws InvalidKeyException { >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected void engineUpdate(byte b) throws >>>>> SignatureException { >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected void engineUpdate(byte[] b, int off, int len) >>>>> + throws SignatureException { >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + protected byte[] engineSign() throws SignatureException { >>>>> + return new byte[1]; >>>>> + } >>>>> + >>>>> + protected boolean engineVerify(byte[] sigBytes) >>>>> + throws SignatureException { >>>>> + return false; >>>>> + } >>>>> + >>>>> + @Deprecated >>>>> + protected void engineSetParameter(String param, Object value) >>>>> + throws InvalidParameterException { >>>>> + // do nothing >>>>> + } >>>>> + >>>>> + @Deprecated >>>>> + protected Object engineGetParameter(String param) >>>>> + throws InvalidParameterException { >>>>> + return null; >>>>> + } >>>>> + } >>>>> + >>>>> + public static void main(String[] args) throws Exception { >>>>> + new NoProviderSignature().initVerify(new >>>>> NoProviderPublicKey()); >>>>> + } >>>>> +} >>>>> >>>>> >>>>> On 12/12/2016 1:44 PM, Sean Mullan wrote: >>>>>> On 12/8/16 11:17 AM, Adam Petcher wrote: >>>>>>> Subclasses of Signature may have a null provider. In this case, the >>>>>>> debug logging code will throw a NPE when attempting to call >>>>>>> getName() on >>>>>>> it. Since this member may be null, I would like to change its >>>>>>> type to >>>>>>> Optional to ensure that code checks whether it is present before >>>>>>> using >>>>>>> it. I have assumed that getProvider() methods (in both Signature and >>>>>>> Service) always return non-null---if this assumption is incorrect, >>>>>>> then >>>>>>> I'll need to change some of the uses of Optional in/around these >>>>>>> methods. >>>>>> I think we would want to preserve the current behavior of >>>>>> getProvider returning null for one of these subclasses (even though >>>>>> it isn't specified that null is an acceptable return value). Better >>>>>> to be safe here, otherwise NoSuchElementException would be thrown >>>>>> which would be unexpected and not specified by getProvider. >>>>>> >>>>>> Other than that, just a minor style comment on a few lines of the >>>>>> test: >>>>>> >>>>>>> + private static class NoProviderPublicKey implements PublicKey{ >>>>>> space before "{" >>>>>> >>>>>> --Sean >>>>>> >>>>>>> Note that this issue of missing null checks for providers exists in >>>>>>> several classes (e.g. Cipher, MessageDigest). Once this patch is >>>>>>> reviewed and committed, I will apply the same solution to all other >>>>>>> affected classes. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165751 >>>>>>> >>>>>>> Diff: >>>>>>> >>>>>>> diff --git >>>>>>> a/src/java.base/share/classes/java/security/Signature.java >>>>>>> b/src/java.base/share/classes/java/security/Signature.java >>>>>>> --- a/src/java.base/share/classes/java/security/Signature.java >>>>>>> +++ b/src/java.base/share/classes/java/security/Signature.java >>>>>>> @@ -134,7 +134,7 @@ >>>>>>> private String algorithm; >>>>>>> >>>>>>> // The provider >>>>>>> - Provider provider; >>>>>>> + Optional provider = Optional.empty(); >>>>>>> >>>>>>> /** >>>>>>> * Possible {@link #state} value, signifying that >>>>>>> @@ -266,7 +266,7 @@ >>>>>>> SignatureSpi spi = (SignatureSpi)instance.impl; >>>>>>> sig = new Delegate(spi, algorithm); >>>>>>> } >>>>>>> - sig.provider = instance.provider; >>>>>>> + sig.provider = Optional.of(instance.provider); >>>>>>> return sig; >>>>>>> } >>>>>>> >>>>>>> @@ -449,13 +449,17 @@ >>>>>>> */ >>>>>>> public final Provider getProvider() { >>>>>>> chooseFirstProvider(); >>>>>>> - return this.provider; >>>>>>> + return this.provider.get(); >>>>>>> } >>>>>>> >>>>>>> void chooseFirstProvider() { >>>>>>> // empty, overridden in Delegate >>>>>>> } >>>>>>> >>>>>>> + private String getProvidedByString(){ >>>>>>> + return provider.map(x -> " from: " + >>>>>>> x.getName()).orElse(""); >>>>>>> + } >>>>>>> + >>>>>>> /** >>>>>>> * Initializes this object for verification. If this method is >>>>>>> called >>>>>>> * again with a different argument, it negates the effect >>>>>>> @@ -473,7 +477,7 @@ >>>>>>> >>>>>>> if (!skipDebug && pdebug != null) { >>>>>>> pdebug.println("Signature." + algorithm + >>>>>>> - " verification algorithm from: " + >>>>>>> this.provider.getName()); >>>>>>> + " verification algorithm" + getProvidedByString()); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @@ -522,7 +526,7 @@ >>>>>>> >>>>>>> if (!skipDebug && pdebug != null) { >>>>>>> pdebug.println("Signature." + algorithm + >>>>>>> - " verification algorithm from: " + >>>>>>> this.provider.getName()); >>>>>>> + " verification algorithm" + getProvidedByString()); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @@ -543,7 +547,7 @@ >>>>>>> >>>>>>> if (!skipDebug && pdebug != null) { >>>>>>> pdebug.println("Signature." + algorithm + >>>>>>> - " signing algorithm from: " + >>>>>>> this.provider.getName()); >>>>>>> + " signing algorithm" + getProvidedByString()); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @@ -566,7 +570,7 @@ >>>>>>> >>>>>>> if (!skipDebug && pdebug != null) { >>>>>>> pdebug.println("Signature." + algorithm + >>>>>>> - " signing algorithm from: " + >>>>>>> this.provider.getName()); >>>>>>> + " signing algorithm" + getProvidedByString()); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @@ -1087,7 +1091,7 @@ >>>>>>> } >>>>>>> try { >>>>>>> sigSpi = newInstance(s); >>>>>>> - provider = s.getProvider(); >>>>>>> + provider = Optional.of(s.getProvider()); >>>>>>> // not needed any more >>>>>>> firstService = null; >>>>>>> serviceIterator = null; >>>>>>> @@ -1132,7 +1136,7 @@ >>>>>>> try { >>>>>>> SignatureSpi spi = newInstance(s); >>>>>>> init(spi, type, key, random); >>>>>>> - provider = s.getProvider(); >>>>>>> + provider = Optional.of(s.getProvider()); >>>>>>> sigSpi = spi; >>>>>>> firstService = null; >>>>>>> serviceIterator = null; >>>>>>> diff --git a/test/java/security/Signature/NoProvider.java >>>>>>> b/test/java/security/Signature/NoProvider.java >>>>>>> new file mode 100644 >>>>>>> --- /dev/null >>>>>>> +++ b/test/java/security/Signature/NoProvider.java >>>>>>> @@ -0,0 +1,99 @@ >>>>>>> +/* >>>>>>> + * Copyright (c) 2016, Oracle and/or its affiliates. All rights >>>>>>> reserved. >>>>>>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>> + * >>>>>>> + * This code is free software; you can redistribute it and/or >>>>>>> modify it >>>>>>> + * under the terms of the GNU General Public License version 2 >>>>>>> only, as >>>>>>> + * published by the Free Software Foundation. >>>>>>> + * >>>>>>> + * This code is distributed in the hope that it will be useful, but >>>>>>> WITHOUT >>>>>>> + * ANY WARRANTY; without even the implied warranty of >>>>>>> MERCHANTABILITY or >>>>>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>> License >>>>>>> + * version 2 for more details (a copy is included in the LICENSE >>>>>>> file that >>>>>>> + * accompanied this code). >>>>>>> + * >>>>>>> + * You should have received a copy of the GNU General Public >>>>>>> License >>>>>>> version >>>>>>> + * 2 along with this work; if not, write to the Free Software >>>>>>> Foundation, >>>>>>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>>>> + * >>>>>>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>>>> 94065 USA >>>>>>> + * or visit www.oracle.com if you need additional information or >>>>>>> have any >>>>>>> + * questions. >>>>>>> + */ >>>>>>> + >>>>>>> +/* >>>>>>> + * @test >>>>>>> + * @bug 8165751 >>>>>>> + * @summary Verify that that a subclass of Signature that does not >>>>>>> contain a >>>>>>> + * provider can be used verify. >>>>>>> + * @run main/othervm -Djava.security.debug=provider NoProvider >>>>>>> + */ >>>>>>> + >>>>>>> +import java.security.*; >>>>>>> + >>>>>>> +public class NoProvider { >>>>>>> + >>>>>>> + private static class NoProviderPublicKey implements PublicKey{ >>>>>>> + public String getAlgorithm(){ >>>>>>> + return "NoProvider"; >>>>>>> + } >>>>>>> + public String getFormat(){ >>>>>>> + return "none"; >>>>>>> + } >>>>>>> + public byte[] getEncoded(){ >>>>>>> + return new byte[1]; >>>>>>> + } >>>>>>> + } >>>>>>> + >>>>>>> + private static class NoProviderSignature extends Signature{ >>>>>>> + >>>>>>> + public NoProviderSignature(){ >>>>>>> + super("NoProvider"); >>>>>>> + } >>>>>>> + >>>>>>> + protected void engineInitVerify(PublicKey publicKey) >>>>>>> + throws InvalidKeyException{ >>>>>>> + // do nothing >>>>>>> + } >>>>>>> + >>>>>>> + protected void engineInitSign(PrivateKey privateKey) >>>>>>> + throws InvalidKeyException{ >>>>>>> + // do nothing >>>>>>> + } >>>>>>> + >>>>>>> + protected void engineUpdate(byte b) throws >>>>>>> SignatureException{ >>>>>>> + // do nothing >>>>>>> + } >>>>>>> + >>>>>>> + protected void engineUpdate(byte[] b, int off, int len) >>>>>>> + throws SignatureException{ >>>>>>> + // do nothing >>>>>>> + } >>>>>>> + >>>>>>> + protected byte[] engineSign() throws SignatureException{ >>>>>>> + return new byte[1]; >>>>>>> + } >>>>>>> + >>>>>>> + protected boolean engineVerify(byte[] sigBytes) >>>>>>> + throws SignatureException{ >>>>>>> + return false; >>>>>>> + } >>>>>>> + >>>>>>> + @Deprecated >>>>>>> + protected void engineSetParameter(String param, Object >>>>>>> value) >>>>>>> + throws InvalidParameterException{ >>>>>>> + // do nothing >>>>>>> + } >>>>>>> + >>>>>>> + @Deprecated >>>>>>> + protected Object engineGetParameter(String param) >>>>>>> + throws InvalidParameterException{ >>>>>>> + return null; >>>>>>> + } >>>>>>> + >>>>>>> + } >>>>>>> + >>>>>>> + public static void main(String[] args) throws Exception { >>>>>>> + new NoProviderSignature().initVerify(new >>>>>>> NoProviderPublicKey()); >>>>>>> + } >>>>>>> +} >>> > From sean.mullan at oracle.com Tue Dec 13 21:09:35 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Dec 2016 16:09:35 -0500 Subject: RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool In-Reply-To: References: Message-ID: Hi Max, Could you include more information that shows what signature algorithm is used based on the key size range and algorithm? --Sean On 12/11/16 9:53 PM, Wang Weijun wrote: > Please take a review at the release note at > > https://bugs.openjdk.java.net/browse/JDK-8157389 > > Thanks > Max > From lussnig at suche.org Tue Dec 13 16:46:04 2016 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 13 Dec 2016 17:46:04 +0100 Subject: RandomCookie problem ? In-Reply-To: <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> Message-ID: <2683164e-0a3b-379f-f92f-2a1d2c0d6045@suche.org> Hi, even if the case is with the current time not active. Is it an good idea to define an fixed value for random generator under special conditions that are time depending ? Gru? Thomas --- package sun.security.ssl; RandomCookie(final SecureRandom sr) { final long ts0 = System.currentTimeMillis() / 1000L; int ts1; if(ts0 < Integer.MAX_VALUE) { ts1 = (int)ts0 ; } else *{ ts1 = Integer.MAX_VALUE; }* this.random_bytes = new byte[32]; sr.nextBytes(this.random_bytes); this.random_bytes[0] = (byte)(ts1 >> 24); this.random_bytes[1] = (byte)(ts1 >> 16); this.random_bytes[2] = (byte)(ts1 >> 8); this.random_bytes[3] = (byte) ts1; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Dec 13 21:32:01 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Dec 2016 16:32:01 -0500 Subject: On 8171135: Include javadoc on JarSigner API in security doc In-Reply-To: <57547857-FBA1-4857-A954-70FDEDA64709@oracle.com> References: <57547857-FBA1-4857-A954-70FDEDA64709@oracle.com> Message-ID: <71c1d793-8b11-72d9-b038-629eb5bec830@oracle.com> I would check with Jon Gibbons to see if there may be a more "official" place for exported, non-SE javadocs; otherwise it seems ok to me. --Sean On 12/12/16 9:50 PM, Wang Weijun wrote: > Hi All > > I've create a new bug to include the javadoc of the non-Java SE JarSigner API into security doc: > > https://bugs.openjdk.java.net/browse/JDK-8171135 > > If you think this is OK, I'll move the bug to doc. > > Thanks > Max > From xuelei.fan at oracle.com Tue Dec 13 21:48:04 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Dec 2016 13:48:04 -0800 Subject: RandomCookie problem ? In-Reply-To: <2683164e-0a3b-379f-f92f-2a1d2c0d6045@suche.org> References: <584987B6.6030800@oracle.com> <65dec0b1-db46-4604-2a71-5d58fb3c1e49@oracle.com> <371bbadb-32ca-c599-9031-c7f9f62eec9e@oracle.com> <2675b181-ff49-01a3-7902-1c947e393683@oracle.com> <2683164e-0a3b-379f-f92f-2a1d2c0d6045@suche.org> Message-ID: <6f2d9f2b-fbfc-2851-35b4-037677d9ec8c@oracle.com> On 12/13/2016 8:46 AM, Thomas Lu?nig wrote: > Hi, > > even if the case is with the current time not active. Is it an good idea > to define an fixed value > for random generator under special conditions that are time depending ? > The issue was fixed in JDK 9: https://bugs.openjdk.java.net/browse/JDK-8046294 Thanks, Xuelei > Gru? Thomas > > --- > > package sun.security.ssl; > > RandomCookie(final SecureRandom sr) { > final long ts0 = System.currentTimeMillis() / 1000L; > int ts1; > if(ts0 < Integer.MAX_VALUE) { ts1 = (int)ts0 ; } > else *{ ts1 = Integer.MAX_VALUE; }* > this.random_bytes = new byte[32]; > sr.nextBytes(this.random_bytes); > this.random_bytes[0] = (byte)(ts1 >> 24); > this.random_bytes[1] = (byte)(ts1 >> 16); > this.random_bytes[2] = (byte)(ts1 >> 8); > this.random_bytes[3] = (byte) ts1; > } From weijun.wang at oracle.com Wed Dec 14 01:39:27 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 09:39:27 +0800 Subject: On 8171135: Include javadoc on JarSigner API in security doc In-Reply-To: <71c1d793-8b11-72d9-b038-629eb5bec830@oracle.com> References: <57547857-FBA1-4857-A954-70FDEDA64709@oracle.com> <71c1d793-8b11-72d9-b038-629eb5bec830@oracle.com> Message-ID: Jon Will there be a dedicated page for all non-SE javadocs? We already had some in jdk.security.auth, jdk.security.jgss on the security guide home page [1]. Also, I am not sure if this belongs to the docs or build category if the javadoc is meant to be generated automatically. Therefore I let it stay in the security-libs at the moment. Thanks Max [1] http://download.java.net/java/jdk9/docs/technotes/guides/security/index.html > On Dec 14, 2016, at 5:32 AM, Sean Mullan wrote: > > I would check with Jon Gibbons to see if there may be a more "official" place for exported, non-SE javadocs; otherwise it seems ok to me. > > --Sean > > On 12/12/16 9:50 PM, Wang Weijun wrote: >> Hi All >> >> I've create a new bug to include the javadoc of the non-Java SE JarSigner API into security doc: >> >> https://bugs.openjdk.java.net/browse/JDK-8171135 >> >> If you think this is OK, I'll move the bug to doc. >> >> Thanks >> Max >> From weijun.wang at oracle.com Wed Dec 14 01:45:05 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 09:45:05 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: Webrev updated at http://cr.openjdk.java.net/~weijun/8168979/webrev.01 One comment is moved to its correct position and a typo fixed. Thanks Daniel for the comment. Can someone with a reviewer hat take a look? Thanks Max > On Dec 12, 2016, at 6:03 PM, Daniel Fuchs wrote: > > Hi Max, > > Don't count me as reviewer - but I see a mismatched comment > in the file: > > 209 /** > 210 * Creates FilePermission objects with special internals. > 211 * See {@link FilePermCompat#newPermPlusAltPath(Permission)} and > 212 * {@link FilePermCompat#newPermUsingAltPath(Permission)}. > 213 */ > 214 > 215 private static final Path here = builtInFS.getPath( > 216 GetPropertyAction.privilegedGetProperty("user.dir")); > > I guess the comment is a left over from some merge or previous fix? > > > Also I noticed the following later on: > > 541 * invalid {@code FilePermission}. Even if two {@code FilePermission} > 542 * are created with the same invalid path, one does imply the other. > > should this be: > > Even if two {@code FilePermission} are created with the same > invalid path, one does *not* imply the other. > > best regards, > > -- daniel > > On 12/12/16 09:01, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ >> >> This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Wed Dec 14 02:04:04 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 10:04:04 +0800 Subject: RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool In-Reply-To: References: Message-ID: <328FBA04-5369-49D7-A715-370121A5E0C0@oracle.com> I copied the exact @implNote from JarSigner into the release note. BTW, I noticed NIST 800-57 Part 1 has a new revision 4, which has the same tables as in revision 3. A new bug https://bugs.openjdk.java.net/browse/JDK-8171190 created and I'll create a webrev soon. Thanks Max > On Dec 14, 2016, at 5:09 AM, Sean Mullan wrote: > > Hi Max, > > Could you include more information that shows what signature algorithm is used based on the key size range and algorithm? > > --Sean > > On 12/11/16 9:53 PM, Wang Weijun wrote: >> Please take a review at the release note at >> >> https://bugs.openjdk.java.net/browse/JDK-8157389 >> >> Thanks >> Max >> From weijun.wang at oracle.com Wed Dec 14 02:09:03 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 10:09:03 +0800 Subject: RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec Message-ID: <26480D75-4A8E-487A-847E-0D5AE84E276E@oracle.com> NIST 800-57 Part 1 has a new revision. The lines below are newly introduced in jdk9. diff --git a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java --- a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java +++ b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java @@ -1024,7 +1024,7 @@ } } - // Values from SP800-57 part 1 rev 3 tables 2 and three + // Values from SP800-57 part 1 rev 4 tables 2 and 3 private static String ecStrength (int bitLength) { if (bitLength >= 512) { // 256 bits of strength return "SHA512"; @@ -1035,7 +1035,7 @@ } } - // same values for RSA and DSA + // Same values for RSA and DSA private static String ifcFfcStrength (int bitLength) { if (bitLength > 7680) { // 256 bits return "SHA512"; diff --git a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java --- a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java +++ b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java @@ -430,7 +430,7 @@ * SHA384withECDSA for a 384-bit EC key. * * @implNote This implementation makes use of comparable strengths - * as defined in Tables 2 and 3 of NIST SP 800-57 Part 1-Rev.3. + * as defined in Tables 2 and 3 of NIST SP 800-57 Part 1-Rev.4. * Specifically, if a DSA or RSA key with a key size greater than 7680 * bits, or an EC key with a key size greater than or equal to 512 bits, * SHA-512 will be used as the hash function for the signature. Thanks Max From xuelei.fan at oracle.com Wed Dec 14 02:11:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Dec 2016 18:11:16 -0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: <35ec0955-b04e-00cd-6367-a88eeda883bc@oracle.com> On 12/13/2016 5:45 PM, Wang Weijun wrote: > A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. Looks like two sides of the same coin. If there is an invalid <> (not existing in practice, I think), it now implies all; if no change on this point, <> does not imply invalid one. The existing behavior looks more safe to me. What's you concern to make this behavior change? Otherwise, looks fine to me. Xuelei From weijun.wang at oracle.com Wed Dec 14 02:14:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 10:14:40 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: <35ec0955-b04e-00cd-6367-a88eeda883bc@oracle.com> References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> <35ec0955-b04e-00cd-6367-a88eeda883bc@oracle.com> Message-ID: <05C423C1-69E3-4D5D-A8C2-349634B9B8CB@oracle.com> > On Dec 14, 2016, at 10:11 AM, Xuelei Fan wrote: > > On 12/13/2016 5:45 PM, Wang Weijun wrote: >> A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. > Looks like two sides of the same coin. If there is an invalid <> (not existing in practice, I think), Not existing in theory either. As the change says, invalid happens when the conversion of string to NIO Path fails. For <>, there will be no such conversion. > it now implies all; if no change on this point, <> does not imply invalid one. The existing behavior looks more safe to me. What's you concern to make this behavior change? Just safer. Sometimes an app can recover from a FileNotExistException but not a SecurityException. Thanks Max > > Otherwise, looks fine to me. > > Xuelei From xuelei.fan at oracle.com Wed Dec 14 02:28:51 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Dec 2016 18:28:51 -0800 Subject: RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec In-Reply-To: <26480D75-4A8E-487A-847E-0D5AE84E276E@oracle.com> References: <26480D75-4A8E-487A-847E-0D5AE84E276E@oracle.com> Message-ID: Looks fine to me. Xuelei On 12/13/2016 6:09 PM, Wang Weijun wrote: > NIST 800-57 Part 1 has a new revision. The lines below are newly introduced in jdk9. > > diff --git a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java > --- a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java > +++ b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java > @@ -1024,7 +1024,7 @@ > } > } > > - // Values from SP800-57 part 1 rev 3 tables 2 and three > + // Values from SP800-57 part 1 rev 4 tables 2 and 3 > private static String ecStrength (int bitLength) { > if (bitLength >= 512) { // 256 bits of strength > return "SHA512"; > @@ -1035,7 +1035,7 @@ > } > } > > - // same values for RSA and DSA > + // Same values for RSA and DSA > private static String ifcFfcStrength (int bitLength) { > if (bitLength > 7680) { // 256 bits > return "SHA512"; > diff --git a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java > --- a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java > +++ b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java > @@ -430,7 +430,7 @@ > * SHA384withECDSA for a 384-bit EC key. > * > * @implNote This implementation makes use of comparable strengths > - * as defined in Tables 2 and 3 of NIST SP 800-57 Part 1-Rev.3. > + * as defined in Tables 2 and 3 of NIST SP 800-57 Part 1-Rev.4. > * Specifically, if a DSA or RSA key with a key size greater than 7680 > * bits, or an EC key with a key size greater than or equal to 512 bits, > * SHA-512 will be used as the hash function for the signature. > > Thanks > Max > From weijun.wang at oracle.com Wed Dec 14 05:53:47 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 13:53:47 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) Message-ID: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> An clarification is added to FilePermission::implies: * @implNote .... * a simple {@code npath} is recursively inside a wildcard {@code npath} * if and only if {@code simple_npath.relativize(wildcard_npath)} - * is a series of one or more "..". An invalid {@code FilePermission} does + * is a series of one or more "..". Note that this means "/-" does not + * imply "foo". An invalid {@code FilePermission} does * not imply any object except for itself. The newly added sentence is Note that this means "/-" does not imply "foo". JCK has agreed to update their test. Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. Thanks Max From sha.jiang at oracle.com Wed Dec 14 08:13:04 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 14 Dec 2016 16:13:04 +0800 Subject: RFR[9] JDK-8164595: javax/net/ssl/FixingJavadocs/SSLSessionNulls.java fails intermittently with javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake In-Reply-To: <8af75ff0-70ee-f8d7-3050-accb4c049923@oracle.com> References: <9514b33b-e256-d17a-8ed7-e31dbffe8166@oracle.com> <8af75ff0-70ee-f8d7-3050-accb4c049923@oracle.com> Message-ID: Because of the push for JDK-8170329, the patch has to depend on the new SSLSocketTemplate. Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164595/webrev.02/ Best regards, John Jiang On 2016/11/23 13:38, John Jiang wrote: > Please review this patch. Thanks! > > John Jiang > > > On 2016/11/19 19:38, John Jiang wrote: >> After push for JDK-8168969, this fix has to use updated >> SSLSocketTemplate.java. >> Please review the updated webrev: >> http://cr.openjdk.java.net/~jjiang/8164595/webrev.01 >> >> Best regards, >> John Jiang >> >> On 2016/10/27 12:36, John Jiang wrote: >>> Hi, >>> Please review this patch for test >>> javax/net/ssl/FixingJavadocs/SSLSessionNulls.java. >>> It takes advantage of javax/net/ssl/templates/SSLTest.java to fix >>> the intermittent SSLHandshakeException issue. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8164595/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8164595 >>> >>> Best regards, >>> John Jiang >> >> > > From ecki at zusammenkunft.net Wed Dec 14 09:19:19 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 14 Dec 2016 09:19:19 +0000 (UTC) Subject: RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec In-Reply-To: <26480D75-4A8E-487A-847E-0D5AE84E276E@oracle.com> References: <26480D75-4A8E-487A-847E-0D5AE84E276E@oracle.com> Message-ID: <57A008FAA9E6E1E3.59A3B7B5-E5FF-4874-84C5-0C0141DC4EFC@mail.outlook.com> Hello, I noticed in the existing code:?Is the comment "256 bits" referring to the 'comparable strength'? # if (bitLength > 7680) { // 256 bits If so, it seems misleading, according to table 2 this would be 192 bit. Maybe this can be corrected, removed or the meaning of the comment clarified. Gruss Bernd -- http://bernd.eckenfels.net _____________________________ From: Wang Weijun Sent: Mittwoch, Dezember 14, 2016 4:39 AM Subject: RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec To: NIST 800-57 Part 1 has a new revision. The lines below are newly introduced in jdk9. diff --git a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java --- a/src/java.base/share/classes/sun/security/x509/AlgorithmId.java +++ b/src/java.base/share/classes/sun/security/x509/AlgorithmId.java @@ -1024,7 +1024,7 @@ } } - // Values from SP800-57 part 1 rev 3 tables 2 and three + // Values from SP800-57 part 1 rev 4 tables 2 and 3 private static String ecStrength (int bitLength) { if (bitLength >= 512) { // 256 bits of strength return "SHA512"; @@ -1035,7 +1035,7 @@ } } - // same values for RSA and DSA + // Same values for RSA and DSA private static String ifcFfcStrength (int bitLength) { if (bitLength > 7680) { // 256 bits return "SHA512"; diff --git a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java --- a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java +++ b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java @@ -430,7 +430,7 @@ * SHA384withECDSA for a 384-bit EC key. * * @implNote This implementation makes use of comparable strengths - * as defined in Tables 2 and 3 of NIST SP 800-57 Part 1-Rev.3. + * as defined in Tables 2 and 3 of NIST SP 800-57 Part 1-Rev.4. * Specifically, if a DSA or RSA key with a key size greater than 7680 * bits, or an EC key with a key size greater than or equal to 512 bits, * SHA-512 will be used as the hash function for the signature. Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Dec 14 09:28:18 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 17:28:18 +0800 Subject: RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec In-Reply-To: <57A008FAA9E6E1E3.59A3B7B5-E5FF-4874-84C5-0C0141DC4EFC@mail.outlook.com> References: <26480D75-4A8E-487A-847E-0D5AE84E276E@oracle.com> <57A008FAA9E6E1E3.59A3B7B5-E5FF-4874-84C5-0C0141DC4EFC@mail.outlook.com> Message-ID: 7680 itself is 192 bits, and for any bitLength greater than 7680 I treat it as in a "higher" level. --Max > On Dec 14, 2016, at 5:19 PM, Bernd Eckenfels wrote: > > Hello, > > I noticed in the existing code: Is the comment "256 bits" referring to the 'comparable strength'? > > # if (bitLength > 7680) { // 256 bits > > If so, it seems misleading, according to table 2 this would be 192 bit. Maybe this can be corrected, removed or the meaning of the comment clarified. > > Gruss > Bernd > -- > http://bernd.eckenfels.net From xuelei.fan at oracle.com Wed Dec 14 17:11:41 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 14 Dec 2016 09:11:41 -0800 Subject: RFR[9] JDK-8164595: javax/net/ssl/FixingJavadocs/SSLSessionNulls.java fails intermittently with javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake In-Reply-To: References: <9514b33b-e256-d17a-8ed7-e31dbffe8166@oracle.com> <8af75ff0-70ee-f8d7-3050-accb4c049923@oracle.com> Message-ID: <8b823bca-9d79-79d6-7431-5ccaf5cd4808@oracle.com> Looks fine to me. Thanks, Xuelei On 12/14/2016 12:13 AM, John Jiang wrote: > Because of the push for JDK-8170329, the patch has to depend on the new > SSLSocketTemplate. > Please review the new webrev: > http://cr.openjdk.java.net/~jjiang/8164595/webrev.02/ > > Best regards, > John Jiang > > > On 2016/11/23 13:38, John Jiang wrote: >> Please review this patch. Thanks! >> >> John Jiang >> >> >> On 2016/11/19 19:38, John Jiang wrote: >>> After push for JDK-8168969, this fix has to use updated >>> SSLSocketTemplate.java. >>> Please review the updated webrev: >>> http://cr.openjdk.java.net/~jjiang/8164595/webrev.01 >>> >>> Best regards, >>> John Jiang >>> >>> On 2016/10/27 12:36, John Jiang wrote: >>>> Hi, >>>> Please review this patch for test >>>> javax/net/ssl/FixingJavadocs/SSLSessionNulls.java. >>>> It takes advantage of javax/net/ssl/templates/SSLTest.java to fix >>>> the intermittent SSLHandshakeException issue. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8164595/webrev.00/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8164595 >>>> >>>> Best regards, >>>> John Jiang >>> >>> >> >> > From sha.jiang at oracle.com Thu Dec 15 05:54:15 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 15 Dec 2016 13:54:15 +0800 Subject: RFR[9] JDK-8171297: ProblemList javax/net/ssl/DTLS/PacketLossRetransmission.java due to JDK-8169086 Message-ID: Hi, javax/net/ssl/DTLS/PacketLossRetransmission.java has failed for several times on macosx-x64 platform. It should put it into ProblemList. Please review the below patch: diff -r 49b3d6d9b4df test/ProblemList.txt --- a/test/ProblemList.txt Thu Dec 15 10:47:46 2016 +0530 +++ b/test/ProblemList.txt Thu Dec 15 05:52:04 2016 +0000 @@ -217,6 +217,8 @@ sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 macosx-all +javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 + ############################################################################ # jdk_sound Best regards, John Jiang From xuelei.fan at oracle.com Thu Dec 15 06:33:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 14 Dec 2016 22:33:16 -0800 Subject: RFR[9] JDK-8171297: ProblemList javax/net/ssl/DTLS/PacketLossRetransmission.java due to JDK-8169086 In-Reply-To: References: Message-ID: <6d19669a-6c6d-68e6-d2b1-a63cbca0cafe@oracle.com> Ok. Xuelei On 12/14/2016 9:54 PM, John Jiang wrote: > Hi, > javax/net/ssl/DTLS/PacketLossRetransmission.java has failed for several > times on macosx-x64 platform. It should put it into ProblemList. > > Please review the below patch: > > diff -r 49b3d6d9b4df test/ProblemList.txt > --- a/test/ProblemList.txt Thu Dec 15 10:47:46 2016 +0530 > +++ b/test/ProblemList.txt Thu Dec 15 05:52:04 2016 +0000 > @@ -217,6 +217,8 @@ > > sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 macosx-all > > +javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 > + > ############################################################################ > > > # jdk_sound > > Best regards, > John Jiang > From artem.smotrakov at oracle.com Thu Dec 15 19:23:58 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 15 Dec 2016 11:23:58 -0800 Subject: [9] RFR: 8166531: sun/security/ssl/SocketCreation/SocketCreation.java fails intermittently Message-ID: <864d279d-d942-bf5d-e0cd-1f2893a81b69@oracle.com> Hello, Please review the patch below for sun/security/ssl/SocketCreation/SocketCreation.java test. The test has been observed to fail intermittently, but I couldn't reproduce it by running the test in a loop. The test creates sockets for TLS connection in different ways. Even if the test is very old, I wouldn't like to change its original behavior. It might be better to use SSLSocketTemplate here, but it would require a significant update to SSLSocketTemplate, and splitting the test to 5 tests. Instead of this, I am proposing to add some simple synchronization on client side where the test was seen to fail. If it doesn't work, we can try to use SSLSocketTemplate then. Bug: https://bugs.openjdk.java.net/browse/JDK-8166531 Webrev: http://cr.openjdk.java.net/~asmotrak/8166531/webrev.00/ Artem From adam.petcher at oracle.com Thu Dec 15 20:08:21 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 15 Dec 2016 15:08:21 -0500 Subject: [PATCH] 8170876: NPE in Cipher with java.security.debug=provider Message-ID: <65ba1668-3e80-16e6-a080-12f9b6a7ccf1@oracle.com> I'm continuing my quest to rid engine classes of NullPointerException due to calling getName() on a null provider. This patch fixes Cipher (which fails in a test using NullCipher) and all other engine classes that have this pattern. I found them by searching the codebase for references to Provider::getName. This fix does not address NPEs caused by calls to other methods of Provider, or calls that occur outside the engine classes (e.g. someEngine.getProvider().getName()). I augmented an existing test so it will check for the NPE in Cipher. The diff also containsa fix for a small typo in the NullProvider test for Signature. Bug: https://bugs.openjdk.java.net/browse/JDK-8170876 Diff: diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java --- a/src/java.base/share/classes/java/security/KeyStore.java +++ b/src/java.base/share/classes/java/security/KeyStore.java @@ -824,10 +824,14 @@ if (!skipDebug && pdebug != null) { pdebug.println("KeyStore." + type.toUpperCase() + " type from: " + - this.provider.getName()); + getProviderName()); } } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + /** * Returns a keystore object of the specified type. * diff --git a/src/java.base/share/classes/java/security/MessageDigest.java b/src/java.base/share/classes/java/security/MessageDigest.java --- a/src/java.base/share/classes/java/security/MessageDigest.java +++ b/src/java.base/share/classes/java/security/MessageDigest.java @@ -430,13 +430,17 @@ return digest(); } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + /** * Returns a string representation of this message digest object. */ public String toString() { ByteArrayOutputStream baos = new ByteArrayOutputStream(); PrintStream p = new PrintStream(baos); - p.print(algorithm+" Message Digest from "+provider.getName()+", "); + p.print(algorithm+" Message Digest from "+getProviderName()+", "); switch (state) { case INITIAL: p.print(""); diff --git a/src/java.base/share/classes/java/security/SecureRandom.java b/src/java.base/share/classes/java/security/SecureRandom.java --- a/src/java.base/share/classes/java/security/SecureRandom.java +++ b/src/java.base/share/classes/java/security/SecureRandom.java @@ -310,10 +310,14 @@ if (!skipDebug && pdebug != null) { pdebug.println("SecureRandom." + algorithm + - " algorithm from: " + this.provider.getName()); + " algorithm from: " + getProviderName()); } } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + /** * Returns a {@code SecureRandom} object that implements the specified * Random Number Generator (RNG) algorithm. diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java b/src/java.base/share/classes/javax/crypto/Cipher.java --- a/src/java.base/share/classes/javax/crypto/Cipher.java +++ b/src/java.base/share/classes/javax/crypto/Cipher.java @@ -611,6 +611,10 @@ return getInstance(transformation, p); } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + /** * Returns a {@code Cipher} object that implements the specified * transformation. @@ -1278,7 +1282,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Cipher." + transformation + " " + getOpmodeString(opmode) + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } @@ -1421,7 +1425,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Cipher." + transformation + " " + getOpmodeString(opmode) + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } @@ -1564,7 +1568,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Cipher." + transformation + " " + getOpmodeString(opmode) + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } @@ -1754,7 +1758,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Cipher." + transformation + " " + getOpmodeString(opmode) + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } diff --git a/src/java.base/share/classes/javax/crypto/KeyAgreement.java b/src/java.base/share/classes/javax/crypto/KeyAgreement.java --- a/src/java.base/share/classes/javax/crypto/KeyAgreement.java +++ b/src/java.base/share/classes/javax/crypto/KeyAgreement.java @@ -484,7 +484,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("KeyAgreement." + algorithm + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } @@ -517,6 +517,10 @@ init(key, params, JceSecurity.RANDOM); } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + /** * Initializes this key agreement with the given key, set of * algorithm parameters, and source of randomness. @@ -545,7 +549,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("KeyAgreement." + algorithm + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } diff --git a/src/java.base/share/classes/javax/crypto/KeyGenerator.java b/src/java.base/share/classes/javax/crypto/KeyGenerator.java --- a/src/java.base/share/classes/javax/crypto/KeyGenerator.java +++ b/src/java.base/share/classes/javax/crypto/KeyGenerator.java @@ -154,7 +154,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("KeyGenerator." + algorithm + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } @@ -172,10 +172,14 @@ if (!skipDebug && pdebug != null) { pdebug.println("KeyGenerator." + algorithm + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + /** * Returns the algorithm name of this {@code KeyGenerator} object. * diff --git a/src/java.base/share/classes/javax/crypto/Mac.java b/src/java.base/share/classes/javax/crypto/Mac.java --- a/src/java.base/share/classes/javax/crypto/Mac.java +++ b/src/java.base/share/classes/javax/crypto/Mac.java @@ -415,6 +415,10 @@ return spi.engineGetMacLength(); } + private String getProviderName() { + return (provider == null) ? "(no provider)" : provider.getName(); + } + /** * Initializes this {@code Mac} object with the given key. * @@ -437,7 +441,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Mac." + algorithm + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } @@ -464,7 +468,7 @@ if (!skipDebug && pdebug != null) { pdebug.println("Mac." + algorithm + " algorithm from: " + - this.provider.getName()); + getProviderName()); } } diff --git a/test/java/security/Signature/NoProvider.java b/test/java/security/Signature/NoProvider.java --- a/test/java/security/Signature/NoProvider.java +++ b/test/java/security/Signature/NoProvider.java @@ -25,7 +25,7 @@ * @test * @bug 8165751 * @summary Verify that that a subclass of Signature that does not contain a - * provider can be used verify. + * provider can be used to verify. * @run main/othervm -Djava.security.debug=provider NoProvider */ diff --git a/test/javax/crypto/NullCipher/TestNPE.java b/test/javax/crypto/NullCipher/TestNPE.java --- a/test/javax/crypto/NullCipher/TestNPE.java +++ b/test/javax/crypto/NullCipher/TestNPE.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,10 +23,12 @@ /* * @test - * @bug 4937853 + * @bug 4937853 8170876 * @summary Make sure normal calls of NullCipher does not throw NPE. * @author Valerie Peng * @key randomness + * @run main TestNPE + * @run main/othervm -Djava.security.debug=provider TestNPE */ import java.util.Arrays; import java.security.AlgorithmParameters; From xuelei.fan at oracle.com Thu Dec 15 22:04:44 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 15 Dec 2016 14:04:44 -0800 Subject: [9] RFR: 8166531: sun/security/ssl/SocketCreation/SocketCreation.java fails intermittently In-Reply-To: <864d279d-d942-bf5d-e0cd-1f2893a81b69@oracle.com> References: <864d279d-d942-bf5d-e0cd-1f2893a81b69@oracle.com> Message-ID: <4c6fb817-c66a-272e-9d9e-7811f8959e0c@oracle.com> I'm not sure this update would work. As this is a special test, it might be possible to copy/past and update the template code (or old sample code) here as we did to use the old template. Xuelei On 12/15/2016 11:23 AM, Artem Smotrakov wrote: > Hello, > > Please review the patch below for > sun/security/ssl/SocketCreation/SocketCreation.java test. > > The test has been observed to fail intermittently, but I couldn't > reproduce it by running the test in a loop. The test creates sockets for > TLS connection in different ways. Even if the test is very old, I > wouldn't like to change its original behavior. It might be better to use > SSLSocketTemplate here, but it would require a significant update to > SSLSocketTemplate, and splitting the test to 5 tests. Instead of this, I > am proposing to add some simple synchronization on client side where the > test was seen to fail. If it doesn't work, we can try to use > SSLSocketTemplate then. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166531 > Webrev: http://cr.openjdk.java.net/~asmotrak/8166531/webrev.00/ > > Artem > From artem.smotrakov at oracle.com Thu Dec 15 22:09:24 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 15 Dec 2016 14:09:24 -0800 Subject: [9] RFR: 8166531: sun/security/ssl/SocketCreation/SocketCreation.java fails intermittently In-Reply-To: <4c6fb817-c66a-272e-9d9e-7811f8959e0c@oracle.com> References: <864d279d-d942-bf5d-e0cd-1f2893a81b69@oracle.com> <4c6fb817-c66a-272e-9d9e-7811f8959e0c@oracle.com> Message-ID: <575990ef-4623-fa60-df96-7dd79129fa50@oracle.com> Hi Xuelei, I am not sure either, but I would like to try. If it doesn't work, we can go and re-write the test to follow SSLSocketTemplate. Actually, I don't think it is really possible because SSLSocketTemplate uses connect() method which is not used by the test. Artem On 12/15/2016 02:04 PM, Xuelei Fan wrote: > I'm not sure this update would work. > > As this is a special test, it might be possible to copy/past and > update the template code (or old sample code) here as we did to use > the old template. > > Xuelei > > On 12/15/2016 11:23 AM, Artem Smotrakov wrote: >> Hello, >> >> Please review the patch below for >> sun/security/ssl/SocketCreation/SocketCreation.java test. >> >> The test has been observed to fail intermittently, but I couldn't >> reproduce it by running the test in a loop. The test creates sockets for >> TLS connection in different ways. Even if the test is very old, I >> wouldn't like to change its original behavior. It might be better to use >> SSLSocketTemplate here, but it would require a significant update to >> SSLSocketTemplate, and splitting the test to 5 tests. Instead of this, I >> am proposing to add some simple synchronization on client side where the >> test was seen to fail. If it doesn't work, we can try to use >> SSLSocketTemplate then. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166531 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8166531/webrev.00/ >> >> Artem >> From vincent.x.ryan at oracle.com Fri Dec 16 00:39:23 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 16 Dec 2016 00:39:23 +0000 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: References: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> Message-ID: <1C4D8A34-D449-4406-A353-19C2ECDC2DBB@oracle.com> Thanks Brad for those review comments. I?ve make some implementation changes and updated the existing ALPN tests. No public API changes. A new webrev is available at: http://cr.openjdk.java.net/~vinnie/8170282/webrev.02/ > On 9 Dec 2016, at 23:27, Bradford Wetmore wrote: > > API looks good. > > SSLEngineImpl/SSLSocketImpl.java > ================================ > 212/229: I might suggest a more descriptive variable name, like applicationSelector. "selector" is a bit ambiguous. > > 450/1379: > getHandshakeApplicationProtocolSelector()); > -> > selector); > > Xuelei wrote: > > > This method would work in server side only. You mention this point > > in the apiNote part. I'd like to spec this point in the beginning > > part. > > If you do something like this, then you need to be careful to mention something like "application protocols such as ALPN would do this on the server side..." NPN is the reverse, where the server offers the strings, and the client selects. > > > and application developer know what kind of information can be > > retrieved from the handshake session reliably. > > Whatever you put in here, make sure it can be changed later in case we are able revisit the selection mechanism. > > > The current application protocol selection scenarios looks like: > > In my previous response, I suggested a different approach where everything ALPN is done together. I think it may be similar to your N1-4. > > I look forward to the ServerHandshaker change next week. > > Brad > > > On 12/9/2016 1:08 PM, Vincent Ryan wrote: >> Thanks for your detailed review Brad. I?ve generated a new webrev: >> http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ >> >> >> >>> On 9 Dec 2016, at 01:34, Bradford Wetmore wrote: >>> >>> >>> Hi Vinnie, >>> >>> On 12/8/2016 2:18 PM, Vincent Ryan wrote: >>>> The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot >>>> be easily addressed using the existing ALPN APIs. >>>> >>>> This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications >>>> to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the >>>> TLS protocol implementation to be examined by the TLS server application before it sets the application protocol. >>>> Additional TLS parameters are also available for inspection in the callback function. >>>> >>>> This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs. >>> >>> Technically, the API could be used for NPN (though it's pretty much dead), so that would be a listing the options on the server side, and selection on client side. >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ >>> >>> SSLEngineImpl.java/SSLSocketImpl.java >>> ===================================== >>> Please use the standard handshaker initialization pattern where the Handshaker is initialized with all of the data/mechanisms needed for a complete handshake. This will will ensure consistent handshake results and avoid potential strange race conditions. (There's some corresponding API comments below.) >>> >>> You would register your callback after the handshaker.setApplicationProtocols() calls at (currently) line 444 in the SSLEngineImpl code. >>> >>> >>> SSLEngine.java/SSLSocket.java >>> ============================= >>> I would suggest putting an introduction to this addition in the class description section, that application values can be set using SSLParameters.setApplication...() and selected with the default algorithm, or that a more accurate selection mechanism can be created by registering the callback that could look at any Handshake in progress and make appropriate decisions. >>> >>> 1339: >>> Registers the callback function that selects an application protocol >>> value during the SSL/TLS/DTLS handshake. >>> -> >>> Registers a callback function that selects an application protocol >>> value for a SSL/TLS/DTLS handshake. The function overrides any values set using {@link SSLParameters#setApplicationProtocols SSLParameters.setApplicationProtocols}. >>> >>> and remove the corresponding section from the return docs (in the {@code String section}). >>> >>> the function's first argument enables the current >>> handshake settings to be inspected.
>>> -> >>> the function's first argument allows the current SSLEngine(SSLSocket) to be inspected, including the handshake session and configuration settings.
>>> >>> If null is returned, or a value that was not advertised >>> then the underlying protocol will determine what action >>> to take. >>> (For example, ALPN will send a "no_application_protocol" >>> alert and terminate the connection.) >>> -> >>> If the return value is null (no value chosen) or is a value that was not advertised by the peer, the underlying protocol will determine what action to take. (For example, ALPN will send a "no_application_protocol" alert and terminate the connection.) >>> >>> Also, TLS should be configured with parameters that >>> -> >>> Also, this SSLEngine(SSLSocket) should be configured with parameters that >>> >>> @param selector the callback function, or null to de-register. >>> -> >>> @param selector the callback function, or null to disable the callback functionality. >>> >>> Retrieves the callback function that selects an application protocol >>> value during the SSL/TLS/DTLS handshake. >>> -> >>> Retrieves the callback function that selects an application protocol >>> value during a SSL/TLS/DTLS handshake. >>> >>> This method should be called by TLS protocol implementations during >>> the TLS handshake. The callback function should not be called until >>> after the cipher suite has been selected. >>> >>> I would suggest removing this apiNote entirely. I expect only applications will call this method, so the first sentence is not necessary since it's up to the implementation how it wants to store the BiFunction. I expect that when the handshaker is initialized, the current BiFunction will be assigned to it, and thus can't be changed for the current handshake/Handshaker in progress. The second sentence ties an ordering to the selection of ciphersuite and ALPN value, and will tie our hands if we ever revisit the group protocol/ciphersuite/SNI/ALPN selection discussion. >>> >>> ServerHandshaker.java >>> ===================== >>> I was expecting that the ALPN callback logic would be an update for our current ALPN decision logic. If a callback was set, use it, else look at defined strings from the SSLParameters, else fail. e.g. >>> >>> ALPNExtension clientHelloALPN = (ALPNExtension) >>> mesg.extensions.get(ExtensionType.EXT_ALPN); >>> >>> if (clientHelloALPN != null) { >>> List protocols = clientHelloALPN.getPeerAPs(); >>> if (applicationSelector != null) { >>> applicationProtocol = >>> selector.apply(SSLEngine/SSLSocket, peerAPs); >>> } else if (localApl.length > 0)) { >>> // Intersect the requested and the locally supported, >>> // and save for later. Use server preference order >>> for (String ap : localApl) { >>> ...deleted... >>> } >>> applicationProtocol = negotiatedValue; >>> } >>> if (negotiatedValue == null) { >>> fatalSE(Alerts.alert_no_application_protocol, >>> new SSLHandshakeException( >>> "No matching ALPN values")); >>> } >>> } >>> >>> Thanks. >>> >>> Brad >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Fri Dec 16 01:15:24 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 15 Dec 2016 17:15:24 -0800 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <1C4D8A34-D449-4406-A353-19C2ECDC2DBB@oracle.com> References: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> <1C4D8A34-D449-4406-A353-19C2ECDC2DBB@oracle.com> Message-ID: <3df1767d-84ed-05e1-2945-619d92bf3e92@oracle.com> (Xuelei, question for you below) Hi Vinnie, There is no test yet for SSLEngine/SSLSocket: public BiFunction, String> getHandshakeApplicationProtocolSelector() { Tests are passing at 100% with latest jdk.patch. SSLSocketImpl.java ================== 2672: Sorry, but I think what you want here is: if ((handshaker != null) && !handshaker.started()) { -> if ((handshaker != null) && !handshaker.activated()) { Xuelei can confirm. BTW, I just filed: 8171337: Check for correct SSLEngineImpl/SSLSocketImpl.setSSLParameters handshaker update method as I think setSSLParameters may be using the wrong method. SSLEngineImpl.java ================== 2275: I misspoke earlier today. Please add a similar change that you made in SSLSocket (2671-2674). if ((handshaker != null) && !handshaker.activated()) { ServerHandshaker.java ===================== 536: Minor nit: suggest renaming hasCallback to something a little more descriptive. By the time you drop 400 lines, you may have forgotten the variable meaning. hasAPCallback? 535: A comments describing your current logic would be nice. if (there is a callback) { use the callback } else { use the list } Rest looks good! Thanks. Brad On 12/15/2016 4:39 PM, Vincent Ryan wrote: > Thanks Brad for those review comments. > > I?ve make some implementation changes and updated the existing ALPN tests. > No public API changes. > > A new webrev is available at: > http://cr.openjdk.java.net/~vinnie/8170282/webrev.02/ > > > >> On 9 Dec 2016, at 23:27, Bradford Wetmore > > wrote: >> >> API looks good. >> >> SSLEngineImpl/SSLSocketImpl.java >> ================================ >> 212/229: I might suggest a more descriptive variable name, like >> applicationSelector. "selector" is a bit ambiguous. >> >> 450/1379: >> getHandshakeApplicationProtocolSelector()); >> -> >> selector); >> >> Xuelei wrote: >> >> > This method would work in server side only. You mention this point >> > in the apiNote part. I'd like to spec this point in the beginning >> > part. >> >> If you do something like this, then you need to be careful to mention >> something like "application protocols such as ALPN would do this on >> the server side..." NPN is the reverse, where the server offers the >> strings, and the client selects. >> >> > and application developer know what kind of information can be >> > retrieved from the handshake session reliably. >> >> Whatever you put in here, make sure it can be changed later in case we >> are able revisit the selection mechanism. >> >> > The current application protocol selection scenarios looks like: >> >> In my previous response, I suggested a different approach where >> everything ALPN is done together. I think it may be similar to your N1-4. >> >> I look forward to the ServerHandshaker change next week. >> >> Brad >> >> >> On 12/9/2016 1:08 PM, Vincent Ryan wrote: >>> Thanks for your detailed review Brad. I?ve generated a new webrev: >>> http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ >>> >>> >>> >>>> On 9 Dec 2016, at 01:34, Bradford Wetmore >>>> > >>>> wrote: >>>> >>>> >>>> Hi Vinnie, >>>> >>>> On 12/8/2016 2:18 PM, Vincent Ryan wrote: >>>>> The Java Servlet Expect Group reported that they have identified a >>>>> specific HTTP2 server use-case that cannot >>>>> be easily addressed using the existing ALPN APIs. >>>>> >>>>> This changeset fixes that problem. It supports a new callback >>>>> mechanism to allow TLS server applications >>>>> to set an application protocol during the TLS handshake. >>>>> Specifically it allows the cipher suite chosen by the >>>>> TLS protocol implementation to be examined by the TLS server >>>>> application before it sets the application protocol. >>>>> Additional TLS parameters are also available for inspection in the >>>>> callback function. >>>>> >>>>> This new mechanism is available only to TLS server applications. >>>>> TLS clients will continue to use the existing ALPN APIs. >>>> >>>> Technically, the API could be used for NPN (though it's pretty much >>>> dead), so that would be a listing the options on the server side, >>>> and selection on client side. >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ >>>> >>>> SSLEngineImpl.java/SSLSocketImpl.java >>>> ===================================== >>>> Please use the standard handshaker initialization pattern where the >>>> Handshaker is initialized with all of the data/mechanisms needed for >>>> a complete handshake. This will will ensure consistent handshake >>>> results and avoid potential strange race conditions. (There's some >>>> corresponding API comments below.) >>>> >>>> You would register your callback after the >>>> handshaker.setApplicationProtocols() calls at (currently) line 444 >>>> in the SSLEngineImpl code. >>>> >>>> >>>> SSLEngine.java/SSLSocket.java >>>> ============================= >>>> I would suggest putting an introduction to this addition in the >>>> class description section, that application values can be set using >>>> SSLParameters.setApplication...() and selected with the default >>>> algorithm, or that a more accurate selection mechanism can be >>>> created by registering the callback that could look at any Handshake >>>> in progress and make appropriate decisions. >>>> >>>> 1339: >>>> Registers the callback function that selects an application protocol >>>> value during the SSL/TLS/DTLS handshake. >>>> -> >>>> Registers a callback function that selects an application protocol >>>> value for a SSL/TLS/DTLS handshake. The function overrides any >>>> values set using {@link SSLParameters#setApplicationProtocols >>>> SSLParameters.setApplicationProtocols}. >>>> >>>> and remove the corresponding section from the return docs (in the >>>> {@code String section}). >>>> >>>> the function's first argument enables the current >>>> handshake settings to be inspected.
>>>> -> >>>> the function's first argument allows the current >>>> SSLEngine(SSLSocket) to be inspected, including the handshake >>>> session and configuration settings.
>>>> >>>> If null is returned, or a value that was not advertised >>>> then the underlying protocol will determine what action >>>> to take. >>>> (For example, ALPN will send a "no_application_protocol" >>>> alert and terminate the connection.) >>>> -> >>>> If the return value is null (no value chosen) or is a value that was >>>> not advertised by the peer, the underlying protocol will determine >>>> what action to take. (For example, ALPN will send a >>>> "no_application_protocol" alert and terminate the connection.) >>>> >>>> Also, TLS should be configured with parameters that >>>> -> >>>> Also, this SSLEngine(SSLSocket) should be configured with parameters >>>> that >>>> >>>> @param selector the callback function, or null to de-register. >>>> -> >>>> @param selector the callback function, or null to disable the >>>> callback functionality. >>>> >>>> Retrieves the callback function that selects an application protocol >>>> value during the SSL/TLS/DTLS handshake. >>>> -> >>>> Retrieves the callback function that selects an application protocol >>>> value during a SSL/TLS/DTLS handshake. >>>> >>>> This method should be called by TLS protocol implementations during >>>> the TLS handshake. The callback function should not be called until >>>> after the cipher suite has been selected. >>>> >>>> I would suggest removing this apiNote entirely. I expect only >>>> applications will call this method, so the first sentence is not >>>> necessary since it's up to the implementation how it wants to store >>>> the BiFunction. I expect that when the handshaker is initialized, >>>> the current BiFunction will be assigned to it, and thus can't be >>>> changed for the current handshake/Handshaker in progress. The >>>> second sentence ties an ordering to the selection of ciphersuite and >>>> ALPN value, and will tie our hands if we ever revisit the group >>>> protocol/ciphersuite/SNI/ALPN selection discussion. >>>> >>>> ServerHandshaker.java >>>> ===================== >>>> I was expecting that the ALPN callback logic would be an update for >>>> our current ALPN decision logic. If a callback was set, use it, >>>> else look at defined strings from the SSLParameters, else fail. e.g. >>>> >>>> ALPNExtension clientHelloALPN = (ALPNExtension) >>>> mesg.extensions.get(ExtensionType.EXT_ALPN); >>>> >>>> if (clientHelloALPN != null) { >>>> List protocols = clientHelloALPN.getPeerAPs(); >>>> if (applicationSelector != null) { >>>> applicationProtocol = >>>> selector.apply(SSLEngine/SSLSocket, peerAPs); >>>> } else if (localApl.length > 0)) { >>>> // Intersect the requested and the locally supported, >>>> // and save for later. Use server preference order >>>> for (String ap : localApl) { >>>> ...deleted... >>>> } >>>> applicationProtocol = negotiatedValue; >>>> } >>>> if (negotiatedValue == null) { >>>> fatalSE(Alerts.alert_no_application_protocol, >>>> new SSLHandshakeException( >>>> "No matching ALPN values")); >>>> } >>>> } >>>> >>>> Thanks. >>>> >>>> Brad >>>> >>>> >>> > From xuelei.fan at oracle.com Fri Dec 16 01:52:19 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 15 Dec 2016 17:52:19 -0800 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <3df1767d-84ed-05e1-2945-619d92bf3e92@oracle.com> References: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> <1C4D8A34-D449-4406-A353-19C2ECDC2DBB@oracle.com> <3df1767d-84ed-05e1-2945-619d92bf3e92@oracle.com> Message-ID: On 12/15/2016 5:15 PM, Bradford Wetmore wrote: > (Xuelei, question for you below) > > Hi Vinnie, > > There is no test yet for SSLEngine/SSLSocket: > > public BiFunction, String> > getHandshakeApplicationProtocolSelector() { > > Tests are passing at 100% with latest jdk.patch. > > > SSLSocketImpl.java > ================== > 2672: Sorry, but I think what you want here is: > > if ((handshaker != null) && !handshaker.started()) { > -> > if ((handshaker != null) && !handshaker.activated()) { > > Xuelei can confirm. More safe to use activated(). Xuelei > BTW, I just filed: > > 8171337: Check for > correct SSLEngineImpl/SSLSocketImpl.setSSLParameters > handshaker update method > > as I think setSSLParameters may be using the wrong method. > > > SSLEngineImpl.java > ================== > 2275: I misspoke earlier today. Please add a similar change that you > made in SSLSocket (2671-2674). > > if ((handshaker != null) && !handshaker.activated()) { > > > ServerHandshaker.java > ===================== > 536: Minor nit: suggest renaming hasCallback to something a little > more descriptive. By the time you drop 400 lines, you may have > forgotten the variable meaning. hasAPCallback? > > 535: A comments describing your current logic would be nice. > > if (there is a callback) { > use the callback > } else { > use the list > } > > Rest looks good! Thanks. > > Brad > > > > On 12/15/2016 4:39 PM, Vincent Ryan wrote: >> Thanks Brad for those review comments. >> >> I?ve make some implementation changes and updated the existing ALPN >> tests. >> No public API changes. >> >> A new webrev is available at: >> http://cr.openjdk.java.net/~vinnie/8170282/webrev.02/ >> >> >> >>> On 9 Dec 2016, at 23:27, Bradford Wetmore >> > wrote: >>> >>> API looks good. >>> >>> SSLEngineImpl/SSLSocketImpl.java >>> ================================ >>> 212/229: I might suggest a more descriptive variable name, like >>> applicationSelector. "selector" is a bit ambiguous. >>> >>> 450/1379: >>> getHandshakeApplicationProtocolSelector()); >>> -> >>> selector); >>> >>> Xuelei wrote: >>> >>> > This method would work in server side only. You mention this point >>> > in the apiNote part. I'd like to spec this point in the beginning >>> > part. >>> >>> If you do something like this, then you need to be careful to mention >>> something like "application protocols such as ALPN would do this on >>> the server side..." NPN is the reverse, where the server offers the >>> strings, and the client selects. >>> >>> > and application developer know what kind of information can be >>> > retrieved from the handshake session reliably. >>> >>> Whatever you put in here, make sure it can be changed later in case we >>> are able revisit the selection mechanism. >>> >>> > The current application protocol selection scenarios looks like: >>> >>> In my previous response, I suggested a different approach where >>> everything ALPN is done together. I think it may be similar to your >>> N1-4. >>> >>> I look forward to the ServerHandshaker change next week. >>> >>> Brad >>> >>> >>> On 12/9/2016 1:08 PM, Vincent Ryan wrote: >>>> Thanks for your detailed review Brad. I?ve generated a new webrev: >>>> http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ >>>> >>>> >>>> >>>>> On 9 Dec 2016, at 01:34, Bradford Wetmore >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi Vinnie, >>>>> >>>>> On 12/8/2016 2:18 PM, Vincent Ryan wrote: >>>>>> The Java Servlet Expect Group reported that they have identified a >>>>>> specific HTTP2 server use-case that cannot >>>>>> be easily addressed using the existing ALPN APIs. >>>>>> >>>>>> This changeset fixes that problem. It supports a new callback >>>>>> mechanism to allow TLS server applications >>>>>> to set an application protocol during the TLS handshake. >>>>>> Specifically it allows the cipher suite chosen by the >>>>>> TLS protocol implementation to be examined by the TLS server >>>>>> application before it sets the application protocol. >>>>>> Additional TLS parameters are also available for inspection in the >>>>>> callback function. >>>>>> >>>>>> This new mechanism is available only to TLS server applications. >>>>>> TLS clients will continue to use the existing ALPN APIs. >>>>> >>>>> Technically, the API could be used for NPN (though it's pretty much >>>>> dead), so that would be a listing the options on the server side, >>>>> and selection on client side. >>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 >>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ >>>>> >>>>> SSLEngineImpl.java/SSLSocketImpl.java >>>>> ===================================== >>>>> Please use the standard handshaker initialization pattern where the >>>>> Handshaker is initialized with all of the data/mechanisms needed for >>>>> a complete handshake. This will will ensure consistent handshake >>>>> results and avoid potential strange race conditions. (There's some >>>>> corresponding API comments below.) >>>>> >>>>> You would register your callback after the >>>>> handshaker.setApplicationProtocols() calls at (currently) line 444 >>>>> in the SSLEngineImpl code. >>>>> >>>>> >>>>> SSLEngine.java/SSLSocket.java >>>>> ============================= >>>>> I would suggest putting an introduction to this addition in the >>>>> class description section, that application values can be set using >>>>> SSLParameters.setApplication...() and selected with the default >>>>> algorithm, or that a more accurate selection mechanism can be >>>>> created by registering the callback that could look at any Handshake >>>>> in progress and make appropriate decisions. >>>>> >>>>> 1339: >>>>> Registers the callback function that selects an application protocol >>>>> value during the SSL/TLS/DTLS handshake. >>>>> -> >>>>> Registers a callback function that selects an application protocol >>>>> value for a SSL/TLS/DTLS handshake. The function overrides any >>>>> values set using {@link SSLParameters#setApplicationProtocols >>>>> SSLParameters.setApplicationProtocols}. >>>>> >>>>> and remove the corresponding section from the return docs (in the >>>>> {@code String section}). >>>>> >>>>> the function's first argument enables the current >>>>> handshake settings to be inspected.
>>>>> -> >>>>> the function's first argument allows the current >>>>> SSLEngine(SSLSocket) to be inspected, including the handshake >>>>> session and configuration settings.
>>>>> >>>>> If null is returned, or a value that was not advertised >>>>> then the underlying protocol will determine what action >>>>> to take. >>>>> (For example, ALPN will send a "no_application_protocol" >>>>> alert and terminate the connection.) >>>>> -> >>>>> If the return value is null (no value chosen) or is a value that was >>>>> not advertised by the peer, the underlying protocol will determine >>>>> what action to take. (For example, ALPN will send a >>>>> "no_application_protocol" alert and terminate the connection.) >>>>> >>>>> Also, TLS should be configured with parameters that >>>>> -> >>>>> Also, this SSLEngine(SSLSocket) should be configured with parameters >>>>> that >>>>> >>>>> @param selector the callback function, or null to de-register. >>>>> -> >>>>> @param selector the callback function, or null to disable the >>>>> callback functionality. >>>>> >>>>> Retrieves the callback function that selects an application protocol >>>>> value during the SSL/TLS/DTLS handshake. >>>>> -> >>>>> Retrieves the callback function that selects an application protocol >>>>> value during a SSL/TLS/DTLS handshake. >>>>> >>>>> This method should be called by TLS protocol implementations during >>>>> the TLS handshake. The callback function should not be called until >>>>> after the cipher suite has been selected. >>>>> >>>>> I would suggest removing this apiNote entirely. I expect only >>>>> applications will call this method, so the first sentence is not >>>>> necessary since it's up to the implementation how it wants to store >>>>> the BiFunction. I expect that when the handshaker is initialized, >>>>> the current BiFunction will be assigned to it, and thus can't be >>>>> changed for the current handshake/Handshaker in progress. The >>>>> second sentence ties an ordering to the selection of ciphersuite and >>>>> ALPN value, and will tie our hands if we ever revisit the group >>>>> protocol/ciphersuite/SNI/ALPN selection discussion. >>>>> >>>>> ServerHandshaker.java >>>>> ===================== >>>>> I was expecting that the ALPN callback logic would be an update for >>>>> our current ALPN decision logic. If a callback was set, use it, >>>>> else look at defined strings from the SSLParameters, else fail. e.g. >>>>> >>>>> ALPNExtension clientHelloALPN = (ALPNExtension) >>>>> mesg.extensions.get(ExtensionType.EXT_ALPN); >>>>> >>>>> if (clientHelloALPN != null) { >>>>> List protocols = clientHelloALPN.getPeerAPs(); >>>>> if (applicationSelector != null) { >>>>> applicationProtocol = >>>>> selector.apply(SSLEngine/SSLSocket, peerAPs); >>>>> } else if (localApl.length > 0)) { >>>>> // Intersect the requested and the locally supported, >>>>> // and save for later. Use server preference order >>>>> for (String ap : localApl) { >>>>> ...deleted... >>>>> } >>>>> applicationProtocol = negotiatedValue; >>>>> } >>>>> if (negotiatedValue == null) { >>>>> fatalSE(Alerts.alert_no_application_protocol, >>>>> new SSLHandshakeException( >>>>> "No matching ALPN values")); >>>>> } >>>>> } >>>>> >>>>> Thanks. >>>>> >>>>> Brad >>>>> >>>>> >>>> >> From weijun.wang at oracle.com Fri Dec 16 03:43:19 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 16 Dec 2016 11:43:19 +0800 Subject: RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac Message-ID: <40f9a2d2-d4af-f5c5-2770-ce84949d1c24@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8171340/webrev.00/ All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)". Everything else is whitespace change. Thanks Max From weijun.wang at oracle.com Fri Dec 16 08:07:53 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 16 Dec 2016 16:07:53 +0800 Subject: RFR 8171353: New home for SecurityTools.java test utility Message-ID: Hi Artem I hope you are OK with this change: diff --git a/test/lib/security/SecurityTools.java b/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java rename from test/lib/security/SecurityTools.java rename to test/lib/testlibrary/jdk/testlibrary/SecurityTools.java --- a/test/lib/security/SecurityTools.java +++ b/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java @@ -20,13 +20,11 @@ * or visit www.oracle.com if you need additional information or have any * questions. */ +package jdk.testlibrary; import java.util.ArrayList; import java.util.Collections; import java.util.List; -import jdk.testlibrary.JDKToolLauncher; -import jdk.testlibrary.OutputAnalyzer; -import jdk.testlibrary.ProcessTools; public class SecurityTools { diff --git a/test/sun/security/tools/keytool/PrintSSL.java b/test/sun/security/tools/keytool/PrintSSL.java --- a/test/sun/security/tools/keytool/PrintSSL.java +++ b/test/sun/security/tools/keytool/PrintSSL.java @@ -25,7 +25,6 @@ * @test * @bug 6480981 8160624 * @summary keytool should be able to import certificates from remote SSL server - * @library /lib/security * @library /lib/testlibrary * @run main/othervm PrintSSL */ @@ -37,6 +36,7 @@ import javax.net.ssl.SSLServerSocketFactory; import javax.net.ssl.SSLSocket; import jdk.testlibrary.OutputAnalyzer; +import jdk.testlibrary.SecurityTools; public class PrintSSL { diff --git a/test/sun/security/tools/keytool/ReadJar.java b/test/sun/security/tools/keytool/ReadJar.java --- a/test/sun/security/tools/keytool/ReadJar.java +++ b/test/sun/security/tools/keytool/ReadJar.java @@ -25,7 +25,6 @@ * @test * @bug 6890872 8168882 * @summary keytool -printcert to recognize signed jar files - * @library /lib/security * @library /lib/testlibrary */ @@ -33,6 +32,7 @@ import java.nio.file.Paths; import jdk.testlibrary.JarUtils; import jdk.testlibrary.OutputAnalyzer; +import jdk.testlibrary.SecurityTools; public class ReadJar { Thanks Max From chris.hegarty at oracle.com Fri Dec 16 09:49:54 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 16 Dec 2016 09:49:54 +0000 Subject: RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac In-Reply-To: <40f9a2d2-d4af-f5c5-2770-ce84949d1c24@oracle.com> References: <40f9a2d2-d4af-f5c5-2770-ce84949d1c24@oracle.com> Message-ID: <680a8e3c-cc28-6d71-c5af-2d7e55068bcb@oracle.com> On 16/12/16 03:43, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8171340/webrev.00/ > > All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)". Thank you Max. Reviewed. -Chris. From vincent.x.ryan at oracle.com Fri Dec 16 11:51:24 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 16 Dec 2016 11:51:24 +0000 Subject: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake In-Reply-To: <3df1767d-84ed-05e1-2945-619d92bf3e92@oracle.com> References: <5e048efd-a2ee-58e2-d635-9f0e1c9f71ff@oracle.com> <1C4D8A34-D449-4406-A353-19C2ECDC2DBB@oracle.com> <3df1767d-84ed-05e1-2945-619d92bf3e92@oracle.com> Message-ID: I?ve made the change to use activated() rather than started() in SSLEngineImpl and SSLSocketImpl and also the suggestions for ServerHandshaker. I?ve also updated the tests to check SSLEngine/SSLSocket.getHandshakeApplicationProtocolSelector. All tests pass. Thanks for all the review comments. > On 16 Dec 2016, at 01:15, Bradford Wetmore wrote: > > (Xuelei, question for you below) > > Hi Vinnie, > > There is no test yet for SSLEngine/SSLSocket: > > public BiFunction, String> > getHandshakeApplicationProtocolSelector() { > > Tests are passing at 100% with latest jdk.patch. > > > SSLSocketImpl.java > ================== > 2672: Sorry, but I think what you want here is: > > if ((handshaker != null) && !handshaker.started()) { > -> > if ((handshaker != null) && !handshaker.activated()) { > > Xuelei can confirm. BTW, I just filed: > > 8171337: Check for > correct SSLEngineImpl/SSLSocketImpl.setSSLParameters > handshaker update method > > as I think setSSLParameters may be using the wrong method. > > > SSLEngineImpl.java > ================== > 2275: I misspoke earlier today. Please add a similar change that you made in SSLSocket (2671-2674). > > if ((handshaker != null) && !handshaker.activated()) { > > > ServerHandshaker.java > ===================== > 536: Minor nit: suggest renaming hasCallback to something a little more descriptive. By the time you drop 400 lines, you may have forgotten the variable meaning. hasAPCallback? > > 535: A comments describing your current logic would be nice. > > if (there is a callback) { > use the callback > } else { > use the list > } > > Rest looks good! Thanks. > > Brad > > > > On 12/15/2016 4:39 PM, Vincent Ryan wrote: >> Thanks Brad for those review comments. >> >> I?ve make some implementation changes and updated the existing ALPN tests. >> No public API changes. >> >> A new webrev is available at: >> http://cr.openjdk.java.net/~vinnie/8170282/webrev.02/ >> >> >> >>> On 9 Dec 2016, at 23:27, Bradford Wetmore >> > wrote: >>> >>> API looks good. >>> >>> SSLEngineImpl/SSLSocketImpl.java >>> ================================ >>> 212/229: I might suggest a more descriptive variable name, like >>> applicationSelector. "selector" is a bit ambiguous. >>> >>> 450/1379: >>> getHandshakeApplicationProtocolSelector()); >>> -> >>> selector); >>> >>> Xuelei wrote: >>> >>> > This method would work in server side only. You mention this point >>> > in the apiNote part. I'd like to spec this point in the beginning >>> > part. >>> >>> If you do something like this, then you need to be careful to mention >>> something like "application protocols such as ALPN would do this on >>> the server side..." NPN is the reverse, where the server offers the >>> strings, and the client selects. >>> >>> > and application developer know what kind of information can be >>> > retrieved from the handshake session reliably. >>> >>> Whatever you put in here, make sure it can be changed later in case we >>> are able revisit the selection mechanism. >>> >>> > The current application protocol selection scenarios looks like: >>> >>> In my previous response, I suggested a different approach where >>> everything ALPN is done together. I think it may be similar to your N1-4. >>> >>> I look forward to the ServerHandshaker change next week. >>> >>> Brad >>> >>> >>> On 12/9/2016 1:08 PM, Vincent Ryan wrote: >>>> Thanks for your detailed review Brad. I?ve generated a new webrev: >>>> http://cr.openjdk.java.net/~vinnie/8170282/webrev.01/ >>>> >>>> >>>> >>>>> On 9 Dec 2016, at 01:34, Bradford Wetmore >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> Hi Vinnie, >>>>> >>>>> On 12/8/2016 2:18 PM, Vincent Ryan wrote: >>>>>> The Java Servlet Expect Group reported that they have identified a >>>>>> specific HTTP2 server use-case that cannot >>>>>> be easily addressed using the existing ALPN APIs. >>>>>> >>>>>> This changeset fixes that problem. It supports a new callback >>>>>> mechanism to allow TLS server applications >>>>>> to set an application protocol during the TLS handshake. >>>>>> Specifically it allows the cipher suite chosen by the >>>>>> TLS protocol implementation to be examined by the TLS server >>>>>> application before it sets the application protocol. >>>>>> Additional TLS parameters are also available for inspection in the >>>>>> callback function. >>>>>> >>>>>> This new mechanism is available only to TLS server applications. >>>>>> TLS clients will continue to use the existing ALPN APIs. >>>>> >>>>> Technically, the API could be used for NPN (though it's pretty much >>>>> dead), so that would be a listing the options on the server side, >>>>> and selection on client side. >>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170282 >>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8170282/webrev.00/ >>>>> >>>>> SSLEngineImpl.java/SSLSocketImpl.java >>>>> ===================================== >>>>> Please use the standard handshaker initialization pattern where the >>>>> Handshaker is initialized with all of the data/mechanisms needed for >>>>> a complete handshake. This will will ensure consistent handshake >>>>> results and avoid potential strange race conditions. (There's some >>>>> corresponding API comments below.) >>>>> >>>>> You would register your callback after the >>>>> handshaker.setApplicationProtocols() calls at (currently) line 444 >>>>> in the SSLEngineImpl code. >>>>> >>>>> >>>>> SSLEngine.java/SSLSocket.java >>>>> ============================= >>>>> I would suggest putting an introduction to this addition in the >>>>> class description section, that application values can be set using >>>>> SSLParameters.setApplication...() and selected with the default >>>>> algorithm, or that a more accurate selection mechanism can be >>>>> created by registering the callback that could look at any Handshake >>>>> in progress and make appropriate decisions. >>>>> >>>>> 1339: >>>>> Registers the callback function that selects an application protocol >>>>> value during the SSL/TLS/DTLS handshake. >>>>> -> >>>>> Registers a callback function that selects an application protocol >>>>> value for a SSL/TLS/DTLS handshake. The function overrides any >>>>> values set using {@link SSLParameters#setApplicationProtocols >>>>> SSLParameters.setApplicationProtocols}. >>>>> >>>>> and remove the corresponding section from the return docs (in the >>>>> {@code String section}). >>>>> >>>>> the function's first argument enables the current >>>>> handshake settings to be inspected.
>>>>> -> >>>>> the function's first argument allows the current >>>>> SSLEngine(SSLSocket) to be inspected, including the handshake >>>>> session and configuration settings.
>>>>> >>>>> If null is returned, or a value that was not advertised >>>>> then the underlying protocol will determine what action >>>>> to take. >>>>> (For example, ALPN will send a "no_application_protocol" >>>>> alert and terminate the connection.) >>>>> -> >>>>> If the return value is null (no value chosen) or is a value that was >>>>> not advertised by the peer, the underlying protocol will determine >>>>> what action to take. (For example, ALPN will send a >>>>> "no_application_protocol" alert and terminate the connection.) >>>>> >>>>> Also, TLS should be configured with parameters that >>>>> -> >>>>> Also, this SSLEngine(SSLSocket) should be configured with parameters >>>>> that >>>>> >>>>> @param selector the callback function, or null to de-register. >>>>> -> >>>>> @param selector the callback function, or null to disable the >>>>> callback functionality. >>>>> >>>>> Retrieves the callback function that selects an application protocol >>>>> value during the SSL/TLS/DTLS handshake. >>>>> -> >>>>> Retrieves the callback function that selects an application protocol >>>>> value during a SSL/TLS/DTLS handshake. >>>>> >>>>> This method should be called by TLS protocol implementations during >>>>> the TLS handshake. The callback function should not be called until >>>>> after the cipher suite has been selected. >>>>> >>>>> I would suggest removing this apiNote entirely. I expect only >>>>> applications will call this method, so the first sentence is not >>>>> necessary since it's up to the implementation how it wants to store >>>>> the BiFunction. I expect that when the handshaker is initialized, >>>>> the current BiFunction will be assigned to it, and thus can't be >>>>> changed for the current handshake/Handshaker in progress. The >>>>> second sentence ties an ordering to the selection of ciphersuite and >>>>> ALPN value, and will tie our hands if we ever revisit the group >>>>> protocol/ciphersuite/SNI/ALPN selection discussion. >>>>> >>>>> ServerHandshaker.java >>>>> ===================== >>>>> I was expecting that the ALPN callback logic would be an update for >>>>> our current ALPN decision logic. If a callback was set, use it, >>>>> else look at defined strings from the SSLParameters, else fail. e.g. >>>>> >>>>> ALPNExtension clientHelloALPN = (ALPNExtension) >>>>> mesg.extensions.get(ExtensionType.EXT_ALPN); >>>>> >>>>> if (clientHelloALPN != null) { >>>>> List protocols = clientHelloALPN.getPeerAPs(); >>>>> if (applicationSelector != null) { >>>>> applicationProtocol = >>>>> selector.apply(SSLEngine/SSLSocket, peerAPs); >>>>> } else if (localApl.length > 0)) { >>>>> // Intersect the requested and the locally supported, >>>>> // and save for later. Use server preference order >>>>> for (String ap : localApl) { >>>>> ...deleted... >>>>> } >>>>> applicationProtocol = negotiatedValue; >>>>> } >>>>> if (negotiatedValue == null) { >>>>> fatalSE(Alerts.alert_no_application_protocol, >>>>> new SSLHandshakeException( >>>>> "No matching ALPN values")); >>>>> } >>>>> } >>>>> >>>>> Thanks. >>>>> >>>>> Brad >>>>> >>>>> >>>> >> From sean.mullan at oracle.com Fri Dec 16 16:14:23 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Dec 2016 11:14:23 -0500 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: References: Message-ID: Hi Xuelei, First cut of a review at this. I still need to review TrustStoreManager, so will get back to you later on that. Looks very good so far. * KeyStores.java Do an 'hg rename' on this file, so you can see the diffs between this and the new name (TrustStoreUtil), and you preserve the history. * TrustStoreUtil.java 54 Set set = new HashSet(); Use <> operator. 71 } catch (KeyStoreException e) { 72 // ignore 73 } This should be rare, but maybe we want to log this. * TrustStoreManager.java 65 public static KeyStore getgetTrustedKeyStore() throws Exception { s/getget/get/ * TrustManagerFactoryImpl.java 85 abstract X509TrustManager getInstance( 86 Collection trustedCerts) throws KeyStoreException; It no longer makes sense for this method to throw KeyStoreException. * X509TrustManagerImpl.java 71 X509TrustManagerImpl(String validatorType, 72 Collection trustedCerts) throws KeyStoreException { No longer can throw KeyStoreException so it can be removed from throws clause. 83 if (debug != null && Debug.isOn("trustmanager")) { 84 showTrustedCerts(); Not sure why you made this change (and on line 99) because showTrustedCerts is still only called if debug is enabled. --Sean On 11/26/16 7:46 PM, Xuelei Fan wrote: > Hi, > > Please review the performance enhancement update: > > http://cr.openjdk.java.net/~xuelei/8129988/webrev.00/ > > In SunJSSE provider, there are two ways to use the default trust store > (lib/security/cacerts), using the default SSLContext instance or using > the default trust manager. > > The default SSLContext holds a strong reference to a collection of > trusted certificates in cacerts in static mode. The default trust > manager reads the cacerts file and creates a KeyStore and parses the > certificates each time. > > With the growth of cacerts, the loading and cache of trusted certificate > is not performance friendly. > > In this fix, I'm trying to find a balance between CPU and memory: reuse > the loaded trusted certificates if possible and release the unused > trusted certificates if necessary. > > Thanks, > Xuelei > From artem.smotrakov at oracle.com Fri Dec 16 17:56:41 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 16 Dec 2016 09:56:41 -0800 Subject: RFR 8171353: New home for SecurityTools.java test utility In-Reply-To: References: Message-ID: <8d270e3f-f0a6-7485-42dc-0e6e94df8bc2@oracle.com> Hi Max, I am fine with it. Artem On 12/16/2016 12:07 AM, Wang Weijun wrote: > Hi Artem > > I hope you are OK with this change: > > diff --git a/test/lib/security/SecurityTools.java b/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java > rename from test/lib/security/SecurityTools.java > rename to test/lib/testlibrary/jdk/testlibrary/SecurityTools.java > --- a/test/lib/security/SecurityTools.java > +++ b/test/lib/testlibrary/jdk/testlibrary/SecurityTools.java > @@ -20,13 +20,11 @@ > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > +package jdk.testlibrary; > > import java.util.ArrayList; > import java.util.Collections; > import java.util.List; > -import jdk.testlibrary.JDKToolLauncher; > -import jdk.testlibrary.OutputAnalyzer; > -import jdk.testlibrary.ProcessTools; > > public class SecurityTools { > > diff --git a/test/sun/security/tools/keytool/PrintSSL.java b/test/sun/security/tools/keytool/PrintSSL.java > --- a/test/sun/security/tools/keytool/PrintSSL.java > +++ b/test/sun/security/tools/keytool/PrintSSL.java > @@ -25,7 +25,6 @@ > * @test > * @bug 6480981 8160624 > * @summary keytool should be able to import certificates from remote SSL server > - * @library /lib/security > * @library /lib/testlibrary > * @run main/othervm PrintSSL > */ > @@ -37,6 +36,7 @@ > import javax.net.ssl.SSLServerSocketFactory; > import javax.net.ssl.SSLSocket; > import jdk.testlibrary.OutputAnalyzer; > +import jdk.testlibrary.SecurityTools; > > public class PrintSSL { > > diff --git a/test/sun/security/tools/keytool/ReadJar.java b/test/sun/security/tools/keytool/ReadJar.java > --- a/test/sun/security/tools/keytool/ReadJar.java > +++ b/test/sun/security/tools/keytool/ReadJar.java > @@ -25,7 +25,6 @@ > * @test > * @bug 6890872 8168882 > * @summary keytool -printcert to recognize signed jar files > - * @library /lib/security > * @library /lib/testlibrary > */ > > @@ -33,6 +32,7 @@ > import java.nio.file.Paths; > import jdk.testlibrary.JarUtils; > import jdk.testlibrary.OutputAnalyzer; > +import jdk.testlibrary.SecurityTools; > > public class ReadJar { > > Thanks > Max > From xuelei.fan at oracle.com Fri Dec 16 19:03:57 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 16 Dec 2016 11:03:57 -0800 Subject: Code Review Request, JDK-8171337 Check for correct SSLEngineImpl/SSLSocketImpl.setSSLParameters handshaker update method Message-ID: <5f70dd69-e177-1118-005c-bcf4987b23fb@oracle.com> Hi Brad, Please review this handshake update method miss-use fix: http://cr.openjdk.java.net/~xuelei/8171337/webrev.00/ The activation process of handshake may consider the parameters in a big picture and make adjustment accordingly. Basically, SSL parameters should be configured before the handshake activated. Thanks, Xuelei From amanda.jiang at oracle.com Sun Dec 18 21:38:13 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Sun, 18 Dec 2016 13:38:13 -0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: References: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> Message-ID: <6ddf6f80-edf6-367c-b3aa-cdf2ecfa314c@oracle.com> Hi Paul, Artem and Max, Thanks for your comments. Please check the new webrev at: http://cr.openjdk.java.net/~amjiang/8075618/webrev.03/ (It looks like "cr.openjdk.java.net" is down, I also attach the webrev with this email). In the new webrev, I fixed some syntax issue mentioned by Paul and also simplied the test codes with Artem and Max's suggestions. Unfortunately I cannot fully apply some functions from http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java . Those functions returns deprecated "OutputAnalyzer " class in http://hg.openjdk.java.net/jdk9/dev/jdk/file/ab164f8b8569/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java , which conflicts with the "OubputAnalyzer" class I imported for my test ( http://hg.openjdk.java.net/jdk9/dev/file/5e79c9bac1b5/test/lib/jdk/test/lib/process/OutputAnalyzer.java) Max, I also add one test case for permission granted to signed multi-release jar files, other functional tests are covered by http://hg.openjdk.java.net/jdk9/dev/jdk/file/ab164f8b8569/test/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java Thanks Amanda On 12/12/16 6:31 PM, Wang Weijun wrote: > Hi Amanda > > Can you also test the new JarSigner API? > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd > > line 2.72 has an example on it. > >> On Dec 13, 2016, at 9:22 AM, Artem Smotrakov wrote: >> >> You can use http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java which would simplify the code. This lib was added to be used in such tests. > Correct. I also wonder if there are existing methods on javac compilation. > > Do we have existing tests on checking if a signed multi-version jar works as expected? Say, permission granted, getCertificates() returning non-null, etc? > > Thanks > Max > -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip Type: application/zip Size: 60311 bytes Desc: not available URL: From weijun.wang at oracle.com Sun Dec 18 23:55:36 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 19 Dec 2016 07:55:36 +0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: <6ddf6f80-edf6-367c-b3aa-cdf2ecfa314c@oracle.com> References: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> <6ddf6f80-edf6-367c-b3aa-cdf2ecfa314c@oracle.com> Message-ID: <4B9405D2-C45D-404B-8CD1-736874200AA8@oracle.com> > On Dec 19, 2016, at 5:38 AM, Amanda Jiang wrote: > > Hi Paul, Artem and Max, > > Thanks for your comments. Please check the new webrev at: http://cr.openjdk.java.net/~amjiang/8075618/webrev.03/ (It looks like "cr.openjdk.java.net" is down, I also attach the webrev with this email). > > In the new webrev, I fixed some syntax issue mentioned by Paul and also simplied the test codes with Artem and Max's suggestions. Unfortunately I cannot fully apply some functions from http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java . Those functions returns deprecated "OutputAnalyzer " class in http://hg.openjdk.java.net/jdk9/dev/jdk/file/ab164f8b8569/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java , which conflicts with the "OubputAnalyzer" class I imported for my test ( http://hg.openjdk.java.net/jdk9/dev/file/5e79c9bac1b5/test/lib/jdk/test/lib/process/OutputAnalyzer.java) This is a pity. We should move it to the root repo before more people start using it. > > Max, > > I also add one test case for permission granted to signed multi-release jar files, Maybe it's better to move the checkPermission() calls into v9/version/Version.java? This would demonstrate that the versioned class itself is granted permissions. In order to make sure it's not another version of Version.java that is running, I think you can call assertContains("I am running on version 10"). And if you don't intend to reuse Main.java, I think it's not worth passing into arguments. Thanks Max > other functional tests are covered by http://hg.openjdk.java.net/jdk9/dev/jdk/file/ab164f8b8569/test/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java > > Thanks > Amanda > On 12/12/16 6:31 PM, Wang Weijun wrote: >> Hi Amanda >> >> Can you also test the new JarSigner API? >> >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd >> >> line 2.72 has an example on it. >> >>> On Dec 13, 2016, at 9:22 AM, Artem Smotrakov wrote: >>> >>> You can use http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java which would simplify the code. This lib was added to be used in such tests. >> Correct. I also wonder if there are existing methods on javac compilation. >> >> Do we have existing tests on checking if a signed multi-version jar works as expected? Say, permission granted, getCertificates() returning non-null, etc? >> >> Thanks >> Max >> > > From amanda.jiang at oracle.com Mon Dec 19 05:51:59 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Sun, 18 Dec 2016 21:51:59 -0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: <4B9405D2-C45D-404B-8CD1-736874200AA8@oracle.com> References: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> <6ddf6f80-edf6-367c-b3aa-cdf2ecfa314c@oracle.com> <4B9405D2-C45D-404B-8CD1-736874200AA8@oracle.com> Message-ID: <7c0cf594-ccac-ecee-a244-fc51bfcff48e@oracle.com> Hi Max, Please see updated webrev : http://cr.openjdk.java.net/~amjiang/8075618/webrev.04/ (also attached) On 12/18/16 3:55 PM, Wang Weijun wrote: >> On Dec 19, 2016, at 5:38 AM, Amanda Jiang wrote: >> >> Hi Paul, Artem and Max, >> >> Thanks for your comments. Please check the new webrev at: http://cr.openjdk.java.net/~amjiang/8075618/webrev.03/ (It looks like "cr.openjdk.java.net" is down, I also attach the webrev with this email). >> >> In the new webrev, I fixed some syntax issue mentioned by Paul and also simplied the test codes with Artem and Max's suggestions. Unfortunately I cannot fully apply some functions from http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java . Those functions returns deprecated "OutputAnalyzer " class in http://hg.openjdk.java.net/jdk9/dev/jdk/file/ab164f8b8569/test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java , which conflicts with the "OubputAnalyzer" class I imported for my test ( http://hg.openjdk.java.net/jdk9/dev/file/5e79c9bac1b5/test/lib/jdk/test/lib/process/OutputAnalyzer.java) > This is a pity. We should move it to the root repo before more people start using it. Yes we should update SecurityTools.java and move it to root repo, I created an enhancement issue https://bugs.openjdk.java.net/browse/JDK-8171423 , Feel free to edit it or leave comments. >> Max, >> >> I also add one test case for permission granted to signed multi-release jar files, > Maybe it's better to move the checkPermission() calls into v9/version/Version.java? This would demonstrate that the versioned class itself is granted permissions. > > In order to make sure it's not another version of Version.java that is running, I think you can call assertContains("I am running on version 10"). > > And if you don't intend to reuse Main.java, I think it's not worth passing into arguments. I moved the checkPermission() calls into v9/bersion/Version.java, but I did not check if the output contains "I'm running on version 9", I think it does not make sense to make test fail with later or earlier version of Java (10 or 8). > > > Thanks > Max > >> other functional tests are covered by http://hg.openjdk.java.net/jdk9/dev/jdk/file/ab164f8b8569/test/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java >> >> Thanks >> Amanda >> On 12/12/16 6:31 PM, Wang Weijun wrote: >>> Hi Amanda >>> >>> Can you also test the new JarSigner API? >>> >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd >>> >>> line 2.72 has an example on it. >>> >>>> On Dec 13, 2016, at 9:22 AM, Artem Smotrakov wrote: >>>> >>>> You can use http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java which would simplify the code. This lib was added to be used in such tests. >>> Correct. I also wonder if there are existing methods on javac compilation. >>> >>> Do we have existing tests on checking if a signed multi-version jar works as expected? Say, permission granted, getCertificates() returning non-null, etc? >>> >>> Thanks >>> Max >>> >> Thanks, Amanda -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip Type: application/zip Size: 55126 bytes Desc: not available URL: From weijun.wang at oracle.com Mon Dec 19 06:23:00 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 19 Dec 2016 14:23:00 +0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: <7c0cf594-ccac-ecee-a244-fc51bfcff48e@oracle.com> References: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> <6ddf6f80-edf6-367c-b3aa-cdf2ecfa314c@oracle.com> <4B9405D2-C45D-404B-8CD1-736874200AA8@oracle.com> <7c0cf594-ccac-ecee-a244-fc51bfcff48e@oracle.com> Message-ID: <4CDCF443-1CCC-4BB7-A35B-B95FAD46AFFD@oracle.com> > Please see updated webrev : http://cr.openjdk.java.net/~amjiang/8075618/webrev.04/ (also attached) > > I moved the checkPermission() calls into v9/bersion/Version.java, but I did not check if the output contains "I'm running on version 9", I think it does not make sense to make test fail with later or earlier version of Java (10 or 8). This test will run in JDK 10 and your checkPermission(perm,bool) method will not get called. Suppose a regression is introduced one day that breaks the access control checking, this test will not be able to catch it. If you check for the "version 9" string, the test will fail which reminds you to move the checkPermission call to Version.java of JDK 10 and it will catch that regression. Thanks Max From amanda.jiang at oracle.com Mon Dec 19 06:43:36 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Sun, 18 Dec 2016 22:43:36 -0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: <4CDCF443-1CCC-4BB7-A35B-B95FAD46AFFD@oracle.com> References: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> <6ddf6f80-edf6-367c-b3aa-cdf2ecfa314c@oracle.com> <4B9405D2-C45D-404B-8CD1-736874200AA8@oracle.com> <7c0cf594-ccac-ecee-a244-fc51bfcff48e@oracle.com> <4CDCF443-1CCC-4BB7-A35B-B95FAD46AFFD@oracle.com> Message-ID: <05e08267-c33a-c7c8-28c7-9aa7f56a3684@oracle.com> On 12/18/16 10:23 PM, Wang Weijun wrote: >> Please see updated webrev : http://cr.openjdk.java.net/~amjiang/8075618/webrev.04/ (also attached) >> >> I moved the checkPermission() calls into v9/bersion/Version.java, but I did not check if the output contains "I'm running on version 9", I think it does not make sense to make test fail with later or earlier version of Java (10 or 8). > This test will run in JDK 10 and your checkPermission(perm,bool) method will not get called. Suppose a regression is introduced one day that breaks the access control checking, this test will not be able to catch it. > > If you check for the "version 9" string, the test will fail which reminds you to move the checkPermission call to Version.java of JDK 10 and it will catch that regression. > > Thanks > Max Version check added to the test :http://cr.openjdk.java.net/~amjiang/8075618/webrev.05 Thanks, Amanda -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip Type: application/zip Size: 55280 bytes Desc: not available URL: From weijun.wang at oracle.com Mon Dec 19 07:11:58 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 19 Dec 2016 15:11:58 +0800 Subject: RFR 8075618: Create tests to check jarsigner work with multi-version jar In-Reply-To: <05e08267-c33a-c7c8-28c7-9aa7f56a3684@oracle.com> References: <44694335-0efa-e32f-c05c-426d57ddf5dc@oracle.com> <6ddf6f80-edf6-367c-b3aa-cdf2ecfa314c@oracle.com> <4B9405D2-C45D-404B-8CD1-736874200AA8@oracle.com> <7c0cf594-ccac-ecee-a244-fc51bfcff48e@oracle.com> <4CDCF443-1CCC-4BB7-A35B-B95FAD46AFFD@oracle.com> <05e08267-c33a-c7c8-28c7-9aa7f56a3684@oracle.com> Message-ID: <66695BAE-4833-465A-9F26-CF7A54B3A38C@oracle.com> Hi Amanda Everything is fine. I have no other comment. Thanks Max > On Dec 19, 2016, at 2:43 PM, Amanda Jiang wrote: > > > > On 12/18/16 10:23 PM, Wang Weijun wrote: >>> Please see updated webrev : http://cr.openjdk.java.net/~amjiang/8075618/webrev.04/ (also attached) >>> >>> I moved the checkPermission() calls into v9/bersion/Version.java, but I did not check if the output contains "I'm running on version 9", I think it does not make sense to make test fail with later or earlier version of Java (10 or 8). >> This test will run in JDK 10 and your checkPermission(perm,bool) method will not get called. Suppose a regression is introduced one day that breaks the access control checking, this test will not be able to catch it. >> >> If you check for the "version 9" string, the test will fail which reminds you to move the checkPermission call to Version.java of JDK 10 and it will catch that regression. >> >> Thanks >> Max > Version check added to the test :http://cr.openjdk.java.net/~amjiang/8075618/webrev.05 > Thanks, > Amanda > From bradford.wetmore at oracle.com Mon Dec 19 20:20:44 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 19 Dec 2016 12:20:44 -0800 Subject: Code Review Request, JDK-8171337 Check for correct SSLEngineImpl/SSLSocketImpl.setSSLParameters handshaker update method In-Reply-To: <5f70dd69-e177-1118-005c-bcf4987b23fb@oracle.com> References: <5f70dd69-e177-1118-005c-bcf4987b23fb@oracle.com> Message-ID: <1df5a5a9-2a65-82c7-dbb6-c58570f65fc5@oracle.com> For SSLSocket, there are other .started() methods with similar conditions, should those be changed as well? Thanks, Brad On 12/16/2016 11:03 AM, Xuelei Fan wrote: > Hi Brad, > > Please review this handshake update method miss-use fix: > > http://cr.openjdk.java.net/~xuelei/8171337/webrev.00/ > > The activation process of handshake may consider the parameters in a big > picture and make adjustment accordingly. Basically, SSL parameters > should be configured before the handshake activated. > > Thanks, > Xuelei From sean.mullan at oracle.com Mon Dec 19 20:35:32 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Dec 2016 15:35:32 -0500 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: References: Message-ID: Here are more comments on TrustStoreManager: 87-93: these variables can be declared private 120 new PrivilegedAction() { use <> operator 152 // Not break, so the file is accessbile. s/accessbile/inaccessible/ 156 "Not accessible trust store: " + s/Not accessible/Inaccessible/ We probably should avoid dumping the filename since the pathname may contain sensitive info and can end up in logs. I would probably print the property name instead as it still contains enough info to debug the problem. Same comment on lines 163-4. 159 } catch (Exception exp) { Why is this needed? This is done inside a doPriv, so no SecurityExc should be thrown. 198 public int hashCode() { Seems like you might want to compute the hashcode once and store it. 213 if (storePassword != null && !storePassword.isEmpty()) { 214 MessageDigest md = JsseJce.getMessageDigest("SHA-256"); 215 result = 31 * result + 216 Arrays.hashCode(md.digest(storePassword.getBytes())); 217 } Why are you hashing the password here? Are you afraid this could be leaked or guessed somehow? I would just leave the password out of the hashcode and equals. It doesn't matter, it's still the same file, right? I'm not sure if the type or provider matter either. Don't you just care about the name of the file and the modification time? 268 if ((temporaryDesc != null) && Why would a null descriptor ever be ok? Shouldn't you just let this throw NPE? Same comment on line 301. That's all my comments for now. I'll wait until you post another update to finish my review. --Sean On 12/16/16 11:14 AM, Sean Mullan wrote: > Hi Xuelei, > > First cut of a review at this. I still need to review TrustStoreManager, > so will get back to you later on that. Looks very good so far. > > * KeyStores.java > > Do an 'hg rename' on this file, so you can see the diffs between this > and the new name (TrustStoreUtil), and you preserve the history. > > * TrustStoreUtil.java > > 54 Set set = new HashSet(); > > Use <> operator. > > 71 } catch (KeyStoreException e) { > 72 // ignore > 73 } > > This should be rare, but maybe we want to log this. > > * TrustStoreManager.java > > 65 public static KeyStore getgetTrustedKeyStore() throws Exception { > > s/getget/get/ > > * TrustManagerFactoryImpl.java > > 85 abstract X509TrustManager getInstance( > 86 Collection trustedCerts) throws > KeyStoreException; > > It no longer makes sense for this method to throw KeyStoreException. > > * X509TrustManagerImpl.java > > 71 X509TrustManagerImpl(String validatorType, > 72 Collection trustedCerts) throws > KeyStoreException { > > No longer can throw KeyStoreException so it can be removed from throws > clause. > > 83 if (debug != null && Debug.isOn("trustmanager")) { > 84 showTrustedCerts(); > > Not sure why you made this change (and on line 99) because > showTrustedCerts is still only called if debug is enabled. > > --Sean > > On 11/26/16 7:46 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the performance enhancement update: >> >> http://cr.openjdk.java.net/~xuelei/8129988/webrev.00/ >> >> In SunJSSE provider, there are two ways to use the default trust store >> (lib/security/cacerts), using the default SSLContext instance or using >> the default trust manager. >> >> The default SSLContext holds a strong reference to a collection of >> trusted certificates in cacerts in static mode. The default trust >> manager reads the cacerts file and creates a KeyStore and parses the >> certificates each time. >> >> With the growth of cacerts, the loading and cache of trusted certificate >> is not performance friendly. >> >> In this fix, I'm trying to find a balance between CPU and memory: reuse >> the loaded trusted certificates if possible and release the unused >> trusted certificates if necessary. >> >> Thanks, >> Xuelei >> From xuelei.fan at oracle.com Tue Dec 20 00:39:43 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 19 Dec 2016 16:39:43 -0800 Subject: Code Review Request, JDK-8171337 Check for correct SSLEngineImpl/SSLSocketImpl.setSSLParameters handshaker update method In-Reply-To: <1df5a5a9-2a65-82c7-dbb6-c58570f65fc5@oracle.com> References: <5f70dd69-e177-1118-005c-bcf4987b23fb@oracle.com> <1df5a5a9-2a65-82c7-dbb6-c58570f65fc5@oracle.com> Message-ID: On 12/19/2016 12:20 PM, Bradford Wetmore wrote: > For SSLSocket, there are other .started() methods with similar > conditions, should those be changed as well? > The one in SSLSocketImpl is used to get the handshake application protocol (getHandshakeApplicationProtocol, line 2661-2664), better to use started() for the accuracy value for "handshake". Thanks, Xuelei > Thanks, > > Brad > > > On 12/16/2016 11:03 AM, Xuelei Fan wrote: >> Hi Brad, >> >> Please review this handshake update method miss-use fix: >> >> http://cr.openjdk.java.net/~xuelei/8171337/webrev.00/ >> >> The activation process of handshake may consider the parameters in a big >> picture and make adjustment accordingly. Basically, SSL parameters >> should be configured before the handshake activated. >> >> Thanks, >> Xuelei From weijun.wang at oracle.com Tue Dec 20 07:25:18 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 20 Dec 2016 15:25:18 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> Message-ID: <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> Ping again. > On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: > > An clarification is added to FilePermission::implies: > > * @implNote > .... > * a simple {@code npath} is recursively inside a wildcard {@code npath} > * if and only if {@code simple_npath.relativize(wildcard_npath)} > - * is a series of one or more "..". An invalid {@code FilePermission} does > + * is a series of one or more "..". Note that this means "/-" does not > + * imply "foo". An invalid {@code FilePermission} does > * not imply any object except for itself. > > The newly added sentence is > > Note that this means "/-" does not imply "foo". > > JCK has agreed to update their test. > > Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. > > Thanks > Max > From sha.jiang at oracle.com Tue Dec 20 14:11:44 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 20 Dec 2016 22:11:44 +0800 Subject: RFR[9] JDK-8168935: sun/security/ssl/SSLContextImpl/TrustTrustedCert.java failed Intermittently Message-ID: Hi, In test sun/security/ssl/SSLContextImpl/TrustTrustedCert.java, the server may wait for the client for a long time, then the test execution goes to timeout. This patch takes advantage of javax/net/ssl/templates/SSLSocketTemplate.java to fix this issue. Please note that: 1. SSLSocketTemplate.java is modified a bit to aid this fix. 2. Compare with the previous version of TrustTrustedCert.java, the server side should handle SSLSocketException if the certificates do not conform to algorithm constraints. That's similar to the scenario on the client side. Webrev: http://cr.openjdk.java.net/~jjiang/8168935/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8168935 Best regards, John Jiang From xuelei.fan at oracle.com Tue Dec 20 17:18:53 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 20 Dec 2016 09:18:53 -0800 Subject: RFR[9] JDK-8168935: sun/security/ssl/SSLContextImpl/TrustTrustedCert.java failed Intermittently In-Reply-To: References: Message-ID: <63cc6a77-b75f-99fc-9446-871c10c8b986@oracle.com> Hi John, I was wondering to add three methods in the template: . configureClientSocket(SSLSocket socket) . configureServerSocket(SSLSocket socket) . configureServerSocket(SSLServerSocket socket) However, there was no use of any of them of my previous update, so we did not add them. Your adding of createSSLServerSocket() looks fine. except that it is not straightfoard that the caller (TrustTrustedCert.java) is calling super.createSSLServerSocket(). Would you mind add and update to use configureServerSocket(SSLServerSocket)? Otherwise, looks fine to me. Thanks, Xuelei On 12/20/2016 6:11 AM, John Jiang wrote: > Hi, > In test sun/security/ssl/SSLContextImpl/TrustTrustedCert.java, the > server may wait for the client for a long time, then the test execution > goes to timeout. > This patch takes advantage of > javax/net/ssl/templates/SSLSocketTemplate.java to fix this issue. > > Please note that: > 1. SSLSocketTemplate.java is modified a bit to aid this fix. > 2. Compare with the previous version of TrustTrustedCert.java, the > server side should handle SSLSocketException if the certificates do not > conform to algorithm constraints. That's similar to the scenario on the > client side. > > Webrev: http://cr.openjdk.java.net/~jjiang/8168935/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8168935 > > Best regards, > John Jiang > From xuelei.fan at oracle.com Tue Dec 20 20:21:54 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 20 Dec 2016 12:21:54 -0800 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: References: Message-ID: New: http://cr.openjdk.java.net/~xuelei/8129988/webrev.01/ On 12/19/2016 12:35 PM, Sean Mullan wrote: > Here are more comments on TrustStoreManager: > > 87-93: these variables can be declared private > > 120 new PrivilegedAction() { > > use <> operator > Updated. > 152 // Not break, so the file is > accessbile. > > s/accessbile/inaccessible/ > > 156 "Not accessible trust > store: " + > > s/Not accessible/Inaccessible/ > updated. > We probably should avoid dumping the filename since the pathname may > contain sensitive info and can end up in logs. I would probably print > the property name instead as it still contains enough info to debug the > problem. Same comment on lines 163-4. > Good point. Updated to use property name. > 159 } catch (Exception exp) { > > Why is this needed? This is done inside a doPriv, so no SecurityExc > should be thrown. > Right, this block is useless. Removed. > 198 public int hashCode() { > > Seems like you might want to compute the hashcode once and store it. > The hashCode() method is not actually used in the context. The code is Saving a cache needs additional space and synchronization. We can make the improvement later if the method is used. > 213 if (storePassword != null && !storePassword.isEmpty()) { > 214 MessageDigest md = > JsseJce.getMessageDigest("SHA-256"); > 215 result = 31 * result + > 216 Arrays.hashCode(md.digest(storePassword.getBytes())); > 217 } > > Why are you hashing the password here? Are you afraid this could be > leaked or guessed somehow? Yes. The hash code of the password part can be computed. I was wondering the String.hashCode() may not have sufficient strength. > I would just leave the password out of the > hashcode and equals. It doesn't matter, it's still the same file, right? > I'm not sure if the type or provider matter either. Don't you just care > about the name of the file and the modification time? > For file type key store, the file and the modification time should be sufficient. But for non-file (PKCS11) key store, the provider and password may be sensible. The basic idea is that, if one of the system property get updated, the key store should be reloaded. Checking every property update makes the code more straightforward. > 268 if ((temporaryDesc != null) && > > Why would a null descriptor ever be ok? Shouldn't you just let this > throw NPE? Same comment on line 301. > The temporaryDesc is initialized as null. A singleton service (TrustStoreManage.tam) is used and lazy loaded. Null means the descriptor has not been assigned. > That's all my comments for now. I'll wait until you post another update > to finish my review. > > --Sean > > > On 12/16/16 11:14 AM, Sean Mullan wrote: >> Hi Xuelei, >> >> First cut of a review at this. I still need to review TrustStoreManager, >> so will get back to you later on that. Looks very good so far. >> >> * KeyStores.java >> >> Do an 'hg rename' on this file, so you can see the diffs between this >> and the new name (TrustStoreUtil), and you preserve the history. >> >> * TrustStoreUtil.java >> 'hg rename' is used. Looks like webrev cannot identify rename of files. >> 54 Set set = new HashSet(); >> >> Use <> operator. >> Updated. >> 71 } catch (KeyStoreException e) { >> 72 // ignore >> 73 } >> >> This should be rare, but maybe we want to log this. >> Not sure log it in JSSE or PKIC. I added a comment, may add the debug log in the future. >> * TrustStoreManager.java >> >> 65 public static KeyStore getgetTrustedKeyStore() throws >> Exception { >> >> s/getget/get/ >> Ooops. Updated. >> * TrustManagerFactoryImpl.java >> >> 85 abstract X509TrustManager getInstance( >> 86 Collection trustedCerts) throws >> KeyStoreException; >> >> It no longer makes sense for this method to throw KeyStoreException. >> good point! Updated. >> * X509TrustManagerImpl.java >> >> 71 X509TrustManagerImpl(String validatorType, >> 72 Collection trustedCerts) throws >> KeyStoreException { >> >> No longer can throw KeyStoreException so it can be removed from throws >> clause. >> Updated. >> 83 if (debug != null && Debug.isOn("trustmanager")) { >> 84 showTrustedCerts(); >> >> Not sure why you made this change (and on line 99) because >> showTrustedCerts is still only called if debug is enabled. >> When I read the code, I'm not sure what's the purpose of showTrustedCerts() until I rollover to showTrustedCerts implementation. I was wondering, this update may make the code easier to read. Thanks, Xuelei >> --Sean >> >> On 11/26/16 7:46 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the performance enhancement update: >>> >>> http://cr.openjdk.java.net/~xuelei/8129988/webrev.00/ >>> >>> In SunJSSE provider, there are two ways to use the default trust store >>> (lib/security/cacerts), using the default SSLContext instance or using >>> the default trust manager. >>> >>> The default SSLContext holds a strong reference to a collection of >>> trusted certificates in cacerts in static mode. The default trust >>> manager reads the cacerts file and creates a KeyStore and parses the >>> certificates each time. >>> >>> With the growth of cacerts, the loading and cache of trusted certificate >>> is not performance friendly. >>> >>> In this fix, I'm trying to find a balance between CPU and memory: reuse >>> the loaded trusted certificates if possible and release the unused >>> trusted certificates if necessary. >>> >>> Thanks, >>> Xuelei >>> From sean.mullan at oracle.com Tue Dec 20 21:02:17 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 20 Dec 2016 16:02:17 -0500 Subject: [PATCH] 8170876: NPE in Cipher with java.security.debug=provider In-Reply-To: <65ba1668-3e80-16e6-a080-12f9b6a7ccf1@oracle.com> References: <65ba1668-3e80-16e6-a080-12f9b6a7ccf1@oracle.com> Message-ID: <6611e40b-7484-627b-684e-36be244774fd@oracle.com> I think you missed java.security.KeyPairGenerator which has the same issue. Otherwise looks good. --Sean On 12/15/16 3:08 PM, Adam Petcher wrote: > I'm continuing my quest to rid engine classes of NullPointerException > due to calling getName() on a null provider. This patch fixes Cipher > (which fails in a test using NullCipher) and all other engine classes > that have this pattern. I found them by searching the codebase for > references to Provider::getName. This fix does not address NPEs caused > by calls to other methods of Provider, or calls that occur outside the > engine classes (e.g. someEngine.getProvider().getName()). > > I augmented an existing test so it will check for the NPE in Cipher. The > diff also containsa fix for a small typo in the NullProvider test for > Signature. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170876 > > Diff: > > diff --git a/src/java.base/share/classes/java/security/KeyStore.java > b/src/java.base/share/classes/java/security/KeyStore.java > --- a/src/java.base/share/classes/java/security/KeyStore.java > +++ b/src/java.base/share/classes/java/security/KeyStore.java > @@ -824,10 +824,14 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("KeyStore." + type.toUpperCase() + " type > from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > /** > * Returns a keystore object of the specified type. > * > diff --git > a/src/java.base/share/classes/java/security/MessageDigest.java > b/src/java.base/share/classes/java/security/MessageDigest.java > --- a/src/java.base/share/classes/java/security/MessageDigest.java > +++ b/src/java.base/share/classes/java/security/MessageDigest.java > @@ -430,13 +430,17 @@ > return digest(); > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > /** > * Returns a string representation of this message digest object. > */ > public String toString() { > ByteArrayOutputStream baos = new ByteArrayOutputStream(); > PrintStream p = new PrintStream(baos); > - p.print(algorithm+" Message Digest from "+provider.getName()+", > "); > + p.print(algorithm+" Message Digest from "+getProviderName()+", "); > switch (state) { > case INITIAL: > p.print(""); > diff --git a/src/java.base/share/classes/java/security/SecureRandom.java > b/src/java.base/share/classes/java/security/SecureRandom.java > --- a/src/java.base/share/classes/java/security/SecureRandom.java > +++ b/src/java.base/share/classes/java/security/SecureRandom.java > @@ -310,10 +310,14 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("SecureRandom." + algorithm + > - " algorithm from: " + this.provider.getName()); > + " algorithm from: " + getProviderName()); > } > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > /** > * Returns a {@code SecureRandom} object that implements the specified > * Random Number Generator (RNG) algorithm. > diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java > b/src/java.base/share/classes/javax/crypto/Cipher.java > --- a/src/java.base/share/classes/javax/crypto/Cipher.java > +++ b/src/java.base/share/classes/javax/crypto/Cipher.java > @@ -611,6 +611,10 @@ > return getInstance(transformation, p); > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > /** > * Returns a {@code Cipher} object that implements the specified > * transformation. > @@ -1278,7 +1282,7 @@ > if (!skipDebug && pdebug != null) { > pdebug.println("Cipher." + transformation + " " + > getOpmodeString(opmode) + " algorithm from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > @@ -1421,7 +1425,7 @@ > if (!skipDebug && pdebug != null) { > pdebug.println("Cipher." + transformation + " " + > getOpmodeString(opmode) + " algorithm from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > @@ -1564,7 +1568,7 @@ > if (!skipDebug && pdebug != null) { > pdebug.println("Cipher." + transformation + " " + > getOpmodeString(opmode) + " algorithm from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > @@ -1754,7 +1758,7 @@ > if (!skipDebug && pdebug != null) { > pdebug.println("Cipher." + transformation + " " + > getOpmodeString(opmode) + " algorithm from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > diff --git a/src/java.base/share/classes/javax/crypto/KeyAgreement.java > b/src/java.base/share/classes/javax/crypto/KeyAgreement.java > --- a/src/java.base/share/classes/javax/crypto/KeyAgreement.java > +++ b/src/java.base/share/classes/javax/crypto/KeyAgreement.java > @@ -484,7 +484,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("KeyAgreement." + algorithm + " algorithm > from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > @@ -517,6 +517,10 @@ > init(key, params, JceSecurity.RANDOM); > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > /** > * Initializes this key agreement with the given key, set of > * algorithm parameters, and source of randomness. > @@ -545,7 +549,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("KeyAgreement." + algorithm + " algorithm > from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > diff --git a/src/java.base/share/classes/javax/crypto/KeyGenerator.java > b/src/java.base/share/classes/javax/crypto/KeyGenerator.java > --- a/src/java.base/share/classes/javax/crypto/KeyGenerator.java > +++ b/src/java.base/share/classes/javax/crypto/KeyGenerator.java > @@ -154,7 +154,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("KeyGenerator." + algorithm + " algorithm > from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > @@ -172,10 +172,14 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("KeyGenerator." + algorithm + " algorithm > from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > /** > * Returns the algorithm name of this {@code KeyGenerator} object. > * > diff --git a/src/java.base/share/classes/javax/crypto/Mac.java > b/src/java.base/share/classes/javax/crypto/Mac.java > --- a/src/java.base/share/classes/javax/crypto/Mac.java > +++ b/src/java.base/share/classes/javax/crypto/Mac.java > @@ -415,6 +415,10 @@ > return spi.engineGetMacLength(); > } > > + private String getProviderName() { > + return (provider == null) ? "(no provider)" : provider.getName(); > + } > + > /** > * Initializes this {@code Mac} object with the given key. > * > @@ -437,7 +441,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Mac." + algorithm + " algorithm from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > @@ -464,7 +468,7 @@ > > if (!skipDebug && pdebug != null) { > pdebug.println("Mac." + algorithm + " algorithm from: " + > - this.provider.getName()); > + getProviderName()); > } > } > > diff --git a/test/java/security/Signature/NoProvider.java > b/test/java/security/Signature/NoProvider.java > --- a/test/java/security/Signature/NoProvider.java > +++ b/test/java/security/Signature/NoProvider.java > @@ -25,7 +25,7 @@ > * @test > * @bug 8165751 > * @summary Verify that that a subclass of Signature that does not > contain a > - * provider can be used verify. > + * provider can be used to verify. > * @run main/othervm -Djava.security.debug=provider NoProvider > */ > > diff --git a/test/javax/crypto/NullCipher/TestNPE.java > b/test/javax/crypto/NullCipher/TestNPE.java > --- a/test/javax/crypto/NullCipher/TestNPE.java > +++ b/test/javax/crypto/NullCipher/TestNPE.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -23,10 +23,12 @@ > > /* > * @test > - * @bug 4937853 > + * @bug 4937853 8170876 > * @summary Make sure normal calls of NullCipher does not throw NPE. > * @author Valerie Peng > * @key randomness > + * @run main TestNPE > + * @run main/othervm -Djava.security.debug=provider TestNPE > */ > import java.util.Arrays; > import java.security.AlgorithmParameters; > From adam.petcher at oracle.com Tue Dec 20 21:31:29 2016 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 20 Dec 2016 16:31:29 -0500 Subject: [PATCH] 8170876: NPE in Cipher with java.security.debug=provider In-Reply-To: <6611e40b-7484-627b-684e-36be244774fd@oracle.com> References: <65ba1668-3e80-16e6-a080-12f9b6a7ccf1@oracle.com> <6611e40b-7484-627b-684e-36be244774fd@oracle.com> Message-ID: KeyPairGenerator didn't require any changes because that class does not reference its provider member. KeyPairGenerator.Delegate has similar code that prints the name of its provider, but this is not an instance of the pattern that I was addressing, and I don't have any reason to believe there is anything wrong with it. Though maybe I missed something here. If you still think this class needs a modification, please point me to a line number that has this issue. On 12/20/2016 4:02 PM, Sean Mullan wrote: > I think you missed java.security.KeyPairGenerator which has the same > issue. Otherwise looks good. > > --Sean > > On 12/15/16 3:08 PM, Adam Petcher wrote: >> I'm continuing my quest to rid engine classes of NullPointerException >> due to calling getName() on a null provider. This patch fixes Cipher >> (which fails in a test using NullCipher) and all other engine classes >> that have this pattern. I found them by searching the codebase for >> references to Provider::getName. This fix does not address NPEs caused >> by calls to other methods of Provider, or calls that occur outside the >> engine classes (e.g. someEngine.getProvider().getName()). >> >> I augmented an existing test so it will check for the NPE in Cipher. The >> diff also containsa fix for a small typo in the NullProvider test for >> Signature. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170876 >> >> Diff: >> >> diff --git a/src/java.base/share/classes/java/security/KeyStore.java >> b/src/java.base/share/classes/java/security/KeyStore.java >> --- a/src/java.base/share/classes/java/security/KeyStore.java >> +++ b/src/java.base/share/classes/java/security/KeyStore.java >> @@ -824,10 +824,14 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("KeyStore." + type.toUpperCase() + " type >> from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> + private String getProviderName() { >> + return (provider == null) ? "(no provider)" : >> provider.getName(); >> + } >> + >> /** >> * Returns a keystore object of the specified type. >> * >> diff --git >> a/src/java.base/share/classes/java/security/MessageDigest.java >> b/src/java.base/share/classes/java/security/MessageDigest.java >> --- a/src/java.base/share/classes/java/security/MessageDigest.java >> +++ b/src/java.base/share/classes/java/security/MessageDigest.java >> @@ -430,13 +430,17 @@ >> return digest(); >> } >> >> + private String getProviderName() { >> + return (provider == null) ? "(no provider)" : >> provider.getName(); >> + } >> + >> /** >> * Returns a string representation of this message digest object. >> */ >> public String toString() { >> ByteArrayOutputStream baos = new ByteArrayOutputStream(); >> PrintStream p = new PrintStream(baos); >> - p.print(algorithm+" Message Digest from "+provider.getName()+", >> "); >> + p.print(algorithm+" Message Digest from >> "+getProviderName()+", "); >> switch (state) { >> case INITIAL: >> p.print(""); >> diff --git a/src/java.base/share/classes/java/security/SecureRandom.java >> b/src/java.base/share/classes/java/security/SecureRandom.java >> --- a/src/java.base/share/classes/java/security/SecureRandom.java >> +++ b/src/java.base/share/classes/java/security/SecureRandom.java >> @@ -310,10 +310,14 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("SecureRandom." + algorithm + >> - " algorithm from: " + this.provider.getName()); >> + " algorithm from: " + getProviderName()); >> } >> } >> >> + private String getProviderName() { >> + return (provider == null) ? "(no provider)" : >> provider.getName(); >> + } >> + >> /** >> * Returns a {@code SecureRandom} object that implements the >> specified >> * Random Number Generator (RNG) algorithm. >> diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java >> b/src/java.base/share/classes/javax/crypto/Cipher.java >> --- a/src/java.base/share/classes/javax/crypto/Cipher.java >> +++ b/src/java.base/share/classes/javax/crypto/Cipher.java >> @@ -611,6 +611,10 @@ >> return getInstance(transformation, p); >> } >> >> + private String getProviderName() { >> + return (provider == null) ? "(no provider)" : >> provider.getName(); >> + } >> + >> /** >> * Returns a {@code Cipher} object that implements the specified >> * transformation. >> @@ -1278,7 +1282,7 @@ >> if (!skipDebug && pdebug != null) { >> pdebug.println("Cipher." + transformation + " " + >> getOpmodeString(opmode) + " algorithm from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> @@ -1421,7 +1425,7 @@ >> if (!skipDebug && pdebug != null) { >> pdebug.println("Cipher." + transformation + " " + >> getOpmodeString(opmode) + " algorithm from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> @@ -1564,7 +1568,7 @@ >> if (!skipDebug && pdebug != null) { >> pdebug.println("Cipher." + transformation + " " + >> getOpmodeString(opmode) + " algorithm from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> @@ -1754,7 +1758,7 @@ >> if (!skipDebug && pdebug != null) { >> pdebug.println("Cipher." + transformation + " " + >> getOpmodeString(opmode) + " algorithm from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> diff --git a/src/java.base/share/classes/javax/crypto/KeyAgreement.java >> b/src/java.base/share/classes/javax/crypto/KeyAgreement.java >> --- a/src/java.base/share/classes/javax/crypto/KeyAgreement.java >> +++ b/src/java.base/share/classes/javax/crypto/KeyAgreement.java >> @@ -484,7 +484,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("KeyAgreement." + algorithm + " algorithm >> from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> @@ -517,6 +517,10 @@ >> init(key, params, JceSecurity.RANDOM); >> } >> >> + private String getProviderName() { >> + return (provider == null) ? "(no provider)" : >> provider.getName(); >> + } >> + >> /** >> * Initializes this key agreement with the given key, set of >> * algorithm parameters, and source of randomness. >> @@ -545,7 +549,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("KeyAgreement." + algorithm + " algorithm >> from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> diff --git a/src/java.base/share/classes/javax/crypto/KeyGenerator.java >> b/src/java.base/share/classes/javax/crypto/KeyGenerator.java >> --- a/src/java.base/share/classes/javax/crypto/KeyGenerator.java >> +++ b/src/java.base/share/classes/javax/crypto/KeyGenerator.java >> @@ -154,7 +154,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("KeyGenerator." + algorithm + " algorithm >> from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> @@ -172,10 +172,14 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("KeyGenerator." + algorithm + " algorithm >> from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> + private String getProviderName() { >> + return (provider == null) ? "(no provider)" : >> provider.getName(); >> + } >> + >> /** >> * Returns the algorithm name of this {@code KeyGenerator} object. >> * >> diff --git a/src/java.base/share/classes/javax/crypto/Mac.java >> b/src/java.base/share/classes/javax/crypto/Mac.java >> --- a/src/java.base/share/classes/javax/crypto/Mac.java >> +++ b/src/java.base/share/classes/javax/crypto/Mac.java >> @@ -415,6 +415,10 @@ >> return spi.engineGetMacLength(); >> } >> >> + private String getProviderName() { >> + return (provider == null) ? "(no provider)" : >> provider.getName(); >> + } >> + >> /** >> * Initializes this {@code Mac} object with the given key. >> * >> @@ -437,7 +441,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Mac." + algorithm + " algorithm from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> @@ -464,7 +468,7 @@ >> >> if (!skipDebug && pdebug != null) { >> pdebug.println("Mac." + algorithm + " algorithm from: " + >> - this.provider.getName()); >> + getProviderName()); >> } >> } >> >> diff --git a/test/java/security/Signature/NoProvider.java >> b/test/java/security/Signature/NoProvider.java >> --- a/test/java/security/Signature/NoProvider.java >> +++ b/test/java/security/Signature/NoProvider.java >> @@ -25,7 +25,7 @@ >> * @test >> * @bug 8165751 >> * @summary Verify that that a subclass of Signature that does not >> contain a >> - * provider can be used verify. >> + * provider can be used to verify. >> * @run main/othervm -Djava.security.debug=provider NoProvider >> */ >> >> diff --git a/test/javax/crypto/NullCipher/TestNPE.java >> b/test/javax/crypto/NullCipher/TestNPE.java >> --- a/test/javax/crypto/NullCipher/TestNPE.java >> +++ b/test/javax/crypto/NullCipher/TestNPE.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2007, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -23,10 +23,12 @@ >> >> /* >> * @test >> - * @bug 4937853 >> + * @bug 4937853 8170876 >> * @summary Make sure normal calls of NullCipher does not throw NPE. >> * @author Valerie Peng >> * @key randomness >> + * @run main TestNPE >> + * @run main/othervm -Djava.security.debug=provider TestNPE >> */ >> import java.util.Arrays; >> import java.security.AlgorithmParameters; >> From sean.mullan at oracle.com Tue Dec 20 21:50:21 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 20 Dec 2016 16:50:21 -0500 Subject: [PATCH] 8170876: NPE in Cipher with java.security.debug=provider In-Reply-To: References: <65ba1668-3e80-16e6-a080-12f9b6a7ccf1@oracle.com> <6611e40b-7484-627b-684e-36be244774fd@oracle.com> Message-ID: On 12/20/16 4:31 PM, Adam Petcher wrote: > KeyPairGenerator didn't require any changes because that class does not > reference its provider member. KeyPairGenerator.Delegate has similar > code that prints the name of its provider, but this is not an instance > of the pattern that I was addressing, and I don't have any reason to > believe there is anything wrong with it. > > Though maybe I missed something here. If you still think this class > needs a modification, please point me to a line number that has this issue. Nope, you're right - I see more of the context now and it looks fine. --Sean > > > On 12/20/2016 4:02 PM, Sean Mullan wrote: >> I think you missed java.security.KeyPairGenerator which has the same >> issue. Otherwise looks good. >> >> --Sean >> >> On 12/15/16 3:08 PM, Adam Petcher wrote: >>> I'm continuing my quest to rid engine classes of NullPointerException >>> due to calling getName() on a null provider. This patch fixes Cipher >>> (which fails in a test using NullCipher) and all other engine classes >>> that have this pattern. I found them by searching the codebase for >>> references to Provider::getName. This fix does not address NPEs caused >>> by calls to other methods of Provider, or calls that occur outside the >>> engine classes (e.g. someEngine.getProvider().getName()). >>> >>> I augmented an existing test so it will check for the NPE in Cipher. The >>> diff also containsa fix for a small typo in the NullProvider test for >>> Signature. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170876 >>> >>> Diff: >>> >>> diff --git a/src/java.base/share/classes/java/security/KeyStore.java >>> b/src/java.base/share/classes/java/security/KeyStore.java >>> --- a/src/java.base/share/classes/java/security/KeyStore.java >>> +++ b/src/java.base/share/classes/java/security/KeyStore.java >>> @@ -824,10 +824,14 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("KeyStore." + type.toUpperCase() + " type >>> from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> + private String getProviderName() { >>> + return (provider == null) ? "(no provider)" : >>> provider.getName(); >>> + } >>> + >>> /** >>> * Returns a keystore object of the specified type. >>> * >>> diff --git >>> a/src/java.base/share/classes/java/security/MessageDigest.java >>> b/src/java.base/share/classes/java/security/MessageDigest.java >>> --- a/src/java.base/share/classes/java/security/MessageDigest.java >>> +++ b/src/java.base/share/classes/java/security/MessageDigest.java >>> @@ -430,13 +430,17 @@ >>> return digest(); >>> } >>> >>> + private String getProviderName() { >>> + return (provider == null) ? "(no provider)" : >>> provider.getName(); >>> + } >>> + >>> /** >>> * Returns a string representation of this message digest object. >>> */ >>> public String toString() { >>> ByteArrayOutputStream baos = new ByteArrayOutputStream(); >>> PrintStream p = new PrintStream(baos); >>> - p.print(algorithm+" Message Digest from "+provider.getName()+", >>> "); >>> + p.print(algorithm+" Message Digest from >>> "+getProviderName()+", "); >>> switch (state) { >>> case INITIAL: >>> p.print(""); >>> diff --git a/src/java.base/share/classes/java/security/SecureRandom.java >>> b/src/java.base/share/classes/java/security/SecureRandom.java >>> --- a/src/java.base/share/classes/java/security/SecureRandom.java >>> +++ b/src/java.base/share/classes/java/security/SecureRandom.java >>> @@ -310,10 +310,14 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("SecureRandom." + algorithm + >>> - " algorithm from: " + this.provider.getName()); >>> + " algorithm from: " + getProviderName()); >>> } >>> } >>> >>> + private String getProviderName() { >>> + return (provider == null) ? "(no provider)" : >>> provider.getName(); >>> + } >>> + >>> /** >>> * Returns a {@code SecureRandom} object that implements the >>> specified >>> * Random Number Generator (RNG) algorithm. >>> diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java >>> b/src/java.base/share/classes/javax/crypto/Cipher.java >>> --- a/src/java.base/share/classes/javax/crypto/Cipher.java >>> +++ b/src/java.base/share/classes/javax/crypto/Cipher.java >>> @@ -611,6 +611,10 @@ >>> return getInstance(transformation, p); >>> } >>> >>> + private String getProviderName() { >>> + return (provider == null) ? "(no provider)" : >>> provider.getName(); >>> + } >>> + >>> /** >>> * Returns a {@code Cipher} object that implements the specified >>> * transformation. >>> @@ -1278,7 +1282,7 @@ >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Cipher." + transformation + " " + >>> getOpmodeString(opmode) + " algorithm from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> @@ -1421,7 +1425,7 @@ >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Cipher." + transformation + " " + >>> getOpmodeString(opmode) + " algorithm from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> @@ -1564,7 +1568,7 @@ >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Cipher." + transformation + " " + >>> getOpmodeString(opmode) + " algorithm from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> @@ -1754,7 +1758,7 @@ >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Cipher." + transformation + " " + >>> getOpmodeString(opmode) + " algorithm from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> diff --git a/src/java.base/share/classes/javax/crypto/KeyAgreement.java >>> b/src/java.base/share/classes/javax/crypto/KeyAgreement.java >>> --- a/src/java.base/share/classes/javax/crypto/KeyAgreement.java >>> +++ b/src/java.base/share/classes/javax/crypto/KeyAgreement.java >>> @@ -484,7 +484,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("KeyAgreement." + algorithm + " algorithm >>> from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> @@ -517,6 +517,10 @@ >>> init(key, params, JceSecurity.RANDOM); >>> } >>> >>> + private String getProviderName() { >>> + return (provider == null) ? "(no provider)" : >>> provider.getName(); >>> + } >>> + >>> /** >>> * Initializes this key agreement with the given key, set of >>> * algorithm parameters, and source of randomness. >>> @@ -545,7 +549,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("KeyAgreement." + algorithm + " algorithm >>> from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> diff --git a/src/java.base/share/classes/javax/crypto/KeyGenerator.java >>> b/src/java.base/share/classes/javax/crypto/KeyGenerator.java >>> --- a/src/java.base/share/classes/javax/crypto/KeyGenerator.java >>> +++ b/src/java.base/share/classes/javax/crypto/KeyGenerator.java >>> @@ -154,7 +154,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("KeyGenerator." + algorithm + " algorithm >>> from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> @@ -172,10 +172,14 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("KeyGenerator." + algorithm + " algorithm >>> from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> + private String getProviderName() { >>> + return (provider == null) ? "(no provider)" : >>> provider.getName(); >>> + } >>> + >>> /** >>> * Returns the algorithm name of this {@code KeyGenerator} object. >>> * >>> diff --git a/src/java.base/share/classes/javax/crypto/Mac.java >>> b/src/java.base/share/classes/javax/crypto/Mac.java >>> --- a/src/java.base/share/classes/javax/crypto/Mac.java >>> +++ b/src/java.base/share/classes/javax/crypto/Mac.java >>> @@ -415,6 +415,10 @@ >>> return spi.engineGetMacLength(); >>> } >>> >>> + private String getProviderName() { >>> + return (provider == null) ? "(no provider)" : >>> provider.getName(); >>> + } >>> + >>> /** >>> * Initializes this {@code Mac} object with the given key. >>> * >>> @@ -437,7 +441,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Mac." + algorithm + " algorithm from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> @@ -464,7 +468,7 @@ >>> >>> if (!skipDebug && pdebug != null) { >>> pdebug.println("Mac." + algorithm + " algorithm from: " + >>> - this.provider.getName()); >>> + getProviderName()); >>> } >>> } >>> >>> diff --git a/test/java/security/Signature/NoProvider.java >>> b/test/java/security/Signature/NoProvider.java >>> --- a/test/java/security/Signature/NoProvider.java >>> +++ b/test/java/security/Signature/NoProvider.java >>> @@ -25,7 +25,7 @@ >>> * @test >>> * @bug 8165751 >>> * @summary Verify that that a subclass of Signature that does not >>> contain a >>> - * provider can be used verify. >>> + * provider can be used to verify. >>> * @run main/othervm -Djava.security.debug=provider NoProvider >>> */ >>> >>> diff --git a/test/javax/crypto/NullCipher/TestNPE.java >>> b/test/javax/crypto/NullCipher/TestNPE.java >>> --- a/test/javax/crypto/NullCipher/TestNPE.java >>> +++ b/test/javax/crypto/NullCipher/TestNPE.java >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2003, 2007, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -23,10 +23,12 @@ >>> >>> /* >>> * @test >>> - * @bug 4937853 >>> + * @bug 4937853 8170876 >>> * @summary Make sure normal calls of NullCipher does not throw NPE. >>> * @author Valerie Peng >>> * @key randomness >>> + * @run main TestNPE >>> + * @run main/othervm -Djava.security.debug=provider TestNPE >>> */ >>> import java.util.Arrays; >>> import java.security.AlgorithmParameters; >>> > From sha.jiang at oracle.com Wed Dec 21 06:12:10 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 21 Dec 2016 14:12:10 +0800 Subject: RFR[9] JDK-8168935: sun/security/ssl/SSLContextImpl/TrustTrustedCert.java failed Intermittently In-Reply-To: <63cc6a77-b75f-99fc-9446-871c10c8b986@oracle.com> References: <63cc6a77-b75f-99fc-9446-871c10c8b986@oracle.com> Message-ID: Hi Xuelei, Thanks for you comments. Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8168935/webrev.01/ The updated version adds method configureServerSocket(SSLServerSocket socket) only, because the other two methods has no association to this fix. And it looks the existing method runClientApplication(SSLSocket socket) could do the same things for method configureClientSocket(SSLSocket socket). Best regards, John Jiang On 2016/12/21 1:18, Xuelei Fan wrote: > Hi John, > > I was wondering to add three methods in the template: > . configureClientSocket(SSLSocket socket) > . configureServerSocket(SSLSocket socket) > . configureServerSocket(SSLServerSocket socket) > > However, there was no use of any of them of my previous update, so we > did not add them. Your adding of createSSLServerSocket() looks fine. > except that it is not straightfoard that the caller > (TrustTrustedCert.java) is calling super.createSSLServerSocket(). > Would you mind add and update to use > configureServerSocket(SSLServerSocket)? > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > On 12/20/2016 6:11 AM, John Jiang wrote: >> Hi, >> In test sun/security/ssl/SSLContextImpl/TrustTrustedCert.java, the >> server may wait for the client for a long time, then the test execution >> goes to timeout. >> This patch takes advantage of >> javax/net/ssl/templates/SSLSocketTemplate.java to fix this issue. >> >> Please note that: >> 1. SSLSocketTemplate.java is modified a bit to aid this fix. > > >> 2. Compare with the previous version of TrustTrustedCert.java, the >> server side should handle SSLSocketException if the certificates do not >> conform to algorithm constraints. That's similar to the scenario on the >> client side. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8168935/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8168935 >> >> Best regards, >> John Jiang >> > From xuelei.fan at oracle.com Wed Dec 21 06:34:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 20 Dec 2016 22:34:23 -0800 Subject: RFR[9] JDK-8168935: sun/security/ssl/SSLContextImpl/TrustTrustedCert.java failed Intermittently In-Reply-To: References: <63cc6a77-b75f-99fc-9446-871c10c8b986@oracle.com> Message-ID: On 12/20/2016 10:12 PM, John Jiang wrote: > Hi Xuelei, > Thanks for you comments. > Please review the updated webrev: > http://cr.openjdk.java.net/~jjiang/8168935/webrev.01/ > Looks fine to me. > The updated version adds method configureServerSocket(SSLServerSocket > socket) only, because the other two methods has no association to this fix. > And it looks the existing method runClientApplication(SSLSocket socket) > could do the same things for method configureClientSocket(SSLSocket > socket). > I think so, too. Thanks, Xuelei > Best regards, > John Jiang > > On 2016/12/21 1:18, Xuelei Fan wrote: >> Hi John, >> >> I was wondering to add three methods in the template: >> . configureClientSocket(SSLSocket socket) >> . configureServerSocket(SSLSocket socket) >> . configureServerSocket(SSLServerSocket socket) >> >> However, there was no use of any of them of my previous update, so we >> did not add them. Your adding of createSSLServerSocket() looks fine. >> except that it is not straightfoard that the caller >> (TrustTrustedCert.java) is calling super.createSSLServerSocket(). >> Would you mind add and update to use >> configureServerSocket(SSLServerSocket)? >> >> Otherwise, looks fine to me. >> >> Thanks, >> Xuelei >> >> On 12/20/2016 6:11 AM, John Jiang wrote: >>> Hi, >>> In test sun/security/ssl/SSLContextImpl/TrustTrustedCert.java, the >>> server may wait for the client for a long time, then the test execution >>> goes to timeout. >>> This patch takes advantage of >>> javax/net/ssl/templates/SSLSocketTemplate.java to fix this issue. >>> >>> Please note that: >>> 1. SSLSocketTemplate.java is modified a bit to aid this fix. >> >> >>> 2. Compare with the previous version of TrustTrustedCert.java, the >>> server side should handle SSLSocketException if the certificates do not >>> conform to algorithm constraints. That's similar to the scenario on the >>> client side. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8168935/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8168935 >>> >>> Best regards, >>> John Jiang >>> >> > From sibabrata.sahoo at oracle.com Wed Dec 21 07:34:17 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 20 Dec 2016 23:34:17 -0800 (PST) Subject: [9] RFR 8161232: AsyncSSLSocketClose.java test fails timeout. Message-ID: <448cf801-d3e0-4ee5-bcc1-3e3f6dbc4f57@default> Hi, Please review the following patch, JBS: https://bugs.openjdk.java.net/browse/JDK-8161232 Webrev: http://cr.openjdk.java.net/~ssahoo/8161232/webrev.00/ Description: It was reported the Test was failing with timeout consistently on macOS. There is no log available anymore and the issue is not reproducible after several trial. It also seems that the actual issue has been fixed by JDK-8075484. I believe it will be appropriate for now to remove the Test from problem list and re-open if the issue persist again. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Dec 21 17:01:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 21 Dec 2016 09:01:16 -0800 Subject: [9] RFR 8161232: AsyncSSLSocketClose.java test fails timeout. In-Reply-To: <448cf801-d3e0-4ee5-bcc1-3e3f6dbc4f57@default> References: <448cf801-d3e0-4ee5-bcc1-3e3f6dbc4f57@default> Message-ID: Looks good to me. Thanks, Xuelei On 12/20/2016 11:34 PM, Sibabrata Sahoo wrote: > Hi, > > > > Please review the following patch, > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8161232 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8161232/webrev.00/ > > > > Description: > > It was reported the Test was failing with timeout consistently on macOS. > There is no log available anymore and the issue is not reproducible > after several trial. It also seems that the actual issue has been fixed > by JDK-8075484. I believe it will be appropriate for now to remove the > Test from problem list and re-open if the issue persist again. > > > > Thanks, > > Siba > > > From xuelei.fan at oracle.com Wed Dec 21 20:05:52 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 21 Dec 2016 12:05:52 -0800 Subject: Code Review Request, 6972386 issues with String.toLowerCase/toUpperCase Message-ID: <8c7674c4-16e9-28d2-6c2c-2dadb349a528@oracle.com> Hi, Please review the fix: http://cr.openjdk.java.net/~xuelei/6972386/webrev.00/ Change to use the language/country neutral locale for the locale sensitive operations. Thanks, Xuelei From xuelei.fan at oracle.com Wed Dec 21 20:39:28 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 21 Dec 2016 12:39:28 -0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> Message-ID: I'm trying to understand this update. Does "/-" imply "/foo"? Does the following spec can be used to explain the new added note? *
  • if the wildcard flag is "-", the simple pathname's path * must be recursively inside the wildcard pathname's path. Xuelei On 12/19/2016 11:25 PM, Wang Weijun wrote: > Ping again. > >> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >> >> An clarification is added to FilePermission::implies: >> >> * @implNote >> .... >> * a simple {@code npath} is recursively inside a wildcard {@code npath} >> * if and only if {@code simple_npath.relativize(wildcard_npath)} >> - * is a series of one or more "..". An invalid {@code FilePermission} does >> + * is a series of one or more "..". Note that this means "/-" does not >> + * imply "foo". An invalid {@code FilePermission} does >> * not imply any object except for itself. >> >> The newly added sentence is >> >> Note that this means "/-" does not imply "foo". >> >> JCK has agreed to update their test. >> >> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Wed Dec 21 23:58:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Dec 2016 07:58:46 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> Message-ID: <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> > On Dec 22, 2016, at 4:39 AM, Xuelei Fan wrote: > > I'm trying to understand this update. Does "/-" imply "/foo"? Yes. > > Does the following spec can be used to explain the new added note? > > *
  • if the wildcard flag is "-", the simple pathname's path > * must be recursively inside the wildcard pathname's path. Yes. But the precise meaning of "recursively inside" is different between the pre-jdk9 and jdk9 behaviors. The @implNote explains more. --Max > > Xuelei > > On 12/19/2016 11:25 PM, Wang Weijun wrote: >> Ping again. >> >>> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >>> >>> An clarification is added to FilePermission::implies: >>> >>> * @implNote >>> .... >>> * a simple {@code npath} is recursively inside a wildcard {@code npath} >>> * if and only if {@code simple_npath.relativize(wildcard_npath)} >>> - * is a series of one or more "..". An invalid {@code FilePermission} does >>> + * is a series of one or more "..". Note that this means "/-" does not >>> + * imply "foo". An invalid {@code FilePermission} does >>> * not imply any object except for itself. >>> >>> The newly added sentence is >>> >>> Note that this means "/-" does not imply "foo". >>> >>> JCK has agreed to update their test. >>> >>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >>> >>> Thanks >>> Max >>> >> From s.abramoviz at emergecds.com Wed Dec 21 19:43:28 2016 From: s.abramoviz at emergecds.com (Shlomi Abramoviz) Date: Wed, 21 Dec 2016 21:43:28 +0200 Subject: An Unexpected I/O exception with AsyncHttpClient while performing SSL requests Message-ID: Hi everyone, I was referred to this group and I hope this is the right place and would really appreciate if you could share your opinion with me. My company works with Play framework and Scala as our backend server. Lately we've been having problems with the server. While making a secured (SSL) request to a remote API, we're getting the exception below. Seems to be a problem regarding to the SSL, but I'm not sure. We had a similar problem a month ago, and setting the flag: -J-XX:-UseAESIntrinsics -DXX:-UseAESIntrinsics seemed to help. Now the problem is back. Some more information: - Play 2.5.9 - Scala 2.11.8 - Server OS: Centos 6.8 - JVM 1.8.0_25 The Exception: - AsyncHttpClient-2-4 - 2016-12-21 03:59:17,434 - [debug] - from org.asynchttpclient.netty.handler.HttpHandler - Unexpected I/O exception on channel [id: 0x9ad15e31, L:/[IP_ADDRESS:PORT - R:SERVER/IP_ADDRESS:443] java.lang.NullPointerException: null at java.lang.System.arraycopy(Native Method) at com.sun.crypto.provider.GCTR.reset(GCTR.java:125) at com.sun.crypto.provider.GCTR.doFinal(GCTR.java:116) at com.sun.crypto.provider.GaloisCounterMode.doLastBlock(GaloisCounterMode.java:343) at com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:511) at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1023) at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:960) at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:479) at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:830) at javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at javax.crypto.Cipher.doFinal(Cipher.java:2416) at sun.security.ssl.CipherBox.decrypt(CipherBox.java:535) at sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:200) at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:968) at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:901) at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:775) at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1094) at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:966) at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:900) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345) at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:611) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:552) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:466) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:140) at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144) at java.lang.Thread.run(Thread.java:745) Does anyone have an idea what the problem could be and how can we fix it? Also, is there any other place you know where I could get help about this topic? Thanks in advance, Shlomi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Dec 22 00:12:53 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 21 Dec 2016 16:12:53 -0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> Message-ID: I think the note is an example, may not need an additional CCC. For easier reading, I may use a contrast example. For example, "Note that this means "/-" implies "/foo" but not "foo".". Use the one you like, I'm OK with the either. Xuelei On 12/21/2016 3:58 PM, Wang Weijun wrote: > >> On Dec 22, 2016, at 4:39 AM, Xuelei Fan wrote: >> >> I'm trying to understand this update. Does "/-" imply "/foo"? > > Yes. > >> >> Does the following spec can be used to explain the new added note? >> >> *
  • if the wildcard flag is "-", the simple pathname's path >> * must be recursively inside the wildcard pathname's path. > > Yes. > > But the precise meaning of "recursively inside" is different between the pre-jdk9 and jdk9 behaviors. The @implNote explains more. > > --Max > >> >> Xuelei >> >> On 12/19/2016 11:25 PM, Wang Weijun wrote: >>> Ping again. >>> >>>> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >>>> >>>> An clarification is added to FilePermission::implies: >>>> >>>> * @implNote >>>> .... >>>> * a simple {@code npath} is recursively inside a wildcard {@code npath} >>>> * if and only if {@code simple_npath.relativize(wildcard_npath)} >>>> - * is a series of one or more "..". An invalid {@code FilePermission} does >>>> + * is a series of one or more "..". Note that this means "/-" does not >>>> + * imply "foo". An invalid {@code FilePermission} does >>>> * not imply any object except for itself. >>>> >>>> The newly added sentence is >>>> >>>> Note that this means "/-" does not imply "foo". >>>> >>>> JCK has agreed to update their test. >>>> >>>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >>>> >>>> Thanks >>>> Max >>>> >>> > From weijun.wang at oracle.com Thu Dec 22 00:14:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Dec 2016 08:14:28 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> Message-ID: <279964A0-C943-48B7-86F0-210871A2723F@oracle.com> > On Dec 22, 2016, at 8:12 AM, Xuelei Fan wrote: > > I think the note is an example, may not need an additional CCC. That's always my understanding. > > For easier reading, I may use a contrast example. For example, "Note that this means "/-" implies "/foo" but not "foo".". Good advice. Thanks Max > > Use the one you like, I'm OK with the either. > > Xuelei > > On 12/21/2016 3:58 PM, Wang Weijun wrote: >> >>> On Dec 22, 2016, at 4:39 AM, Xuelei Fan wrote: >>> >>> I'm trying to understand this update. Does "/-" imply "/foo"? >> >> Yes. >> >>> >>> Does the following spec can be used to explain the new added note? >>> >>> *
  • if the wildcard flag is "-", the simple pathname's path >>> * must be recursively inside the wildcard pathname's path. >> >> Yes. >> >> But the precise meaning of "recursively inside" is different between the pre-jdk9 and jdk9 behaviors. The @implNote explains more. >> >> --Max >> >>> >>> Xuelei >>> >>> On 12/19/2016 11:25 PM, Wang Weijun wrote: >>>> Ping again. >>>> >>>>> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >>>>> >>>>> An clarification is added to FilePermission::implies: >>>>> >>>>> * @implNote >>>>> .... >>>>> * a simple {@code npath} is recursively inside a wildcard {@code npath} >>>>> * if and only if {@code simple_npath.relativize(wildcard_npath)} >>>>> - * is a series of one or more "..". An invalid {@code FilePermission} does >>>>> + * is a series of one or more "..". Note that this means "/-" does not >>>>> + * imply "foo". An invalid {@code FilePermission} does >>>>> * not imply any object except for itself. >>>>> >>>>> The newly added sentence is >>>>> >>>>> Note that this means "/-" does not imply "foo". >>>>> >>>>> JCK has agreed to update their test. >>>>> >>>>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> >> From weijun.wang at oracle.com Thu Dec 22 00:26:56 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Dec 2016 08:26:56 +0800 Subject: Code Review Request, 6972386 issues with String.toLowerCase/toUpperCase In-Reply-To: <8c7674c4-16e9-28d2-6c2c-2dadb349a528@oracle.com> References: <8c7674c4-16e9-28d2-6c2c-2dadb349a528@oracle.com> Message-ID: Change looks fine. Thanks for taking care of CtrDrbg.java. I've make quite some changes like this and it's a shame I missed it in my own code. --Max > On Dec 22, 2016, at 4:05 AM, Xuelei Fan wrote: > > Hi, > > Please review the fix: > > http://cr.openjdk.java.net/~xuelei/6972386/webrev.00/ > > Change to use the language/country neutral locale for the locale sensitive operations. > > Thanks, > Xuelei From weijun.wang at oracle.com Thu Dec 22 01:52:13 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Dec 2016 09:52:13 +0800 Subject: RFR 8170732: GssKrb5Client sends non-zero buffer size when qop is "auth" Message-ID: <4DAED2E1-205B-4F36-B593-FC458876C83D@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8170732/webrev.00/ According to https://tools.ietf.org/html/rfc4752#section-3.1: The client then constructs data, with the first octet containing the bit-mask specifying the selected security layer, the second through fourth octets containing in network byte order the maximum size output_message the client is able to receive (which MUST be 0 if the client does not support any security layer), A test is modified to check this case. Please note that when there is no security layer, you cannot call wrap/unwrap anymore. Thanks Max From tiantian.du at oracle.com Thu Dec 22 09:20:23 2016 From: tiantian.du at oracle.com (Tim Du) Date: Thu, 22 Dec 2016 17:20:23 +0800 Subject: [9] RFR:8168769: javax/net/ssl/TLSv12/DisabledShortRSAKeys.java timed out Message-ID: Hi All: Would like help to review the code change for javax/net/ssl/TLSv12/DisabledShortRSAKeys.java? The test case failed with synchronization test issue between client and server intermittently, use advantage of SSLSocketSample.java to make stable and get rid of duplicate codes.Thanks. JBS:https://bugs.openjdk.java.net/browse/JDK-8168769 webrev:http://cr.openjdk.java.net/~tidu/8168769/webrev.00/ Regards Tim From vincent.x.ryan at oracle.com Thu Dec 22 10:38:27 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 22 Dec 2016 10:38:27 +0000 Subject: [9] RFR 8171443: (spec) An ALPN callback function may also ignore ALPN Message-ID: <5FC5BC0C-6A74-4CB1-8E58-A2F6E2B81615@oracle.com> Please review this spec change to allow an ALPN callback function to also disable ALPN usage and return no ALPN extension value during a TLS handshake. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8171443 Webrev: http://cr.openjdk.java.net/~vinnie/8171443/webrev.01/ From simone.bordet at gmail.com Thu Dec 22 11:06:15 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 22 Dec 2016 12:06:15 +0100 Subject: [9] RFR 8171443: (spec) An ALPN callback function may also ignore ALPN In-Reply-To: <5FC5BC0C-6A74-4CB1-8E58-A2F6E2B81615@oracle.com> References: <5FC5BC0C-6A74-4CB1-8E58-A2F6E2B81615@oracle.com> Message-ID: Vincent, On Thu, Dec 22, 2016 at 11:38 AM, Vincent Ryan wrote: > Please review this spec change to allow an ALPN callback function to also disable ALPN usage > and return no ALPN extension value during a TLS handshake. As I understand it, the callback needs to convey 3 results: 1. a success -> non empty string 2. a failure -> null 3. no action -> empty string I wonder if it is better to convey the failure by throwing an exception ? This would also match the case where the implementation of the function, for any reason, throws an unexpected exception such as NPE or ClassCastException, etc. I expect the SSLEngine implementation to catch Throwable from the invocation of the callback and send back a TLS close message with code 120. If the failure case is conveyed with an exception, then only 2 cases remain, and then null can be used to signal "no action" ? The SSLEngine implementation should also check that the String returned is among those sent by the other peer, so an empty string is as invalid as the string "no_proto" - hence the choice of null to signal "no action". Makes sense ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.coffey at oracle.com Thu Dec 22 11:13:42 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 22 Dec 2016 11:13:42 +0000 Subject: An Unexpected I/O exception with AsyncHttpClient while performing SSL requests In-Reply-To: References: Message-ID: <6fd909a5-ec95-8b32-24db-d597fdaedb9f@oracle.com> Your JDK version is quite old. Try updating to the latest JDK 8u release. this might be a factor and was fixed in 8u51. http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/445debb5c61d Sean. On 21/12/2016 19:43, Shlomi Abramoviz wrote: > Hi everyone, > I was referred to this group and I hope this is the right place and > would really appreciate if you could share your opinion with me. > > My company works with Play framework and Scala as our backend server. > Lately we've been having problems with the server. While making a > secured (SSL) request to a remote API, we're getting the exception > below. Seems to be a problem regarding to the SSL, but I'm not sure. > We had a similar problem a month ago, and setting the flag: > > -J-XX:-UseAESIntrinsics -DXX:-UseAESIntrinsics > > seemed to help. Now the problem is back. > > Some more information: - Play 2.5.9 - Scala 2.11.8 - Server OS: Centos > 6.8 - JVM 1.8.0_25 > > The Exception: > > * AsyncHttpClient-2-4 - 2016-12-21 03:59:17,434 - [debug] - from > org.asynchttpclient.netty.handler.HttpHandler - Unexpected I/O > exception on channel [id: 0x9ad15e31, L:/[IP_ADDRESS:PORT - > R:SERVER/IP_ADDRESS:443] java.lang.NullPointerException: null at > java.lang.System.arraycopy(Native Method) at > com.sun.crypto.provider.GCTR.reset(GCTR.java:125) at > com.sun.crypto.provider.GCTR.doFinal(GCTR.java:116) at > com.sun.crypto.provider.GaloisCounterMode.doLastBlock(GaloisCounterMode.java:343) > at > com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:511) > at > com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1023) > at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:960) > at > com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:479) > at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:830) at > javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at > javax.crypto.Cipher.doFinal(Cipher.java:2416) at > sun.security.ssl.CipherBox.decrypt(CipherBox.java:535) at > sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:200) > at > sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:968) > at > sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:901) > at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:775) > at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) at > io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1094) at > io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:966) at > io.netty.handler.ssl.SslHandler.decode(SslHandler.java:900) at > io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) > at > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345) > at > io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366) > at > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352) > at > io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911) > at > io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > at > io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:611) > at > io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:552) > at > io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:466) > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438) at > io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:140) > at > io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144) > at java.lang.Thread.run(Thread.java:745) > > Does anyone have an idea what the problem could be and how can we fix it? > > Also, is there any other place you know where I could get help about > this topic? > > Thanks in advance, > > Shlomi. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Dec 22 11:18:01 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 22 Dec 2016 11:18:01 +0000 Subject: [9] RFR:8168769: javax/net/ssl/TLSv12/DisabledShortRSAKeys.java timed out In-Reply-To: References: Message-ID: <7f6568bc-4d82-2d65-4592-c969287f8a43@oracle.com> Looks good. regards, Sean. On 22/12/2016 09:20, Tim Du wrote: > Hi All: > > Would like help to review the code change for > javax/net/ssl/TLSv12/DisabledShortRSAKeys.java? The test case failed > with synchronization test issue between client and server > intermittently, use advantage of SSLSocketSample.java to make stable > and get rid of duplicate codes.Thanks. > > JBS:https://bugs.openjdk.java.net/browse/JDK-8168769 > webrev:http://cr.openjdk.java.net/~tidu/8168769/webrev.00/ > > Regards > Tim From vincent.x.ryan at oracle.com Thu Dec 22 12:10:06 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 22 Dec 2016 12:10:06 +0000 Subject: [9] RFR 8171443: (spec) An ALPN callback function may also ignore ALPN In-Reply-To: References: <5FC5BC0C-6A74-4CB1-8E58-A2F6E2B81615@oracle.com> Message-ID: <3CCA9C25-4A67-4B72-BE00-DE070AD01B6F@oracle.com> Hello Simone, Throwing an exception is certainly another option but we chose these 3 specific return values for the callback so that they match the existing behaviour of SSLEngine.getApplicationProtocol / SSLEngine.getHandshakeApplicationProtocol and the SSLSocket equivalents. http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLEngine.html#getApplicationProtocol-- http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLEngine.html#getHandshakeApplicationProtocol-- http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLSocket.html#getApplicationProtocol-- http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLSocket.html#getHandshakeApplicationProtocol-- BTW if a runtime exception does get thrown from the callback then it gets handled further up the call stack where a TLS fatal alert will be returned. I don?t think it is worth changing all these methods to throw an exception instead. I?d prefer to keep the current behaviour. Thanks. > On 22 Dec 2016, at 11:06, Simone Bordet wrote: > > Vincent, > > On Thu, Dec 22, 2016 at 11:38 AM, Vincent Ryan > wrote: >> Please review this spec change to allow an ALPN callback function to also disable ALPN usage >> and return no ALPN extension value during a TLS handshake. > > As I understand it, the callback needs to convey 3 results: > 1. a success -> non empty string > 2. a failure -> null > 3. no action -> empty string > > I wonder if it is better to convey the failure by throwing an exception ? > This would also match the case where the implementation of the > function, for any reason, throws an unexpected exception such as NPE > or ClassCastException, etc. > I expect the SSLEngine implementation to catch Throwable from the > invocation of the callback and send back a TLS close message with code > 120. > > If the failure case is conveyed with an exception, then only 2 cases > remain, and then null can be used to signal "no action" ? > > The SSLEngine implementation should also check that the String > returned is among those sent by the other peer, so an empty string is > as invalid as the string "no_proto" - hence the choice of null to > signal "no action". > > Makes sense ? > > Thanks ! > > -- > Simone Bordet > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Thu Dec 22 16:55:41 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Dec 2016 08:55:41 -0800 Subject: [9] RFR:8168769: javax/net/ssl/TLSv12/DisabledShortRSAKeys.java timed out In-Reply-To: References: Message-ID: 144 InputStream sslIS = socket.getInputStream(); This variable is not used and can be removed. Otherwise, looks fine to me. Xuelei On 12/22/2016 1:20 AM, Tim Du wrote: > Hi All: > > Would like help to review the code change for > javax/net/ssl/TLSv12/DisabledShortRSAKeys.java? The test case failed > with synchronization test issue between client and server > intermittently, use advantage of SSLSocketSample.java to make stable and > get rid of duplicate codes.Thanks. > > JBS:https://bugs.openjdk.java.net/browse/JDK-8168769 > webrev:http://cr.openjdk.java.net/~tidu/8168769/webrev.00/ > > Regards > Tim From xuelei.fan at oracle.com Thu Dec 22 16:58:12 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Dec 2016 08:58:12 -0800 Subject: [9] RFR 8171443: (spec) An ALPN callback function may also ignore ALPN In-Reply-To: <5FC5BC0C-6A74-4CB1-8E58-A2F6E2B81615@oracle.com> References: <5FC5BC0C-6A74-4CB1-8E58-A2F6E2B81615@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 12/22/2016 2:38 AM, Vincent Ryan wrote: > Please review this spec change to allow an ALPN callback function to also disable ALPN usage > and return no ALPN extension value during a TLS handshake. > > Thanks. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171443 > Webrev: http://cr.openjdk.java.net/~vinnie/8171443/webrev.01/ > From sean.mullan at oracle.com Thu Dec 22 17:32:13 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 22 Dec 2016 12:32:13 -0500 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: References: Message-ID: On 12/20/16 3:21 PM, Xuelei Fan wrote: >> 213 if (storePassword != null && !storePassword.isEmpty()) { >> 214 MessageDigest md = >> JsseJce.getMessageDigest("SHA-256"); >> 215 result = 31 * result + >> 216 Arrays.hashCode(md.digest(storePassword.getBytes())); >> 217 } >> >> Why are you hashing the password here? Are you afraid this could be >> leaked or guessed somehow? > Yes. The hash code of the password part can be computed. I was > wondering the String.hashCode() may not have sufficient strength. > >> I would just leave the password out of the >> hashcode and equals. It doesn't matter, it's still the same file, right? >> I'm not sure if the type or provider matter either. Don't you just care >> about the name of the file and the modification time? >> > For file type key store, the file and the modification time should be > sufficient. But for non-file (PKCS11) key store, the provider and > password may be sensible. The basic idea is that, if one of the system > property get updated, the key store should be reloaded. Checking every > property update makes the code more straightforward. But the main focus of this performance issue is for the cacerts file, which is not PKCS11. So I would not use the password and other non-relevant or security-sensitive attributes. A hash of the password isn't sufficient against dictionary-type attacks, for example. >> 268 if ((temporaryDesc != null) && >> >> Why would a null descriptor ever be ok? Shouldn't you just let this >> throw NPE? Same comment on line 301. >> > The temporaryDesc is initialized as null. A singleton service > (TrustStoreManage.tam) is used and lazy loaded. Null means the > descriptor has not been assigned. I think there are thread-safeness issues in the TrustStoreManager class. You are not synchronizing when you read so looks like there can be various race conditions. For example, this.descriptor and this.ksRef can be updated by another thread in the middle of this code 267 TrustStoreDescriptor temporaryDesc = this.descriptor; 268 if ((temporaryDesc != null) && 269 temporaryDesc.equals(descriptor)) { 270 KeyStore ks = ksRef.get(); 271 if (ks != null) { 272 return ks; 273 } 274 } Maybe that doesn't really matter, but I'm not sure -- have you thought about it? --Sean From xuelei.fan at oracle.com Thu Dec 22 19:52:28 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Dec 2016 11:52:28 -0800 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: References: Message-ID: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> updated: http://cr.openjdk.java.net/~xuelei/8129988/webrev.02/ On 12/22/2016 9:32 AM, Sean Mullan wrote: > On 12/20/16 3:21 PM, Xuelei Fan wrote: > >>> 213 if (storePassword != null && >>> !storePassword.isEmpty()) { >>> 214 MessageDigest md = >>> JsseJce.getMessageDigest("SHA-256"); >>> 215 result = 31 * result + >>> 216 Arrays.hashCode(md.digest(storePassword.getBytes())); >>> 217 } >>> >>> Why are you hashing the password here? Are you afraid this could be >>> leaked or guessed somehow? >> Yes. The hash code of the password part can be computed. I was >> wondering the String.hashCode() may not have sufficient strength. >> >>> I would just leave the password out of the >>> hashcode and equals. It doesn't matter, it's still the same file, right? >>> I'm not sure if the type or provider matter either. Don't you just care >>> about the name of the file and the modification time? >>> >> For file type key store, the file and the modification time should be >> sufficient. But for non-file (PKCS11) key store, the provider and >> password may be sensible. The basic idea is that, if one of the system >> property get updated, the key store should be reloaded. Checking every >> property update makes the code more straightforward. > > But the main focus of this performance issue is for the cacerts file, > which is not PKCS11. So I would not use the password and other > non-relevant or security-sensitive attributes. A hash of the password > isn't sufficient against dictionary-type attacks, for example. > I see your point. The password hash code block is removed. >>> 268 if ((temporaryDesc != null) && >>> >>> Why would a null descriptor ever be ok? Shouldn't you just let this >>> throw NPE? Same comment on line 301. >>> >> The temporaryDesc is initialized as null. A singleton service >> (TrustStoreManage.tam) is used and lazy loaded. Null means the >> descriptor has not been assigned. > > I think there are thread-safeness issues in the TrustStoreManager class. > You are not synchronizing when you read so looks like there can be > various race conditions. For example, this.descriptor and this.ksRef can > be updated by another thread in the middle of this code > > 267 TrustStoreDescriptor temporaryDesc = this.descriptor; > 268 if ((temporaryDesc != null) && > 269 temporaryDesc.equals(descriptor)) { > 270 KeyStore ks = ksRef.get(); > 271 if (ks != null) { > 272 return ks; > 273 } > 274 } > > Maybe that doesn't really matter, but I'm not sure -- have you thought > about it? > I thought about the issue. But I really missed to the double check idiom. Updated. For performance consideration, I'm trying to mitigate the impact of synchronization. Once the key store get loaded, there is a strong reference, and it can be used safely. If another thread is trying to modify the descriptor and key store, this thread will use the existing key store, and another thread can use the new key store. If two threads try to modify the key store for the same descriptor, I added the double check idiom so that the first thread will complete the update and the 2nd thread will use the 1st thread updated key store. If two threads try to modify the key store for different descriptor, each will get a different key store and the 2nd thread will reset the final key store for future use. In general, applications would not modify the system properties. So the use of the synchronized block should be very rare. It benefits the performance in multiple threading computation environment. Xuelei > --Sean From bradford.wetmore at oracle.com Thu Dec 22 23:26:41 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 22 Dec 2016 15:26:41 -0800 Subject: [9] RFR 8171443: (spec) An ALPN callback function may also ignore ALPN In-Reply-To: References: <5FC5BC0C-6A74-4CB1-8E58-A2F6E2B81615@oracle.com> Message-ID: <8239e93d-022e-c9a0-9643-26a28456a0eb@oracle.com> +1. Brad On 12/22/2016 8:58 AM, Xuelei Fan wrote: > Looks fine to me. > > Thanks, > Xuelei > > On 12/22/2016 2:38 AM, Vincent Ryan wrote: >> Please review this spec change to allow an ALPN callback function to >> also disable ALPN usage >> and return no ALPN extension value during a TLS handshake. >> >> Thanks. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171443 >> Webrev: http://cr.openjdk.java.net/~vinnie/8171443/webrev.01/ >> From dalibor.topic at oracle.com Fri Dec 23 13:11:22 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 23 Dec 2016 14:11:22 +0100 Subject: An Unexpected I/O exception with AsyncHttpClient while performing SSL requests In-Reply-To: References: Message-ID: <35ed5f1f-eca2-b92f-b561-7796dbeb257a@oracle.com> On 21.12.2016 20:43, Shlomi Abramoviz wrote: > Also, is there any other place you know where I could get help about > this topic? If your question is about the Oracle JDK, you can try https://community.oracle.com/community/java . If it's about an OpenJDK build provided by a third party, you can try their forums, mailing lists, or other feedback channels. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sean.mullan at oracle.com Fri Dec 23 15:52:43 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 23 Dec 2016 10:52:43 -0500 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> References: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> Message-ID: <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> On 12/22/16 2:52 PM, Xuelei Fan wrote: > updated: http://cr.openjdk.java.net/~xuelei/8129988/webrev.02/ I think there are still some race conditions. For example: 264 TrustStoreDescriptor temporaryDesc = this.descriptor; 265 KeyStore cachedKeyStore = ksRef.get(); 266 if (descriptor.equals(temporaryDesc) && (cachedKeyStore != null)) { 267 return cachedKeyStore; 268 } There is no locking here. Maybe that's ok based on your explanation below, but it seems a bit fragile and could lead to problems that are hard to debug. Have you looked at the AtomicReference class? You could define a new class containing the descriptor, keystore, and certs and wrap that in an AtomicReference and then use the methods on that class to update it. Might be worth exploring that a bit more. --Sean > On 12/22/2016 9:32 AM, Sean Mullan wrote: >> On 12/20/16 3:21 PM, Xuelei Fan wrote: >> >>>> 213 if (storePassword != null && >>>> !storePassword.isEmpty()) { >>>> 214 MessageDigest md = >>>> JsseJce.getMessageDigest("SHA-256"); >>>> 215 result = 31 * result + >>>> 216 Arrays.hashCode(md.digest(storePassword.getBytes())); >>>> 217 } >>>> >>>> Why are you hashing the password here? Are you afraid this could be >>>> leaked or guessed somehow? >>> Yes. The hash code of the password part can be computed. I was >>> wondering the String.hashCode() may not have sufficient strength. >>> >>>> I would just leave the password out of the >>>> hashcode and equals. It doesn't matter, it's still the same file, >>>> right? >>>> I'm not sure if the type or provider matter either. Don't you just care >>>> about the name of the file and the modification time? >>>> >>> For file type key store, the file and the modification time should be >>> sufficient. But for non-file (PKCS11) key store, the provider and >>> password may be sensible. The basic idea is that, if one of the system >>> property get updated, the key store should be reloaded. Checking every >>> property update makes the code more straightforward. >> >> But the main focus of this performance issue is for the cacerts file, >> which is not PKCS11. So I would not use the password and other >> non-relevant or security-sensitive attributes. A hash of the password >> isn't sufficient against dictionary-type attacks, for example. >> > I see your point. The password hash code block is removed. > >>>> 268 if ((temporaryDesc != null) && >>>> >>>> Why would a null descriptor ever be ok? Shouldn't you just let this >>>> throw NPE? Same comment on line 301. >>>> >>> The temporaryDesc is initialized as null. A singleton service >>> (TrustStoreManage.tam) is used and lazy loaded. Null means the >>> descriptor has not been assigned. >> >> I think there are thread-safeness issues in the TrustStoreManager class. >> You are not synchronizing when you read so looks like there can be >> various race conditions. For example, this.descriptor and this.ksRef can >> be updated by another thread in the middle of this code >> >> 267 TrustStoreDescriptor temporaryDesc = this.descriptor; >> 268 if ((temporaryDesc != null) && >> 269 temporaryDesc.equals(descriptor)) { >> 270 KeyStore ks = ksRef.get(); >> 271 if (ks != null) { >> 272 return ks; >> 273 } >> 274 } >> >> Maybe that doesn't really matter, but I'm not sure -- have you thought >> about it? >> > I thought about the issue. But I really missed to the double check > idiom. Updated. > > For performance consideration, I'm trying to mitigate the impact of > synchronization. Once the key store get loaded, there is a strong > reference, and it can be used safely. If another thread is trying to > modify the descriptor and key store, this thread will use the existing > key store, and another thread can use the new key store. If two threads > try to modify the key store for the same descriptor, I added the double > check idiom so that the first thread will complete the update and the > 2nd thread will use the 1st thread updated key store. If two threads > try to modify the key store for different descriptor, each will get a > different key store and the 2nd thread will reset the final key store > for future use. > > In general, applications would not modify the system properties. So the > use of the synchronized block should be very rare. It benefits the > performance in multiple threading computation environment. > > Xuelei > >> --Sean From weijun.wang at oracle.com Mon Dec 26 19:25:38 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 27 Dec 2016 03:25:38 +0800 Subject: RFR 8172017: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and rcache_usemd5.sh fail on Solaris (Additional pre-authentication required) Message-ID: <57aaff7a-ed0f-2d4d-8b05-100359ba104c@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8172017/webrev.00 On Solaris when launched by root, the rcache directory is a little different. I've manually tested this on a Solaris machine, and seen rcache files created at different directories when the test was launched by root and a normal user. Thanks Max From claes.redestad at oracle.com Tue Dec 27 14:04:45 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Dec 2016 15:04:45 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy Message-ID: Hi, since java.util.concurrent.AtomicReference was changed to use a VarHandle internally, using it from within the security libraries can lead to hard to diagnose bootstrap cycles (since VarHandles has to do doPrivileged calls during setup). The need to initialize VarHandles is also cause for a small startup regression for any application run with a security manager. The use of AtomicReference in java.security.Policy is not really motivated, though, since only the .get/.set methods are used, thus a rather straight-forward fix is to convert the code to use a volatile reference instead with identical semantics: Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ While a rather insignificant startup improvement in and off itself, this would help to unblock the attempted fix to resolve https://bugs.openjdk.java.net/browse/JDK-8062389 Thanks! /Claes From peter.levart at gmail.com Wed Dec 28 00:07:05 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Dec 2016 01:07:05 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: References: Message-ID: <978ff508-a07f-9778-efde-52d19d1f31d2@gmail.com> Hi Claes, A nice find! This is certainly a straightforward and low-risk fix for breaking the initialization cycle problem with JDK-8062389. Related to VarHandles, the call trace of the initialization cycle also includes the following part of code in VarHandle: AccessMode(final String methodName, AccessType at) { this.methodName = methodName; this.at = at; // Assert that return type is correct // Otherwise, when disabled avoid using reflection assert at.returnType == getReturnType(methodName); } ... private static Class getReturnType(String name) { try { Method m = VarHandle.class.getMethod(name, Object[].class); return m.getReturnType(); } catch (Exception e) { throw newInternalError(e); } } ... where enabling assertions (tests enable assertions) causes the initialization of VarHandle(s) to involve reflection. This is also a place that could be made more robust, perhaps by devising a special test that verifies method return types, instead of embedding the check into the AccessMode constructor... Regards, Peter On 12/27/2016 03:04 PM, Claes Redestad wrote: > Hi, > > since java.util.concurrent.AtomicReference was changed to use a > VarHandle internally, using it from within the security libraries can > lead to hard to diagnose bootstrap cycles (since VarHandles has to do > doPrivileged calls during setup). The need to initialize VarHandles is > also cause for a small startup regression for any application run with > a security manager. > > The use of AtomicReference in java.security.Policy is not really > motivated, though, since only the .get/.set methods are used, thus a > rather straight-forward fix is to convert the code to use a volatile > reference instead with identical semantics: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 > Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ > > While a rather insignificant startup improvement in and off itself, > this would help to unblock the attempted fix to resolve > https://bugs.openjdk.java.net/browse/JDK-8062389 > > Thanks! > > /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Dec 30 01:10:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Dec 2016 11:10:15 +1000 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: References: Message-ID: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> Hi Claes, On 28/12/2016 12:04 AM, Claes Redestad wrote: > Hi, > > since java.util.concurrent.AtomicReference was changed to use a > VarHandle internally, using it from within the security libraries can > lead to hard to diagnose bootstrap cycles (since VarHandles has to do > doPrivileged calls during setup). The need to initialize VarHandles is > also cause for a small startup regression for any application run with > a security manager. > > The use of AtomicReference in java.security.Policy is not really > motivated, though, since only the .get/.set methods are used, thus a > rather straight-forward fix is to convert the code to use a volatile > reference instead with identical semantics: I agree, this was a good find! - AtomicReference use was unnecessary in this class and certainly not worth the additional initialization complexity. Not sure about the "// volatile read" commentary when there is no corresponding volatile-write commentary, and when not applied in all locations. Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 > Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ > > While a rather insignificant startup improvement in and off itself, > this would help to unblock the attempted fix to resolve > https://bugs.openjdk.java.net/browse/JDK-8062389 > > Thanks! > > /Claes From claes.redestad at oracle.com Fri Dec 30 14:50:58 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 30 Dec 2016 15:50:58 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> Message-ID: Hi David, On 2016-12-30 02:10, David Holmes wrote: > Hi Claes, > > On 28/12/2016 12:04 AM, Claes Redestad wrote: >> Hi, >> >> since java.util.concurrent.AtomicReference was changed to use a >> VarHandle internally, using it from within the security libraries can >> lead to hard to diagnose bootstrap cycles (since VarHandles has to do >> doPrivileged calls during setup). The need to initialize VarHandles is >> also cause for a small startup regression for any application run with >> a security manager. >> >> The use of AtomicReference in java.security.Policy is not really >> motivated, though, since only the .get/.set methods are used, thus a >> rather straight-forward fix is to convert the code to use a volatile >> reference instead with identical semantics: > > I agree, this was a good find! - AtomicReference use was unnecessary in > this class and certainly not worth the additional initialization > complexity. thanks for reviewing! > > Not sure about the "// volatile read" commentary when there is no > corresponding volatile-write commentary, and when not applied in all > locations. yes, it seems I was lacking in dedication to this idea. It seems customary to point out that one is intentionally doing a read into a local variable as to avoid both performance and correctness issues that'd result if someone tried to "simplify" things. As we're safely publishing an object with only final fields a comment on the writes isn't strictly necessary, but I don't mind adding comments there too for consistency. Or do we prefer no comments at all? :-) /Claes > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 >> Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ >> >> While a rather insignificant startup improvement in and off itself, >> this would help to unblock the attempted fix to resolve >> https://bugs.openjdk.java.net/browse/JDK-8062389 >> >> Thanks! >> >> /Claes From david.holmes at oracle.com Fri Dec 30 23:45:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 31 Dec 2016 09:45:08 +1000 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> Message-ID: On 31/12/2016 12:50 AM, Claes Redestad wrote: > Hi David, > > On 2016-12-30 02:10, David Holmes wrote: >> Hi Claes, >> >> On 28/12/2016 12:04 AM, Claes Redestad wrote: >>> Hi, >>> >>> since java.util.concurrent.AtomicReference was changed to use a >>> VarHandle internally, using it from within the security libraries can >>> lead to hard to diagnose bootstrap cycles (since VarHandles has to do >>> doPrivileged calls during setup). The need to initialize VarHandles is >>> also cause for a small startup regression for any application run with >>> a security manager. >>> >>> The use of AtomicReference in java.security.Policy is not really >>> motivated, though, since only the .get/.set methods are used, thus a >>> rather straight-forward fix is to convert the code to use a volatile >>> reference instead with identical semantics: >> >> I agree, this was a good find! - AtomicReference use was unnecessary in >> this class and certainly not worth the additional initialization >> complexity. > > thanks for reviewing! > >> >> Not sure about the "// volatile read" commentary when there is no >> corresponding volatile-write commentary, and when not applied in all >> locations. > > yes, it seems I was lacking in dedication to this idea. > > It seems customary to point out that one is intentionally doing a read > into a local variable as to avoid both performance and correctness > issues that'd result if someone tried to "simplify" things. As we're > safely publishing an object with only final fields a comment on the > writes isn't strictly necessary, but I don't mind adding comments > there too for consistency. Not sure how others have done this but the read-into-a-local should be documented more clearly as it isn't just the volatile aspect that is critical (for memory ordering) but the read-once aspect! The volatile write must also come after all other initialization actions - even when done inside a sync block. (It does, but it isn't obvious that it does, or that it has to.) > Or do we prefer no comments at all? :-) Not sure. I'll let you think about it so more. I'll be back in the office on Tuesday :) Cheers, David > /Claes > >> >> Thanks, >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 >>> Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ >>> >>> While a rather insignificant startup improvement in and off itself, >>> this would help to unblock the attempted fix to resolve >>> https://bugs.openjdk.java.net/browse/JDK-8062389 >>> >>> Thanks! >>> >>> /Claes