Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* 
package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR 
API,  java.* API's ONCE REMOVED CANNOT BE REPLACED.  IF YOU ARE 
CONCERNED SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, 
OR CREATE AN INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME 
CONTROL OVER BACKWARD COMPATIBLE API EVOLUTION.


On 5/05/2021 10:08 am, Ron Pressler wrote:

Resent with plain-text formatting (I hope) & corrections/rephrasing


On 4 May 2021, at 03:49, Peter Firmstone  wrote:


Yes, I'm sure millions of developers don't use the security infrastructure 
because they only have low value data to protect, or it belongs to someone else 
and developers that do, can use it incorrectly, it's probably worse to do the 
latter, but then people synchronize incorrectly too, but we don't remove 
synchronization because of that.


The Security Manager hasn’t been a central part of Java’s server-side security 
for years. Some of the most critical and
best-secured systems in the world are written in Java, and they don’t use the 
Security Manager, so let’s not equate a
particular sandboxing mechanism designed for untrusted code with security.


Got any example best-secured systems?

I think we are talking past each other here.   You keep talking about 
untrusted code, which sounds like applets to me.  I've read and still 
have a copy of Li Gong's book, applets were only one of the 
considerations.  I am talking about authorization and access control.  
We use and develop distributed or p2p systems, we don't allow untrusted 
code to run at all, never ever, that's a dumb idea, so lets stop talking 
about untrusted code, we don't use that.    We do utilize dynamic 
downloaded code from others and use dynamic class loading, we verify 
this prior to loading.  We check it's authorized to run before running 
it.  Again I repeat, we do not run untrusted code, that would allow an 
attacker to cause denial of service etc, the JVM has no control over 
badly behaving code.


We've been using this since Java 1.4, to control access to networks, 
file systems and other custom permissions we created, it is used to 
protect access to sensitive data.  We are still using it.  I understand 
access control will be removed:


https://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc4.html#20389

We would like to continue restricting access to data after the above is 
removed.  Will Java be introducing new Role Based Access Control API or 
something similar?


Our software will fail to run on Java after the above is removed.   I 
understand we have to remove access control functionality from our 
software for it to continue functioning? We do need to understand how 
this will impact security, I think you are trying to convince me or 
yourself that security will not be impacted?  We can't just assume we 
can remove access control and our software will be no less secure.


What is the new API for access control in Java?

Obviously we won't have a call stack with domains, I don't know how we 
will transfer the user Subject to other threads, for TLS and Kerberos 
connections.  No doubt something is planned.


Is the recommendation simply not to upgrade Java until new access 
control API is developed?





Please provide some examples,  migration options suggestions will be 
appreciated.

I’ve jotted down some thoughts in a blog post: 
https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/


Noted, a good start.  I get the feeling this JEP is being rushed through 
however, with little regard for those of us who were foolish enough to 
use Java's security API's and will have to suffer the consequences.







With Serialization, we've been given more than ample notice to do something 
about migrating away from it, but OpenJDK paints over it and wastes resources 
adding features to putty and paint over it some more, features that no one 
uses.  Removing Serialization has greater appeal :)

This step to remove SecurityManager is so sudden with no replacement options, 
it's a broken promise to developers, who've invested in Java.

Removing SecurityManager has a significantly negative effect on security for 
me, just so you know.  I'm not happy about its proposed removal, but I realise 
there's not much I can do about it, other than request it be done in the least 
painful manner.

I began learning Java over 20 years ago, I understand the need to keep Java 
relevant, however move quickly and break things is for younger software 
platforms.


Not everyone has to agree with every priority decision, and the process doesn’t 
require convincing every last Java developer. But
it is not sudden, and there will be alternatives for those aspects of Security 
Manager that more people use. I don’t think it is fair
to harm millions of Java developers by diverting resources from features they 
want to features very few people want, as long as

Re: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v2]

[Xue-Lei Andrew Fan]

On Thu, 29 Apr 2021 15:58:28 GMT, Xue-Lei Andrew Fan  wrote:

>> Yes, I’ve made a test that calculates total time spent by server to receive 
>> "N" connections. Every server handshake is performed in a separate thread
>> The client starts "T" threads. Every thread sends one initial connection and 
>> "R-1" renegotiated connections. So, the total number of connections is  
>> "N"="T"*"R"
>> 
>> Results for the original and JDK-8241248 code are almost identical:
>> "T"=10 "R"=100
>> Original OpenJDK: 1140 ms
>> JDK-8241248 code: 1090 ms
>> 
>> "T"=50 "R"=100
>> Original OpenJDK: 1164 ms
>> JDK-8241248 code: 1108 ms
>> 
>> "T"=60 "R"=100
>> Original OpenJDK: 1461 ms
>> JDK-8241248 code: 1579 ms
>> 
>> "T"=70 "R"=100
>> Original OpenJDK: 2058 ms
>> JDK-8241248 code: 1999 ms
>> 
>> "T"=80 "R"=100
>> Original OpenJDK: 2148 ms
>> JDK-8241248 code: 2125 ms
>> 
>> "T"=90 "R"=100
>> Original OpenJDK: 2540 ms
>> JDK-8241248 code: 2514 ms
>> 
>> "T"=90 "R"=100
>> Original OpenJDK: 3011 ms
>> JDK-8241248 code: 3010 ms
>> 
>> I can confirm that the synchronization code works. Without it, I still catch 
>> exception from different threads trying to resume the same session from the 
>> cache
>
> Thank you for the update.
> 
> I also expect the code easy to read and maintain in the future.  But please 
> go ahead for the integration if you don't want to make the update now.  We 
> could file an enhancement later on.

> @XueleiFan , @jnimeh, thank you for your suggestions. I have updated 
> synchronization using ReentrantLock in the Cache object. The performance test 
> showed no issues.

Thank you for considering use ReentrantLock, the "synchronized" keyword is 
something we are trying to avoid in the JSSE implementation.  However, the 
reentrant lock introduced is not the lock in the Cache implementation.  They 
are overlapped and could be conflict.  The performance test looks good with 
just a few threads, but I'm not very sure of the through put impact if the 
threads goes up to 1M or more (there were complaints previously for large 
volume traffics).

Maybe, you could keep it simple by adding a pull() method in the Cache class 
(find the session and remove it from the cache if found), by using the Cache 
class internal synchronize methods.

-

PR: https://git.openjdk.java.net/jdk/pull/3664

Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

Resent with plain-text formatting (I hope) & corrections/rephrasing

> On 4 May 2021, at 03:49, Peter Firmstone  wrote:
> 
> 
> Yes, I'm sure millions of developers don't use the security infrastructure 
> because they only have low value data to protect, or it belongs to someone 
> else and developers that do, can use it incorrectly, it's probably worse to 
> do the latter, but then people synchronize incorrectly too, but we don't 
> remove synchronization because of that.
> 

The Security Manager hasn’t been a central part of Java’s server-side security 
for years. Some of the most critical and 
best-secured systems in the world are written in Java, and they don’t use the 
Security Manager, so let’s not equate a 
particular sandboxing mechanism designed for untrusted code with security.


> Lets drop the excuses that it's just a theoretical, impractical thing that 
> nobody uses, and say instead that we know that this does something important, 
> it is very powerful, it is a deployed API that is in use, probably the only 
> least privileged protection domain model that really works, but we are no 
> longer supporting it moving forward because it is not well understood by 
> those maintaining it and for this reason it creates a significant maintenance 
> burden.

I have to disagree on all counts here. Also, I want to emphasise that if 
Security Manager were an important security feature for
Java these days, then "some people have been able to make it effective" is the 
very opposite of “works” when it comes to security
and a mainstream language. A mechanism that confuses most people is still 
undesirable even if a small minority uses it correctly.

You can believe that the maintainers misunderstand this feature — that is a 
very bold claim — but even
if it were true it doesn’t change the following empirical facts: 1. SM is not 
used as a central security Java feature, 2. It is used at all by very few 
projects, and 3. it is a heavy maintenance burden. Maybe the reasons for these 
is misunderstanding or general incompetence
but that doesn’t change the reality. We need to work in the world we have, not 
the one we wish we had.

> Please provide some examples,  migration options suggestions will be 
> appreciated.

I’ve jotted down some thoughts in a blog post: 
https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/


> With Serialization, we've been given more than ample notice to do something 
> about migrating away from it, but OpenJDK paints over it and wastes resources 
> adding features to putty and paint over it some more, features that no one 
> uses.  Removing Serialization has greater appeal :)
> 
> This step to remove SecurityManager is so sudden with no replacement options, 
> it's a broken promise to developers, who've invested in Java.
> 
> Removing SecurityManager has a significantly negative effect on security for 
> me, just so you know.  I'm not happy about its proposed removal, but I 
> realise there's not much I can do about it, other than request it be done in 
> the least painful manner.
> 
> I began learning Java over 20 years ago, I understand the need to keep Java 
> relevant, however move quickly and break things is for younger software 
> platforms.  


Not everyone has to agree with every priority decision, and the process doesn’t 
require convincing every last Java developer. But
it is not sudden, and there will be alternatives for those aspects of Security 
Manager that more people use. I don’t think it is fair
to harm millions of Java developers by diverting resources from features they 
want to features very few people want, as long as
a reasonable removal process is employed, and I think it is here. 

> Once SecurityManager has been removed, we will lose control over who has 
> access to sensitive data, so it's likely we will be stuck on the last version 
> of Java that provides SecurityManager.  The best way I can see for those who 
> need the level of security that SecurityManager provides is to maintain a 
> community LTS edition on OpenJDK, it will be much easier to maintain and 
> backport security patches if Serialization in its current form has been 
> removed, as it will likely have been removed from later versions of Java by 
> that time.

I disagree. I don’t think that the Security Manager offers a higher level of 
security, just a very elaborate and fine-grained one.

> Lets be clear Java will no longer be able to finely control access to 
> sensitive data with the removal of SecurityManager.  I'm sure it will be a 
> great bonus for OpenJDK dev's not to have to think about, but it will impact 
> some developers significantly, who would like to do so with the least 
> suffering possible.

I wouldn’t say Java (or anything else, for that matter) is “able" to do it now, 
except in the sense that people (scientists) are 
able (in a billion-dollar particle accelerator) to transmute lead into gold (a 
few atoms). We’ve had twenty five years to 

Re: RFR: 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod

[Valerie Peng]

On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao  wrote:

> Hi,
> 
> Please find in this PR a proposal to fix JDK-8265462 [1].
> 
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal 
> Module. If the NSS Internal Module has more slots (for example, as a result 
> of an initialization sequence such as the one triggered from the 
> libnsssysinit.so library), they will be ignored. The goal is to handle 
> multiple-slots scenarios while keeping OpenJDK's previous behavior.
> 
> No regressions observed in the jdk/sun/security/pkcs11 tests category.
> 
> A new regression test was not added as part of this changeset because of its 
> complexity. It would depend on a specific NSS configuration, or the NSS 
> library would need to be mocked. I've done manual testing in my environment 
> and JDK-8265462 [1] has further information about it.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462

Here are some comments. Rest looks fine. Thanks. Valerie

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 81:

> 79: 
> 80: private final static int FIPS_SLOT_ID = 0x3;
> 81: 

Add a comment on where these are defined in native side, i.e. which sunpkcs11 
header file as well as the NSS header just in case?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 415:

> 413: } else {
> 414: throw new RuntimeException("Unexpected slot ID in 
> the" +
> 415: " NSS Internal Module");

Add the slot ID to the exception message?

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h line 78:

> 76: 
> 77: /* represent a pkcs#11 slot reference counted. */
> 78: struct PK11SlotInfoStr {

nit: add which nss header this is from.

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h line 166:

> 164: };
> 165: 
> 166: struct SECMODModuleStr {

Same nit: add which nss header this is from.

-

PR: https://git.openjdk.java.net/jdk/pull/3661

Re: RFR: 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod

[Valerie Peng]

On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao  wrote:

> Hi,
> 
> Please find in this PR a proposal to fix JDK-8265462 [1].
> 
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal 
> Module. If the NSS Internal Module has more slots (for example, as a result 
> of an initialization sequence such as the one triggered from the 
> libnsssysinit.so library), they will be ignored. The goal is to handle 
> multiple-slots scenarios while keeping OpenJDK's previous behavior.
> 
> No regressions observed in the jdk/sun/security/pkcs11 tests category.
> 
> A new regression test was not added as part of this changeset because of its 
> complexity. It would depend on a specific NSS configuration, or the NSS 
> library would need to be mocked. I've done manual testing in my environment 
> and JDK-8265462 [1] has further information about it.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h line 112:

> 110: #define NETSCAPE_SLOT_ID 1
> 111: #define PRIVATE_KEY_SLOT_ID 2
> 112: #define FIPS_SLOT_ID 3

These NSS specific defines is better off to be placed in a separate header file 
for ease of maintenance. In the past when PKCS#11 version is updated, we just 
drop the latest header files in and replace existing ones. Why not adding them 
to  to j2secmod.h or pkcs11wrapper.h?

-

PR: https://git.openjdk.java.net/jdk/pull/3661

Re: RFR: 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod

[Valerie Peng]

On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao  wrote:

> Hi,
> 
> Please find in this PR a proposal to fix JDK-8265462 [1].
> 
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal 
> Module. If the NSS Internal Module has more slots (for example, as a result 
> of an initialization sequence such as the one triggered from the 
> libnsssysinit.so library), they will be ignored. The goal is to handle 
> multiple-slots scenarios while keeping OpenJDK's previous behavior.
> 
> No regressions observed in the jdk/sun/security/pkcs11 tests category.
> 
> A new regression test was not added as part of this changeset because of its 
> complexity. It would depend on a specific NSS configuration, or the NSS 
> library would need to be mocked. I've done manual testing in my environment 
> and JDK-8265462 [1] has further information about it.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462

src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h line 105:

> 103: #define CKN_OTP_CHANGED 1UL
> 104: 
> 105: typedef CK_ULONG CK_PROFILE_ID;

There is already a typedef for CK_PROFILE_ID further down in this file.

-

PR: https://git.openjdk.java.net/jdk/pull/3661

Re: Tentative suggestion: Make X509Key.getKey() non-protected

[Michael StJohns]

Hi Tim -

Pardon the top posting, and I'm only speaking for myself, but your 
suggestion is unlikely to get any traction.


First and most importantly, sun.security.x509 et al are non-public 
classes (e.g. not part of the JDK API, rather than a reference to their 
java tagging), and generally align their public behaviors with the API, 
and modify their private behaviors as necessary to make them more 
efficient etc.   E.g. you can't even count on X509Key to exist from JDK 
to JDK as its possible that the plugin maintainer may completely 
refactor those classes at any time.


Secondly, the API and the encoding of the public and private keys 
generally reflects what the various RFCs and other standards documents 
specify.  Most of the key material has multiple ways to encode it, but 
that's not the responsibility of either the JDK or the underlying 
plugins - they all support a common PKIX encoding basis and expect that 
"foreign" keys (e.g. keys originating outside of a given provider) will 
be encoded in the common fashion when they enter or leave the 
provider. It's left to the programmer to do whatever other encodings 
are necessary and to do the translations to and from those.  (I have 
personal code for translating between raw EC keys and at least two 
different forms of secure element native forms, as well as moving public 
key material in and out of smart cards in various formats).


Third, yes it is 80s technology or earlier, but for better or worse, its 
what the infrastructure supports.


You may find a better place to make this suggestion over with the 
BouncyCastle folk.  There are a host of utilities included with their 
ASN1 libraries and crypto Providers that can be used to get what you 
want - but I see you've already noted that.


You could always build your own provider classes to do what you want.

Later, Mike



On 5/4/2021 2:48 PM, Tim Bray wrote:
Pardon the interruption.  I'm working on a social-media identity 
federation project involving zero-knowledge proofs where you post 
public-key/nonce/sig combinations to multiple places to prove the 
poster identities' shared ownership of a private key. Details (not 
really relevant to the following): 
https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity 



The representation of the public key needs to be textual. The most 
straightforward way to do that is a one-liner like so: 
Base64.getEncoder().encodeToString(key.getEncoded()) which gives you 
Base64'ed PKIX.


Problem is, people are wondering why they need PKIX. They want to use 
EdDSA and they don't see the need for algorithm agility (there's a 
faction that thinks it's actively harmful) and  point out that ed25119 
keys are just 32 bytes worth of bits and don't see why they need to 
use Eighties technologies to express them in ASCII and ask "why can't 
I just base64 those bytes?"  Which is straightforward in Go and JS and 
so on.


It is however not straightforward in Java (unless I'm missing 
something obvious, wouldn't be surprising) 
because sun.security.x509.X509Key.getKey() is protected; see 
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131 



I have verified, via abuse of the reflection APIs, that the BitArray 
that call returns does indeed represent the appropriate 32 ed25519 
bytes. So, I have an object that has the data that I need inside but 
for reasons of policy it is declining to reveal them.  BTW you can do 
this in BouncyCastle and friends.


Rather than changing protection on a long-established method, maybe a 
new public byte[] getKeyBytes() would be the thing to do?  Or maybe it 
would be better to make this an EdDSA-specific operation? Maybe the 
EdDSA classes already provide a way to do this that I couldn't find?


So, with an apology for possibly wasting your time, two questions:

1. Is there a principled Java 15 way to get the key bytes that I'm not 
smart enough to have found?
2. Failing that, would a proposal to allow access to un-PKIX'ed EdDSA 
key bytes be ruled out in principle for some good reason that I don't 
know about?

Tentative suggestion: Make X509Key.getKey() non-protected

[Tim Bray]

Pardon the interruption.  I'm working on a social-media identity federation
project involving zero-knowledge proofs where you post public-key/nonce/sig
combinations to multiple places to prove the poster identities' shared
ownership of a private key.  Details (not really relevant to the
following):
https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity

The representation of the public key needs to be textual. The most
straightforward way to do that is a one-liner like so:
Base64.getEncoder().encodeToString(key.getEncoded()) which gives you
Base64'ed PKIX.

Problem is, people are wondering why they need PKIX. They want to use EdDSA
and they don't see the need for algorithm agility (there's a faction that
thinks it's actively harmful) and  point out that ed25119 keys are just 32
bytes worth of bits and don't see why they need to use Eighties
technologies to express them in ASCII and ask "why can't I just base64
those bytes?"  Which is straightforward in Go and JS and so on.

It is however not straightforward in Java (unless I'm missing something
obvious, wouldn't be surprising) because sun.security.x509.X509Key.getKey()
is protected; see
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131

I have verified, via abuse of the reflection APIs, that the BitArray that
call returns does indeed represent the appropriate 32 ed25519 bytes. So, I
have an object that has the data that I need inside but for reasons of
policy it is declining to reveal them.  BTW you can do this in BouncyCastle
and friends.

Rather than changing protection on a long-established method, maybe a new
public byte[] getKeyBytes() would be the thing to do?  Or maybe it would be
better to make this an EdDSA-specific operation?  Maybe the EdDSA classes
already provide a way to do this that I couldn't find?

So, with an apology for possibly wasting your time, two questions:

1. Is there a principled Java 15 way to get the key bytes that I'm not
smart enough to have found?
2. Failing that, would a proposal to allow access to un-PKIX'ed EdDSA key
bytes be ruled out in principle for some good reason that I don't know
about?

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

On 4 May 2021, at 03:49, Peter Firmstone 
mailto:peter.firmst...@zeus.net.au>> wrote:


Yes, I'm sure millions of developers don't use the security infrastructure 
because they only have low value data to protect, or it belongs to someone else 
and developers that do, can use it incorrectly, it's probably worse to do the 
latter, but then people synchronize incorrectly too, but we don't remove 
synchronization because of that.

The Security Manager hasn’t been a central part of Java’s server-side security 
for years. Some of the most critical and best-secured
systems in the world are written in Java, and they don’t use the Security 
Manager, so let’s not equate a particular sandboxing mechanism
designed for untrusted code with security.


Lets drop the excuses that it's just a theoretical, impractical thing that 
nobody uses, and say instead that we know that this does something important, 
it is very powerful, it is a deployed API that is in use, probably the only 
least privileged protection domain model that really works, but we are no 
longer supporting it moving forward because it is not well understood by those 
maintaining it and for this reason it creates a significant maintenance burden.

I have to disagree on all counts here. Also, I want to emphasise that if 
Security Manager were an important security feature for
Java these days, then “some people have been able to make it effective” is the 
very opposite of “works” when it comes to security
and a mainstream language. You can believe that the maintainers misunderstand 
this feature — that is a very bold claim — but even
if it were true it doesn’t change the following empirical facts: 1. SM is not 
used as a central security Java feature, 2. It is used at all
by very few projects, and 3. it is a heavy maintenance burden. Maybe the 
reasons for these is misunderstanding or general incompetence
but that doesn’t change the reality.


Please provide some examples,  migration options suggestions will be 
appreciated.

I’ve jotted down some thoughts in a blog post: 
https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/


With Serialization, we've been given more than ample notice to do something 
about migrating away from it, but OpenJDK paints over it and wastes resources 
adding features to putty and paint over it some more, features that no one 
uses.  Removing Serialization has greater appeal :)

This step to remove SecurityManager is so sudden with no replacement options, 
it's a broken promise to developers, who've invested in Java.

Removing SecurityManager has a significantly negative effect on security for 
me, just so you know.  I'm not happy about its proposed removal, but I realise 
there's not much I can do about it, other than request it be done in the least 
painful manner.

I began learning Java over 20 years ago, I understand the need to keep Java 
relevant, however move quickly and break things is for younger software 
platforms.

Not everyone has to agree on every priority decision, and the process doesn’t 
require convincing every last Java developer. But
it is not sudden, and there will be alternatives for those aspects of Security 
Manager that many people use. I don’t think it is fair
to harm millions of Java developers by diverting resources from features they 
want to features very few people want, as long as
a reasonable removal process is employed, and I think it is here.


Once SecurityManager has been removed, we will lose control over who has access 
to sensitive data, so it's likely we will be stuck on the last version of Java 
that provides SecurityManager.  The best way I can see for those who need the 
level of security that SecurityManager provides is to maintain a community LTS 
edition on OpenJDK, it will be much easier to maintain and backport security 
patches if Serialization in its current form has been removed, as it will 
likely have been removed from later versions of Java by that time.


I disagree.

Lets be clear Java will no longer be able to finely control access to sensitive 
data with the removal of SecurityManager.  I'm sure it will be a great bonus 
for OpenJDK dev's not to have to think about, but it will impact some 
developers significantly, who would like to do so with the least suffering 
possible.


I wouldn’t say Java (or anything else, for that matter) is “able" to do it now, 
except in the sense that people (scientists) are able (in a billion-
dollar particle accelerator) to transmute lead into gold (a few atoms). We’ve 
had twenty five years to convince the world this could work,
the world isn’t buying, and our job isn’t to sell ideas but to serve millions 
of developers. It’s time to move on.

— Ron

Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption

[Daniel Fuchs]

On Tue, 4 May 2021 15:12:39 GMT, Fernando Guallini  
wrote:

> test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior 
> when a server closes the socket connection during a handshake. The server was 
> waiting a fixed 100ms before closing it, but there was no guarantee that the 
> client started the handshake before or during that time frame 
> 
> With this changeset, the server is checking whether the client thread has 
> initiated handshake, and retrying if needed after waiting a short time. In 
> addition, the test is now reusing SSLSocketTemplate to simplify sockets 
> configuration and client/server synchronization

test/jdk/sun/security/ssl/SSLSocketImpl/CloseSocket.java line 45:

> 43: public class CloseSocket extends SSLSocketTemplate {
> 44: 
> 45: private static Thread clientThread = null;

Shouldn't this variable be `volatile`? If I'm not mistaken it's set in one 
thread and potentially read in a different thread? An alternative could be to 
use a CountDownLatch instead.

-

PR: https://git.openjdk.java.net/jdk/pull/3856

RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption

[Fernando Guallini]

test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when 
a server closes the socket connection during a handshake. The server was 
waiting a fixed 100ms before closing it, but there was no guarantee that the 
client started the handshake before or during that time frame 

With this changeset, the server is checking whether the client thread has 
initiated handshake, and retrying if needed after waiting a short time. In 
addition, the test is now reusing SSLSocketTemplate to simplify sockets 
configuration and client/server synchronization

-

Commit messages:
 - close socket after handshake started

Changes: https://git.openjdk.java.net/jdk/pull/3856/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3856=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8164804
  Stats: 103 lines in 1 file changed: 39 ins; 50 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3856/head:pull/3856

PR: https://git.openjdk.java.net/jdk/pull/3856

Fwd: Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore

[Jean-Yves Cronier]

Following the advice of Wei-Jun Wang, I share/forward to this mailing-list, 
details of a problem that I encounter on MacOS.

At the moment, I don't know how to modify the existing code so that the Apple 
Provider can behave like SunMSCAPI


> Début du message réexpédié :
> 
> De: Wei-Jun Wang 
> Objet: Rép. : Java Bug : Mutual HTTPS authentication not possible with a 
> non-extractable private key with Apple/KeychainStore
> Date: 3 mai 2021 à 18:11:12 UTC+2
> À: Jean-Yves Cronier 
> 
> And BTW, it’s better to write to an area-specific mail list next time when 
> you find an issue in OpenJDK. The jdk-dev@ mail list is probably too big and 
> people discuss more grand things there. :-)
> 
> For security, it’s security-dev@openjdk.java.net.
> 
> Thanks,
> Weijun
> 
 Le 3 mai 2021 à 16:03, Wei-Jun Wang  a écrit :
 
 Hi Jean-Yves,
 
 On macOS there’s only native key/certificate management but no signature 
 signing/verification. If you look at 
 https://docs.oracle.com/javase/9/security/oracleproviders.htm, the Apple 
 provider only implements KeyStore. If you need to use a key in client 
 auth, it needs to extract that key and use another provider (SunRsaSign or 
 SunEC) to use it.
 
 On the other hand, SunMSCAPI has implemented both KeyStore and Signature, 
 therefore it can do both things inside the provider and the key does not 
 need to be extracted.
 
 I’ve filed https://bugs.openjdk.java.net/browse/JDK-8266439.
 
 Thanks,
 Weijun
 
> On May 1, 2021, at 8:19 AM, Jean-Yves Cronier  
> wrote:
> 
> Description
> 
> I have imported my personal certificate in macOS keychain with 
> "non-extractable" option (cf. 
> https://ss64.com/osx/security-export.html).
> Private key is now protected, and we can't export private key from macOS 
> KeyChain
> But I am unable to establish connexion with a web-API which require 
> client certificate for mutual authentication with Java
> It work perfectly well with curl/git, and browsers (safari/chrome)
> 
> 
> <>System / OS / Java Runtime Information
> 
> openjdk 11.0.11
> macOS 11.3
> 
> 
> <>Steps to Reproduce
> 
> 1. Add personal certificate with "non-extractable" option. Example with a 
> personal certificate sent to me in a P12 file named "my-certificate.p12", 
> with following command-line:
> security import my-certificate.p12 -x -P « my-strong-password"
> 2. Connect a site require mutual authentication (for example : 
> https://server.cryptomix.com/secure/ 
>  )
> 
> 
> <>Expected Result
> 
> Display content detail of selected client certificate
> 
> 
> <>Actual Result
> 
> Error: No TLS client certificate presented 
> 
> 
> <>Source code for an executable test case
> 
> import javax.net.ssl.HttpsURLConnection;
> import java.io.IOException;
> import java.net.URL;
> import java.security.cert.X509Certificate;
> 
> public class MutualAuthenticationTest {
>   public static void main(String[] args) throws IOException {
>   System.setProperty("javax.net.ssl.keyStoreType", 
> "KeychainStore");
>   System.setProperty("javax.net.ssl.keyStore", "NONE");
>   System.setProperty("javax.net.ssl.keyStorePassword", "-");
>   testUrl(new URL("https://server.cryptomix.com/secure/;));
>   }
> 
>   public static void testUrl(URL targetUrl) throws IOException {
>   HttpsURLConnection con = (HttpsURLConnection) 
> targetUrl.openConnection();
>   // Open the connection
>   con.getResponseCode();
> 
>   assert con.getLocalCertificates() != null && 
> con.getLocalCertificates().length > 0 : "Must use a personnel certificate 
> for mutual authentication";
>   X509Certificate personalCertificate = (X509Certificate) 
> con.getLocalCertificates()[0];
>   assert personalCertificate.getSubjectDN() != null;
>   }
> }
> 
> 
> <>Workaround
> 
> No possible workaround on MacOS which Apple/KeychainStore
> NB : Perfectly work on Windows/MSCAPI with personnel certificate (with 
> non-exportable private key option)
>>> 
>> 
> 

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v11]

[Maurizio Cimadamore]

> This PR contains the API and implementation changes for JEP-412 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one 
additional commit since the last revision:

  Fix message string in Reflection::ensureNativeAccess

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/2a31da40..72eb9bbc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10]

[Alan Bateman]

On Tue, 4 May 2021 12:05:15 GMT, Maurizio Cimadamore  
wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more 
>> detailed description of such changes, to avoid repetitions during the review 
>> process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Tweak comment in Module::enableNativeAccess

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 112:

> 110: Module module = currentClass.getModule();
> 111: if 
> (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) {
> 112: throw new IllegalCallerException("Illegal native access from 
> module: " + module);

You may want to drop "module" from the exception message as Module::toString is 
specified to return "module " or "unnamed module " so you'll end up 
duplication "module" in the message.

-

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7]

[Alan Bateman]

On Tue, 4 May 2021 12:01:44 GMT, Maurizio Cimadamore  
wrote:

>> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java
>>  line 34:
>> 
>>> 32: import java.util.Set;
>>> 33: 
>>> 34: public final class IllegalNativeAccessChecker {
>> 
>> Are you sure about the name of the this class? It doesn't do any checking 
>> and it's not concerned with "illegal native access" either, instead it just 
>> provides access to the names of modules that have been granted native access.
>
> I've decided to drop this class and move the logic in ModuleBootstrap. To 
> handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED 
> module and set the flag there when decoding the command line option. This 
> seems to be consistent with what is done in other areas.

Good, this looks much simpler now.

-

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7]

[Maurizio Cimadamore]

On Tue, 4 May 2021 08:12:23 GMT, Alan Bateman  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - Revert bad change in benchmark copyright
>>  - Do not apply optimized bound check if accessed offset/length do not fit 
>> in an `int` value
>
> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java
>  line 34:
> 
>> 32: import java.util.Set;
>> 33: 
>> 34: public final class IllegalNativeAccessChecker {
> 
> Are you sure about the name of the this class? It doesn't do any checking and 
> it's not concerned with "illegal native access" either, instead it just 
> provides access to the names of modules that have been granted native access.

I've decided to drop this class and move the logic in ModuleBootstrap. To 
handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED 
module and set the flag there when decoding the command line option. This seems 
to be consistent with what is done in other areas.

-

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10]

[Maurizio Cimadamore]

> This PR contains the API and implementation changes for JEP-412 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with one 
additional commit since the last revision:

  Tweak comment in Module::enableNativeAccess

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/ead71078..2a31da40

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v9]

[Maurizio Cimadamore]

> This PR contains the API and implementation changes for JEP-412 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with three 
additional commits since the last revision:

 - Tweak code some more
 - Use uniform naming convention for implementation metods in Module
 - Remove IllegalNativeAccessChecker

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/6a659d87..ead71078

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=07-08

  Stats: 169 lines in 5 files changed: 41 ins; 114 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v8]

[Maurizio Cimadamore]

> This PR contains the API and implementation changes for JEP-412 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

Maurizio Cimadamore has updated the pull request incrementally with two 
additional commits since the last revision:

 - Remove redundant initializer in Module
 - Address review comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/793ea5c5..6a659d87

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=06-07

  Stats: 19 lines in 3 files changed: 6 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7]

[Maurizio Cimadamore]

On Tue, 4 May 2021 08:20:43 GMT, Alan Bateman  wrote:

> Just to double, there is no way to enable native access for modules in module 
> layers (other than the boot layer), right?

No, at the moment it is not possible to enable native access programmatically. 
We will explore something along those lines in the future.

-

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7]

[Alan Bateman]

On Fri, 30 Apr 2021 15:20:42 GMT, Maurizio Cimadamore  
wrote:

>> This PR contains the API and implementation changes for JEP-412 [1]. A more 
>> detailed description of such changes, to avoid repetitions during the review 
>> process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - Revert bad change in benchmark copyright
>  - Do not apply optimized bound check if accessed offset/length do not fit in 
> an `int` value

Just to double, there is no way to enable native access for modules in module 
layers (other than the boot layer), right?

src/java.base/share/classes/java/lang/Module.java line 115:

> 113: 
> 114: // is this module a native module
> 115: private volatile boolean enableNativeAccess = false;

Can you drop "= false", it's not needed and I don't think we want a 
volatile-write here.
Also the comment may date from a previous iteration as there isn't any concept 
of a "native module".

src/java.base/share/classes/java/lang/System.java line 2346:

> 2344: public boolean isEnableNativeAccess(Module m) {
> 2345: return m.isEnableNativeAccess();
> 2346: }

Can you move this up so they are with the other Module methods?

src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java 
line 34:

> 32: import java.util.Set;
> 33: 
> 34: public final class IllegalNativeAccessChecker {

Are you sure about the name of the this class? It doesn't do any checking and 
it's not concerned with "illegal native access" either, instead it just 
provides access to the names of modules that have been granted native access.

src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java 
line 47:

> 45: private static IllegalNativeAccessChecker checker;
> 46: 
> 47: static Collection enableNativeAccessModules() {

I assume this can be changed to Iterable as you don't want anything 
outside of this class changing the collection.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 889:

> 887: } else {
> 888: // silently skip.
> 889: // warnUnknownModule(ENABLE_NATIVE_ACCESS, name);

Maybe for later but the other options do emit a warning when unknown module is 
specified. If the decoding of this command line option is moved to 
ModuleBootstrap then most of this class will go away and you will be able to 
use warnUnknownModule.

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 113:

> 111: if 
> (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) {
> 112: String moduleName = module.isNamed()?  module.getName() : 
> "UNNAMED";
> 113: throw new IllegalCallerException("Illegal native access from 
> module: " + moduleName);

"UNNAMED" is a bit inconsistent with the other exception messages. Can you just 
use Module::toString here instead, meaning "Illegal native access from " + 
module ?

-

PR: https://git.openjdk.java.net/jdk/pull/3699