Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[Peter Firmstone]

Hi Arjan,

Java 8 is supported until 2030, and 17 to 2029, we would be unable to 
continue testing against new Java releases.


https://bugs.openjdk.java.net/browse/JDK-8272340

With this choice, there will be incompatible Java versions we must 
prevent our software from running on, until it becomes possible to 
support a later version.


It also means that someone who wants to use new Java API's on a Java 
version we don't support may be forced to migrate away from using our 
software.   It also means that we will be unable to take advantage of 
new Java API's which may put us at a significant disadvantage.


Regards,

Peter.

On 2/05/2022 5:24 pm, arjan tijms wrote:

Hi,

On Monday, May 2, 2022, Peter Firmstone  
wrote:


I guess I'm just trying to say we need more time, the process of
extricating SM for security will take years, if we can leave SM as
it is in deprecated form for a number of years, that would be
greatly appreciated.


Just wondering, but would it not be an option to just keep using the 
last LTS that has the SM? That may well enable you to keep using the 
SM for something like 10 years?


Kind regards,
Arjan Tijms



Regards,

Peter.

On 27/04/2022 3:38 am, Sean Mullan wrote:



On 4/26/22 1:06 PM, Scott Stark wrote:

By "migration feature" I'm talking about being able to
retain the type of library code where one has a
conditional call to an AccessController::doPrivileged(...)
method that is only done when System.getSecurityManager()
is not null. Not having to remove this code in all
dependent libraries for a given Jakarta EE application
server product in order to run on Java SE 21 is seen as
necessary to navigate supporting application servers over
a range of Java SE versions. The general consensus was
that having to deal with Java SE 11, 17 and 21 would only
be possible if this SecurityManager related code could
remain as is, even if the only executed path would be
for System.getSecurityManager() == null. We can deal with
a gradual degradation of the SecurityManager behavior, but
it was unclear if Java SE 21 was looking for a complete
removal of the APIs the libraries use.


Yes, we understand these concerns. We recognize the
compatibility issues and the importance for code using the SM
APIs to continue to work as if an SM has not been enabled.
This is the motivation behind the language in the JEP that
discusses a gradual degradation and phasing out of the SM APIs
until the compatibility risk is low enough that removal is
acceptable.

Also, you mention SE 21, but as of yet there is not yet a
targeted release for the SM removal. There will likely be a
JEP for the removal of the SM and this will need to go through
several phases of the JEP process before it can be targeted to
a specific release.

I'm sure many of the Jakarta EE platform dev members have
code repositories to offer for scanning to aide in
determining when the SecurityManager dependencies have
been removed. If there is a avenue for that information,
please let me know.


Thanks for that offer. I don't have an avenue for that
information yet, but I will see if we can start creating a
list of significant SM-enabled libraries and other projects
that we can monitor over time.

--Sean

Thanks,
Scott

On Apr 26, 2022 at 11:09:22 AM, Sean Mullan
mailto:sean.mul...@oracle.com>>
wrote:

Hello Scott,

On 4/25/22 2:25 PM, Scott Stark wrote:

Hello,

I'm Scott Stark of Red Hat, and a member of the
Jakarta EE platform dev
group (EEPD). I'm currently coordinating the
Jakarta EE 10 release that
is targeting June of this year (2022). The removal
of the
SecurityManager as described in JEP-411 has been a
topic for the EEPD on
may calls this year. Recent discussions make it
clear that any
SecurityManager alternative would need to be taken
up by the EEPD, and
such an effort is going to be a non-trivial
undertaking, and may not be
addressed at all.

A general concern among vendors in the EEPD is the
timeframe for the
code that bridges between the JVM running with and
without a
SecurityManager instance needing to be updated.
 

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[arjan tijms]

Hi,

On Monday, May 2, 2022, Peter Firmstone  wrote:

I guess I'm just trying to say we need more time, the process of
> extricating SM for security will take years, if we can leave SM as it is in
> deprecated form for a number of years, that would be greatly appreciated.


Just wondering, but would it not be an option to just keep using the last
LTS that has the SM? That may well enable you to keep using the SM for
something like 10 years?

Kind regards,
Arjan Tijms




>
> Regards,
>
> Peter.
>
> On 27/04/2022 3:38 am, Sean Mullan wrote:
>
>>
>>
>> On 4/26/22 1:06 PM, Scott Stark wrote:
>>
>>> By "migration feature" I'm talking about being able to retain the type
>>> of library code where one has a conditional call to an
>>> AccessController::doPrivileged(...) method that is only done when
>>> System.getSecurityManager() is not null. Not having to remove this code in
>>> all dependent libraries for a given Jakarta EE application server product
>>> in order to run on Java SE 21 is seen as necessary to navigate supporting
>>> application servers over a range of Java SE versions. The general consensus
>>> was that having to deal with Java SE 11, 17 and 21 would only be possible
>>> if this SecurityManager related code could remain as is, even if the only
>>> executed path would be for System.getSecurityManager() == null. We can
>>> deal with a gradual degradation of the SecurityManager behavior, but it was
>>> unclear if Java SE 21 was looking for a complete removal of the APIs the
>>> libraries use.
>>>
>>
>> Yes, we understand these concerns. We recognize the compatibility issues
>> and the importance for code using the SM APIs to continue to work as if an
>> SM has not been enabled. This is the motivation behind the language in the
>> JEP that discusses a gradual degradation and phasing out of the SM APIs
>> until the compatibility risk is low enough that removal is acceptable.
>>
>> Also, you mention SE 21, but as of yet there is not yet a targeted
>> release for the SM removal. There will likely be a JEP for the removal of
>> the SM and this will need to go through several phases of the JEP process
>> before it can be targeted to a specific release.
>>
>> I'm sure many of the Jakarta EE platform dev members have code
>>> repositories to offer for scanning to aide in determining when the
>>> SecurityManager dependencies have been removed. If there is a avenue for
>>> that information, please let me know.
>>>
>>
>> Thanks for that offer. I don't have an avenue for that information yet,
>> but I will see if we can start creating a list of significant SM-enabled
>> libraries and other projects that we can monitor over time.
>>
>> --Sean
>>
>> Thanks,
>>> Scott
>>>
>>> On Apr 26, 2022 at 11:09:22 AM, Sean Mullan >> > wrote:
>>>
 Hello Scott,

 On 4/25/22 2:25 PM, Scott Stark wrote:

> Hello,
>
> I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev
> group (EEPD). I'm currently coordinating the Jakarta EE 10 release that
> is targeting June of this year (2022). The removal of the
> SecurityManager as described in JEP-411 has been a topic for the EEPD
> on
> may calls this year. Recent discussions make it clear that any
> SecurityManager alternative would need to be taken up by the EEPD, and
> such an effort is going to be a non-trivial undertaking, and may not be
> addressed at all.
>
> A general concern among vendors in the EEPD is the timeframe for the
> code that bridges between the JVM running with and without a
> SecurityManager instance needing to be updated. Such code is the
> subject
> of this JEP-411 paragraph:
>
> "In feature releases after Java 18, we will degrade other Security
> Manager APIs so that they remain in place but with limited or no
> functionality. For example, we may revise
> AccessController::doPrivileged
> simply to run the given action, or revise System::getSecurityManager
> always to return null. This will allow libraries that support the
> Security Manager and were compiled against previous Java releases to
> continue to work without change or even recompilation. We expect to
> remove the APIs once the compatibility risk of doing so declines to an
> acceptable level."
>
> Of particular interest is the timeframe for "remove the APIs once the
> compatibility risk of doing so declines to an acceptable level".
>
> Vendors in EEPD would like to see Java SE 21 ship with a migration
> feature along the lines of the proposed "AccessController::doPrivilege
> d
> simply to run the given action, or revise System::getSecurityManager
> always to return null" behaviors.
>

 Can you clarify what you mean by "a migration feature" and also provide
 some background as to why vendors in EEPD would like to see this? Do you
 mean something like a system property that 

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[Peter Firmstone]

Our software was never designed to run without SM enabled.  We will need 
to instrument the Java API's with some access controls, this will be 
reliant on the removal of finalizers, or the option to disable them.


In our case deserialization is decided by the permission granted to the 
authenticated remote user.   Deserialization also has a number of 
different categories based on risk.   For example explicit permission is 
required to deserialize a MarshalledObject, in this case the 
MarshalledObject is only used for equals comparison, the 
MarshalledObject is never itself unmarshalled, checked by code audit 
before granting this permission.  The ability to class load remote code 
dynamically is also determined by permission.


Our software attempts to set the security manager if it hasn't been set.

We realise that this is no longer the recommended way to secure Java 
software, however our software will be insecure without SM until we can 
replace its functionality.


The problem is, OpenJDK is telling us that this is not the best way to 
secure Java, that there are better alternatives, however without SM our 
software will be insecure, until we are able to redesign it, 
unentangling our dependency on SM isn't a simple problem to solve.


I guess I'm just trying to say we need more time, the process of 
extricating SM for security will take years, if we can leave SM as it is 
in deprecated form for a number of years, that would be greatly appreciated.


Regards,

Peter.

On 27/04/2022 3:38 am, Sean Mullan wrote:



On 4/26/22 1:06 PM, Scott Stark wrote:
By "migration feature" I'm talking about being able to retain the 
type of library code where one has a conditional call to an 
AccessController::doPrivileged(...) method that is only done when 
System.getSecurityManager() is not null. Not having to remove this 
code in all dependent libraries for a given Jakarta EE application 
server product in order to run on Java SE 21 is seen as necessary to 
navigate supporting application servers over a range of Java SE 
versions. The general consensus was that having to deal with Java SE 
11, 17 and 21 would only be possible if this SecurityManager related 
code could remain as is, even if the only executed path would be 
for System.getSecurityManager() == null. We can deal with a gradual 
degradation of the SecurityManager behavior, but it was unclear if 
Java SE 21 was looking for a complete removal of the APIs the 
libraries use.


Yes, we understand these concerns. We recognize the compatibility 
issues and the importance for code using the SM APIs to continue to 
work as if an SM has not been enabled. This is the motivation behind 
the language in the JEP that discusses a gradual degradation and 
phasing out of the SM APIs until the compatibility risk is low enough 
that removal is acceptable.


Also, you mention SE 21, but as of yet there is not yet a targeted 
release for the SM removal. There will likely be a JEP for the removal 
of the SM and this will need to go through several phases of the JEP 
process before it can be targeted to a specific release.


I'm sure many of the Jakarta EE platform dev members have code 
repositories to offer for scanning to aide in determining when the 
SecurityManager dependencies have been removed. If there is a avenue 
for that information, please let me know.


Thanks for that offer. I don't have an avenue for that information 
yet, but I will see if we can start creating a list of significant 
SM-enabled libraries and other projects that we can monitor over time.


--Sean


Thanks,
Scott

On Apr 26, 2022 at 11:09:22 AM, Sean Mullan > wrote:

Hello Scott,

On 4/25/22 2:25 PM, Scott Stark wrote:

Hello,

I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform 
dev
group (EEPD). I'm currently coordinating the Jakarta EE 10 release 
that

is targeting June of this year (2022). The removal of the
SecurityManager as described in JEP-411 has been a topic for the 
EEPD on

may calls this year. Recent discussions make it clear that any
SecurityManager alternative would need to be taken up by the EEPD, and
such an effort is going to be a non-trivial undertaking, and may 
not be

addressed at all.

A general concern among vendors in the EEPD is the timeframe for the
code that bridges between the JVM running with and without a
SecurityManager instance needing to be updated. Such code is the 
subject

of this JEP-411 paragraph:

"In feature releases after Java 18, we will degrade other Security
Manager APIs so that they remain in place but with limited or no
functionality. For example, we may revise 
AccessController::doPrivileged

simply to run the given action, or revise System::getSecurityManager
always to return null. This will allow libraries that support the
Security Manager and were compiled against previous Java releases to
continue to work without change or even recompilation. We expect to
remove the APIs once the compatibility 

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[Scott Stark]

 By "migration feature" I'm talking about being able to retain the type of
library code where one has a conditional call to an
AccessController::doPrivileged(...) method that is only done when
System.getSecurityManager() is not null. Not having to remove this code in
all dependent libraries for a given Jakarta EE application server product
in order to run on Java SE 21 is seen as necessary to navigate supporting
application servers over a range of Java SE versions. The general consensus
was that having to deal with Java SE 11, 17 and 21 would only be possible
if this SecurityManager related code could remain as is, even if the only
executed path would be for System.getSecurityManager() == null. We can deal
with a gradual degradation of the SecurityManager behavior, but it was
unclear if Java SE 21 was looking for a complete removal of the APIs the
libraries use.

I'm sure many of the Jakarta EE platform dev members have code repositories
to offer for scanning to aide in determining when the SecurityManager
dependencies have been removed. If there is a avenue for that information,
please let me know.

Thanks,
Scott

On Apr 26, 2022 at 11:09:22 AM, Sean Mullan  wrote:

> Hello Scott,
>
> On 4/25/22 2:25 PM, Scott Stark wrote:
>
> Hello,
>
>
> I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev
>
> group (EEPD). I'm currently coordinating the Jakarta EE 10 release that
>
> is targeting June of this year (2022). The removal of the
>
> SecurityManager as described in JEP-411 has been a topic for the EEPD on
>
> may calls this year. Recent discussions make it clear that any
>
> SecurityManager alternative would need to be taken up by the EEPD, and
>
> such an effort is going to be a non-trivial undertaking, and may not be
>
> addressed at all.
>
>
> A general concern among vendors in the EEPD is the timeframe for the
>
> code that bridges between the JVM running with and without a
>
> SecurityManager instance needing to be updated. Such code is the subject
>
> of this JEP-411 paragraph:
>
>
> "In feature releases after Java 18, we will degrade other Security
>
> Manager APIs so that they remain in place but with limited or no
>
> functionality. For example, we may revise AccessController::doPrivileged
>
> simply to run the given action, or revise System::getSecurityManager
>
> always to return null. This will allow libraries that support the
>
> Security Manager and were compiled against previous Java releases to
>
> continue to work without change or even recompilation. We expect to
>
> remove the APIs once the compatibility risk of doing so declines to an
>
> acceptable level."
>
>
> Of particular interest is the timeframe for "remove the APIs once the
>
> compatibility risk of doing so declines to an acceptable level".
>
>
> Vendors in EEPD would like to see Java SE 21 ship with a migration
>
> feature along the lines of the proposed "AccessController::doPrivileged
>
> simply to run the given action, or revise System::getSecurityManager
>
> always to return null" behaviors.
>
>
> Can you clarify what you mean by "a migration feature" and also provide
> some background as to why vendors in EEPD would like to see this? Do you
> mean something like a system property that enables the degraded behavior
> as described above?
>
> Is there some metric for tracking "when the compatibility risk of doing
>
> so declines to an acceptable level."? I believe the EEPD vendors would
>
> like readiness of their projects and upstream dependencies to somehow be
>
> included in any such tracking.
>
>
> So, first we do not yet have a proposed target date for when we would
> like to remove support for the Security Manager (SM) from the JDK. By
> removing support, I mean that the JDK would no longer include a SM
> implementation. However, I don't anticipate that any SM specific APIs
> would be degraded *prior* to removing SM support from the JDK.
>
> Some APIs will likely be degraded as described above at the same time we
> remove support for the SM from the JDK.
>
> As for when the APIs will actually be removed, this will most likely be
> a longer period, possibly several JDK releases. We recognize that many
> libraries and applications will need time to adapt to the changes and
> remove dependencies on the APIs. We have tools that check open source
> repositories for API dependencies and are able to provide us with data
> that helps assess the compatibility risk. However, I can't give you a
> timeframe for API removal yet.
>
> HTH,
> Sean
>

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[Sean Mullan]

On 4/26/22 1:06 PM, Scott Stark wrote:
By "migration feature" I'm talking about being able to retain the type 
of library code where one has a conditional call to an 
AccessController::doPrivileged(...) method that is only done when 
System.getSecurityManager() is not null. Not having to remove this code 
in all dependent libraries for a given Jakarta EE application server 
product in order to run on Java SE 21 is seen as necessary to navigate 
supporting application servers over a range of Java SE versions. The 
general consensus was that having to deal with Java SE 11, 17 and 21 
would only be possible if this SecurityManager related code could remain 
as is, even if the only executed path would be 
for System.getSecurityManager() == null. We can deal with a gradual 
degradation of the SecurityManager behavior, but it was unclear if Java 
SE 21 was looking for a complete removal of the APIs the libraries use.


Yes, we understand these concerns. We recognize the compatibility issues 
and the importance for code using the SM APIs to continue to work as if 
an SM has not been enabled. This is the motivation behind the language 
in the JEP that discusses a gradual degradation and phasing out of the 
SM APIs until the compatibility risk is low enough that removal is 
acceptable.


Also, you mention SE 21, but as of yet there is not yet a targeted 
release for the SM removal. There will likely be a JEP for the removal 
of the SM and this will need to go through several phases of the JEP 
process before it can be targeted to a specific release.


I'm sure many of the Jakarta EE platform dev members have code 
repositories to offer for scanning to aide in determining when the 
SecurityManager dependencies have been removed. If there is a avenue for 
that information, please let me know.


Thanks for that offer. I don't have an avenue for that information yet, 
but I will see if we can start creating a list of significant SM-enabled 
libraries and other projects that we can monitor over time.


--Sean


Thanks,
Scott

On Apr 26, 2022 at 11:09:22 AM, Sean Mullan > wrote:

Hello Scott,

On 4/25/22 2:25 PM, Scott Stark wrote:

Hello,

I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev
group (EEPD). I'm currently coordinating the Jakarta EE 10 release that
is targeting June of this year (2022). The removal of the
SecurityManager as described in JEP-411 has been a topic for the EEPD on
may calls this year. Recent discussions make it clear that any
SecurityManager alternative would need to be taken up by the EEPD, and
such an effort is going to be a non-trivial undertaking, and may not be
addressed at all.

A general concern among vendors in the EEPD is the timeframe for the
code that bridges between the JVM running with and without a
SecurityManager instance needing to be updated. Such code is the subject
of this JEP-411 paragraph:

"In feature releases after Java 18, we will degrade other Security
Manager APIs so that they remain in place but with limited or no
functionality. For example, we may revise AccessController::doPrivileged
simply to run the given action, or revise System::getSecurityManager
always to return null. This will allow libraries that support the
Security Manager and were compiled against previous Java releases to
continue to work without change or even recompilation. We expect to
remove the APIs once the compatibility risk of doing so declines to an
acceptable level."

Of particular interest is the timeframe for "remove the APIs once the
compatibility risk of doing so declines to an acceptable level".

Vendors in EEPD would like to see Java SE 21 ship with a migration
feature along the lines of the proposed "AccessController::doPrivileged
simply to run the given action, or revise System::getSecurityManager
always to return null" behaviors.


Can you clarify what you mean by "a migration feature" and also provide
some background as to why vendors in EEPD would like to see this? Do you
mean something like a system property that enables the degraded behavior
as described above?


Is there some metric for tracking "when the compatibility risk of doing
so declines to an acceptable level."? I believe the EEPD vendors would
like readiness of their projects and upstream dependencies to somehow be
included in any such tracking.


So, first we do not yet have a proposed target date for when we would
like to remove support for the Security Manager (SM) from the JDK. By
removing support, I mean that the JDK would no longer include a SM
implementation. However, I don't anticipate that any SM specific APIs
would be degraded *prior* to removing SM support from the JDK.

Some APIs will likely be degraded as described above at the same time we
remove support for the SM from the JDK.

As for when the APIs will actually be removed, this will most likely be
a longer period, possibly several JDK releases. We recognize that many
libraries and applications will 

Re: Timeframe for JEP-411 completely removing SecurityManager APIs

[Sean Mullan]

Hello Scott,

On 4/25/22 2:25 PM, Scott Stark wrote:

Hello,

I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev 
group (EEPD). I'm currently coordinating the Jakarta EE 10 release that 
is targeting June of this year (2022). The removal of the 
SecurityManager as described in JEP-411 has been a topic for the EEPD on 
may calls this year. Recent discussions make it clear that any 
SecurityManager alternative would need to be taken up by the EEPD, and 
such an effort is going to be a non-trivial undertaking, and may not be 
addressed at all.


A general concern among vendors in the EEPD is the timeframe for the 
code that bridges between the JVM running with and without a 
SecurityManager instance needing to be updated. Such code is the subject 
of this JEP-411 paragraph:


"In feature releases after Java 18, we will degrade other Security 
Manager APIs so that they remain in place but with limited or no 
functionality. For example, we may revise AccessController::doPrivileged 
simply to run the given action, or revise System::getSecurityManager 
always to return null. This will allow libraries that support the 
Security Manager and were compiled against previous Java releases to 
continue to work without change or even recompilation. We expect to 
remove the APIs once the compatibility risk of doing so declines to an 
acceptable level."


Of particular interest is the timeframe for "remove the APIs once the 
compatibility risk of doing so declines to an acceptable level".


Vendors in EEPD would like to see Java SE 21 ship with a migration 
feature along the lines of the proposed "AccessController::doPrivileged 
simply to run the given action, or revise System::getSecurityManager 
always to return null" behaviors.


Can you clarify what you mean by "a migration feature" and also provide 
some background as to why vendors in EEPD would like to see this? Do you 
mean something like a system property that enables the degraded behavior 
as described above?


Is there some metric for tracking "when the compatibility risk of doing 
so declines to an acceptable level."? I believe the EEPD vendors would 
like readiness of their projects and upstream dependencies to somehow be 
included in any such tracking.


So, first we do not yet have a proposed target date for when we would 
like to remove support for the Security Manager (SM) from the JDK. By 
removing support, I mean that the JDK would no longer include a SM 
implementation. However, I don't anticipate that any SM specific APIs 
would be degraded *prior* to removing SM support from the JDK.


Some APIs will likely be degraded as described above at the same time we 
remove support for the SM from the JDK.


As for when the APIs will actually be removed, this will most likely be 
a longer period, possibly several JDK releases. We recognize that many 
libraries and applications will need time to adapt to the changes and 
remove dependencies on the APIs. We have tools that check open source 
repositories for API dependencies and are able to provide us with data 
that helps assess the compatibility risk. However, I can't give you a 
timeframe for API removal yet.


HTH,
Sean

Timeframe for JEP-411 completely removing SecurityManager APIs

[Scott Stark]

Hello,

I'm Scott Stark of Red Hat, and a member of the Jakarta EE platform dev
group (EEPD). I'm currently coordinating the Jakarta EE 10 release that is
targeting June of this year (2022). The removal of the SecurityManager as
described in JEP-411 has been a topic for the EEPD on may calls this year.
Recent discussions make it clear that any SecurityManager alternative would
need to be taken up by the EEPD, and such an effort is going to be a
non-trivial undertaking, and may not be addressed at all.

A general concern among vendors in the EEPD is the timeframe for the code
that bridges between the JVM running with and without a SecurityManager
instance needing to be updated. Such code is the subject of this JEP-411
paragraph:

"In feature releases after Java 18, we will degrade other Security Manager
APIs so that they remain in place but with limited or no functionality. For
example, we may revise AccessController::doPrivileged simply to run the
given action, or revise System::getSecurityManager always to return null.
This will allow libraries that support the Security Manager and were
compiled against previous Java releases to continue to work without change
or even recompilation. We expect to remove the APIs once the compatibility
risk of doing so declines to an acceptable level."

Of particular interest is the timeframe for "remove the APIs once the
compatibility risk of doing so declines to an acceptable level".

Vendors in EEPD would like to see Java SE 21 ship with a migration feature
along the lines of the proposed "AccessController::doPrivileged simply to
run the given action, or revise System::getSecurityManager always to return
null" behaviors.

Is there some metric for tracking "when the compatibility risk of doing so
declines to an acceptable level."? I believe the EEPD vendors would like
readiness of their projects and upstream dependencies to somehow be
included in any such tracking.

Thanks,
Scott Stark