https://github.com/jenkins-infra/jenkins.io/pull/4547#pullrequestreview-747378748
On Monday, September 6, 2021 at 6:25:41 PM UTC+1 jn...@cloudbees.com 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 bma...@gmail.com 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 <timja...@gmail.com> 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, jn...@cloudbees.com <jn...@cloudbees.com> >>> 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 boa...@gmail.com >>>>> 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, 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. >>>>>> >>>>>> 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 jn...@cloudbees.com >>>>>> 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 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 >>>>>> >>>>>> <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 jenkinsci-de...@googlegroups.com. >>>> 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 jenkinsci-de...@googlegroups.com. >>> >> 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0f12a053-0bad-4dd9-80da-a115d439249en%40googlegroups.com.
