Dear Java-SE security developers,
Imagine a following code:
```
Subject s1 = ... ;
Subject s2 = ... ;
s2.getPrincipals().addAll(s1.getPrincipals());
```
The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
values
by calling collectionNullClean, which calls Se
Hi Sean , I opened
https://bugs.openjdk.java.net/browse/JDK-8243543
JDK-8243543 : jtreg test
security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java
fails
Best regards, Matthias
>> Hello,?? the test
>> 'security/infra/java/security/cert/CertPathValidator/certific
Hi Tigran,
In java.util.Set, we have:
* @throws NullPointerException if the specified element is null and this
* set does not permit null elements
* (optional)
*/
boolean contains(Object o);
As an implementation, SecureSet must follow the spec to throw an NPE. If
Hi Max,
that's right, but java doc as well mentions that this exception is *optional*,
and has a corresponding note:
Some collection implementations have restrictions on the elements that they may
contain. For example, some implementations prohibit null elements, and some
have restrictions on
My understanding is by optional you have 2 options while designing the Set:
1. Allow null
2. Not allow null
Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
permit null elements" category and therefore it should "@throws
NullPointerException if the specified eleme
I read it differently:
Attempting to query the presence of an ineligible element may throw an
exception, or it may simply return false; some implementations
will exhibit the former behavior and some will exhibit the latter.
Implementation might thrown an exception or return false, but s
Hello,
I would agree with the interpretation that the NPE is not mandatory.
But even if we keep it, the actual problem in addAll() should be fixed? There
is no point in calling contains(null) on a SecureSet, right?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von:
Here is the benchmark results:
Benchmark Mode CntScore Error Units
SubjectBenchmark.jdkSubject thrpt 20 473086.025 ± 7661.215 ops/s
SubjectBenchmark.patchedSubject thrpt 20 2529016.530 ± 50982.465 ops/s
On a one hand, patched version has 5
Hi Tigran,
I read "Collection.html#optional-restrictions" carefully, and yes you're
correct. Sorry for my ignorance.
This method is called quite a lot. It might be worth an enhancement.
Thanks,
Max
> On Apr 24, 2020, at 9:00 PM, Mkrtchyan, Tigran
> wrote:
>
>
>
> Here is the benchmark res
Hi Max,
Do you want me to go though official contribution (I already have signed OCA
for glassfish) or
someone from oracle team will take care about it?
Thanks,
Tigran.
- Original Message -
> From: "Weijun Wang"
> To: "Tigran Mkrtchyan"
> Cc: "security-dev"
> Sent: Friday, April 24
You can send me a patch and I can sponsor it.
Thanks,
Max
> On Apr 24, 2020, at 9:54 PM, Mkrtchyan, Tigran
> wrote:
>
> Hi Max,
>
> Do you want me to go though official contribution (I already have signed OCA
> for glassfish) or
> someone from oracle team will take care about it?
>
> Thanks
Hi,
DHE_DSS cipher suites cannot work with SHA256withDSA (key size 2048)
certificates over pre-TLSv1.2 protocols.
Please see JDK-8242928 for more details.
This fix takes the test to use a SHA1withDSA certificate (key size 1024)
for TLSv1 and TLSv1.1.
Webrev: http://cr.openjdk.java.net/~jjian
Looks fine to me.
Thanks,
Xuelei
On 4/24/2020 8:42 AM, sha.ji...@oracle.com wrote:
Hi,
DHE_DSS cipher suites cannot work with SHA256withDSA (key size 2048)
certificates over pre-TLSv1.2 protocols.
Please see JDK-8242928 for more details.
This fix takes the test to use a SHA1withDSA certifica
To correct an oversight to include security-dev in the reviews...
Several security tests were modified to use the HexPrinter instead of
HexDumpEncoder.
Please review[2] and comment on a new Hex printing utility to support
OpenJDK tests.
The usefulness of a hex printing has been discussed fro
On 4/23/20 1:14 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8236464/webrev.00/
In the current implementation, the sending of close_notify may not
respect the SO_LINGER setting in some circumstances. With this update,
the deliverin
The patch is attached.
Thanks,
Tigran.
- Original Message -
> From: "Weijun Wang"
> To: "Tigran Mkrtchyan"
> Cc: "security-dev"
> Sent: Friday, April 24, 2020 4:21:27 PM
> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
> You can send me a patch and I can
Hi Tony,
Thanks for the review. I will update the typo before commit.
Xuelei
On 4/24/2020 10:08 AM, Anthony Scarpino wrote:
On 4/23/20 1:14 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8236464/webrev.00/
In the current implementat
Everything in the security tests looks fine to me.
Thanks,
Max
> On Apr 25, 2020, at 1:03 AM, Roger Riggs wrote:
>
> To correct an oversight to include security-dev in the reviews...
> Several security tests were modified to use the HexPrinter instead of
> HexDumpEncoder.
>
>
> Please review
18 matches
Mail list logo
