Removing unsafe old versions of plugins from update sites

[Daniel Beck]

Hi everyone,

as discussed a while back[1], and implemented for the first time with Pipeline Classpath Plugin a few weeks ago[2], we started removing plugins with unfixed security vulnerabilities from distribution.

What we haven't discussed is what to do with plugins that receive fixes: Should we remove their older, vulnerable releases from update sites?

The Jenkins project operates a number of versioned update sites to service older LTS releases versions of plugins compatible with them, currently starting at 1.609 and including every LTS baseline since then.

If a plugin that currently requires e.g. 1.651.x gets fixed, the fixed version will only be available for Jenkins 1.651.x and up. So should we remove older releases from distribution, resulting in the plugin being unavailable for 1.642 and earlier versions of Jenkins, even though (vulnerable) releases of that plugin exist what would be compatible with these older cores?

Of course, plugin maintainers could always back port security fixes to older lines and publish maintenance releases, but what should we do in general?

Daniel

1: https://groups.google.com/d/msg/jenkinsci-dev/NaAqqChOVmY/BvA_TuzjAQAJ
2: https://jenkins.io/security/advisory/2017-03-20/#pipeline-classpath-step-plugin-allowed-script-security-sandbox-bypass

[Oleg Nenashev]

Hi,

I think that the minimal requirement from the community side is to have the Security fixes applicable on the last Jenkins LTS with security fixes in the core. Instances with older cores are formally "unsecure", hence their admins should be able to react to plugin security changes if they want to keep there instances "secure".

So de-listing of plugins for older releases IMHO does not worth efforts, especially since there is an administrative warning for unsafe core/plugins. The instance admins will be warned.

The only concern are Jenkins packages being offered by Enterprise vendors. Some of them provide longer supported release lines with backporting, and there the "last security LTS release" becomes inapplicable. But I am not sure it should matter for Jenkins project since that companies offer their own update centers as well.

BR, Oleg

четверг, 6 апреля 2017 г., 15:12:18 UTC+2 пользователь Daniel Beck написал:

[Daniel Beck]

> On 10.04.2017, at 00:01, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> I think that the minimal requirement from the community side is to have the Security fixes applicable on the last Jenkins LTS with security fixes in the core.

Strictly speaking, this is up to maintainers, but I would be surprised if anyone decided on a Jenkins dependency more recent than current LTS for security fixes.

> So de-listing of plugins for older releases IMHO does not worth efforts, especially since there is an administrative warning for unsafe core/plugins. The instance admins will be warned.

Only since 2.40 and 2.32.2, so in my example in the original email, there's plenty of instances without a warning, that still would get the plugin.

[Daniel Beck]

> On 10.04.2017, at 00:05, Daniel Beck <m...@beckweb.net> wrote:
>
> Only since 2.40 and 2.32.2, so in my example in the original email, there's plenty of instances without a warning, that still would get the plugin.

In fact, I expect we'll still operate update sites for releases older than 2.32.x for at least another 1-2 years. So just pointing to warnings for dealing with this isn't a solution even in the medium term.