Please review these changes to update the security libraries to use sealed
classes. See JEP 409 for more details on sealed classes.
No CSR is required as all the changes are to internal classes. A few classes
that did not have subclasses were simply marked final instead of sealed.
On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard wrote:
>> Addition of a configure option --with-cacerts-src='user cacerts folder' to
>> allow developers to specify their own cacerts PEM folder for generation of
>> the cacerts store using the deterministic openjdk GenerateCacerts tool.
>>
>>
On Tue, 19 Oct 2021 19:48:23 GMT, Weijun Wang wrote:
>> The cacerts file is now a password-less PKCS12 file. This make sure old code
>> that uses a JKS KeyStore object can continuously load it using a null
>> password (in fact, any password) and see all certificates inside.
>
> Weijun Wang has
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote:
> The cacerts file is now a password-less PKCS12 file. This make sure old code
> that uses a JKS KeyStore object can continuously load it using a null
> password (in fact, any password) and see all certificates inside.
On Tue, 17 Aug 2021 03:59:15 GMT, Rajan Halade wrote:
> Removed the expiring root certificate.
Marked as reviewed by mullan (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5137
On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote:
> This CA had no code signing certificates issued so it is safe to remove it
> from cacerts truststore.
Marked as reviewed by mullan (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4851
On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
>
On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman wrote:
>> It includes both:
>> 
>
> Thanks for checking, I assumed that was the case so wondering if it
On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote:
> This is the security libs portion of the effort to replace
> archaic/non-inclusive words with more neutral terms (see JDK-8253315 for
> details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as
This change removes five root certificates with 1024-bit RSA public keys from
the system-wide `cacerts` keystore. These are older VeriSign and Thawte root CA
certificates which are no longer necessary to retain and should have minimal
compatibility risk if removed.
See the CSR for more
On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino
wrote:
>> This change removes the native elliptic curves library code; as well as, and
>> calls to that code, tests, and files
>> associated with those libraries. The makefiles have been changed to remove
>> from all source builds of the ec
On 6/14/19 11:33 AM, Weijun Wang wrote:
Here is the updated webrev
http://cr.openjdk.java.net/~weijun/8225392/webrev.01/
The only change is ordering in 'keytool -list' and its test.
Looks fine.
--Sean
Thanks,
Max
On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote:
On 6/14/19 1:49 AM
On 6/14/19 1:49 AM, Weijun Wang wrote:
BTW, something not related but similar: Do you like me to also sort aliases
alphabetically in the output of "keytool -list"?
Yes, I think that is useful.
--Sean
It might be useful to run older versions of keytool against the cacerts
binary you created - this would give you more assurance that your
hand-coded format is correct. I would also try various commands, etc.
--Sean
Thanks,
Max
On Jun 13, 2019, at 4:15 AM, Sean Mullan wrote:
On 6/12/19 4:0
Using the certificate's notBefore date as the KeyStore entry creation
date is misleading since many of these root certs were not integrated
into the JDK until after they were created by the CA. Can we somehow
extract the last revision time of each PEM file instead? That is more
aligned with
with instructions or a
code snippet so that the next time we add a cert we know what to include
at the top for consistency.
Thanks,
Sean
Thanks,
Max
p.s. `keytool -printcert` shows validity in local timezone. Does not look good
to me.
On May 31, 2019, at 6:51 AM, Sean Mullan wrote:
One
One suggestion is to put a printable form of the contents of the
certificate at the top of each of the PEM files. It would be nice as a
quick-look to see what is in the certificate. Of course, you can also
use keytool -printcert to do that, but if I am just perusing the source
code via a
On 12/5/17 12:01 PM, Volker Simonis wrote:
Hi Rajan,
'cacerts' is a binary file and I thought we have at least the
convention in the OpenJDK project that we don't want to check in
binary artefact's if possible.
One problem with 'cacerts' being a binary file is that we can not add
a license and
.01/
--Sean
Thanks,
Jan
On 17.8.2017 21:08, Sean Mullan wrote:
Please review this JDK 10 change to remove the deprecated classes in
com.sun.security.auth.** that have been previously marked with
forRemoval=true in JDK 9.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
I have
On Aug 18, 2017, at 3:08 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
Please review this JDK 10 change to remove the deprecated classes in
com.sun.security.auth.** that have been previously marked with forRemoval=true
in JDK 9.
webrev: http://cr.openjdk.java.net/~mullan/webrevs/81595
ean
Thanks
Max
On Aug 10, 2017, at 3:15 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
Max,
Could you please review the following CSR:
https://bugs.openjdk.java.net/browse/JDK-8186047
Thanks,
Sean
On 8/4/17 11:12 AM, Alan Bateman wrote:
On 04/08/2017 07:59, Jiri Vanek wrote:
Hello!
I'm packaging openjdk9 for Fedora, and following files:
jdk/lib/security/blacklisted.certs
jdk/lib/security/default.policy
Seems to be config files. Still, they are in lib/security, whether all
other
General: change the text of all of the links from "Java Cryptography
Architecture Standard Algorithm Name Documentation" (the old name) to
"Java Security Standard Algorithm Names Specification".
Looks good otherwise.
Thanks,
Sean
On 5/5/17 9:17 AM, Magnus Ihse Bursie wrote:
The Security
/default.policy
endif
Thanks. However, shouldn't that be "ifeq" and not "ifneq"?
--Sean
/Erik
On 2016-08-17 18:18, Sean Mullan wrote:
Please review this simple fix to append the solaris default.policy
file to the overall default.policy file.
Bug: https://bugs.openjdk.java.ne
Please review this simple fix to append the solaris default.policy file
to the overall default.policy file.
Bug: https://bugs.openjdk.java.net/browse/JDK-8164071
diff -r 551f7617b2c0 make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk Wed Aug 17 10:08:18 2016 +0800
+++
- src/java.base/share/classes/sun/security/tools/keytool/Resources.java
131 "operates on the cacerts keystore"}, // -cacerts
"operates" sounds a little odd. How about "access the cacerts keystore"
(so it is consistent with the warning below).
133 "Warning: use
Adding build-dev for review since there is one change to a Makefile in
the webrev below.
Thanks,
Sean
On 07/14/2016 04:05 PM, Sean Mullan wrote:
Please review this change to the default Policy provider implementation
to grant de-privileged module permissions by default even when
Weijun wrote:
On Nov 25, 2015, at 11:04 PM, Sean Mullan <sean.mul...@oracle.com> wrote:
The fix looks fine to me. For testing, can you create a test that uses a custom
java.security file with "#ifndef solaris-sparc" in it, and check whether the
property is used or not dependin
The fix looks fine to me. For testing, can you create a test that uses a
custom java.security file with "#ifndef solaris-sparc" in it, and check
whether the property is used or not depending on what system is being
tested?
--Sean
On 11/24/2015 06:10 AM, Magnus Ihse Bursie wrote:
On
Couple of minor comments on ProviderConfig.java
183: you can use the diamond operator for anonymous classes now
(PrivilegedAction). You could also use a lambda expression here but
I'll leave that up to you.
193: the braces around if (debug != null) are not indented properly
Looks fine
, Wang Weijun
weijun.w...@oracle.com
wrote:
On Jul 25, 2014, at 22:30, Sean Mullan sean.mul...@oracle.com
wrote:
http://cr.openjdk.java.net/~weijun/6997010/webrev.00/
4. *IMPORTANT*: In order to easily maintain platform-related entries,
every line (including the last line) in package.access
On 07/22/2014 10:28 PM, Wang Weijun wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/6997010/webrev.00/
The fix consolidates java.security-platform files into one with
#ifdef directives.
There are several major changes:
1. Creation of file is moved from CopyFiles
On 07/02/2014 01:02 AM, Wang Weijun wrote:
On Jul 2, 2014, at 12:48, David Holmes david.hol...@oracle.com wrote:
73 // Output sorted for eye pleasure.
?? eye pleasure
Well, it's easy for a human to locate one from a sorted output. Or maybe it's
because the old one is sorted and I
On 12/02/2013 05:05 PM, Sean Mullan wrote:
What I am not 100% sure is whether the 'j2' in those library names is
from Java 2. The 2 simply could have been a way to avoid naming
clashes. IBM's JDK includes a pkcs11 library named libjpkcs11.so. Also,
pkcs11 support and the libj2pkcs11.so library
On 11/29/2013 06:47 PM, Omair Majid wrote:
* Sean Mullan sean.mul...@oracle.com [2013-11-27 12:16]:
On 11/27/2013 10:46 AM, Wang Weijun wrote:
What security libs have j2 in their names?
libj2gss.so etc.
Any idea what the compatibility risk of removing the 2 would be?
This seems less
On 12/02/2013 04:50 PM, Phil Race wrote:
On 12/2/2013 1:28 PM, Sean Mullan wrote:
'j' sounds reasonable to me. However, I'm not really sure if the 'j2'
here is from 'j2se', 'j2re', or 'j2sdk', I would have to ask some
developers who did the original implementation. It could have been
simply
On 11/27/2013 03:41 AM, Alan Bateman wrote:
On 27/11/2013 00:29, David Holmes wrote:
On 27/11/2013 8:49 AM, mark.reinh...@oracle.com wrote:
Now that we've removed the old build system, can we please now
remove the last vestiges of Sun's pre-Java 5 naming scheme?
There are also a bunch of
On 11/27/2013 10:46 AM, Wang Weijun wrote:
What security libs have j2 in their names?
libj2gss.so etc.
Any idea what the compatibility risk of removing the 2 would be?
This seems less prominent because it doesn't say j2se, j2re or
j2sdk but I think it would be fine to rename these if
On 10/10/2013 05:57 AM, Erik Joelsson wrote:
Adding makefiles to make/tools is not needed for the new build. Either
remove those changes or make a complete port to the old build. I'm not
pushing for porting this to the old build at this point since missing
this will not cause the old build to
On 10/09/2013 05:14 AM, Erik Joelsson wrote:
Hello Sean,
On 2013-10-09 06:33, David Holmes wrote:
Hi Sean,
Not a full review.
On 9/10/2013 5:52 AM, Sean Mullan wrote:
Please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8007292
This bug requires build
Updated webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8007292/webrev.01/
Let me know if there are any more comments, otherwise I will plan to
push tomorrow.
Thanks,
Sean
On 10/09/2013 09:20 AM, Sean Mullan wrote:
On 10/09/2013 05:14 AM, Erik Joelsson wrote:
Hello Sean,
On 2013-10-09
Please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8007292
This bug requires build changes and a new build tool to add additional
restricted packages to the java.security file which are not part of
OpenJDK. These packages are only added when doing a build
On 09/17/2013 07:07 AM, Weijun Wang wrote:
Webrev updated to version 02 at
http://cr.openjdk.java.net/~weijun/8011402/webrev.02/
Changes since webrev.01:
1. Makefiles:
- new build logic outside ifndef OPENJDK
- Add a sed check to make sure open and close list use same algorithm
2.
Ok, I suggested you use a WeakHashMap but now I'm a little concerned
this could become a bottleneck if every certificate check has to lock
the map. Hmm. Maybe we should go back to the previous code, that also
had some concurrency issues but it was only per certificate, and wasn't
too bad
On 09/06/2013 09:30 AM, Weijun Wang wrote:
Hi Sean
Please review the code changes at
8011402: Move blacklisting certificate logic from hard code to data
Hard coded blacklisted certificates are moved out of the class file and
now inside a data file. Furthermore, only their fingerprints are
46 matches
Mail list logo
