From xuelei.fan at oracle.com Thu May 1 14:12:16 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 01 May 2014 22:12:16 +0800
Subject: JDK 9 Review Request for 8038349: Signing XML with DSA throws
Exception when key is larger than 1024 bits
In-Reply-To: <53605F63.1030003@oracle.com>
References: <53601037.3090307@oracle.com> <53605F63.1030003@oracle.com>
Message-ID: <53625640.1030606@oracle.com>
> security/utils/JavaUtils.java
> =============================
The updated code is a straightforward move from other classes in order
to remove the duplicated code. Looks fine but we might want to make a
few little enhancements within this fix.
162 public static byte[] convertASN1toXMLDSIG(byte asn1Bytes[], ..
201 public static byte[] convertXMLDSIGtoASN1(byte xmldsigBytes[], ..
Minor comment about code conversions. I may prefer to use consistent
style to declare the array parameters.
byte asn1Bytes[] -> byte[] asn1Bytes
byte xmldsigBytes[] -> byte[] xmldsigBytes
convertASN1toXMLDSIG(byte asn1Bytes[], int size):
-------------------------------------------------
I may check the asn1Bytes.length against/and the "size" parameter, and
check first 3 bytes before getting the 4rd byte. Similarly, I may check
the first byte and the rest length of the array before try to parse the
s (the 2nd fragment of the array) value of the signature.
convertXMLDSIGtoASN1(byte xmldsigBytes[], int size):
----------------------------------------------------
I did not get the idea behind lines 212-215 and lines 220-223. Why try
to check and ignore the negative value?
225 byte asn1Bytes[] = new byte[6 + j + l];
By the line, the length of the target byte array is known. I might
prefer to allocate the exactly size for byte array here. Otherwise, the
2nd System.arraycopy() would need re-allocate the array for more space.
Xuelei
> On 4/30/2014 4:48 AM, Sean Mullan wrote:
>> Please review the following change which adds support for 2048-bit DSA
>> keys and the DSA-SHA256 algorithm to the XML Signature implementation:
>>
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038349/webrev.00/
>>
>> JDK 8 already includes the underlying support for both of these in the
>> Sun provider. For 2048 bit keys, the ASN.1 parsing code in the XML
>> Signature layer needed to be adapted to handle 2048 bit keys, and for
>> SHA-256 it was just a matter of registering the algorithm URI and
>> instantiating a Signature object with the SHA256WithDSA algorithm.
>>
>> Thanks,
>> Sean
>
From sean.mullan at oracle.com Thu May 1 19:10:40 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 01 May 2014 15:10:40 -0400
Subject: JDK 9 Review Request for 8038349: Signing XML with DSA throws
Exception when key is larger than 1024 bits
In-Reply-To: <53625640.1030606@oracle.com>
References: <53601037.3090307@oracle.com> <53605F63.1030003@oracle.com>
<53625640.1030606@oracle.com>
Message-ID: <53629C30.8090704@oracle.com>
On 05/01/2014 10:12 AM, Xuelei Fan wrote:
>> security/utils/JavaUtils.java
>> =============================
> The updated code is a straightforward move from other classes in order
> to remove the duplicated code. Looks fine but we might want to make a
> few little enhancements within this fix.
>
> 162 public static byte[] convertASN1toXMLDSIG(byte asn1Bytes[], ..
> 201 public static byte[] convertXMLDSIGtoASN1(byte xmldsigBytes[], ..
>
> Minor comment about code conversions. I may prefer to use consistent
> style to declare the array parameters.
> byte asn1Bytes[] -> byte[] asn1Bytes
> byte xmldsigBytes[] -> byte[] xmldsigBytes
Yes, I agree and will change that.
> convertASN1toXMLDSIG(byte asn1Bytes[], int size):
> -------------------------------------------------
> I may check the asn1Bytes.length against/and the "size" parameter, and
> check first 3 bytes before getting the 4rd byte. Similarly, I may check
> the first byte and the rest length of the array before try to parse the
> s (the 2nd fragment of the array) value of the signature.
Ok, I moved those checks to the start of the method.
> convertXMLDSIGtoASN1(byte xmldsigBytes[], int size):
> ----------------------------------------------------
> I did not get the idea behind lines 212-215 and lines 220-223. Why try
> to check and ignore the negative value?
I do not know but I am reluctant to remove it in case I break something.
The code is not commented very well.
> 225 byte asn1Bytes[] = new byte[6 + j + l];
> By the line, the length of the target byte array is known. I might
> prefer to allocate the exactly size for byte array here. Otherwise, the
> 2nd System.arraycopy() would need re-allocate the array for more space.
I'm not quite following you here. System.arrayCopy doesn't resize the
array, it will throw an exception if the dest array is not big enough.
Can you clarify what you mean or show me the corrected code?
Thanks,
Sean
>
> Xuelei
>
>> On 4/30/2014 4:48 AM, Sean Mullan wrote:
>>> Please review the following change which adds support for 2048-bit DSA
>>> keys and the DSA-SHA256 algorithm to the XML Signature implementation:
>>>
>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038349/webrev.00/
>>>
>>> JDK 8 already includes the underlying support for both of these in the
>>> Sun provider. For 2048 bit keys, the ASN.1 parsing code in the XML
>>> Signature layer needed to be adapted to handle 2048 bit keys, and for
>>> SHA-256 it was just a matter of registering the algorithm URI and
>>> instantiating a Signature object with the SHA256WithDSA algorithm.
>>>
>>> Thanks,
>>> Sean
>>
>
From xuelei.fan at oracle.com Thu May 1 23:27:49 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 02 May 2014 07:27:49 +0800
Subject: JDK 9 Review Request for 8038349: Signing XML with DSA throws
Exception when key is larger than 1024 bits
In-Reply-To: <53629C30.8090704@oracle.com>
References: <53601037.3090307@oracle.com> <53605F63.1030003@oracle.com>
<53625640.1030606@oracle.com> <53629C30.8090704@oracle.com>
Message-ID: <5362D875.6060405@oracle.com>
My fault. I read the "l" (L) in the following line as "1" (one).
>> 225 byte asn1Bytes[] = new byte[6 + j + l];
Xuelei
On 5/2/2014 3:10 AM, Sean Mullan wrote:
>> 225 byte asn1Bytes[] = new byte[6 + j + l];
>> By the line, the length of the target byte array is known. I might
>> prefer to allocate the exactly size for byte array here. Otherwise, the
>> 2nd System.arraycopy() would need re-allocate the array for more space.
>
> I'm not quite following you here. System.arrayCopy doesn't resize the
> array, it will throw an exception if the dest array is not big enough.
> Can you clarify what you mean or show me the corrected code?
>
> Thanks,
From fweimer at redhat.com Mon May 5 11:51:38 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 05 May 2014 13:51:38 +0200
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <53305DBA.1000001@redhat.com>
References: <53305DBA.1000001@redhat.com>
Message-ID: <53677B4A.5030808@redhat.com>
On 03/24/2014 05:30 PM, Florian Weimer wrote:
> This CR adds a new class java.security.StandardMessageDigests:
>
>
>
> Could I get a bug number if this change is fine in principle?
>
> Cryptographic hash functions are frequently used directly, often for
> non-cryptographic purposes, so I think it makes sense to provide a
> convenient way to access implementations for the most common hashes. The
> new class follows the java.nio.charset.StandardCharsets precedent
> (separate class, "Standard" in the name).
>
> I deliberately did not include support for MD5. It would be nice if we
> could drop the NoSuchAlgorithmException, but this would be problematic
> once there are providers that do not support SHA-1.
>
> Instantiating digest objects through cloning should be quite a bit
> faster than the provider route (but I measured this some time ago only,
> so these results could be outdated by now).
Ping? This change proposal is in response to an earlier discussion:
I fixed the webrev so that the fast path actually runs, and now JMH
reports a speedup:
Benchmark Mode Samples
Mean Mean error Units
o.o.j.b.StandardMessageDigestsBenchmark.get thrpt 200
1650.350 53.388 ops/ms
o.o.j.b.StandardMessageDigestsBenchmark.smd thrpt 200
1814.137 59.414 ops/ms
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Mon May 5 12:31:28 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 05 May 2014 20:31:28 +0800
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <53677B4A.5030808@redhat.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
Message-ID: <536784A0.4060200@oracle.com>
Comparing with the call:
MessageDigest md = MessageDigest.getInstance("SHA-1");
What's the benefit of the following call?
MessageDigest md = StandardMessageDigests.newSHA1();
What's the context that this new class is supposed to use?
Thanks & Regards,
Xuelei
On 5/5/2014 7:51 PM, Florian Weimer wrote:
> On 03/24/2014 05:30 PM, Florian Weimer wrote:
>> This CR adds a new class java.security.StandardMessageDigests:
>>
>>
>>
>> Could I get a bug number if this change is fine in principle?
>>
>> Cryptographic hash functions are frequently used directly, often for
>> non-cryptographic purposes, so I think it makes sense to provide a
>> convenient way to access implementations for the most common hashes. The
>> new class follows the java.nio.charset.StandardCharsets precedent
>> (separate class, "Standard" in the name).
>>
>> I deliberately did not include support for MD5. It would be nice if we
>> could drop the NoSuchAlgorithmException, but this would be problematic
>> once there are providers that do not support SHA-1.
>>
>> Instantiating digest objects through cloning should be quite a bit
>> faster than the provider route (but I measured this some time ago only,
>> so these results could be outdated by now).
>
> Ping? This change proposal is in response to an earlier discussion:
>
>
>
>
> I fixed the webrev so that the fast path actually runs, and now JMH
> reports a speedup:
>
> Benchmark Mode Samples Mean
> Mean error Units
> o.o.j.b.StandardMessageDigestsBenchmark.get thrpt 200
> 1650.350 53.388 ops/ms
> o.o.j.b.StandardMessageDigestsBenchmark.smd thrpt 200
> 1814.137 59.414 ops/ms
>
From fweimer at redhat.com Mon May 5 13:09:46 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 05 May 2014 15:09:46 +0200
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <536784A0.4060200@oracle.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com>
Message-ID: <53678D9A.6070002@redhat.com>
On 05/05/2014 02:31 PM, Xuelei Fan wrote:
> Comparing with the call:
> MessageDigest md = MessageDigest.getInstance("SHA-1");
>
> What's the benefit of the following call?
>
> MessageDigest md = StandardMessageDigests.newSHA1();
>
> What's the context that this new class is supposed to use?
It's 10% faster, even including the digest overhead for a single-block
message. I forgot to mention that the benchmark numbers I posted
include that, to make them more realistic. If I only measure the cost
of instantiation and a single-byte update, the numbers are as follows:
Benchmark Mode Samples
Mean Mean error Units
o.o.j.b.StandardMessageDigestsBenchmark.get thrpt 200
6292.827 178.149 ops/ms
o.o.j.b.StandardMessageDigestsBenchmark.smd thrpt 200
10018.883 294.193 ops/ms
I think the single-block hashing case is important because it is not
always possible to reuse an existing digest object after calling
reset(). The difference will be more visible once we have message
digests with hardware support (which is apparently around the corner for
SHA-1 and SHA-256).
We could also revisit the decision about NoSuchAlgorithmException:
>>> I deliberately did not include support for MD5. It would be nice if we
>>> could drop the NoSuchAlgorithmException, but this would be problematic
>>> once there are providers that do not support SHA-1.
If we guarantee that the algorithms are always supported, we could drop
the checked exception, making it easier to initialize objects. This
would be an added benefit, then.
--
Florian Weimer / Red Hat Product Security Team
From Xuelei.Fan at Oracle.Com Mon May 5 14:43:34 2014
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Mon, 5 May 2014 22:43:34 +0800
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <53678D9A.6070002@redhat.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
Message-ID: <382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
> On May 5, 2014, at 9:09 PM, Florian Weimer wrote:
>
>> On 05/05/2014 02:31 PM, Xuelei Fan wrote:
>> Comparing with the call:
>> MessageDigest md = MessageDigest.getInstance("SHA-1");
>>
>> What's the benefit of the following call?
>>
>> MessageDigest md = StandardMessageDigests.newSHA1();
>>
>> What's the context that this new class is supposed to use?
>
> It's 10% faster, even including the digest overhead for a single-block message.
clone() is an optional operation for MD. This point may make this class unreliable. I think it might be a better place to make the improvement in crypto providers. BTW! I guess in some situation or some providers, clone() might not be a lightweight operation.
> I forgot to mention that the benchmark numbers I posted include that, to make them more realistic. If I only measure the cost of instantiation and a single-byte update, the numbers are as follows:
>
> Benchmark Mode Samples Mean Mean error Units
> o.o.j.b.StandardMessageDigestsBenchmark.get thrpt 200 6292.827 178.149 ops/ms
> o.o.j.b.StandardMessageDigestsBenchmark.smd thrpt 200 10018.883 294.193 ops/ms
>
> I think the single-block hashing case is important because it is not always possible to reuse an existing digest object after calling reset().
It means the reset() does not work. Looks like a bug to me.
> The difference will be more visible once we have message digests with hardware support (which is apparently around the corner for SHA-1 and SHA-256).
>
> We could also revisit the decision about NoSuchAlgorithmException:
>
>>>> I deliberately did not include support for MD5. It would be nice if we
>>>> could drop the NoSuchAlgorithmException, but this would be problematic
>>>> once there are providers that do not support SHA-1.
>
> If we guarantee that the algorithms are always supported, we could drop the checked exception, making it easier to initialize objects. This would be an added benefit, then.
It cannot be guaranteed in JRE level. The supported algorithms should totally depend on crypto providers, although java may suggest a minimal supported algorithm set.
Thanks & Regards,
Xuelei
> --
> Florian Weimer / Red Hat Product Security Team
From fweimer at redhat.com Tue May 6 09:45:58 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 11:45:58 +0200
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
<382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
Message-ID: <5368AF56.4030707@redhat.com>
On 05/05/2014 04:43 PM, Xuelei Fan wrote:
>> It's 10% faster, even including the digest overhead for a single-block message.
> clone() is an optional operation for MD. This point may make this class unreliable.
I think the MessageDigest specification requires that this works. The
TLS implementation also relies on this behavior (i.e. clone() either
consistently fails or consistently succeeds).
Note that I'm not blindly calling clone(), I'm providing a fallback in
case clone() does not work.
> I think it might be a better place to make the improvement in crypto providers.
What kind of improvement are you thinking of?
> BTW! I guess in some situation or some providers, clone() might not be a lightweight operation.
Hmm. I can see that the state cannot be cloned at all (that's why
cloning is optional), but allocating a new state has to happen anyway,
no matter how the object is constructed.
>> I think the single-block hashing case is important because it is not always possible to reuse an existing digest object after calling reset().
> It means the reset() does not work. Looks like a bug to me.
What I meant is that there might be no place to store the reference to a
long-term MessageDigest object which is reused again and again, so the
best thing the code can do is to allocate a fresh object when it is needed?
Hmm, maybe we could provide a tread-local message digest that can be
used to hash byte arrays? It would address the simplest possible case
where the instantiation overhead is most visible.
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Tue May 6 10:10:15 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 18:10:15 +0800
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
Message-ID: <5368B507.7010000@oracle.com>
Hi,
Please review this simple but interesting fix:
http://cr.openjdk.java.net/~xuelei/8042449/webrev.00/
During the checking of invalid record version, a byte to byte comparing
is coded as:
if (...
recordVersion.major > ProtocolVersion.MAX.major) {
throw new SSLException
}
"recordVersion.major" and "ProtocolVersion.MAX.major" is byte type,
which is signed. If the major version is "0xa9", recordVersion.major is
a negative value (-87). If ProtocolVersion.MAX.major is positive, the
checking above does not work any more.
This fix converts the version number to positive value before make the
comparing.
Thanks,
Xuelei
From xuelei.fan at oracle.com Tue May 6 11:39:18 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 19:39:18 +0800
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <5368AF56.4030707@redhat.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
<382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
<5368AF56.4030707@redhat.com>
Message-ID: <5368C9E6.2080404@oracle.com>
Another concern of mine is about that the returned MessageDigest object
heavily depends on the providers configuration when the object get
instantiated for the 1st time. If the providers configuration get
updated during run time, the provider of the returned MessageDigest
object does not get updated accordingly. This proposal may be a pretty
good practice in application layer in some circumstance, but may result
in unnecessary complexity in JRE layer because we don't know the exact
context that the application want to use this class, and the exact
implementation details of the underlying MD service provider.
On 5/6/2014 5:45 PM, Florian Weimer wrote:
> On 05/05/2014 04:43 PM, Xuelei Fan wrote:
>
>>> It's 10% faster, even including the digest overhead for a
>>> single-block message.
>
>> clone() is an optional operation for MD. This point may make this
>> class unreliable.
>
> I think the MessageDigest specification requires that this works.
Per the spec, clone() may throw CloneNotSupportedException. It is OK a
certain provider does not support Cloneable.
> The
> TLS implementation also relies on this behavior (i.e. clone() either
> consistently fails or consistently succeeds).
>
That's true. SunJSSE requires cloneable MD implementation.
> Note that I'm not blindly calling clone(), I'm providing a fallback in
> case clone() does not work.
>
It's a good workaround.
>> I think it might be a better place to make the improvement in crypto
>> providers.
>
> What kind of improvement are you thinking of?
>
If the performance can get improvement here by define a static cloneable
object, it might be also can get improvement in the same way in the
provider implementation, unless the improvement is all about
implementation service look up among the supported providers.
>> BTW! I guess in some situation or some providers, clone() might not be
>> a lightweight operation.
>
> Hmm. I can see that the state cannot be cloned at all (that's why
> cloning is optional), but allocating a new state has to happen anyway,
> no matter how the object is constructed.
>
Let's consider a case, every MD object should be bound to a session, and
the operations should be synchronized in the session. clone() will share
the session, the operations among different MD objects that share the
session need to be synchronized. I think, there is a significant
performance and scalablity impact if StandardMessageDigests is used for
such cases in concurrency context.
>>> I think the single-block hashing case is important because it is not
>>> always possible to reuse an existing digest object after calling
>>> reset().
>
>> It means the reset() does not work. Looks like a bug to me.
>
> What I meant is that there might be no place to store the reference to a
> long-term MessageDigest object which is reused again and again, so the
> best thing the code can do is to allocate a fresh object when it is needed?
>
The object of MessageDigest is not immutable. IMHO, as we discussed
above, there are a lot of issues need to be considered carefully to
support such a long-term object in JRE.
Thanks,
Xuelei
> Hmm, maybe we could provide a tread-local message digest that can be
> used to hash byte arrays? It would address the simplest possible case
> where the instantiation overhead is most visible.
>
From fweimer at redhat.com Tue May 6 11:41:39 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 13:41:39 +0200
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
In-Reply-To: <5368B507.7010000@oracle.com>
References: <5368B507.7010000@oracle.com>
Message-ID: <5368CA73.9080508@redhat.com>
On 05/06/2014 12:10 PM, Xuelei Fan wrote:
> Please review this simple but interesting fix:
> http://cr.openjdk.java.net/~xuelei/8042449/webrev.00/
It's strange that the code caches the major/minor version components as
fields of ProtocolVersion, but these fields cannot be used directly and
still need shifting and masking.
Maybe it's better to store the components as ints, or remove the fields
completely and use accessors that extract the components from the
version field as needed?
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Tue May 6 12:00:10 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 20:00:10 +0800
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
In-Reply-To: <5368CA73.9080508@redhat.com>
References: <5368B507.7010000@oracle.com> <5368CA73.9080508@redhat.com>
Message-ID: <5368CECA.8070103@oracle.com>
On 5/6/2014 7:41 PM, Florian Weimer wrote:
> On 05/06/2014 12:10 PM, Xuelei Fan wrote:
>
>> Please review this simple but interesting fix:
>> http://cr.openjdk.java.net/~xuelei/8042449/webrev.00/
>
> It's strange that the code caches the major/minor version components as
> fields of ProtocolVersion, but these fields cannot be used directly and
> still need shifting and masking.
>
> Maybe it's better to store the components as ints, or remove the fields
> completely and use accessors that extract the components from the
> version field as needed?
>
We need to convert the byte and int type back-and-forth. Store as ints
is convenient for comparing. Store as bytes is convenient for assigning
to a new generated record.
Storing both int version and major/minor byte versions is a little bit
redundancy. The update is significant. I will focus on the signed byte
issue in this fix.
Thanks for the comment!
Xuelei
From fweimer at redhat.com Tue May 6 12:06:29 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 14:06:29 +0200
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <5368C9E6.2080404@oracle.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
<382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
<5368AF56.4030707@redhat.com> <5368C9E6.2080404@oracle.com>
Message-ID: <5368D045.3070302@redhat.com>
On 05/06/2014 01:39 PM, Xuelei Fan wrote:
> Another concern of mine is about that the returned MessageDigest object
> heavily depends on the providers configuration when the object get
> instantiated for the 1st time. If the providers configuration get
> updated during run time, the provider of the returned MessageDigest
> object does not get updated accordingly. This proposal may be a pretty
> good practice in application layer in some circumstance, but may result
> in unnecessary complexity in JRE layer because we don't know the exact
> context that the application want to use this class, and the exact
> implementation details of the underlying MD service provider.
Hmm. It would certainly be possible to invalidate the cache if the
provider configuration is changed.
It's unlikely that a library-based reimplementation could get this right.
> Per the spec, clone() may throw CloneNotSupportedException. It is OK a
> certain provider does not support Cloneable.
The key part is that the behavior has to be consistent across all
objects. It's not required that clone() works, but if it works for one
instance, it works for all of them.
>> The
>> TLS implementation also relies on this behavior (i.e. clone() either
>> consistently fails or consistently succeeds).
>>
> That's true. SunJSSE requires cloneable MD implementation.
Are you sure? It contains a fairly elaborate workaround for the
non-cloneable case (construct as many digest objects as needed, and then
feed them data in parallel so that you can finalize one pseudo-clone,
but continue hashing using the other one).
> If the performance can get improvement here by define a static cloneable
> object, it might be also can get improvement in the same way in the
> provider implementation, unless the improvement is all about
> implementation service look up among the supported providers.
It's the service lookup. Well, it was the service lookup in 2010.
>>> BTW! I guess in some situation or some providers, clone() might not be
>>> a lightweight operation.
>>
>> Hmm. I can see that the state cannot be cloned at all (that's why
>> cloning is optional), but allocating a new state has to happen anyway,
>> no matter how the object is constructed.
>>
> Let's consider a case, every MD object should be bound to a session, and
> the operations should be synchronized in the session. clone() will share
> the session, the operations among different MD objects that share the
> session need to be synchronized. I think, there is a significant
> performance and scalablity impact if StandardMessageDigests is used for
> such cases in concurrency context.
Why would clone() share the session, but constructing a new digest would
not? Because sharing the session would be the only way to share the
state? Ugh, yes, you might be right.
>> What I meant is that there might be no place to store the reference to a
>> long-term MessageDigest object which is reused again and again, so the
>> best thing the code can do is to allocate a fresh object when it is needed?
>>
> The object of MessageDigest is not immutable. IMHO, as we discussed
> above, there are a lot of issues need to be considered carefully to
> support such a long-term object in JRE.
I meant a method like this:
public static byte[] sha1(byte[] buffer, int offset, int length) {
MessageDigest md = threadLocalMDs.sha1();
md.update(buffer, offset, length);
return md.digest();
}
The actual digest object would not be exposed through this interface.
This would cover the use case of hashing short buffers, where the
instantiation overhead is most visible.
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Tue May 6 12:35:37 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 20:35:37 +0800
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <5368D045.3070302@redhat.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
<382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
<5368AF56.4030707@redhat.com> <5368C9E6.2080404@oracle.com>
<5368D045.3070302@redhat.com>
Message-ID: <5368D719.3000109@oracle.com>
>> Per the spec, clone() may throw CloneNotSupportedException. It is OK a
>> certain provider does not support Cloneable.
>
> The key part is that the behavior has to be consistent across all
> objects. It's not required that clone() works, but if it works for one
> instance, it works for all of them.
>
True.
>>> The
>>> TLS implementation also relies on this behavior (i.e. clone() either
>>> consistently fails or consistently succeeds).
>>>
>> That's true. SunJSSE requires cloneable MD implementation.
>
> Are you sure? It contains a fairly elaborate workaround for the
> non-cloneable case (construct as many digest objects as needed, and then
> feed them data in parallel so that you can finalize one pseudo-clone,
> but continue hashing using the other one).
>
Right. You got it! That's also what I mean with "cloneable".
>>>> BTW! I guess in some situation or some providers, clone() might not be
>>>> a lightweight operation.
>>>
>>> Hmm. I can see that the state cannot be cloned at all (that's why
>>> cloning is optional), but allocating a new state has to happen anyway,
>>> no matter how the object is constructed.
>>>
>> Let's consider a case, every MD object should be bound to a session, and
>> the operations should be synchronized in the session. clone() will share
>> the session, the operations among different MD objects that share the
>> session need to be synchronized. I think, there is a significant
>> performance and scalablity impact if StandardMessageDigests is used for
>> such cases in concurrency context.
>
> Why would clone() share the session, but constructing a new digest would
> not? Because sharing the session would be the only way to share the
> state? Ugh, yes, you might be right.
>
When I though about the case, the idea come to my mind was that the
clone() may need to use the current states of MD. It is great if all of
the current states can also be cloned to another session. But ...
When the implementation of the underlying is unknown, it is hard to
estimate the detailed behavior in the unknown black box.
Xuelei
From fweimer at redhat.com Tue May 6 13:01:12 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 15:01:12 +0200
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <5368D719.3000109@oracle.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
<382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
<5368AF56.4030707@redhat.com> <5368C9E6.2080404@oracle.com>
<5368D045.3070302@redhat.com> <5368D719.3000109@oracle.com>
Message-ID: <5368DD18.5050907@redhat.com>
On 05/06/2014 02:35 PM, Xuelei Fan wrote:
> When I though about the case, the idea come to my mind was that the
> clone() may need to use the current states of MD. It is great if all of
> the current states can also be cloned to another session. But ...
The PKCS#11 provider can do this. The session is initialized lazily, so
that it doesn't have to be cloned at all if no data has been hashed yet.
As far as I can tell, you end up with the same token no matter how the
digest object is created (after all, there might be only one in the
system), which probably incurs some synchronization overhead. But it
doesn't matter if you use cloning or not. Allocation is always kind of
expensive because of the finalization requirement.
> When the implementation of the underlying is unknown, it is hard to
> estimate the detailed behavior in the unknown black box.
True. So you think providing more efficient means for hashing
relatively short byte sequences isn't worth the effort?
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Tue May 6 13:14:09 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 21:14:09 +0800
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <5368DD18.5050907@redhat.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
<382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
<5368AF56.4030707@redhat.com> <5368C9E6.2080404@oracle.com>
<5368D045.3070302@redhat.com> <5368D719.3000109@oracle.com>
<5368DD18.5050907@redhat.com>
Message-ID: <5368E021.6040709@oracle.com>
On 5/6/2014 9:01 PM, Florian Weimer wrote:
>> When the implementation of the underlying is unknown, it is hard to
>> estimate the detailed behavior in the unknown black box.
>
> True. So you think providing more efficient means for hashing
> relatively short byte sequences isn't worth the effort?
The benefits are small, I think. It is easy to get similar improvement
in application layer, but if we want add this to JRE for general use, we
may need to evaluation too much uncertainties or limitations.
Xuelei
From fweimer at redhat.com Tue May 6 13:31:58 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 15:31:58 +0200
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
In-Reply-To: <5368CECA.8070103@oracle.com>
References: <5368B507.7010000@oracle.com> <5368CA73.9080508@redhat.com>
<5368CECA.8070103@oracle.com>
Message-ID: <5368E44E.4030008@redhat.com>
On 05/06/2014 02:00 PM, Xuelei Fan wrote:
> Storing both int version and major/minor byte versions is a little bit
> redundancy. The update is significant. I will focus on the signed byte
> issue in this fix.
Yes, I get that. I've verified that you've covered all the version
comparisons.
I was just wondering if accessor methods (or storing the values as ints)
would make it less likely that the issue reoccurs in a different
variant. But the new checkRecordVersion() probably covers that.
--
Florian Weimer / Red Hat Product Security Team
From fweimer at redhat.com Tue May 6 13:36:56 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 15:36:56 +0200
Subject: Review Request of JDK Enhancement Proposal: OCSP stapling
In-Reply-To: <533B497D.1010304@oracle.com>
References: <532A2455.9080902@oracle.com> <533B497D.1010304@oracle.com>
Message-ID: <5368E578.5040501@redhat.com>
On 04/02/2014 01:19 AM, Xuelei Fan wrote:
> Here is the updated version:
> http://cr.openjdk.java.net/~xuelei/8034248/jep-csre-v01.txt
>
> Updated the description section and a few words so that it is easier to
> understand.
I think the server side would benefit from an API which allows code to
directly supply the OCSP response to be stapled, perhaps as part of the
extended trust manager.
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Tue May 6 13:37:56 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 21:37:56 +0800
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
In-Reply-To: <5368E44E.4030008@redhat.com>
References: <5368B507.7010000@oracle.com> <5368CA73.9080508@redhat.com>
<5368CECA.8070103@oracle.com> <5368E44E.4030008@redhat.com>
Message-ID: <5368E5B4.1040700@oracle.com>
On 5/6/2014 9:31 PM, Florian Weimer wrote:
> On 05/06/2014 02:00 PM, Xuelei Fan wrote:
>
>> Storing both int version and major/minor byte versions is a little bit
>> redundancy. The update is significant. I will focus on the signed byte
>> issue in this fix.
>
> Yes, I get that. I've verified that you've covered all the version
> comparisons.
>
Thanks for the code review. Do you have a OpenJDK author account?
> I was just wondering if accessor methods (or storing the values as ints)
> would make it less likely that the issue reoccurs in a different
> variant.
I think, it should be better.
Thanks,
Xuelei
> But the new checkRecordVersion() probably covers that.
>
From fweimer at redhat.com Tue May 6 13:39:57 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 15:39:57 +0200
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
In-Reply-To: <5368E5B4.1040700@oracle.com>
References: <5368B507.7010000@oracle.com>
<5368CA73.9080508@redhat.com> <5368CECA.8070103@oracle.com>
<5368E44E.4030008@redhat.com> <5368E5B4.1040700@oracle.com>
Message-ID: <5368E62D.6070902@redhat.com>
On 05/06/2014 03:37 PM, Xuelei Fan wrote:
> On 5/6/2014 9:31 PM, Florian Weimer wrote:
>> On 05/06/2014 02:00 PM, Xuelei Fan wrote:
>>
>>> Storing both int version and major/minor byte versions is a little bit
>>> redundancy. The update is significant. I will focus on the signed byte
>>> issue in this fix.
>>
>> Yes, I get that. I've verified that you've covered all the version
>> comparisons.
> Thanks for the code review. Do you have a OpenJDK author account?
I'm not an official reviewer, I'm afraid.
I used to have an author account (fweimer), but can no longer access it.
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Tue May 6 13:43:43 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 21:43:43 +0800
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
In-Reply-To: <5368E62D.6070902@redhat.com>
References: <5368B507.7010000@oracle.com>
<5368CA73.9080508@redhat.com> <5368CECA.8070103@oracle.com>
<5368E44E.4030008@redhat.com> <5368E5B4.1040700@oracle.com>
<5368E62D.6070902@redhat.com>
Message-ID: <5368E70F.1080707@oracle.com>
On 5/6/2014 9:39 PM, Florian Weimer wrote:
> On 05/06/2014 03:37 PM, Xuelei Fan wrote:
>> On 5/6/2014 9:31 PM, Florian Weimer wrote:
>>> On 05/06/2014 02:00 PM, Xuelei Fan wrote:
>>>
>>>> Storing both int version and major/minor byte versions is a little bit
>>>> redundancy. The update is significant. I will focus on the signed
>>>> byte
>>>> issue in this fix.
>>>
>>> Yes, I get that. I've verified that you've covered all the version
>>> comparisons.
>
>> Thanks for the code review. Do you have a OpenJDK author account?
>
> I'm not an official reviewer, I'm afraid.
>
I will your name in a "also reviewed by" section. I still need an
official reviewer.
Thanks,
Xuelei
From xuelei.fan at oracle.com Tue May 6 14:05:12 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 06 May 2014 22:05:12 +0800
Subject: Review Request of JDK Enhancement Proposal: OCSP stapling
In-Reply-To: <5368E578.5040501@redhat.com>
References: <532A2455.9080902@oracle.com> <533B497D.1010304@oracle.com>
<5368E578.5040501@redhat.com>
Message-ID: <5368EC18.1010907@oracle.com>
On 5/6/2014 9:36 PM, Florian Weimer wrote:
> On 04/02/2014 01:19 AM, Xuelei Fan wrote:
>> Here is the updated version:
>> http://cr.openjdk.java.net/~xuelei/8034248/jep-csre-v01.txt
>>
>> Updated the description section and a few words so that it is easier to
>> understand.
>
> I think the server side would benefit from an API which allows code to
> directly supply the OCSP response to be stapled, perhaps as part of the
> extended trust manager.
>
Typically, OCSP response is time-variant. Ideally, the response should
be retrieved and updated internally, in time and automatically. For the
first stage, I only want to implement the essential feature, and keep
the footprint as small as possible.
Thanks,
Xuelei
From bradford.wetmore at oracle.com Tue May 6 20:43:54 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 06 May 2014 13:43:54 -0700
Subject: Code review request [JDK 9] 8042449 Issue for negative byte major
record version
In-Reply-To: <5368E70F.1080707@oracle.com>
References: <5368B507.7010000@oracle.com> <5368CA73.9080508@redhat.com> <5368CECA.8070103@oracle.com> <5368E44E.4030008@redhat.com>
<5368E5B4.1040700@oracle.com> <5368E62D.6070902@redhat.com>
<5368E70F.1080707@oracle.com>
Message-ID: <5369498A.1080703@oracle.com>
> I still need an official reviewer.
Thanks for looking into this, I was going check into it today if you
didn't. I figured it must be something in byte comparison. Sure enough.
Good catches! :) That code's been in there a long time!
Only nit is Copyright Dates if you choose to update.
Rest looks good.
Brad
On 5/6/2014 6:43 AM, Xuelei Fan wrote:
> On 5/6/2014 9:39 PM, Florian Weimer wrote:
>> On 05/06/2014 03:37 PM, Xuelei Fan wrote:
>>> On 5/6/2014 9:31 PM, Florian Weimer wrote:
>>>> On 05/06/2014 02:00 PM, Xuelei Fan wrote:
>>>>
>>>>> Storing both int version and major/minor byte versions is a little bit
>>>>> redundancy. The update is significant. I will focus on the signed
>>>>> byte
>>>>> issue in this fix.
>>>>
>>>> Yes, I get that. I've verified that you've covered all the version
>>>> comparisons.
>>
>>> Thanks for the code review. Do you have a OpenJDK author account?
>>
>> I'm not an official reviewer, I'm afraid.
>>
> I will your name in a "also reviewed by" section. I still need an
> official reviewer.
>
> Thanks,
> Xuelei
>
From jamil.j.nimeh at oracle.com Wed May 7 19:12:42 2014
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 07 May 2014 12:12:42 -0700
Subject: webrev request: JDK-6996377
Message-ID: <536A85AA.5080103@oracle.com>
Please review the webrev for JDK-6996377 when you get a chance.
http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
Thank you,
--Jamil
From anthony.scarpino at oracle.com Wed May 7 20:22:14 2014
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 07 May 2014 13:22:14 -0700
Subject: Very slow performance of AES/GCM in JDK 8 SunJCE provider
In-Reply-To: <9F85D762-3C7D-4C92-8E80-4E80A744A7F9@whittington.net.nz>
References: <9F85D762-3C7D-4C92-8E80-4E80A744A7F9@whittington.net.nz>
Message-ID: <536A95F6.8040608@oracle.com>
Hi Tim,
CLMUL acceleration is being looked into.
Tony
On 03/27/2014 02:28 PM, Tim Whittington wrote:
> Hi all
>
> I?ve noticed that the performance of the AES/GCM implementation in the JDK 8 SunJCE provider is very slow.
>
> On a simple micro-benchmark (standard caveats etc. etc.) encrypting 10 MB blocks of random data (not decrypt) I get the following rough throughputs:
>
> AES/ECB +UseAESIntrinsics - 600 MB/s (btw this is awesome fast for Java, up from about 300 MB/s in Java 7)
> AES/ECB -UseAESIntrinsics - 120 MB/s (again a good bump from about 90 MB/s in Java 7)
> AES/GCM - 4 MB/s
>
> 4 MB/s is pretty catastrophic (especially compared to the stellar baseline AES performance).
>
> A quick peek in a profiler reveals pretty much all the time is in GHash.blockMult()/getBit()/shift().
> The performance of the AES/GCM mode is comparable to other pure Java implementations without table based multiplier optimisations (which typically provide speeds in the 40-60 MB/s on the same micro-benchmark).
>
> I wonder if the JDK implementation could adopt one of those approaches or (better) implement an intrinsic to speed this up (perhaps using the CLMUL interaction set when available).
>
> cheers
> tim
>
> ?
>
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
>
> Darwin 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
>
From xuelei.fan at oracle.com Thu May 8 13:48:21 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 08 May 2014 21:48:21 +0800
Subject: webrev request: JDK-6996377
In-Reply-To: <536A85AA.5080103@oracle.com>
References: <536A85AA.5080103@oracle.com>
Message-ID: <536B8B25.6010405@oracle.com>
In general, the source code fix looks fine to me. A few minor comments:
1. Copyright
PKIXValidator.java
------------------
It is not have to, I normally update the copyright date to the present
year when I update a file.
ctortest.sh:
ConstructorTest.java:
---------------------
When create a new source, we need to use the current year as the
copyright date.
- # Copyright (c) 2010, 2013, Oracle and/or its affiliates. ...
+ # Copyright (c) 2014, Oracle and/or its affiliates. ...
- * Copyright (c) 2010, Oracle and/or its affiliates. ...
+ * Copyright (c) 2014, Oracle and/or its affiliates. ...
2. Clean up resources allocated in the test
There is a new keystore generated in ctortest.jks. Need to remove the
file at the end of the test, even the test cannot pass.
Thanks,
Xuelei
On 5/8/2014 3:12 AM, Jamil Nimeh wrote:
> Please review the webrev for JDK-6996377 when you get a chance.
>
> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
>
> Thank you,
> --Jamil
From sean.mullan at oracle.com Thu May 8 13:50:52 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 08 May 2014 09:50:52 -0400
Subject: webrev request: JDK-6996377
In-Reply-To: <536A85AA.5080103@oracle.com>
References: <536A85AA.5080103@oracle.com>
Message-ID: <536B8BBC.7030902@oracle.com>
On 05/07/2014 03:12 PM, Jamil Nimeh wrote:
> Please review the webrev for JDK-6996377 when you get a chance.
>
> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
- PKIXValidator[130]: you can use the diamond operator to make the code
more concise:
new HashMap<>();
- shell script tests are somewhat discouraged going forward, since they
are harder to debug and can have various cross-platform issues, etc. Do
you think you could try to just create a Java test? One option is to
hard-code the certs (base64-encoded) inside the Java source code and use
CertificateFactory to instantiate them. If you do that, you should
include the keytool commands that you used to create the certs in
comments so that they can be re-created later on if necessary.
--Sean
From jamil.j.nimeh at oracle.com Thu May 8 13:55:29 2014
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 08 May 2014 06:55:29 -0700
Subject: webrev request: JDK-6996377
In-Reply-To: <536B8BBC.7030902@oracle.com>
References: <536A85AA.5080103@oracle.com> <536B8BBC.7030902@oracle.com>
Message-ID: <536B8CD1.2040403@oracle.com>
Ah, didn't know that we were moving away from the scripts. I had
thought about hard-coding certs, but I liked the on-the-fly generation
approach because it kept the validity periods always within current
time. But it's easy to just make really long lived certs so I'll make
that change.
I'll make the change on line 130 as well and look for any other
instances where I'm doing that.
Thanks!
--Jamil
On 05/08/2014 06:50 AM, Sean Mullan wrote:
> On 05/07/2014 03:12 PM, Jamil Nimeh wrote:
>> Please review the webrev for JDK-6996377 when you get a chance.
>>
>> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
>
> - PKIXValidator[130]: you can use the diamond operator to make the
> code more concise:
>
> new HashMap<>();
>
> - shell script tests are somewhat discouraged going forward, since
> they are harder to debug and can have various cross-platform issues,
> etc. Do you think you could try to just create a Java test? One option
> is to hard-code the certs (base64-encoded) inside the Java source code
> and use CertificateFactory to instantiate them. If you do that, you
> should include the keytool commands that you used to create the certs
> in comments so that they can be re-created later on if necessary.
>
> --Sean
>
From sean.mullan at oracle.com Thu May 8 14:00:58 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 08 May 2014 10:00:58 -0400
Subject: webrev request: JDK-6996377
In-Reply-To: <536B8CD1.2040403@oracle.com>
References: <536A85AA.5080103@oracle.com> <536B8BBC.7030902@oracle.com>
<536B8CD1.2040403@oracle.com>
Message-ID: <536B8E1A.3060005@oracle.com>
On 05/08/2014 09:55 AM, Jamil Nimeh wrote:
> Ah, didn't know that we were moving away from the scripts.
See https://blogs.oracle.com/jjg/entry/shelling_tests for some more
rationale.
> I had
> thought about hard-coding certs, but I liked the on-the-fly generation
> approach because it kept the validity periods always within current
> time. But it's easy to just make really long lived certs so I'll make
> that change.
You can also work around the expiration issue by setting the validity
date to a time within the validity period of the certificate. See
PKIXParameters.setDate(). We do that a lot in other tests.
--Sean
From sean.coffey at oracle.com Thu May 8 15:59:56 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 08 May 2014 16:59:56 +0100
Subject: RFR: 8028192 : Use of PKCS11-NSS provider in FIPS mode broken
Message-ID: <536BA9FC.2030504@oracle.com>
This is more or less a backport of the 8u20 code to the 7u-dev codebase.
This update fixes the SunJSSE problem that in FIPS mode, SunJSSE does
not work because keys cannot be extracted from crypto device.
Builds and tests are good.
http://cr.openjdk.java.net/~coffeys/webrev.8028192.jdk.7udev/webrev/
Regards,
Sean.
From jamil.j.nimeh at oracle.com Fri May 9 01:23:15 2014
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 08 May 2014 18:23:15 -0700
Subject: [Update]: webrev request: JDK-6996377
In-Reply-To: <536A85AA.5080103@oracle.com>
References: <536A85AA.5080103@oracle.com>
Message-ID: <536C2E03.8020800@oracle.com>
Hello all,
Updated webrev to account for Sean and Xuelei's comments is here:
http://cr.openjdk.java.net/~ascarpino/6996377/webrev.02/
Thank you,
--Jamil
On 05/07/2014 12:12 PM, Jamil Nimeh wrote:
> Please review the webrev for JDK-6996377 when you get a chance.
>
> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
>
> Thank you,
> --Jamil
From xuelei.fan at oracle.com Fri May 9 02:00:22 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 May 2014 10:00:22 +0800
Subject: [Update]: webrev request: JDK-6996377
In-Reply-To: <536C2E03.8020800@oracle.com>
References: <536A85AA.5080103@oracle.com> <536C2E03.8020800@oracle.com>
Message-ID: <536C36B6.9060505@oracle.com>
test/sun/security/validator/ConstructorTest.java
------------------------------------------------
Missed a "," in the copyright date line. May only need 2014 as this is
a new test.
- * Copyright (c) 2010, 2014 Oracle and/or its affiliates. ...
+ * Copyright (c) 2010, 2014, Oracle and/or its affiliates. ...
Or
+ * Copyright (c) 2014, Oracle and/or its affiliates. ...
I would prefer the later.
Otherwise, looks fine to me.
Xuelei
On 5/9/2014 9:23 AM, Jamil Nimeh wrote:
> Hello all,
>
> Updated webrev to account for Sean and Xuelei's comments is here:
>
> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.02/
>
>
> Thank you,
> --Jamil
>
> On 05/07/2014 12:12 PM, Jamil Nimeh wrote:
>> Please review the webrev for JDK-6996377 when you get a chance.
>>
>> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
>>
>> Thank you,
>> --Jamil
>
From fweimer at redhat.com Fri May 9 08:54:04 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 09 May 2014 10:54:04 +0200
Subject: Review Request of JDK Enhancement Proposal: OCSP stapling
In-Reply-To: <5368EC18.1010907@oracle.com>
References: <532A2455.9080902@oracle.com> <533B497D.1010304@oracle.com>
<5368E578.5040501@redhat.com> <5368EC18.1010907@oracle.com>
Message-ID: <536C97AC.9070002@redhat.com>
On 05/06/2014 04:05 PM, Xuelei Fan wrote:
> On 5/6/2014 9:36 PM, Florian Weimer wrote:
>> On 04/02/2014 01:19 AM, Xuelei Fan wrote:
>>> Here is the updated version:
>>> http://cr.openjdk.java.net/~xuelei/8034248/jep-csre-v01.txt
>>>
>>> Updated the description section and a few words so that it is easier to
>>> understand.
>>
>> I think the server side would benefit from an API which allows code to
>> directly supply the OCSP response to be stapled, perhaps as part of the
>> extended trust manager.
>>
> Typically, OCSP response is time-variant. Ideally, the response should
> be retrieved and updated internally, in time and automatically. For the
> first stage, I only want to implement the essential feature, and keep
> the footprint as small as possible.
I think we need a non-blocking way to inject the OCSP response into
SSLEngine.
And from a deployment perspective, we really need to provide something
that avoids making the OCSP request directly (or through an HTTP proxy).
Access to external resources is often quite restricted, and due to the
way OCSP has been specified, it is rather difficult to proxy it without
providing a generic web proxy service.
--
Florian Weimer / Red Hat Product Security Team
From fweimer at redhat.com Fri May 9 08:56:03 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 09 May 2014 10:56:03 +0200
Subject: [PATCH] Add class java.security.StandardMessageDigests
In-Reply-To: <5368E021.6040709@oracle.com>
References: <53305DBA.1000001@redhat.com> <53677B4A.5030808@redhat.com>
<536784A0.4060200@oracle.com> <53678D9A.6070002@redhat.com>
<382AF588-599B-42B9-B607-8AC2B29B1968@Oracle.Com>
<5368AF56.4030707@redhat.com> <5368C9E6.2080404@oracle.com>
<5368D045.3070302@redhat.com> <5368D719.3000109@oracle.com>
<5368DD18.5050907@redhat.com> <5368E021.6040709@oracle.com>
Message-ID: <536C9823.9080204@redhat.com>
On 05/06/2014 03:14 PM, Xuelei Fan wrote:
>> True. So you think providing more efficient means for hashing
>> relatively short byte sequences isn't worth the effort?
> The benefits are small, I think. It is easy to get similar improvement
> in application layer, but if we want add this to JRE for general use, we
> may need to evaluation too much uncertainties or limitations.
Okay, let's bury this for now. We can revisit it again once
hardware-accelerated hashing makes the instantiation overhead more
visible. :-)
--
Florian Weimer / Red Hat Product Security Team
From xuelei.fan at oracle.com Fri May 9 09:28:05 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 May 2014 17:28:05 +0800
Subject: RFR: 8028192 : Use of PKCS11-NSS provider in FIPS mode broken
In-Reply-To: <536BA9FC.2030504@oracle.com>
References: <536BA9FC.2030504@oracle.com>
Message-ID: <536C9FA5.50002@oracle.com>
Looks fine to me.
Thanks,
Xuelei
On 5/8/2014 11:59 PM, Se?n Coffey wrote:
> This is more or less a backport of the 8u20 code to the 7u-dev codebase.
>
> This update fixes the SunJSSE problem that in FIPS mode, SunJSSE does
> not work because keys cannot be extracted from crypto device.
>
> Builds and tests are good.
> http://cr.openjdk.java.net/~coffeys/webrev.8028192.jdk.7udev/webrev/
>
> Regards,
> Sean.
From xuelei.fan at oracle.com Fri May 9 12:25:55 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 May 2014 20:25:55 +0800
Subject: Review Request of JDK Enhancement Proposal: OCSP stapling
In-Reply-To: <536C97AC.9070002@redhat.com>
References: <532A2455.9080902@oracle.com> <533B497D.1010304@oracle.com>
<5368E578.5040501@redhat.com> <5368EC18.1010907@oracle.com>
<536C97AC.9070002@redhat.com>
Message-ID: <536CC953.40307@oracle.com>
On 5/9/2014 4:54 PM, Florian Weimer wrote:
> On 05/06/2014 04:05 PM, Xuelei Fan wrote:
>> On 5/6/2014 9:36 PM, Florian Weimer wrote:
>>> On 04/02/2014 01:19 AM, Xuelei Fan wrote:
>>>> Here is the updated version:
>>>> http://cr.openjdk.java.net/~xuelei/8034248/jep-csre-v01.txt
>>>>
>>>> Updated the description section and a few words so that it is easier to
>>>> understand.
>>>
>>> I think the server side would benefit from an API which allows code to
>>> directly supply the OCSP response to be stapled, perhaps as part of the
>>> extended trust manager.
>>>
>> Typically, OCSP response is time-variant. Ideally, the response should
>> be retrieved and updated internally, in time and automatically. For the
>> first stage, I only want to implement the essential feature, and keep
>> the footprint as small as possible.
>
> I think we need a non-blocking way to inject the OCSP response into
> SSLEngine.
>
Yes. The delegated task can be used to get the OCSP response.
> And from a deployment perspective, we really need to provide something
> that avoids making the OCSP request directly (or through an HTTP proxy).
> Access to external resources is often quite restricted, and due to the
> way OCSP has been specified, it is rather difficult to proxy it without
> providing a generic web proxy service.
>
Really good point! In SunJSSE provider, the PKIXRevocationChecker can
be used to get the OCSP response. However, this cannot apply to
customized key/trust manager. I will consider to add new APIs to allow
the supply of OCSp response, probably in key manager, in this JEP or an
additional small enhancement later.
Thanks,
Xuelei
From sean.mullan at oracle.com Fri May 9 17:11:23 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 09 May 2014 13:11:23 -0400
Subject: [Update]: webrev request: JDK-6996377
In-Reply-To: <536C2E03.8020800@oracle.com>
References: <536A85AA.5080103@oracle.com> <536C2E03.8020800@oracle.com>
Message-ID: <536D0C3B.9060607@oracle.com>
Looks good, very comprehensive test. My only comment is that it would be
helpful to add the keytool command you used to create each certificate
in a comment above the base64-encoded String.
Thanks,
Sean
On 05/08/2014 09:23 PM, Jamil Nimeh wrote:
> Hello all,
>
> Updated webrev to account for Sean and Xuelei's comments is here:
>
> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.02/
>
>
> Thank you,
> --Jamil
>
> On 05/07/2014 12:12 PM, Jamil Nimeh wrote:
>> Please review the webrev for JDK-6996377 when you get a chance.
>>
>> http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
>>
>> Thank you,
>> --Jamil
>
From weijun.wang at oracle.com Wed May 14 00:38:11 2014
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 14 May 2014 08:38:11 +0800
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout as
msec instead of sec
Message-ID: <5372BAF3.1020202@oracle.com>
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
The problem is that Java treats kdc_timeout as milliseconds but others
(NetBSD here) might treat it as seconds. With this code change, when the
number is <= 120, it's seconds, otherwise, milliseconds.
One exception would be that someone thinking NetBSD style could set it
to 999 for a "maximum" timeout but the final result is less than 1
second. In that case, we should advise him/her to set it to 99999999.
Thanks
Max
From Xuelei.Fan at Oracle.COM Wed May 14 05:21:12 2014
From: Xuelei.Fan at Oracle.COM (Xuelei Fan)
Date: Wed, 14 May 2014 13:21:12 +0800
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
as msec instead of sec
In-Reply-To: <5372BAF3.1020202@oracle.com>
References: <5372BAF3.1020202@oracle.com>
Message-ID: <5372FD48.7090007@Oracle.COM>
This does not sound like a safe update to me. Is it possible to
detected the actual kdc_timeout spec (for example, using the known
platform) of the underlying configuration?
Xuelei
On 5/14/2014 8:38 AM, Weijun Wang wrote:
> Please review the code changes at
>
> http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
>
> The problem is that Java treats kdc_timeout as milliseconds but others
> (NetBSD here) might treat it as seconds. With this code change, when the
> number is <= 120, it's seconds, otherwise, milliseconds.
>
> One exception would be that someone thinking NetBSD style could set it
> to 999 for a "maximum" timeout but the final result is less than 1
> second. In that case, we should advise him/her to set it to 99999999.
>
> Thanks
> Max
From weijun.wang at oracle.com Wed May 14 06:04:29 2014
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 14 May 2014 14:04:29 +0800
Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_RFR_8036779:_sun.security.krb5.KdcComm_inte?=
=?utf-8?Q?rprets_kdc=5Ftimeout_asmsec_instead_of_sec?=
Message-ID: <201405140605.s4E65c92029133@userz7021.oracle.com>
What do you mean by detecting the platform? So if I find the file is also used by NetBSD krb5 then I treat it as second and if not millisecond? That's quite impossible. In my opinion, it all depends on how the writer is educated, Java or some else.
How is this unsafe, especially compared to if we don't fix it? The only bad thing is that if someone wants to set the timeout to be less than 120 ms, now there will be no way to do it. But that should never happen, right?
My comment in the bug mentions we can support "5s", but then I realize it dies not really solve the unit-less case.
Thanks
Max
-----????-----
???: Xuelei Fan
????: 2014/5/14 13:21
???: security-dev at openjdk.java.net
??: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout asmsec instead of sec
This does not sound like a safe update to me. Is it possible to
detected the actual kdc_timeout spec (for example, using the known
platform) of the underlying configuration?
Xuelei
On 5/14/2014 8:38 AM, Weijun Wang wrote:
> Please review the code changes at
>
> http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
>
> The problem is that Java treats kdc_timeout as milliseconds but others
> (NetBSD here) might treat it as seconds. With this code change, when the
> number is <= 120, it's seconds, otherwise, milliseconds.
>
> One exception would be that someone thinking NetBSD style could set it
> to 999 for a "maximum" timeout but the final result is less than 1
> second. In that case, we should advise him/her to set it to 99999999.
>
> Thanks
> Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Xuelei.Fan at Oracle.COM Wed May 14 07:19:47 2014
From: Xuelei.Fan at Oracle.COM (Xuelei Fan)
Date: Wed, 14 May 2014 15:19:47 +0800
Subject: =?UTF-8?B?562U5aSNOiBSRlIgODAzNjc3OTogc3VuLnNlY3VyaXR5LmtyYjU=?=
=?UTF-8?B?LktkY0NvbW0gaW50ZXJwcmV0cyBrZGNfdGltZW91dCBhc21zZWMgaW5zdGVhZCA=?=
=?UTF-8?B?b2Ygc2Vj?=
Message-ID: <53731913.90209@Oracle.COM>
On 5/14/2014 2:04 PM, Weijun Wang wrote:
> What do you mean by detecting the platform? So if I find the file is
> also used by NetBSD krb5 then I treat it as second and if not
> millisecond?
Yes.
> That's quite impossible. In my opinion, it all depends on
> how the writer is educated, Java or some else.
>
The spec should be clear, and the writer should be well educated. It
cannot be a condition to update the implementation that the write is not
educated.
> How is this unsafe, especially compared to if we don't fix it? The only
> bad thing is that if someone wants to set the timeout to be less than
> 120 ms, now there will be no way to do it. But that should never happen,
> right?
>
My concerns is that it might happen. 120ms is not a small number, and
120s is not a big number in some circumstances.
Alternatively, for better inerop, we can suggest to use explicit spec in
the configure instead of guess the what the spec is. Support two
default specs is really confusing.
Xuelei
> My comment in the bug mentions we can support "5s", but then I realize
> it dies not really solve the unit-less case.
>
> Thanks
> Max
> ------------------------------------------------------------------------
> ???: Xuelei Fan
> ????: 2014/5/14 13:21
> ???: security-dev at openjdk.java.net
> ??: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
> asmsec instead of sec
>
> This does not sound like a safe update to me. Is it possible to
> detected the actual kdc_timeout spec (for example, using the known
> platform) of the underlying configuration?
>
> Xuelei
>
>
> On 5/14/2014 8:38 AM, Weijun Wang wrote:
> > Please review the code changes at
> >
> > http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
> >
> > The problem is that Java treats kdc_timeout as milliseconds but others
> > (NetBSD here) might treat it as seconds. With this code change, when the
> > number is <= 120, it's seconds, otherwise, milliseconds.
> >
> > One exception would be that someone thinking NetBSD style could set it
> > to 999 for a "maximum" timeout but the final result is less than 1
> > second. In that case, we should advise him/her to set it to 99999999.
> >
> > Thanks
> > Max
>
From christos at zoulas.com Wed May 14 11:51:06 2014
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 14 May 2014 07:51:06 -0400
Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_RFR_8036779:_sun.security.krb5.KdcComm_inte?=
=?utf-8?Q?rprets_kdc=5Ftimeout_asmsec_instead_of_sec?=
In-Reply-To: <201405140605.s4E65c92029133@userz7021.oracle.com>
from Weijun Wang (May 14, 2:04pm)
Message-ID: <20140514115106.8557B17FDA1@rebar.astron.com>
On May 14, 2:04pm, weijun.wang at oracle.com (Weijun Wang) wrote:
-- Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_RFR_8036779:_sun.security.krb5.KdcC
| What do you mean by detecting the platform? So if I find the file is also u=
| sed by NetBSD krb5 then I treat it as second and if not millisecond? That's=
| quite impossible. In my opinion, it all depends on how the writer is educa=
| ted, Java or some else.
|
| How is this unsafe, especially compared to if we don't fix it? The only bad=
| thing is that if someone wants to set the timeout to be less than 120 ms, =
| now there will be no way to do it. But that should never happen, right?
|
| My comment in the bug mentions we can support "5s", but then I realize it d=
| ies not really solve the unit-less case.
There were three major implementations of Kerberos before Java. Two of them
(MIT and Heimdal) used krb5.conf (the third being Microsoft). Both treat naked
time values as seconds. Heimdal just documented better what MIT did, since it
was built with compatibility to the MIT reference implementation in mind:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/krb5.conf.5.html
http://web.mit.edu/kerberos/krb5-devel/doc/basic/date_format.html#duration
Since java is re-using an existing file with an existing format it should
be parsing the values using the same default units. Otherwise it should stop
using that file.
What's even weirder is if java behaves differently depending if I am using
the native OS kerberos libraries instead of the java ones.
christos
From weijun.wang at oracle.com Wed May 14 12:14:18 2014
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 14 May 2014 20:14:18 +0800
Subject: =?UTF-8?B?562U5aSNOiBSRlIgODAzNjc3OTogc3VuLnNlY3VyaXR5LmtyYjU=?=
=?UTF-8?B?LktkY0NvbW0gaW50ZXJwcmV0cyBrZGNfdGltZW91dCBhc21zZWMgaW5zdGVhZCA=?=
=?UTF-8?B?b2Ygc2Vj?=
In-Reply-To: <20140514115106.8557B17FDA1@rebar.astron.com>
References: <20140514115106.8557B17FDA1@rebar.astron.com>
Message-ID: <53735E1A.2000902@oracle.com>
On 5/14/2014 19:51, christos at zoulas.com wrote:
> On May 14, 2:04pm, weijun.wang at oracle.com (Weijun Wang) wrote:
> -- Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_RFR_8036779:_sun.security.krb5.KdcC
>
> | What do you mean by detecting the platform? So if I find the file is also u=
> | sed by NetBSD krb5 then I treat it as second and if not millisecond? That's=
> | quite impossible. In my opinion, it all depends on how the writer is educa=
> | ted, Java or some else.
> |
> | How is this unsafe, especially compared to if we don't fix it? The only bad=
> | thing is that if someone wants to set the timeout to be less than 120 ms, =
> | now there will be no way to do it. But that should never happen, right?
> |
> | My comment in the bug mentions we can support "5s", but then I realize it d=
> | ies not really solve the unit-less case.
>
> There were three major implementations of Kerberos before Java. Two of them
> (MIT and Heimdal) used krb5.conf (the third being Microsoft). Both treat naked
> time values as seconds. Heimdal just documented better what MIT did, since it
> was built with compatibility to the MIT reference implementation in mind:
>
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/krb5.conf.5.html
> http://web.mit.edu/kerberos/krb5-devel/doc/basic/date_format.html#duration
>
> Since java is re-using an existing file with an existing format it should
> be parsing the values using the same default units. Otherwise it should stop
> using that file.
This is correct, but unfortunately Java has parsed that value in a wrong
way for a very long time and has its own compatibility concern now.
That's why I suggest the (value < 120 ? sec : msec) rule. Do you think
it works?
>
> What's even weirder is if java behaves differently depending if I am using
> the native OS kerberos libraries instead of the java ones.
I don't want to be so smart either.
Thanks
Max
>
> christos
>
From weijun.wang at oracle.com Wed May 14 12:24:12 2014
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 14 May 2014 20:24:12 +0800
Subject: =?UTF-8?B?562U5aSNOiBSRlIgODAzNjc3OTogc3VuLnNlY3VyaXR5LmtyYjU=?=
=?UTF-8?B?LktkY0NvbW0gaW50ZXJwcmV0cyBrZGNfdGltZW91dCBhc21zZWMgaW5zdGVhZCA=?=
=?UTF-8?B?b2Ygc2Vj?=
In-Reply-To: <53731913.90209@Oracle.COM>
References: <53731913.90209@Oracle.COM>
Message-ID: <5373606C.7060906@oracle.com>
On 5/14/2014 15:19, Xuelei Fan wrote:
> On 5/14/2014 2:04 PM, Weijun Wang wrote:
>> What do you mean by detecting the platform? So if I find the file is
>> also used by NetBSD krb5 then I treat it as second and if not
>> millisecond?
> Yes.
>
>> That's quite impossible. In my opinion, it all depends on
>> how the writer is educated, Java or some else.
>>
> The spec should be clear, and the writer should be well educated. It
> cannot be a condition to update the implementation that the write is not
> educated.
>
>> How is this unsafe, especially compared to if we don't fix it? The only
>> bad thing is that if someone wants to set the timeout to be less than
>> 120 ms, now there will be no way to do it. But that should never happen,
>> right?
>>
> My concerns is that it might happen. 120ms is not a small number, and
> 120s is not a big number in some circumstances.
120ms and 120s are possible values, but I doubt people will set them in
krb5.conf.
>
> Alternatively, for better inerop, we can suggest to use explicit spec in
> the configure instead of guess the what the spec is. Support two
> default specs is really confusing.
>
Unless we drop kdc_timeout and invent a new key name, we will have to
deal with the correctness (sec) and compatibility (msec) at the same
time. Yes, we can suggest people always adding a unit, but it looks most
people simply put a bare number there.
--Max
> Xuelei
>
>> My comment in the bug mentions we can support "5s", but then I realize
>> it does not really solve the unit-less case.
>>
>> Thanks
>> Max
>> ------------------------------------------------------------------------
>> ???: Xuelei Fan
>> ????: 2014/5/14 13:21
>> ???: security-dev at openjdk.java.net
>> ??: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>> asmsec instead of sec
>>
>> This does not sound like a safe update to me. Is it possible to
>> detected the actual kdc_timeout spec (for example, using the known
>> platform) of the underlying configuration?
>>
>> Xuelei
>>
>>
>> On 5/14/2014 8:38 AM, Weijun Wang wrote:
>> > Please review the code changes at
>> >
>> > http://cr.openjdk.java.net/~weijun/8036779/webrev.00/
>> >
>> > The problem is that Java treats kdc_timeout as milliseconds but others
>> > (NetBSD here) might treat it as seconds. With this code change,
>> when the
>> > number is <= 120, it's seconds, otherwise, milliseconds.
>> >
>> > One exception would be that someone thinking NetBSD style could set it
>> > to 999 for a "maximum" timeout but the final result is less than 1
>> > second. In that case, we should advise him/her to set it to 99999999.
>> >
>> > Thanks
>> > Max
>>
>
From xuelei.fan at oracle.com Thu May 15 01:27:11 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 May 2014 09:27:11 +0800
Subject: =?UTF-8?B?562U5aSNOiBSRlIgODAzNjc3OTogc3VuLnNlY3VyaXR5LmtyYjU=?=
=?UTF-8?B?LktkY0NvbW0gaW50ZXJwcmV0cyBrZGNfdGltZW91dCBhc21zZWMgaW5zdGVhZCA=?=
=?UTF-8?B?b2Ygc2Vj?=
In-Reply-To: <5373606C.7060906@oracle.com>
References: <53731913.90209@Oracle.COM> <5373606C.7060906@oracle.com>
Message-ID: <537417EF.104@oracle.com>
On 5/14/2014 8:24 PM, Weijun Wang wrote:
>>> How is this unsafe, especially compared to if we don't fix it? The only
>>> bad thing is that if someone wants to set the timeout to be less than
>>> 120 ms, now there will be no way to do it. But that should never happen,
>>> right?
>>>
>> My concerns is that it might happen. 120ms is not a small number, and
>> 120s is not a big number in some circumstances.
>
> 120ms and 120s are possible values,
So it is really confusing to me that 119 will be treated as seconds, and
121 will be treated as milliseconds.
> but I doubt people will set them in
> krb5.conf.
>
I did not get your idea. People won't use kdc_timeout option at all?
>>
>> Alternatively, for better inerop, we can suggest to use explicit spec in
>> the configure instead of guess the what the spec is. Support two
>> default specs is really confusing.
>>
>
> Unless we drop kdc_timeout and invent a new key name, we will have to
> deal with the correctness (sec) and compatibility (msec) at the same
> time. Yes, we can suggest people always adding a unit, but it looks most
> people simply put a bare number there.
IMHO, just declare it as a known issue of Java is an alternative
approach I may prefer.
Is Java the only implementation to use milliseconds in the
configuration? Do we have public specification for the kdc_timeout
option? Or we just declare we follow the industry conversions? If Java
is the only vendor to use milliseconds wrongly, it may be OK to make the
correction in a major release (JDK 9?).
Xuelei
From weijun.wang at oracle.com Thu May 15 01:41:09 2014
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 15 May 2014 09:41:09 +0800
Subject: =?UTF-8?B?562U5aSNOiBSRlIgODAzNjc3OTogc3VuLnNlY3VyaXR5LmtyYjU=?=
=?UTF-8?B?LktkY0NvbW0gaW50ZXJwcmV0cyBrZGNfdGltZW91dCBhc21zZWMgaW5zdGVhZCA=?=
=?UTF-8?B?b2Ygc2Vj?=
In-Reply-To: <537417EF.104@oracle.com>
References: <53731913.90209@Oracle.COM> <5373606C.7060906@oracle.com>
<537417EF.104@oracle.com>
Message-ID: <53741B35.3010407@oracle.com>
On 5/15/2014 9:27, Xuelei Fan wrote:
> On 5/14/2014 8:24 PM, Weijun Wang wrote:
>>>> How is this unsafe, especially compared to if we don't fix it? The only
>>>> bad thing is that if someone wants to set the timeout to be less than
>>>> 120 ms, now there will be no way to do it. But that should never happen,
>>>> right?
>>>>
>>> My concerns is that it might happen. 120ms is not a small number, and
>>> 120s is not a big number in some circumstances.
>>
>> 120ms and 120s are possible values,
> So it is really confusing to me that 119 will be treated as seconds, and
> 121 will be treated as milliseconds.
This is unfortunate, we can document it.
>
>> but I doubt people will set them in
>> krb5.conf.
>>
> I did not get your idea. People won't use kdc_timeout option at all?
No, what I mean is people is not likely to set these values as
kdc_timeout. If someone sets it to 120ms it means he does not want to
wait more than that and would rather switch to another KDC or fail. That
looks too impatient. If someone sets it to 120s, that is a too long time
for me. In general, 3 sec to 30 sec sounds sane.
>
>>>
>>> Alternatively, for better inerop, we can suggest to use explicit spec in
>>> the configure instead of guess the what the spec is. Support two
>>> default specs is really confusing.
>>>
>>
>> Unless we drop kdc_timeout and invent a new key name, we will have to
>> deal with the correctness (sec) and compatibility (msec) at the same
>> time. Yes, we can suggest people always adding a unit, but it looks most
>> people simply put a bare number there.
> IMHO, just declare it as a known issue of Java is an alternative
> approach I may prefer.
>
> Is Java the only implementation to use milliseconds in the
> configuration? Do we have public specification for the kdc_timeout
> option? Or we just declare we follow the industry conversions? If Java
> is the only vendor to use milliseconds wrongly, it may be OK to make the
> correction in a major release (JDK 9?).
We should be the only one using msec.
Java SE have a public spec saying the default value is 30000, that
implies we uses msec. Oracle has other doc claiming it's msec:
http://docs.oracle.com/cd/E19728-01/820-2550/activedir_auth.html
If we just change to sec it is a big compatibility issue. User won't
notice any error report expect finding their app runs much slower.
Thanks
Max
>
> Xuelei
>
From xuelei.fan at oracle.com Thu May 15 02:09:38 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 May 2014 10:09:38 +0800
Subject: =?UTF-8?B?562U5aSNOiBSRlIgODAzNjc3OTogc3VuLnNlY3VyaXR5LmtyYjU=?=
=?UTF-8?B?LktkY0NvbW0gaW50ZXJwcmV0cyBrZGNfdGltZW91dCBhc21zZWMgaW5zdGVhZCA=?=
=?UTF-8?B?b2Ygc2Vj?=
In-Reply-To: <53741B35.3010407@oracle.com>
References: <53731913.90209@Oracle.COM> <5373606C.7060906@oracle.com>
<537417EF.104@oracle.com> <53741B35.3010407@oracle.com>
Message-ID: <537421E2.3070002@oracle.com>
On 5/15/2014 9:41 AM, Weijun Wang wrote:
>
> On 5/15/2014 9:27, Xuelei Fan wrote:
>> On 5/14/2014 8:24 PM, Weijun Wang wrote:
>>>>> How is this unsafe, especially compared to if we don't fix it? The
>>>>> only
>>>>> bad thing is that if someone wants to set the timeout to be less than
>>>>> 120 ms, now there will be no way to do it. But that should never
>>>>> happen,
>>>>> right?
>>>>>
>>>> My concerns is that it might happen. 120ms is not a small number, and
>>>> 120s is not a big number in some circumstances.
>>>
>>> 120ms and 120s are possible values,
>> So it is really confusing to me that 119 will be treated as seconds, and
>> 121 will be treated as milliseconds.
>
> This is unfortunate, we can document it.
>
The actual problem is, what if I want to use 121 seconds? It is a
possible timeout value in practice.
>>
>>> but I doubt people will set them in
>>> krb5.conf.
>>>
>> I did not get your idea. People won't use kdc_timeout option at all?
>
> No, what I mean is people is not likely to set these values as
> kdc_timeout. If someone sets it to 120ms it means he does not want to
> wait more than that and would rather switch to another KDC or fail. That
> looks too impatient. If someone sets it to 120s, that is a too long time
> for me. In general, 3 sec to 30 sec sounds sane.
>
As I said, in some circumstance 120ms is too big (two notes in a
cluster?); however, it some other circumstance, 120s is too
small(limited bandwidth network?). We cannot guess what's the proper
value before we exactly know what the circumstance is. Actually, we
cannot know that for every deployment. So it does not sound like a safe
fix to me to use a mixed spec.
>>
>>>>
>>>> Alternatively, for better inerop, we can suggest to use explicit
>>>> spec in
>>>> the configure instead of guess the what the spec is. Support two
>>>> default specs is really confusing.
>>>>
>>>
>>> Unless we drop kdc_timeout and invent a new key name, we will have to
>>> deal with the correctness (sec) and compatibility (msec) at the same
>>> time. Yes, we can suggest people always adding a unit, but it looks most
>>> people simply put a bare number there.
>> IMHO, just declare it as a known issue of Java is an alternative
>> approach I may prefer.
>>
>> Is Java the only implementation to use milliseconds in the
>> configuration? Do we have public specification for the kdc_timeout
>> option? Or we just declare we follow the industry conversions? If Java
>> is the only vendor to use milliseconds wrongly, it may be OK to make the
>> correction in a major release (JDK 9?).
>
> We should be the only one using msec.
>
Oops!
> Java SE have a public spec saying the default value is 30000, that
> implies we uses msec. Oracle has other doc claiming it's msec:
>
> http://docs.oracle.com/cd/E19728-01/820-2550/activedir_auth.html
>
> If we just change to sec it is a big compatibility issue. User won't
> notice any error report expect finding their app runs much slower.
>
Then I would suggest to declare it as a known issue, and suggest to use
explicit spec in practice.
Xuelei
> Thanks
> Max
>
>>
>> Xuelei
>>
From fweimer at redhat.com Thu May 15 08:23:25 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 15 May 2014 10:23:25 +0200
Subject: =?UTF-8?B?562U5aSNOiBSRlIgODAzNjc3OTogc3VuLnNlY3VyaXR5LmtyYjU=?=
=?UTF-8?B?LktkY0NvbW0gaW50ZXJwcmV0cyBrZGNfdGltZW91dCBhc21zZWMgaW5zdGVhZCA=?=
=?UTF-8?B?b2Ygc2Vj?=
In-Reply-To: <537421E2.3070002@oracle.com>
References: <53731913.90209@Oracle.COM>
<5373606C.7060906@oracle.com> <537417EF.104@oracle.com>
<53741B35.3010407@oracle.com> <537421E2.3070002@oracle.com>
Message-ID: <5374797D.3080103@redhat.com>
On 05/15/2014 04:09 AM, Xuelei Fan wrote:
> The actual problem is, what if I want to use 121 seconds? It is a
> possible timeout value in practice.
I assume you could specify it as 121000 milliseconds. :-)
--
Florian Weimer / Red Hat Product Security Team
From valerie.peng at oracle.com Thu May 15 23:08:30 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Thu, 15 May 2014 16:08:30 -0700
Subject: RFR 8027575: b113 causing a lot of memory allocation and regression
for wls_webapp_atomics
Message-ID: <537548EE.5050909@oracle.com>
Can someone help reviewing this SunJCE provider fix? Essentially,
CipherCore class is updated to minimize memory allocation and data
copying. The fix has been verified against the wls_webapp_atomics benchmark.
Webrev: http://cr.openjdk.java.net/~valeriep/8027575/webrev.00/
Thanks,
Valerie
From valerie.peng at oracle.com Thu May 15 23:11:03 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Thu, 15 May 2014 16:11:03 -0700
Subject: RFR 8037745: Consider re-enabling PKCS11 mechanisms previously
disabled due to Solaris bug 7050617
Message-ID: <53754987.3090802@oracle.com>
Tony,
Can you please help reviewing this PKCS11 provider configuration file
change?
This is for removing the digest related mechs from the disabledMechanism
section now that relevant native bugs have been fixed.
Webrev: http://cr.openjdk.java.net/~valeriep/8037745/webrev.00/
Thanks,
Valerie
From bradford.wetmore at oracle.com Fri May 16 00:21:46 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 15 May 2014 17:21:46 -0700
Subject: RFR 8037745: Consider re-enabling PKCS11 mechanisms previously
disabled due to Solaris bug 7050617
In-Reply-To: <53754987.3090802@oracle.com>
References: <53754987.3090802@oracle.com>
Message-ID: <53755A1A.8040207@oracle.com>
Whoo Hoo. :)
Looks good.
Brad
On 5/15/2014 4:11 PM, Valerie (Yu-Ching) Peng wrote:
> Tony,
>
> Can you please help reviewing this PKCS11 provider configuration file
> change?
> This is for removing the digest related mechs from the disabledMechanism
> section now that relevant native bugs have been fixed.
>
> Webrev: http://cr.openjdk.java.net/~valeriep/8037745/webrev.00/
>
> Thanks,
> Valerie
From anthony.scarpino at oracle.com Fri May 16 00:43:07 2014
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 15 May 2014 17:43:07 -0700
Subject: RFR 8037745: Consider re-enabling PKCS11 mechanisms previously
disabled due to Solaris bug 7050617
In-Reply-To: <53754987.3090802@oracle.com>
References: <53754987.3090802@oracle.com>
Message-ID: <252DD3F2-1C1C-479E-82F5-0127E25DE323@oracle.com>
Looks good
Tony
> On May 15, 2014, at 4:11 PM, "Valerie (Yu-Ching) Peng" wrote:
>
> Tony,
>
> Can you please help reviewing this PKCS11 provider configuration file change?
> This is for removing the digest related mechs from the disabledMechanism section now that relevant native bugs have been fixed.
>
> Webrev: http://cr.openjdk.java.net/~valeriep/8037745/webrev.00/
>
> Thanks,
> Valerie
From rob.mckenna at oracle.com Fri May 16 14:29:44 2014
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 16 May 2014 15:29:44 +0100
Subject: RFR - 8028627: Unsynchronized code path from javax.crypto.Cipher
to the WeakHashMap used by JceSecurity to store codebase mappings
Message-ID: <537620D8.7090906@oracle.com>
Hi folks,
The synopsis says it all really. There is an unsynchronized code path
from javax.crypto.Cipher to the WeakHashMap used by JceSecurity to store
codebase mappings. While this bug is extremely unlikely to manifest we
have a couple of reports of it in the wild.
As you can see from the following webrev I'm simply syncing on the
WeakHashMap.
http://cr.openjdk.java.net/~robm/8028627/webrev.01/
-Rob
From ivan.gerasimov at oracle.com Fri May 16 15:54:54 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 16 May 2014 19:54:54 +0400
Subject: RFR [7195480]: javax.smartcardio does not detect cards on Mac OS
X
Message-ID: <537634CE.2020007@oracle.com>
Hello!
It was reported that CardTerminal.isCardPresent(),
CardTerminal.waitForCardAbsent(...) and
CardTerminal.waitForCardPresent(...) do not work correctly on Mac OS X.
It is due to the difference in the types of the fields of
SCARD_READERSTATE structure used across different platforms.
In addition to the field type correction, it is also needed to make sure
the fields are aligned correctly.
I made sure that the total size of the structure (61 bytes) is correct
by requesting information about the same reader twice:
(had to mess with sun.security.smartcardio.PCSC.SCardGetStatusChange() a
bit to check, but didn't include it the test).
No new tests go with the fix.
The already existing manual test
jdk/test/sun/security/smartcardio/TestPresent.java can be used to
demonstrate the bug with the current jdk.
With the fix this test isn't failing.
I assume that the correct behavior in the case of several card readers
can be checked with
jdk/test/sun/security/smartcardio/TestMultiplePresent.java, but cannot
check it myself as I don't currently have access to a mac comp with more
than one readers.
Would you please help review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-7195480
WEBREV: http://cr.openjdk.java.net/~igerasim/7195480/0/webrev/
Sincerely yours,
Ivan
From sean.mullan at oracle.com Fri May 16 16:52:14 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 16 May 2014 12:52:14 -0400
Subject: RFR - 8028627: Unsynchronized code path from javax.crypto.Cipher
to the WeakHashMap used by JceSecurity to store codebase mappings
In-Reply-To: <537620D8.7090906@oracle.com>
References: <537620D8.7090906@oracle.com>
Message-ID: <5376423E.5030705@oracle.com>
Looks ok to me. While you are in there, can you fix the typo a couple
lines above that:
s/Retuns/Returns
You also need to add an appropriate "noreg" label to the bug.
--Sean
On 05/16/2014 10:29 AM, Rob McKenna wrote:
> Hi folks,
>
> The synopsis says it all really. There is an unsynchronized code path
> from javax.crypto.Cipher to the WeakHashMap used by JceSecurity to store
> codebase mappings. While this bug is extremely unlikely to manifest we
> have a couple of reports of it in the wild.
>
> As you can see from the following webrev I'm simply syncing on the
> WeakHashMap.
>
> http://cr.openjdk.java.net/~robm/8028627/webrev.01/
>
> -Rob
>
From weijun.wang at oracle.com Sun May 18 02:06:30 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sun, 18 May 2014 10:06:30 +0800
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
asmsec instead of sec
In-Reply-To: <537421E2.3070002@oracle.com>
References: <53731913.90209@Oracle.COM> <5373606C.7060906@oracle.com>
<537417EF.104@oracle.com> <53741B35.3010407@oracle.com>
<537421E2.3070002@oracle.com>
Message-ID:
How about this? I will support "s" and "ms" units ("ms" is not defined by other vendors though). But will still try to be a little smart when there is no unit.
--Max
On May 15, 2014, at 10:09, Xuelei Fan wrote:
> The actual problem is, what if I want to use 121 seconds? It is a
> possible timeout value in practice.
>
>>
>> If we just change to sec it is a big compatibility issue. User won't
>> notice any error report expect finding their app runs much slower.
>>
> Then I would suggest to declare it as a known issue, and suggest to use
> explicit spec in practice.
From christos at zoulas.com Sun May 18 13:48:20 2014
From: christos at zoulas.com (Christos Zoulas)
Date: Sun, 18 May 2014 09:48:20 -0400
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
asmsec instead of sec
In-Reply-To:
from Wang Weijun (May 18, 10:06am)
Message-ID: <20140518134820.6A65C17FDA1@rebar.astron.com>
On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
-- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
| How about this? I will support "s" and "ms" units ("ms" is not defined by o=
| ther vendors though). But will still try to be a little smart when there is=
| no unit.
Heuristics can make the situation worse; they are difficult to document
and explain to users. But if java is going to support ms, let's coordinate
with heimdal and mit to make them support it too.
christos
From Xuelei.Fan at Oracle.Com Sun May 18 15:12:00 2014
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Sun, 18 May 2014 23:12:00 +0800
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
asmsec instead of sec
In-Reply-To: <20140518134820.6A65C17FDA1@rebar.astron.com>
References: <20140518134820.6A65C17FDA1@rebar.astron.com>
Message-ID: <5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
> On May 18, 2014, at 9:48 PM, christos at zoulas.com wrote:
>
> On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
> -- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>
> | How about this? I will support "s" and "ms" units ("ms" is not defined by o=
> | ther vendors though). But will still try to be a little smart when there is=
> | no unit.
>
> Heuristics can make the situation worse; they are difficult to document
> and explain to users. But if java is going to support ms, let's coordinate
> with heimdal and mit to make them support it too.
>
+1
Xuelei
> christos
>
From weijun.wang at oracle.com Mon May 19 02:36:30 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 19 May 2014 10:36:30 +0800
Subject: unit of kdc_timeout
Message-ID: <89E3CA2D-4B92-4F89-A42B-A1535F96B1FD@oracle.com>
Hi All
I am a member of Oracle's Java SE security team, and recently we found a bug about the inconsistency of the kdc_timeout setting between Java and other vendors. Java does not support specifying a unit and always treats the value as milliseconds. While the others support units and when no unit is given the value means seconds.
We are going to fix this bug by first supporting the "s" unit. To give a chance for old Java users to specify milliseconds, we plan to also support "ms". Do you think it's useful? i.e. Do customers have a requirement of setting the timeout to be less than one second? Of course, the most difficult thing we (Java) need to determine is what to do when there is no unit. I am thinking of a (v>120 ? ms: s) heuristics but it could be dangerous. I am not asking any other vendor to follow this style, but do you know how people are setting this value?
I do notice MIT's krb5 doc has no kdc_timeout at all. Maybe the algorithm does not care about it anymore?
Thanks
Max
From weijun.wang at oracle.com Mon May 19 02:38:48 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 19 May 2014 10:38:48 +0800
Subject: unit of kdc_timeout
Message-ID: <76AF0108-F8AE-45AF-8C8D-247A77EBA49C@oracle.com>
Hi All
I am a member of Oracle's Java SE security team, and recently we found a bug about the inconsistency of the kdc_timeout setting between Java and other vendors. Java does not support specifying a unit and always treats the value as milliseconds. While the others support units and when no unit is given the value means seconds.
We are going to fix this bug by first supporting the "s" unit. To give a chance for old Java users to specify milliseconds, we plan to also support "ms". Do you think it's useful? i.e. Do customers have a requirement of setting the timeout to be less than one second? Of course, the most difficult thing we (Java) need to determine is what to do when there is no unit. I am thinking of a (v>120 ? ms: s) heuristics but it could be dangerous. I am not asking any other vendor to follow this style, but do you know how people are setting this value?
I do notice MIT's krb5 doc has no kdc_timeout at all. Maybe the algorithm does not care about it anymore?
Thanks
Max
From hbhotz at oxy.edu Mon May 19 03:06:58 2014
From: hbhotz at oxy.edu (Henry B Hotz)
Date: Sun, 18 May 2014 20:06:58 -0700
Subject: unit of kdc_timeout
In-Reply-To: <76AF0108-F8AE-45AF-8C8D-247A77EBA49C@oracle.com>
References: <76AF0108-F8AE-45AF-8C8D-247A77EBA49C@oracle.com>
Message-ID:
I presume this is for parameters specified the "Java way", and you do the right thing when you're reading a krb5.conf file.
I can't personally think of anything where I would care about a sub-second value. OTOH the standard timeout for kinit is 1 second so it seems possible someone else might.
On May 18, 2014, at 7:38 PM, Wang Weijun wrote:
> Hi All
>
> I am a member of Oracle's Java SE security team, and recently we found a bug about the inconsistency of the kdc_timeout setting between Java and other vendors. Java does not support specifying a unit and always treats the value as milliseconds. While the others support units and when no unit is given the value means seconds.
>
> We are going to fix this bug by first supporting the "s" unit. To give a chance for old Java users to specify milliseconds, we plan to also support "ms". Do you think it's useful? i.e. Do customers have a requirement of setting the timeout to be less than one second? Of course, the most difficult thing we (Java) need to determine is what to do when there is no unit. I am thinking of a (v>120 ? ms: s) heuristics but it could be dangerous. I am not asking any other vendor to follow this style, but do you know how people are setting this value?
>
> I do notice MIT's krb5 doc has no kdc_timeout at all. Maybe the algorithm does not care about it anymore?
>
> Thanks
> Max
>
Personal email. hbhotz at oxy.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sean.coffey at oracle.com Mon May 19 09:30:09 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Mon, 19 May 2014 10:30:09 +0100
Subject: RFR [7195480]: javax.smartcardio does not detect cards on Mac OS X
In-Reply-To: <537634CE.2020007@oracle.com>
References: <537634CE.2020007@oracle.com>
Message-ID: <5379CF21.4050107@oracle.com>
Hopefully a member of the security team can help review this Ivan. It
looks good to me. I'm not sure if QA run any smart card tests on mac -
doesn't look like it! It could be worth following up with them to ensure
they add this to their test configurations.
One note on the 'noreg-existing' label. It's not one of the official
ones from the openJDK developer doc [1]. There's quite a few occurrences
of it though. I'd suggest something like 'noreg-sqe'. You already have a
pointer to the testcase in the bug report.
regards,
Sean.
On 16/05/14 16:54, Ivan Gerasimov wrote:
> Hello!
>
> It was reported that CardTerminal.isCardPresent(),
> CardTerminal.waitForCardAbsent(...) and
> CardTerminal.waitForCardPresent(...) do not work correctly on Mac OS X.
> It is due to the difference in the types of the fields of
> SCARD_READERSTATE structure used across different platforms.
>
> In addition to the field type correction, it is also needed to make
> sure the fields are aligned correctly.
> I made sure that the total size of the structure (61 bytes) is correct
> by requesting information about the same reader twice:
> (had to mess with sun.security.smartcardio.PCSC.SCardGetStatusChange()
> a bit to check, but didn't include it the test).
>
> No new tests go with the fix.
> The already existing manual test
> jdk/test/sun/security/smartcardio/TestPresent.java can be used to
> demonstrate the bug with the current jdk.
> With the fix this test isn't failing.
>
> I assume that the correct behavior in the case of several card readers
> can be checked with
> jdk/test/sun/security/smartcardio/TestMultiplePresent.java, but cannot
> check it myself as I don't currently have access to a mac comp with
> more than one readers.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7195480
> WEBREV: http://cr.openjdk.java.net/~igerasim/7195480/0/webrev/
>
> Sincerely yours,
> Ivan
From ivan.gerasimov at oracle.com Mon May 19 10:20:11 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 19 May 2014 14:20:11 +0400
Subject: RFR [7195480]: javax.smartcardio does not detect cards on Mac OS X
In-Reply-To: <5379CF21.4050107@oracle.com>
References: <537634CE.2020007@oracle.com> <5379CF21.4050107@oracle.com>
Message-ID: <5379DADB.2010307@oracle.com>
Thanks Se?n!
Yes, I was in doubt which noreg- label to choose. noreg-sqe seems to be
more appropriate, so I set it.
Sincerely yours,
Ivan
On 19.05.2014 13:30, Se?n Coffey wrote:
> Hopefully a member of the security team can help review this Ivan. It
> looks good to me. I'm not sure if QA run any smart card tests on mac -
> doesn't look like it! It could be worth following up with them to
> ensure they add this to their test configurations.
>
> One note on the 'noreg-existing' label. It's not one of the official
> ones from the openJDK developer doc [1]. There's quite a few
> occurrences of it though. I'd suggest something like 'noreg-sqe'. You
> already have a pointer to the testcase in the bug report.
>
> regards,
> Sean.
>
> On 16/05/14 16:54, Ivan Gerasimov wrote:
>> Hello!
>>
>> It was reported that CardTerminal.isCardPresent(),
>> CardTerminal.waitForCardAbsent(...) and
>> CardTerminal.waitForCardPresent(...) do not work correctly on Mac OS X.
>> It is due to the difference in the types of the fields of
>> SCARD_READERSTATE structure used across different platforms.
>>
>> In addition to the field type correction, it is also needed to make
>> sure the fields are aligned correctly.
>> I made sure that the total size of the structure (61 bytes) is
>> correct by requesting information about the same reader twice:
>> (had to mess with
>> sun.security.smartcardio.PCSC.SCardGetStatusChange() a bit to check,
>> but didn't include it the test).
>>
>> No new tests go with the fix.
>> The already existing manual test
>> jdk/test/sun/security/smartcardio/TestPresent.java can be used to
>> demonstrate the bug with the current jdk.
>> With the fix this test isn't failing.
>>
>> I assume that the correct behavior in the case of several card
>> readers can be checked with
>> jdk/test/sun/security/smartcardio/TestMultiplePresent.java, but
>> cannot check it myself as I don't currently have access to a mac comp
>> with more than one readers.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7195480
>> WEBREV: http://cr.openjdk.java.net/~igerasim/7195480/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>
>
>
From rob.mckenna at oracle.com Mon May 19 12:49:18 2014
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 19 May 2014 13:49:18 +0100
Subject: RFR - 8028627: Unsynchronized code path from javax.crypto.Cipher
to the WeakHashMap used by JceSecurity to store codebase mappings
In-Reply-To: <5376423E.5030705@oracle.com>
References: <537620D8.7090906@oracle.com> <5376423E.5030705@oracle.com>
Message-ID: <5379FDCE.3050300@oracle.com>
Thanks Sean, will do.
-Rob
On 16/05/14 17:52, Sean Mullan wrote:
> Looks ok to me. While you are in there, can you fix the typo a couple
> lines above that:
>
> s/Retuns/Returns
>
> You also need to add an appropriate "noreg" label to the bug.
>
> --Sean
>
> On 05/16/2014 10:29 AM, Rob McKenna wrote:
>> Hi folks,
>>
>> The synopsis says it all really. There is an unsynchronized code path
>> from javax.crypto.Cipher to the WeakHashMap used by JceSecurity to store
>> codebase mappings. While this bug is extremely unlikely to manifest we
>> have a couple of reports of it in the wild.
>>
>> As you can see from the following webrev I'm simply syncing on the
>> WeakHashMap.
>>
>> http://cr.openjdk.java.net/~robm/8028627/webrev.01/
>>
>> -Rob
>>
From weijun.wang at oracle.com Mon May 19 13:49:53 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 19 May 2014 21:49:53 +0800
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
asmsec instead of sec
In-Reply-To: <5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
References: <20140518134820.6A65C17FDA1@rebar.astron.com>
<5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
Message-ID:
After some discussion with mit and heimdal lead engineers, I don't want to support ms at the moment. mit does not use kdc_timeout at all and heimdal's internal presentation is of seconds.
So this is my plan: support "s" but if unspecified treat it as "ms". There will be a release notes describing this. This won't automatically fix the case for the bug reporter but at least give him a workaround -- use the 's' unit for interop.
Does this sound clean?
Thanks
Max
On May 18, 2014, at 23:12, Xuelei Fan wrote:
>
>> On May 18, 2014, at 9:48 PM, christos at zoulas.com wrote:
>>
>> On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
>> -- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>>
>> | How about this? I will support "s" and "ms" units ("ms" is not defined by o=
>> | ther vendors though). But will still try to be a little smart when there is=
>> | no unit.
>>
>> Heuristics can make the situation worse; they are difficult to document
>> and explain to users. But if java is going to support ms, let's coordinate
>> with heimdal and mit to make them support it too.
>>
> +1
>
> Xuelei
>
>> christos
>>
From xuelei.fan at oracle.com Mon May 19 14:18:17 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 19 May 2014 22:18:17 +0800
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
asmsec instead of sec
In-Reply-To:
References: <20140518134820.6A65C17FDA1@rebar.astron.com>
<5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
Message-ID: <537A12A9.8060602@oracle.com>
On 5/19/2014 9:49 PM, Wang Weijun wrote:
> After some discussion with mit and heimdal lead engineers, I don't want to support ms at the moment. mit does not use kdc_timeout at all and heimdal's internal presentation is of seconds.
>
> So this is my plan: support "s" but if unspecified treat it as "ms". There will be a release notes describing this. This won't automatically fix the case for the bug reporter but at least give him a workaround -- use the 's' unit for interop.
>
+1
Xuelei
> Does this sound clean?
>
> Thanks
> Max
>
> On May 18, 2014, at 23:12, Xuelei Fan wrote:
>
>>
>>> On May 18, 2014, at 9:48 PM, christos at zoulas.com wrote:
>>>
>>> On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
>>> -- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>>>
>>> | How about this? I will support "s" and "ms" units ("ms" is not defined by o=
>>> | ther vendors though). But will still try to be a little smart when there is=
>>> | no unit.
>>>
>>> Heuristics can make the situation worse; they are difficult to document
>>> and explain to users. But if java is going to support ms, let's coordinate
>>> with heimdal and mit to make them support it too.
>>>
>> +1
>>
>> Xuelei
>>
>>> christos
>>>
>
From ghudson at MIT.EDU Mon May 19 03:10:51 2014
From: ghudson at MIT.EDU (Greg Hudson)
Date: Sun, 18 May 2014 23:10:51 -0400
Subject: unit of kdc_timeout
In-Reply-To: <89E3CA2D-4B92-4F89-A42B-A1535F96B1FD@oracle.com>
References: <89E3CA2D-4B92-4F89-A42B-A1535F96B1FD@oracle.com>
Message-ID: <5379763B.9080305@mit.edu>
On 05/18/2014 10:36 PM, Wang Weijun wrote:
> I do notice MIT's krb5 doc has no kdc_timeout at all.
MIT krb5's sendto_kdc timeouts are all hardcoded and, as far as I can
tell, they always have been. Way back in 1.2, there were some global
variables which a sufficiently dodgy application could set, but there
still doesn't seem to have been a public interface for changing them.
From lha at kth.se Mon May 19 06:16:15 2014
From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=)
Date: Mon, 19 May 2014 06:16:15 +0000
Subject: unit of kdc_timeout
In-Reply-To:
References: <76AF0108-F8AE-45AF-8C8D-247A77EBA49C@oracle.com>,
Message-ID: <05DFD8BD-E48A-4CE4-8F7B-B116604B7E79@kth.se>
A sub second unit would be used. However we use time_t, so currently sub second time is not possible in Heimdal.
The default unit is seconds.
Skickat fr?n min iPad
19 maj 2014 kl. 05:07 skrev "Henry B Hotz" >:
I presume this is for parameters specified the "Java way", and you do the right thing when you're reading a krb5.conf file.
I can't personally think of anything where I would care about a sub-second value. OTOH the standard timeout for kinit is 1 second so it seems possible someone else might.
On May 18, 2014, at 7:38 PM, Wang Weijun > wrote:
Hi All
I am a member of Oracle's Java SE security team, and recently we found a bug about the inconsistency of the kdc_timeout setting between Java and other vendors. Java does not support specifying a unit and always treats the value as milliseconds. While the others support units and when no unit is given the value means seconds.
We are going to fix this bug by first supporting the "s" unit. To give a chance for old Java users to specify milliseconds, we plan to also support "ms". Do you think it's useful? i.e. Do customers have a requirement of setting the timeout to be less than one second? Of course, the most difficult thing we (Java) need to determine is what to do when there is no unit. I am thinking of a (v>120 ? ms: s) heuristics but it could be dangerous. I am not asking any other vendor to follow this style, but do you know how people are setting this value?
I do notice MIT's krb5 doc has no kdc_timeout at all. Maybe the algorithm does not care about it anymore?
Thanks
Max
Personal email. hbhotz at oxy.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From valerie.peng at oracle.com Mon May 19 23:16:35 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Mon, 19 May 2014 16:16:35 -0700
Subject: RFR [7195480]: javax.smartcardio does not detect cards on Mac OS X
In-Reply-To: <537634CE.2020007@oracle.com>
References: <537634CE.2020007@oracle.com>
Message-ID: <537A90D3.3060201@oracle.com>
Changes look fine to me.
Thanks,
Valerie
On 05/16/14 08:54, Ivan Gerasimov wrote:
> Hello!
>
> It was reported that CardTerminal.isCardPresent(),
> CardTerminal.waitForCardAbsent(...) and
> CardTerminal.waitForCardPresent(...) do not work correctly on Mac OS X.
> It is due to the difference in the types of the fields of
> SCARD_READERSTATE structure used across different platforms.
>
> In addition to the field type correction, it is also needed to make
> sure the fields are aligned correctly.
> I made sure that the total size of the structure (61 bytes) is correct
> by requesting information about the same reader twice:
> (had to mess with sun.security.smartcardio.PCSC.SCardGetStatusChange()
> a bit to check, but didn't include it the test).
>
> No new tests go with the fix.
> The already existing manual test
> jdk/test/sun/security/smartcardio/TestPresent.java can be used to
> demonstrate the bug with the current jdk.
> With the fix this test isn't failing.
>
> I assume that the correct behavior in the case of several card readers
> can be checked with
> jdk/test/sun/security/smartcardio/TestMultiplePresent.java, but cannot
> check it myself as I don't currently have access to a mac comp with
> more than one readers.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7195480
> WEBREV: http://cr.openjdk.java.net/~igerasim/7195480/0/webrev/
>
> Sincerely yours,
> Ivan
From ivan.gerasimov at oracle.com Tue May 20 05:46:26 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 20 May 2014 09:46:26 +0400
Subject: RFR [7195480]: javax.smartcardio does not detect cards on Mac OS X
In-Reply-To: <537A90D3.3060201@oracle.com>
References: <537634CE.2020007@oracle.com> <537A90D3.3060201@oracle.com>
Message-ID: <537AEC32.8070004@oracle.com>
Thank you Valerie!
On 20.05.2014 3:16, Valerie (Yu-Ching) Peng wrote:
> Changes look fine to me.
> Thanks,
> Valerie
>
>
> On 05/16/14 08:54, Ivan Gerasimov wrote:
>> Hello!
>>
>> It was reported that CardTerminal.isCardPresent(),
>> CardTerminal.waitForCardAbsent(...) and
>> CardTerminal.waitForCardPresent(...) do not work correctly on Mac OS X.
>> It is due to the difference in the types of the fields of
>> SCARD_READERSTATE structure used across different platforms.
>>
>> In addition to the field type correction, it is also needed to make
>> sure the fields are aligned correctly.
>> I made sure that the total size of the structure (61 bytes) is
>> correct by requesting information about the same reader twice:
>> (had to mess with
>> sun.security.smartcardio.PCSC.SCardGetStatusChange() a bit to check,
>> but didn't include it the test).
>>
>> No new tests go with the fix.
>> The already existing manual test
>> jdk/test/sun/security/smartcardio/TestPresent.java can be used to
>> demonstrate the bug with the current jdk.
>> With the fix this test isn't failing.
>>
>> I assume that the correct behavior in the case of several card
>> readers can be checked with
>> jdk/test/sun/security/smartcardio/TestMultiplePresent.java, but
>> cannot check it myself as I don't currently have access to a mac comp
>> with more than one readers.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7195480
>> WEBREV: http://cr.openjdk.java.net/~igerasim/7195480/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>
>
>
From ivan.gerasimov at oracle.com Tue May 20 11:00:46 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 20 May 2014 15:00:46 +0400
Subject: RFR [8043507]: javax.smartcardio.CardTerminals.list() fails on MacOSX
Message-ID: <537B35DE.60605@oracle.com>
Hello!
The function javax.smartcardio.CardTerminals.list() sometimes fails when
called from an app running on MacOSX.
The problem is due to that CALL_SCardListReaders(_, _, _, &size) expects
the size variable to be of size uint32_t on os x, but we provide a
pointer to 64 bit int instead.
As a result, the higher bits may contain garbage upon return, and we try
to allocate a too large block of memory.
The simplest solution is to initialize 'size' to zero before the call.
No new tests with the fix, as the exiting tests already demonstrate
intermittent failures because of this bug.
For example, I've seem how ./sun/security/smartcardio/TestDefault.java
failed once on every few hundred runs.
With the fix this test doesn't fail even when running in a loop with
thousands of iterations.
Would you please review this simple fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043507
WEBREV: http://cr.openjdk.java.net/~igerasim/8043507/0/webrev/
Sincerely yours,
Ivan
From mkaszub at tlen.pl Tue May 20 14:53:24 2014
From: mkaszub at tlen.pl (=?UTF-8?Q?Marcin_Kaszubski?=)
Date: Tue, 20 May 2014 16:53:24 +0200
Subject: =?UTF-8?Q?Signing_operation_on_client_side_?=
=?UTF-8?Q?during_SSL_Handshake?=
Message-ID: <768a615a.24d4f11b.537b6c64.468ec@tlen.pl>
Hi,
I want to use private key stored in client TPM to establish MTLS (so both client and server will be verified) connection with server. So during ssl handshake this key will be used to sign some data. I wanted to write my own provider and implement required services to achieve it. Unfortunately during code review of jdk i found a problem. During sign operation on client side provider seems to be hardcoded.?
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/RSASignature.java#82
How can I use my own providers and its implementation of Signature to achieve it? Is there a different implementation of SSLSocket which my be used to achieve it??
This is calling stack:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/ClientHandshaker.java#734http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/HandshakeMessage.java#1262http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/RSASignature.java#82
Best Regards,
Marcin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sean.mullan at oracle.com Tue May 20 18:14:12 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 20 May 2014 14:14:12 -0400
Subject: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
asmsec instead of sec
In-Reply-To:
References: <20140518134820.6A65C17FDA1@rebar.astron.com> <5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
Message-ID: <537B9B74.7030902@oracle.com>
On 05/19/2014 09:49 AM, Wang Weijun wrote:
> After some discussion with mit and heimdal lead engineers, I don't want to support ms at the moment. mit does not use kdc_timeout at all and heimdal's internal presentation is of seconds.
>
> So this is my plan: support "s" but if unspecified treat it as "ms". There will be a release notes describing this. This won't automatically fix the case for the bug reporter but at least give him a workaround -- use the 's' unit for interop.
>
> Does this sound clean?
Sounds good to me. Since the reporter was already changing the default
value, it's not unreasonable to require them to add a 's'.
--Sean
>
> Thanks
> Max
>
> On May 18, 2014, at 23:12, Xuelei Fan wrote:
>
>>
>>> On May 18, 2014, at 9:48 PM, christos at zoulas.com wrote:
>>>
>>> On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
>>> -- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>>>
>>> | How about this? I will support "s" and "ms" units ("ms" is not defined by o=
>>> | ther vendors though). But will still try to be a little smart when there is=
>>> | no unit.
>>>
>>> Heuristics can make the situation worse; they are difficult to document
>>> and explain to users. But if java is going to support ms, let's coordinate
>>> with heimdal and mit to make them support it too.
>>>
>> +1
>>
>> Xuelei
>>
>>> christos
>>>
>
From bradford.wetmore at oracle.com Tue May 20 18:20:51 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 20 May 2014 11:20:51 -0700
Subject: Signing operation on client side during SSL Handshake
In-Reply-To: <768a615a.24d4f11b.537b6c64.468ec@tlen.pl>
References: <768a615a.24d4f11b.537b6c64.468ec@tlen.pl>
Message-ID: <537B9D03.8040201@oracle.com>
You should continue following the code, but IIRC, internally
"MD5andSHA1withRSA" does a Signature.getInstance("NONEwithRSA"), and
then MessageDigest.getInstance("MD5") and ("SHA").
As long as your provider provides those algorithms and is prioritized
ahead of other providers which do provide them, you should get them.
Note this is an implementation detail which could change, but AFAIK
Oracle isn't doing any development in the Open 6 tree.
brad
On 5/20/2014 7:53 AM, Marcin Kaszubski wrote:
> Hi,
> I want to use private key stored in client TPM to establish MTLS (so
> both client and server will be verified) connection with server. So
> during ssl handshake this key will be used to sign some data. I wanted
> to write my own provider and implement required services to achieve it.
> Unfortunately during code review of jdk i found a problem. During sign
> operation on client side provider seems to be hardcoded.
>
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/RSASignature.java#82
>
>
> How can I use my own providers and its implementation of Signature to
> achieve it? Is there a different implementation of SSLSocket which my be
> used to achieve it?
>
> This is calling stack:
>
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/ClientHandshaker.java#734
>
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/HandshakeMessage.java#1262
>
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/RSASignature.java#82
>
>
>
>
> Best Regards,
> Marcin
From weijun.wang at oracle.com Wed May 21 11:51:00 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 21 May 2014 19:51:00 +0800
Subject: RFR: 8043537: Changes for JDK-8039951 introduced circular dependency
between Kerberos and com.sun.security.auth
Message-ID: <3BE8BEEF-B5D2-4414-8EB9-AB2271D5AC8A@oracle.com>
Hi All
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8043537/webrev.02/
The fix creates geteuid() in sun.misc.VM so DflCache.java does not depend on JAAS modules anymore. Alan suggested me to add some similar methods so other people can use it.
Thanks
Max
From Alan.Bateman at oracle.com Wed May 21 13:56:53 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 May 2014 14:56:53 +0100
Subject: RFR: 8043537: Changes for JDK-8039951 introduced circular
dependency between Kerberos and com.sun.security.auth
In-Reply-To: <3BE8BEEF-B5D2-4414-8EB9-AB2271D5AC8A@oracle.com>
References: <3BE8BEEF-B5D2-4414-8EB9-AB2271D5AC8A@oracle.com>
Message-ID: <537CB0A5.9090100@oracle.com>
On 21/05/2014 12:51, Wang Weijun wrote:
> Hi All
>
> Please review the code changes at
>
> http://cr.openjdk.java.net/~weijun/8043537/webrev.02/
>
> The fix creates geteuid() in sun.misc.VM so DflCache.java does not depend on JAAS modules anymore. Alan suggested me to add some similar methods so other people can use it.
>
>
This looks okay to me, thanks for fixing this issue.
-Alan.
From valerie.peng at oracle.com Wed May 21 23:13:12 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Wed, 21 May 2014 16:13:12 -0700
Subject: RFR [8043507]: javax.smartcardio.CardTerminals.list() fails on
MacOSX
In-Reply-To: <537B35DE.60605@oracle.com>
References: <537B35DE.60605@oracle.com>
Message-ID: <537D3308.9050805@oracle.com>
Looks good.
Have you looked for similar problems in the code? I wonder if this is
the only occurrence.
Thanks,
Valerie
On 05/20/14 04:00, Ivan Gerasimov wrote:
> Hello!
>
> The function javax.smartcardio.CardTerminals.list() sometimes fails
> when called from an app running on MacOSX.
> The problem is due to that CALL_SCardListReaders(_, _, _, &size)
> expects the size variable to be of size uint32_t on os x, but we
> provide a pointer to 64 bit int instead.
> As a result, the higher bits may contain garbage upon return, and we
> try to allocate a too large block of memory.
>
> The simplest solution is to initialize 'size' to zero before the call.
>
> No new tests with the fix, as the exiting tests already demonstrate
> intermittent failures because of this bug.
>
> For example, I've seem how ./sun/security/smartcardio/TestDefault.java
> failed once on every few hundred runs.
> With the fix this test doesn't fail even when running in a loop with
> thousands of iterations.
>
> Would you please review this simple fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043507
> WEBREV: http://cr.openjdk.java.net/~igerasim/8043507/0/webrev/
>
> Sincerely yours,
> Ivan
From vladimir.kozlov at oracle.com Wed May 21 23:34:24 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 21 May 2014 16:34:24 -0700
Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better
code generation by JIT compiler
Message-ID: <537D3800.8020603@oracle.com>
http://cr.openjdk.java.net/~kvn/8035974/webrev
https://bugs.openjdk.java.net/browse/JDK-8035974
Contributed by James Cheng and modified by me.
To use intrinsics to accelerate SHA operations on multiple blocks [1],
it is needed to pull a loop out of DigestBase.engineUpdate() and make a
new method implCompressMultiBlock() which contains only the loop and can
be intrinsified.
On platforms which does not use intrinsic implCompressMultiBlock()
method will be inlined by JIT and the same code will be generated as
before. So no performance regression with the pure Java SUN provider is
expected.
About arithmetic change. limit = ofs + len will not overflow integer
because ofs <= b.length - len (there is check).
Tested with jdk jtreg tests and new hotspot jtreg test James wrote for
8035968.
Thanks,
Vladimir
[1] https://bugs.openjdk.java.net/browse/JDK-8035968
From weijun.wang at oracle.com Thu May 22 00:20:36 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 22 May 2014 08:20:36 +0800
Subject: RFR 8036709: Java 7 jarsigner displays warning about cert policy tree
Message-ID: <5F9D25BB-56D1-497B-9EBF-07EDA6102FAC@oracle.com>
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8036709/webrev.01/
Before this change, jarsigner simply put a cert chain into a CertPath and validate it. If the CertPath contains a trust anchor inside, the validation could fail even if it should not. This fix searches for a trust anchor in the cert chain, if truncate at the position if one is found. If the first certificate is already a trust anchor, we don't do validation at all.
Thanks
Max
From ivan.gerasimov at oracle.com Thu May 22 07:25:12 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 22 May 2014 11:25:12 +0400
Subject: RFR [8043507]: javax.smartcardio.CardTerminals.list() fails on
MacOSX
In-Reply-To: <537D3308.9050805@oracle.com>
References: <537B35DE.60605@oracle.com> <537D3308.9050805@oracle.com>
Message-ID: <537DA658.6000604@oracle.com>
On 22.05.2014 3:13, Valerie (Yu-Ching) Peng wrote:
> Looks good.
>
Thank you Valerie!
> Have you looked for similar problems in the code? I wonder if this is
> the only occurrence.
>
I've scanned through the rest of pcsc.c and found a few other places
that can potentially have the same issue.
In all the places the variable is declared to be 64 bit integer, but the
library function expects a pointer to 32 bit integer.
I didn't check whether the bugs can really be observed there, but think
it's better to play safe and initialize variables to zero before passing
a pointer to them to a library function.
Would you please take a look the updated webrev?
WEBREV: http://cr.openjdk.java.net/~igerasim/8043507/1/webrev/
Sincerely yours,
Ivan
> Thanks,
> Valerie
>
> On 05/20/14 04:00, Ivan Gerasimov wrote:
>> Hello!
>>
>> The function javax.smartcardio.CardTerminals.list() sometimes fails
>> when called from an app running on MacOSX.
>> The problem is due to that CALL_SCardListReaders(_, _, _, &size)
>> expects the size variable to be of size uint32_t on os x, but we
>> provide a pointer to 64 bit int instead.
>> As a result, the higher bits may contain garbage upon return, and we
>> try to allocate a too large block of memory.
>>
>> The simplest solution is to initialize 'size' to zero before the call.
>>
>> No new tests with the fix, as the exiting tests already demonstrate
>> intermittent failures because of this bug.
>>
>> For example, I've seem how
>> ./sun/security/smartcardio/TestDefault.java failed once on every few
>> hundred runs.
>> With the fix this test doesn't fail even when running in a loop with
>> thousands of iterations.
>>
>> Would you please review this simple fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043507
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8043507/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>
>
>
From sean.mullan at oracle.com Thu May 22 18:15:42 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 22 May 2014 14:15:42 -0400
Subject: RFR 8036709: Java 7 jarsigner displays warning about cert policy
tree
In-Reply-To: <5F9D25BB-56D1-497B-9EBF-07EDA6102FAC@oracle.com>
References: <5F9D25BB-56D1-497B-9EBF-07EDA6102FAC@oracle.com>
Message-ID: <537E3ECE.3000806@oracle.com>
Hi Max,
Did you consider using a CertPathBuilder instead? This should
essentially do the same thing (find a matching trust anchor, and build a
validated path).
--Sean
On 05/21/2014 08:20 PM, Wang Weijun wrote:
> Hi All
>
> Please review the code change at
>
> http://cr.openjdk.java.net/~weijun/8036709/webrev.01/
>
> Before this change, jarsigner simply put a cert chain into a CertPath and validate it. If the CertPath contains a trust anchor inside, the validation could fail even if it should not. This fix searches for a trust anchor in the cert chain, if truncate at the position if one is found. If the first certificate is already a trust anchor, we don't do validation at all.
>
> Thanks
> Max
>
From bradford.wetmore at oracle.com Thu May 22 20:36:11 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 22 May 2014 13:36:11 -0700
Subject: Webrev for 8043342: StringBuffer/StringBuilder crypto changes.
Message-ID: <537E5FBB.1060504@oracle.com>
No additional code review necessary, this is just an FYI.
For internal reasons (i.e. we have to sign our JCE jar files), we have
separated the JCE portion for:
8041679: Replace uses of StringBuffer with StringBuilder within the JDK
into:
8043342: Replace uses of StringBuffer with StringBuilder within crypto code
It's the exact same code, but only the four JCE files are included here.
http://cr.openjdk.java.net/~wetmore/8043342/webrev.00/
I am sponsoring this for Jamil, from an original fix [1] sponsored by
Paul Sandoz from:
Ot?vio Gon?alves de Santana
Thanks,
Brad
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026820.html
From weijun.wang at oracle.com Thu May 22 23:42:07 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 23 May 2014 07:42:07 +0800
Subject: RFR 8036709: Java 7 jarsigner displays warning about cert policy
tree
In-Reply-To: <537E3ECE.3000806@oracle.com>
References: <5F9D25BB-56D1-497B-9EBF-07EDA6102FAC@oracle.com>
<537E3ECE.3000806@oracle.com>
Message-ID: <8E6A8CAB-544B-492D-A013-58D5CBF94FB8@oracle.com>
On May 23, 2014, at 2:15, Sean Mullan wrote:
> Hi Max,
>
> Did you consider using a CertPathBuilder instead? This should essentially do the same thing (find a matching trust anchor, and build a validated path).
I thought about it but anyway the certchain is still a chain. If I just treat them as an unordered set of certs, it seems too tolerant.
--Max
>
> --Sean
>
> On 05/21/2014 08:20 PM, Wang Weijun wrote:
>> Hi All
>>
>> Please review the code change at
>>
>> http://cr.openjdk.java.net/~weijun/8036709/webrev.01/
>>
>> Before this change, jarsigner simply put a cert chain into a CertPath and validate it. If the CertPath contains a trust anchor inside, the validation could fail even if it should not. This fix searches for a trust anchor in the cert chain, if truncate at the position if one is found. If the first certificate is already a trust anchor, we don't do validation at all.
>>
>> Thanks
>> Max
>>
From valerie.peng at oracle.com Fri May 23 00:25:38 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Thu, 22 May 2014 17:25:38 -0700
Subject: RFR [8043507]: javax.smartcardio.CardTerminals.list() fails on
MacOSX
In-Reply-To: <537DA658.6000604@oracle.com>
References: <537B35DE.60605@oracle.com> <537D3308.9050805@oracle.com>
<537DA658.6000604@oracle.com>
Message-ID: <537E9582.4000007@oracle.com>
Looks good.
Thanks,
Valerie
On 05/22/14 00:25, Ivan Gerasimov wrote:
>
> On 22.05.2014 3:13, Valerie (Yu-Ching) Peng wrote:
>> Looks good.
>>
> Thank you Valerie!
>
>> Have you looked for similar problems in the code? I wonder if this is
>> the only occurrence.
>>
> I've scanned through the rest of pcsc.c and found a few other places
> that can potentially have the same issue.
> In all the places the variable is declared to be 64 bit integer, but
> the library function expects a pointer to 32 bit integer.
> I didn't check whether the bugs can really be observed there, but
> think it's better to play safe and initialize variables to zero before
> passing a pointer to them to a library function.
>
> Would you please take a look the updated webrev?
>
> WEBREV: http://cr.openjdk.java.net/~igerasim/8043507/1/webrev/
>
> Sincerely yours,
> Ivan
>
>
>> Thanks,
>> Valerie
>>
>> On 05/20/14 04:00, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> The function javax.smartcardio.CardTerminals.list() sometimes fails
>>> when called from an app running on MacOSX.
>>> The problem is due to that CALL_SCardListReaders(_, _, _, &size)
>>> expects the size variable to be of size uint32_t on os x, but we
>>> provide a pointer to 64 bit int instead.
>>> As a result, the higher bits may contain garbage upon return, and we
>>> try to allocate a too large block of memory.
>>>
>>> The simplest solution is to initialize 'size' to zero before the call.
>>>
>>> No new tests with the fix, as the exiting tests already demonstrate
>>> intermittent failures because of this bug.
>>>
>>> For example, I've seem how
>>> ./sun/security/smartcardio/TestDefault.java failed once on every few
>>> hundred runs.
>>> With the fix this test doesn't fail even when running in a loop with
>>> thousands of iterations.
>>>
>>> Would you please review this simple fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043507
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8043507/0/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>
>>
>>
>
From ecki at zusammenkunft.net Fri May 23 00:34:13 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 23 May 2014 02:34:13 +0200
Subject: Locking/Singleton in JCAUtil
Message-ID: <20140523023413.000071eb.ecki@zusammenkunft.net>
Hello,
by browsing the source code I run across the JCAUtil class. It is
(among other stuff) responsible for providing a SecureRandom singleton.
The code looks a bit strange.
First of all, it defines a LOCK object, but instead of using an
unreachable instancde (which is a common pattern for those kind of LOCK
objects) it uses the public class itself:
private static final Object LOCK = JCAUtil.class;
Typical this would be a problem as I can lock up the class. In this
specific case the LOCK is only used in one place, and there it is used
for a double checked locking, which is I guess good as it only checks
the monitor before any user code can lock it. Nevertheless, I would
recommend to change this to a more common pattern (or remove the field
and us synchronized(JCAUtil.class) to make it more explicite.
Another option would be to get rid of all the volatile/lock/DCL by
having a static initialisation. If this is not possible for dependency
reasons, I would have expected a comment like "this needs to be lazy
because..."
With final and without volatile it also looks more predictable:
private static final SecureRandom secureRandom = new SecureRandom();
public static SecureRandom getSecureRandom() { return secureRandom; }
WDYT?
Gruss
Bernd
From ecki at zusammenkunft.net Fri May 23 00:34:22 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 23 May 2014 02:34:22 +0200
Subject: Get intermediate MessageDigest state?
Message-ID: <20140523023422.00001a59.ecki@zusammenkunft.net>
Hello,
for some applications I need to safe and resume the state of a
MessageDigest implementation (SHA1 and others). I wonder if there has
been any discussion about exporting states from Digesters or Cipher
Streams?
For MD5 there is a implementation which supports this, but of course I
would prefer JCE provider (especially if I can get a speed up with
intrinsics)
https://code.google.com/p/project-penny/wiki/RecMD5
I can imagine first a getter/setter for the state, but also (with
help of clone) using the digest() method could be possible (at least
for some digest algorithms).
Greetings
Bernd
From bernd-2014 at eckenfels.net Fri May 23 01:11:35 2014
From: bernd-2014 at eckenfels.net (Bernd Eckenfels)
Date: Fri, 23 May 2014 03:11:35 +0200
Subject: Locking/Singleton in JCAUtil
In-Reply-To: <20140523023413.000071eb.ecki@zusammenkunft.net>
References: <20140523023413.000071eb.ecki@zusammenkunft.net>
Message-ID: <20140523031135.000050bd.bernd-2014@eckenfels.net>
And just a followup: it is interesting to note, that this Utility is
still used as default random source for Key Generators and DSA
Signatures. I would expect those need to refer to
SecureRandom.getInstanceStrong() instead? (the string instance getter
is nowhere used?)
Bernd
From david.lloyd at redhat.com Fri May 23 01:49:26 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 22 May 2014 20:49:26 -0500
Subject: Get intermediate MessageDigest state?
In-Reply-To: <20140523023422.00001a59.ecki@zusammenkunft.net>
References: <20140523023422.00001a59.ecki@zusammenkunft.net>
Message-ID: <537EA926.5030202@redhat.com>
On 05/22/2014 07:34 PM, Bernd Eckenfels wrote:
> Hello,
>
> for some applications I need to safe and resume the state of a
> MessageDigest implementation (SHA1 and others). I wonder if there has
> been any discussion about exporting states from Digesters or Cipher
> Streams?
>
> For MD5 there is a implementation which supports this, but of course I
> would prefer JCE provider (especially if I can get a speed up with
> intrinsics)
>
> https://code.google.com/p/project-penny/wiki/RecMD5
>
> I can imagine first a getter/setter for the state, but also (with
> help of clone) using the digest() method could be possible (at least
> for some digest algorithms).
Using MessageDigest.clone() is the usual approach. Theoretically
though, some providers won't be cloneable; the only practical recourse
in this case is to replay the whole of the input, unfortunately.
--
- DML
From bernd-2014 at eckenfels.net Fri May 23 02:40:37 2014
From: bernd-2014 at eckenfels.net (Bernd Eckenfels)
Date: Fri, 23 May 2014 04:40:37 +0200
Subject: Get intermediate MessageDigest state?
In-Reply-To: <537EA926.5030202@redhat.com>
References: <20140523023422.00001a59.ecki@zusammenkunft.net>
<537EA926.5030202@redhat.com>
Message-ID: <20140523044037.00007f9f.bernd-2014@eckenfels.net>
Am Thu, 22 May 2014 20:49:26 -0500
schrieb "David M. Lloyd" :
> Using MessageDigest.clone() is the usual approach. Theoretically
> though, some providers won't be cloneable; the only practical
> recourse in this case is to replay the whole of the input,
> unfortunately.
My problem is, that I need to serialize the state to a database or
file. The problem about the non-clone support is not a big problem for
me, as I can select a well known provider.
Greetings
Bernd
From ecki at zusammenkunft.net Fri May 23 02:43:06 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 23 May 2014 04:43:06 +0200
Subject: Get intermediate MessageDigest state?
In-Reply-To: <537EA926.5030202@redhat.com>
References: <20140523023422.00001a59.ecki@zusammenkunft.net>
<537EA926.5030202@redhat.com>
Message-ID: <20140523044306.00006a34.ecki@zusammenkunft.net>
Am Thu, 22 May 2014 20:49:26 -0500
schrieb "David M. Lloyd" :
> Using MessageDigest.clone() is the usual approach. Theoretically
> though, some providers won't be cloneable; the only practical
> recourse in this case is to replay the whole of the input,
> unfortunately.
Yes, I have the need to persist the partial state in a database. So I
would need to get the actual state bytes.
In some cases I can use the clone() and its also not a big problem to
request providers which are known to be Cloneable.
Greetings
Bernd
From paul.sandoz at oracle.com Fri May 23 09:06:19 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 23 May 2014 11:06:19 +0200
Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for
better code generation by JIT compiler
In-Reply-To: <537D3800.8020603@oracle.com>
References: <537D3800.8020603@oracle.com>
Message-ID:
On May 22, 2014, at 1:34 AM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8035974/webrev
> https://bugs.openjdk.java.net/browse/JDK-8035974
>
> Contributed by James Cheng and modified by me.
>
Looks good to me.
Paul.
> To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method implCompressMultiBlock() which contains only the loop and can be intrinsified.
>
> On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance regression with the pure Java SUN provider is expected.
>
> About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check).
>
> Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968.
>
> Thanks,
> Vladimir
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8035968
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From anthony.scarpino at oracle.com Fri May 23 14:25:50 2014
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 23 May 2014 07:25:50 -0700
Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for
better code generation by JIT compiler
In-Reply-To: <537D3800.8020603@oracle.com>
References: <537D3800.8020603@oracle.com>
Message-ID: <357BA371-4662-48CC-89C7-50F1918C86EB@oracle.com>
This looks fine to me
Tony
> On May 21, 2014, at 4:34 PM, Vladimir Kozlov wrote:
>
> http://cr.openjdk.java.net/~kvn/8035974/webrev
> https://bugs.openjdk.java.net/browse/JDK-8035974
>
> Contributed by James Cheng and modified by me.
>
> To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method implCompressMultiBlock() which contains only the loop and can be intrinsified.
>
> On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance regression with the pure Java SUN provider is expected.
>
> About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check).
>
> Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968.
>
> Thanks,
> Vladimir
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8035968
From forax at univ-mlv.fr Fri May 23 10:17:49 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 23 May 2014 12:17:49 +0200
Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for
better code generation by JIT compiler
In-Reply-To:
References: <537D3800.8020603@oracle.com>
Message-ID: <537F204D.1000109@univ-mlv.fr>
On 05/23/2014 11:06 AM, Paul Sandoz wrote:
> On May 22, 2014, at 1:34 AM, Vladimir Kozlov wrote:
>
>> http://cr.openjdk.java.net/~kvn/8035974/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8035974
>>
>> Contributed by James Cheng and modified by me.
>>
> Looks good to me.
>
> Paul.
implCompressMultiBlock should be private thus don't need to be final.
R?mi
>
>> To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method implCompressMultiBlock() which contains only the loop and can be intrinsified.
>>
>> On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance regression with the pure Java SUN provider is expected.
>>
>> About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check).
>>
>> Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968.
>>
>> Thanks,
>> Vladimir
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8035968
From james.cheng at oracle.com Fri May 23 17:27:32 2014
From: james.cheng at oracle.com (james cheng)
Date: Fri, 23 May 2014 10:27:32 -0700
Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for
better code generation by JIT compiler
In-Reply-To: <537F204D.1000109@univ-mlv.fr>
References: <537D3800.8020603@oracle.com>
<537F204D.1000109@univ-mlv.fr>
Message-ID: <537F8504.1070104@oracle.com>
On 5/23/2014 3:17 AM, Remi Forax wrote:
>
> On 05/23/2014 11:06 AM, Paul Sandoz wrote:
>> On May 22, 2014, at 1:34 AM, Vladimir Kozlov wrote:
>>
>>> http://cr.openjdk.java.net/~kvn/8035974/webrev
>>> https://bugs.openjdk.java.net/browse/JDK-8035974
>>>
>>> Contributed by James Cheng and modified by me.
>>>
>> Looks good to me.
>>
>> Paul.
>
> implCompressMultiBlock should be private thus don't need to be final.
>
> R?mi
I pulled it out of engineUpdate() so kept it "protected final" as before. I
just tried it with "private" and it still could be intrinsified. So either way
is okay in terms of intrinsification.
Thanks,
-James
>
>>
>>> To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method
>>> implCompressMultiBlock() which contains only the loop and can be intrinsified.
>>>
>>> On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance
>>> regression with the pure Java SUN provider is expected.
>>>
>>> About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check).
>>>
>>> Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8035968
>
From vladimir.kozlov at oracle.com Fri May 23 18:18:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 23 May 2014 11:18:31 -0700
Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for
better code generation by JIT compiler
In-Reply-To: <537F8504.1070104@oracle.com>
References: <537D3800.8020603@oracle.com>
<537F204D.1000109@univ-mlv.fr> <537F8504.1070104@oracle.com>
Message-ID: <537F90F7.2020408@oracle.com>
Thank you, Paul, Remi, Anthony, for reviews.
I changed "protected final" to "private" as suggested:
http://cr.openjdk.java.net/~kvn/8035974/webrev.01
Note, JIT inlines final and private methods without generation a
method's class check. So inlined code is the same.
Thanks,
Vladimir
On 5/23/14 10:27 AM, james cheng wrote:
> On 5/23/2014 3:17 AM, Remi Forax wrote:
>>
>> On 05/23/2014 11:06 AM, Paul Sandoz wrote:
>>> On May 22, 2014, at 1:34 AM, Vladimir Kozlov
>>> wrote:
>>>
>>>> http://cr.openjdk.java.net/~kvn/8035974/webrev
>>>> https://bugs.openjdk.java.net/browse/JDK-8035974
>>>>
>>>> Contributed by James Cheng and modified by me.
>>>>
>>> Looks good to me.
>>>
>>> Paul.
>>
>> implCompressMultiBlock should be private thus don't need to be final.
>>
>> R?mi
>
> I pulled it out of engineUpdate() so kept it "protected final" as
> before. I
> just tried it with "private" and it still could be intrinsified. So
> either way
> is okay in terms of intrinsification.
>
> Thanks,
> -James
>
>>
>>>
>>>> To use intrinsics to accelerate SHA operations on multiple blocks
>>>> [1], it is needed to pull a loop out of DigestBase.engineUpdate()
>>>> and make a new method
>>>> implCompressMultiBlock() which contains only the loop and can be
>>>> intrinsified.
>>>>
>>>> On platforms which does not use intrinsic implCompressMultiBlock()
>>>> method will be inlined by JIT and the same code will be generated as
>>>> before. So no performance
>>>> regression with the pure Java SUN provider is expected.
>>>>
>>>> About arithmetic change. limit = ofs + len will not overflow integer
>>>> because ofs <= b.length - len (there is check).
>>>>
>>>> Tested with jdk jtreg tests and new hotspot jtreg test James wrote
>>>> for 8035968.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8035968
>>
From weijun.wang at oracle.com Tue May 27 10:50:28 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 27 May 2014 18:50:28 +0800
Subject: GSSCredential inside Subject?
Message-ID: <8FBC27C9-A32E-45DF-BF6B-B40B23B8367B@oracle.com>
Hi Valerie
I am working on breaking JGSS into modules and is now looking at sun/security/jgss/GSSUtil.java. There is a method
public static Vector
searchSubject(final GSSNameSpi name,
final Oid mech,
final boolean initiate,
final Class credCls) {
which goes inside a Subject's priv cred sets looking for GSSCredentialImpl objects. I searched thru other JDK codes and cannot see who is putting those objects there. Do you remember anything? Or we are thinking about applications putting them there? I cannot think of any such convention.
In fact, all I can see JAAS/JGSS/krb5 doing with a Subject is putting KerberosPrincipal into princ set and KerberosKey/KerberosTicket/KeyTab into priv cred set. Nothing else.
Thanks
Max
From ivan.gerasimov at oracle.com Tue May 27 11:59:21 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 27 May 2014 15:59:21 +0400
Subject: RFR [8043507]: (smartcardio) Card.transmitControlCommand() does not
work on Mac OS X
Message-ID: <53847E19.1040507@oracle.com>
Hello!
SunPCSC provider uses SCardControl() function to send a request to the
cardreader.
However, on MacOSX pcsc-lite API has two similar functions exported:
SCardControl and SCardControl132.
The second function is actually the one we need to use: The first
function has different signature and is a legacy.
Due to this bug, a simple call card.transmitControlCommand(0x42000d48,
new byte[] {}) which should retrieve a list of supported commands fails
with SCARD_E_INVALID_PARAMETER error code:
With the proposed fix the function works as expected.
Would you please help review it?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039319
WEBREV: http://cr.openjdk.java.net/~igerasim/8039319/0/webrev/
Sincerely yours,
Ivan
From ivan.gerasimov at oracle.com Tue May 27 19:30:47 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 27 May 2014 23:30:47 +0400
Subject: RFR [8043720] (smartcardio) Native memory should be handled more
accurately
Message-ID: <5384E7E7.1080409@oracle.com>
Hello!
Here is a proposal to make some native memory manipulations in
src/share/native/sun/security/smartcardio/pcsc.c more accurate.
1)
Add another argument to pcsc_multi2jstring() which will hold the size of
the character array to be parsed.
In the function we make sure we do not access memory outside the array.
2)
In pcsc_multi2jstring():
There is a constant PCSCLITE_MAX_READERS_CONTEXTS == 16, which limits
number of cardreaders in the system.
So we don't need to allocate the buffer with malloc.
3)
In Java_sun_security_smartcardio_PCSC_SCardListReaders():
The 'size' variable is initialized in the pcsc-lite API call to
SCardListReaders.
Even though it should not be zero, if SCardListReaders returned
SUCCESS, it's still a call of foreign function.
Thus we better handle the case when size == 0.
4)
Currently Java_sun_security_smartcardio_PCSC_SCardGetStatusChange is
always called with non-empty jReaderNames argument.
However, it seems easy to make it more robust with a couple of checks
for the empty array of names.
5)
In Java_sun_security_smartcardio_PCSC_SCardGetStatusChange, readers'
names are allocated with strdup() and later freed with free().
If the program gets to cleanup upon an error, some of the names may turn
out be be never initialized, so free() can fail.
Would you please help review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043720
WEBREV: http://cr.openjdk.java.net/~igerasim/8043720/0/webrev/
Sincerely yours,
Ivan
From sean.mullan at oracle.com Tue May 27 19:46:36 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 27 May 2014 15:46:36 -0400
Subject: RFR 8036709: Java 7 jarsigner displays warning about cert policy
tree
In-Reply-To: <8E6A8CAB-544B-492D-A013-58D5CBF94FB8@oracle.com>
References: <5F9D25BB-56D1-497B-9EBF-07EDA6102FAC@oracle.com>
<537E3ECE.3000806@oracle.com>
<8E6A8CAB-544B-492D-A013-58D5CBF94FB8@oracle.com>
Message-ID: <5384EB9C.4060403@oracle.com>
On 05/22/2014 07:42 PM, Wang Weijun wrote:
>
> On May 23, 2014, at 2:15, Sean Mullan wrote:
>
>> Hi Max,
>>
>> Did you consider using a CertPathBuilder instead? This should essentially do the same thing (find a matching trust anchor, and build a validated path).
>
> I thought about it but anyway the certchain is still a chain. If I just treat them as an unordered set of certs, it seems too tolerant.
Ok. The fix looks fine to me, though it looks like the code in the 2
methods is very similar - could it be refactored into a common method?
--Sean
>
> --Max
>
>>
>> --Sean
>>
>> On 05/21/2014 08:20 PM, Wang Weijun wrote:
>>> Hi All
>>>
>>> Please review the code change at
>>>
>>> http://cr.openjdk.java.net/~weijun/8036709/webrev.01/
>>>
>>> Before this change, jarsigner simply put a cert chain into a CertPath and validate it. If the CertPath contains a trust anchor inside, the validation could fail even if it should not. This fix searches for a trust anchor in the cert chain, if truncate at the position if one is found. If the first certificate is already a trust anchor, we don't do validation at all.
>>>
>>> Thanks
>>> Max
>>>
>
From vincent.x.ryan at oracle.com Tue May 27 20:55:59 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 27 May 2014 21:55:59 +0100
Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
In-Reply-To:
References:
Message-ID:
Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor your fix if you wish.
On 27 May 2014, at 21:09, Jeremy Manson wrote:
> Just like the title says - every time you generate a new private key, you
> leak a little memory. Webrev here:
>
> http://cr.openjdk.java.net/~jmanson/8044059/webrev/
>
> This is probably the wrong mailing list for this bug, but I expect someone
> on this list will point me in the right direction.
>
> Jeremy
From valerie.peng at oracle.com Wed May 28 00:20:26 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Tue, 27 May 2014 17:20:26 -0700
Subject: RFR [8043507]: (smartcardio) Card.transmitControlCommand() does
not work on Mac OS X
In-Reply-To: <53847E19.1040507@oracle.com>
References: <53847E19.1040507@oracle.com>
Message-ID: <53852BCA.3020309@oracle.com>
Looks good.
Thanks,
Valerie
On 05/27/14 04:59, Ivan Gerasimov wrote:
> Hello!
>
> SunPCSC provider uses SCardControl() function to send a request to the
> cardreader.
> However, on MacOSX pcsc-lite API has two similar functions exported:
> SCardControl and SCardControl132.
> The second function is actually the one we need to use: The first
> function has different signature and is a legacy.
>
> Due to this bug, a simple call card.transmitControlCommand(0x42000d48,
> new byte[] {}) which should retrieve a list of supported commands
> fails with SCARD_E_INVALID_PARAMETER error code:
>
> With the proposed fix the function works as expected.
> Would you please help review it?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8039319
> WEBREV: http://cr.openjdk.java.net/~igerasim/8039319/0/webrev/
>
> Sincerely yours,
> Ivan
From jamil.j.nimeh at oracle.com Wed May 28 00:53:39 2014
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 27 May 2014 17:53:39 -0700
Subject: Webrev request: JDK-8015081
Message-ID: <53853393.6020108@oracle.com>
Hello all,
This bug was originally to resolve issues where Subject principal and
credential Set fields containing null elements could cause
NullPointerException to be thrown. It was decided to make the Subject
throw NullPointerException when attempts to construct or modify Subjects
will null elements. In addition, certain Set methods called upon
principals and credentials where the input Collection contained null
elements could have different effects depending on which set. These
methods, when called with Collections containing null elements as input
now throw NullPointerException as well.
Operation Before After
(Prin/Pub/Priv) (Prin/Pub/Priv) (Prin/Pub/Priv)
----------------------------------------------------------------------------
add(null) SecurityException/true/true NPE/NPE/NPE
remove(null) false/false/false (*) NPE/NPE/NPE
contains(null) false/false/false (*) NPE/NPE/NPE
addAll(collection w/ null) SecurityException/true/true NPE/NPE/NPE
removeAll(collection w/ null) true/true/true (**) NPE/NPE/NPE
containsAll(coll. w/ null) false/false/NPE NPE/NPE/NPE
retainAll(collection w/ null) true/true/true (***) NPE/NPE/NPE
* - Assumes Subject has no null values in its private SecureSet
collections
** - Assumes input collection has at least one non-null element that
exists in the target SecureSet
*** - Assumes input collection is not equivalent to or a superset of the
target SecureSet (which would cause no change)
Bug: https://bugs.openjdk.java.net/browse/JDK-8015081
Webrev: http://cr.openjdk.java.net/~ascarpino/8015081/webrev.02
Thanks,
--Jamil
From jeremymanson at google.com Tue May 27 21:18:35 2014
From: jeremymanson at google.com (Jeremy Manson)
Date: Tue, 27 May 2014 14:18:35 -0700
Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
In-Reply-To:
References:
Message-ID:
Thanks, Vincent. This would be the first change I've made as an author, so
I'm not sure what the process is. I think I just need someone to do the
review, and then I can check it in?
Jeremy
On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan
wrote:
> Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor your
> fix if you wish.
>
> On 27 May 2014, at 21:09, Jeremy Manson wrote:
>
> > Just like the title says - every time you generate a new private key, you
> > leak a little memory. Webrev here:
> >
> > http://cr.openjdk.java.net/~jmanson/8044059/webrev/
> >
> > This is probably the wrong mailing list for this bug, but I expect
> someone
> > on this list will point me in the right direction.
> >
> > Jeremy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From weijun.wang at oracle.com Wed May 28 04:47:56 2014
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 28 May 2014 12:47:56 +0800
Subject: RFR 8036709: Java 7 jarsigner displays warning about cert policy
tree
In-Reply-To: <5384EB9C.4060403@oracle.com>
References: <5F9D25BB-56D1-497B-9EBF-07EDA6102FAC@oracle.com>
<537E3ECE.3000806@oracle.com>
<8E6A8CAB-544B-492D-A013-58D5CBF94FB8@oracle.com>
<5384EB9C.4060403@oracle.com>
Message-ID: <53856A7C.3090204@oracle.com>
On 5/28/2014 3:46, Sean Mullan wrote:
> Ok. The fix looks fine to me, though it looks like the code in the 2
> methods is very similar - could it be refactored into a common method?
Yes, it's now
http://cr.openjdk.java.net/~weijun/8036709/webrev.02/
Thanks
Max
From iris.clark at oracle.com Wed May 28 05:00:30 2014
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 27 May 2014 22:00:30 -0700 (PDT)
Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
In-Reply-To:
References:
Message-ID: <13a1868f-854e-4bcb-8666-8678b25acb04@default>
Hi, Jeremy.
As an "Author", you can create a changeset but you can't push to the repo until you're a "Committer". Additional details about the differences between Author and Committer may be found here [1,2].
The diffs to create a changeset are (of course) in your webrev. Your Sponsor can use that along with the "hg commit -u jmanson ..." to list you as the changeset Author. Alternatively, your Sponsor may want you to just send the output of "hg export -g" which would preserve information in the changeset header including the author, commit comment, etc.
Thanks,
iris
[1]: http://openjdk.java.net/projects/#project-author
[2]: http://openjdk.java.net/projects/#project-committer
-----Original Message-----
From: Jeremy Manson [mailto:jeremymanson at google.com]
Sent: Tuesday, May 27, 2014 2:19 PM
To: Vincent Ryan
Cc: OpenJDK; core-libs-dev
Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in?
Jeremy
On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan
wrote:
> Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor
> your fix if you wish.
>
> On 27 May 2014, at 21:09, Jeremy Manson wrote:
>
> > Just like the title says - every time you generate a new private
> > key, you leak a little memory. Webrev here:
> >
> > http://cr.openjdk.java.net/~jmanson/8044059/webrev/
> >
> > This is probably the wrong mailing list for this bug, but I expect
> someone
> > on this list will point me in the right direction.
> >
> > Jeremy
>
>
From sean.mullan at oracle.com Wed May 28 15:03:27 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 28 May 2014 11:03:27 -0400
Subject: RFR 8036709: Java 7 jarsigner displays warning about cert policy
tree
In-Reply-To: <53856A7C.3090204@oracle.com>
References: <5F9D25BB-56D1-497B-9EBF-07EDA6102FAC@oracle.com>
<537E3ECE.3000806@oracle.com>
<8E6A8CAB-544B-492D-A013-58D5CBF94FB8@oracle.com>
<5384EB9C.4060403@oracle.com> <53856A7C.3090204@oracle.com>
Message-ID: <5385FABF.8070405@oracle.com>
On 05/28/2014 12:47 AM, Weijun Wang wrote:
>
> On 5/28/2014 3:46, Sean Mullan wrote:
>> Ok. The fix looks fine to me, though it looks like the code in the 2
>> methods is very similar - could it be refactored into a common method?
>
> Yes, it's now
>
> http://cr.openjdk.java.net/~weijun/8036709/webrev.02/
This looks fine.
--Sean
From vincent.x.ryan at oracle.com Wed May 28 15:52:04 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 28 May 2014 16:52:04 +0100
Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
In-Reply-To:
References:
<13a1868f-854e-4bcb-8666-8678b25acb04@default>
Message-ID: <8A7D584B-9C81-49B9-80E2-616484EB836D@oracle.com>
I?ll begin reviewing your changeset and get back to you.
Thanks.
On 28 May 2014, at 16:28, Jeremy Manson wrote:
> Ah, okay. Thanks, Iris. I should already know known that - Martin has explained it to me before.
>
> Vincent - let me know how you want to proceed.
>
> Jeremy
>
>
> On Tue, May 27, 2014 at 10:00 PM, Iris Clark wrote:
> Hi, Jeremy.
>
> As an "Author", you can create a changeset but you can't push to the repo until you're a "Committer". Additional details about the differences between Author and Committer may be found here [1,2].
>
> The diffs to create a changeset are (of course) in your webrev. Your Sponsor can use that along with the "hg commit -u jmanson ..." to list you as the changeset Author. Alternatively, your Sponsor may want you to just send the output of "hg export -g" which would preserve information in the changeset header including the author, commit comment, etc.
>
> Thanks,
> iris
>
> [1]: http://openjdk.java.net/projects/#project-author
> [2]: http://openjdk.java.net/projects/#project-committer
>
> -----Original Message-----
> From: Jeremy Manson [mailto:jeremymanson at google.com]
> Sent: Tuesday, May 27, 2014 2:19 PM
> To: Vincent Ryan
> Cc: OpenJDK; core-libs-dev
> Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
>
> Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in?
>
> Jeremy
>
>
> On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan
> wrote:
>
> > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor
> > your fix if you wish.
> >
> > On 27 May 2014, at 21:09, Jeremy Manson wrote:
> >
> > > Just like the title says - every time you generate a new private
> > > key, you leak a little memory. Webrev here:
> > >
> > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/
> > >
> > > This is probably the wrong mailing list for this bug, but I expect
> > someone
> > > on this list will point me in the right direction.
> > >
> > > Jeremy
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vincent.x.ryan at oracle.com Wed May 28 16:23:49 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 28 May 2014 17:23:49 +0100
Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
In-Reply-To:
References:
<13a1868f-854e-4bcb-8666-8678b25acb04@default>
<8A7D584B-9C81-49B9-80E2-616484EB836D@oracle.com>
Message-ID:
It?s difficult to develop a useful test that is cross-platform so let?s skip the testcase for this fix.
On 28 May 2014, at 17:21, Jeremy Manson wrote:
> You can defer the change if you need to. I'm going on vacation from the 6th to the 16th, so there are timing issues around that.
>
> At Google, we plug in a different version of malloc that checks to make sure that you've freed everything you've allocated. It's a bit painful to write this from scratch, but I might be able to hack something together for you (that only runs on Linux), if you want.
>
> Jeremy
>
>
> On Wed, May 28, 2014 at 8:52 AM, Vincent Ryan wrote:
> I?ll begin reviewing your changeset and get back to you.
> Thanks.
>
> On 28 May 2014, at 16:28, Jeremy Manson wrote:
>
>> Ah, okay. Thanks, Iris. I should already know known that - Martin has explained it to me before.
>>
>> Vincent - let me know how you want to proceed.
>>
>> Jeremy
>>
>>
>> On Tue, May 27, 2014 at 10:00 PM, Iris Clark wrote:
>> Hi, Jeremy.
>>
>> As an "Author", you can create a changeset but you can't push to the repo until you're a "Committer". Additional details about the differences between Author and Committer may be found here [1,2].
>>
>> The diffs to create a changeset are (of course) in your webrev. Your Sponsor can use that along with the "hg commit -u jmanson ..." to list you as the changeset Author. Alternatively, your Sponsor may want you to just send the output of "hg export -g" which would preserve information in the changeset header including the author, commit comment, etc.
>>
>> Thanks,
>> iris
>>
>> [1]: http://openjdk.java.net/projects/#project-author
>> [2]: http://openjdk.java.net/projects/#project-committer
>>
>> -----Original Message-----
>> From: Jeremy Manson [mailto:jeremymanson at google.com]
>> Sent: Tuesday, May 27, 2014 2:19 PM
>> To: Vincent Ryan
>> Cc: OpenJDK; core-libs-dev
>> Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
>>
>> Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in?
>>
>> Jeremy
>>
>>
>> On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan
>> wrote:
>>
>> > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor
>> > your fix if you wish.
>> >
>> > On 27 May 2014, at 21:09, Jeremy Manson wrote:
>> >
>> > > Just like the title says - every time you generate a new private
>> > > key, you leak a little memory. Webrev here:
>> > >
>> > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/
>> > >
>> > > This is probably the wrong mailing list for this bug, but I expect
>> > someone
>> > > on this list will point me in the right direction.
>> > >
>> > > Jeremy
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jeremymanson at google.com Wed May 28 15:28:04 2014
From: jeremymanson at google.com (Jeremy Manson)
Date: Wed, 28 May 2014 08:28:04 -0700
Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation
In-Reply-To: <13a1868f-854e-4bcb-8666-8678b25acb04@default>
References:
<13a1868f-854e-4bcb-8666-8678b25acb04@default>
Message-ID:
Ah, okay. Thanks, Iris. I should already know known that - Martin has
explained it to me before.
Vincent - let me know how you want to proceed.
Jeremy
On Tue, May 27, 2014 at 10:00 PM, Iris Clark wrote:
> Hi, Jeremy.
>
> As an "Author", you can create a changeset but you can't push to the repo
> until you're a "Committer". Additional details about the differences
> between Author and Committer may be found here [1,2].
>
> The diffs to create a changeset are (of course) in your webrev. Your
> Sponsor can use that along with the "hg commit -u jmanson ..." to list you
> as the changeset Author. Alternatively, your Sponsor may want you to just
> send the output of "hg export -g" which would preserve information in the
> changeset header including the author, commit comment, etc.
>
> Thanks,
> iris
>
> [1]: http://openjdk.java.net/projects/#project-author
> [2]: http://openjdk.java.net/projects/#project-committer
>
> -----Original Message-----
> From: Jeremy Manson [mailto:jeremymanson at google.com]
> Sent: Tuesday, May 27, 2014 2:19 PM
> To: Vincent Ryan
> Cc: OpenJDK; core-libs-dev
> Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key
> Generation
>
> Thanks, Vincent. This would be the first change I've made as an author,
> so I'm not sure what the process is. I think I just need someone to do the
> review, and then I can check it in?
>
> Jeremy
>
>
> On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan
> wrote:
>
> > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor
> > your fix if you wish.
> >
> > On 27 May 2014, at 21:09, Jeremy Manson wrote:
> >
> > > Just like the title says - every time you generate a new private
> > > key, you leak a little memory. Webrev here:
> > >
> > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/
> > >
> > > This is probably the wrong mailing list for this bug, but I expect
> > someone
> > > on this list will point me in the right direction.
> > >
> > > Jeremy
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ivan.gerasimov at oracle.com Wed May 28 20:39:29 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 29 May 2014 00:39:29 +0400
Subject: RFR [7047033] (smartcardio) Card.disconnect(boolean reset) does not
reset when reset is true
Message-ID: <53864981.3090809@oracle.com>
Hello!
The argument 'reset' of javax.smartcardio.Card#disconnect has the
reverse logic: When it is true, the card is not reset and vice versa.
Would you please help review the trivial fix for this issue?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-7047033
WEBREV: http://cr.openjdk.java.net/~igerasim/7047033/0/webrev/
Sincerely yours,
Ivan
From ivan.gerasimov at oracle.com Wed May 28 21:00:28 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 29 May 2014 01:00:28 +0400
Subject: RFR [8043720] (smartcardio) Native memory should be handled more
accurately
In-Reply-To: <5384E7E7.1080409@oracle.com>
References: <5384E7E7.1080409@oracle.com>
Message-ID: <53864E6C.4030505@oracle.com>
One additional change:
In pcsc_multi2jstring() it is better to make sure the whole parsed
buffer is null-terminates.
This way we can guarantee that in the following line we will not access
memory outside the buffer:
js = (*env)->NewStringUTF(env, tab[cnt]);
Would you please help review the updated webrev?
http://cr.openjdk.java.net/~igerasim/8043720/1/webrev/
Sincerely yours,
Ivan
On 27.05.2014 23:30, Ivan Gerasimov wrote:
> Hello!
>
> Here is a proposal to make some native memory manipulations in
> src/share/native/sun/security/smartcardio/pcsc.c more accurate.
>
> 1)
> Add another argument to pcsc_multi2jstring() which will hold the size
> of the character array to be parsed.
> In the function we make sure we do not access memory outside the array.
>
> 2)
> In pcsc_multi2jstring():
> There is a constant PCSCLITE_MAX_READERS_CONTEXTS == 16, which limits
> number of cardreaders in the system.
> So we don't need to allocate the buffer with malloc.
>
> 3)
> In Java_sun_security_smartcardio_PCSC_SCardListReaders():
> The 'size' variable is initialized in the pcsc-lite API call to
> SCardListReaders.
> Even though it should not be zero, if SCardListReaders returned
> SUCCESS, it's still a call of foreign function.
> Thus we better handle the case when size == 0.
>
> 4)
> Currently Java_sun_security_smartcardio_PCSC_SCardGetStatusChange is
> always called with non-empty jReaderNames argument.
> However, it seems easy to make it more robust with a couple of checks
> for the empty array of names.
>
> 5)
> In Java_sun_security_smartcardio_PCSC_SCardGetStatusChange, readers'
> names are allocated with strdup() and later freed with free().
> If the program gets to cleanup upon an error, some of the names may
> turn out be be never initialized, so free() can fail.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043720
> WEBREV: http://cr.openjdk.java.net/~igerasim/8043720/0/webrev/
>
> Sincerely yours,
> Ivan
>
>
>
From valerie.peng at oracle.com Wed May 28 21:40:03 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Wed, 28 May 2014 14:40:03 -0700
Subject: RFR [7047033] (smartcardio) Card.disconnect(boolean reset) does
not reset when reset is true
In-Reply-To: <53864981.3090809@oracle.com>
References: <53864981.3090809@oracle.com>
Message-ID: <538657B3.7000508@oracle.com>
Looks good.
Valerie
On 05/28/14 13:39, Ivan Gerasimov wrote:
> Hello!
>
> The argument 'reset' of javax.smartcardio.Card#disconnect has the
> reverse logic: When it is true, the card is not reset and vice versa.
> Would you please help review the trivial fix for this issue?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7047033
> WEBREV: http://cr.openjdk.java.net/~igerasim/7047033/0/webrev/
>
> Sincerely yours,
> Ivan
From valerie.peng at oracle.com Wed May 28 22:42:27 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Wed, 28 May 2014 15:42:27 -0700
Subject: RFR [8043720] (smartcardio) Native memory should be handled more
accurately
In-Reply-To: <53864E6C.4030505@oracle.com>
References: <5384E7E7.1080409@oracle.com> <53864E6C.4030505@oracle.com>
Message-ID: <53866653.5020207@oracle.com>
Changes look fine.
Thanks,
Valerie
On 05/28/14 14:00, Ivan Gerasimov wrote:
> One additional change:
> In pcsc_multi2jstring() it is better to make sure the whole parsed
> buffer is null-terminates.
>
> This way we can guarantee that in the following line we will not
> access memory outside the buffer:
> js = (*env)->NewStringUTF(env, tab[cnt]);
>
> Would you please help review the updated webrev?
> http://cr.openjdk.java.net/~igerasim/8043720/1/webrev/
>
> Sincerely yours,
> Ivan
>
>
> On 27.05.2014 23:30, Ivan Gerasimov wrote:
>> Hello!
>>
>> Here is a proposal to make some native memory manipulations in
>> src/share/native/sun/security/smartcardio/pcsc.c more accurate.
>>
>> 1)
>> Add another argument to pcsc_multi2jstring() which will hold the size
>> of the character array to be parsed.
>> In the function we make sure we do not access memory outside the array.
>>
>> 2)
>> In pcsc_multi2jstring():
>> There is a constant PCSCLITE_MAX_READERS_CONTEXTS == 16, which limits
>> number of cardreaders in the system.
>> So we don't need to allocate the buffer with malloc.
>>
>> 3)
>> In Java_sun_security_smartcardio_PCSC_SCardListReaders():
>> The 'size' variable is initialized in the pcsc-lite API call to
>> SCardListReaders.
>> Even though it should not be zero, if SCardListReaders returned
>> SUCCESS, it's still a call of foreign function.
>> Thus we better handle the case when size == 0.
>>
>> 4)
>> Currently Java_sun_security_smartcardio_PCSC_SCardGetStatusChange is
>> always called with non-empty jReaderNames argument.
>> However, it seems easy to make it more robust with a couple of checks
>> for the empty array of names.
>>
>> 5)
>> In Java_sun_security_smartcardio_PCSC_SCardGetStatusChange, readers'
>> names are allocated with strdup() and later freed with free().
>> If the program gets to cleanup upon an error, some of the names may
>> turn out be be never initialized, so free() can fail.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043720
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8043720/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>>
>>
>
From valerie.peng at oracle.com Wed May 28 23:25:27 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Wed, 28 May 2014 16:25:27 -0700
Subject: GSSCredential inside Subject?
In-Reply-To: <8FBC27C9-A32E-45DF-BF6B-B40B23B8367B@oracle.com>
References: <8FBC27C9-A32E-45DF-BF6B-B40B23B8367B@oracle.com>
Message-ID: <53867067.5030105@oracle.com>
AFAIK, this searchSubject utility function is looking for the requested
GSSCredentialSpi objects (not GSSCredentialImpl object which contains a
Hashtable of GSSCredentialSpi objects and their keys).
When creating the Subject object ourselves, we only convert and stores
Kerberos-specific creds and ignores non-Kerberos creds (including native
GSS cred since all we have is native GSS cred handle which can't be
converted into KerberosKey/Ticket).
However, the app can do whatever they want when constructing their own
Subject objects. Although I am not sure if any such usage exists.
Valerie
On 05/27/14 03:50, Wang Weijun wrote:
> Hi Valerie
>
> I am working on breaking JGSS into modules and is now looking at sun/security/jgss/GSSUtil.java. There is a method
>
> public static Vector
> searchSubject(final GSSNameSpi name,
> final Oid mech,
> final boolean initiate,
> final Class credCls) {
>
> which goes inside a Subject's priv cred sets looking for GSSCredentialImpl objects. I searched thru other JDK codes and cannot see who is putting those objects there. Do you remember anything? Or we are thinking about applications putting them there? I cannot think of any such convention.
>
> In fact, all I can see JAAS/JGSS/krb5 doing with a Subject is putting KerberosPrincipal into princ set and KerberosKey/KerberosTicket/KeyTab into priv cred set. Nothing else.
>
> Thanks
> Max
>
From robbiexgibson at yahoo.com Wed May 28 23:04:36 2014
From: robbiexgibson at yahoo.com (Robert Gibson)
Date: Wed, 28 May 2014 16:04:36 -0700 (PDT)
Subject: Change in PKIX certificate chain validation Java 6->Java 7
Message-ID: <1401318276.81408.YahooMailNeo@web121305.mail.ne1.yahoo.com>
Hi,
I was researching a StackOverflow question [1] and I came across some behaviour with the validation of certificate chains that I don't quite understand.
I have a chain consisting of a root certificate with validity period 1999->2019; an intermediate certificate with validity period 2004->2024; and a server certificate with validity period 2006->2016. sun.security.provider.certpath.AdaptableX509CertSelector seems to be choking because the validity end date of the intermediate certificate is after the validity end date of the root certificate, even though we are currently within the validity period for all three certificates. ?(By the way, -Djava.security.debug=certpath doesn't actually give any clues as to the reason for the failure, I had to resort to debugging the process.)
Is this expected behaviour? Should I file a bug?
'Invalid' certificate chain is available at [2]. All the browsers I tried validated it fine, it's just Java 7+ that chokes.
Thanks,
Robbie
[1] http://stackoverflow.com/questions/23775155/pkix-path-does-not-chain-with-any-of-the-trust-anchors-error-in-windows-environm
[2]?https://www.envmgr.com/LabelService/EwsLabelService.asmx
From jason.uh at oracle.com Thu May 29 01:55:18 2014
From: jason.uh at oracle.com (Jason Uh)
Date: Wed, 28 May 2014 18:55:18 -0700
Subject: Change in PKIX certificate chain validation Java 6->Java 7
In-Reply-To: <1401318276.81408.YahooMailNeo@web121305.mail.ne1.yahoo.com>
References: <1401318276.81408.YahooMailNeo@web121305.mail.ne1.yahoo.com>
Message-ID: <53869386.7080204@oracle.com>
Hi Robert,
This was actually fixed in
https://bugs.openjdk.java.net/browse/JDK-8021804 and is pending a
backport to JDK 7u.
Thanks,
Jason
On 5/28/14 4:04 PM, Robert Gibson wrote:
> Hi,
> I was researching a StackOverflow question [1] and I came across some behaviour with the validation of certificate chains that I don't quite understand.
>
> I have a chain consisting of a root certificate with validity period 1999->2019; an intermediate certificate with validity period 2004->2024; and a server certificate with validity period 2006->2016. sun.security.provider.certpath.AdaptableX509CertSelector seems to be choking because the validity end date of the intermediate certificate is after the validity end date of the root certificate, even though we are currently within the validity period for all three certificates. (By the way, -Djava.security.debug=certpath doesn't actually give any clues as to the reason for the failure, I had to resort to debugging the process.)
>
> Is this expected behaviour? Should I file a bug?
>
> 'Invalid' certificate chain is available at [2]. All the browsers I tried validated it fine, it's just Java 7+ that chokes.
>
> Thanks,
> Robbie
>
> [1] http://stackoverflow.com/questions/23775155/pkix-path-does-not-chain-with-any-of-the-trust-anchors-error-in-windows-environm
> [2] https://www.envmgr.com/LabelService/EwsLabelService.asmx
>
From weijun.wang at oracle.com Thu May 29 04:22:25 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 29 May 2014 12:22:25 +0800
Subject: GSSCredential inside Subject?
In-Reply-To: <53867067.5030105@oracle.com>
References: <8FBC27C9-A32E-45DF-BF6B-B40B23B8367B@oracle.com>
<53867067.5030105@oracle.com>
Message-ID: <7C84FA95-54F4-46F1-AE6A-BA9C07386362@oracle.com>
On May 29, 2014, at 7:25, Valerie (Yu-Ching) Peng wrote:
>
> AFAIK, this searchSubject utility function is looking for the requested GSSCredentialSpi objects (not GSSCredentialImpl object which contains a Hashtable of GSSCredentialSpi objects and their keys).
The method returns GSSCredentialSpi but what is stored inside the subject is GSSCredentialImpl
Iterator iterator =
accSubj.getPrivateCredentials
(GSSCredentialImpl.class).iterator();
Since GSSCredentialImpl is GSSCredential which is public, applications are able to manipulate them. That's what I am worried about.
>
> When creating the Subject object ourselves, we only convert and stores Kerberos-specific creds and ignores non-Kerberos creds (including native GSS cred since all we have is native GSS cred handle which can't be converted into KerberosKey/Ticket).
>
> However, the app can do whatever they want when constructing their own Subject objects. Although I am not sure if any such usage exists.
I'll read more code history to see if there is a convention.
Thanks
Max
>
> Valerie
>
> On 05/27/14 03:50, Wang Weijun wrote:
>> Hi Valerie
>>
>> I am working on breaking JGSS into modules and is now looking at sun/security/jgss/GSSUtil.java. There is a method
>>
>> public static Vector
>> searchSubject(final GSSNameSpi name,
>> final Oid mech,
>> final boolean initiate,
>> final Class credCls) {
>>
>> which goes inside a Subject's priv cred sets looking for GSSCredentialImpl objects. I searched thru other JDK codes and cannot see who is putting those objects there. Do you remember anything? Or we are thinking about applications putting them there? I cannot think of any such convention.
>>
>> In fact, all I can see JAAS/JGSS/krb5 doing with a Subject is putting KerberosPrincipal into princ set and KerberosKey/KerberosTicket/KeyTab into priv cred set. Nothing else.
>>
>> Thanks
>> Max
>>
>
From weijun.wang at oracle.com Thu May 29 09:38:47 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 29 May 2014 17:38:47 +0800
Subject: 2nd round RFR 8036779: sun.security.krb5.KdcComm interprets
kdc_timeout asmsec instead of sec
In-Reply-To:
References: <20140518134820.6A65C17FDA1@rebar.astron.com>
<5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
Message-ID: <8F20F2CE-EB0F-410C-B083-440CC2920A86@oracle.com>
New webrev at
http://cr.openjdk.java.net/~weijun/8036779/webrev.01/
The value can take the form of a bare non-negative integer in milliseconds, or a non-negative integer followed by "s" (no space between) in seconds.
Thanks
Max
On May 19, 2014, at 21:49, Wang Weijun wrote:
> After some discussion with mit and heimdal lead engineers, I don't want to support ms at the moment. mit does not use kdc_timeout at all and heimdal's internal presentation is of seconds.
>
> So this is my plan: support "s" but if unspecified treat it as "ms". There will be a release notes describing this. This won't automatically fix the case for the bug reporter but at least give him a workaround -- use the 's' unit for interop.
>
> Does this sound clean?
>
> Thanks
> Max
>
> On May 18, 2014, at 23:12, Xuelei Fan wrote:
>
>>
>>> On May 18, 2014, at 9:48 PM, christos at zoulas.com wrote:
>>>
>>> On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
>>> -- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>>>
>>> | How about this? I will support "s" and "ms" units ("ms" is not defined by o=
>>> | ther vendors though). But will still try to be a little smart when there is=
>>> | no unit.
>>>
>>> Heuristics can make the situation worse; they are difficult to document
>>> and explain to users. But if java is going to support ms, let's coordinate
>>> with heimdal and mit to make them support it too.
>>>
>> +1
>>
>> Xuelei
>>
>>> christos
>>>
>
From xuelei.fan at oracle.com Thu May 29 10:19:42 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 29 May 2014 18:19:42 +0800
Subject: 2nd round RFR 8036779: sun.security.krb5.KdcComm interprets
kdc_timeout asmsec instead of sec
In-Reply-To: <8F20F2CE-EB0F-410C-B083-440CC2920A86@oracle.com>
References: <20140518134820.6A65C17FDA1@rebar.astron.com>
<5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
<8F20F2CE-EB0F-410C-B083-440CC2920A86@oracle.com>
Message-ID: <538709BE.8090707@oracle.com>
Looks fine to me. A minor comment about the coding conversions.
src/share/classes/sun/security/krb5/KdcComm.java
================================================
437 if (s == null) return -1;
I would suggest always use braces even for single line statement [1].
if (s == null) {
return -1;
}
Xuelei
[1]: http://sim.ivi.co/2014/02/love-to-use-braces-even-for-single-line.html
On 5/29/2014 5:38 PM, Wang Weijun wrote:
> New webrev at
>
> http://cr.openjdk.java.net/~weijun/8036779/webrev.01/
>
> The value can take the form of a bare non-negative integer in milliseconds, or a non-negative integer followed by "s" (no space between) in seconds.
>
> Thanks
> Max
>
> On May 19, 2014, at 21:49, Wang Weijun wrote:
>
>> After some discussion with mit and heimdal lead engineers, I don't want to support ms at the moment. mit does not use kdc_timeout at all and heimdal's internal presentation is of seconds.
>>
>> So this is my plan: support "s" but if unspecified treat it as "ms". There will be a release notes describing this. This won't automatically fix the case for the bug reporter but at least give him a workaround -- use the 's' unit for interop.
>>
>> Does this sound clean?
>>
>> Thanks
>> Max
>>
>> On May 18, 2014, at 23:12, Xuelei Fan wrote:
>>
>>>
>>>> On May 18, 2014, at 9:48 PM, christos at zoulas.com wrote:
>>>>
>>>> On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
>>>> -- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>>>>
>>>> | How about this? I will support "s" and "ms" units ("ms" is not defined by o=
>>>> | ther vendors though). But will still try to be a little smart when there is=
>>>> | no unit.
>>>>
>>>> Heuristics can make the situation worse; they are difficult to document
>>>> and explain to users. But if java is going to support ms, let's coordinate
>>>> with heimdal and mit to make them support it too.
>>>>
>>> +1
>>>
>>> Xuelei
>>>
>>>> christos
>>>>
>>
>
From vincent.x.ryan at oracle.com Thu May 29 13:29:05 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 29 May 2014 14:29:05 +0100
Subject: [9] RFR: 8044038: Security tests fail on 32 bit linux platform
Message-ID: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
Please review this trivial change to enable the PKCS11/NSS tests to be run on older (Ubuntu) Linux 32-bit releases.
The ?/usr/lib32? directory is now included in the search order for NSS libraries.
Bug: https://bugs.openjdk.java.net/browse/JDK-8044038
Webrev: http://cr.openjdk.java.net/~vinnie/8044038/webrev.00
Thanks.
From xuelei.fan at oracle.com Thu May 29 13:35:50 2014
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 29 May 2014 21:35:50 +0800
Subject: [9] RFR: 8044038: Security tests fail on 32 bit linux platform
In-Reply-To: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
References: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
Message-ID: <538737B6.2060108@oracle.com>
Looks fine to me.
Xuelei
On 5/29/2014 9:29 PM, Vincent Ryan wrote:
> Please review this trivial change to enable the PKCS11/NSS tests to be run on older (Ubuntu) Linux 32-bit releases.
> The ?/usr/lib32? directory is now included in the search order for NSS libraries.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044038
> Webrev: http://cr.openjdk.java.net/~vinnie/8044038/webrev.00
>
> Thanks.
>
>
>
From weijun.wang at oracle.com Thu May 29 13:40:38 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 29 May 2014 21:40:38 +0800
Subject: [9] RFR: 8044038: Security tests fail on 32 bit linux platform
In-Reply-To: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
References: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
Message-ID: <7A6B6012-7FBE-42BB-8DC0-DF5E7A14F5A3@oracle.com>
Vinnie
The bug report shows sun/security/tools/keytool/autotest.sh also failed. The test includes
LIBNAME=`find_one \
"/usr/lib/libsoftokn3.so" \
"/usr/lib/i386-linux-gnu/nss/libsoftokn3.so" \
"/usr/lib/nss/libsoftokn3.so"`
Maybe adding a line for /usr/lib32?
Have you verified the fix on the machine?
Thanks
Max
On May 29, 2014, at 21:29, Vincent Ryan wrote:
> Please review this trivial change to enable the PKCS11/NSS tests to be run on older (Ubuntu) Linux 32-bit releases.
> The ?/usr/lib32? directory is now included in the search order for NSS libraries.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044038
> Webrev: http://cr.openjdk.java.net/~vinnie/8044038/webrev.00
>
> Thanks.
>
>
>
From vincent.x.ryan at oracle.com Thu May 29 13:47:16 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 29 May 2014 14:47:16 +0100
Subject: [9] RFR: 8044038: Security tests fail on 32 bit linux platform
In-Reply-To: <7A6B6012-7FBE-42BB-8DC0-DF5E7A14F5A3@oracle.com>
References: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
<7A6B6012-7FBE-42BB-8DC0-DF5E7A14F5A3@oracle.com>
Message-ID:
Sure. I?ll add it to autotest.sh too.
On 29 May 2014, at 14:40, Wang Weijun wrote:
> Vinnie
>
> The bug report shows sun/security/tools/keytool/autotest.sh also failed. The test includes
>
> LIBNAME=`find_one \
> "/usr/lib/libsoftokn3.so" \
> "/usr/lib/i386-linux-gnu/nss/libsoftokn3.so" \
> "/usr/lib/nss/libsoftokn3.so"`
>
> Maybe adding a line for /usr/lib32?
>
> Have you verified the fix on the machine?
>
> Thanks
> Max
>
> On May 29, 2014, at 21:29, Vincent Ryan wrote:
>
>> Please review this trivial change to enable the PKCS11/NSS tests to be run on older (Ubuntu) Linux 32-bit releases.
>> The ?/usr/lib32? directory is now included in the search order for NSS libraries.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044038
>> Webrev: http://cr.openjdk.java.net/~vinnie/8044038/webrev.00
>>
>> Thanks.
>>
>>
>>
>
From vincent.x.ryan at oracle.com Thu May 29 14:50:08 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 29 May 2014 15:50:08 +0100
Subject: [9] RFR: 8044038: Security tests fail on 32 bit linux platform
In-Reply-To:
References: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
<7A6B6012-7FBE-42BB-8DC0-DF5E7A14F5A3@oracle.com>
Message-ID: <36732697-FF17-4A3D-9BA2-CDDF1884D6A6@oracle.com>
Updated webrev at:
http://cr.openjdk.java.net/~vinnie/8044038/webrev.01/
On 29 May 2014, at 14:47, Vincent Ryan wrote:
> Sure. I?ll add it to autotest.sh too.
>
> On 29 May 2014, at 14:40, Wang Weijun wrote:
>
>> Vinnie
>>
>> The bug report shows sun/security/tools/keytool/autotest.sh also failed. The test includes
>>
>> LIBNAME=`find_one \
>> "/usr/lib/libsoftokn3.so" \
>> "/usr/lib/i386-linux-gnu/nss/libsoftokn3.so" \
>> "/usr/lib/nss/libsoftokn3.so"`
>>
>> Maybe adding a line for /usr/lib32?
>>
>> Have you verified the fix on the machine?
>>
>> Thanks
>> Max
>>
>> On May 29, 2014, at 21:29, Vincent Ryan wrote:
>>
>>> Please review this trivial change to enable the PKCS11/NSS tests to be run on older (Ubuntu) Linux 32-bit releases.
>>> The ?/usr/lib32? directory is now included in the search order for NSS libraries.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044038
>>> Webrev: http://cr.openjdk.java.net/~vinnie/8044038/webrev.00
>>>
>>> Thanks.
>>>
>>>
>>>
>>
>
From weijun.wang at oracle.com Thu May 29 14:55:42 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 29 May 2014 22:55:42 +0800
Subject: [9] RFR: 8044038: Security tests fail on 32 bit linux platform
In-Reply-To: <36732697-FF17-4A3D-9BA2-CDDF1884D6A6@oracle.com>
References: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
<7A6B6012-7FBE-42BB-8DC0-DF5E7A14F5A3@oracle.com>
<36732697-FF17-4A3D-9BA2-CDDF1884D6A6@oracle.com>
Message-ID: <32ED5F25-5FE4-41E9-ABDD-314B9537B526@oracle.com>
Great. That looks good.
Thanks
Max
On May 29, 2014, at 22:50, Vincent Ryan wrote:
> Updated webrev at:
> http://cr.openjdk.java.net/~vinnie/8044038/webrev.01/
>
>
> On 29 May 2014, at 14:47, Vincent Ryan wrote:
>
>> Sure. I?ll add it to autotest.sh too.
>>
>> On 29 May 2014, at 14:40, Wang Weijun wrote:
>>
>>> Vinnie
>>>
>>> The bug report shows sun/security/tools/keytool/autotest.sh also failed. The test includes
>>>
>>> LIBNAME=`find_one \
>>> "/usr/lib/libsoftokn3.so" \
>>> "/usr/lib/i386-linux-gnu/nss/libsoftokn3.so" \
>>> "/usr/lib/nss/libsoftokn3.so"`
>>>
>>> Maybe adding a line for /usr/lib32?
>>>
>>> Have you verified the fix on the machine?
>>>
>>> Thanks
>>> Max
>>>
>>> On May 29, 2014, at 21:29, Vincent Ryan wrote:
>>>
>>>> Please review this trivial change to enable the PKCS11/NSS tests to be run on older (Ubuntu) Linux 32-bit releases.
>>>> The ?/usr/lib32? directory is now included in the search order for NSS libraries.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044038
>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8044038/webrev.00
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>
>>
>
From vincent.x.ryan at oracle.com Thu May 29 14:58:34 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 29 May 2014 15:58:34 +0100
Subject: [9] RFR: 8044038: Security tests fail on 32 bit linux platform
In-Reply-To: <32ED5F25-5FE4-41E9-ABDD-314B9537B526@oracle.com>
References: <83DC2BD9-8606-4AE1-BC9D-B6AF137A65A9@oracle.com>
<7A6B6012-7FBE-42BB-8DC0-DF5E7A14F5A3@oracle.com>
<36732697-FF17-4A3D-9BA2-CDDF1884D6A6@oracle.com>
<32ED5F25-5FE4-41E9-ABDD-314B9537B526@oracle.com>
Message-ID:
Thanks.
On 29 May 2014, at 15:55, Wang Weijun wrote:
> Great. That looks good.
>
> Thanks
> Max
>
> On May 29, 2014, at 22:50, Vincent Ryan wrote:
>
>> Updated webrev at:
>> http://cr.openjdk.java.net/~vinnie/8044038/webrev.01/
>>
>>
>> On 29 May 2014, at 14:47, Vincent Ryan wrote:
>>
>>> Sure. I?ll add it to autotest.sh too.
>>>
>>> On 29 May 2014, at 14:40, Wang Weijun wrote:
>>>
>>>> Vinnie
>>>>
>>>> The bug report shows sun/security/tools/keytool/autotest.sh also failed. The test includes
>>>>
>>>> LIBNAME=`find_one \
>>>> "/usr/lib/libsoftokn3.so" \
>>>> "/usr/lib/i386-linux-gnu/nss/libsoftokn3.so" \
>>>> "/usr/lib/nss/libsoftokn3.so"`
>>>>
>>>> Maybe adding a line for /usr/lib32?
>>>>
>>>> Have you verified the fix on the machine?
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>> On May 29, 2014, at 21:29, Vincent Ryan wrote:
>>>>
>>>>> Please review this trivial change to enable the PKCS11/NSS tests to be run on older (Ubuntu) Linux 32-bit releases.
>>>>> The ?/usr/lib32? directory is now included in the search order for NSS libraries.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044038
>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8044038/webrev.00
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
From ivan.gerasimov at oracle.com Thu May 29 18:28:58 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 29 May 2014 22:28:58 +0400
Subject: RFR [8044342] build failure on Windows noticed with recent smartcardio
fix.
Message-ID: <53877C6A.8070903@oracle.com>
Hi!
With the recent code modification I used a pcsc-lite specific constant
which is only defined on *nix platforms.
As a result, windows builds failed. Sorry about that!
Would you please review the partial backout fix: Dynamic array
allocation is restored.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044342
WEBREV: http://cr.openjdk.java.net/~igerasim/8044342/0/webrev/
Sincerely yours,
Ivan
From valerie.peng at oracle.com Thu May 29 20:09:57 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Thu, 29 May 2014 13:09:57 -0700
Subject: RFR [8044342] build failure on Windows noticed with recent
smartcardio fix.
In-Reply-To: <53877C6A.8070903@oracle.com>
References: <53877C6A.8070903@oracle.com>
Message-ID: <53879415.8000702@oracle.com>
1) Since we are rolling back to the earlier code, how about just use the
original code? I somehow find this easier to parse than the 2 nested
almost-identical for-loops in the current fix.
char* cp = spec;
while (*cp != 0) {
cp += (strlen(cp) + 1);
++cnt;
}
2) Add back the NULL check for the malloc call, e.g.
if (tab == NULL) {
throwOutOfMemoryError(env, NULL);
return NULL;
}
Thanks,
Valerie
On 05/29/14 11:28, Ivan Gerasimov wrote:
> Hi!
>
> With the recent code modification I used a pcsc-lite specific constant
> which is only defined on *nix platforms.
> As a result, windows builds failed. Sorry about that!
>
> Would you please review the partial backout fix: Dynamic array
> allocation is restored.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044342
> WEBREV: http://cr.openjdk.java.net/~igerasim/8044342/0/webrev/
>
> Sincerely yours,
> Ivan
From ivan.gerasimov at oracle.com Thu May 29 20:39:59 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 30 May 2014 00:39:59 +0400
Subject: RFR [8044342] build failure on Windows noticed with recent
smartcardio fix.
In-Reply-To: <53879415.8000702@oracle.com>
References: <53877C6A.8070903@oracle.com> <53879415.8000702@oracle.com>
Message-ID: <53879B1F.2040505@oracle.com>
Thanks Valerie!
On 30.05.2014 0:09, Valerie (Yu-Ching) Peng wrote:
>
> 1) Since we are rolling back to the earlier code, how about just use
> the original code? I somehow find this easier to parse than the 2
> nested almost-identical for-loops in the current fix.
> char* cp = spec;
> while (*cp != 0) {
> cp += (strlen(cp) + 1);
> ++cnt;
> }
>
> 2) Add back the NULL check for the malloc call, e.g.
> if (tab == NULL) {
> throwOutOfMemoryError(env, NULL);
> return NULL;
> }
>
Alright, I reverted it back:
http://cr.openjdk.java.net/~igerasim/8044342/1/webrev/
It may be worth to return to this code later, since pcsc_multi2jstring()
had been seen in the stack traces of some crash reports.
But at the moment, reverting to the original code may be the easiest way
to restore build-ability.
Sincerely yours,
Ivan
> Thanks,
> Valerie
>
>
> On 05/29/14 11:28, Ivan Gerasimov wrote:
>> Hi!
>>
>> With the recent code modification I used a pcsc-lite specific
>> constant which is only defined on *nix platforms.
>> As a result, windows builds failed. Sorry about that!
>>
>> Would you please review the partial backout fix: Dynamic array
>> allocation is restored.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044342
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8044342/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>
>
>
From valerie.peng at oracle.com Thu May 29 22:09:45 2014
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Thu, 29 May 2014 15:09:45 -0700
Subject: RFR [8044342] build failure on Windows noticed with recent
smartcardio fix.
In-Reply-To: <53879B1F.2040505@oracle.com>
References: <53877C6A.8070903@oracle.com> <53879415.8000702@oracle.com>
<53879B1F.2040505@oracle.com>
Message-ID: <5387B029.7090805@oracle.com>
Changes look good.
Thanks,
Valerie
On 05/29/14 13:39, Ivan Gerasimov wrote:
> Thanks Valerie!
>
> On 30.05.2014 0:09, Valerie (Yu-Ching) Peng wrote:
>>
>> 1) Since we are rolling back to the earlier code, how about just use
>> the original code? I somehow find this easier to parse than the 2
>> nested almost-identical for-loops in the current fix.
>> char* cp = spec;
>> while (*cp != 0) {
>> cp += (strlen(cp) + 1);
>> ++cnt;
>> }
>>
>> 2) Add back the NULL check for the malloc call, e.g.
>> if (tab == NULL) {
>> throwOutOfMemoryError(env, NULL);
>> return NULL;
>> }
>>
> Alright, I reverted it back:
>
> http://cr.openjdk.java.net/~igerasim/8044342/1/webrev/
>
> It may be worth to return to this code later, since
> pcsc_multi2jstring() had been seen in the stack traces of some crash
> reports.
> But at the moment, reverting to the original code may be the easiest
> way to restore build-ability.
>
> Sincerely yours,
> Ivan
>
>> Thanks,
>> Valerie
>>
>>
>> On 05/29/14 11:28, Ivan Gerasimov wrote:
>>> Hi!
>>>
>>> With the recent code modification I used a pcsc-lite specific
>>> constant which is only defined on *nix platforms.
>>> As a result, windows builds failed. Sorry about that!
>>>
>>> Would you please review the partial backout fix: Dynamic array
>>> allocation is restored.
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044342
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8044342/0/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>
>>
>>
>
From kumar.x.srinivasan at oracle.com Fri May 30 00:28:26 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 29 May 2014 17:28:26 -0700
Subject: RFR [8044342] build failure on Windows noticed with recent
smartcardio fix.
In-Reply-To: <5387B029.7090805@oracle.com>
References: <53877C6A.8070903@oracle.com> <53879415.8000702@oracle.com>
<53879B1F.2040505@oracle.com> <5387B029.7090805@oracle.com>
Message-ID: <5387D0AA.7000800@oracle.com>
Thanks for fixing this so quickly, the build appears to be fine now.
Kumar
On 5/29/2014 3:09 PM, Valerie (Yu-Ching) Peng wrote:
> Changes look good.
> Thanks,
> Valerie
>
> On 05/29/14 13:39, Ivan Gerasimov wrote:
>> Thanks Valerie!
>>
>> On 30.05.2014 0:09, Valerie (Yu-Ching) Peng wrote:
>>>
>>> 1) Since we are rolling back to the earlier code, how about just use
>>> the original code? I somehow find this easier to parse than the 2
>>> nested almost-identical for-loops in the current fix.
>>> char* cp = spec;
>>> while (*cp != 0) {
>>> cp += (strlen(cp) + 1);
>>> ++cnt;
>>> }
>>>
>>> 2) Add back the NULL check for the malloc call, e.g.
>>> if (tab == NULL) {
>>> throwOutOfMemoryError(env, NULL);
>>> return NULL;
>>> }
>>>
>> Alright, I reverted it back:
>>
>> http://cr.openjdk.java.net/~igerasim/8044342/1/webrev/
>>
>> It may be worth to return to this code later, since
>> pcsc_multi2jstring() had been seen in the stack traces of some crash
>> reports.
>> But at the moment, reverting to the original code may be the easiest
>> way to restore build-ability.
>>
>> Sincerely yours,
>> Ivan
>>
>>> Thanks,
>>> Valerie
>>>
>>>
>>> On 05/29/14 11:28, Ivan Gerasimov wrote:
>>>> Hi!
>>>>
>>>> With the recent code modification I used a pcsc-lite specific
>>>> constant which is only defined on *nix platforms.
>>>> As a result, windows builds failed. Sorry about that!
>>>>
>>>> Would you please review the partial backout fix: Dynamic array
>>>> allocation is restored.
>>>>
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044342
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8044342/0/webrev/
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>
>>>
>>>
>>
>
From weijun.wang at oracle.com Fri May 30 06:46:01 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 30 May 2014 14:46:01 +0800
Subject: 2nd round RFR 8036779: sun.security.krb5.KdcComm interprets
kdc_timeout asmsec instead of sec
In-Reply-To: <538709BE.8090707@oracle.com>
References: <20140518134820.6A65C17FDA1@rebar.astron.com>
<5FE5F206-5491-402A-8227-56FE4A076D63@Oracle.Com>
<8F20F2CE-EB0F-410C-B083-440CC2920A86@oracle.com>
<538709BE.8090707@oracle.com>
Message-ID: <8E1B71B9-637E-4C0B-95E5-096963B512A7@oracle.com>
On May 29, 2014, at 18:19, Xuelei Fan wrote:
> Looks fine to me. A minor comment about the coding conversions.
>
> src/share/classes/sun/security/krb5/KdcComm.java
> ================================================
> 437 if (s == null) return -1;
>
> I would suggest always use braces even for single line statement [1].
> if (s == null) {
> return -1;
> }
OK. Updated.
I am strongly against a single-line block on the new line
if (s == null)
return -1;
but think it's OK to write them on a single line.
BTW, some funny codes:
void day_of_my_life() {
...
if (hour > 9 && hour < 18)
goto work;
goto work;
time_to_play();
}
Thanks
Max
>
>
> Xuelei
>
> [1]: http://sim.ivi.co/2014/02/love-to-use-braces-even-for-single-line.html
>
>
> On 5/29/2014 5:38 PM, Wang Weijun wrote:
>> New webrev at
>>
>> http://cr.openjdk.java.net/~weijun/8036779/webrev.01/
>>
>> The value can take the form of a bare non-negative integer in milliseconds, or a non-negative integer followed by "s" (no space between) in seconds.
>>
>> Thanks
>> Max
>>
>> On May 19, 2014, at 21:49, Wang Weijun wrote:
>>
>>> After some discussion with mit and heimdal lead engineers, I don't want to support ms at the moment. mit does not use kdc_timeout at all and heimdal's internal presentation is of seconds.
>>>
>>> So this is my plan: support "s" but if unspecified treat it as "ms". There will be a release notes describing this. This won't automatically fix the case for the bug reporter but at least give him a workaround -- use the 's' unit for interop.
>>>
>>> Does this sound clean?
>>>
>>> Thanks
>>> Max
>>>
>>> On May 18, 2014, at 23:12, Xuelei Fan wrote:
>>>
>>>>
>>>>> On May 18, 2014, at 9:48 PM, christos at zoulas.com wrote:
>>>>>
>>>>> On May 18, 10:06am, weijun.wang at oracle.com (Wang Weijun) wrote:
>>>>> -- Subject: Re: RFR 8036779: sun.security.krb5.KdcComm interprets kdc_timeout
>>>>>
>>>>> | How about this? I will support "s" and "ms" units ("ms" is not defined by o=
>>>>> | ther vendors though). But will still try to be a little smart when there is=
>>>>> | no unit.
>>>>>
>>>>> Heuristics can make the situation worse; they are difficult to document
>>>>> and explain to users. But if java is going to support ms, let's coordinate
>>>>> with heimdal and mit to make them support it too.
>>>>>
>>>> +1
>>>>
>>>> Xuelei
>>>>
>>>>> christos
>>>>>
>>>
>>
>
From Alan.Bateman at oracle.com Fri May 30 12:58:15 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 30 May 2014 13:58:15 +0100
Subject: 8044027: Remove unused XML Signature schema and dtd files from source
Message-ID: <53888067.6090309@oracle.com>
As part of preparing to restructure the source code as modules, we are
finding a number of files in the jdk repository that are not used in the
build. In this case there are a number of XML schema/DTD files that came
from the original Apache code but ignored in the JDK build. I checked
with Sean and he told me that they can be deleted so I need a Reviewer
to okay reviewing the following files:
R com/sun/org/apache/xml/internal/security/resource/schema/etsi.xsd
R com/sun/org/apache/xml/internal/security/resource/schema/xenc-schema.rng
R com/sun/org/apache/xml/internal/security/resource/schema/xenc-schema.xsd
R
com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.dtd
R
com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.rng
R
com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.xsd
There is also one small clean-up in the build as it is no longer
necessary to exclude these files from being copied into the build tree.
diff --git a/make/CopyIntoClasses.gmk b/make/CopyIntoClasses.gmk
--- a/make/CopyIntoClasses.gmk
+++ b/make/CopyIntoClasses.gmk
@@ -30,7 +30,6 @@
# These directories should not be copied at all
EXCLUDES += \
- com/sun/org/apache/xml/internal/security/resource/schema \
java/awt/doc-files \
java/lang/doc-files \
javax/swing/doc-files \
Thanks,
Alan.
From sean.mullan at oracle.com Fri May 30 13:06:00 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 30 May 2014 09:06:00 -0400
Subject: 8044027: Remove unused XML Signature schema and dtd files from
source
In-Reply-To: <53888067.6090309@oracle.com>
References: <53888067.6090309@oracle.com>
Message-ID: <53888238.4070606@oracle.com>
Looks fine to me. You can remove the schema directory as well since it
will be empty after this change.
--Sean
On 05/30/2014 08:58 AM, Alan Bateman wrote:
>
> As part of preparing to restructure the source code as modules, we are
> finding a number of files in the jdk repository that are not used in the
> build. In this case there are a number of XML schema/DTD files that came
> from the original Apache code but ignored in the JDK build. I checked
> with Sean and he told me that they can be deleted so I need a Reviewer
> to okay reviewing the following files:
>
> R com/sun/org/apache/xml/internal/security/resource/schema/etsi.xsd
> R com/sun/org/apache/xml/internal/security/resource/schema/xenc-schema.rng
> R com/sun/org/apache/xml/internal/security/resource/schema/xenc-schema.xsd
> R
> com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.dtd
>
> R
> com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.rng
>
> R
> com/sun/org/apache/xml/internal/security/resource/schema/xmldsig-core-schema.xsd
>
>
> There is also one small clean-up in the build as it is no longer
> necessary to exclude these files from being copied into the build tree.
>
> diff --git a/make/CopyIntoClasses.gmk b/make/CopyIntoClasses.gmk
> --- a/make/CopyIntoClasses.gmk
> +++ b/make/CopyIntoClasses.gmk
> @@ -30,7 +30,6 @@
>
> # These directories should not be copied at all
> EXCLUDES += \
> - com/sun/org/apache/xml/internal/security/resource/schema \
> java/awt/doc-files \
> java/lang/doc-files \
> javax/swing/doc-files \
>
>
> Thanks,
> Alan.
>
>
>
From Alan.Bateman at oracle.com Fri May 30 13:39:45 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 30 May 2014 14:39:45 +0100
Subject: 8044027: Remove unused XML Signature schema and dtd files from
source
In-Reply-To: <53888238.4070606@oracle.com>
References: <53888067.6090309@oracle.com> <53888238.4070606@oracle.com>
Message-ID: <53888A21.60305@oracle.com>
On 30/05/2014 14:06, Sean Mullan wrote:
> Looks fine to me. You can remove the schema directory as well since it
> will be empty after this change.
Thanks. Mercurial looks after empty directories, a hg rm isn't required
for that.
-Alan.
From roger.riggs at oracle.com Fri May 30 18:30:19 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 30 May 2014 14:30:19 -0400
Subject: RFR 80044461: Cleanup new Boolean and single character strings
Message-ID: <5388CE3B.4070205@oracle.com>
A quick sanity check please for these cleanup changes to remove uses of
new Boolean and using chars instead of single character strings contributed
by Ot?vio Gon?alves de Santana.
These changes update multiple classes in the jdk9-dev repo (except
client packages).
webrev: http://cr.openjdk.java.net/~rriggs/webrev-8044461-cleanup/
Issue: https://bugs.openjdk.java.net/browse/JDK-8044461
Thanks, Roger
From Lance.Andersen at oracle.com Fri May 30 18:46:49 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Fri, 30 May 2014 14:46:49 -0400
Subject: RFR 80044461: Cleanup new Boolean and single character strings
In-Reply-To: <5388CE3B.4070205@oracle.com>
References: <5388CE3B.4070205@oracle.com>
Message-ID: <7D86B773-EAEB-4AEE-B3B8-6F97F744CBD1@oracle.com>
Looks fine
On May 30, 2014, at 2:30 PM, roger riggs wrote:
> A quick sanity check please for these cleanup changes to remove uses of
> new Boolean and using chars instead of single character strings contributed
> by Ot?vio Gon?alves de Santana.
>
> These changes update multiple classes in the jdk9-dev repo (except client packages).
>
> webrev: http://cr.openjdk.java.net/~rriggs/webrev-8044461-cleanup/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8044461
>
> Thanks, Roger
>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL:
From Alan.Bateman at oracle.com Fri May 30 19:07:01 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 30 May 2014 20:07:01 +0100
Subject: RFR 80044461: Cleanup new Boolean and single character strings
In-Reply-To: <5388CE3B.4070205@oracle.com>
References: <5388CE3B.4070205@oracle.com>
Message-ID: <5388D6D5.2030709@oracle.com>
On 30/05/2014 19:30, roger riggs wrote:
> A quick sanity check please for these cleanup changes to remove uses of
> new Boolean and using chars instead of single character strings
> contributed
> by Ot?vio Gon?alves de Santana.
>
> These changes update multiple classes in the jdk9-dev repo (except
> client packages).
>
> webrev: http://cr.openjdk.java.net/~rriggs/webrev-8044461-cleanup/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8044461
You might want to check the alignment in VMOptionCompositeData and
StackTraceElementCompositeData, otherwise I don't see any issues.
-Alan.