Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VULN-DISCLOSURE-POLICY: on legacy dependencies #16086

Closed
wants to merge 5 commits into from
Closed

Conversation

bagder
Copy link
Member

@bagder bagder commented Jan 25, 2025

Problems that only trigger using legacy dependencies are not considered security problems.

Problems that only trigger using *legacy* dependencies are not
considered security problems.
@samueloph
Copy link
Member

If a vulnerability was in the dependency, then it would not be applicable to this, because the CVE would go to that dependency instead, this means this is about cases where the vulnerability relies on how curl is using the dependency.

The benefit in creating CVEs in these cases is that it lets everyone know that they should not be building with that version, and this lets them double check their LTS releases (which are more susceptible for this).

the legacy version is no longer in use by any existing still supported operating system or distribution

This might be hard to check, possibly more work checking this than checking whether a certain report is a valid vulnerability and creating a CVE?

There are a few Linux distributions which consistently provide 10+ years of support (some of these have more than 10 years): Debian, Ubuntu, RedHat, SUSE. So they are all possibly affected by these issues.

Old still-supported distro releases tend to either live in a different repository (e.g.: Freexian's Debian ELTS) or not distribute the source code unless you're a paying customer (e.g.: RedHat), making it difficult for a curl developer to check their dependencies' versions.

The curl project can fix these vulnerabilities by dropping support for the old version, requiring a minimum version for the build, but it's not required for the curl project to fix them. It's fine to say the mitigation is to build with version > X and let distributors publish their own CVE assessments based on whether or not they build with that dependency.

I think releasing CVEs in these cases will make distributions of curl more secure, leaving no margins for mistakes, but I will understand if the decision is to merge this PR.

@stiiin
Copy link

stiiin commented Jan 25, 2025

There are a few Linux distributions which consistently provide 10+ years of support (some of these have more than 10 years): Debian, Ubuntu, RedHat, SUSE. So they are all possibly affected by these issues.

Doesn't the second clause in the PR explicitly make an exception for these cases, @samueloph?

@samueloph
Copy link
Member

There are a few Linux distributions which consistently provide 10+ years of support (some of these have more than 10 years): Debian, Ubuntu, RedHat, SUSE. So they are all possibly affected by these issues.

Doesn't the second clause in the PR explicitly make an exception for these cases, @samueloph?

Yes, but then I mention below in that comment why that's something hard to check (and error-prone).

@stiiin
Copy link

stiiin commented Jan 25, 2025

There are a few Linux distributions which consistently provide 10+ years of support (some of these have more than 10 years): Debian, Ubuntu, RedHat, SUSE. So they are all possibly affected by these issues.

Doesn't the second clause in the PR explicitly make an exception for these cases, @samueloph?

Yes, but then I mention below in that comment why that's something hard to check (and error-prone).

I get that the word "any" in "any existing still supported operating system or distribution" makes this difficult if it's up to the responder to establish that, because that would require them to check a possibly open-ended enormous set of existing OS'es/distros that qualify as "still supported". Do I understand your point there correctly?

If so, I don't think it has to be that way. The responder has a duty of care for their product, and reports of vulnerabilities should be cause for investigation, but the reporter also has a large burden of proof. Even if the report doesn't indicate which OS or distro was used to trigger the vulnerability, this information can become clear in a dialog between the responder and the reporter. One example of such an OS or distro would be enough for this exclusion not to apply. Or am I missing something here?

@samueloph
Copy link
Member

I get that the word "any" in "any existing still supported operating system or distribution" makes this difficult if it's up to the responder to establish that, because that would require them to check a possibly open-ended enormous set of existing OS'es/distros that qualify as "still supported". Do I understand your point there correctly?

It's not only the amount of them, it's mostly due to how difficult it is to check and how this will lead to false negatives.

If so, I don't think it has to be that way. The responder has a duty of care for their product, and reports of vulnerabilities should be cause for investigation, but the reporter also has a large burden of proof. Even if the report doesn't indicate which OS or distro was used to trigger the vulnerability, this information can become clear in a dialog between the responder and the reporter. One example of such an OS or distro would be enough for this exclusion not to apply. Or am I missing something here?

The main point is that this is error-prone, being either the reporter or the curl developers responsible for the check, there could be CVEs that are not created for issues that affect a still-supported Linux distro. At the end of the day, the vulnerability will still be there, so this is about whether or not to create a CVE to have as an identifier for it.

This is only focusing on distros, other distributors of curl would not be covered for this and so they could also be affected.

Creating a CVE does take some effort, so it's understandable if curl decides not to cover these cases, this is similar to the case of projects not creating CVEs for unsupported releases (if when their releases are not that old). I'm mostly pointing out the benefits of doing it and how there could be cases of a CVE not being created for a build that someone still supports.

@xquery
Copy link
Member

xquery commented Jan 25, 2025

I am all for addressing the pathological scenario of using ancient, unpatched, unsupported software - doing so should always mean there should be a default 'not fit for purpose' stance. I do think generically defining the term 'legacy software' is hard and we might find we have to update this policy as and when. Thanks for doing this!

@jay
Copy link
Member

jay commented Jan 25, 2025

So I think we can all agree the word legacy is somewhat subjective. Maybe as a report qualifier it should be judged on a case by case basis.

@bagder
Copy link
Member Author

bagder commented Jan 25, 2025

I've tried to draw a line to help identify when we won't chase a problem nor register a new CVE for it. I don't think the way I write "legacy" here should cause much concern since I also define exactly what I mean with the term in this context. But we can certainly use another term if someone has a better name or phrasing to suggest.

Everyone can still argue that their case is worthy of attention and should get an exception or maybe a reason why they should be heard. This document is a set of guidelines to help everyone involved to understand the play-field. They are not hard black and white rules.

@bagder bagder closed this in cb4cd36 Jan 27, 2025
@bagder bagder deleted the bagder/legacy-dep branch January 27, 2025 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants