> and it seems that experimenting with odd vulnerability disclosure schemes is frowned upon.
Good grief, you weren't kidding.
No kidding, my guy. We've spent a few decades coming to a rough consensus on the right way to report findings. No one's likely to have patience for trying something totally different where they don't have standardized playbooks to follow.
Rough consensus on the right way to report isolated findings. Report one hole, and that hole will be fixed, but you don’t expect anything beyond that.
If you have systemic or architectural problems, that procedure doesn’t work. It will amount to putting one or two bandaids on an entire sieve.
If a building inspector finds a small number of fixable problems, they’ll give a report saying “fix this, this and this, then you’re okay”. If they find a large number of issues in the first stages of their inspection, they might stop the inspection and perhaps even decline to tell you what the problems are, because that would lead to patching those things, while the underlying posture remains unchanged. (And for some sorts of structural problems, they may just condemn it as unfixable.)
It’s clear that jvoisin considers the typical vulnerability disclosure procedure to be inapplicable and/or harmful in this sort of way. I can’t assess the case on its merits, but I do find it plausible.
I get the criticism but also I don't get the criticism.
Thank fuck that someone found this bug and let them and the rest of us about it so we can protect ourselves. My forgejo instance was already running on my tailnet with no public exposure but had been considering public disclosure of it for some collaborators.
There has been a lot of talk around forgejo as an alternative to github for months now. To now understand that their security posture seems to be, 'like, yaknow, whatever...' is disturbing.
I think both parties can take this opportunity to mature. I understand that Forgejo is a community project, but community projects should have standards or very explicit disclaimers when it comes to security.
The growing popularity of the project + an increase of AI-powered security enthusiasts submitting random bugs has created a HUGE backlog for the Foregejo security team.
Instead of acting like this, the author should offer to help the project.
coordinated disclosure has always been a courtesy (with a deadline to motivate the vendor to fix their stuff) and i don't like how people seem to just expect it now
(From one of the toots) > That said, I do not believe humiliation is the ultimate goal of the contributor here, nor venting a frustration. The ideal outcome is probably to acknowledge the risk, reduce the interpersonal heat
I think that’s a very charitable interpretation, and that’s a good attitude in general. In this case though, given that this ended up with all toots and tweets about it, I would suspect notoriety and internet points are at the top of the list of at least some parties here…
Missed the original. That seems like a reasonable way to highlight software that you believe is fundamentally insecure. Obviously you can't be on the hook to fix deep architectural issues yourself, but just submitting a single PR will be treated as "problem solved". Since most of any software contains some vulnerability, just saying "this software has an RCE" isn't actually a disclosure at all. The real issue is that the given vulnerability was (supposedly) easy to find, which if true is not something that will be fixed by targeting just that exploit chain, and needs deep changes to fix.
Previously:
https://news.ycombinator.com/item?id=47941590
Tangential: the favicon for dustri.org is from a really delightful (and hilariously dark) children's book called "I Want My Hat Back" https://en.wikipedia.org/wiki/I_Want_My_Hat_Back
This is the classic response of a troll.
> and it seems that experimenting with odd vulnerability disclosure schemes is frowned upon.
Good grief, you weren't kidding.
No kidding, my guy. We've spent a few decades coming to a rough consensus on the right way to report findings. No one's likely to have patience for trying something totally different where they don't have standardized playbooks to follow.
Rough consensus on the right way to report isolated findings. Report one hole, and that hole will be fixed, but you don’t expect anything beyond that.
If you have systemic or architectural problems, that procedure doesn’t work. It will amount to putting one or two bandaids on an entire sieve.
If a building inspector finds a small number of fixable problems, they’ll give a report saying “fix this, this and this, then you’re okay”. If they find a large number of issues in the first stages of their inspection, they might stop the inspection and perhaps even decline to tell you what the problems are, because that would lead to patching those things, while the underlying posture remains unchanged. (And for some sorts of structural problems, they may just condemn it as unfixable.)
It’s clear that jvoisin considers the typical vulnerability disclosure procedure to be inapplicable and/or harmful in this sort of way. I can’t assess the case on its merits, but I do find it plausible.
I hope it's that, otherwise the lack of self awareness is would be amusing.
I get the criticism but also I don't get the criticism.
Thank fuck that someone found this bug and let them and the rest of us about it so we can protect ourselves. My forgejo instance was already running on my tailnet with no public exposure but had been considering public disclosure of it for some collaborators.
There has been a lot of talk around forgejo as an alternative to github for months now. To now understand that their security posture seems to be, 'like, yaknow, whatever...' is disturbing.
I think both parties can take this opportunity to mature. I understand that Forgejo is a community project, but community projects should have standards or very explicit disclaimers when it comes to security.
The growing popularity of the project + an increase of AI-powered security enthusiasts submitting random bugs has created a HUGE backlog for the Foregejo security team.
Instead of acting like this, the author should offer to help the project.
I think the author would argue they did try to do so, but their efforts were poorly received.
The author doesn’t owe forgejo anything. They are doing them a favor by highlighting the issues
No, the author is seeking attention. He is not doing forgejo or their users any favours by completely ignoring the rules of engagement
https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc...
coordinated disclosure has always been a courtesy (with a deadline to motivate the vendor to fix their stuff) and i don't like how people seem to just expect it now
(From one of the toots) > That said, I do not believe humiliation is the ultimate goal of the contributor here, nor venting a frustration. The ideal outcome is probably to acknowledge the risk, reduce the interpersonal heat
I think that’s a very charitable interpretation, and that’s a good attitude in general. In this case though, given that this ended up with all toots and tweets about it, I would suspect notoriety and internet points are at the top of the list of at least some parties here…
Missed the original. That seems like a reasonable way to highlight software that you believe is fundamentally insecure. Obviously you can't be on the hook to fix deep architectural issues yourself, but just submitting a single PR will be treated as "problem solved". Since most of any software contains some vulnerability, just saying "this software has an RCE" isn't actually a disclosure at all. The real issue is that the given vulnerability was (supposedly) easy to find, which if true is not something that will be fixed by targeting just that exploit chain, and needs deep changes to fix.
[dead]