Posted by jwilk 6 days ago
Thank you for reaching out to us. Please be aware that we do not run any kind of security bounty/reward programs.
Having performed our own analysis we have not been able to identify any practically exploitable security risks.
If you have found a practically exploitable security issue with our website, please provide some form of demonstration so that we may discuss further.
I don’t think that would come across as not being concerned about security, but puts the onus on the “researcher” to prove there is a real problem.
Chances are they did some automated scan and found some out of date JavaScript library version which despite having a vulnerability, is not actually a security risk on a static content site.
a) nonsense in which case nobody should spend any time fixing this (I'm thinking things like the frontend DDOS CVEs that are common) b) an actual problem in which case a compliance person at one of these mega tech companies will tell the engineers it needs to be fixed. If the maintainer refuses to be the person fixing it (a reasonable choice), the mega tech company will eventually just do it.
I suppose the risk is the mega tech company only fixes it for their internal fork.
They'd rather send a patch than having to maintain and sync an internal fork with upstream.
Of course that's exactly what traditional Linux distributions signed up to do.
Clearly many people have decided that they're better off without the distributions' packaging work. But maybe they should be thinking about how to get the "buffering" part back, and ideally make it work better than the distributions managed to.
"All null-pointer-referencing issues should come with an accompanying fix pull request".
I think something like "Null-pointer-referencing issues will not be looked at by core maintainers unless someone already provides a patch". That way, someone else who knows how to fix the problem can step in, and users aren't left with the false impression that merely reporting their bug will not guarantee a solution.
If getting rid of your input gets rid of the other 20 issues, I would take it.
this is why i never report stuff to open source. if you wanna play bug bounty and cve hoarder its better to stick with bug bounty programs.
why? there the security researcher can be depressed about the process himself rather than some volunteer coder. gotta not make your issues other ppls issues.
Yes open source has changed, from when the early 90s. There are more users, companies use projects and make millions with other peoples work.
I feel with the maintainer, with how ungrateful people are. And demanding without giving.
Open Source licenses fall short.
Open Source projects should clearly state what they think about fixing security, taking on external contributions or if they consider the project feature complete. Just like standard licenses, we should have a standard, parseable maintenance "contract".
"I fix whatever you pay for, I fix nothing, I fix how I see fit. Including disclosure, etc."
So everyone is clear about what to expect.
https://gitlab.gnome.org/GNOME/libxml2/-/blob/63f98ee8a3a11f...
"The viewpoint expressed by Wellnhofer's is understandable, though one might argue about the assertion that libxml2 was not of sufficient quality for mainstream use. It was certainly promoted on the project web site as a capable and portable toolkit for the purpose of parsing XML. Open-source proponents spent much of the late 1990s and early 2000s trying to entice companies to trust the quality of projects like libxml2, so it is hard to blame those companies now for believing it was suitable for mainstream use at the time."
If the license says one thing, and you say and promote something else, you can't say "But it's in the license" and "I said so at a conference" just as it fits you.
So what should I believe? What you write in the license? What you say at a conference? Nothing you say?
I think the software I wrote is pretty great, but I sure don't want to be liable for the things you do with it.