No David is right, the code will run with the privileges of it's own
ProtectionDomain, so if that PD is not trusted, the code cannot bypass security
checks from static initializers. This does not break secure by default.
A static initializer can write to static fields, but public or protected s
BTW, if you feel like it in any backports, the casts to
SSLHandshakeException weren't needed.
Brad
On 8/1/2014 11:46 AM, Rob McKenna wrote:
Thanks Brad, patch updated, built & tested.
-Rob
On 01/08/14 01:39, Bradford Wetmore wrote:
Rob,
Looks ok to me too. There are probably other
Thanks Brad, patch updated, built & tested.
-Rob
On 01/08/14 01:39, Bradford Wetmore wrote:
Rob,
Looks ok to me too. There are probably other places with RTE's we
could fix, but this will solve the immediate problem.
Two comments to consider:
1. Use a Multi-catch exception. JDK7+.
I noticed that the implementation of DigestInputStream does not feed
skipped-over bytes to the message digest. The specification is silent
on this, and I'm not sure if this a specification deficiency or an
implementation bug.
--
Florian Weimer / Red Hat Product Security
On Aug 1, 2014, at 16:27, Xuelei Fan wrote:
> On 8/1/2014 12:53 PM, Wang Weijun wrote:
>>
>> On Jul 31, 2014, at 10:15, Xuelei Fan wrote:
>>
The server side now only enables TLS_RSA_WITH_AES_128_CBC_SHA256. If other
protocols are enabled,
>>
>> Oh, typo. I meant to ask: "If other
On 8/1/2014 12:53 PM, Wang Weijun wrote:
>
> On Jul 31, 2014, at 10:15, Xuelei Fan wrote:
>
>>> The server side now only enables TLS_RSA_WITH_AES_128_CBC_SHA256. If other
>>> protocols are enabled,
>
> Oh, typo. I meant to ask: "If other cipher suites are enabled, what will be
> the differenc
