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 implemen
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
}
"r
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 updat
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
st
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 ProtocolVe
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 retu
>> 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
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 sessi
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?
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
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
dire
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 signific
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.
Ye
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
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 serv
> 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.
R
16 matches
Mail list logo
