Updating detached plugins

[Basil Crow]

Since before my involvement as a core maintainer, we have apparently
had a policy to "only update detached plugins when we are forced to,
for example because there was a security advisory," and to run
LoadDetachedPluginsTest#noUpdateSiteWarnings when updating them. This
policy predates my involvement as a core maintainer, and when it was
introduced to me the reasoning behind it was not explicitly stated.

In recent years a few things have changed. First, we have seen an
increased need to update libraries to satisfy security scanners, even
when the old versions are not exploitable in Jenkins. Second,
Dependabot is now proposing updates to these detached plugins, and
ignoring these updates results in stagnant PRs. Third, we have
occasionally seen a need to mitigate the impact of JENKINS-69361.

Since 2022 I have been regularly updating detached plugins, justified
as an exception to the usual policy in order to mitigate the impact of
JENKINS-69361. At this point in 2024, the exception has become the
rule, so I would like to propose a change in policy to update detached
plugins as the Dependabot PRs come in, for the reasons given in the
preceding paragraph.

Since manually running LoadDetachedPluginsTest#noUpdateSiteWarnings
for each Dependabot PR is a nuisance, I would also like to propose
that we drop the requirement for running this test or that we enable
the test by default, accepting in the latter case that it will cause
some friction during the small window of time after a security
advisory marks a plugin release as vulnerable but before the relevant
Dependabot PR(s) is/are picked up.

The main issue regarding updating detached plugins, if I recall
correctly, was that this may (possibly?) limit users' ability to
downgrade these plugins below the version that we bundle. I am not
sure if this claim was ever verified. If this claim is verified,
either by a user reporting the inability to downgrade such a plugin,
or by manual testing, then I could possibly be fine with retaining the
existing policy but disabling Dependabot updates to detached plugins
to reduce PR noise.

[Daniel Beck]

On Tue, Apr 9, 2024 at 8:28 PM Basil Crow <m...@basilcrow.com> wrote:

Third, we have occasionally seen a need to mitigate the impact of JENKINS-69361.

Since 2022 I have been regularly updating detached plugins, justified
as an exception to the usual policy in order to mitigate the impact of
JENKINS-69361.

Are you aware of examples of this problem other than the two Jira issues? Only instance-identity has been explicitly mentioned (and one comment mentions unspecified other plugins, which I guess are the javax-* plugins). I think I have a plausible explanation for the bug that would limit the problem to just these plugins, but lack further information about the scope of the problem.

[Basil Crow]

On Tue, Apr 9, 2024 at 12:33 PM 'Daniel Beck' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
>
> Are you aware of examples of this problem other than the two Jira issues?

Daniel, I am not aware of any such examples.

[Daniel Beck]

On Tue, Apr 9, 2024 at 9:34 PM Basil Crow <m...@basilcrow.com> wrote:

Daniel, I am not aware of any such examples.

Thanks for that confirmation.

At this point I'm not entirely convinced JENKINS-69361 is real, and unless you know more than is present in Jira, we don't understand it well enough to act on it. Trying to reproduce it by manually dropping instance-identity 113 and bouncycastle-api 2.26 in an otherwise 2.346.x Jenkins home (reproduction instructions are unclear how this would otherwise work given its core dependency) and starting 2.361.1, it gets appropriately ignored by entering the first block and passing the version comparison:

PluginManager#loadDetachedPlugins: Upgraded Jenkins from version 2.346.2 to version 2.361.1-SNAPSHOT. Loaded detached plugins (and dependencies): []

While updating to a newer Jenkins results in bundled plugins being updated to the bundled releases if what's installed is older, it's possible to downgrade plugins afterwards and have that remain, as long as the core version doesn't change (not entering https://github.com/jenkinsci/jenkins/blob/16a65758149f71de1fd61dd0d7aa1fa9c06cd8c3/core/src/main/java/hudson/PluginManager.java#L812-L818). That manual downgrade would need to happen on every bundled version bump though, which given the regularity of plugin releases would be practically every LTS bump (not to mention the lack of support for downgrading configuration). It used to be possible for users to "pin" versions of plugins, but that was dropped in or around 2.0 when we no longer installed bundled plugins by default, making it basically an offline fallback only (resulting in the current policy IIRC). https://groups.google.com/g/jenkinsci-dev/c/kRobm-cxFw8/m/6V66uhibAwAJ and related messages may shed some light on how we got here. OTOH you've applied the pre-emptive updates for a while, as you wrote, and I'm not aware of many (or any) complaints about being forced to update plugins.

At this point, neither the reasons to implement the policy change nor the reason not to are very convincing to me. Wearing my security hat I'd prefer updating everything all the time. As an admin I'd be more hesitant, but for the rare cases a bundled plugin release causes problems, the existing ability to downgrade (and wait for maintainers to fix whatever is the blocker) seems like it might be just enough to move forward with this. I guess this amounts to +0.5.

Re the test -- I'd skip it for future automatic PRs. When we only updated bundled dependencies to address security vulnerabilities, we needed a way to ensure any such PR was complete, as nothing else would increase these versions until the next PR updating bundled plugins due to vulnerabilities.

[Basil Crow]

Thanks, Daniel. I'll plan on proceeding with a lazy consensus decision
that from now on, we'll accept the Dependabot PRs that update detached
plugins, we'll keep the test ignored, and we won't run the ignored
test manually for Dependabot PRs. If nobody objects to this lazy
consensus decision by Monday, I'll consider the matter settled and
merge jenkinsci/jenkins#9109.