I think what's happening here is, people don't have time to assess. And frankly, can you blame them?
A person might be implementing dozens or hundreds of pieces of software from multiple vendors. Now there are CVEs on their radar. They have to deal, and assess.
What do they do?
Do a deep dive on every CVE, including looking at code, validating what the CVE represents, and assessing security risk org wide, no matter how and where and in what way the software is used? Is code even available?
Or, is the prudent thing to say "CVE -- we need the vendor to resolve".
How much work must an end user put in, when a CVE is there?
I agree 100% that this is terrible, but my point is to at least understand it from the side of implementation. What I tend to do is use my distro for everything I possibly can. This provides an entity that is handling CVEs, and even categorizing them:
This helps reduce the need to handle CVEs directly. Not eliminate of course, but vastly reduce it. Output of clicking on a CVE is helpful with a rating:
This rating may be because it does not affect debian in its default config, or because something isn't compiled in, or the impact is truly low, or so on.
This gives me something to read if I must, and to grasp when I have no time to deep dive. I trust debian to be reasonably fast and work well to resolve CVEs of importance, and properly triage the rest.
Yes, I know of edge cases, yes I know of the fact that seldom used packages often need an end user to report a CVE. It can and does happen. But the goal here is "doing our very best" and "proving we'd doing that".
So this helps by allowing me to better focus on CVEs of vendor products I use, and get a better grasp on how to pursue vendors.
Yet when dealing with the infrastructure of smaller companies -- they just don't have the time. They still have to manage the same issues as a larger company, that being SoC2 compliance or what not, as well as liability issues in their market sphere.
And the thing is, I'm willing to bet larger companies are far worse at this CVE chicanery. It's just rote to them. Smaller companies have flexibility.
Here's a hotlist for making at least some of this manageable, because if you give people information, you don't have to respond as much:
* have a RSS feed, or a webpage which is only updated if there is a security update for your software
* have a stable and development(bleeding edge) branch. One branch only has security updates and never new code. Maybe, possibly bugfixes, but bugfixes must not break the API, config files, or create requirements for newer versions of libraries
* provide a mailing list never ever ever used for marketing purposes, which alerts users to new updates for software. never spam that email address. ever.
Important:
If you have outstanding CVEs, list them somewhere on a static page, with a description of what the issue is, and how you've triaged it. If you believe it's a bogus CVE, say so. If you think it only causes issues in certain circumstances, and is thus less important that other CVEs you are working on, say so.
Keep all CVEs here by simply updating the page to indicate a CVE was resolved, but also with a version/commit and date of when. Again, information resolves so many issues.
Do these things, and your end users will love you, and it will engender more trust that security issues are being dealt with seriously. (Note: not saying that aren't, but if you make it easy for people to know when updates come out, lots of questions stop being asked)
When engineers see this sort of thing, they love you. They become stronger advocates. It falls under marketing as much as technical due diligence.
As an open source software vendor I can say two things:
1) The CVE system allows vendors to deny CVEs that relate to their product. I don't know the exact rules, so I don't know if it applies in this case. We take anything that can crash our software seriously.
2) For users without a support contract, your priority does not automatically become out priority. If you want your issues fixed then make sure we have the money to do so. Just because you got a free download doesn't give you any rights to support.
What started this is a case where you have to put weird stuff in a config file to trigger the CVE. If the people behind dnsmasq don't get paid or not enough, then it is perfectly fine if this is not a priority.
We have a very popular product, lots of use in what is really the foundation of the internet and almost no support contracts.
So you can turn the argument around, if you are not paying for software, consider it a hobby project. Feel free to report and issue and create a ticket. But don't expect anything to happen. And don't complain on mailing lists how your issue is not taken seriously. Just fix the issue yourself or switch to a different product.
I think you're missing my point. Your code is your resume. It's also an advertisement for whether your product is worth donating to, helping with, buying, and whether you are an excellent coder and project maintainer or not.
A CVE, bogus or not, needs to be handled. If you don't, it reflects upon you. Hands down. No amount of "but it's for free" works to negate this. Ever. No one can demand anything of you, but your reputation will 100% be graded upon how you deal with such things.
This is the way the world works. This is how reputation works. Get over it. Deal with it. Understand it. No, you're not going to ever change this, unless you genetically engineer new humans. This is how humans, and human society has existed for millennia. You will never, ever, ever, change this. You will never explain an alternate to anyone. Ever.
Even if the CVE is bogus, you need to set the record straight, and it's almost akin to libel against your project and you. My suggestions about having a page listing all CVEs are fairly clear and to the point.
These suggestions help people asses your project and your reliability and competency. Yet at the same time? They reduce your effort and work!
Instead of debating endlessly on a mailing list, and instead of repeated bug reports, a well placed security page will take the lion's bulk of such things, answer them, and leave the project team free to not deal with questions on each CVE.
Such a list gives you an authoritative reason why the CVE is triaged as it is, you can point mailing list inquiries at it, WONTFIX bug reports at it, and you can even put your project's stance at the top of the page!
What I've been saying in these posts, is that organization overrules chaos. And that even if some weirdos disagree with you, or have silly expectations, you're crystal clear on things.
I think this is what you want. Your concerns about what people should expect, are dealt with via this method. I actually think we're aligned here, except (perhaps?) you think doing this is work.
It's not. It's the opposite of work. It's saving time.
Why?
Because you will never, ever, ever change human behaviour. Ever. Literally nothing has ever changed in, for example, how commercial transactions occur. This exact complaint could happen today over a used car:
Every problem you've had with humans has been done endlessly billions of trillions of times. Just because it's a software project, doesn't mean it's any different than any other project. There have been volunteer, for free works since the inception of humanity. There have been people with unrealistic expectations, and the tug and pull therein.
I'll reiterate my original stance, just make it clear. Make it clear that you're dealing with CVEs. Part of this makes it eminently clear that the fly in the ointment is the persistent person with crazy expectations. Not your project.
A person might be implementing dozens or hundreds of pieces of software from multiple vendors. Now there are CVEs on their radar. They have to deal, and assess.
What do they do?
Do a deep dive on every CVE, including looking at code, validating what the CVE represents, and assessing security risk org wide, no matter how and where and in what way the software is used? Is code even available?
Or, is the prudent thing to say "CVE -- we need the vendor to resolve".
How much work must an end user put in, when a CVE is there?
I agree 100% that this is terrible, but my point is to at least understand it from the side of implementation. What I tend to do is use my distro for everything I possibly can. This provides an entity that is handling CVEs, and even categorizing them:
https://security-tracker.debian.org/tracker/source-package/o...
This helps reduce the need to handle CVEs directly. Not eliminate of course, but vastly reduce it. Output of clicking on a CVE is helpful with a rating:
https://security-tracker.debian.org/tracker/CVE-2021-36368
This rating may be because it does not affect debian in its default config, or because something isn't compiled in, or the impact is truly low, or so on.
This gives me something to read if I must, and to grasp when I have no time to deep dive. I trust debian to be reasonably fast and work well to resolve CVEs of importance, and properly triage the rest.
Yes, I know of edge cases, yes I know of the fact that seldom used packages often need an end user to report a CVE. It can and does happen. But the goal here is "doing our very best" and "proving we'd doing that".
So this helps by allowing me to better focus on CVEs of vendor products I use, and get a better grasp on how to pursue vendors.
Yet when dealing with the infrastructure of smaller companies -- they just don't have the time. They still have to manage the same issues as a larger company, that being SoC2 compliance or what not, as well as liability issues in their market sphere.
And the thing is, I'm willing to bet larger companies are far worse at this CVE chicanery. It's just rote to them. Smaller companies have flexibility.
Here's a hotlist for making at least some of this manageable, because if you give people information, you don't have to respond as much:
* have a RSS feed, or a webpage which is only updated if there is a security update for your software
* have a stable and development(bleeding edge) branch. One branch only has security updates and never new code. Maybe, possibly bugfixes, but bugfixes must not break the API, config files, or create requirements for newer versions of libraries
* provide a mailing list never ever ever used for marketing purposes, which alerts users to new updates for software. never spam that email address. ever.
Important:
If you have outstanding CVEs, list them somewhere on a static page, with a description of what the issue is, and how you've triaged it. If you believe it's a bogus CVE, say so. If you think it only causes issues in certain circumstances, and is thus less important that other CVEs you are working on, say so.
Keep all CVEs here by simply updating the page to indicate a CVE was resolved, but also with a version/commit and date of when. Again, information resolves so many issues.
Do these things, and your end users will love you, and it will engender more trust that security issues are being dealt with seriously. (Note: not saying that aren't, but if you make it easy for people to know when updates come out, lots of questions stop being asked)
When engineers see this sort of thing, they love you. They become stronger advocates. It falls under marketing as much as technical due diligence.