Live data from Hacker News

Forgejo <=16.0.3 Critical RCE

codeberg.org

51–60 of 87 posts

Re: Forgejo <=16.0.3 Critical RCE

#51
post #22

Earlier quoted context omitted.

Why can't you use an LLM to find vulnerabilities and then hand-code the fix? You don't even have to clean-room implement it; let the LLM write the code, and then reimplement, doing what you can to de-LLM-ify it.

You can. People on Codeberg use LLMs. They are just against spam of low quality projects generated with LLMs.

That is actually entirely not what they were saying at the time of the vote and its aftermath. At all.

Go back and read the threads. On this forum, or on mastodon, or on the vote. It was pretty vociferously ... shall we say ... "principled"

It was never stated to be about "low quality" but about use in "large part" or "majority", and when pressed people refused to define what that meant, and in fact got angry and defensive and said things like "you'll know if you've crossed the line" and "stop trying to force consent" and similar pearls of wisdom.

The post-facto rationalization did in fact leave them room to judge "quality" on a purely subjective basis. I didn't stick around to find out how that would shake out.

Re: Forgejo <=16.0.3 Critical RCE

#52

The opex and security fine costs of moving off managed services like GitHub/GitLab are catching up.

This vulnerability, which doesn’t affect my installation, would take approximately 5 minutes to patch if it did. With that exception, my server will have had approximately 99.999% uptime over the last several years. It would take a boatload of such events to equal the opex of GitHub hosting. That’s not an excuse to run amok, but it’s far from tipping the scales in GitHub’s cost favor.

Yep. I have one hanging off an openbsd machine on a tailnet, took me like... 5 minutes to update it, and it's not exactly a common setup...

Re: Forgejo <=16.0.3 Critical RCE

#53

The opex and security fine costs of moving off managed services like GitHub/GitLab are catching up.

The amount of time I need to spend maintaining my Forgejo instance this year, even after accounting for this RCE, has been less than the amount of time GitHub has been degraded or unavailable this year.

Re: Forgejo <=16.0.3 Critical RCE

#54
post #19

Earlier quoted context omitted.

> Gitea is protected against both of these issues. Is Gitea's immunity just incidental because it was written by a different person, or is it due to a deliberate defensive system that prevents such bug/mistake from occurring?

Very interested in knowing too, since the issues seems to not be related at all, or similar, so now this must mean a Gitea "project leader" would only say this if they have some sort of layer that doesn't require them to manually patch issues individually. Meaning, firewall? Would be weird if that's built-in into Gitea though... Hmm.

It looks like Gitea made the same fix (rm -r .git after template processing) back in February: https://github.com/go-gitea/gitea/commit/2176e84ab977011ff2b...

PR: https://github.com/go-gitea/gitea/pull/36734

So likely Gitea < 1.25.5 was vulnerable.

Re: Forgejo <=16.0.3 Critical RCE

#55

The opex and security fine costs of moving off managed services like GitHub/GitLab are catching up.

Wouldn't most users considering or using Forgejo also have considered (or used) self-hosted Gitlab which would have the same opex / security costs (and much higher hardware requirements)?

Re: Forgejo <=16.0.3 Critical RCE

#56
post #6

You should change the URL to https://codeberg.org/forgejo/forgejo/milestone/139655 > PR: Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. Dur…

> To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.

What happened to sandboxing the offending git invocation?

Re: Forgejo <=16.0.3 Critical RCE

#58

Earlier quoted context omitted.

That is about Codeberg, not Forgejo. Forgejo disallows LLM contributions, including using a "general AI" (they include LLMs under "general AI") for reviews[0]: > 5. Using general AI for review is forbidden. If the change contains changes to the UX it has to be approved by a human reviewer. [0] https://codeberg.org/forgejo/governance/src/branch/main/AIAg...

> Forgejo disallows LLM contributions You're misreading the rule. >> 5. Using general AI for review is forbidden. The second sentence makes it even clearer, as it would have been unnecessary under a blanket ban scenario >> ... If the change contains changes to the UX it has to be approved by a human reviewer.

This looks unambiguous to me:

  > Forgejo does not accept works of authorship (code, documentation, etc.) either partially or completely generated by AI due to legal uncertainties.

Re: Forgejo <=16.0.3 Critical RCE

#59

Earlier quoted context omitted.

> Forgejo disallows LLM contributions You're misreading the rule. >> 5. Using general AI for review is forbidden. The second sentence makes it even clearer, as it would have been unnecessary under a blanket ban scenario >> ... If the change contains changes to the UX it has to be approved by a human reviewer.

This looks unambiguous to me: > Forgejo does not accept works of authorship (code, documentation, etc.) either partially or completely generated by AI due to legal uncertainties.

Using AI to find a vulnerability is not a work of authorship. Using the AI generated text as your bug report would be, but if you use AI to find a bug, then write up a report yourself, I think that would be fine.
Post reply on HN