https://github.com/jenkins-infra/jenkins.io/pull/4547#pullrequestreview-747378748
On Monday, September 6, 2021 at 6:25:41 PM UTC+1 [email protected] wrote: > > 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 > <https://issues.jenkins.io/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+lts-candidate>. > > > > especially in the combination with "Backporters use this query > <https://issues.jenkins.io/issues/?filter=12146> 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 > > On Thursday, September 2, 2021 at 8:46:08 PM UTC+1 [email protected] wrote: > >> 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 >> >> Le jeu. 2 sept. 2021 à 12:18, Tim Jacomb <[email protected]> a écrit : >> >>> 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 >>> >>> >>> >>> On Wed, 1 Sept 2021 at 15:48, [email protected] <[email protected]> >>> wrote: >>> >>>> 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 >>>> >>>> >>>> >>>> On Wednesday, September 1, 2021 at 3:36:05 PM UTC+1 Oleg Nenashev wrote: >>>> >>>>> 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 >>>>> >>>>> On Tuesday, August 31, 2021 at 8:16:08 PM UTC+2 [email protected] >>>>> wrote: >>>>> >>>>>> 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, [email protected] < >>>>>> [email protected]> 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. >>>>>> >>>>>> That will greatly help on the security scanners area, where the >>>>>> "fear" dominates the market :-) >>>>>> >>>>>> Thanks James for the suggestion, great idea. >>>>>> >>>>>> Wadeck >>>>>> >>>>>> On Tuesday, August 31, 2021 at 3:58:38 PM UTC+2 [email protected] >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-dev/bad90cc0-1307-4184-9d3f-2a6a27345ddan%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jenkinsci-dev/bad90cc0-1307-4184-9d3f-2a6a27345ddan%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieHQt%3D9hzh2mJjv9p2-LSKSaYtcdz%3D9K0kN9CKMGpioTA%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieHQt%3D9hzh2mJjv9p2-LSKSaYtcdz%3D9K0kN9CKMGpioTA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0f12a053-0bad-4dd9-80da-a115d439249en%40googlegroups.com.
