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

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

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.

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

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

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

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

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

Hello Brian Speaking for Weld codebase, I have already removed SM references for the upcoming Weld 6 (EE 11, CDI 4.1) some time ago. Here's the Weld issue - https://issues.redhat.com/browse/WELD-2789 And the PR - https://github.com/weld/core/pull/2983 I did that based on the fact that EE 11 states that it removes all use of SM as one of its key changes ( https://jakarta.ee/specifications/platform/11/). Plus, I am also aware of the WFLY issue that aimed to fail boot in EE 11 if SM was detected - https://issues.redhat.com/browse/WFLY-19287 However, based on your email, it seems that this is a problem for WFLY but I am failing to see why. If EE 11 doesn't aim to support SM, why do we need to keep it in future WFLY versions? Regards Matej On Tue, Nov 19, 2024 at 4:27 PM 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... > _______________________________________________ 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...