On Mon, 21 Dec 2020 23:58:03 GMT, Xue-Lei Andrew Fan wrote:
> Comparing to Collection.toArray(new T[size)), he Collection.toArray(new T[0])
> seems faster, safer and contractually cleaner. In the update, the use of
> Collection.toArray(new T[size)) in the SunJSSE provider implementation is
>
ific problem and the existing API is still
available for the common case.
On 8 Dec 2016, at 23:13, David M. Lloyd wrote:
On 12/08/2016 04:18 PM, Vincent Ryan wrote:
The Java Servlet Expect Group reported that they have identified a
specific HTTP2 server use-case that cannot
be easily addres
On 12/08/2016 04:18 PM, Vincent Ryan wrote:
The Java Servlet Expect Group reported that they have identified a specific
HTTP2 server use-case that cannot
be easily addressed using the existing ALPN APIs.
This changeset fixes that problem. It supports a new callback mechanism to
allow TLS serve
I haven't run into this personally, but I may soon, so I have a
question: did anyone try simply lying about the destination port (which
is easy with SSLEngine, but might only be possible for SSLSocket if you
do something funny with socket factorys - or maybe not at all)?
On 12/06/2016 11:56 AM
This will not work because System.nanoTime() can be negative and wrap
around. You can't compare one nanoTime to another, only differences are
useful.
On 06/15/2016 05:30 PM, Bradford Wetmore wrote:
Looks good, Max, thanks for taking this over.
Xuelei, it's a threaded accumulator, which feeds
On 06/15/2016 07:36 AM, Simone Bordet wrote:
Hi,
On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd wrote:
The problem is that this is quite subjective. In my opinion the current
solution is both clean and precise:
1) Read the hello packet
2) Examine the protocols, host names, and cipher
On 06/14/2016 09:28 PM, Greg Wilkins wrote:
On 15 June 2016 at 11:40, Jason T. Greene mailto:jason.gre...@redhat.com>> wrote:
> On Jun 14, 2016, at 7:04 PM, Greg Wilkins mailto:gr...@webtide.com>> wrote:
>
> If SslEngine is changed to allow the negotiated application protocol to
On 06/15/2016 03:35 AM, Simone Bordet wrote:
Hi,
On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley wrote:
The problem I have with reading posts about JDK9 problems is that I
can't tell the *severity* of the problems. I don't know if something
is a total blocker or an inconvenience. When someone
On 06/14/2016 09:47 AM, Simone Bordet wrote:
Hi,
On Tue, Jun 14, 2016 at 4:31 PM, David M. Lloyd wrote:
During the unwrap(), the JDK implementation picks a cipher based on
the JDK logic.
In particular, in my case, I had a keystore with a certificate that
was *not* ECDSA.
Could you not use
I have a few questions, inline.
On 06/14/2016 08:57 AM, Simone Bordet wrote:
Hi,
I gave a shot at implementing ALPN in JDK 9 in Jetty.
TLDR: I could not find a way to make it work. This email is to discuss
whether I am off road or discuss possible solutions.
Below my feedback.
* Lack of faci
On 01/13/2016 07:44 AM, Wang Weijun wrote:
Hi David
On Jan 13, 2016, at 8:08 PM, David M. Lloyd wrote:
On 01/12/2016 07:02 PM, Wang Weijun wrote:
A new webrev at
http://cr.openjdk.java.net/~weijun/8058778/webrev.09/
A couple of questions/comments...
+public interface Builder
On 01/12/2016 07:02 PM, Wang Weijun wrote:
A new webrev at
http://cr.openjdk.java.net/~weijun/8058778/webrev.09/
A couple of questions/comments...
+public interface Builder
+> {
What is the point of the "T" self-type variable? It does not seem to be
referenced. Also the
I didn't reply on this last week, but this looks workable to me. Thanks!
On 10/02/2015 07:19 PM, Bradford Wetmore wrote:
On 10/1/2015 7:35 PM, Xuelei Fan wrote:
On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
Major changes:
1. ApplicationProtocols is gone. The H2 black list and comparator
Hi Brad, thanks for replying; comments are inline:
On 09/28/2015 08:40 PM, Bradford Wetmore wrote:
Several comments about David's proposal:
1. Only the initial ClientHellos are parsable.
===
The biggest problem I have with an Explorer-based design i
On 09/25/2015 02:11 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote:
The application protocol implementation chooses only valid cipher suites for
the protocol. Why would it choose one that is not valid, considering that
the protocol implementation itself is
very low
risk to either the JDK/SE timeline or the EE timeline
* Since most or all of the "hard" logic is on the server side, the
majority of API consumers will have an easy time using the API
* We server developers can handle the rest!
On 09/25/2015 12:23 PM, David M. Lloyd wrote:
On
On 09/25/2015 12:13 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote:
A: receive raw SSL packet on Socket or SocketChannel
A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
This requires the application to write a TLS parser. This is
On 09/25/2015 11:37 AM, Simone Bordet wrote:
David,
sorry, but I don't understand your proposal.
Can you please write it down in pseudo code what a server application
should do and what the JDK should do to negotiate HTTP/2 with a client
?
Sure.
A: receive raw SSL packet on Socket or SocketC
On 09/25/2015 10:13 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd wrote:
Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine
to specify the selected protocol; this would be done during setup before you
initiate handshake (which is why you
On 09/25/2015 07:29 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 2:15 PM, David M. Lloyd wrote:
...why does sorting even matter? Why should selection not be implemented
100% in user code, based on both the cipher suites list and application
protocol, rendering this whole discussion
On 09/25/2015 06:42 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote:
Here is the question to answer, which preference should be respected
firstly between cipher suite and application protocol? If application
protocol are preferred at first, of course, applicati
Sorry I didn't get the reply from Simone Bordet - it must have gone to
only one of the two lists (which I'm not on).
On 9/25/2015 9:14 PM, Simone Bordet wrote:
I don't follow ?
SNI has APIs in JDK 8, you don't use SSLExplorer at all.
They're highly limited; you can only tell the socket/engine
It has caused some consternation among certain of our engineers that
there is a new possible status code in SSLEngineResult.HandshakeStatus.
If a new status were generally added, it would cause subtle or not so
subtle breakage amount current SSLEngine consumers.
I request that it be made more
On 06/29/2015 04:32 AM, Andrew Haley wrote:
On 29/06/15 09:37, Vladimir Kozlov wrote:
Hi, Andrew
Did you file RFE for this change? 8046943 is JEP.
No; I will do so.
typo? "less" -> "more".
+ * number of ints in the number is less than this value we do not
+ * use the intrinsic.
+
On 04/13/2015 09:58 AM, Thomas Lußnig wrote:
On 10.04.2015 00:36, mark.reinh...@oracle.com wrote:
New JEP Candidate: http://openjdk.java.net/jeps/244
- Mark
Hi,
would it not be an great idea to combine all these new extensions to an
generic way how to handle the SSL Protocol Handshake ?
Do
Another area of applicability is inner authentication mechanisms which
make use of channel binding; these mechanisms need to actually acquire
chunks of data from the handshake exchange.
http://tools.ietf.org/html/rfc5929 for more info
On 11/10/2014 03:36 PM, Bernd Eckenfels wrote:
Hello,
the
On 11/10/2014 07:28 AM, Simone Bordet wrote:
Hi,
On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer wrote:
On 11/07/2014 02:06 PM, Simone Bordet wrote:
This email is about the idea to introduce in JDK 9 a fully fledged TLS
Extensions API.
Adding ALPN [0] support to JDK 9 requires, differently
On 10/30/2014 11:49 AM, mark.reinh...@oracle.com wrote:
New JEP Candidate: http://openjdk.java.net/jeps/219
Awesome!
--
- DML
On 10/29/2014 08:35 AM, Michael Maass wrote:
Hello All,
I've spent the last 6 months working with some colleagues on a project
that aimed to stop an exploitation avenue that has been popular with
recent Java exploits: disabling the security manager. We think that what
ended up with may be worthy
On 10/03/2014 10:15 PM, Alan Bateman wrote:
On 03/10/2014 08:13, David M. Lloyd wrote:
:
Why the problem occurs
--
The root of the problem traces back to
SecurityManager.checkMemberAccess(). This method is the one remaining
method in all of SecurityManager which uses the
This discussion fizzled out last time it happened (2011 or something?).
So to avoid that happening again, I'm going to (hopefully clearly and
in simple unambiguous terms) explain what the problem is, why it should
be fixed, why the problem occurs, and exactly what should be done to fix
the pro
On 07/28/2014 03:33 PM, Peter Levart wrote:
On 07/28/2014 03:34 PM, David M. Lloyd wrote:
On 07/24/2014 04:17 AM, Tom Hawtin wrote:
On 23/07/2014 14:40, David M. Lloyd wrote:
On 07/23/2014 07:07 AM, Tom Hawtin wrote:
On 23/07/2014 05:26, David M. Lloyd wrote:
• Always have static
On 07/24/2014 04:17 AM, Tom Hawtin wrote:
On 23/07/2014 14:40, David M. Lloyd wrote:
On 07/23/2014 07:07 AM, Tom Hawtin wrote:
On 23/07/2014 05:26, David M. Lloyd wrote:
• Always have static initialization blocks be privileged (this does
require users to be cognizant of this fact when
On 07/23/2014 07:07 AM, Tom Hawtin wrote:
On 23/07/2014 05:26, David M. Lloyd wrote:
I would suggest that one or more of the following be done to mitigate
this problem:
• Always have static initialization blocks be privileged (this does
require users to be cognizant of this fact when writing
On 04/25/2014 09:36 AM, Sean Mullan wrote:
Please review a draft of a proposed research JEP to improve the
performance of the Security Manager:
I have another idea that might be worth looking into. One problem with
security manager performance is that many times a class will perform
privileg
On 04/25/2014 09:36 AM, Sean Mullan wrote:
Please review a draft of a proposed research JEP to improve the
performance of the Security Manager:
http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00
I am particularly interested in any experience you have measuring or
Maybe you already know this, but this past April, Sean Mullan (from
Oracle) posted a "JEP Review Request" [1] for a blanket initiative to
improve security manager performance.
This kind of thing sounds like exactly the sort of thing that would fit
in under that initiative, IMO.
[1]
http://m
On 06/16/2014 09:19 AM, Frank Ding wrote:
Hi Jeff,
Thanks for your reply. One further question is that you confirmed
that two AccessControlContext objects considered equal via method
equals() should return same results for
AccessControlContext.checkPermission() but test shows that 2
AccessCon
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 implementati
On 04/25/2014 02:35 PM, Sean Mullan wrote:
On 04/25/2014 10:54 AM, David M. Lloyd wrote:
On 04/25/2014 09:36 AM, Sean Mullan wrote:
Please review a draft of a proposed research JEP to improve the
performance of the Security Manager:
http://cr.openjdk.java.net/~mullan/jeps/Improve-Security
On 04/25/2014 09:36 AM, Sean Mullan wrote:
Please review a draft of a proposed research JEP to improve the
performance of the Security Manager:
http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00
I am particularly interested in any experience you have measuring or
pr
41 matches
Mail list logo
