> Because an infected machine can and often will participate in infecting other machines.
OK, so how disclosing this vulnerability will help preventing that? It is the opposite, disclosing this vulnerability only speeds up this process.
> Not to mention that if
That big if.
> If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.).
That's good example.
And that's one more reason to privately push the owners of the project owner to fix the issue instead of disclosing after one day.
> that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing
I agree, that's bad, and that's happen all the time in huge companies, not just single-person open source side projects.
The correct response to vulnerability would be creating a post to pressure project owner by explaining the dangers of it without disclosing how exactly it can be exploited.
> It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate.
Analogy. Your coworker is dumb. You can say he is dumb. And then he refuses to work with you.
Saying he is dumb is not innaccurate. But it doesn't help constructive team work.
The blog author could start by apologizing (or at least by redacting the post), if they wanted to work with the project team.
OK, so how disclosing this vulnerability will help preventing that? It is the opposite, disclosing this vulnerability only speeds up this process.
> Not to mention that if
That big if.
> If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.).
That's good example.
And that's one more reason to privately push the owners of the project owner to fix the issue instead of disclosing after one day.
> that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing
I agree, that's bad, and that's happen all the time in huge companies, not just single-person open source side projects.
The correct response to vulnerability would be creating a post to pressure project owner by explaining the dangers of it without disclosing how exactly it can be exploited.
> It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate.
Analogy. Your coworker is dumb. You can say he is dumb. And then he refuses to work with you.
Saying he is dumb is not innaccurate. But it doesn't help constructive team work.
The blog author could start by apologizing (or at least by redacting the post), if they wanted to work with the project team.