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

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