Hi Juan Pablo,

 Here’s the PR:
https://github.com/apache/jspwiki/pull/402

<https://github.com/apache/jspwiki/pull/402>
cheers

Arturo


On Sat, Oct 11, 2025 at 12:27 PM Juan Pablo Santos Rodríguez <
[email protected]> wrote:

> Hi!
>
> Jürgen you made a very good point indeed, there's no need to tackle the
> SecurityManager stuff right now for 3.0, the same problem sits for 2.12, so
> it's nothing new.
>
> I'd do like to remove the method on the Session API, though, so we don't
> have to change 3.x with 4.x only b/c of that. I doubt it has use outside
> JSPWiki itself, and will have to go anyway. I'll try to do that this week
> and prepare 3.x for releade, if no one does it before.
>
> Cheers,
> juan pablo
>
> El sáb, 4 oct 2025, 2:03, Murray Altheim <[email protected]> escribió:
>
> > +1, strongly agree. It's a big version change, time to not worry too
> > much about backwards compatibility. I'd guess more people would be
> > interested in a major upgrade (in functionality, security, compatibility
> > with current tech) than would be worried about backwards compatibility.
> > I don't have any sense of how many users are actually using custom
> > plugins, but I'd think for many (if not most) they'd simply copy their
> > wiki page directory over to the new version and they'd be good to go.
> >
> > I do like the idea of abandoning what is now effectively a bespoke
> > security solution and going with what's compatible with JDK-25. In 2025
> > I think that better integrating with contemporary work environments is
> > a big win.
> >
> > M.
> >
> > On 4/10/25 08:48, Jürgen Weber wrote:
> > > Hi,
> > >
> > > Tomcat 10.0.0 was released 2020-12-08. Now almost five years later we
> > > should finally release the  Jakarta migration as 3.0. So users can
> > > move on to Tomcat 10.1.46 or JBoss EAP 8. Tomcat have released 73 fix
> > > versions since 10.0.0.
> > > Removing Security Manager stuff is a big change, way bigger than
> > > Jakarta which basically was a trivial change. Still JSPWIKI-1170 took
> > > over three years.
> > > Let's not wait again. Let's get out 3.0 now and do all further changes
> > for 3.1.
> > >
> > > Cheers,
> > > Juergen
> > >
> > > Am Fr., 3. Okt. 2025 um 21:16 Uhr schrieb Juan Pablo Santos Rodríguez
> > > <[email protected]>:
> > >>
> > >> Hi!
> > >>
> > >> just to clarify, there are two topics here:
> > >>
> > >> 1.- Deleting a method from a class in jspwiki-api: given that, by
> > >> [#1], changes in there are reserved for major versions, and the
> > >> proposed deletion is hardly used and, as a fact, needs to be removed
> > >> in the future b/c affected classes will not exist in the JDK, my
> > >> proposal is to delete that method now. AIUI, this would hardly give a
> > >> headache to anyone.
> > >>
> > >> 2.- Security Manager stuff: talking about first point, why not go and
> > >> remove ALL the security manager related code for 3.0.0. That would
> > >> make it JDK-25 compatible. JSPWiki security is indeed built around the
> > >> Security Manager (f.ex the policy files), but not around all the
> > >> classes that are going away. JSPWiki relies on a global policy (1), if
> > >> set, through the SM, and if not present defaults to the local policy
> > >> (2). Reading the code, seems that this second part is still supported
> > >> in JDK-25. I suspect that very few people are using the global
> > >> security manager, while the rest delegate on the local policies, so
> > >> that ought to be another not-so-annoying breaking change, which
> > >> affects a small minority. I want to make a quick test of removing the
> > >> deprecated code and seeing how JSPWiki security behaves. If it still
> > >> works as expected, keep that, if not, it would be a major PITA,
> > >> requiring much more attention, and would not be on scope for 3.0.0.
> > >>
> > >> Also, we have a long outstanding,
> > >> https://issues.apache.org/jira/browse/JSPWIKI-129 which was logged to
> > >> make JSPWiki run under a Security Manager, meaning that "an effective
> > >> policy cannot be written".
> > >>
> > >> Anyway, I'll dig a bit and see where do I get (anyone with a bit of
> > >> spare time to also look at this would be very welcome O:-)).
> > >>
> > >> cheers,
> > >> juan pablo
> > >>
> > >> [#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=VersioningProposal
> > >>
> > >> On Wed, Oct 1, 2025 at 2:22 PM Alex O'Ree <[email protected]>
> wrote:
> > >>>
> > >>> My complaint is that jspwiki reads in and parses the web.xml file at
> > bootup
> > >>> to get the security roles. Anything not listed is ignored. This could
> > be a
> > >>> bit more dynamic. Servlet request.isUserInRole is all we really need
> > >>> instead of all the caching and middlewear code in the middle. Makes
> it
> > hard
> > >>> for users backed by ldap to quickly and easily add new roles,
> > especially in
> > >>> a docker container
> > >>>
> > >>> On Wed, Oct 1, 2025, 7:32 AM Arturo Bernal <[email protected]>
> wrote:
> > >>>
> > >>>> I think JSPWiki’s security is JAAS/container-managed with our
> > >>>> Permission/ACL layer; it isn’t built on the JDK SecurityManager. The
> > only
> > >>>> SM-adjacent touchpoint is the deprecated Session#doPrivileged(...)
> > >>>> wrapper—barely used and not on the auth/ACL path—so 3.0.0 is the
> > right time
> > >>>> to drop it and document.
> > >>>>
> > >>>> Arturo
> > >>>>
> > >>>>
> > >>>> On Wed, Oct 1, 2025 at 12:02 PM Jürgen Weber <[email protected]>
> > wrote:
> > >>>>
> > >>>>> I believe the jspwiki Security is built around the SecurityManager,
> > isn't
> > >>>>> it?
> > >>>>> Removing the dependency is better for 3.1
> > >>>>>
> > >>>>> Arturo Bernal <[email protected]> schrieb am Mi., 1. Okt. 2025,
> > 11:37:
> > >>>>>
> > >>>>>> Hi All,
> > >>>>>>
> > >>>>>> +1 (binding). 3.0.0 is the right line in the sand: remove the
> > Security
> > >>>>>> Manager–dependent API and other long-deprecated code, finish the
> > >>>>>> javax→Jakarta cleanup, and baseline JDK 17
> > >>>>>>
> > >>>>>> cheers,
> > >>>>>> Arturo
> > >>>>>>
> > >>>>>>
> > >>>>>> Arturo
> > >>>>>>
> > >>>>>>
> > >>>>>> On Tue, Sep 30, 2025 at 8:52 PM Juan Pablo Santos Rodríguez <
> > >>>>>> [email protected]> wrote:
> > >>>>>>
> > >>>>>>> Hi!
> > >>>>>>>
> > >>>>>>> While going through the code I've noticed that jspwiki-api not
> only
> > >>>>>>> contained a method relying on javax, thus implying a major
> > version),
> > >>>>>>> but there's also a method [#1] which uses classes from the
> Security
> > >>>>>>> Manager, marked Deprecated and for removal at a latter version
> > (done
> > >>>>>>> in JDK-24, IIRC). This method is barely used throughout the code,
> > and
> > >>>>>>> I suspect is less used on third party extensions.
> > >>>>>>>
> > >>>>>>> As such, I'd like to remove it from the jspwiki-api module, so we
> > >>>>>>> avoid a breaking change in a future release, and also remove the
> > rest
> > >>>>>>> of the related deprecated code throughout the code base.
> > >>>>>>>
> > >>>>>>> This way JSPWiki should be able to run using JDK 17 to 25.
> > Thoughts?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> cheers,
> > >>>>>>> juan pablo
> > >>>>>>>
> > >>>>>>> [#1]:
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> >
> https://github.com/apache/jspwiki/blob/master/jspwiki-api/src/main/java/org/apache/wiki/api/core/Session.java#L240-L252
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >
> >
> > --
> >
> >
> ...........................................................................
> > Murray Altheim <murray18 at altheim dot com>                       = =
> ===
> > http://www.altheim.com/murray/                                     ===
> > ===
> >                                                                     = =
> > ===
> >      In the evening
> >      The rice leaves in the garden
> >      Rustle in the autumn wind
> >      That blows through my reed hut.
> >             -- Minamoto no Tsunenobu
> >
> >
> >
>

Reply via email to