You must log in or # to comment.
I’m not sure why this Lemmy post was titled “RCE in Forgejo” when it just links to a yet-to-be-proven exploit, and the post itself is just a boast on not disclosing the vuln and telling maintainers to duplicate efforts. Feels rather disingenuous.
Other than that the idea of treating Forgejo as some sort of vendor to pull a carrot on is kind of a stupid joke. The security policy, even if lengthy, provides basis for collaboration. And these behaviors, although coming out the volunteer effort of a security researcher, does not exempt one from looking like an ass.
Also see the Mastodon thread for more.
You’re right, I added a question mark.
Alternatively: Forgejo reaches feature parity with GitHub.
What a dick that guy is.
Edit: I hate to remove comments and it may get me banned but due to the hate speech I’m receiving regarding things unrelated to software while trying to sympathize with a frustrated security researcher who got caught up in unnecessary bureaucracy when taken en masse, I’m going to remove these comments for now. This is why we volunteer FOSS engineers have to stay clear of popular projects I guess.
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.
Edit: I hate to remove comments and it may get me banned but due to the hate speech I’m receiving regarding things unrelated to software while trying to sympathize with a frustrated security researcher who got caught up in unnecessary bureaucracy when taken en masse, I’m going to remove these comments for now. This is why we volunteer FOSS engineers have to stay clear of popular projects I guess.
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.mdUse 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.
Edit: I hate to remove comments and it may get me banned but due to the hate speech I’m receiving regarding things unrelated to software while trying to sympathize with a frustrated security researcher who got caught up in unnecessary bureaucracy when taken en masse, I’m going to remove these comments for now. This is why we volunteer FOSS engineers have to stay clear of popular projects I guess.
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…)
Edit: And regarding just dropping the security team an informal mail… I don’t know if that’s clever. You’d normally either follow some security policy, or don’t engage. Sending them other kinds of mails which violate their policy (an internal carrot) might not be the best choice.
Edit: I hate to remove comments and it may get me banned but due to the hate speech I’m receiving regarding things unrelated to software while trying to sympathize with a frustrated security researcher who got caught up in unnecessary bureaucracy when taken en masse, I’m going to remove these comments for now. This is why we volunteer FOSS engineers have to stay clear of popular projects I guess.
I don’t think you read the article.
Did you miss this part
with a lot of MUST/MUST NOT about what I must or mustn’t do should I decide to go this way.
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.
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.
… Fortunately (or unfortunately depending who you’re asking), the RCE relies on open registration , and on a configuration option set to a non-default value (which is the case on some instances I’ve looked at, so nothing exotic), meaning that its selling value is pretty low/nonexistent …
From the posted blogpost
There’s an HN thread about this and yes it sounds like the guy is being stupid and/or there was a communications error. He submitted a PR for a potentially breaking change and it was closed as “needs discussion”. That is, instead of clicking “open PR”, he was advised to instead click “open discussion” and talk about the proposed change and its potential downstream effects. He instead got pissy and started spamming forums.
Setting aside the Forgejo issues for a moment, I can’t quite see the logic behind the author’s description of a “carrot disclosure”.
As written, it’s a third option for disclosure, beyond 1) coordinated disclosure (often 90 days for the vendor to fix things) or 2) full disclosure (immediately going public, esp when the vulnerability is believed to be actively exploited). But what the author describes as the carrot is to publish only the output of a proof-of-concept, and then the onus is on the vendor to figure out both the vulnerability and the fixes.
This seems wildly irresponsible to me, to put the effort into writing a working PoC but then to willfully withhold it, so as to basically force the vendor into a wild goose chase. And that’s the best case scenario, when the PoC is actually legit. At worst, it’s a DoS against a vendor (causing them to re-audit code to find a bug that doesn’t actually exist, eg hallucinated AI slop) or is a form of defamation to scare users away.
Then there’s the issue of when it’s not a “vendor” per-se but a group of volunteers of an open-source project, which I will distinguish from commercial vendors as “maintainers”. Is it ethical to withhold an already-written PoC from FOSS maintainers, whom often do not have the material capabilities to do a full-scale audit when given basically no clues?
To be clear, I’m not a security researcher and have done zero disclosures of any form. But if I ever ran a project and received a so-called carrot disclosure, why shouldn’t I immediately call their bluff and treat it as full-disclosure? This situation seems like Schrodinger’s Cat, where the only way to rip away the uncertainty is to throw open the box. Worse case, the project suffers the reputational hit for having a legit vulnerability. But best case, the vulnerability is non-existent. But what this supposed “third way” purports to do is no different than sowing the seeds of fear, uncertainty, and doubt amongst users. Someone tell me how this isn’t one step away from extortion.
I think game theory would say that any and all recipients of “carrot” disclosures should always call the bluff, immediately and vocally. I don’t see any way for such disclosures to be anything but unnecessarily antagonistic. I refuse to credit the term with any legitimacy.
What’s a good alternative? I’m not 100% sold on forgejo either due to some bugs and security issues I’ve run into as well, but I’ve found few self-hosted alternatives that are a good fit. I need very little beyond a git repo. But I like having the web UI for reviewing code and pull requests and basic issue tracking and need that to support OIDC, but otherwise I’m open. I want something relatively lightweight, fully FOSS, and telemetry and all other external communication can be disabled.
Forgejo is fine. Don’t expose it to the internet unless you have to, or mirror your repos to Codeberg and let them worry about it.
Yeah I keep it isolated for now, but use it very little. I plan to expand to try to get off of some other platforms, so just looking if any other options exist, even if they lack features since I don’t use a lot.
If I like having a web UI means you can do without it, git doesn’t require anything fancy. I just have my git repos on my server and push/pull from my workstations over SSH. It doesn’t require anything but git & SSH on the server. You can even collaborate with others by giving them a locked down account that can’t do anything other then interact with the git repo.
This approach certainly isn’t for everyone. The web UI can be super handy, but if you just want your own self-hosted git server, keep it simple.
