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-dev+unsubscr...@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.
