Carrot Disclosure: Forgejo

This is a weird post to be honest. You've found a whole bunch of serious security issues, filed two PRs, one of which is adding some quotes because

> Those aren't exploitable XSS, but it doesn't hurt to have a second layer of defense.

The other suggests breaking clients that aren't using the more secure version of an OAuth method because

> I can't think of any OAuth client that would like to [use it]

That second one is a good idea, but the maintainer is also right to ask for some discussion before introducing a breaking change.

But crucially: neither of these are the kind of significant security issues you've found. Maybe lead with an actual bug?

There’s an old cryptography story.

A cryptographer friend tells the story of an amateur who kept bothering him with the cipher he invented. The cryptographer would break the cipher, the amateur would make a change to “fix” it, and the cryptographer would break it again. This exchange went on a few times until the cryptographer became fed up. When the amateur visited him to hear what the cryptographer thought, the cryptographer put three envelopes face down on the table. “In each of these envelopes is an attack against your cipher. Take one and read it. Don’t come back until you’ve discovered the other two attacks.” The amateur was never heard from again.

https://www.schneier.com/crypto-gram/archives/1998/1015.html

This entire post reads as rage bait. They’re mad because Forgejo has … a process? And what are these vulnerabilities, concretely?

> But given the sorry state of the codebase

I honesty want a refund on the 10 minutes I wasted reading this.

Did the author actually disclose this RCE or just open random PRs and claim there's an issue?

It doesn't appear like the author is acting in good faith, instead grandstanding in public because they feel superior.

I note that the code that pull request 12283 is changing builds HTML via string concatenation/templates, which is a widespread source of XSS problems. Maybe it is time to for browsers and JavaScript runtimes/libraries to deprecate string based HTML building and require DOM based instead. The former is unsafe by design and the latter is a safe-by-construction approach.

Getting HTML building right is a pretty basic building block of web apps, Forgejo can't have great security practices if they aren't doing that. So I can easily imagine the OP is correct in their assessment of Forgejo code security.

The author sent 5 more pull requests fixing (tragically) fundamental security flaws. https://codeberg.org/forgejo/forgejo/pulls?q=&type=all&sort=...

In the age of AI, carrot disclosure is potentially a full disclosure with extra steps. I'm no security expert, but with the context provided, the forgejo codebase and the outline of the redacted script, I think there is a good chance I could use codex to crunch through the vuln chain and reproduce the script.

I run a forgejo instance at home but wouldn't dream of opening it up to the public. Works great, and fast on lan, but imo keep it there

Hopefully someone a little more.. pragmatic gets eyes on that linked PR.

https://codeberg.org/forgejo/governance/src/commit/5c07b3801...

> Failure to comply with these rules will be criticized publicly, and we reserve the right to no longer coordinate with you or your project in the future.

lol

Imagine if every open source contributor behaved like that.

"I found performance problems in your software, but I won't disclose them until you fix them."

"I'm a designer, but I won't disclose my improvement to your project until you adjust all the CSS bugs in your project."

If that person is skilled with finding security bugs, then that could be their contribution to that open-source project, like any other contribution.

From a linked PR (related to this RCE?), from a maintainer who closed it:

>Just thinking something not being used is not enough, even if it's a security sensitive topic

Linux kernel seems to disagree. This is a dangerously naive way to think of networked software in the AI age.

---

edit: I got hit with the "posting too fast" block again, so I'll reply to dangus here:

>While a remote host would further prove the claim, the person clearly claims it is RCE, not just CE. It would be quite the pie in the face if the author wrote a python script to take in an IP address but modified system files on the backend to create a stunt.

This is so wrong. Because he didn't like a PR removing a feature, and they haven't yet merged another PR that was opened yesterday?!?

The author's attitude is so off-putting. What gives? Did Forgejo hurt you?

The Forgejo disclosure process looked pretty simple and straightforward to me. The bold and all-caps words that bothered the author are just making sure you know how to disclose vulnerabilities safely without leaking zero-day exploits to a wider audience than necessary.

I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.

Show us the exploit hitting a remote server.