Spring Security upgrade from 5.x to 6.x

[Mark Waite]

The Spring project has announced that Spring Security 5.8.x and Spring Framework 5.3.x will be end of life on August 31, 2024.  Jenkins currently uses  Spring Security 5.8.x and Spring Framework 5.3.x.

Jenkins needs to upgrade to Spring Security 6.x.  Spring Security 6.x in Jenkins requires:

• Spring Framework 6.x which requires Java 17 and Jakarta EE 9

When Jenkins transitions from Jakarta EE 8 to Jakarta EE 9, we'll also need to use:

• Jetty 12
• Apache file uploader 2.x

Given the size of that change and its dependency on Java 17 as a minimum Jenkins version, I think that we want to switch Jenkins to require Java 17 as soon as possible after the last Java 11 LTS baseline is selected.

Proposed Timeline

• 26 Jun 2024 - Choose LTS baseline for last LTS to support Java 11
  
• 3 Jul 2024 - Require Java 17 in Jenkins weekly release
• 7 Aug 2024 -Last LTS.1 release to support Java 11 (likely 2.464.1)
• 31 Aug 2024 Spring Security 5.8.x public support ends
• 18 Sep 2024 - Choose LTS baseline to require Java 17
• 2 Oct 2024 - Last LTS.3 to support Java 11
• 30 Oct 2024 - First LTS.1 to require Java 17 (likely 2.476.1)

Basil prototyped the Jakarta EE 9 upgrade in August 2023.  The prototype showed that the bridge method injector may help with the transition.  The prototype showed that there is a lot of work to be done in order to upgrade Spring Security in Jenkins from 5.x to 6.x

I noted the timeline because I had initially assumed that we would transition Jenkins weekly to require Java 17 in late August or early September 2024.  Based on the large amount of work that is needed for the Spring Security upgrade from 5.x to 6.x, I think that we should require Java 17 the week after we've selected the baseline for the final LTS line that will support Java 11.

If you're willing to help with the Spring Security upgrade project, I'd love to have you respond to this email message.  If you have strong objections to the timeline, please respond with your concerns.

I will share more details as I learn more.

Thanks,

Mark Waite

[Basil Crow]

Based on my prototyping in JENKINS-73120, there is quite a bit of work
to support Jetty 12 (even just EE 8 with javax imports), blocked on
the requirement of Java 17. From my perspective the sooner we require
Java 17, the better. Perhaps we can require Java 17 in weeklies two
weeks earlier than planned, acknowledging that this creates two fewer
choices for LTS selection. Thoughts?

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4a260cec-dbe4-4b63-a9e6-7c17ebcbfaebn%40googlegroups.com.

[Mark Waite]

On Friday, May 10, 2024 at 12:51:46 PM UTC-6 Basil wrote:

Based on my prototyping in JENKINS-73120, there is quite a bit of work
to support Jetty 12 (even just EE 8 with javax imports), blocked on
the requirement of Java 17. From my perspective the sooner we require
Java 17, the better. Perhaps we can require Java 17 in weeklies two
weeks earlier than planned, acknowledging that this creates two fewer
choices for LTS selection. Thoughts?

I like the idea.  It would mean that the LTS baseline selected for the
last Jenkins LTS to support Java 11 would need to be two weeks earlier,
but we've chosen LTS baselines that were not the most recent weekly
before.

Mark Waite

[Tim Jacomb]

Sounds good to me

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/450e7eff-2c7b-4aba-a10a-979aa7dba9a2n%40googlegroups.com.

[Ivan Fernandez Calvo]

Please do it, I am waiting for this change to update the SAML plugin to the latest PAC4J version

[Bob Du]

Some thoughts on Apache file uploader 2.x

As far as I know, Apache file uploader 2.x has not been able to release the GA version and is still in the snapshot version status.

https://mvnrepository.com/artifact/commons-fileupload/commons-fileupload

In addition, the apache file uploader package name has been changed from org.apache.commons.fileupload to org.apache.commons.fileupload2
Introducing this upgrade would seem to run counter to our ongoing vision of reducing the API surface area of Jenkins core.

In addition, in version 1.3 of Apache file uploader, we used our own patch branch for a long time and did not reuse the upstream version until 1.4.

https://github.com/jenkinsci/jenkins/pull/5174

Is it possible to consider reverting our fork version and self-releasing fork file uploader 1.6 version using jakarta api

I tried this modification in my own repository

https://github.com/BobDu/commons-fileupload/pull/1/files

It looks like it compiles easily and passes the internal unit tests
Is this solution feasible?

[Basil Crow]

While still in milestone status, Commons FileUpload 2.x is being recommended on the project's home page and GitHub page, and hopefully it will reach GA this year. The Spring 5.3.x EOL will likely push the whole Java ecosystem toward Java EE 9+.

A custom fork of an actively maintained upstream project is a maintenance burden. My prototype shows that we can maintain compatibility with plugins across the package rename with a handful of bridge methods. Once those (few) plugins are migrated to the new package name, the bridge methods can be deleted, resulting in a lateral move in API surface area (removal of 1.x and addition of 2.x) rather than an increase (addition of 2.x to the existing 1.x).

In the long term, API surface area can be decreased by removing this library altogether. Multipart file upload is built into the servlet spec since 3.1 via the HttpServletRequest#getPart() API. That is a bit of a more involved project (in the sense of being less of a mechanical rename and more of a logical rewrite of the relevant code) to redesign the relevant Jenkins APIs in Stapler and core and migrate core and plugins to these new APIs. A medium-term migration from Commons FileUpload 1.x to 2.x in no way precludes this long-term strategy.

[evernat]

When speaking of migrating Jenkins to Jakarta EE/jakarta.servlet api, a number of Jenkins plugins depends on the javax.servlet api, either in their code or in their dependencies. They will need to migrate too, except there is an automatic compatibility or migration tool like "<Loader jakartaConverter="TOMCAT" />".

Perhaps a first list of plugins to migrate could be made by looking usage of javax.servlet.http.HttpServletRequest and other classes in plugins with https://github.com/jenkins-infra/usage-in-plugins

For one, the monitoring plugin 1.x depends on the javax.servlet api. I can migrate it to the jakarta.servlet api in monitoring plugin 2.x including upgrade of dependency.

And I suppose that "jenkins.version" in pom.xml of the plugin could be used to set the Jenkins required version of the migrated version of the plugin.

In case that the plugin is not upgraded at the same time that Jenkins is upgraded by the user, the plugin will probably break by throwing ClassNotFound / NoClassDefFound, for example when loading the PluginImpl class in the monitoring plugin.

Emeric

[Bob Du]

I see. 

As stated above Spring Security 5.x EOL deadline. We have until August 31, 2024 to move to jakarta api.

To be honest, I have doubts about whether commons-uploadfile can release the 2.x GA version within 3 months. Then we have to think about a problem in advance. If there is no 2.x GA version yet, do we ship a snapshot version of commons-uploadfile 2.x in Jenkins?

In addition, I tried to count the code size of commons-uploadfile and found that there were only 41 valid java files and 2503 lines of valid code. (using the cloc tool analysis, a npm package). Not very huge.  The maintenance burden of using the fork version as a transitional stage in the short term will not be too heavy.

If we once reach a consensus on the long-term goal - to remove the dependency on commons-uploadfile in jenkins. So as a short-term solution, forking and maintaining a commons-uploadfile seems to be a low cost solution. Focus more engineering energy on long-term goals.

I am willing to contribute code to achieve this long-term goal.

[Basil Crow]

Unlike snapshot releases, milestone releases are tagged and published
in Maven Central, so I don't see any issues with upgrading to 2.0.0-M2
immediately. In practice, if a Commons FileUpload v2 API did change
between now and GA, it wouldn't be too much work to adapt the few
plugins that consume it. We routinely adapt small sets of plugins here
and there when there are breaking UI changes.

It would be nice to see someone explore the details of removing
Commons FileUpload entirely. Most of the Jenkins APIs that refer to
Commons FileUpload are in Stapler, with consumers in core and plugins.
A good starting point would be to reimplement Stapler, core, and at
least one plugin without Commons FileUpload. That would provide a
broad range of producers and consumers to validate any API changes.
The Testing Done section of
https://github.com/jenkinsci/jenkins/pull/5174 highlights the main
consumers throughout the ecosystem.

[Basil Crow]

On Sat, May 11, 2024 at 8:43 PM Bob Du <ggb...@gmail.com> wrote:
>
> I am willing to contribute code to achieve this long-term goal.

Great! I have filed https://issues.jenkins.io/browse/JENKINS-73169
with more details about this long-term removal, explaining the
reasoning behind the removal, the relevant portions of our integration
guidelines, and a suggested implementation strategy that spans
Stapler, core, and plugins.

[Basil Crow]

On Sat, May 11, 2024 at 1:34 AM Ivan Fernandez Calvo
<kuisat...@gmail.com> wrote:
>
> Please do it, I am waiting for this change to update the SAML plugin to the latest PAC4J version

Your wish is my command, Ivan! As discussed at the last governance
board meeting, we are going to do it in a weekly release before the
end of June. I plan to release a new version of jenkinsci/pom with
maven.compiler.release set to 17 and adopt it in core and all core
components, producing a weekly release that requires Java 17 bytecode.
I will try to retain Java 11 bytecode in executable.Main to print a
decent user-friendly error message on the controller on Java 11 (no
such plan for agents, though).

The plugin parent POM will continue to support cores with both Java 11
and 17 bytecode (i.e., its minimum jenkins.version will not change)
for a little while longer. The value of maven.compiler.release will
default to 11 but will be dynamically reconfigured to 17 during the
build when jenkins.version is set to a core with Java 17 bytecode.
This should even work fine in IntelliJ this time around thanks to
https://github.com/jenkinsci/maven-hpi-plugin/pull/578 (as long as at
least one Maven build has been done prior to importing the project in
IntelliJ), though developers should still exercise caution when
upgrading libraries to Java 17 bytecode due to Enforcer's
"EnforceBytecodeVersion" check being somewhat crippled during the
transition period (as described in
https://github.com/jenkinsci/maven-hpi-plugin/pull/583). This
transition period is similar to the last one we did when we required
Java 11, but it should be slightly smoother due to improved IDE
support. FTR we had the same gap with Enforcer last time around and a
bug or two slipped through during the transition period, so we need to
be particularly vigilant about upgrading libraries until the
transition period is over.

The astute reader will notice that I wrote "I plan to release a new
version of jenkinsci/pom with maven.compiler.release set to 17 and
adopt it in […] all core components" (including the test harness) as
well as "the plugin parent POM will continue to support cores with
both Java 11 and 17 bytecode […] for a little while longer", two
statements that are seemingly in contradiction due to the fact that a
test harness with Java 17 bytecode will not be usable in a plugin
parent POM that continues to support cores with Java 11 bytecode
(i.e., maven.compiler.release set to 11). How is this contradiction to
be resolved? By creating a backport branch of the test harness that
continues to be based on Java 11 bytecode, and using this backport
branch in the plugin parent POM until we decide to drop Java 11
support in the plugin parent POM (most likely around the timeframe
when Jetty 12 EE 9 is delivered in LTS). This means that every change
to the test harness will need to be backported to become available to
plugin parent POM releases—painful in the short term, but the idea is
that this phase will not last more than a few months. Meanwhile, on
the default branch of the test harness, we hope to soon deliver
functionality to support both Jetty 12 EE 8 and Jetty 12 EE 9,
selecting dynamically based on the core in use. This will be explained
further in a forthcoming JEP, and it will allow plugins with tests
that rely on Jetty APIs to begin migrating to Jetty 12 in advance of
the rest of the ecosystem.

I am planning to follow a lazy consensus approach with this plan. If
nobody objects to this lazy consensus decision by the end of next
week, I will consider the matter settled and start executing on the
plan the week after that, with a weekly release that requires Java 17
delivered by the end of June.

[Basil Crow]

On Tue, Jun 4, 2024 at 5:21 PM Basil Crow <m...@basilcrow.com> wrote:
> I am planning to follow a lazy consensus approach with this plan. If
> nobody objects to this lazy consensus decision by the end of next
> week, I will consider the matter settled and start executing on the
> plan the week after that, with a weekly release that requires Java 17
> delivered by the end of June.

https://github.com/jenkinsci/jenkins/pull/9358 has been merged toward
2.463, which will require Java 17 or newer.

As a follow-up I proposed
https://github.com/jenkinsci/jenkins/pull/9382 to use pattern matching
for instanceof. Similar PRs could be proposed to adopt enhanced switch
statements, text blocks, and record classes if anyone is interested.

[Basil Crow]

On Tue, Jun 4, 2024 at 5:21 PM Basil Crow <m...@basilcrow.com> wrote:

> By creating a backport branch of the test harness that
> continues to be based on Java 11 bytecode, and using this backport
> branch in the plugin parent POM until we decide to drop Java 11
> support in the plugin parent POM (most likely around the timeframe
> when Jetty 12 EE 9 is delivered in LTS). This means that every change
> to the test harness will need to be backported to become available to
> plugin parent POM releases—painful in the short term, but the idea is
> that this phase will not last more than a few months.

With today's release of 2.463, the default branch of the test harness
is now targeting 2.463 and Java 17 or newer. I have created a 2225.x
backport branch that still targets 2.361 and Java 11 or newer. The
plugin POM will still support Java 11 for a bit longer, so test
harness changes should generally be backported to this branch in the
short term. Let me know if you need help doing this.

https://github.com/jenkinsci/jenkins-test-harness/pull/762 and
https://github.com/jenkinsci/jenkins-test-harness/pull/770, both
targeting the default branch of the test harness, add EE 8 and EE 9
support (respectively). These PRs will not be backported; rather, they
will form the basis of a future plugin POM release that requires Java
17 or newer and Jetty 12 or newer.

[Basil Crow]

Spring Security 6.x (including EE 9) was delivered in 2.475, with two
follow-on regression fixes in 2.476 and 2.477 respectively. At the
time of this writing, I am not aware of any unresolved issues with
Spring Security 6.x or EE 9. I recommend either 2.476 or 2.477 be
chosen as the next LTS line, and if 2.476 is chosen then the relevant
regression fix should be backported.

https://github.com/jenkinsci/plugin-pom/pull/1004 proposes requiring
Java 17 or newer and Jetty 12 (EE 9) or newer for plugin development.
My recommendation is to merge and release this PR once the next LTS
line is selected. While more aggressive than usual for the plugin
parent POM, this eliminates the need for a number of workarounds when
using newer core releases. We can always create a Java 11 backport
branch if necessary, but I have no plans to do that at present.