Andrew,
Bug report just created :
JDK-8015275 : Resolve ambiguity in OCSPChecker & CrlRevocationChecker
Looks like both classes being modified for jdk8 don't exist any longer.
Regards,
Sean.
On 22/05/2013 19:25, Andrew Hughes wrote:
Webrev: http://cr.openjdk.java.net/~andrew/7u/webrev/
There
On 23/05/2013 10:45, Andrew Hughes wrote:
Original Message -
Andrew,
Bug report just created :
JDK-8015275 : Resolve ambiguity in OCSPChecker & CrlRevocationChecker
Looks like both classes being modified for jdk8 don't exist any longer.
Ah, even better. Seems they were removed in:
A JIRA system is now the system of record for OpenJDK issues.[1]
Work on getting that system open to external audience is ongoing. In the
meantime you can reference the bug via bugs.sun.com :
http://bugs.sun.com/view_bug.do?bug_id=7007966
regards,
Sean.
[1] https://blogs.oracle.com/darcy/ent
I'd like to move this testcase from our internal test repo and replace
the current "test/java/lang/SecurityManager/CheckPackageAccess.java"
testcase . It's a straightforward test to ensure that the package
restrictions enforced via the java.security file are those expected.
The testcase should
This is more or less a backport of the 8u20 code to the 7u-dev codebase.
This update fixes the SunJSSE problem that in FIPS mode, SunJSSE does
not work because keys cannot be extracted from crypto device.
Builds and tests are good.
http://cr.openjdk.java.net/~coffeys/webrev.8028192.jdk.7udev/web
Hopefully a member of the security team can help review this Ivan. It
looks good to me. I'm not sure if QA run any smart card tests on mac -
doesn't look like it! It could be worth following up with them to ensure
they add this to their test configurations.
One note on the 'noreg-existing' lab
Looking to backport this fix to the JDK 7u code line. The code was
refactored in JDK 8 but the change is still easily applied.
No issues with JPRT test run.
bug ID: https://bugs.openjdk.java.net/browse/JDK-8021804
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8021804.7u/webrev/
JDK 8 chang
Looking to backport this change to jdk7u-dev. Best security practice
would be to lower the preference ordering of RC4 ciphersuites. This is
work that's already in progress for JDK 8u and JDK 9.
For JDK 7u, I'd also like to introduce a compatibility flag which will
reverse this change in case l
A recent fix was introduced to preserve the behaviour of an old buggy
implementation of smartcardio Card.disconnect :
https://bugs.openjdk.java.net/browse/JDK-8049250
The old behaviour is not fully restored with this flag if a security
manager lacking sufficient permissions is present. This cou
see your point.
However, I am a little concerned that the security check isn't being
performed in the old buggy impl.
Is there any customer running into this, e.g. rely on the old behavior
with security manager enabled?
Valerie
On 7/22/2014 2:45 PM, Seán Coffey wrote:
A recent fix was introd
Ivan,
No need to convert the JDK 9 patch here. Lambda in JDK 8u!
I'm approving the jdk9 changeset for import into jdk8u-dev on condition
that it applies cleanly. If it doesn't get a peer code review.
regards,
Sean.
On 07/08/2014 13:21, Ivan Gerasimov wrote:
Hello!
May I ask for the approval
Looks good Vinnie. Thanks for handling this. One more comment from me..
I recently worked with a group who were reading the verbose security
messages when trying to debug an SSL connection issue. They weren't sure
if two-way SSL authentication was set up between the server and client.
Could we
I'd like to bring this change into 7u only. The 7u40 7109096 fix introduced
tighter conditions around Key.getFormat(). Some interoperability issues
have been seen for key generators that mightn't strictly honour the
ASN.1 data format of X509 keys.
As a result, I don't think the restriction was su
g a bug 8u/9 also.
regards,
Sean.
and open another bug to correct that in JDK 9.
Thanks,
Sean
On 09/02/2014 11:52 AM, Seán Coffey wrote:
I'd like to bring this change into 7u only. The 7u40 7109096 fix
introduced
tighter conditions around Key.getFormat(). Some interoperability issues
ha
https://bugs.openjdk.java.net/browse/JDK-8057076
As per earlier discussion today, a simple update to the exception
message used in JDK 9.
diff --git
a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
b/src/java.base/share/classes/sun/security/tools/keytool/CertAndKey
On some recent JPRT test jobs, I've noticed that the jdk_security3 test
target is taking 40+ mins on some systems. Looking closer at test times,
I see that sun/security/krb5 tests alone can take ~15-16 mins to run.
I'd like to separate those tests out into their own test target
(jdk_security4)
tests also there:
test/sun/security/krb5 \
test/sun/security/jgss \
test/com/sun/security/jgss \
test/javax/security/auth/kerberos \
Is that OK?
Thanks
Max
On 9/10/2014 1:10, Seán Coffey wrote:
On some recent JPRT test jobs, I've noticed that the jdk_security3
looking to push two fixes to jdk8u :
8052406: SSLv2Hello protocol may be filter out unexpectedly
This is a straight forward backport of the JDK 9. The testcase did require
one minor config adjustment :
pathToStores value updated to : "../../../../sun/security/ssl/etc";
8057813: Alterations to j
Thanks for tackling this one Vinnie. It'll certainly help better debug
environments
where several providers are available to perform similar crypto operations.
One minor suggestion might be to use a simple boolean to control whether
the engine provider info gets printed.
i.e. change "private st
Continuation of the security test target clean up for jdk7u.
7u doesn't have the test groups concept so I had to break down some
test targets to explicit directory names. Also found that the
javax/xml/crypto
was missing for 7u testing.
http://cr.openjdk.java.net/~coffeys/webrev.7u.8057813/webr
Iris is correct. This fix is in JDK 9 only. I'm not sure why you think
it's fixed in jdk8u.
Max - are you willing to pull this fix into the JDK 8u code line or
shall I ?
regards,
Sean.
On 30/09/2014 07:56, Koen Serry wrote:
Hi,
could anyone merge the code of jdk9 into jdk8 as supposedly d
On 01/10/14 01:38, Wang Weijun wrote:
On Oct 1, 2014, at 0:05, Seán Coffey wrote:
Iris is correct. This fix is in JDK 9 only. I'm not sure why you think it's
fixed in jdk8u.
Max - are you willing to pull this fix into the JDK 8u code line or shall I ?
Public holiday here. Can
Approved.
-Rob
On 30/09/14 18:46, Seán Coffey wrote:
Looking to backport this change from JDK 8u. JDK 8u changeset applies
cleanly.
bug report : https://bugs.openjdk.java.net/browse/JDK-8052406
changeset : http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ddba61b06470
regards,
Sean.
Valerie Peng (original author) is probably best suited to reviewing this
but I think she's out of the office the moment and back next week. Let's
hope we can get an update/review then.
regards,
Sean.
On 01/10/2014 16:11, Andrew Hughes wrote:
- Original Message -
- Original Messa
I should have prefixed my comments with point that this is a request for
review given the changes. Subject updated.
regards,
Sean.
On 01/10/2014 17:23, Seán Coffey wrote:
Turned out that I do need to make a change to this backport. The
testcase hadn't run initially on JPRT due to a new
Simple fix to the issue reported in the bug report. I've moved the
logging calls past the 'sa.initVerify(pk);" call.
bug : https://bugs.openjdk.java.net/browse/JDK-8031191
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8031191/webrev/
regards,
Sean.
I'm looking to backport this fix to JDK 7u code line. The fix applies
pretty much as is with the JDK 8 fix with the exception of not having to
deal with a ServiceCreds tgt variable (Krb5Util.java) which was only
introduced in JDK 8 for : 6355584: Introduce constrained Kerberos delegation
bug :
the coming 1-2 weeks.
regards,
Sean.
On 07/10/2014 11:40, Koen Serry wrote:
Hi,
sorry to be a bit of a nuisance, just for my info, were you able to
apply the patch in JDK8u ?
Thanks,
Koen
On 01/10/14 11:41, Seán Coffey wrote:
On 01/10/14 01:38, Wang Weijun wrote:
On Oct 1, 2014, at 0:05
Ping.
regards,
Sean.
On 02/10/2014 10:19, Seán Coffey wrote:
I should have prefixed my comments with point that this is a request
for review given the changes. Subject updated.
regards,
Sean.
On 01/10/2014 17:23, Seán Coffey wrote:
Turned out that I do need to make a change to this backport
Ping.
regards,
Sean.
On 02/10/2014 17:34, Seán Coffey wrote:
I'm looking to backport this fix to JDK 7u code line. The fix applies
pretty much as is with the JDK 8 fix with the exception of not having
to deal with a ServiceCreds tgt variable (Krb5Util.java) which was
only introduced in
Thanks for the code reviews Valerie.
Andrew - looks like you need to submit new review with 7169496. Note
that you still need to file for approval once code review is complete :
http://openjdk.java.net/projects/jdk7u/groundrules.html
I'm just being cautious on this one given the possible beha
are settings
on the Apache webserver that allow it to still accept DH keys of less
than 2048 bits. Is that the case ?
regards,
Sean.
On 08/01/15 19:08, Seán Coffey wrote:
Thanks for the code reviews Valerie.
Andrew - looks like you need to submit new review with 7169496. Note
that you still
Hi Peter,
security-dev is best mailing list to discuss this issue, I'm cc'ing that
list and bcc'ing off jdk7u-dev.
Are you hitting this issue with JDK 8 and later ? (I'll assume so) -
You've hit https://bugs.openjdk.java.net/browse/JDK-8039921
To aid compatibility, it's been decided to relax
Peter,
the issue you reference isn't a problem in jdk7u. - for the Oracle JDK
at least. The code snippet your refer to is from jdk8 source code. The
key length restriction was initially introduced as a side effect of this
fix in JDK 8 https://bugs.openjdk.java.net/browse/JDK-7044060
That sai
Looking for a review around this issue that came in as a reported
performance regression in NTLM proxy authentication. It turned out that
HttpsClients were being discarded after Proxy SocketAddress equality
tests failed. Lack of caching is expensive in terms for performance for
TLS and needless
Hi Jason,
I just spotted this thread now. Thanks for taking this on. I'd like to
do some testing with your new patch and get back to you tomorrow. Will
update then!
regards,
Sean.
On 13/02/2015 00:05, Jason Uh wrote:
Please review this change, which augments some of the debug statements
for
Jason,
thanks for taking this on. Your changes look fine to be and should help
the debugging experience. Some extra comments from me. Here's some
standard output that one sees (early in connection) from a standard TLS
connection attempt with verbose certpath logging :
certpath: PKIXCertPath
On 03/02/2015 09:26 AM, Seán Coffey wrote:
Jason,
thanks for taking this on. Your changes look fine to be and should help
the debugging experience. Some extra comments from me. Here's some
standard output that one sees (early in connection) from a standard TLS
connection attempt
http://cr.openjdk.java.net/~juh/8054037/02/
Looks good.
regards,
Sean.
On 03/03/2015 18:25, Jason Uh wrote:
Thanks for catching that. Here it is with the HandshakeMessage.java
changes.
I'll push with both bug IDs.
On 03/03/2015 01:25 AM, Seán Coffey wrote:
Jason,
I think you'
This issue was reported while debugging a pkcs11 issue. While I can't
reproduce it, the captured stack trace does show a deadlock issue. Fix
is to simply stop using the SessionManager class lock to record and
print the maxActiveSessions in use and replace it with a local lock.
bug: https://bug
Thanks Sean. Yes - I'll add those braces before pushing.
regards,
Sean.
On 27/03/2015 18:58, Sean Mullan wrote:
This looks fine, just one comment. Can you put braces around the if
debug statement on lines 117-118 (just to be safe).
--Sean
On 03/25/2015 09:52 AM, Seán Coffey wrote:
ustmanager
-Dcom.oracle.security.ucrypto.debug=true
-Djava.security.debug=all -Djsse.S
Probably the synopsis should be changed.
Brad
On 3/27/2015 12:05 PM, Seán Coffey wrote:
Thanks Sean. Yes - I'll add those braces before pushing.
regards,
Sean.
On 27/03/2015 18:58, Sean Mullan wrote:
Looks good.
Approved.
Regards,
Sean.
On 15/04/15 09:17, Artem Smotrakov wrote:
cc'ing [email protected]
Would you please approve this backport to 8u-dev?
The difference is:
- JDK 9 has a single java.security file, but JDK 8u has java.security
file for each generic platform, so each
FYI,
concerns from Darwin on the 8078439: 8048194 fixes.
regards,
Sean.
Forwarded Message
Subject:8078439: 8048194: possible bug in commit for these two fixes
Date: Wed, 20 May 2015 16:28:29 -0700
From: Darwin Felix
To: [email protected]
CC: darwi
Approved.
Regards,
Sean.
On 21/05/2015 07:46, Weijun Wang wrote:
Code change is fine.
Thanks
Max
On 5/21/2015 12:58 AM, Ivan Gerasimov wrote:
Hi!
The backport required some manual editing, thus I'm asking for a review
too.
Would you please review and approve backporting this fix?
BUGURL: h
Looking to resolve a recently reported issue where the P11ECKeyFactory
class has too much dependence on the SunEC provider. With some
reshuffling and creation of a new P11ECUtil class, I was able to remove
the call for lookup of SunEC Provider. The test picks up the regression
when running with
A regression has been discovered after JDK-8058547 was fixed in 8u60.
For now, I'm proposing we back the fix out from the jdk8u-dev forest and
plan a new fix. This is a straight-forward anti delta of 8058547
JDK 9 is not impacted since JDK-8055753 already removed this code.
bug : https://bug
e
On 6/5/2015 3:21 AM, Seán Coffey wrote:
Looking to resolve a recently reported issue where the
P11ECKeyFactory class has too much dependence on the SunEC provider.
With some reshuffling and creation of a new P11ECUtil class, I was
able to remove the call for lookup of SunEC Provider. The test
Looks good to me.. and is much easier to read now!
Regards,
Sean.
On 08/07/2015 16:35, Ivan Gerasimov wrote:
Hello!
We've got a request to fix javadoc for SecureRandom, so that the
example code will read
byte[] bytes = new byte[20];
instead of
byte bytes[] = new byte[20];
I took opportunity
On 08/07/2015 18:14, Ivan Gerasimov wrote:
On 08.07.2015 18:57, Seán Coffey wrote:
Looks good to me.. and is much easier to read now!
Thanks Seán for review!
I've missed some portion of update int the previous webrev.
Now, sending the whole changeset:
http://cr.openjdk.java.net/~ige
Bug report : https://bugs.openjdk.java.net/browse/JDK-8131665
Simple fix to improve the Error message for this scenario.
diff --git
a/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java
b/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java
--- a/src/java.base/share/cla
Hoping to improve some of the exception messaging that is thrown from
Ucrypto code. I'm hoping to tackle other components in the security
libraries on a case by case basis. Aim is to improve exception messages
and capture detail for end user where possible.
bug report : https://bugs.openjdk.ja
Hi Artem,
I'll let the main review to other reviewers but while we're here, can
you consider improving the original exception message that was seen in
this issue ?
In LDAPCertStore constructor :
} else {
throw new InvalidAlgorithmParameterException(
"parame
Looks good to me Ivan. Thanks for handling.
Some new exception messages need padding out as per efforts in 8133535
but I'll re-sync/rework my patch once your changes hit the repo.
Regards,
Sean.
On 03/09/2015 16:53, Ivan Gerasimov wrote:
Hello!
Would you please help review this fix, which a
With recent changes from (JDK-8132082) affecting the same ucrypto code,
I've re-based my patch. Here's the new webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9.v2/webrev/
Regards,
Sean.
On 24/08/2015 13:54, Seán Coffey wrote:
Hoping to improve some of the exception
On 08/09/2015 10:42, Ivan Gerasimov wrote:
Thanks, Seán!
On 08.09.2015 11:00, Seán Coffey wrote:
With recent changes from (JDK-8132082) affecting the same ucrypto
code, I've re-based my patch. Here's the new webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9.v2/webr
- removed unused field
- removed unused imports
Artem
On 09/02/2015 01:23 PM, Seán Coffey wrote:
Hi Artem,
I'll let the main review to other reviewers but while we're here, can
you consider improving the original exception message that was seen
in this issue ?
In LDAPCertStore c
Brad, Vinnie,
This is a forward port of 6998583 to JDK 7. Can you review ?
http://cr.openjdk.java.net/~coffeys/6998583/webrev.6998583.0/
Thanks,
Sean.
Makes sense Andrew. Will take into account before
pushing final changes.
regards,
Sean.
On 25/11/2010 00:31, Dr Andrew John Hughes wrote:
On 25 November 2010 00:29, Dr Andrew John Hughes
wrote:
On 22 November 2010 14:20, Vincent Ryan wrote:
Fix looks good Sean.
On 22/11/2010 13:50, Seán
Andrew,
this is a code review request for the recent SSLSocketImpl
issues that we've been working on.
7025227 SSLSocketImpl does not close the TCP layer socket if a close
notify cannot be sent to the peer
6932403 SSLSocketImpl state issue
http://cr.openjdk.java.net/~coffeys/7025227/webrev.00/
This is a forward port of http://bugs.sun.com/view_bug.do?bug_id=7024697
to jdk 7 & 8 releases.
Code change is identical to that made in jdk6.
http://cr.openjdk.java.net/~coffeys/webrev.7024697/
regards,
Sean.
This is a forward port to JDK 8 of a fix gone into jdk 5 and jdk6 releases.
It'll be ported to 7u shortly after jdk8.
Bug id is not public.
NTSystem() obtains a native Token instance for each constructor call.
This is unnecessary and Token instances should only be requested when
called for, i.e.
Should this test be set to run manually ?
5 mins is far too long for a jtreg unit test IMO.
regards,
Sean.
On 13/10/2011 02:52, Xuelei Fan wrote:
Looks fine to me.
Xuelei
On 10/13/2011 3:12 AM, Weijun Wang wrote:
Sorry, a new updated webrev
http://cr.openjdk.java.net/~weijun/7099399/web
thanks for raising this point Chris.
we certainly don't want any windows for such an attack. I'll revisit this.
regards,
Sean.
On 24/02/12 13:31, Christopher Meyer wrote:
Hi,
please correct me if I'm wrong, but the Changeset 5052 in ZoneInfoFile could
maybe draw an unexpected SideChannel at Sy
hold on,
the indexOf test will match with those ASCII format chars.
i.e
"/.\56/.\56/.\56/etc/passwd".indexOf("..") returns 1.
Is the fix still ok then [email protected]
regards,
Sean
On 24/02/12 14:09, Seán Coffey wrote:
thanks for raising this point Chris.
we
Looks good Sean. Thanks for taking care of jdk 8 changes.
Hopefully someone else can also review since I'm not an official jdk 8
reviewer.
regards,
Sean.
On 06/04/12 14:40, Sean Mullan wrote:
Hi Sean,
Can you please review the code changes for the following bugs:
7152564: Improve CodeSourc
This is a backport from jdk8 (minus the javadoc changes) to jdk7u
The same fix has also gone into a jdk6 update.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152564
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7152564.7u/
Regards,
Sean
The JDK has historically allowed builds without the javax.crypto package
src.
Bug fix 7058133 altered the bootclasspath for security library builds.
This fix simply allows the builds to continue if javax.crypto package is
not present. In such cases we append the jce.jar to bootclasspath.
I'v
Recently noticed that the 6424631 fix was not fully ported to the JDK 7
workspace. Porting the changes (to 8 & 7) so that no regression is seen
for users migrating to latest JDK families.
bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169257
webrev : http://cr.openjdk.java.n
/12 6:25 AM, Seán Coffey wrote:
Recently noticed that the 6424631 fix was not fully ported to the JDK 7
workspace. Porting the changes (to 8& 7) so that no regression is seen
for users migrating to latest JDK families.
bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169257
we
21/05/2012 17:04, Seán Coffey wrote:
Thanks Sean,
Further testing has thrown up a testcase failure. (recursion in Policy
setup) - This one skipped by me prior to logging RFR. Let me look into
it and get back with an updated webrev.
Regards,
Sean.
On 21/05/12 13:37, Sean Mullan wrote:
The ch
Requesting a review for the following issue :
http://bugs.sun.com/view_bug.do?bug_id=7179879
The SSLSocketImpl doesn't appear to handle the case where a connect
operation is cancelled
before an SSL session has begun (we simple ignore such a case)
Fix would be to honour the close call which in
Looking for a code review around the following perf. related backports
to JDK 7u8. The changesets didn't apply cleanly but there was no major
code differences encountered while porting.
Builds and security tests ran fine.
7107616: scalability blocker in javax.crypto.JceSecurityManager
jdk 8 ch
I was wondering the same. Is this sparc only or is solaris x86 impacted
also ?
regards,
Sean.
On 22/03/2013 10:00, Alan Bateman wrote:
On 22/03/2013 09:49, Weijun Wang wrote:
Please take a look at
http://cr.openjdk.java.net/~weijun/8010531/webrev.00/
The tests have been failed a lot rece
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
the code duplication.
On 10/1/2018 9: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 :
em 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 w
/
This code 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 c
Looks fine to me.
Regards,
Sean.
On 17/10/18 08:03, [email protected] 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
+++ b/test/jdk
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, L
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
Looks fine. I'll push this for you.
Regards,
Sean.
On 22/10/18 06:46, Jaikiran Pai wrote:
I noticed a typo in one of the SSL log messages, while looking into a
log file generated during a SSL handshake. Here's a trivial patch which
fixes the typo. I'm not a committer so will need help from some
.v7/webrev/
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 ev
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 t
the case 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:[email protected]>> wrote:
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 user
ents/X509ValidationEvent.java
47: remove blank line
* test/jdk/jdk/security/logging/TestTLSHandshakeLog.java
--Sean
On 11/6/18 3:46 AM, Seán Coffey wrote:
With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk
code.
Some modifications also made based on off-thread suggest
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 prope
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.
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.
initState;
}
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.c
28%3a59.png
Regards,
Sean.
On 14/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 pos
() 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
pub
ffeys/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: 82
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
transform
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/
DK-8207768
regards,
Sean.
Gruss
Bernd
--
http://bernd.eckenfels.net
--------
*Von:* Seán Coffey
*Gesendet:* Freitag, November 16, 2018 5:15 PM
*An:* Bernd Eckenfels; [email protected]
*Betreff:* Re: RFR: 8213952: Relax DNSNam
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 w
anywhere, please add a test 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 t
ot;san5 -ext san=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 No
1 - 100 of 320 matches
Mail list logo
