LTS backporting policy

[jn...@cloudbees.com]

Hi all,

I would like to propose that we add to the list of eligible criteria for backporting the following

* is a dependency update with a known security issue

The reason for this if we have a dependency with a security issue that is exploitable from Jenkins we already do include that as a LTS issue via the current SECURITY process, however if the issue is not exploitable then we do not. (for example the recent XStream issues have not impacts Jenkins as we already use an allow list).

However as supply chain issues are becoming more prominent to our users, they are scanning software with automated tools that look at the dependencies, and these scanners do not understand how a library is used or  configured, and has the potential to:

* make the software look insecure (thus be a barrier to adoption) 
or 
* cause extra nose asking about CVE-2021-123456

WDYT?

/James

[wfoll...@cloudbees.com]

Totally agree. Especially when the update is not a major bump of 3 versions. Most of the time it's just a minor/bug version bump.

That will greatly help on the security scanners area, where the "fear" dominates the market :-)

Thanks James for the suggestion, great idea.

Wadeck

[Matt Sicker]

Are there specific libraries we can list for safe upgrades? Like XStream, Jackson, Commons, etc, for common upgrades. I wouldn’t be super comfortable with a blanket policy, but for all our more stable ones, I think it’s a good idea.

Matt Sicker

On Aug 31, 2021, at 09:01, wfoll...@cloudbees.com <wfoll...@cloudbees.com> wrote:

Totally agree. Especially when the update is not a major bump of 3 versions. Most of the time it's just a minor/bug version bump.

--
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/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%40googlegroups.com.

[Oleg Nenashev]

I am +0.5, but being eligible does not immediately mean the change would be backported. Dependency updates may also introduce regressions. As any other backport, risks need to be evaluated. IMHO it should be up for backporting requesters to prove the safety of changes and to ensure there is enough soak testing and test coverage. Same for any other non-critical backport

[jn...@cloudbees.com]

Sure,

I was just asking it to be added to the list of eligible criteria.  As with any bug that is also eligible there is a decision to be made as to if we are to cherry-pick the change or not.

(on a randomly different note - if we where actually vulnerable - we would not have this luxury!)

/James

[Tim Jacomb]

This is already covered as far as I can tell:

https://www.jenkins.io/download/lts/#backporting-process

> Aside from the model set out above, backporters apply some subjective selection — for example whether a fix is easy and safe to backport, confidence in the fix, importance/impact of the problem, how much time is left until the end of backporting window and so on.

We have already been back-porting some dependency updates (e.g. xstream), as security scanners pick them up even though we know we aren't vulnerable.

Do you think that's enough? Or some more specific wording on that page?

Thanks

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bad90cc0-1307-4184-9d3f-2a6a27345ddan%40googlegroups.com.

[Baptiste Mathus]

Right, re-reading this part well (thanks Tim), I think this should be enough indeed? 

Not fully sure about the term "fix" being too precise, or vague :), but probably that's nitpicking.

WDYT James, do you feel making a more precise note around "dependency update with known CVE" or so would still be important for some reason?

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieHQt%3D9hzh2mJjv9p2-LSKSaYtcdz%3D9K0kN9CKMGpioTA%40mail.gmail.com.

[jn...@cloudbees.com]

>  This is already covered as far as I can tell:

I think Tim was referring to the "subject to risk" rather than "not a bug".

As I read
   Any user can propose that a bug fix be backported to LTS by labeling with lts-candidate.

especially in the combination with "Backporters use this query to list up issues that need to be attended once resolved."  where the query is "issuetype in (Bug, Improvement)" I am not sure that covers library updates for reasons other than bugs (and improvements - but funnily that is at odds with the previous "bug fix" and non bug fixes have been historically denied).


What I am hearing at least is that no body is against this in principal so I will try and come up with a PR to https://www.jenkins.io/download/lts/ that describes the situation and we can move the details of wording over there.

/James

[jn...@cloudbees.com]

https://github.com/jenkins-infra/jenkins.io/pull/4547#pullrequestreview-747378748