On 5/29/2019 12:30 PM, Martin Balao wrote:
Hi Xuelei,
Thanks for blacklisting this test.
I've been trying to reproduce this failure in my local Windows
environment without success. Thus, I'm not sure of what's going on.
My hypothesis is that SSLCipher class may be initialized, for some
reason,
On 6/2/19 10:28 PM, Weijun Wang wrote:
I am playing with KeyStore.Entry.Attribute and found out it's only retrievable
with Entry::getAttributes. This means for a PrivateKeyEntry that is protected
with a password, you will have to provide that password to get the entry first
to get the attribut
Hi,
On 6/1/19 8:29 AM, Michał Zegan wrote:
Hello,
I believe I have found a bug but not quite sure if it is in
documentation or jdk impl itself. I currently have no code example, but
I looked into the jdk code itself.
This
https://docs.oracle.com/en/java/javase/11/security/java-pki-programmers-gu
I just filed https://bugs.openjdk.java.net/browse/JDK-8225181.
Thanks,
Max
> On Jun 3, 2019, at 10:18 PM, Sean Mullan wrote:
>
> On 6/2/19 10:28 PM, Weijun Wang wrote:
>> I am playing with KeyStore.Entry.Attribute and found out it's only
>> retrievable with Entry::getAttributes. This means for
On 6/3/2019 10:18 AM, Sean Mullan wrote:
On 6/2/19 10:28 PM, Weijun Wang wrote:
I am playing with KeyStore.Entry.Attribute and found out it's only
retrievable with Entry::getAttributes. This means for a
PrivateKeyEntry that is protected with a password, you will have to
provide that password t
The storepass and the keypass are usually the same but they are independent. If
the Mac is there and a non-null storepass is provided at loading, then
integrity checking is performed. We do allow storepass being null in
KeyStore::load and the method spec says:
* @param password the password use
On 6/2/19 11:00 AM, Weijun Wang wrote:
But it still has to be a keystore. KeyStore is designed into SSL's TrustManagerFactory. JSSE has system
properties javax.net.ssl.trustStore* pointing to it specifying file name, keystore type, and password. If we
really use a PEM bundle, we might need to d
On Sat, Jun 01, 2019 at 07:43:42AM +0800, Weijun Wang wrote:
> >> This is for export(), where they use
> >> "WELLKNOWN:ORG.H5L.REFERALS-REALM" but I hesitate to introduce it.
> >
> > Heimdal defines that, but doesn't use it. MIT doesn't even define
> > it.
>
> I thought I saw it with MIT but may
Hi Sean and Michal, one comment in-line below:
On 6/3/2019 7:45 AM, Sean Mullan wrote:
Hi,
On 6/1/19 8:29 AM, Michał Zegan wrote:
Hello,
I believe I have found a bug but not quite sure if it is in
documentation or jdk impl itself. I currently have no code example, but
I looked into the jdk cod
W dniu 03.06.2019 o 16:45, Sean Mullan pisze:
> Hi,
>
> On 6/1/19 8:29 AM, Michał Zegan wrote:
>> Hello,
>> I believe I have found a bug but not quite sure if it is in
>> documentation or jdk impl itself. I currently have no code example, but
>> I looked into the jdk code itself.
>> This
>> http
W dniu 03.06.2019 o 18:58, Jamil Nimeh pisze:
> Hi Sean and Michal, one comment in-line below:
>
> On 6/3/2019 7:45 AM, Sean Mullan wrote:
>> Hi,
>>
>> On 6/1/19 8:29 AM, Michał Zegan wrote:
>>> Hello,
>>> I believe I have found a bug but not quite sure if it is in
>>> documentation or jdk impl
On 6/3/2019 11:05 AM, Weijun Wang wrote:
The storepass and the keypass are usually the same but they are independent. If
the Mac is there and a non-null storepass is provided at loading, then
integrity checking is performed. We do allow storepass being null in
KeyStore::load and the method spe
Am 2019-06-03 um 17:07 schrieb Sean Mullan:
On 6/2/19 11:00 AM, Weijun Wang wrote:
But it still has to be a keystore. KeyStore is designed into SSL's
TrustManagerFactory. JSSE has system properties
javax.net.ssl.trustStore* pointing to it specifying file name,
keystore type, and password. If we
On 6/3/19 1:16 PM, Michał Zegan wrote:
It says in PKIXParameters.setRevocationEnabled [1]:
"Sophisticated applications should set this flag to false when it is not
practical to use a PKIX service provider's default revocation checking
mechanism or when an alternative revocation checking mechanis
W dniu 03.06.2019 o 22:34, Sean Mullan pisze:
> On 6/3/19 1:16 PM, Michał Zegan wrote:
>>> It says in PKIXParameters.setRevocationEnabled [1]:
>>>
>>> "Sophisticated applications should set this flag to false when it is not
>>> practical to use a PKIX service provider's default revocation checkin
> On Jun 4, 2019, at 1:34 AM, Michael StJohns wrote:
>
> On 6/3/2019 11:05 AM, Weijun Wang wrote:
>> The storepass and the keypass are usually the same but they are independent.
>> If the Mac is there and a non-null storepass is provided at loading, then
>> integrity checking is performed. W
I believe I updated all comments in the latest webrev.
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
Tony
On 5/16/19 2:30 PM, Anthony Scarpino wrote:
I'm asking for a review of this rather large change to add support
stateless tickets in the TLS 1.3 5077 RFC.
https://bugs.openjdk.
On 6/3/2019 7:27 PM, Weijun Wang wrote:
On Jun 4, 2019, at 1:34 AM, Michael StJohns wrote:
On 6/3/2019 11:05 AM, Weijun Wang wrote:
The storepass and the keypass are usually the same but they are independent. If
the Mac is there and a non-null storepass is provided at loading, then
integri
I think you're worried about if KeyStore::getAttributes and
Entry::getAttributes would return different values before a provider has the
chance to implement the former. This is something we need to be very care of.
Maybe the default implementation of KeyStoreSpi::engineGetAttributes should
thro
Rethinking about this. Although this sspi.cpp is included in OpenJDK, it was
meant to be a pure standalone DLL that has nothing to do with JNI or JVM.
Adding this "JDK_" thing would be a tiny taint to the whole program. I'd rather
make it SSPI_BRIDGE_TRACE. Is that better? Or still SSPI_TRACE?
Tiny comments:
- java.security typos:
492,497: ovewritten
496: infite
- CredentialsUtils.java:
36: unused import
- KDCRep.java:
no need to move the position
- ReferralsCache.java:
Red Hat has different copyright lines. For example, in java.base. Maybe any
one is OK. IANAL. S
Am 2019-06-04 um 04:09 schrieb Weijun Wang:
Rethinking about this. Although this sspi.cpp is included in OpenJDK, it was meant to be
a pure standalone DLL that has nothing to do with JNI or JVM. Adding this
"JDK_" thing would be a tiny taint to the whole program. I'd rather make it
SSPI_BRIDGE
22 matches
Mail list logo
