Re: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

[Sergey Bylokhov]

Hi, Sean.
One question related to SecurityManager and performance, is it possible 
to provide a special version of AccessController.doPrivileged which will 
be noop if SecurityManager is not present?


On 03/10/2018 13:12, Sean Mullan wrote:
For those of you that are not also subscribed to security-dev, this is 
mostly FYI, as the review is winding down, but if you have any comments, 
let me know.


This change will add new token options ("allow" and "disallow") to the 
java.security.manager system property. The "disallow" option is intended 
to provide a potential performance boost for applications that don't 
enable a SecurityManager, as there is a cost associated with allowing a 
SecurityManager to enabled at runtime, even if it is never enabled. The 
CSR provides a good summary of the issue and spec changes: 
https://bugs.openjdk.java.net/browse/JDK-8203316


Thanks,
Sean

 Forwarded Message 
Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's 
security manager immutable

Date: Tue, 2 Oct 2018 11:34:09 -0400
From: Sean Mullan 
Organization: Oracle Corporation
To: security Dev OpenJDK 

Hello,

Thanks for all the comments so far, and the interesting discussions 
about the future of the SecurityManager. We will definitely return to 
those discussions in the near future, but for now I have a second webrev 
ready for review for this enhancement:


http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/

The main changes since the initial revision are:

1. System.setSecurityManager is no longer deprecated. This type of 
change clearly needs more discussion and is not an essential part of 
this RFE.


2. After further thought, I took Bernd's suggestion [1] and instead of 
adding a new property to disallow the setting of a SecurityManager at 
runtime, have added new tokens to the existing "java.security.manager" 
system property, named "=disallow", and "=allow" to toggle this 
behavior. The "=" is to avoid any potential clashes with custom SM 
classes with those names. I think this is a cleaner approach. There are 
a couple of new paragraphs in the SecurityManager class description 
describing the "java.security.manager" property and how the new tokens 
work.


3. I also added a comment that Bernd had requested [2] on why 
System.setSecurityManager calls checkPackageAccess("java.lang").


Also, the CSR has been updated: 
https://bugs.openjdk.java.net/browse/JDK-8203316


Thanks,
Sean

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html 

[2] 
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html 



On 9/13/18 4:02 PM, Sean Mullan wrote:
This is a SecurityManager related change which warrants some 
additional details for its motivation.


The current System.setSecurityManager() API allows a SecurityManager 
to be set at run-time. However, because of this mutability, it incurs 
a performance overhead even for applications that never call it and do 
not enable a SecurityManager dynamically, which is probably the 
majority of applications.


For example, there are lots of "SecurityManager sm = 
System.getSecurityManager(); if (sm != null) ..." checks in the JDK. 
If it was known that a SecurityManager could never be set at run-time, 
these checks could be optimized using constant-folding.


There are essentially two main parts to this change:

1. Deprecation of System.securityManager()

Going forward, we want to discourage applications from calling 
System.setSecurityManager(). Instead they should enable a 
SecurityManager using the java.security.manager system property on the 
command-line.


2. A new JDK-specific system property to disallow the setting of the 
security manager at run-time: jdk.allowSecurityManager


If set to false, it allows the run-time to optimize the code and 
improve performance when it is known that an application will never 
run with a SecurityManager. To support this behavior, the 
System.setSecurityManager() API has been updated such that it can 
throw an UnsupportedOperationException if it does not allow a security 
manager to be set dynamically.


webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8203316
JBS: https://bugs.openjdk.java.net/browse/JDK-8191053

(I will likely also send this to core-libs for additional review later)

--Sean



--
Best regards, Sergey.

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

[Stuart Marks]

Hi Sean,

The new arrangement of using special tokens for java.security.manager makes a 
lot more sense than having a separate property. Overall, the proposed semantics 
seem reasonable to me.



I have some suggestions to clarify the proposed specification. (But also see 
below.) From webrev.01:


  81  * Environments using a security manager will typically set the security
  82  * manager at startup. In the JDK implementation, this is done by setting
  83  * the system property "{@code java.security.manager}" on the command line 
to
  84  * the class name of the security manager, or to the empty String ("")
  85  * or "{@code default}" to utilize the default security manager.
  86  * If the "{@code java.security.manager}" system property is not set, the
  87  * default value is {@code null}, which means a security manager will not 
be
  88  * installed at startup.

I'd suggest using the term "special token" to describe the string "default" 
here, to make it clear that this string is interpreted specially and is not 
interpreted as a security manager class name. (The FilePermission docs use the 
term "special token" to describe "<>".)


Similarly, I'd suggest "special token" be used to describe "allow" and 
"disallow" below.


  93  * In the JDK implementation, if the Java virtual machine is started with
  94  * the "{@code java.security.manager}" system property set to
  95  * "{@code =disallow}" then the
  96  * {@link System#setSecurityManager(SecurityManager) setSecurityManager}
  97  * method cannot be used to set a security manager and will throw an
  98  * {@code UnsupportedOperationException}. The ability to dynamically set 
the

(I assume this will be changed from "=disallow" to "disallow" and similar for 
"allow" below.)


This should clarify that if "disallow" is used then no security manager will be 
installed, in addition to preventing one from being installed in the future.


  98  *The ability to dynamically set 
the
  99  * security manager in a running system is an impediment to some 
performance
 100  * optimizations, even if the method is never called.

While I think this is true, it's a bit of rationale stuck into the middle of the 
specification for the values of the system property, and as such it sticks out. 
It kind of begs for more explanation. I'd suggest removing it.


 100  * If a security manager is
 101  * set at startup, or if the property is set to "{@code =allow}", then a
 102  * security manager can be set dynamically.

I'd split this into two (or multiple) sentences, because there's actually a lot 
going on here.


If the property is set to the special token "allow", no security manager is 
installed at startup, but one can be set dynamically using the 
setSecurityManager method. (Right?)


I think there are more cases that need to be covered than just "allow". If the 
property is set to "allow", the class name of a security manager, the empty 
string "", or the special token "default", then the setSecurityManager() method 
can be used to attempt to set the security manager dynamically. However, an 
already-installed security manager may refuse this request. (Right?)


**

Whew, this is kind of a lot. The reason is that there are several different 
values that the property can be set to, and they have an effect on the initial 
SM that's set AND an effect on the behavior of calls to setSecurityManager() at 
runtime. To get this straight, I wrote down a table:



Prop Value  SM installed initially  setSecurityManager() works
--
nullnoneyes
empty stringjava.lang.SecurityManager   maybe
"default"   java.lang.SecurityManager   maybe
"disallow"  noneno
"allow" noneyes
a class namethe named class maybe


Note: "maybe" means that setSecurityManager() will attempt to set the SM, in 
that it won't throw UOE; however, the current SM might disallow it depending 
upon its policies and the privilege of the caller.


From this table one can see that setting the property to the empty string and 
to "default" have identical effects. Also, not setting the property (i.e., its 
value is null) and setting it to "allow" have the same effects. Did I get this 
right?


Anyway, you can describe all of this in prose, but it has to be worded very 
carefully in order to get all the details right. Or, you could put a table 
directly into the spec. Or both! Up to you how you want to proceed.


**

An aside, possibly off topic. If the j.s.m property names a class that's to be 
used as the security manager, presumably it must be a j.l.SecurityManager or a 
subclass. Are there other requirements, such as having a public no-arg 
constructor? Does the class need 

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

[Nico Williams]

On Wed, Oct 03, 2018 at 03:13:55PM -0700, Valerie Peng wrote:
> Thanks for submitting the patches, Max is off on Chinese holidays
> til 7th and I am going to be on vacation til 19th.
> 
> I suppose no bugs have been filed for these issues? Max and I will
> take a look upon our return.

Great!  And I saw Weijun's reply as well.  Thanks!

Enjoy your vacation,

Nico
-- 

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

[Wang Weijun]

Yes, I am on vacation now. 

When I’m back, I’ll post your changes to cr.openjdk.java.net first.

Thanks
Max

> 在 2018年10月4日，06:13，Valerie Peng  写道：
> 
> Hi Nico,
> 
> Thanks for submitting the patches, Max is off on Chinese holidays til 7th and 
> I am going to be on vacation til 19th.
> 
> I suppose no bugs have been filed for these issues? Max and I will take a 
> look upon our return.
> 
> Regards,
> 
> Valerie
> 
> 
>> On 10/3/2018 2:30 PM, Nico Williams wrote:
>>> On Wed, Oct 03, 2018 at 08:49:28PM +, Nico Williams wrote:
>>> I'll attempt to attach all 25 commits now.  I hope the list will accept
>>> them.  I will post them (and webrev) to cr.openjdk.java.net.
>> And... I forgot to attach them.  Let's try again.
> 

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

[Valerie Peng]

Hi Nico,

Thanks for submitting the patches, Max is off on Chinese holidays til 
7th and I am going to be on vacation til 19th.


I suppose no bugs have been filed for these issues? Max and I will take 
a look upon our return.


Regards,

Valerie


On 10/3/2018 2:30 PM, Nico Williams wrote:

On Wed, Oct 03, 2018 at 08:49:28PM +, Nico Williams wrote:

I'll attempt to attach all 25 commits now.  I hope the list will accept
them.  I will post them (and webrev) to cr.openjdk.java.net.

And... I forgot to attach them.  Let's try again.

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

[Nico Williams]

On Wed, Oct 03, 2018 at 07:54:15AM +0100, Alan Bateman wrote:
> The "How to contribute" [1] is the best place to start. I see you
> are listed on the OCA signatories so that gets you through step 0.

Indeed.  Figuring out how to deal with the OCA is a large reason we took
so long to begin this contribution, as our legal department had some
objections for some time which were eventually resolved by having our
open source entity sign the OCA and our contributions done under that
entity.

> For the patches then I think you'll need to start a discussion here
> on the specific issues and changes that are you looking to
> contribute. This project requires all contributions to be sent on

Yes, I'm hoping that my post begins that discussion.

> the mailing list or hosted on locations such as cr.openjdk.java.net.

I'll attempt to attach all 25 commits now.  I hope the list will accept
them.  I will post them (and webrev) to cr.openjdk.java.net.

> From your mail then it sounds like you have a lot of changes so it's
> probably best to start small, say with small fixes, until you've
> gain some experience with the process of contributing and

Our changes are broken up reasonably well -- they are not squashed into
one big commit.  Thus it is already possible to review small ones first.

A lot of these changes are interrelated.  Reviewing them in order of
size might require rebasing our stack of commits, and may not be
entirely possible.

We're extremely familiar with this code as we have been patching the
JGSS stack this way for years (we have developed these patches for JDKs
7, 8, 9, 10, 11, and the current 12 master), and we have been running
this in production (with JDKs 7, 8, and 9, and soon 11) on Linux and
Windows (our patches for earlier versions add native GSS support on
Windows much as Weijun did for JDK 11, which we then use with the SAP
GSS->SSPI bridge, our fork of which is here:
https://github.com/twosigma/gsskrb5).

FWIW, regarding credentials, Viktor and I are part of the Heimdal team,
and we contribute to MIT Kerberos, and I have authored Internet RFCs in
the GSS-API space, thus we're extremely familiar with the GSS-API in
general and several implementation in particular.  Also, I am familiar
with the JGSS team as I used to work in Solaris security engineering
2002-2008 (and continued in Solaris engineering, just not security, for
another two years), and I know the engineers working on JGSS well enough
from back then (e.g., Weijun Wang, Valerie Peng), and I've stayed in
touch with Weijun Wang since leaving Oracle.  We're also maintainers or
contributors to a number of GSS-API applications, including the SSHv2
GSS keyex implementation in PuTTY, similar patches for OpenSSH, and so
on.  Lastly, Viktor is a member of the OpenSSL core team, contributed
DANE support, and is a co-maintainer of Postfix among other things.

> sponsors/reviewers build up confidence in the changes. I suspect you

We're hoping Weijun or Valerie can sponsor this.

> will have the experience of doing significantly better than showing
> up with large patch that add features and changes large areas of
> JGSS. Starting small is really important for sponsors and reviewers
> as the review and testing effort for many contributions can be
> significant.

There was no way to avoid showing up with a large set of patches.  The
problems we're fixing run deep and are interrelated, and indeed, we're
not entirely done fixing problems that run deep, but we are done fixing
all the problems that we care about, thus our commentary-only commits.

In particular, we're not addressing the lack of generality in
ServicePermission.  See, GSS-API is supposed to be a pluggable security
mechanism abstraction, and each security mechanism can have different
ways of naming entities, but ServicePermission is entirely
Kerberos-specific, and there are a number of places where
ServicePermissions are checked if and only if Kerberos was used but not
if something else was used.  It is clearly not correct to skip these
permission checks just because ServicePermission does not support
non-Kerberos mechanisms, but ServicePermission could have been designed
to -and could be updated to- to support them.

Now, we could have shown up quite a while back, but for a variety of
reasons that are not germane here, we ended up not being able to do so
until now.

I'd like to start by reviewing the important changes at an abstract
level:

 - making GSSName extend Principal

   I don't think this should be controversial in the least, but probably
   will require discussion.

   This is one way in which JGSS problems run deep: by not making
   GSSName extend Principal, it is not possible to use native GSS with
   JAAS.

 - adding GssLoginModule

   This is the other way in which the problems we're fixing run deep:
   GSS-API is supposed to be pluggable as to security mechanisms, but
   the JGSS / Krb5 stack is very Kerberos-specific.  It should always
   have been GssLoginModule, not 

Re: RFR 6913047: SunPKCS11 memory leak

[Valerie Peng]

Hi Martin,

I found the problem causing the one regression test failure and fixed 
it. Now Mach5 run is clean.


http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.02

I also made various changes hoping to improve things. You can compare 
the files in above webrev with yours for differences. General principal 
is to minimize the changes as all new code may introduce regressions 
especially with changes of this scale.
One key difference is that in your code, you destroy the native key 
handle after extracting native key info in the key constructor, and then 
re-creating the key handle when increase the reference count. I use a 
different approach, I keep the key handle in the key constructor which 
will then be destroyed when the reference count goes down to 0. From the 
regression test output that I observed, most keys are created and used 
once. Keeping the keyID in constructor seems more efficient. Besides, I 
also disable native key info extraction for all token keys.


One thing that I am debating is whether we should add some property to 
disable this. I am aware that this will only be enabled if the key info 
extraction succeeds. However, would there be cases where the extraction 
succeeds but the re-creation fails? P11 Key objects are quite widely 
used, if something goes wrong, the impact may be significant.


Thanks,
Valerie

On 10/1/2018 6:48 PM, Valerie Peng wrote:


Hi Martin,

For the KeyStore case, they are mostly token objects which the extract 
key info approach does not apply?


For your changes in p11_keymgmt.c, I ran into compiler error and 
SIGBUS errors on two OS (mac and solaris sparc), I ended up changing 
variable initializations as well as memset(...). With the updated 
native changes, I adapted and re-tested my prototype changes. For 
reference, you can find the updated prototype changes at: 
http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.01/


Besides making changes in the keymgmet.c for getting rid of 
platform-specific compilation error and SIGBUS error, I noticed that 
you hardcoded the key wrapping mechanism in native code for both 
getNativeKeyInfo(...)/createNativeKey() methods, it seems better to 
storing the mechanism object at java side, i.e. P11Key and its 
associated classes, and then pass the object to JNI code (please also 
see my webrev.01)


In addition, I switched the reference counting to your model, i.e. 
increase in init() and decrease in reset(), instead of the 
try-n-finally model in prototype webrev.00. My earlier comment on 
P11Cipher class which you should not replace the initialize() call 
with ensureInitialized() call applies to all other PKCS11 classes as well.


With this approach, the KeyID field of P11Key should not be freely 
accessible and directly referenced outside of P11Key class. Also, the 
increase and decrease of reference counting must be paired up. 
Supposedly, the reference count should not go negative, right? If the 
reference counting isn't correct, the key may be freed pre-maturely? 
Lastly, the reference counting is an implementation detail and I think 
it's better to keep it inside the P11Key class/file and not exposing 
it, i.e. through method names.


I have spent time verifying my updated prototype changes and trace the 
reference counting. All look fine, except there is one regression test 
failure (sun/security/tools/keytool/NssTest.java) on linux-x64 which I 
am still troubleshooting. However, I will be on vacation from 10/4 to 
10/21, so I want to update you on what I have so you can continue 
during my vacation.


Thanks,

Valerie



On 9/18/2018 4:48 PM, Valerie Peng wrote:


Hi Martin,

I am ok with your conservation choice of only applying this when 
using NSS. If we are only applying this for NSS, we should really 
refactor the code to minimize the impact on callers and P11Key class. 
My prototype code may be on the extreme end of minimizing changes. 
But the current webrev can use some refactoring also. With your 
explanation, I now understand your model better. How about the 
refactoring in P11Key class? Is there a reason for not doing this? I 
did test my prototype code against existing regression tests (except 
the KeyStore ones as more API changes are needed for persistent keys 
which I have not covered in prototype) but I ran into some strange 
errors in some native p11 calls which I did not touch so I commented 
them out and just checked the part of reference count, etc.


I will take a closer look at the KeyStore case and let you know.
Thanks,
Valerie

On 9/18/2018 7:29 AM, Martin Balao wrote:

Hi Valerie,

Thanks for your comments.

Here it is Webrev.11:

 * 
http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11/ 

 * 
http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11.zip 




L397: That's right. I was trying to simplify 

Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

[Sean Mullan]

For those of you that are not also subscribed to security-dev, this is 
mostly FYI, as the review is winding down, but if you have any comments, 
let me know.


This change will add new token options ("allow" and "disallow") to the 
java.security.manager system property. The "disallow" option is intended 
to provide a potential performance boost for applications that don't 
enable a SecurityManager, as there is a cost associated with allowing a 
SecurityManager to enabled at runtime, even if it is never enabled. The 
CSR provides a good summary of the issue and spec changes: 
https://bugs.openjdk.java.net/browse/JDK-8203316


Thanks,
Sean

 Forwarded Message 
Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's 
security manager immutable

Date: Tue, 2 Oct 2018 11:34:09 -0400
From: Sean Mullan 
Organization: Oracle Corporation
To: security Dev OpenJDK 

Hello,

Thanks for all the comments so far, and the interesting discussions 
about the future of the SecurityManager. We will definitely return to 
those discussions in the near future, but for now I have a second webrev 
ready for review for this enhancement:


http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/

The main changes since the initial revision are:

1. System.setSecurityManager is no longer deprecated. This type of 
change clearly needs more discussion and is not an essential part of 
this RFE.


2. After further thought, I took Bernd's suggestion [1] and instead of 
adding a new property to disallow the setting of a SecurityManager at 
runtime, have added new tokens to the existing "java.security.manager" 
system property, named "=disallow", and "=allow" to toggle this 
behavior. The "=" is to avoid any potential clashes with custom SM 
classes with those names. I think this is a cleaner approach. There are 
a couple of new paragraphs in the SecurityManager class description 
describing the "java.security.manager" property and how the new tokens work.


3. I also added a comment that Bernd had requested [2] on why 
System.setSecurityManager calls checkPackageAccess("java.lang").


Also, the CSR has been updated: 
https://bugs.openjdk.java.net/browse/JDK-8203316


Thanks,
Sean

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html
[2] 
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html


On 9/13/18 4:02 PM, Sean Mullan wrote:
This is a SecurityManager related change which warrants some additional 
details for its motivation.


The current System.setSecurityManager() API allows a SecurityManager to 
be set at run-time. However, because of this mutability, it incurs a 
performance overhead even for applications that never call it and do not 
enable a SecurityManager dynamically, which is probably the majority of 
applications.


For example, there are lots of "SecurityManager sm = 
System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If 
it was known that a SecurityManager could never be set at run-time, 
these checks could be optimized using constant-folding.


There are essentially two main parts to this change:

1. Deprecation of System.securityManager()

Going forward, we want to discourage applications from calling 
System.setSecurityManager(). Instead they should enable a 
SecurityManager using the java.security.manager system property on the 
command-line.


2. A new JDK-specific system property to disallow the setting of the 
security manager at run-time: jdk.allowSecurityManager


If set to false, it allows the run-time to optimize the code and improve 
performance when it is known that an application will never run with a 
SecurityManager. To support this behavior, the 
System.setSecurityManager() API has been updated such that it can throw 
an UnsupportedOperationException if it does not allow a security manager 
to be set dynamically.


webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8203316
JBS: https://bugs.openjdk.java.net/browse/JDK-8191053

(I will likely also send this to core-libs for additional review later)

--Sean

Re: RFR 8210395: Add doc to SecurityTools.java

[Sean Mullan]

Looks fine to me.

--Sean

On 9/24/18 11:59 PM, Weijun Wang wrote:

Ping again.


On Sep 5, 2018, at 12:17 PM, Weijun Wang  wrote:

I ran javadoc on test/lib so I can learn the useful helper classes, and find 
out SecurityTools.java has no javadoc at all.

Please review this change

   http://cr.openjdk.java.net/~weijun/8210395/webrev.00/

Thanks
Max

Re: Conceptual feedback on new ECC JEP

[Adam Petcher]

I received quite a bit of feedback that questions the value of the new 
provider, and the "branchless mode" in general. At the same time, nobody 
has told me that this mode would be useful to them. So I am removing it 
from the JEP. In short, I will only be doing the second bullet point 
from my last email below---SunEC will be modified to include modern 
implementations of these three curves. I want to stress that no change 
to the spec/description of SunEC will be made. In particular, the "EC" 
algorithms in SunEC will make no guarantees related to security against 
side-channel attacks.


Because this is now an implementation-only change, and there is no new 
feature to document, there is no longer any need to make this change 
under a JEP. My plan is to continue this work under JDK-8208698[1] and 
withdraw the JEP. There is no API or behavior change, so there will be 
no CSR for this change.


[1] https://bugs.openjdk.java.net/browse/JDK-8208698


On 9/25/2018 10:40 AM, Adam Petcher wrote:
Thanks, everyone for your feedback on this JEP. I have incorporated 
this feedback (received on this mailing list and elsewhere) into the 
draft JEP[1]. Here is a summary of the current JEP and plan:


*) A new provider (name TBD) will be developed to hold the new ECC 
implementation for the three curves. This provider will feature the 
interoperability-limiting restrictions on its API that were discussed 
at length on this mailing list. The new provider will be at the end of 
the list, so it won't be used by default.
*) The operations of the new implementation will also be added to 
SunEC for the three curves. This means that the new implementation 
will be used by default, in a completely compatible way (without any 
restrictions on its API). Using the new implementation through SunEC 
will not provide the same level of security against side-channel 
attacks as using it through the new provider.
*) We will add some tests that make sure that TLS still work when the 
new provider is used instead of SunEC. We may need to make some small 
changes to the TLS implementation in order to get these tests to pass.
*) A couple of people asked me about whether we could modernize the 
implementation of more curves in the future. I added a section at the 
end of the JEP to discuss this.


Of course, none of this is set in stone, and we still have some API 
details to work out in the CSR. I'll be doing the CSR next, and I'm 
happy to accept feedback at any time.


[1] https://bugs.openjdk.java.net/browse/JDK-8204574


On 8/23/2018 1:50 PM, Adam Petcher wrote:
I'm starting work on yet another ECC JEP[1], this time with the goal 
of developing improved implementations of existing algorithms, rather 
than implementing new ones. The JEP will re-implement ECDH and ECDSA 
for the 256-, 384-, and 521-bit NIST prime curves. The new 
implementation will be all Java, and will resist side-channel attacks 
by not branching on secrets. It will go in a new provider which is 
not in the provider list in the java.security file by default. So it 
will need to be manually enabled by changing the configuration or 
putting the new provider name in the code. It will only support a 
subset of the API that is supported by the implementation in SunEC. 
In particular, it will reject any private keys with scalar values 
specified using BigInteger (as in ECPrivateKeySpec), and its private 
keys will not return scalar values as BigInteger (as in 
ECPrivateKey.getS()).


Please take a look and send me any feedback you have. I'm especially 
looking for suggestions on how this new implementation should fit 
into the API. I would prefer to have it enabled by default, but I 
can't think of a way to do that without either branching on secrets 
in some cases (converting a BigInteger private key to an array) or 
breaking compatibility (throwing an exception when it gets a 
BigInteger private key).


[1] https://bugs.openjdk.java.net/browse/JDK-8204574

Re: JGSS Enhancements (contribution by Two Sigma Open Source)

[Alan Bateman]

On 03/10/2018 00:04, Nico Williams wrote:

Hello,

We at Two Sigma Open Source, LLC, would like to make a contribution, to
the OpenJDK, of various enhancements to the the OpenJDK's JGSS stack,
specifically for better interoperability with native C GSS-API
implementations.  As I understand it, Two Sigma Open Source, LLC, has
signed the OCA already.

The "How to contribute" [1] is the best place to start. I see you are 
listed on the OCA signatories so that gets you through step 0. For the 
patches then I think you'll need to start a discussion here on the 
specific issues and changes that are you looking to contribute. This 
project requires all contributions to be sent on the mailing list or 
hosted on locations such as cr.openjdk.java.net. From your mail then it 
sounds like you have a lot of changes so it's probably best to start 
small, say with small fixes, until you've gain some experience with the 
process of contributing and sponsors/reviewers build up confidence in 
the changes. I suspect you will have the experience of doing 
significantly better than showing up with large patch that add features 
and changes large areas of JGSS. Starting small is really important for 
sponsors and reviewers as the review and testing effort for many 
contributions can be significant.


-Alan

[1] http://openjdk.java.net/contribute/