The PKCS12KeyStore implementation only stores the decrypted certificate, but
the major reason is that we want a password-less keystore to remain
password-less without any property setting, so the newly added certificate must
be stored the same way as the last existing certificate, and I think it
> On Oct 9, 2018, at 3:01 AM, Sean Mullan wrote:
>
> The first sentence is a bit terse. Suggest changing it to:
>
> "The `dns_canonicalize_hostname` flag in the krb5.conf configuration file is
> now supported by the JDK Kerberos implementation."
>
> Also, you should probably spell out "FQDN
The first sentence is a bit terse. Suggest changing it to:
"The `dns_canonicalize_hostname` flag in the krb5.conf configuration
file is now supported by the JDK Kerberos implementation."
Also, you should probably spell out "FQDN".
--Sean
On 10/8/18 2:19 PM, Roger Riggs wrote:
Hi Max,
The r
Hi Max,
The release note is fine though it would more complete if it contained a
link
to the krb5_conf.html where the behavior is described.
The original issue https://bugs.openjdk.java.net/browse/JDK-8210821
describes the behavior if set to 'false', while the release note is
written describi
The organization is better now, thanks. The code looks good to me, but I
would like to request another review from Tony (or someone else who is
familiar with this code) before you push. There is a lot of complexity
here, and it is hard for me to be sure that everything will behave the
same afte
On 10/8/18 11:26 AM, Weijun Wang wrote:
CSR updated. Please take a review.
https://bugs.openjdk.java.net/browse/JDK-8202590
# ... If there
# is at least one certificate in the existing keystore, the algorithm and
# parameter used to encrypt the last certificate in the existing
keystore wi
On 2018-10-08 17:51, Alan Bateman wrote:
On 08/10/2018 16:24, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manife
On 08/10/2018 16:24, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest
doesn't eagerly read in the property val
Thanks, Sean!
/Claes
On 2018-10-08 17:47, Sean Mullan wrote:
Looks good to me.
--Sean
On 10/8/18 11:24 AM, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used i
Looks good to me.
--Sean
On 10/8/18 11:24 AM, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest doesn't
eagerly
CSR updated. Please take a review.
https://bugs.openjdk.java.net/browse/JDK-8202590
A slightly updated webrev at
https://cr.openjdk.java.net/~weijun/8076190/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
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest doesn't
eagerly read in the property value in the static initializer avoids this.
Web
> On Oct 8, 2018, at 1:26 AM, Alan Bateman wrote:
>
> On 07/10/2018 18:08, Scott Palmer wrote:
>> Thanks Alan. I think this is exactly the issue I was hitting.
>>
>> Is it currently not possible to ensure modules have not been tampered with?
>>
> The signature checking for signed JARs on th
And please also review the release note at
https://bugs.openjdk.java.net/browse/JDK-8211380
The text is copied below:
Supports the `dns_canonicalize_hostname` setting in krb5.conf. When set to
true, a short hostname in a service principal name will be canonicalized to a
FQDN if available. O
14 matches
Mail list logo