Since we published the patches for the recently disclosed CVEs, we have had feedback from users on .NET Framework that they are using non-latest versions of the SDK because they find the dependency versions for net462 and netstandard2.0 being 10.0.x problematic, so they have avoided upgrading and thus have a desire for patches of old versions of the SDK so they can stay on old versions: #6975.
Before seriously entertaining the idea of providing backports for security fixes, we should determine exactly what our support policy is because it has impact on bandwidth/supportability/CI etc.
In some cases, e.g. GHSA-g94r-2vxg-569j, the vulnerability has always existed, so backporting for one old patch version creates a potentially slippery slope that could result in the worst case of 14 (1.0.x-1.14.x) backports needed to be published. This is clearly not a sustainable proposition.
Possible (not necessarily suggested/recommended) answers to this question for discussion could be:
- Latest only (e.g.
1.15.x)
- Latest-1 (e.g.
1.14.x and 1.15.x)
- Latest-2 (e.g.
1.13.x-1.15.x)
- Any major/minor version published in the last 6 months (e.g.
1.13.x-1.15.x)
- Any major/minor version published in the last 2 years (e.g.
1.8.x-1.15.x)
- Any major/minor version published that supports an in-support version of .NET (e.g.
1.7.x-1.15.x)
Once we come to a decision, we should:
- Document it
- Mark any NuGet package versions that fall outside the agreed window as deprecated
- Consider some automation to automatically flag packages with an issue as and when they reach the threshold so we can manually mark them as such
Since we published the patches for the recently disclosed CVEs, we have had feedback from users on .NET Framework that they are using non-latest versions of the SDK because they find the dependency versions for
net462andnetstandard2.0being10.0.xproblematic, so they have avoided upgrading and thus have a desire for patches of old versions of the SDK so they can stay on old versions: #6975.Before seriously entertaining the idea of providing backports for security fixes, we should determine exactly what our support policy is because it has impact on bandwidth/supportability/CI etc.
In some cases, e.g. GHSA-g94r-2vxg-569j, the vulnerability has always existed, so backporting for one old patch version creates a potentially slippery slope that could result in the worst case of 14 (1.0.x-1.14.x) backports needed to be published. This is clearly not a sustainable proposition.
Possible (not necessarily suggested/recommended) answers to this question for discussion could be:
1.15.x)1.14.xand1.15.x)1.13.x-1.15.x)1.13.x-1.15.x)1.8.x-1.15.x)1.7.x-1.15.x)Once we come to a decision, we should: