Please review the CSR at
https://bugs.openjdk.java.net/browse/JDK-8224891
(Oh, I hate the CSR having a different bug id.)
Basically, with this change, the cacerts file can be loaded with
KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or
KeyStore.getInstance(new
New webrev at
https://cr.openjdk.java.net/~weijun/8193255/webrev.01
Changes:
1. Textual info at the beginning of each cert
2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir
Thanks,
Max
> On May 31, 2019, at 1:34 AM, Erik Joelsson wrote:
>
> On 2019-05-30 08:3
Sure. How many info do you want to see?
I can prepend `keytool -printcert` but that's too much. At least I think the
extensions part is not needed. Also, I don't wish people reading the
fingerprint inside as genuine and does not calculate it from the cert itself.
So, I'm thinking of
Owner: CN=
The latest CSR looks good to me.
Thanks,
Xuelei
On 5/28/2019 11:55 AM, Anthony Scarpino wrote:
The CSR has been updated with what I believe address the mentioned issues.
Tony
On 5/21/19 4:24 PM, Anthony Scarpino wrote:
Hi All,
Please review the CSR for the stateless Server Side
https://bug
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 browse
Hi Max,
first of all, thanks for doing this enhancement. That'll really help in the
future when downstream vendors merge in additional certificates (or remove
some) like we do with SapMachine. Currently we have to resolve manually
everytime cacerts is modified.
As for the dependencies: if you
On Thu, May 30, 2019 at 11:18:00AM +0800, Weijun Wang wrote:
> Practically, if I always add the current realm to a name without a realm, and
> then always remove the realm if it's the current realm when calling
> InitiateSecurityContext, there should be no harm. If the realm was added by
> me, then
On 2019-05-30 08:32, Weijun Wang wrote:
On May 30, 2019, at 10:01 PM, Erik Joelsson wrote:
In my experience, using directories for dependencies in make does not work
well. Since all the files in make/data/cacerts are in a flat structure, I would
recommend expressing the prerequisites as:
$
> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote:
>
> In my experience, using directories for dependencies in make does not work
> well. Since all the files in make/data/cacerts are in a flat structure, I
> would recommend expressing the prerequisites as:
>
> $(wildcard $(GENDATA_CACERTS
Hello Max,
Looking in ToolsJdk.gmk, I realize that the BUILD_TOOLS variable was
renamed back when we unified the repositories and is now called
BUILD_TOOLS_JDK. It seems like I missed updating the references to this
variable in the gendata dir. If you use the new variable name in the
prerequi
Since I need to track all added, removed, updated files in that directory, I
thought depending on the directory itself is more correct. If I use the
FindFiles function, then if some files are removed the cacerts will not be
rebuilt.
--Max
> On May 30, 2019, at 9:11 PM, David Holmes wrote:
>
Hi Max,
Not a review :)
On 30/05/2019 11:01 pm, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8193255/webrev.00/
Please pay attention to the 1st 3 and the last 2 files. Others are PEM files
for all certs inside the original cacerts.
There is one thing I c
Please take a review at
http://cr.openjdk.java.net/~weijun/8193255/webrev.00/
Please pay attention to the 1st 3 and the last 2 files. Others are PEM files
for all certs inside the original cacerts.
There is one thing I cannot get correct. If I update the GenerateCacerts.java
file and rerun
13 matches
Mail list logo
