t;>>>> netty with our custom SSLEngine implementation as there is no way to
>>>>> access this. Which means depending on if the user use our implementation
>>>>> or the default implementation the behaviour if quite different when using
>>>>>
t;>>>> netty with our custom SSLEngine implementation as there is no way to
>>>>> access this. Which means depending on if the user use our implementation
>>>>> or the default implementation the behaviour if quite different when using
>>>>>
Thanks, I'll proposed the CSR next.
--Max
> On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote:
>
> Look fine to me. Added myself to CSR as reviewer.
>
> Thanks,
>
> Valerie
>
>
> On 9/17/2018 1:17 AM, Weijun Wang wrote:
>> Please review the code change and CSR at
>>
>>http://cr.openjdk.j
Hi Xuelei,
This isn't a significant issue in our case (there isn't any functional
difference in what was being done in that specific catch block, in the
code where this happened). I was only just curious if this was an
intentional. The SSLProtocolException which is now being thrown, I think
is a b
Hi Jaikiran,
Normally, the thrown exception class can be an implementation choice,
and may be not reliable from version to version. We were trying to use
the same exception, but we may miss the use cases. I may suggest to
make the code independent from it. However, if the impact is
signifi
Just checking back on this one. Is this an expected change? Personally,
it's not a big issue in the code where this is happening for me. I'll
probably just change the catch block to a more generic IOException.
However, for any other code which relied on the previous SocketException
catch block, the
Hi Norman,
In general, it is risk to support unknown protocol version in the
key/trust manager implementation. The trust manager implemented for TLS
1.2 and prior versions might not work with TLS 1.3 probably. Did you
make the evaluation? Would you mind contribute a patch?
Please feel fre
Look fine to me. Added myself to CSR as reviewer.
Thanks,
Valerie
On 9/17/2018 1:17 AM, Weijun Wang wrote:
Please review the code change and CSR at
http://cr.openjdk.java.net/~weijun/8210821/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8210822
Thanks
Max
Thanks.. I updated the copyright..
Tony
On 08/29/2018 07:02 AM, Xuelei Fan wrote:
Looks fine to me. Please update the copyright years as well.
Thanks,
Xuelei
On 8/28/2018 9:47 PM, Anthony Scarpino wrote:
I need a review of this fix. Simple change to throw an
UnsupportedOperationException
Has the attached regression been fixed "Re:
-Djava.security.manager=problems for service provider"? I recently
changed all our code to use System.setSecurityManager(), because of this
regression, prior to that we used the command line option, it's going to
take some time to revert...
Securi
Hi Norman,
Thank you so much for the reproducing code. Would you mind file a bug
for this issue?
Thanks,
Xuelei
On 9/17/2018 3:39 AM, Norman Maurer wrote:
Hi all,
As requested I pushed a pure JDK reproducer to GitHub which you can
easily use to reproduce the problem. All the details how
Done..
ID: 9057278
Thanks
Norman
> On 17. Sep 2018, at 18:51, Xuelei Fan wrote:
>
> Hi Norman,
>
> Please file an issue for the tracking.
>
> Thanks,
> Xuelei
>
> On 9/17/2018 5:57 AM, Norman Maurer wrote:
>> Should I open an issue somewhere to keep track of it or will you take care
>> of
Hi Norman,
Please file an issue for the tracking.
Thanks,
Xuelei
On 9/17/2018 5:57 AM, Norman Maurer wrote:
Should I open an issue somewhere to keep track of it or will you take care of
it ?
Bye
Norman
On 11. Sep 2018, at 17:01, Norman Maurer wrote:
This sounds great.
I have no idea ho
On 9/12/18 2:25 PM, Hohensee, Paul wrote:
Thanks very much for investigating. We're aware that the cache size can be set
by the user, but many of our users haven't done so because it hasn't been
necessary, and boom.
Would you mind filing a bug and we will look into it?
Thanks,
Sean
Paul
On 9/16/18 12:48 AM, Alan Bateman wrote:
On 15/09/2018 22:00, Philip Race wrote:
It was exported in the past .. and it was publicly documented ..
http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
.. so I think Sergey was correct in his "JDK" scope.
Implementatio
I'm talking about sandboxing from the perspective of object capability
patterns, where you can contain some actor inside a constrained classloader
context and only allow execution through proxies that may be revoked. The
JEE model, in theory, allows you to run several web applications without
them
Just recently completed updating to X509ExtendedTrustManager, but not
comprehensively yet, as some code is still using X509TrustManager, but
will look into updating it too in the near future ...
Thanks,
Peter.
On 17/09/2018 10:57 PM, Norman Maurer wrote:
Should I open an issue somewhere
Should I open an issue somewhere to keep track of it or will you take care of
it ?
Bye
Norman
> On 11. Sep 2018, at 17:01, Norman Maurer wrote:
>
> This sounds great.
>
> I have no idea how many people still use X509TrustManager, sorry.
>
> It may be a good idea to add something to the jav
Has the attached regression been fixed "Re:
-Djava.security.manager=problems for service provider"? I recently
changed all our code to use System.setSecurityManager(), because of this
regression, prior to that we used the command line option, it's going to
take some time to revert...
Securi
Hi all,
In netty we support using OpenSSL for native SSL which recently added TLSv1.3
support as part of OpenSSL 1.1.1. In an ideal world we would be able to use
this even with Java8 which is almost true except the fact that
sun.security.ssl.ProtocolVersion.valueOf(…) will throw an
IllegalArgu
On Sun, Sep 16, 2018 at 2:38 PM Will Sargent wrote:
>
> > The security manager is legacy these days and I think we need to figure out
> > a plan how to deprecate and eventually bury it.
>
> I don't know of any research or papers that explicitly say that
> SecurityManager is "legacy". I did some
On 16/09/2018 20:37, Will Sargent wrote:
> The security manager is legacy these days and I think we need to
figure out a plan how to deprecate and eventually bury it.
I don't know of any research or papers that explicitly say that
SecurityManager is "legacy". I did some research into this a w
Please review the code change and CSR at
http://cr.openjdk.java.net/~weijun/8210821/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8210822
Thanks
Max
23 matches
Mail list logo
