Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3]

[Xue-Lei Andrew Fan]

On Sat, 30 Apr 2022 03:46:23 GMT, Bradford Wetmore  wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   comment about remove finalize() method
>
> src/java.base/share/classes/sun/security/ssl/BaseSSLSocketImpl.java line 265:
> 
>> 263: }
>> 264: 
>> 265: /**
> 
> Can you please add a quick couple lines here with the technical rationale for 
> removing it, so we don't forget down the road.
> 
> i.e.
> 
> There used to be a finalize() here, but decided that was not
> needed.  If users don't properly close the socket...
> 
> The native resources are handled by the Socket Cleaner.

It may be not common to comment on non-existing method.  Maybe,  the class 
description could be a place to add this note.

-

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

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v2]

[Xue-Lei Andrew Fan]

On Wed, 27 Apr 2022 06:55:42 GMT, Xue-Lei Andrew Fan  wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - typo blank linke correction
>>  - revise the update
>
> ping ...

> @XueleiFan, would you please add a note to the bug itself with the 
> end-result, and a quick note in the place of the finalizer a quick summary of 
> what we decided.

Sure. Notes were added in JBS and the patch.

-

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

Re: RFR: 8212136: Remove BaseSSLSocketImpl finalizer method [v3]

[Xue-Lei Andrew Fan]

> Please review the update to remove finalizer method in the SunJSSE provider 
> implementation.  It is one of the efforts to clean up the use of finalizer 
> method in JDK.

Xue-Lei Andrew Fan has updated the pull request incrementally with one 
additional commit since the last revision:

  comment about remove finalize() method

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8065/files
  - new: https://git.openjdk.java.net/jdk/pull/8065/files/ccfc42da..c90e25a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8065=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8065=01-02

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

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

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: RFR: JDK-8285263 Minor cleanup could be done in java.security [v3]

[Mark Powers]

> https://bugs.openjdk.java.net/browse/JDK-8285263 Minor cleanup could be done 
> in java.security
> 
> JDK-8273046 is the umbrella bug for this bug. The changes were too large for 
> a single code review, so it was decided to split into smaller chunks. This is 
> one such chunk: 
> 
> open/src/java.base/share/classes/java/security

Mark Powers has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains seven commits:

 - third iteration
 - Merge
 - Merge
 - second iteration
 - Merge
 - Merge
 - first iteration

-

Changes: https://git.openjdk.java.net/jdk/pull/8319/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8319=02
  Stats: 639 lines in 96 files changed: 25 ins; 140 del; 474 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8319.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8319/head:pull/8319

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