I don’t really see what is so bad here… There was disclosure of type, but no reference to the exact code. This gives the maintainer a chance to reach out for specifics before bad actors can make a pseudo-zero day.
I understand what you’re saying, but Forgejo has an outdated and made-up-from-thin-air policy. From their security.md:
You MUST disclose vulns to the author (why are we dictating instead of inviting participation)
emails about vulns MUST be encrypted (I don’t even understand this one, this gives really strong “we don’t know how email works” vibes)
And it just goes on, like someone from 2003 wrote that policy.
Now, I’m going to agree with you that it’s a bit of a dick move to do the carrot dangle thing, but some vendors/devs just don’t respond without the pressure. And forgejo has been forced by github supporters to implement a security policy after trying to ignore it.
It seems that the author has some ongoing interactions with forgejo, and it would be great if these were disclosed in the article, but forgejo seems to need a kick in the pants, especially over an RCE, the forbidden sev 10 of vulns.
If you replaced Forgejo with GitHub then I would understand, but Forgejo isn’t a massive organization with hundreds of hired employees, it’s run by people in their spare time with the option of donations.
Anyone can help contribute, instead of doing that, this guy decided to try and get some clout by being an asshole because he is butthurt about some other interaction. If this guy went about it the proper way and then still got no answer or fix after months, then I would understand more, but he didn’t.
Most white-hat security researchers seem like dicks until you realize they are doing most of this research for free and have few ways to get groups to fix the issues beyond spending lots of time doing it themselves or exposing the vulnerabilities in some manner that doesn’t make exploits easy to create for the black-hats.
Forgejo has a responsible disclosure policy, but this person seems like they just don’t want to deal with that and instead opted for the nuclear option immediately.
Did you read the policy and how complex it is? Did you look at the fixes they submitted and how simplistic they were that were rejected for not following a super complex policy meant for major issues in proprietary software? If an expert submits a fix with little to no risk and lots of potential for harm, why not have a simple process or just accept the fix? I wouldn’t want to follow that complex process and wait for embargos to pass before being allowed to suggest the fix for each of those issues.
Erm, did you read them? The policies aren’t complex at all, just submit the issue (and proposed fix if there is one) through a secure channel, that they’re happy to help set up. If you want to disclose the vulnerability, just wait until the embargo passes so there’s time to fix and have users update. There’s not really anything else you need to do here. This is pretty standard stuff that this person just seemed too lazy to participate in.
Of the three fixes submitted, only a single one was closed since it didn’t seem very major and would be a breaking change (which shouldn’t be made without prior discussion). The other two are still open, and a maintainer is helping to add tests for the fixes (since the author didn’t add them). The only comment that was somewhat negative was that security fixes should preferably follow the established guidelines. That’s all.
Your comment said Forgejo has a disclosure process. The article says the author went with a carrot disclosure after reading the disclosure process and making a value judgement. Because your comment only mentioned Forgejo having a disclosure process, not an evaluation of the author’s evaluation of the disclosure process, it made you appear as if you had not read the article.
In your response to me calling that out, you offer an analysis. The author is lazy for using carrot disclosure over the defined disclosure process. That’s a valid take. I’m not going to disagree with that.
They explained that due to the systemic nature of the issues, many of which are across all forks of gitea, and the complex nature of the policy meaning disclosing each one individually and following the separate policies depending on the specifics of each issue, would require a very significant amount of time. Probably a day job worth for a while.
So, they could either drop it and give up, spend all of their free time for the foreseeable future properly disclosing each defect, or use the method they chose to get some level of attention on it without exposing details or breaking the security policy, but still letting both developers and users that there are issues.
I believe they were already frustrated by the responses to the fixes they did submit.
I get the frustration. It is how many big companies avoid responsibility, but that’s usually to avoid cost on actually fixing stuff. In a FOSS project, what’s the point of rejecting a simple fix because some complex process meant for complex issues in proprietary software that the security researcher can’t suggest specific fixes for wasn’t followed. Why fill out a bunch of “paperwork” and initiate a long embargo period before a fix is considered when the fix is already submitted and is simple enough and low risk and impact enough to not require more that a cursory review. It’s like asking a road engineer who sees a small pothole that only damages a few cars a year and offers to fill it because they are often affected by it to file a superior court case in order to report it, much less fix it.
So, it’s a matter of, give up because it’s too much of a burden to report, or announce in the most ethical way possible to incentivize fixes actually happening.
Alternatively, they could have sent the security team an email with the ‘carrot’ and saying “There seems to be fundamental, systemic, security issues in Forgejo; here’s some proof. There’s too much for me to raise individual reports, what are we going to do about it?”
I think there’s pros and cons to everything. That way would have been less of a dickhead move towards the Forgejo developers. But a big letdown to admins as they don’t know what’s up with the software they’re running on their servers. The way the author chose gives some new intelligence to admins, and they can now act on it, since it’s public knowledge. But it’s annoying to the devs.
I guess I as a Forgejo user am kinda greatful they did it this way. Now I got to learn the story and can allocate 2h on the weekend to see if my personal Forgejo container is isolated enough and whether the backups still work.
(But that’s just my opinion after reading one side of the story. Maybe there’s more to the story and they’re being a dick nonetheless…)
What a dick that guy is.
I don’t really see what is so bad here… There was disclosure of type, but no reference to the exact code. This gives the maintainer a chance to reach out for specifics before bad actors can make a pseudo-zero day.
Is it the language you object to?
The entire attitude is shit. Could just contact the developers as outlined, instead of being a prude about it for some clout.
I understand what you’re saying, but Forgejo has an outdated and made-up-from-thin-air policy. From their security.md:
And it just goes on, like someone from 2003 wrote that policy.
Now, I’m going to agree with you that it’s a bit of a dick move to do the carrot dangle thing, but some vendors/devs just don’t respond without the pressure. And forgejo has been forced by github supporters to implement a security policy after trying to ignore it.
It seems that the author has some ongoing interactions with forgejo, and it would be great if these were disclosed in the article, but forgejo seems to need a kick in the pants, especially over an RCE, the forbidden sev 10 of vulns.
If you replaced Forgejo with GitHub then I would understand, but Forgejo isn’t a massive organization with hundreds of hired employees, it’s run by people in their spare time with the option of donations.
Anyone can help contribute, instead of doing that, this guy decided to try and get some clout by being an asshole because he is butthurt about some other interaction. If this guy went about it the proper way and then still got no answer or fix after months, then I would understand more, but he didn’t.
Most white-hat security researchers seem like dicks until you realize they are doing most of this research for free and have few ways to get groups to fix the issues beyond spending lots of time doing it themselves or exposing the vulnerabilities in some manner that doesn’t make exploits easy to create for the black-hats.
Can you please point out the hate speech you received? I can’t find any in the comments here, just people having different opinions.
As the time of writing the comment I am replying to has 15 up- and 3 downvotes. Doesn’t look like it has warranted hate speech.
Forgejo has a responsible disclosure policy, but this person seems like they just don’t want to deal with that and instead opted for the nuclear option immediately.
Did you read the policy and how complex it is? Did you look at the fixes they submitted and how simplistic they were that were rejected for not following a super complex policy meant for major issues in proprietary software? If an expert submits a fix with little to no risk and lots of potential for harm, why not have a simple process or just accept the fix? I wouldn’t want to follow that complex process and wait for embargos to pass before being allowed to suggest the fix for each of those issues.
Erm, did you read them? The policies aren’t complex at all, just submit the issue (and proposed fix if there is one) through a secure channel, that they’re happy to help set up. If you want to disclose the vulnerability, just wait until the embargo passes so there’s time to fix and have users update. There’s not really anything else you need to do here. This is pretty standard stuff that this person just seemed too lazy to participate in.
Of the three fixes submitted, only a single one was closed since it didn’t seem very major and would be a breaking change (which shouldn’t be made without prior discussion). The other two are still open, and a maintainer is helping to add tests for the fixes (since the author didn’t add them). The only comment that was somewhat negative was that security fixes should preferably follow the established guidelines. That’s all.
Yea. But did you read the security.md?
https://codeberg.org/forgejo/governance/src/branch/main/SECURITY-POLICY.md
Use an encrypted email to security@forgejo.org. If you can’t, tell them and they will set one up.
Seems very assholeish to not at least do that.
I don’t think you read the article.
Did you miss this part
Sounds like him being lazy.
Your comment said Forgejo has a disclosure process. The article says the author went with a carrot disclosure after reading the disclosure process and making a value judgement. Because your comment only mentioned Forgejo having a disclosure process, not an evaluation of the author’s evaluation of the disclosure process, it made you appear as if you had not read the article.
In your response to me calling that out, you offer an analysis. The author is lazy for using carrot disclosure over the defined disclosure process. That’s a valid take. I’m not going to disagree with that.
They explained that due to the systemic nature of the issues, many of which are across all forks of gitea, and the complex nature of the policy meaning disclosing each one individually and following the separate policies depending on the specifics of each issue, would require a very significant amount of time. Probably a day job worth for a while.
So, they could either drop it and give up, spend all of their free time for the foreseeable future properly disclosing each defect, or use the method they chose to get some level of attention on it without exposing details or breaking the security policy, but still letting both developers and users that there are issues.
I believe they were already frustrated by the responses to the fixes they did submit.
I get the frustration. It is how many big companies avoid responsibility, but that’s usually to avoid cost on actually fixing stuff. In a FOSS project, what’s the point of rejecting a simple fix because some complex process meant for complex issues in proprietary software that the security researcher can’t suggest specific fixes for wasn’t followed. Why fill out a bunch of “paperwork” and initiate a long embargo period before a fix is considered when the fix is already submitted and is simple enough and low risk and impact enough to not require more that a cursory review. It’s like asking a road engineer who sees a small pothole that only damages a few cars a year and offers to fill it because they are often affected by it to file a superior court case in order to report it, much less fix it.
So, it’s a matter of, give up because it’s too much of a burden to report, or announce in the most ethical way possible to incentivize fixes actually happening.
Alternatively, they could have sent the security team an email with the ‘carrot’ and saying “There seems to be fundamental, systemic, security issues in Forgejo; here’s some proof. There’s too much for me to raise individual reports, what are we going to do about it?”
I think there’s pros and cons to everything. That way would have been less of a dickhead move towards the Forgejo developers. But a big letdown to admins as they don’t know what’s up with the software they’re running on their servers. The way the author chose gives some new intelligence to admins, and they can now act on it, since it’s public knowledge. But it’s annoying to the devs.
I guess I as a Forgejo user am kinda greatful they did it this way. Now I got to learn the story and can allocate 2h on the weekend to see if my personal Forgejo container is isolated enough and whether the backups still work.
(But that’s just my opinion after reading one side of the story. Maybe there’s more to the story and they’re being a dick nonetheless…)