Discussion: Version Support Policy for Security Fixes

[scherersebastian]

Context:

As our software evolves, we need clarity on which versions will receive security fixes. This issue serves as a platform for that discussion.

Proposed Policy

Latest major version.

Request for Comments

Thoughts on the proposed policy? Please share below!

[scherersebastian]

We should also list in our documentation which versions are supported.

[scherersebastian]

For example in SECURITY.md

[Essenbreis]

but we have to consider if more version of products like EDC 0.5.1 + 0.5 + 0.4 are running in parallel in productive environments how to ensure that code runs secure?

[DnlZF]

Workshop discussion and results:
We agree with the proposal

[scherersebastian]

@Siegfriedk what do you think?
We could add something like this to our guidelines (SECURITY.md, ...):
"Only the latest release receives security support and updates. Previous versions are not kept up-to-date in this regard."
You are more familiar with our TRG compliance laws, please share your insights.

[Siegfriedk]

@scherersebastian there has to be a 'overlap' phase for one Major to another i would assume?

I think its a good thing which needs to be defined, i'm not the right person though to manifest/decide it. @danielmiehle might know who

[scherersebastian]

@Siegfriedk @SebastianBezold Since the topic came up today. The procedure is coordinated disclosure. I think you know it.
You discover a vulnerability, you create a solution, a suitable new release with the usual version numbering (3.2.1), if it's critical, you publish a CVE via the GitHub Security Advisories.
... before this happens, we should first decide which versions are actively supported.