It should be noted that Google Project Zero doesn't care whether a software product is maintained by multi-trillion corporations or a single volunteer. Imposing an "industry-standard" 90-day deadline on a unpaid solo developer without offering any help or compensation whatsoever is not sustainable. It forced me to step down as maintainer of libxslt: https://gitlab.gnome.org/GNOME/libxslt/-/issues/127
What is not sustainable is that someone decides to sit on a security bug for any reason. If someone doesn't want to or can't fix a security bug it should be made public so someone else can step in or, at least, so users (be it end users or software projects that use a library) can look for mitigation or alternatives.
The linked conversation looked pretty civil - looks as though you decided to step down, which is entirely reasonable, but I don't see anything forcing you or imposing anything on you.
This isn't the same as bigcorps offloading their compliance costs to open-source ""vendors"". No one's obligated to do anything. The disclosure window is meant to address a tradeoff between giving the dev a chance to fix it, and minimizing users' risk until patch issuance. But if the dev can't fix it, the risk tradeoff shifts and you do have a duty to make it public for users' sake. You can't take it for granted that you're the first one and only one to have found that vulnerability.
Google is a bunch of hypocrites, there are other cases where Google asked third parties for a disclosure extension and the fixes took longer than 90 days, but here is the most recent one I noticed...
You said "Being an unpaid volunteer, I also don't really care about external deadlines. I'll just make the issue and the fix public and people can patch libxslt themselves." But that's what they were going to do anyway if you didn't fix it--they were going to make the issue public. What's the problem?
It seems lately every piece of software is getting more and more vulnerabilities, failures, crashes. Microsoft products are exceptionally high in the list.
I don't understand why they wouldn't give a pre-release patch to the bug reporter (especially if it's someone like Google) for them to analyse before doing a final release.
If they were actively working with Project Zero instead of being seemingly silent, this wouldn't happen
This is where FOSS is still winning and will always win. Fixed happen in the open and bad fixes can be called out
I’m not sure why you think it’s the researchers responsibility to verify patches. It would be nice, especially if they’re knowledgeable in the code, but Microsoft have the resources to put someone else in that position too.
That’s different. I’m not here to mark your work but if you publish your work, I’m happy to publicly point out that you’re wrong, especially if you’re Microsoft size and should have work checkers internally and are continually doing the wrong think and putting people at risk as a result.
What’s the expectation for responsible disclosure when it comes to ineffective patches? Does that normally reset the counter to 90 days, or only if the patch was reasonable and in good faith?
Here's the actual issue with technical details instead of useless blogspam: https://project-zero.issues.chromium.org/issues/437291456
It should be noted that Google Project Zero doesn't care whether a software product is maintained by multi-trillion corporations or a single volunteer. Imposing an "industry-standard" 90-day deadline on a unpaid solo developer without offering any help or compensation whatsoever is not sustainable. It forced me to step down as maintainer of libxslt: https://gitlab.gnome.org/GNOME/libxslt/-/issues/127
What is not sustainable is that someone decides to sit on a security bug for any reason. If someone doesn't want to or can't fix a security bug it should be made public so someone else can step in or, at least, so users (be it end users or software projects that use a library) can look for mitigation or alternatives.
The linked conversation looked pretty civil - looks as though you decided to step down, which is entirely reasonable, but I don't see anything forcing you or imposing anything on you.
Civil, but unreasonable. An unpaid maintainer of a free library isn't a vendor, and shouldn't be treated in any such way. A vendor is paid.
This isn't the same as bigcorps offloading their compliance costs to open-source ""vendors"". No one's obligated to do anything. The disclosure window is meant to address a tradeoff between giving the dev a chance to fix it, and minimizing users' risk until patch issuance. But if the dev can't fix it, the risk tradeoff shifts and you do have a duty to make it public for users' sake. You can't take it for granted that you're the first one and only one to have found that vulnerability.
They aren't demanding anything of you. The alternative is immediate disclosure of bugs, not indefinite embargo of bugs.
Google is a bunch of hypocrites, there are other cases where Google asked third parties for a disclosure extension and the fixes took longer than 90 days, but here is the most recent one I noticed...
https://news.ycombinator.com/item?id=43032464
What do you think of https://bughunters.google.com/open-source-security/patch-rew...?
You said "Being an unpaid volunteer, I also don't really care about external deadlines. I'll just make the issue and the fix public and people can patch libxslt themselves." But that's what they were going to do anyway if you didn't fix it--they were going to make the issue public. What's the problem?
Microsoft, why don't you simply use Copilot to fix the vulnerability?
It seems lately every piece of software is getting more and more vulnerabilities, failures, crashes. Microsoft products are exceptionally high in the list.
More people are looking. Microsoft products have been large attack surface, poorly coded and heavily researched for a very long time.
I don't understand why they wouldn't give a pre-release patch to the bug reporter (especially if it's someone like Google) for them to analyse before doing a final release.
If they were actively working with Project Zero instead of being seemingly silent, this wouldn't happen
This is where FOSS is still winning and will always win. Fixed happen in the open and bad fixes can be called out
I’m not sure why you think it’s the researchers responsibility to verify patches. It would be nice, especially if they’re knowledgeable in the code, but Microsoft have the resources to put someone else in that position too.
The researchers in this case literally checked the patch after release. It costs nothing to send them a pre-release and ask the question
That’s different. I’m not here to mark your work but if you publish your work, I’m happy to publicly point out that you’re wrong, especially if you’re Microsoft size and should have work checkers internally and are continually doing the wrong think and putting people at risk as a result.
What’s the expectation for responsible disclosure when it comes to ineffective patches? Does that normally reset the counter to 90 days, or only if the patch was reasonable and in good faith?