I agree with Adam that this is more of a tuning issue and not a problem
with the crypto. Sending multiple updates is a hack.
I've been aware of this bug for a while and I do not understand why this
is a significant problem. The stackoverflow comments say it takes 50
seconds to trigger the in
> On Nov 15, 2018, at 3:53 AM, Adam Petcher wrote:
>
> This looks good to me, though I made a couple of trivial editorial changes.
> It's fine as is, but you may want to consider using secp384r1 instead of
> brainpool256r1 in your example. I worry that people will experiment with the
> new
Thanks to Xuelei and Sean. I added your recommended words and proposed the CSR.
> On Nov 15, 2018, at 6:16 AM, Sean Mullan wrote:
>
> On 11/14/18 5:07 AM, Weijun Wang wrote:
>> The CSR is re-opened. It is now focusing on -keyalg only. Please take a
>> review:
>>https://bugs.openjdk.java.net
Hello,
For future CSR requests involving system properties, please document the
properties using these javadoc facilities.
Thanks,
-Joe
On 11/14/2018 2:27 PM, Jonathan Gibbons wrote:
This is an FYI to announce some initial, long-overdue support in
javadoc for documenting system properties (
This is an FYI to announce some initial, long-overdue support in javadoc
for documenting system properties (JDK-5076751).
Currently, system properties are just documented using ad-hoc narrative
text, which is fine if you know where to look for any given property.
JDK 12 introduces a new inlin
On 11/14/18 5:07 AM, Weijun Wang wrote:
The CSR is re-opened. It is now focusing on -keyalg only. Please take a review:
https://bugs.openjdk.java.net/browse/JDK-8212111
I think the CSR should also include an example of the informational text
showing what algs and size were used. Looks goo
For 12, I think we should also document the group names in the std. alg
names document so we have somewhere to point to for what names can be
specified, otherwise users will be guessing.
So I targeted this to 12: https://bugs.openjdk.java.net/browse/JDK-8210755
--Sean
On 11/11/18 8:08 PM, Wei
The fix and the CSR look good. Please also add a release note.
--Sean
On 11/8/18 11:51 AM, Adam Petcher wrote:
Oops. And the JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8213363
On 11/8/2018 11:43 AM, Adam Petcher wrote:
webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/
Thanks for the comments Weijun.
As per other review thread, I'm now recording all properties set via
Security.setProperty(String, String).
regards,
Sean.
On 14/11/2018 01:11, Weijun Wang wrote:
Confused. Aren't all Security properties security-related? This is not about
normal system prope
Hi Sean,
comments inline..
On 13/11/2018 18:53, Sean Mullan wrote:
Looking good, a couple of comments/questions:
* src/java.base/share/classes/java/security/Security.java
The isJdkSecurityProperty method could return false positives, for
example there may be a non-JDK property starting with
This looks good to me, though I made a couple of trivial editorial
changes. It's fine as is, but you may want to consider using secp384r1
instead of brainpool256r1 in your example. I worry that people will
experiment with the new feature using your example, and then we'll get
bug tickets becaus
On 11/14/2018 9:16 AM, Jamil Nimeh wrote:
Hi Xuelei,
The fix looks fine to me. I think it would be good to have an else
branch off of the check on line 205 so any < 0 value has a warning log
entry stating that an invalid value was detected and the cache is
getting set to DEFAULT_MAX_CACHE_SI
CCing to core-libs and security.
Based on last comment corresponding java code may need to be re-factored. It is
not simple.
To trigger x64 AES instructions usage early (before JIT compilation kicks in) we may consider call optimized code from
Interpreter similar to CRC32 code. It is also very
Hi Xuelei,
The fix looks fine to me. I think it would be good to have an else
branch off of the check on line 205 so any < 0 value has a warning log
entry stating that an invalid value was detected and the cache is
getting set to DEFAULT_MAX_CACHE_SIZE.
--Jamil
On 11/14/2018 8:59 AM, Xuele
Hi,
Please review this simple update:
http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/
The default value for the maximum number of entries in the SSL session
cache (SSLSessionContext.getSessionCacheSize()) is infinite now. In the
request, the default value is updated to 20480 for per
I'm adding back in hotspot-dev, because this is a somewhat tricky topic
related to intrinsics and JIT. Hopefully, a Hotspot expert can correct
anything that I say below that is wrong, and suggest any solutions that
I missed.
The AES acceleration is implemented in a HotSpot intrinsic. In order
Looks fine to me.
Thanks,
Xuelei
On 11/14/2018 2:21 AM, Sibabrata Sahoo wrote:
Hi Xuelei,
Please review a minor fix for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8211787
Webrev: http://cr.openjdk.java.net/~ssahoo/8211787/webrev.00/
The original intention to “setSoTimeout()” is on serve
I may want to have the warning message with more explicit guide to
cleanup the warning. For example:
Warning: No -keyalg option. The default key algorithm ...
Otherwise, looks fine to me.
I added myself as the reviewer.
Thanks,
Xuelei
On 11/14/2018 2:07 AM, Weijun Wang wrote:
The CSR i
Dropping hotspot-dev and adding security-dev.
On Wed, 2018-11-14 at 14:39 +0200, Gidon Gershinsky wrote:
> Hi,
>
> We are working on an encryption mechanism at the Apache Parquet -
> that will enable efficient analytics on encrypted data by frameworks
> such as Apache Spark.
> https://github.co
On 11/13/18 1:53 PM, Sean Mullan wrote:
* src/java.base/share/classes/sun/security/x509/X509CertImpl.java
158 // Event recording cache list
159 private List recordedCerts;
Shouldn't this be static? Otherwise each certificate would have it's own
instance and duplicates would not be
On 11/13/18 8:11 PM, Weijun Wang wrote:
Confused. Aren't all Security properties security-related? This is not about
normal system properties.
Although probably not that common, an application could create their own
security properties, ex: Security.setProperty("security.myPassword",
"abc123
Hi Xuelei,
Please review a minor fix for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8211787
Webrev: http://cr.openjdk.java.net/~ssahoo/8211787/webrev.00/
The original intention to "setSoTimeout()" is on serverSocket where the server
will fail with timeout if it exceed certain amount
The CSR is re-opened. It is now focusing on -keyalg only. Please take a review:
https://bugs.openjdk.java.net/browse/JDK-8212111
Thanks
Max
> On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote:
>
> Oops, I take this back. The CSR needs more update.
>
> Sorry if you have already start reading i
23 matches
Mail list logo
