On 4/21/2016 11:10 PM, Wang Weijun wrote:
>
>> On Apr 21, 2016, at 9:44 PM, Xuelei Fan wrote:
>>
public MyCertStore extends CertStoreSpi {
public MyCertStore() {
// whatever
// ;-) Don't ask me why this construct is necessary.
}
public MyC
Existing security/crypto APIs in JDK are all BYTE constrained. So, the
implementation will be "BYTE-only".
Are you suggesting to explicitly mention in the SHA-3 JEP that these
algorithm impl will be "BYTE-only"?
Valerie
On 4/21/2016 1:40 AM, e...@zusammenkunft.net wrote:
Hello,
Just notice
On 04/21/2016 04:51 AM, e...@zusammenkunft.net wrote:
Hello,
Two questions: the condition "starting on 2017-01-01" will this be
part of the general algorithm deprecation or the jdkCA qualifier.
I.e. if I add "SHA1" with no qualifier, will it be in effect
immediatelly?
We are going to add a fie
Hello, can answer the first question myself, the additional attribute deny
after is not documented in the JEP but in this task:
https://bugs.openjdk.java.net/browse/JDK-8153777
Gruss
Bernd
-Original Message-
From: e...@zusammenkunft.net
To: security-dev@openjdk.java.net
Sent: Do., 21 Ap
Security libs team,
Over on core-libs, the Class.newInstance method is up for deprecation
since it does not obey the general checked exceptions contract.
Please review the security-libs portion of
http://cr.openjdk.java.net/~darcy/6850612.0/
Generally a new variable was introduced to hos
> On Apr 21, 2016, at 9:44 PM, Xuelei Fan wrote:
>
>>> public MyCertStore extends CertStoreSpi {
>>>
>>> public MyCertStore() {
>>> // whatever
>>> // ;-) Don't ask me why this construct is necessary.
>>> }
>>>
>>> public MyCertStore(XXX params) {
>>> // throws NoSuchMe
Updated webrev looks fine to me.
--Sean
On 04/20/2016 11:18 AM, Xuelei Fan wrote:
Thanks for the comments, all looks reasonable to me.
Updated webrev: http://cr.openjdk.java.net/~xuelei/8144566/webrev.02/
Thanks,
Xuelei
On 4/20/2016 9:10 PM, Sean Mullan wrote:
* SSLSocketImpl.java
2100
On 4/21/2016 12:29 PM, Wang Weijun wrote:
>
>> On Apr 20, 2016, at 9:35 AM, Xuelei Fan wrote:
>>
>> On 4/20/2016 9:17 AM, Wang Weijun wrote:
>>>
On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote:
On 4/19/2016 11:41 PM, Wang Weijun wrote:
> http://cr.openjdk.java.net/~weijun/80
Looks fine to me.
On 4/21/2016 1:48 PM, Rajan Halade wrote:
> Thanks for your comments!
>
> Updated webrev: http://cr.openjdk.java.net/~rhalade/8129329/webrev.01/
>
> On 4/20/16 5:23 PM, Xuelei Fan wrote:
>> You made a few update of the coding style, for example line 60-62, which
>> is different
On 20 Apr 2016, at 20:34, Claes Redestad wrote:
>
>
> On 2016-04-20 20:51, Chris Hegarty wrote:
>> On 20 Apr 2016, at 15:44, Claes Redestad wrote:
>>
>>> Hello,
>>>
>>> now that the sun.security.action package is encapsulated we can simplify
>>> internal code to get System properties.
>>>
Hi All
Webrev updated again at
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec
http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff
Changes since webrev.10:
- DRBG's generateSeed() will directly read from securerandom.sour
Hello,
Two questions: the condition "starting on 2017-01-01" will this be part of the
general algorithm deprecation or the jdkCA qualifier. I.e. if I add "SHA1" with
no qualifier, will it be in effect immediatelly?
The exception for timestamped code, does it also consider the actual signature
Hello,
Just noticed, the validation program allows BIT- or BYTE-only APIs, the
existing ones are all BYTE constrained. That would be a good definition in the
JEP:
http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
Hello,
This is good news. Could the JEP talk about non-octet input length? If I read
SHA3 correctly it will produce different hashes for 5- or 8-bit input. This
means you cannot pad the input to byte boundaries and you would have to specify
a length parameter to byte[] based doFinal().
Since t
14 matches
Mail list logo
