Hi Max,
Could you please review this fix?
http://cr.openjdk.java.net/~juh/8007706/webrev.00/
With the fix, the rules will be:
1. A DNSName must begin with a letter or a digit
2. After the first character, valid characters in DNSName components are
letters, digits, hyphens, and underscores
A
On 07/22/2014 09:52 AM, Jason Uh wrote:
Hi Max,
Could you please review this fix?
http://cr.openjdk.java.net/~juh/8007706/webrev.00/
With the fix, the rules will be:
1. A DNSName must begin with a letter or a digit
2. After the first character, valid characters in DNSName components are
letter
Hi folks,
A simple change to use SSLHandshakeException instead of RuntimeException
in getAgreedSecret in DHCrypt and ECDHCrypt. This will prevent these
RuntimeExceptions from propagating to the application and allow
application programmers to handle them as SSLHandshakeExceptions.
http://cr.
Looks good.
--Sean
On 07/21/2014 06:33 PM, Valerie Peng wrote:
Done, webrev updated at
http://cr.openjdk.java.net/~valeriep/8035166/webrev.01/
Thanks,
Valerie
On 7/21/2014 11:18 AM, Sean Mullan wrote:
Can you also change the following comment in
sun/security/ssl/SupportedEllipticCurvesExtensi
Hi folks,
When repeatedly gathering small amounts of random data the SUN provider
is quicker ucrypto / pkcs11. This proposed fix from Brad allows ucrypto
/ pkcs11 leverage the SUN SHA1 provider for SHA1PRNG. This allows us to
avoid the overhead of calling into the native level repeatedly for s
This is a fix for a test that was on the problem list. The fix is
simple, I just changed the test to run in othervm mode, it was failing
due to a classloader issue running in agentvm mode. Was able to get a
clean jprt run on all systems.
http://cr.openjdk.java.net/~mullan/webrevs/7147060/webre
Looks fine to me.
--Sean
On 07/22/2014 01:44 PM, Rob McKenna wrote:
Hi folks,
When repeatedly gathering small amounts of random data the SUN provider
is quicker ucrypto / pkcs11. This proposed fix from Brad allows ucrypto
/ pkcs11 leverage the SUN SHA1 provider for SHA1PRNG. This allows us to
A recent fix was introduced to preserve the behaviour of an old buggy
implementation of smartcardio Card.disconnect :
https://bugs.openjdk.java.net/browse/JDK-8049250
The old behaviour is not fully restored with this flag if a security
manager lacking sufficient permissions is present. This cou
Well, I see your point.
However, I am a little concerned that the security check isn't being
performed in the old buggy impl.
Is there any customer running into this, e.g. rely on the old behavior
with security manager enabled?
Valerie
On 7/22/2014 2:45 PM, Seán Coffey wrote:
A recent fix was
Please review the code change at
http://cr.openjdk.java.net/~weijun/6997010/webrev.00/
The fix consolidates java.security- files into one with #ifdef
directives.
There are several major changes:
1. Creation of file is moved from CopyFiles to GenerateData, since we are
really generating so
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
11 matches
Mail list logo
