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

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?

> >> >> >>> >>> >>>> 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