[wildfly-dev] Re: Disabling of Security Manager in latest SE 24

James R. Perkins Principal Software Engineer Red Hat <https://www.redhat.com/> <https://www.redhat.com/> On Wed, Nov 20, 2024 at 5:13 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Wed, Nov 20, 2024 at 7:11 PM James Perkins <jperkins(a)redhat.com&gt; > wrote: > >> >> >> James R. Perkins >> >> Principal Software Engineer >> >> Red Hat <https://www.redhat.com/> >> <https://www.redhat.com/> >> >> >> On Wed, Nov 20, 2024 at 3:20 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Wed, Nov 20, 2024 at 3:29 AM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> On Tue, Nov 19, 2024 at 8:17 PM Richard Opalka <ropalka(a)redhat.com&gt; >>>> wrote: >>>> >>>>> I agree with all that has been said above. >>>>> We should also start preparing our users for the upcoming future >>>>> without Security Manager >>>>> and start deprecating (for "removal") affected APIs, specifically >>>>> affected classes, methods & fields >>>>> to let them know in advance there will be no alternative. >>>>> >>>> >>>> I think we need to be a little bit cautious on this one and I think >>>> this goes back to the trigger for Brian starting this thread. >>>> >>>> The more we bombard projects with deprecation warnings when they use >>>> our APIs the more they will want to get ahead and remove the >>>> security manager integration from their project. >>>> >>>> Until WildFly moves to a minimum JDK version of Java 25 or moves to a >>>> minimum Jakarta EE version of 11 or later it is quite possible that these >>>> security manager integrations will remain required for libraries integrated >>>> in WildFly (unless exclusively used for Jakarta EE 11 or later). >>>> >>> >>> +1. >>> >>> We should also have clear best practices in place before we give any >>> signals that people should change things. Particularly for the case where >>> people need to compile against SE versions where the SM classes are present >>> but may run in ones where they are not. For example how to efficiently >>> replace the class 'if (System.getSecurityManager() != null)' or 'if >>> (WildFlySecurityManager.isChecking())' guards with something that will work >>> when there is no SecurityManager class at runtime. Maybe that's just a >>> matter of people starting those 'if' conditions with >>> 'Runtime.version().feature() >= 24 &&' or 'cachedResultOfVersionCheck &&'. >>> >> >> We do something like this with a Multi-Release JAR where in 24+ they >> methods are just no-ops. >> > > What project are you referring to? > It might not make sense, but I was thinking the WildFlySecurityManager. Basically, anything that interacts with the security manager would be a no-op.

> > >> >>> >>> >>>> >>>> >>>>> Due to time constraints It is not possible to do it all at once in >>>>> one major WildFly release in my opinion. >>>>> But the PARENT "SM deprecation" task should be created so we can >>>>> distribute its subtasks across upcoming WildFly releases. >>>>> >>>>> On Tue, Nov 19, 2024 at 7:09 PM Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 19, 2024 at 10:12 AM David Lloyd <david.lloyd(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> I would follow on and say that if you do happen to notice some >>>>>>> obscure security-related JDK API which produces an error starting on Java >>>>>>> 24, the simplest solution is to wrap it in a version check like this: >>>>>>> >>>>>>> if (Runtime.version().feature() < 24) { >>>>>>> // the call will work >>>>>>> } >>>>>>> >>>>>>> And make sure you are using CI to test on both <24 and >=24 in this >>>>>>> case. >>>>>>> >>>>>> >>>>>> +1. Testing on the latest SE, even EA releases, is really good >>>>>> practice. The next LTS release is less than a year away and for sure we'll >>>>>> get demand to support it. If you're testing routinely on the latest from SE >>>>>> you'll be ahead of the game. >>>>>> >>>>>> >>>>>>> On Tue, Nov 19, 2024 at 9:27 AM Brian Stansberry < >>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> tl;dr; Do not remove security manager calls from WildFly or its >>>>>>>> components! Not unless you want and are able to maintain a branch >>>>>>>> supporting them for many years. >>>>>>>> >>>>>>>> >>>>>>>> I don't know all the details, but from a few discussions I've seen >>>>>>>> in the last hour it seems that the promised removal of runtime support for >>>>>>>> the Security Manager[1] has landed in an SE 24 update. >>>>>>>> >>>>>>>> This change means in an SE 24 environment you can no longer enable >>>>>>>> the SM and it will fail if you try. So this will certainly affect our code >>>>>>>> that's meant to run on SE 24 and later; we'll need to adapt to not try and >>>>>>>> turn it on. >>>>>>>> >>>>>>>> What this *should not* mean is calls to SM-related APIs in SE will >>>>>>>> fail. They should still work; they just don't do any enforcement. This >>>>>>>> isn't some odd situation since for decades now the vast majority of calls >>>>>>>> to SM APIs don't result in enforcement -- because the user doesn't enable >>>>>>>> the SM. >>>>>>>> >>>>>>>> WildFly is going to support Java SE versions where the SM works >>>>>>>> for many many more years. It's only in the upcoming WF 35 that we're >>>>>>>> dropping support for SE 11. So who knows how much longer we'll need to >>>>>>>> support SE 21. >>>>>>>> >>>>>>>> If you break SM support in a component, that stream will no longer >>>>>>>> be usable in typical WF! >>>>>>>> >>>>>>>> We'll need to do things to prepare for the day when SM APIs are >>>>>>>> removed from SE and we shouldn't ignore that task. But please don't break >>>>>>>> things. >>>>>>>> >>>>>>>> Kudos to those of you like Richard Opalka and James Perkins who >>>>>>>> are keeping an eye on things and noticed this promptly. >>>>>>>> >>>>>>>> [1] https://openjdk.org/jeps/486 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Principal Architect, Red Hat JBoss EAP >>>>>>>> WildFly Project Lead >>>>>>>> He/Him/His >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>>> List Archives: >>>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> - DML • he/him >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Principal Architect, Red Hat JBoss EAP >>>>>> WildFly Project Lead >>>>>> He/Him/His >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>> List Archives: >>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>> List Archives: >>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His >