Alternatively: Forgejo reaches feature parity with GitHub.

What a dick that guy is.

FYI: The writer works for a AI-based security company and,well,seems to fit in there.

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.

https://news.ycombinator.com/item?id=47941590

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.

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.

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.

I don't get how that output showcases anything, unless he had run that against a known instance of forgejo so the owners of that instance could confirm that he actually executed code. But he's only showing a text file, that's like saying look I hacked super_secure_self_hosted_service:

python hack_it.py localhost:3000

Hacked!

For all we know chain_alpha.py is just a bunch of prints.

Also, even if it is real (which I don't really doubt, but I have seen no proof) holding the information instead of properly disclosing it is just childish. It's not a carrot methodology, it's a stick one, and one without a carrot. This is the sort of thing you do to big companies with no morals, doing it to a small open source project is just wrong, they don't have the manpower or money to redo the investigation you already did. Release a CVE, talk to the devs, and/or push a PR, but saying "I found a vulnerability but I won't tell you about it" is just dumb.