Re: blizzard of deprecation warnings related to JEP 411
On 6/17/21 4:56 AM, Alan Bateman wrote:
On 17/06/2021 00:30, Rick Hillegas wrote:
Thanks for that advice, Alan. I have rototilled
@SuppressWarnings("removal") annotations across the Derby codebase
and thrown more memory at javadoc so that it won't crash on JDK 11.
When I run Derby's test suites, I see a blizzard of the following
diagnostics:
WARNING: java.lang.System::setSecurityManager is deprecated and
will be removed in a future release.
Unfortunately, Derby still has more than 100 canon-based tests which
were developed before assertion-based testing became the norm. These
tests are run both with and without a security manager. In the latter
case, they now fail on JDK 17.
Is there a way to disable this diagnostic?
Even better: Could the diagnostic be removed in the next Open JDK
build? It could be re-introduced when Open JDK provides a replacement
for the deprecated functionality. Right now the diagnostic does not
seem to provide any actionable information.
I assume the OOME with javadoc isn't anything to do with this JEP or
the @SupressWarnings annotations, right?
I stopped investigating the problem after I found that I could work
around it by giving javadoc more memory. All I can report is the following:
1) The extra annotations caused the JDK 11 javadoc tool to run out of
memory.
2) The extra annotations did NOT cause the JDK 17 javadoc tool to run
out of memory.
There isn't any way to suppress the warning. This warning is sending a
clear message that that setSecurityManager will be removed in the
future. The "Illegal reflective access" warnings in JDK 9-15 set the
precedent.
For applications that do set a security manager then it is more likely
that they set it once, at startup, rather than setting it hundreds of
times in a running VM. Does Derby call setSecurityManager itself?
The Derby network server installs a security manager if the DBA doesn't.
With some effort, users can override this behavior. This behavior dates
back to 2007 and was introduced by Derby release 10.3.1.4. At that time,
developers from IBM and Sun Microsystems (the major players in the Derby
community) agreed that the client-server configuration should be "secure
by default."
At least in the embedded case then I wouldn't expect it does as it
will be up to the application to do that if it wants. Clearly Derby
has tests to ensure that it can work with a SM so I assume its the
tests that are calling setSecurityManager. I'm not familar with the
term "canon-based tests" but I'm guessing that these are tests that
run with and without SM and are somehow sensitive to the stderr
stream, is that right?
Canon-based testing is an old black-box testing pattern in which you do
the following:
1) Run a test script through a Read-Evaluate-Print-Loop tool.
2) Collect the console output (stdout + stderr).
3) Compare the actual output to a file of expected output (the canon).
There were a small number of these in the JDK test suite too, but not
many.
-Alan
Re: blizzard of deprecation warnings related to JEP 411
On 17/06/2021 00:30, Rick Hillegas wrote:
Thanks for that advice, Alan. I have rototilled
@SuppressWarnings("removal") annotations across the Derby codebase and
thrown more memory at javadoc so that it won't crash on JDK 11. When I
run Derby's test suites, I see a blizzard of the following diagnostics:
WARNING: java.lang.System::setSecurityManager is deprecated and will
be removed in a future release.
Unfortunately, Derby still has more than 100 canon-based tests which
were developed before assertion-based testing became the norm. These
tests are run both with and without a security manager. In the latter
case, they now fail on JDK 17.
Is there a way to disable this diagnostic?
Even better: Could the diagnostic be removed in the next Open JDK
build? It could be re-introduced when Open JDK provides a replacement
for the deprecated functionality. Right now the diagnostic does not
seem to provide any actionable information.
I assume the OOME with javadoc isn't anything to do with this JEP or the
@SupressWarnings annotations, right?
There isn't any way to suppress the warning. This warning is sending a
clear message that that setSecurityManager will be removed in the
future. The "Illegal reflective access" warnings in JDK 9-15 set the
precedent.
For applications that do set a security manager then it is more likely
that they set it once, at startup, rather than setting it hundreds of
times in a running VM. Does Derby call setSecurityManager itself? At
least in the embedded case then I wouldn't expect it does as it will be
up to the application to do that if it wants. Clearly Derby has tests to
ensure that it can work with a SM so I assume its the tests that are
calling setSecurityManager. I'm not familar with the term "canon-based
tests" but I'm guessing that these are tests that run with and without
SM and are somehow sensitive to the stderr stream, is that right? There
were a small number of these in the JDK test suite too, but not many.
-Alan
Re: blizzard of deprecation warnings related to JEP 411
Hi Rick This is dependant on OpenJDK creating hooks in JVM code for existing permission's without depending existing Security infrastructure. The major components can be found here, also available on Maven: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/SecurityContext.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java Regards, Peter. On 17/06/2021 1:00 am, Rick Hillegas wrote: Thanks, Peter. Derby supports a couple authorization mechanisms, the most important one being the role-based SQL Standard GRANT/REVOKE commands (see https://db.apache.org/derby/docs/10.15/security/csecauthorization.html). I'm afraid that my old eyes didn't see a link to your authorization libraries in your message. On 6/15/21 5:23 PM, Peter Firmstone wrote: Rick, Out of curiosity, does Apache Derby have a need for an Authorization layer? We have tooling to generate our policy files, which simplifies the process a lot, we also have highly scalable and performant SecurityManager and Policy implementations which are compatible with standard Java policy files. This is available under an AL2.0 license. I'm hoping that OpenJDK will create some hooks for permission checks, so that we can continue to provide an authorization layer for Java, following JEP 411. I'll be using StackWalker to reproduce AccessController's stack walk. We also have existing classes which wrap AccessControlContext, so we would use ThreadLocal's to preserve subject. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd.
Re: blizzard of deprecation warnings related to JEP 411
Thanks for that advice, Alan. I have rototilled
@SuppressWarnings("removal") annotations across the Derby codebase and
thrown more memory at javadoc so that it won't crash on JDK 11. When I
run Derby's test suites, I see a blizzard of the following diagnostics:
WARNING: java.lang.System::setSecurityManager is deprecated and will
be removed in a future release.
Unfortunately, Derby still has more than 100 canon-based tests which
were developed before assertion-based testing became the norm. These
tests are run both with and without a security manager. In the latter
case, they now fail on JDK 17.
Is there a way to disable this diagnostic?
Even better: Could the diagnostic be removed in the next Open JDK build?
It could be re-introduced when Open JDK provides a replacement for the
deprecated functionality. Right now the diagnostic does not seem to
provide any actionable information.
On 6/15/21 8:56 AM, Alan Bateman wrote:
On 15/06/2021 15:10, Rick Hillegas wrote:
:
When I tried to build Derby with the Rampdown Phase One build of open
JDK 17 (17-ea+26-2439), I saw many warnings related to the
deprecation of Security Manager classes and methods, undoubtedly the
consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby,
like Tomcat, embraced the Security Manager early on. Permissions
checks were rototilled across the whole code base and our
distributions ship with several template policy files, which we
encourage users to customize for their environments. The "Configuring
Java Security" section of our Security Guide explains how to do this
(https://db.apache.org/derby/docs/10.15/security/index.html).
My build only reported the first 100 warnings. It is likely that
there are many more.
Yes, JEP 411 deprecates a number of APIs for future removal. There
probably isn't much to do right now except to be aware that the APIs
are earmarked for removal in some future release. I've no doubt there
will be another JEP when that time comes. I assume you know about
@SuppressWarnings("removal"), which you can use to suppress the
warnings for now. The JDK usages of these APIs are using
SuppressWarnings as the JDK is compiled with -Xlint set to made
warnings fatal.
-Alan
Re: blizzard of deprecation warnings related to JEP 411
Thanks, Peter. Derby supports a couple authorization mechanisms, the most important one being the role-based SQL Standard GRANT/REVOKE commands (see https://db.apache.org/derby/docs/10.15/security/csecauthorization.html). I'm afraid that my old eyes didn't see a link to your authorization libraries in your message. On 6/15/21 5:23 PM, Peter Firmstone wrote: Rick, Out of curiosity, does Apache Derby have a need for an Authorization layer? We have tooling to generate our policy files, which simplifies the process a lot, we also have highly scalable and performant SecurityManager and Policy implementations which are compatible with standard Java policy files. This is available under an AL2.0 license. I'm hoping that OpenJDK will create some hooks for permission checks, so that we can continue to provide an authorization layer for Java, following JEP 411. I'll be using StackWalker to reproduce AccessController's stack walk. We also have existing classes which wrap AccessControlContext, so we would use ThreadLocal's to preserve subject.
Re: blizzard of deprecation warnings related to JEP 411
Rick,
Out of curiosity, does Apache Derby have a need for an Authorization layer?
We have tooling to generate our policy files, which simplifies the
process a lot, we also have highly scalable and performant
SecurityManager and Policy implementations which are compatible with
standard Java policy files.
This is available under an AL2.0 license.
I'm hoping that OpenJDK will create some hooks for permission checks, so
that we can continue to provide an authorization layer for Java,
following JEP 411.
I'll be using StackWalker to reproduce AccessController's stack walk.
We also have existing classes which wrap AccessControlContext, so we
would use ThreadLocal's to preserve subject.
--
Regards,
Peter.
On 16/06/2021 1:56 am, Alan Bateman wrote:
On 15/06/2021 15:10, Rick Hillegas wrote:
:
When I tried to build Derby with the Rampdown Phase One build of open
JDK 17 (17-ea+26-2439), I saw many warnings related to the
deprecation of Security Manager classes and methods, undoubtedly the
consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby,
like Tomcat, embraced the Security Manager early on. Permissions
checks were rototilled across the whole code base and our
distributions ship with several template policy files, which we
encourage users to customize for their environments. The "Configuring
Java Security" section of our Security Guide explains how to do this
(https://db.apache.org/derby/docs/10.15/security/index.html).
My build only reported the first 100 warnings. It is likely that
there are many more.
Yes, JEP 411 deprecates a number of APIs for future removal. There
probably isn't much to do right now except to be aware that the APIs
are earmarked for removal in some future release. I've no doubt there
will be another JEP when that time comes. I assume you know about
@SuppressWarnings("removal"), which you can use to suppress the
warnings for now. The JDK usages of these APIs are using
SuppressWarnings as the JDK is compiled with -Xlint set to made
warnings fatal.
-Alan
Re: blizzard of deprecation warnings related to JEP 411
On 15/06/2021 15:10, Rick Hillegas wrote:
:
When I tried to build Derby with the Rampdown Phase One build of open
JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation
of Security Manager classes and methods, undoubtedly the consequence
of JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat,
embraced the Security Manager early on. Permissions checks were
rototilled across the whole code base and our distributions ship with
several template policy files, which we encourage users to customize
for their environments. The "Configuring Java Security" section of our
Security Guide explains how to do this
(https://db.apache.org/derby/docs/10.15/security/index.html).
My build only reported the first 100 warnings. It is likely that there
are many more.
Yes, JEP 411 deprecates a number of APIs for future removal. There
probably isn't much to do right now except to be aware that the APIs are
earmarked for removal in some future release. I've no doubt there will
be another JEP when that time comes. I assume you know about
@SuppressWarnings("removal"), which you can use to suppress the warnings
for now. The JDK usages of these APIs are using SuppressWarnings as the
JDK is compiled with -Xlint set to made warnings fatal.
-Alan
blizzard of deprecation warnings related to JEP 411
Resending this message from the account associated with my security-dev subscription, in the hope that this will bypass moderation: Rory O'Donnell recommended that I bring this issue to the security developers' mailing list. I work on Apache Derby. Derby is one of the applications which receive advance notice of new Open JDK distributions. We then build our application with the new JDK's javac and javadoc tools and we run our full test suite against the new JVM. As a canary in the mineshaft, we noticed the following significant disruption. When I tried to build Derby with the Rampdown Phase One build of open JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation of Security Manager classes and methods, undoubtedly the consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, embraced the Security Manager early on. Permissions checks were rototilled across the whole code base and our distributions ship with several template policy files, which we encourage users to customize for their environments. The "Configuring Java Security" section of our Security Guide explains how to do this (https://db.apache.org/derby/docs/10.15/security/index.html). My build only reported the first 100 warnings. It is likely that there are many more. Having read the summary of JEP 411, I understand the motivation for this change. However, I don't understand how applications like Tomcat and Derby are supposed to respond to the new blizzard of deprecation warnings. For instance, is there a replacement for the deprecated AccessController.doPrivileged() method? Or are we supposed to simply disable this deprecation check? Is there some security expert whom I should contact about this change and how to mitigate its effects? Thanks, -Rick
