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

On Thu, Nov 21, 2024 at 9:40 AM 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 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. > Unfortunately WildFlySecurityManager is a subclass of SecurityManager. So *eventually* any use of it must be guarded. > >> >> >>> >>>> >>>> >>>>> >>>>> >>>>>> 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 >> > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His