Re: LTS backporting policy

[jn...@cloudbees.com]

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 
> .
>  
>
>
> 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
>
> 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  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  
>>> 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 

Re: LTS backporting policy

[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

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  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  
>> 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

Re: LTS backporting policy

[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

Le jeu. 2 sept. 2021 à 12:18, Tim Jacomb  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 
> 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
 
 .

 --
>> 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
>> 
>> .
>>
> --
> You received this message because you are subscribed to the 

Re: LTS backporting policy

[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



On Wed, 1 Sept 2021 at 15:48, 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
>>> 
>>> .
>>>
>>> --
> 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
> 
> .
>

-- 
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/CAH-3BieHQt%3D9hzh2mJjv9p2-LSKSaYtcdz%3D9K0kN9CKMGpioTA%40mail.gmail.com.

Re: LTS backporting policy

[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



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  
>> 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
>>  
>> 
>> .
>>
>>

-- 
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.

Re: LTS backporting policy

[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

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  
> 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
>  
> 
> .
>
>

-- 
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/9f2fceb7-68eb-470a-8cdd-93367d65680en%40googlegroups.com.

Re: LTS backporting policy

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

-- 
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/4D6CAB91-D14F-4D5E-BF52-8E121013BADE%40gmail.com.

Re: LTS backporting policy

[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

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

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

-- 
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/ce759c0c-6592-4c49-b6ae-b5b207727144n%40googlegroups.com.