Hello,
While you are at that code, can the JavaDoc @code classnames be changed into
@link as well? (Not sure if it works for packages).
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: Sean Mullan
To: Vincent Ryan , OpenJDK
Sent: Fr., 17 Juni 2016 16:41
Subject:
Hello,
I would not mix performance and policy commits, but maybe those changes are
related to the same task?
What about Group.HmacSHA2:SunJCE is that needed as well? BTW the preferences
are only set for Solaris, why are there no preferences on the other platforms
shipped? (Or rather, why are t
Hello,
In AlgorithmChecker the Javadoc seems to not follow "@param name desc" format
(in two places). Also it should most likely describe something like "time the
signature claimed to be made to check time range limited ciphers after that
date or similiar)
* @param PKIXParameter timestamp (or
If you look at the builtin support it is only AES/CBC with the SunJCE (the
AES/GCM has still a long way to go).
With external/platform specific providers (ucrypto on Solaris, libnss via
PKCS11 and Windows Crypto API) you might get more hw support.
Gruss
Bernd
--
http://bernd.eckenfels.net
---
Hello Valerie,
Yes that is what I was trying to say. :) However I dont know if this is clear
to everybody else.
It confused me, since most of the example testcases in the linked standard are
BIT aligned, only the Validation subproject mentions the possibility of a byte
mode. But I guess if the
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
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
BTW, is there any SHA1 deprecation planned/expected for JNLP code signing?
--
http://bernd.eckenfels.net
-Original Message-
From: "Seán Coffey"
To: "security-dev@openjdk.java.net"
Sent: Mi., 27 Jan. 2016 17:40
Subject: RFR : 8038837:Add support to jarsigner for specifying timestamp has
Hello,
Wang Weijun :
>> On Jan 6, 2016, at 3:31 PM, e...@zusammenkunft.net wrote:
>> is the Intention of the default implementation of getFullEntropy to expand a
>> too short array with the DF as well (which is a dangerous thing to do IMHO)
>> or is the conditional conditioning only to condense
Hello,
is the Intention of the default implementation of getFullEntropy to expand a
too short array with the DF as well (which is a dangerous thing to do IMHO) or
is the conditional conditioning only to condense (aka shorten)? In that case
you should maybe add an assert and make the if compare
Isnt this codepath used as a workaround for dynamically disabling SNI? Using
connect(host..) instead of SSLSocket(host) was at least a common, well known
workaround.
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: Bradford Wetmore
To: Xuelei Fan , OpenJDK
Sent: Di.
Hello,
That buffer sizing/expiring is a bit strange (the dynmic version stranger than
the old one), I do not understand the need for it. The requests should not
varry so much in size. Just reading something like 64bytes at a time (possibly
nonblocking) should be fine. No need to look at the age
Hello Omair,
I brought this up before, and agree with you that it is a good idea: if the
server sends the alert and treats it fatal there is no problem in at least
trying to continue. It is also not a security problem because the certificate
will be validated (and if it is indeed the wrong serv
It is obvious, but I thought I might mention it: it does absolutely not help
the user if a server refuses to negotiate a "MAY not use" cipher only to
fallback to http/1.1 with exactly that cipher. I can see the motivation for
deprecating those ciphers in modern servers (although I am note sure w
Hello,
Just want to mention that with explicite http/https URLs users and applications
are somewhat used to select the application protocol first. In fact if I have a
H2 client I would expect it to try H2 first (especially given the fact that no
weak ciphers could be negotiated anyway). So basi
17 matches
Mail list logo
