Looks good.
--Sean
On 11/29/18 9:19 PM, Weijun Wang wrote:
Webrev updated at
https://cr.openjdk.java.net/~weijun/8214179/webrev.01/
Very glad to remove the change of Resources.java.
Thanks
Max
On Nov 30, 2018, at 3:36 AM, Sean Mullan wrote:
On 11/26/18 8:30 PM, Weijun Wang wrote
This looks fine to me.
--Sean
On 12/2/18 6:23 AM, Weijun Wang wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8214513/webrev.00/
It's now able to read the wrong PBES2-params encoding created by JDK before JDK
11.
Thanks
Max
I haven't reviewed all of this, but had a couple of comments so far:
- VerificationProvider.java
77 // the provider. Otherwise, create a temporary map and use a
This comment is now stale so it needs to be removed/updated.
- Provider.java
You removed synchronized from several of the me
Please review this change to Distrust TLS server certificates anchored
by Symantec Root CAs. Although the restrictions won't kick in until
after 12 GA, the fix touches code that validates certificate chains, so
getting this into 12 now will provide more assurance that the chain
validation code
an
Gruss
Bernd
--
http://bernd.eckenfels.net
*Von:* security-dev im Auftrag
von Sean Mullan
*Gesendet:* Freitag, Dezember 7, 2018 7:03 PM
*An:* security Dev OpenJDK
*Betreff:* RFR (12): 8207258: Distrust TLS server
On 12/7/18 2:16 PM, Bernd Eckenfels wrote:
Actually I was referring to the property name in the issue, did not
notice that the description differs from the patch, sorry.
Ah, sorry about that, that was old information, I need to update the JBS
issue ... will do that.
--Sean
Gruss
Bernd
--
On 12/6/18 8:27 AM, Weijun Wang wrote:
Hi All
Currently, I have 4 code changes out for review and I wish they can make JDK 12
(RDP1 is 12/13)
8076190: Customizing the generation of a PKCS12 keystore
https://cr.openjdk.java.net/~weijun/8076190/webrev.05/
* java.security
1124 # file. Th
,
Sean
No other comment.
Thanks,
Max
On Dec 8, 2018, at 12:02 AM, Sean Mullan wrote:
Please review this change to Distrust TLS server certificates anchored by
Symantec Root CAs. Although the restrictions won't kick in until after 12 GA,
the fix touches code that validates certificate c
On 12/11/18 10:38 AM, Baesken, Matthias wrote:
File paths are, in general, always something that demands extra scrutiny
as it can be the source of security issues (privacy leaks, traversal
attacks, etc). It's not just me that thinks that way, you can do a
search on the Internet and find lots of r
76190/webrev.05
Thanks
Max
On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote:
On 10/1/18 8:02 PM, Weijun Wang wrote:
On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote:
Looks good. After you update the CSR with these changes, I can review it.
Sure.
How do you think of the following change? Sh
On 12/12/18 10:57 AM, Weijun Wang wrote:
Thanks. Will you please also take a look at the release note
athttps://bugs.openjdk.java.net/browse/JDK-8215293?
I'm not sure about including the second sentence: "In particular, the
algorithm for certificate protection and MacData can be set to "NONE"
On 12/14/18 1:57 PM, Nico Williams wrote:
On Fri, Dec 14, 2018 at 02:09:50PM +, Bernd Eckenfels wrote:
Maybe a comment should point to the description of this pattern (if it
applies):
https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5
+1
Do document what initialized/chec
Update the copyright date. Otherwise looks fine.
--Sean
On 12/18/18 2:21 AM, Alan Bateman wrote:
This looks okay to me
(cc'ing security-dev as that is where the smart card I/O API is maintained)
On 18/12/2018 05:23, Priya Lakshmi Muthuswamy wrote:
Hi,
Kindly review the changes for
https:/
Looks good.
--Sean
On 12/17/18 7:41 PM, Valerie Peng wrote:
Any one has time to review this straightforward fix? Details on cause
and fix is elaborated in the link below:
Bug: https://bugs.openjdk.java.net/browse/JDK-8214096
Webrev can be found at
http://cr.openjdk.java.net/~valeriep/821409
On 12/17/18 10:14 PM, Weijun Wang wrote:
Hi Valerie,
Please put lines 87 and 100 into the if-not-null block. Otherwise fine.
Do you think we can enhance the Signature::setParameter method and claim a null
parameter is not meaningful at all and should not have any effect on the
internal state
Looks good, although I think someone from the HotSpot Group should also
review it.
On the bug, can you add the details below into the Description? Also,
since you have no regression test, you will need a noreg label (I guess
noreg-perf would be appropriate). Also, the bug says it is BlockedBy
On 12/18/18 11:33 AM, dean.l...@oracle.com wrote:
Also, the bug says it is BlockedBy JDK-8215205 which should probably
be removed.
That's because JDK-8215205 hasn't been pushed yet.
Ok, but isn't BlockedBy supposed to mean you can't fix this issue until
the one that it is blocked by is fix
On 12/18/18 2:00 PM, Sean Mullan wrote:
On 12/18/18 11:33 AM, dean.l...@oracle.com wrote:
Also, the bug says it is BlockedBy JDK-8215205 which should probably
be removed.
That's because JDK-8215205 hasn't been pushed yet.
Ok, but isn't BlockedBy supposed to mean you can&#
Just a couple of minor comments:
* DNSName
184 * draft-ietf-pkix-new-part1-00.txt: DNSName restrictions are
expressed as foo.bar.com.
Change "draft-ietf-pkix-new-part1-00.txt" to RFC 5280.
* X509CertImpl
67 * * can be referenced in RFC 5280.
remove extra '*'.
--Sean
On 12/19/18 6:
On 11/26/18 8:32 PM, Weijun Wang wrote:
Ping
I made a few tweaks to the title and wording.
On Nov 15, 2018, at 9:24 AM, Weijun Wang wrote:
On Nov 15, 2018, at 3:53 AM, Adam Petcher wrote:
This looks good to me, though I made a couple of trivial editorial changes.
It's fine as is, bu
Looks fine. I think pushing to JDK 13 is fine for now.
--Sean
On 12/20/18 8:57 PM, Weijun Wang wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8215769/webrev.00/
It's currently P4 because I don't think many people import pkcs12 files from
Firefox to Java, and even if s
On 12/21/18 9:50 AM, Weijun Wang wrote:
I think it is ok to use secp384r1 in the release note even though it is the
default for -keysize 384.
OK, I'll use it. And I've just added another sentence that we recommend using
-groupname.
Looks good now.
--Sean
Please review this change to the Java Security Standard Algorithm Names
specification [1] to clarify that standard names that are defined in
later versions of SE are also supported in prior versions, as long as
the applicable Security APIs are also supported.
Please see the CSR for the motivat
Hello,
On 1/15/19 4:03 AM, Andrew Leonard wrote:
Re-posting this question..
Isn't the "certificate_authorities" extension mandatory for TLS1.3?
The text in question says "SHOULD" and not "MUST" [1]. So while it is
very desirable, I would not categorize this as a mandatory requirement.
_h
On 1/15/19 10:24 AM, Martin Balao wrote:
Hi,
Can I have a review for "JDK-8217088 - Disable JDK-6913047 fix
(SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in
getNativeKeyInfo)" [0]?
* http://cr.openjdk.java.net/~mbalao/webrevs/8217088/8217088.webrev.00/
This looks fine. Please add
On 1/15/19 11:20 AM, Sean Mullan wrote:
On 1/15/19 10:24 AM, Martin Balao wrote:
Hi,
Can I have a review for "JDK-8217088 - Disable JDK-6913047 fix
(SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in
getNativeKeyInfo)" [0]?
* http://cr.openjdk.java.net/~mbalao/webrevs/82170
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: https://bugs.openjdk.java.net/browse/JDK-8216280
For some background, the JDK will stop trusting TLS Server certific
This is a nice cleanup. Just a couple of comments:
- Update copyrights now that it is 2019
- For the test, is the source code always guaranteed to be there? I was
not sure if that was a requirement. Or does the test still pass if it
can't find the source code?
Thanks,
Sean
On 12/27/18 3:11
ay be documented
in release notes or in a separate document such as the JDK Security
Providers document."
Thanks,
Sean
[1] https://bugs.openjdk.java.net/browse/JDK-8215320
On 1/2/19 4:37 PM, Iris Clark wrote:
Hi, Sean.
These changes look good.
Thanks,
iris
-Original Message-----
From: S
On 1/17/19 9:23 PM, Weijun Wang wrote:
On Jan 18, 2019, at 2:22 AM, Sean Mullan wrote:
This is a nice cleanup. Just a couple of comments:
- Update copyrights now that it is 2019
Will change.
- For the test, is the source code always guaranteed to be there? I was not
sure if that was
Hi Christoph,
Yes, this indeed looks like a bug. The jdk.tls.disabledAlgorithms
security property probably should not restrict suites that are not
negotiable like TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
Please feel free to file a bug or else Sean Coffey or I can do that on
your behalf tomorrow. T
Actually a bug for this has just been filed by SAP:
https://bugs.openjdk.java.net/browse/JDK-8217579. Since it came in via
webbugs, it has been initially marked Confidential. We can probably just
use this bug. I'll copy in more details and open it up.
--Sean
On 1/22/19 4:46 PM, Sean M
I don't think you really need to run the test with the othervm flag,
unless you are concerned other tests may be setting this property and
(incorrectly) not running in a separate VM, which would be a bug in my
opinion. Well, then maybe you should run it in othervm just in case.
Otherwise, looks
This fixes a regression introduced by the recent change to disable the
TLS NULL cipher suites [1]. This accidentally also disabled the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the name is
decomposed by the algorithm constraints checking code it has NULL for
its different part
the review.
--Sean
--Jamil
On 1/28/2019 10:26 AM, Sean Mullan wrote:
This fixes a regression introduced by the recent change to disable the
TLS NULL cipher suites [1]. This accidentally also disabled the
TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite because when the name
is decomposed by
we have
more of those ciphers.
Ok, thanks for the review.
--Sean
Gruss
Bernd
--
http://bernd.eckenfels.net
*Von: *Sean Mullan <mailto:sean.mul...@oracle.com>
*Gesendet: *Montag, 28. Januar 2019 20:26
*An: *security Dev OpenJDK <mailto:security-dev@openjdk.java.net>
*Betreff: *
You should also update the date in the VERSION file.
--Sean
On 1/28/19 8:02 PM, Weijun Wang wrote:
Please review the change at
https://cr.openjdk.java.net/~weijun/8217690/webrev.00/
Thanks,
Max
CheckCipherSuites.java
116 // List of enabled cipher suites when the "crypto.policy" security
typo: s/enabled/supported/
(I realized that typo after I had already pushed the fix to JDK 13, but
better to just fix it here now).
Otherwise looks good.
--Sean
On 1/31/19 8:36 AM, Langer, Chr
Looks good -- I added my name as Reviewer.
--Sean
On 1/28/19 1:46 PM, Xuelei Fan wrote:
Hi,
Could I get the CSR reviewed:
CSR: https://bugs.openjdk.java.net/browse/JDK-8217907
and here is the proposed release note:
https://bugs.openjdk.java.net/browse/JDK-8217911
If you are using this e
On 2/6/19 4:51 PM, Open eSignForms wrote:
I have a test version of the code that can run standalone and shows the
bug. I'm not sure how best to transfer this information to the forum
for those to play with, but it is included below.
Thanks, I can reproduce the issue now. I will need to debug
Looks good to me.
--Sean
On 2/3/19 9:44 AM, Weijun Wang wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8180569/webrev.00
I've combined ktarg.sh, ktmissing.sh, and ktzero.sh into KtabZero.java.
rcache_usemd5.sh is renamed to ReplayCacheTestProcWithMD5.java. The test ha
Hi Andi,
TLS/JSSE topics are best discussed on the security-dev alias, so I am
copying that list for more discussion and -bcc-ing core-libs-dev.
--Sean
On 2/11/19 3:29 PM, Andi Mullaraj wrote:
Hi java-core community,
I have been directed to this channel to discuss matters related to Java
pe
Looks good, pretty straightforward cleanup.
--Sean
On 2/5/19 1:44 PM, Xuelei Fan wrote:
Hi,
Could I have the update reviewed?
http://cr.openjdk.java.net/~xuelei/8217835/webrev.00/
With this update, the experimental FIPS 140 compliant mode is removed
from the SunJSSE provider. As the SunJ
modified version of the test case to the bug report
which no longer throws an Exception. Let me know if this is an
acceptable workaround. Double-check the namespaces that I used to make
sure they are correct.
--Sean
On 2/7/19 11:23 AM, Open eSignForms wrote:
On 2/7/19 7:49 AM, Sean Mullan
Looks good.
--Sean
On 2/12/19 10:31 PM, Weijun Wang wrote:
The -genkeypair command mistakenly lists -destalias in its option table.
Here is the simple patch:
*diff --git
a/src/java.base/share/classes/sun/security/tools/keytool/Main.java
b/src/java.base/share/classes/sun/security/tools/keyto
s of how this bug is addressed.
Please send over the modified test case and I'll take a look.
It is attached to the bug report in the Attachments section:
https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you download
the one I added yesterday).
--Sean
Thanks!
David
On 2/12/19 2
On 2/11/19 2:32 PM, Xuelei Fan wrote:
Hi,
Could I get the update reviewed?
http://cr.openjdk.java.net/~xuelei/4919790/webrev.00/
721 alert = Alert.UNSUPPORTED_CERTIFCATE;
Can we fix this typo while we are cleaning this up?
s/CERTIFCATE/CERTIFICATE/
Also, I was a bit
="#Payload_Reference_ID">descriptiontext/htmlId="OpenESignForms_Seal_ID"
Target="#OpenESignForms_Seal">xmlns:ns0="http://open.esignforms.com/XMLSchema/2011";
ns0:DeploymentHostAddress="192.1.1.1"
xmlns:ns1="http://open.esignforms.
rties_ID"
xmlns="http://uri.etsi.org/01903/v1.1.1#";>2019-02-13T11:01:22-08:00ns0:ObjectReference="#Payload_Reference_ID">descriptiontext/htmlId="OpenESignForms_Seal_ID"
Target="#OpenESignForms_Seal">xmlns:ns0="http://open.esignforms.com/XM
On 2/14/19 2:20 PM, Jamil Nimeh wrote:
Whoops, forgot to look at RFC 6961. Over there, both revoked and
structural failures are both supposed to yield
bad_certificate_status_response alerts. I think what we have is
conformant with the spec.
Ok, thanks for checking, let's leave the code as i
On 2/14/19 2:38 PM, Xuelei Fan wrote:
Good catch! Here is the updated webrev:
http://cr.openjdk.java.net/~xuelei/4919790/webrev.01/
Looks good.
--Sean
ls verification as the two. I'm guessing
that the verification digest is correct when using multiple namespaced
objects/references, but the signing digest is not since it doesn't
include the 'xades' namespace declaration.
This seems to hold true for Java 8, 10 and 11. Th
On 2/14/19 5:54 PM, Joe Wang wrote:
his is the ASCII code for a carriage return, encoded in XML. I don't
know why that behavior is different in JDK 11. This would be a
question for the XML developers. I have copied Joe Wang, to see if he
might know.
Hi Sean,
There hasn't been functional chan
This probably should have been done a while ago, but these interfaces
are both good examples of functional interfaces, so adding the
annotation is still justified (and simple).
CSR: https://bugs.openjdk.java.net/browse/JDK-8219145
(Diffs are also in the CSR).
Thanks,
Sean
On 2/20/19 1:41 PM, Xuelei Fan wrote:
ping ...
I took a quick look, but not enough time to understand the full context.
The exception in the UnparseableExtension can be useful to get a stack
trace later of why it could not be parsed. Did you think of any other
way you can fix this?
--Sean
In the Problem section:
"This internal package is not exported in the java.base module, and
applications cannot use them directly any more."
That's not quite true. It is not exported but strong encapsulation is
not yet enabled by default at runtime so by default the APIs are still
accessible
On 2/20/19 2:28 PM, Xuelei Fan wrote:
On 2/20/2019 10:52 AM, Sean Mullan wrote:
On 2/20/19 1:41 PM, Xuelei Fan wrote:
ping ...
I took a quick look, but not enough time to understand the full
context. The exception in the UnparseableExtension can be useful to
get a stack trace later of why
On 2/20/19 10:07 PM, Xuelei Fan wrote:
On 2/20/2019 12:21 PM, Sean Mullan wrote:
In the Problem section:
"This internal package is not exported in the java.base module, and
applications cannot use them directly any more."
That's not quite true. It is not exported but strong e
In JDK 11, we included an updated version of Apache Santuario (which the
JDK XML Signature implementation is based on) [1]. This contained a
newer XML marshalling implementation, which has caused a couple of
serious regressions (this one and JDK-8218629 [2]).
After unsuccessfully trying to pat
The diffs seem out of date. The @Deprecated annotations already have
@since="9".
There are a few JSSE APIs that reference these deprecated APIs that
should also be marked forRemoval and included in the CSR:
HandshakeCompletedEvent.getPeerCertificateChain()
SSLSession.getPeerCertificateChain()
(I'd suggest cross-posting to net-dev since some classes in the
networking area are also changed).
- AbstractDelegateHttpsURLConnection
It might be less risky to leave the methods as public just in case some
code out there is using them (even though they are not supposed to).
The rest of thi
AbstractDelegateHttpsURLConnection updated):
http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/
Thanks,
Xuelei
On 2/25/2019 1:55 PM, Sean Mullan wrote:
(I'd suggest cross-posting to net-dev since some classes in the
networking area are also changed).
- AbstractDelegateHttpsURLConnection
It might be less
Looks good.
--Sean
On 3/1/19 2:17 PM, Xuelei Fan wrote:
Hi,
Could I have the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8219994/webrev.00/
In my previous update for JDK-8215430 (removing the internal
com.sun.net.ssl package), I missed to update
java/lang/SecurityManage
hat code is not using XMLUtils, it is not checking
the linebreaks property to see if linebreaks should be inserted
(com.sun.org.apache.xml.internal.security.ignoreLineBreaks). Let me fix
that to use XMLUtils and I'll follow up with another webrev.
Thanks,
Sean
Thanks,
Max
On Feb 26, 20
Updated webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.01/
Changes:
- Added DOMCryptoBinary.java
- Changed Base64 calls to XMLUtils in DOMKeyValue, DOMPGPData,
DOMReference, DOMSignedInfo, DOMX509Data, and DOMXMLSignature
Thanks,
Sean
On 3/4/19 8:33 AM, Sean Mullan
Please review this fix to a regression introduced in JDK 9. An
application run with a SecurityManager and using a JDK that is accessed
over the network using a UNC path fails to startup and throws an
InternalError.
The fix is to load default.policy as a regular File rather than a URL
(URLs ar
Hi Xuelei,
In the Specification section, I think it would be useful to note which
cipher suites are forward secret and which are not. Otherwise, it is
difficult to see what has changed, since there are so many supported
suites. Perhaps in parentheses, ex:
TLS_AES_128_GCM_SHA256 (forward secr
On 3/6/19 4:55 AM, Severin Gehwolf wrote:
On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
It looks like this is JDK-8214418 - which has been fixed
in 12.0.1 b03 and 13-ea b04.
Is there any reason why JDK-8214418 is not public?
"You can't view this issue"
There are internal hostnames
licyUtil::getInputStream can always call url.openStream() now. I've
added core-libs-dev@o.j.n, maybe someone there can give a clear answer.
Thanks,
Max
On Mar 6, 2019, at 3:53 AM, Sean Mullan wrote:
Please review this fix to a regression introduced in JDK 9. An application run
with
-bcc net-dev
Copying security-dev as TLS 1.3 topics are more appropriate for that
mailing list.
--Sean
On 3/10/19 3:24 PM, ra...@web.de wrote:
Dear,
the Java TLS 1.3 implementation supports middlebox compatibility (e.g.
sends a non-empty session id and a ChangeCipherSpec message). Out of
i
Looks good, but a couple of comments:
In the Solution section, it says: "Applications can change the behavior
with the existing SSLParameters.setUseCipherSuitesOrder() method."
I think you should be more clear that this means applications can change
the order of the server's preferred cipher
On 3/12/19 1:12 PM, Xuelei Fan wrote:
On 3/12/2019 6:05 AM, Sean Mullan wrote:
Looks good, but a couple of comments:
In the Solution section, it says: "Applications can change the
behavior with the existing SSLParameters.setUseCipherSuitesOrder()
method."
I think you should be
Looks fine to me.
--Sean
On 3/11/19 6:31 AM, Weijun Wang wrote:
Hi Jon,
Please take a look at the patch below.
*diff --git
a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java
b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java*
*---
a/src/j
My best guess is that https://bugs.openjdk.java.net/browse/JDK-8214418
is the cause.
Xuelei, would you have time to look at this?
Thanks,
Sean
On 3/13/19 2:31 AM, Norman Maurer wrote:
Is there anything else I can do to have anyone look into this?
I just want to make sure this does not fall t
There should also be a release note issue filed for this change.
--Sean
On 3/12/19 11:18 PM, Xuelei Fan wrote:
On 3/12/2019 7:57 PM, Valerie Peng wrote:
Please review the CSR at:
https://bugs.openjdk.java.net/browse/JDK-8220549
I added myself as reviewer.
Webrev updated in place for this n
Hi Bruce,
First, thank you for your interest in JGSS and providing feedback.
Unfortunately, we can't review or accept patches or bug fixes in this
form from an external site.
I would suggest starting a discussion or summary of each of the issues
on this alias (without a proposed patch). We c
Jamil,
I think it might make sense to change the bug synopsis since it isn't
really ignoring the provider argument.
Maybe "Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation".
Thanks,
Sean
On 3/13/19 12:56 PM, Adam Petcher wrote:
Looks good. I added myself as a reviewer.
On the subje
Please add a noreg-self label to the bug since it is a test only fix.
--Sean
On 3/19/19 11:51 AM, Xuelei Fan wrote:
Hi Martin,
In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS"
should be disabled in the test case? It may help for further update if
RSASSA-PSS get support
Looks fine to me.
--Sean
On 3/20/19 2:32 PM, Adam Petcher wrote:
The regression test I added for JDK-8147502[1] has a minor bug. The test
only works for SunEC, so the calls to getInstance should specify SunEC
as the provider. Please review the fix for this test bug---it should
only take a mom
Just don't forget to add a noreg-self label to the bug...
--Sean
On 3/20/19 3:59 PM, Sean Mullan wrote:
Looks fine to me.
--Sean
On 3/20/19 2:32 PM, Adam Petcher wrote:
The regression test I added for JDK-8147502[1] has a minor bug. The
test only works for SunEC, so the calls to getIns
On 3/15/19 5:46 AM, Steve Groeger wrote:
Hi all,
Not sure whether something on this subject has been raised before but I
was unable to see anything in the mailing lists.
I don't think it has been discussed in any detail on this alias.
However, there are some other libraries and toolkits that
Looks good.
--Sean
On 3/21/19 2:49 PM, Xuelei Fan wrote:
Hi,
Could I have the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8221270/webrev.00/
The implementation of SSLSocketImpl.getHandshakeSession() uses two
synchronized over the same object. One should be sufficient.
Looks good.
--Sean
On 3/21/19 3:27 PM, Xuelei Fan wrote:
Hi,
Please review this update to problem list
sun/security/pkcs11/tls/tls12/TestTLS12.java, which is failing on
windows. The issue will be addressed in JDK-8221271.
Thanks,
Xuelei
$ hg diff test/jdk/ProblemList.txt
diff -r f10ca228
Hi Christoph,
On 3/21/19 6:20 AM, Langer, Christoph wrote:
Hi,
I recently came across a scenario where I wanted to use a self-built OpenJDK 8
in a maven build and it could not download artefacts due to missing root
certificates. I helped myself by replacing the cacerts with some other version
On 3/28/19 10:50 AM, Xuelei Fan wrote:
ping ...
Xuelei
On 3/21/2019 8:24 PM, Xuelei Fan wrote:
Hi,
Could I get the update reviewed?
http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/
With this update, server cipher suite preference will be used by
default for TLS handshaking in the S
It is currently possible to change the mappings in a serialized
java.security.Permissions object such that they no longer map correctly,
and Permissions.readObject won't detect this.
This change makes sure that for a deserialized Permissions object, the
permissions are mapped correctly to the
On 3/29/19 11:23 AM, Xuelei Fan wrote:
On 3/28/2019 12:33 PM, Sean Mullan wrote:
On 3/28/19 10:50 AM, Xuelei Fan wrote:
ping ...
Xuelei
On 3/21/2019 8:24 PM, Xuelei Fan wrote:
Hi,
Could I get the update reviewed?
http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/
With this update
Hi David,
These tests still seem somewhat VM-specific to me. We don't have any
*.jasm files in our tests area. Are these tests even relevant anymore
now that doPriv is all-Java? The previous bug fix that introduced these
tests was entirely in the hotspot code and had to do with default
method
Looks good. For future reference, can you add a link to the bug
(8221341) that introduced this regression?
--Sean
On 4/1/19 5:44 PM, Vladimir Kozlov wrote:
https://bugs.openjdk.java.net/browse/JDK-8221782
Recent 'Update Graal' JDK-8221341 added import
jdk.vm.ci.services.Services class to Hot
SocketPermission mapped to a FilePermission, for example.
Would it be better if I added a test for that?
--Sean
--Max
On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote:
It is currently possible to change the mappings in a serialized
java.security.Permissions object such that they no longer map
On 4/2/19 9:44 AM, Weijun Wang wrote:
On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote:
On 4/1/19 11:12 PM, Weijun Wang wrote:
I can understand the change in Permissions, but is there any difference in
PermissionsHash?
The key and value in the PermissionsHash map is always the same object
On 3/28/19 8:20 AM, Weijun Wang wrote:
Please take a review at
https://cr.openjdk.java.net/~weijun/8219861/webrev.01/
The ShowInfo::tls method is extracted from the JSSE Provider doc [1].
Noreg-other?
Seems ok, unless you want to add a test which adds or removes a suite
from the enabled
Looks good.
--Sean
On 4/3/19 11:15 PM, Weijun Wang wrote:
Webrev updated at
https://cr.openjdk.java.net/~weijun/8219861/webrev.02
The "Disabled by Default" lists are removed. They could be a little confused.
Thanks,
Max
On Apr 4, 2019, at 4:25 AM, Sean Mullan wrote:
On 3/
Looks good.
--Sean
On 3/28/19 10:50 AM, Xuelei Fan wrote:
ping ...
Xuelei
On 3/22/2019 7:51 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8163326/webrev.00/
With this update, the SunJSSE default enabled cipher suites preference
On 4/4/19 12:03 PM, Adam Farley8 wrote:
Hi All,
It's been pointed out that the issue in 8218618 affects JDK11 as well.
Is there any concern over backporting the fix?
No, if it is a straight backport and you haven't changed the fix, it
should be safe.
--Sean
Reviews and thoughts are appr
On 4/5/19 9:56 AM, Adam Farley8 wrote:
Hi Sean,
Sean Mullan wrote on 05/04/2019 14:48:14:
From: Sean Mullan
To: Adam Farley8 , security-dev@openjdk.java.net
Date: 05/04/2019 14:47
Subject: Re: RFR: JDK-8221990: JDK11 Backport for "Program fails
when using JDK addressed by UNC pat
wrote:
+1.
--Max
On Apr 2, 2019, at 9:55 PM, Roger Riggs wrote:
Hi Sean,
Typically, fixed serialization streams are encoded in the source
as byte arrays. That keeps binary content out of the repo
and provides a place for the comments.
Roger
On 04/02/2019 09:50 AM, Sean Mullan wrote:
On 4/2/19
d to Permission (" + v + ")");
610 }
611 }
If you are ok with that, I will push the fix.
--Sean
--Max
On Apr 6, 2019, at 1:30 AM, Sean Mullan wrote:
Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.01/
The serialized streams a
Two DocuSign root CA certificates will expire in 90 days. This is
causing failures in mach5 tier 2 and tier 4.
For now, I have modified the test to exclude these certificates until we
can contact the CA vendor to determine if we should remove or replace
them, and filed a follow-on issue to tra
Please review this fix to add temporary test exceptions for 4 more root
CA certificates that are due to expire soon and will start causing test
failures in the next couple of days.
bug: https://bugs.openjdk.java.net/browse/JDK-8222133
diffs:
$ hg diff
diff -r 0608ef3a7740 test/jdk/sun/securit
901 - 1000 of 2385 matches
Mail list logo
