Re: AlgorithmConstraints caching [ was Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice]

I think the work done with 8284694 will help alot in any case since I suspect the same SSLAlgorithmConstraints Object will be shared much more now (rather than spin off new copies) Some recent JFRs I looked at show that alot of CPU cycles[1] get taken in the HandshakeContext methods of :

Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v2]

Hi Valerie, many thanks for the thorough review. I've taken all your feedback on board with the latest push. Some of the test anomalies were a result of previous iterations of test edits I had been making. Regarding the extra edits in "src/java.base/share/lib/security/default.policy", I had

Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads

Thank for the feedback Peter. Comments inline. On 22/06/2021 22:40, Peter Firmstone wrote: Was ever to run with SecurityManager? I found the issue while porting to jdk8u where Solaris uses a configuration file with the SunPKCS11 Provider by default - We have tests to register Providers while

Re: [External] : Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u

Looks good! regards, Sean. On 28/05/2021 17:17, Doerr, Martin wrote: Hi, here’s my new webrev for reverting the pkcs12.macAlgorithm and macIterationCount changes from the JDK-8153005 backport:

(JDK-8266351) Re: [External] : Re: RFR: 8236671: NullPointerException in JKS keystore [v2]

main/java/com/tersesystems/jcakeyfailure/JcaKeyFailure.java*L68__;Iw!!GqivPVa7Brio!KZTaOe6TkXX8t-ZTaptDzm3RETFWZV4O6xj-7_iS2CF-NV4g7FxSSzYEweeC27YT_w$> On Fri, Apr 30, 2021 at 12:40 PM Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Thanks for the feedback Will. It would

Re: [External] : AW: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u

til we switch to the new one in a future release? Best regards, Martin *Von: *Seán Coffey *Datum: *Freitag, 28. Mai 2021 um 15:42 *An: *Doerr, Martin , jdk-updates-...@openjdk.java.net , security-dev , Hohensee, Paul *Betreff: *Re: [11u] RFR: 8267599: Revert the change to the default P

Re: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v2]

Thanks for the review Valerie. I've gone ahead and updated the test. You've a good point in that the PKCS11Test framework didn't suit the test that I needed. The new test no longer extends PKCS11Test as a result. I have kept the refactoring in PKCS11Test thought since it can offer up some

Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u

Martin, you seem to be suggesting a full revert of the JDK-8153005 changes. Note that the Oracle JDK changes only relate to to the default PKCS12 macAlgorithm and macIterationCount (back to HmacPBESHA1 and 10 respectively). While there are other interoperability concerns with the

Re: RFR: 8236671: NullPointerException in JKS keystore [v2]

Thanks for the feedback Will. It would be useful if you can provide a testcase and/or add comments to JDK-8266351 on your experience. regards, Sean. On 30/04/2021 17:54, Will Sargent wrote: > KeyStore specification will be tightened up via

Re: JSSE reference guide issue

Another option for reporting is to use the https://bugreport.java.com portal. Component = documentation. regards, Sean. On 05/02/2021 14:03, Sean Mullan wrote: If you have a JBS account, you can file a bug in the docs/guides category. However, I have also forwarded your email to our

Re: RFR: 8255348: NPE in PKIXCertPathValidator event logging code

Thanks for the comments Sean. Code updated. https://github.com/openjdk/jdk/pull/2150/commits/8a344a85303297f17a6e75e7c1f423c2d16c451a regards, Sean. On 21/01/2021 19:47, Sean Mullan wrote: On Tue, 19 Jan 2021 17:54:33 GMT, Sean Coffey wrote: Correction of NPE and updating of test cases.

Re: RFR: 8253368: TLS connection always receives close_notify exception

of the overall change some more and will reach out to other engineers for opinion also. Hope to revert to the list with an update in next 1-2 weeks. regards, Sean. On Fri, Nov 13, 2020 at 3:01 PM Seán Coffey wrote: Open to discussion on that. It's also highlighted in the TLSv1.3 RFC. The TLS spec

Re: RFR: 8253368: TLS connection always receives close_notify exception

Open to discussion on that. It's also highlighted in the TLSv1.3 RFC. The TLS spec doesn't require a fatal alert to be issued when closing inbound without receiving the peer's close_notify. I've seen a handful of applications making JDK upgrades which are seeing regression as a result of this

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

. JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs. ZipFile.java #661: Suggest to keep the comment and update it with the additional 4 bits for symlink. The rest of code changes and CSR look good. Thanks, Hai-May On Aug 28, 2020, at 7:17 AM, Seán Coffey <mailto:sean.cof...@oracle.

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

28, 2020, at 10:17 AM, Seán Coffey wrote: I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of inter

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. regards, Sean. No other comment. Thanks, Max On Aug 27, 2020, at 3:26 AM, Seán Coffey wrote: updated webrev: http://cr.op

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

updated webrev: http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/ regards, Sean. On 27/08/2020 07:42, Seán Coffey wrote: Hi Max, I looked at updating the warning string but figured that it might have been of no interest to end users. How about this edit

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

5, Weijun Wang wrote: Are you going to update the warning text or create a new one? Thanks, Max On Aug 26, 2020, at 2:26 PM, Seán Coffey wrote: This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should p

RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in

Re: RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider

Your patch looks ok to me Valerie. I note that John mentions an anomaly with your patch - I'm thinking that may need further investigation. regards, Sean. On 06/07/2020 17:33, Valerie Peng wrote: Hi Max, The suggested fix is not much different than the suggested webrev. The essential change

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

ected. These attributes are ignored when signing and are not protected by the signature." regards, Sean. On 02/07/2020 08:59, Alan Bateman wrote: On 30/06/2020 14:51, Seán Coffey wrote: : During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warn

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

t\\.report\\(.*,\"(.*?)\","); If you agree to add a whitespace in the calls in OSCP.java and DistributionFetcher.java, you might want to add a whitespace (or "\s*") here as well. Thanks, Max On Jun 30, 2020, at 9:51 PM, Seán Coffey wrote: Thanks Lance. During the

Re: RFR: 8218021: Have jarsigner preserve posix permission attributes

/ regards, Sean. On 22/06/2020 17:17, Lance Andersen wrote: HI Sean, Looks OK based on our exchanges.  Thank you for your time on this one! Best Lance On Jun 22, 2020, at 7:22 AM, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Thanks Lance. I've updated the patch with some extr

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/ regards, Sean. On 12/06/2020 17:05, Lance Andersen wrote: Hi Sean, I think your changes look fine so all good FMPOV. Best Lance On Jun 12, 2020, at 6:21 AM, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Hi, I'd like to reboot this

RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

Hi, I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms https://bugs.openjdk.java.net/browse/JDK-8218021

Re: Thread leak by LdapLoginModule

If 8217606 is your issue, then it's fixed in JDK 11.0.8 which is due for release in mid July. regards, Sean. On 09/06/2020 22:15, Mkrtchyan, Tigran wrote: Hi all, with Java-11 we have notice a thread leak with ldap module. We use LDAP to authenticate users with username+pasword by directly

Re: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test

Looks like the right approach to me Prasad. Reviewed. regards, Sean. On 04/06/2020 16:13, Prasadrao Koppula wrote: Hi, Could you please review this patch. For timeout/interrupts, JDK11u+ releases, SSLSocket:getSession behavior is different, compare to JDK8u. i.e, connection is in open

Re: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable

I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK

Re: RFR[jdk] 8237474: Default SSLEngine should create in server role

Looks good to me also Prasad. Trivially, I think you can drop the 'object' word in this implNote: "for a new {@code SSLEngine} object" Also, don't forget to create the release note sub-task for this change. regards, Sean. On 02/04/2020 16:56, Prasadrao Koppula wrote: Thanks for review

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

Looks interesting Norman. Do you want to share some more details about the peculiarities of this handshake before considering a fully fledged testcase ? regards, Sean. On 27/03/2020 12:48, Norman Maurer wrote: Hi there, I am just about to add JDK14 to the test matrix for netty and think I

Re: RFR JDK-8240988 : Incorrect copyright header in CertificateValidation.java

Looks fine to me Ravi. regards, Sean. On 30/03/2020 12:14, Ravi Reddy wrote: Hello All, Could you please review this attached patch. This patch fixes the "Incorrect copyright header in CertificateValidation.java". Issue :https://bugs.openjdk.java.net/browse/JDK-8240988

Re: RFR[jdk] 8237474: Default SSLEngine should create in server role

Looks ok to me Prasad. This may also be worthy of highlighting via release note. You might be able to expand test coverage to capture the TLSContext scenario. Something like below patch might work ? --- a/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java +++

Re: RFR(jdk): 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION

Looks fine to me also. Thanks for handling. Sean. On 4 February 2020 21:11:04 GMT, Bradford Wetmore wrote: >Ah yes, defaulted to enhancement. Thanks. > >Brad > > >On 2/4/2020 11:48 AM, Sean Mullan wrote: >> Looks good. I assume this should be a Bug and not an Enhancement >though? >> >>

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

tools docs accordingly. Let me have a think about this. A new flag in jarsigner may help. regards, Sean. Regards, Philipp On Fri, 2020-01-17 at 13:07 +, Seán Coffey wrote: Hi Philipp, On 17/01/2020 12:40, Philipp Kunz wrote: Hi Sean, Nice patch. I wonder why permissions should be preserv

Re: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

d the test would not have to check that files with another name extension than zip don't preserve permissions. Philipp On Fri, 2020-01-17 at 10:59 +0000, Seán Coffey wrote: Hi, Looking to introduce some JDK private functionality which will help preserve internal zip file attribute permis

RFR: 8218021: jarsigner strips the execute permission when signing a .zip file

Hi, Looking to introduce some JDK private functionality which will help preserve internal zip file attribute permissions when jarsigner is run on a zip file. Some of the logic is taken from the recent work carried out in this area for zipfs API.

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

Thanks Alan. Updates made and changes pushed. regards, Sean. On 13/01/2020 18:50, Alan Bateman wrote: On 13/01/2020 10:28, Seán Coffey wrote: some off line comments suggested that I could move the jar initialization checks to the EventHelper class. With that in place, the EventHelper utility

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

Thanks for the reviews. All callers of EventHelper log methods are ensuring that isLoggingSecurity() is true before proceeding. I've added an assert null check in the 4 logger methods to ensure expectations are in place. http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/ Hope this

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

/webrev/ regards, Sean. On 16/12/2019 14:15, Seán Coffey wrote: The recent crypto event logging mechanism (JDK-8148188) has introduced a regression whereby the System Logger may be invoked too early in the bootstrap phase. This causes issue when JarFile objects are locked by JarFile verifier

RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

The recent crypto event logging mechanism (JDK-8148188) has introduced a regression whereby the System Logger may be invoked too early in the bootstrap phase. This causes issue when JarFile objects are locked by JarFile verifier initialization code. The logging work records an X509 Certificate

Re: RFR [14] JDK-8235655, Clean the duplicated block in SSLContextImpl

Looks fine to me. regards, Sean. On 10/12/2019 14:35, Xuelei Fan wrote: On 12/10/2019 6:34 AM, Xuelei Fan wrote: Hi, Could I get the following code-cleanup patch reviewed?     cr.openjdk.java.net/~xuelei/8235655/webrev.00 missing the protocol part:

Re: SunPKCS11 connection lost after Decrypt doFinal (noPadding) openjdk 8_232

Also, which JDK distro version of 8 are you using ? Note that the OpenJDK version has an extra few pkcs11 fixes in OpenJDK in this area (compared to the Oracle JDK 8 Updates) - Below being some of those : https://bugs.openjdk.java.net/browse/JDK-8216597

RFR: 8233801:GCMEmptyIv.java test fails on Solaris 11.4

Seeing an internal test failure on Solaris 11.4. Appears connected with the recent upgrade of PKCS11 libraries to v2.40. The test coverage has increased since SunPKCS11-Solaris now supports  AES/GCM. Unfortunately the bug details are not public but I'll give a summary here. The new test code

Re: RFR 8233884 : Avoid looking up standard charsets in security libraries

On 11/11/2019 20:56, Ivan Gerasimov wrote: Thank you Seán for reviewing! On 11/11/19 7:56 AM, Seán Coffey wrote: Nice work Ivan. I see you've some clean up done on exception handling also. I might have a concern on this change in SSLLogger. You're catching IOException now instead

Re: RFR 8233884 : Avoid looking up standard charsets in security libraries

Nice work Ivan. I see you've some clean up done on exception handling also. I might have a concern on this change in SSLLogger. You're catching IOException now instead of Exception. Given that it's a logger and the intent seems to be to ignore any type of exception - should we leave what's

Re: CSR Review request (11-pool): JDK-8233825: Update SunPKCS11 provider with PKCS11 v2.40 support

Hey Christoph, I've added myself as reviewer for this CSR. Hope that's ok. There was a bug tail with this PKCS11 upgrade (interoperability issues due to ambiguity in the spec) See JDK-8229243 also (and the JDK-8225695 regression) Regards, Sean. On 07/11/19 22:19, Langer, Christoph wrote:

Re: Is there any reason not to have 8223269 in JDK baseline?

. Is there any objection if I propose this for JDK base line? Thanks, Martin.- On 10/30/19 8:14 PM, Seán Coffey wrote: Martin, Newer JDK families should be using the PKCS12 keystore format. For that reason, I kept it 8u only. It was a solution to address a particular use case reported by an Oracle

Re: Is there any reason not to have 8223269 in JDK baseline?

Martin, Newer JDK families should be using the PKCS12 keystore format. For that reason, I kept it 8u only. It was a solution to address a particular use case reported by an Oracle JDK user. regards, Sean. On 30/10/2019 18:21, Martin Balao wrote: Hi, I've noticed that 8223269 [1] (not

Re: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss

Looks fine Joe. regards, Sean. On 23/09/2019 17:15, Joe Darcy wrote: Hello, Another module, another review request as part of making serial warnings more robust:     JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss    

Re:(JDK-8230297) Slow LoginContext.login() due to repeated ServiceLoader lookups

lorent On Tue, Aug 27, 2019 at 6:04 PM Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Probably best to log a bug to capture this issue. It reminds me of another issue I've been meaning to wrap up: https://bugs.openjdk.java.net/browse/JDK-8223260 Similar

Re: Slow LoginContext.login() due to repeated ServiceLoader lookups

Probably best to log a bug to capture this issue. It reminds me of another issue I've been meaning to wrap up: https://bugs.openjdk.java.net/browse/JDK-8223260 Similar scenario in how the ContextFactory is searched for. My proposed patch is to cache a factory per classloader (for the

Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4"

Thanks for taking this on Valerie. It's a shame to see such confusion arise from the new PKCS11 spec. The changes look fine to me. It'll certainly benefit from widespread interoperability testing. Regards, Sean. On 16/08/19 00:49, Valerie Peng wrote: Anyone has time to help review this

RFR: 8228645: Don't run sun/security/pkcs11/Cipher/TestKATForGCM.java on buggy NSS solaris versions

The sun/security/pkcs11/Cipher/TestKATForGCM.java testcase can fail when running on older, buggy NSS libraries. In particular on Solaris 11.2 and earlier. Most of our solaris testing occurs on 11.3 OS but we should discount failures seen in Solaris 11.2 test runs.

Re: RFR (XS) : 8133489: Better messaging for PKIX path validation matching

; } return false; regards, Sean. On 20/06/2019 15:14, Xuelei Fan wrote: On 6/20/2019 5:56 AM, Seán Coffey wrote: A simple debugging enhancement to print out subjectkey ID details when mismatch is encountered. I encountered a DER encoding issue with an ap

RFR (XS) : 8133489: Better messaging for PKIX path validation matching

A simple debugging enhancement to print out subjectkey ID details when mismatch is encountered. I encountered a DER encoding issue with an application server team a good while back and needed such a patch to debug the issue correctly. I added -Djava.security.debug=certpath to a testcase which

RFR (XS) : 8042904: apple.security.KeychainStore.getSalt() calling generateSeed()

https://bugs.openjdk.java.net/browse/JDK-8042904 Looking to correct this issue. SecureRandom.nextBytes looks like the method which should be in use rather than generateSeed(int) --- a/src/java.base/macosx/classes/apple/security/KeychainStore.java +++

Re: RFR: 8191808: Configurable read timeout for CRLs

Thanks. Looks good. regards, Sean. On 09/05/2019 17:38, Sean Mullan wrote: On 5/9/19 11:29 AM, Seán Coffey wrote: Nice feature to have Sean. Thanks. What do you think about adding a debug print if such a value is set ? (perhaps in initializeTimeout method) Good suggestion. I've added

Re: RFR: 8191808: Configurable read timeout for CRLs

Nice feature to have Sean. Thanks. What do you think about adding a debug print if such a value is set ? (perhaps in initializeTimeout method) regards, Sean. On 07/05/2019 17:16, Sean Mullan wrote: On 5/7/19 11:28 AM, Xuelei Fan wrote: What do you think if com.sun.security.crl.readtimeout

Re: RFR: 8222137: Remove T-Systems root CA certificate

anger, Christoph <mailto:christoph.lan...@sap.com> *Cc:* Sean Mullan <mailto:sean.mul...@oracle.com>; security-dev <mailto:security-dev@openjdk.java.net>; Seán Coffey <mailto:sean.cof...@oracle.com> *Subject:* Re: RFR: 8222137: Remove T-Systems root CA certific

Re: RFR: 8222137: Remove T-Systems root CA certificate

2019 21:08 *To:* Langer, Christoph *Cc:* Sean Mullan ; security-dev ; Seán Coffey *Subject:* Re: RFR: 8222137: Remove T-Systems root CA certificate I have created needed backports including 12-pool, 11-pool, 8-pool, and 7-pool. These are assigned to Sean C. for now. Please co-ordinate with him. Tha

Re: [13] RFR JDK-8218780 "Update MUSCLE PCSC-Lite header files"

Looks fine to me Valerie. regards, Sean. On 15/02/2019 20:04, Valerie Peng wrote: Hi Sean (Coffey), Can you please help reviewing this fix? It's about updating the PC/SC lite header files under the MUSCLE directory inside smartcardio module. The header files are from

Re: RFR: 8218553: Enhance keystore load debug output

en someone is trying to debug a live production issue. I think this will help admins to confirm if keystore configuration looks correct in such environments. regards, Sean. Thanks, Max On Feb 6, 2019, at 11:32 PM, Seán Coffey wrote: Looking to improve debug output in the keystore area. I

RFR: 8218553: Enhance keystore load debug output

Looking to improve debug output in the keystore area. It's useful to know how many keys/certs are found in such stores to ensure correct set up. https://bugs.openjdk.java.net/browse/JDK-8218553 http://cr.openjdk.java.net/~coffeys/webrev.8218553/webrev/ -- Regards, Sean.

Re: [12] RFR: 8216280: Allow later Symantec Policy distrust date for two Apple SubCAs

Looks good to me Sean. regards, Sean. On 16/01/2019 19:53, Sean Mullan wrote: Please review this change to allow a later Symantec Policy distrust date for two Apple subordinate CAs. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8216280/webrev.00/ bug:

Re: RFR: 8179943 Typo in javax.net.ssl.SSLSession.removeValue(String) method documentation

Looks fine to me. I can sponsor this patch if required. regards, Sean. On 03/01/2019 16:51, Roger Calnan wrote: please review straightforward fix in the javadoc for javax.net.ssl.SSLSession.removeValue Thanks, Roger *https://bugs.openjdk.java.net/browse/JDK-8179943 Typo in

Re: RFR: 8214532,Update RFC 2459 references in javadoc to RFC 5280

part1-00.txt" to RFC 5280. * X509CertImpl 67 * * can be referenced in RFC 5280. remove extra '*'. --Sean On 12/19/18 6:47 AM, Seán Coffey wrote: Some doc edits to update RFC 2459 to 5280. I've updated the relevant section numbers where necessary. No edits to Java SE specification docs.

RFR: 8214532,Update RFC 2459 references in javadoc to RFC 5280

Some doc edits to update RFC 2459 to 5280. I've updated the relevant section numbers where necessary. No edits to Java SE specification docs. I've taken the opportunity to put a space in some "RFC" references also as it seems to be preferred approach. I've removed a paragraph in

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

whoops: latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v4/webrev/ Regards, Sean. On 03/12/18 17:10, Seán Coffey wrote: The CSR related to this change has been approved. I made further edits to update the DNSName comment code to reference RFC 5280 rather than

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

and bad data set also. A follow on bug has been logged to update all references of RFC 2459 to RFC 5280 (JDK-8214532) Regards, Sean. On 27/11/18 14:27, Seán Coffey wrote: Thanks for the feedback Max. I'll ping Joe Darcy and check if a CSR is required for this type of change. I'll revert back

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

n=oid:1.2.3.4"); +testOK("", pre+"san6 -ext san=dns:1abc.com"); //begin with digit testOK("", pre+"san235 -ext san=uri:http://me.org,dns:me.org,oid:1.2.3.4;); Regards, Sean. On 27/11/18 01:29, Weijun Wang wrote: On Nov 26, 2018, at 11:15

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

est case like "a c.com". BTW, I assume you want to reuse this test for other sub-tasks of JDK-8054380? I see the @summary is more general. No other comments. Thanks Max On Nov 22, 2018, at 12:51 AM, Seán Coffey wrote: p.s I've updated the testcase to test the IOException message

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

p.s I've updated the testcase to test the IOException message for presence of "DNSName". Webrev updated in place. Regards, Sean. On 21/11/18 15:42, Seán Coffey wrote: Thanks for the comments Bernd. Comments inline.. On 16/11/18 21:27, Bernd Eckenfels wrote: Hello Sean, I was on

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

regards, Sean. Gruss Bernd -- http://bernd.eckenfels.net ---- *Von:* Seán Coffey *Gesendet:* Freitag, November 16, 2018 5:15 PM *An:* Bernd Eckenfels; security-dev@openjdk.java.net *Betreff:* Re: RFR: 8213952: Relax DNSName restrict

Re: RFR: 8210838: Override javax.crypto.Cipher.toString()

in the toString method. --Sean On 11/16/18 11:35 AM, Seán Coffey wrote: On 16/11/18 16:16, Sean Mullan wrote: On 11/16/18 9:04 AM, Seán Coffey wrote: That's a good example and point Max. How does this revision look ? http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ 2832

Re: RFR: 8210838: Override javax.crypto.Cipher.toString()

On 16/11/18 16:16, Sean Mullan wrote: On 11/16/18 9:04 AM, Seán Coffey wrote: That's a good example and point Max. How does this revision look ? http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ 2832 * This implementation returns a String containing the transformation

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

/webrev.8213952.v2/webrev/ regards, Sean. Gruss Bernd -- http://bernd.eckenfels.net *Von:* security-dev im Auftrag von Seán Coffey *Gesendet:* Freitag, November 16, 2018 12:25 PM *An:* OpenJDK Dev list *Betreff:* RFR: 8213952

Re: RFR: 8210838: Override javax.crypto.Cipher.toString()

() method. --Max On Nov 16, 2018, at 10:04 PM, Seán Coffey wrote: That's a good example and point Max. How does this revision look ? http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ Regards, Sean. On 16/11/18 03:35, Weijun Wang wrote: Signature's toString looks like public String

Re: RFR: 8148188: Enhance the security libraries to record events of interest

/11/18 21:09, Seán Coffey wrote: Hi Sean, comments inline.. On 13/11/2018 18:53, Sean Mullan wrote: Looking good, a couple of comments/questions: * src/java.base/share/classes/java/security/Security.java The isJdkSecurityProperty method could return false positives, for example there may

Re: RFR: 8210838: Override javax.crypto.Cipher.toString()

; } Maybe you can add some similar info. In fact, it looks like you can extract the debug output at the end of each init() methods into a new toString() method. Thanks Max On Nov 16, 2018, at 12:35 AM, Seán Coffey wrote: A simple enhancement to override toString() for javax.crypto.Ciph

RFR: 8213952: Relax DNSName restriction as per RFC 1123

Looking to make an adjustment to DNSName constructor to help comply with RFC 1123 https://bugs.openjdk.java.net/browse/JDK-8213952 http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ regards, Sean.

RFR: 8210838: Override javax.crypto.Cipher.toString()

A simple enhancement to override toString() for javax.crypto.Cipher class https://bugs.openjdk.java.net/browse/JDK-8210838 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ regards, Sean.

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Thanks for the comments Weijun. As per other review thread, I'm now recording all properties set via Security.setProperty(String, String). regards, Sean. On 14/11/2018 01:11, Weijun Wang wrote: Confused. Aren't all Security properties security-related? This is not about normal system

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Erik, comments inline.. On 08/11/18 15:12, Erik Gahlin wrote: Hi Sean, I think we could still call the event "jdk.SecurityPropertyModification", but add a @Description that explains that events are only emitted for the JDK due to security concerns. If we at a later stage want to include

Re: Additional debug log message in KeyTab

of a simple edit to an existing test. regards, Sean. Assuming it's just of the form if (debug) { System.out.println(...);; } Cheers, Lars <https://openjdk.java.net/contribute/> On Wed, Nov 7, 2018 at 1:44 PM Seán Coffey <mailto:sean.cof...@oracle.com>> wrote: Looks like a r

Re: Additional debug log message in KeyTab

Looks like a reasonable minor enhancement to me. To contribute, you'll need to sign the OCA first. More information at : https://openjdk.java.net/contribute/ Regards, Sean. On 07/11/18 11:40, Lars Francke wrote: Hi, I have to preface this by saying that this would be my first contribution

Re: RFR: 8148188: Enhance the security libraries to record events of interest

/ Regards, Sean. On 17/10/18 11:25, Seán Coffey wrote: I'd like to re-boot this review. I've been working with Erik off thread who's been helping with code and test design. Some of the main changes worthy of highlighting : * Separate out the tests for JFR and Logger events * Rename some events

Re: RFR [12]: 8195793: Remove GTE CyberTrust Global Root

Looks fine. Regards, Sean. On 18/10/18 16:04, Sean Mullan wrote: Please review this change to remove the GTE CyberTrust Global Root from the cacerts keystore. This root is expired and all certificates that chain back to this root have expired. Note that retaining roots past their expiration

Re: Upgrade to RSAKeyGenParameterSpec.F4 for RSA Keypair generation test?

Hi Xin, looks like a reasonable backport candidate for jdk8u. I guess the changeset will apply cleanly once you correct the paths. You should have no problem with a push request on jdk8u-dev : http://openjdk.java.net/projects/jdk8u/approval-template.html Regards, Sean. On 18/10/18 23:34,

Re: RFR[12] JDK-8212562: To remove lib/security from test/jdk/TEST.groups

Looks fine to me. Regards, Sean. On 17/10/18 08:03, sha.ji...@oracle.com wrote: Hi, test/jdk/lib/security doesn't exist, so this directory could be removed from jdk_security3 diff -r f54dcfc5a5f8 test/jdk/TEST.groups --- a/test/jdk/TEST.groupsFri Oct 05 15:12:37 2018 -0700 +++

Re: RFR: 8148188: Enhance the security libraries to record events of interest

is dependent on the JDK-8203629 enhancement being integrated. Regards, Sean. On 10/07/18 13:50, Seán Coffey wrote: Erik, After some trial edits, I'm not so sure if moving the event & logger commit code into the class where it's used works too well after all. In the code you suggested, the

Re: RFR: 8209862:CipherCore performance improvement

is optional): Lines 848, 915, and 969 are longer than 80 characters Line 1075: no space before ? character On 10/2/2018 1:51 PM, Seán Coffey wrote: Good points from Adam and Tony. I've taken them both on board. Sergey has already eliminated a lot of duplicate code but there was further

Re: RFR: 8209862:CipherCore performance improvement

:11 AM, Seán Coffey wrote: JDK-8207775 introduced some performance regressions in the ciphercore area. Sergey Kuksenko has been looking at this and has contributed the following patch: http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ bug report : https://bugs.openjdk.java.net/browse/JDK

RFR: 8209862:CipherCore performance improvement

JDK-8207775 introduced some performance regressions in the ciphercore area. Sergey Kuksenko has been looking at this and has contributed the following patch: http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 I've been reviewing

Re: RFR: JDK-8209129 :Further improvements to cipher buffer management

I made those minor edits in the end and pushed the changes. We should examine usage of Arrays.fill(passwd, '0') in other parts of the JDK as a follow up. regards, Sean. On 22/08/2018 23:01, Seán Coffey wrote: On 22 August 2018 19:22:49 IST, Ivan Gerasimov wrote: Hi Seán! Just a minor

Re: RFR: JDK-8209129 :Further improvements to cipher buffer management

appreciate it. '0' is used in other, similar, fill operations IIRC. Perhaps we can optimize such code across all security libs code via another JBS issue. Regards, Sean. > >With kind regards, > >Ivan > > >On 8/22/18 9:25 AM, Seán Coffey wrote: >> Thanks for reviewin

Re: RFR: JDK-8209129 :Further improvements to cipher buffer management

ove local copy 97 Arrays.fill(passwd, '0'); If passwd == null, line 97 would throw an NPE. Another good catch! updated webrev : http://cr.openjdk.java.net/~coffeys/webrev.8209129.v3/webrev/ regards, Sean. Otherwise fine. Thanks Max On Aug 17, 2018, at 12:53 AM, Seán Coffey wro

Re: RFR: JDK-8209129 :Further improvements to cipher buffer management

Ping. I'd like to push on with this review. Regards, Sean. On 16/08/18 17:53, Seán Coffey wrote: Find new webrev here Max : http://cr.openjdk.java.net/~coffeys/webrev.8209129.v2/webrev/ regards : MD4.java: 110 void implReset() { Add @Override. There's a whole bunch

RFR: 8u-dev : 8206911: javax/xml/crypto/dsig/GenerationTests.java fails in 8u-dev

This test is currently on the ProblemList for solaris-all in jdk8u-dev. The test can fail on Solaris installs where the native pkcs11 library might not be fully patched. I've modified the testcase to allow for such failure and to re-run with the SunPKCS11-Solaris Provider removed. Testing

RFR: JDK-8208675: Remove legacy sun.security.key.serial.interop property

"sun.security.key.serial.interop" is an old JDK 1.4 -1.5 interoperability property. It can be safely removed now. JBS report : https://bugs.openjdk.java.net/browse/JDK-8208675 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8208675/webrev/ regards, Sean.

  1   2   3   >