docs: add CVE release guidance

[SMoraisAnsys]

As title says. Partially address #558 (comment)

[da1910]

Couple of text issues, and a question/issue about the guidance in general

[da1910]

This is, as far as I remember from our discussion, explicitely not the case we're considering here?

We'd discussed making a release when we had to change to allow a non-vulnerable version to be installed, for example:

# Before the update
[tool.poetry.dependencies]
Pillow = "<10.0.0"

# After the update
[tool.poetry.dependencies]
Pillow = "<11.0.0" # CVE-2023-44271 fix

[da1910]

Requiring library authors to exclude vulnerable versions of dependencies from our version ranges is not a sustainable policy imo

[SMoraisAnsys]

When we discussed we also mentioned that project should avoid setting upper versions limits unless it is absolutely necessary, cf #586. That's why this draft mainly focused on restricting minimum version. However, I agree that excluding vulnerable versions of dependencies is not a sustainable policy.

If others agree with you, I can update the PR accordingly. Thanks for the suggestions !
Pinging @MaxJPRey @RobPasMue @jorgepiloto @greschd for visibility

[RobPasMue]

Main message that we need to get through to our library maintainers is that our library's latest version should be installable free of CVEs (with a reasonable buffer time of course).

When one of our dependencies has a CVE, and our library only allows the usage of versions of that dependency affected by the CVE... that's when maintainers need to do some remediation (i.e. do a new release that allows the installation of CVE-free versions of our dependency)

But, actively excluding CVE-impacted versions of our dependencies is a no-go IMO (just like @da1910 pointed out).

[RobPasMue]

Now... if maintainers also want to prevent the consumption of CVE affected versions (i.e. blocking any CVE affected version), that's a decision they can consider on their side -- but it's up to them I'd say. Although it might become a nightmare for them.

[jorgepiloto]

It is not possible securing our ecosystem without excluding vulnerable dependencies. If no other option because of the lack of alternatives, this must be documented within the library, see PyACP security considerations. This goes in the line of what @RobPasMue mentioned about maintainers.

Regarding the limits, I do not think we must limit major versions. A dependency can release a new major and your project may not be affected at all. If the major release affects the latest stable release, you just do a patch for limiting the version while fixing things in main. Then, you decide whether to patch things again or release a new version.

Overall, I see things this way:

[project]
dependencies = [
  # The conservative scenario
  "dependency>=lowest_vulnerability_free_version",
  # The flexible scenario 
  "dependency>=lowest_supported_version,!=not-valid-version,!=another-not-valid-version",
]

[da1910]

I would object as strongly as I possibly can to any requirement that we exclude vulnerable dependencies from our version ranges. It is not scalable, not practical, and entirely unnecessary for a security perspective in an open-source ecosystem.

[da1910]

Suggested change

	- your PyPI package no longer resolves to vulnerable combinations;
	- Your PyPI package no longer requires a vulnerable combination of dependencies.

[da1910]

Suggested change

	- automated tooling stop reporting your package as affected by the CVE;
	- Automated tooling stops reporting your package as affected by the CVE.

[da1910]

Suggested change

	- users who pin your package can become aware of the fix and update accordingly.
	- Users of your package can be made aware of the fix and can update accordingly.

[da1910]

Suggested change

	update the version range in your project to exclude the vulnerable version. This
	update the version range in your project to allow the fixed version. This