> 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. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.
Forgejo <=16.0.3 Critical RCE (codeberg.org)
amiga386 16 hours ago
embedding-shape 14 hours ago
If you have open registrations or otherwise users you don't 100% trust with the ability to create new repository (which is the default I think?), they could potentially exploit this and you probably wanna upgrade ASAP.
If you have only trusted users, or single user, seems it's fine. Of course, wanna upgrade anyway to not add escalation paths, but in the other situation it's graver.
amluto 10 hours ago
What happened to sandboxing the offending git invocation?
techknowlogick 15 hours ago
(bias note: part of project leadership of Gitea)
Edit: As a note, security incidents happen to everyone and we shouldn't shame anyone for reporting them, especially as that'd otherwise cause less issues to be reported overall.
tredre3 15 hours ago
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?
embedding-shape 14 hours ago
jonstaab 13 hours ago
ThePowerOfFuet 12 hours ago
Macha 11 hours ago
PR: https://github.com/go-gitea/gitea/pull/36734
So likely Gitea < 1.25.5 was vulnerable.
fartfeatures 8 hours ago
vanschelven 43 minutes ago
ntauthority 3 hours ago
wvbdmp 3 hours ago
dabeeeenster 12 hours ago
nirui an hour ago
// Before template expansion, .git was removed so that a fresh repo can be initialized; remove it again in case
// some template variable usage has conflicted with this directory and impacts git operations.
if err := root.RemoveAll(".git"); err != nil {
return fmt.Errorf("unable to remove .git folder")
}
Why the `err` isn't carried by the error message? For security? Then maybe log it internally?User/operator can't really fix the problem if you keep giving them information this vague.
keel-control 16 hours ago
They may not use AI to check for vulnerabilities but attackers are going to which puts themselves at the disadvantage.
titularcomment 16 hours ago
otherme123 16 hours ago
You are implying that just by allowing LLM contributions your product is free of bugs, and the LLM won't introduce new bugs. Of course, if the LLM introduces bugs, the solution is to add another layer of LLM looking for bugs, ad infinitum.
Another post from today from Shopify, praising LLM to code their frontend, also stated that their LLM generated code is not ready to deploy, and needs to be reviewed:
> It’s tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn’t work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can’t be shipped. [...] each [build] must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts.
1matin 16 hours ago
you didn't read the comment, did you?
cmrdporcupine 11 hours ago
That... is not the implication of the comment you're replying to.
You don't need to make it all fundamentalist.
striking 16 hours ago
iCarrot 3 hours ago
>6. It is not allowed to use AI in an autonomous-looking way to contribute in Forgejo. This also applies when someone engages in 'vibe coding' or uses so-called 'agent mode'.
bdcravens 15 hours ago
omnimus 15 hours ago
cmrdporcupine 11 hours ago
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.
mitxela 6 hours ago
pixl97 13 hours ago
burkaman 15 hours ago
https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36...
badsectoracula 15 hours ago
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...
burkaman 14 hours ago
The rule you quoted is about code reviews, they don't want you using an LLM to write reviews or leave comments.
This is a pretty poorly written policy to be honest, so I understand if you interpret it to mean "no LLMs in any capacity", but I think if that's what they meant they would have said that. In fact they explicitly allow content "made with the help of AI", you just have to disclose it.
imtringued 2 hours ago
>Vibe coding is the practice where AI creates a code change (feature, bug fix, tests, refactor) with a human that describes what needs to be implemented.
So if you let an AI prompt another AI without human input, that's not vibe coding? Meanwhile if you prompt the model with pseudo code you've written or code written in another programming language to translate into the target language, that's vibe coding?
>It is not allowed to use AI in an autonomous-looking way to contribute in Forgejo.
They used the word "in", meaning it could refer to organizational membership, their repo or theoretically any instance of Forgejo, including self hosted ones. They failed to specify what part of Forgejo or the definition of Forgejo they meant.
Overall this is a pretty poorly written document and when you think about it, it doesn't really matter how poorly written it is when they are basically 100% against AI.
overfeed 14 hours ago
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.
semiquaver 10 hours ago
> Forgejo does not accept works of authorship (code, documentation, etc.) either partially or completely generated by AI due to legal uncertainties.thayne 9 hours ago
dessimus 8 hours ago
Would that not imply that a change that does not effect the UX does not have to be approved by a human reviewer? Otherwise, why specifically call out "changes to the UX" and not say "all changes"?
Macha 16 hours ago
https://codeberg.org/forgejo/forgejo/pulls/14301:
*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. During this process, variable template expansion could be misused in order to create a new `.git` folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing `.git` folder is removed from the directory before the git repository is initialized.
https://codeberg.org/forgejo/forgejo/pulls/14301:
ensure authorization reducer is accessed when checking editable PRs in APIs. When editing a git repo contents through Forgejo's API, a specialized security control is used to permit repository maintainers to edit branches that they do not own when an open pull request with the "allow maintainer edit" option is present. This specialized security control did not take into account API-specific security restrictions, such as repo-specific access tokens. As a result, it was possible for an API access token with restricted permission to make modifications outside of that restricted permission. The specialized security control has been updated to take into account API authentication security restrictions.
---
So if like me you run a private forgejo instance with closed signups and limited repository creation, you can wait for the update. Otherwise maybe take it off the public internet for a bit?
jzebedee 16 hours ago
Security bug fixes
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. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.hephaes7us 16 hours ago
rcleveng 16 hours ago
Any mirror?
sbx320 16 hours ago
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. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.tugback an hour ago
mmsc 13 hours ago
embedding-shape 13 hours ago
mfenniak 13 hours ago
johnsea an hour ago
miguelgrinberg 15 hours ago
snvzz 9 hours ago
0. https://codeberg.org/forgejo/forgejo/src/branch/forgejo/rele...
innocent_name 15 hours ago
kstrauser 13 hours ago
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.
cyberpunk 11 hours ago
lukeify 11 hours ago
davidee 10 hours ago
bitbasher 10 hours ago
PaoloBarbolini 16 hours ago
xyst 16 hours ago
p4bl0 15 hours ago
nightpool 15 hours ago
Sphax 16 hours ago
teaearlgraycold 9 hours ago
dboreham 15 hours ago
nightpool 15 hours ago
msm_ 15 hours ago
It can't be done without authenticating first, but there's nothing about RCE that says that it must be sent from unauthenticated connection.
mitxela 6 hours ago
msm_ 15 hours ago
You should be OK, but if attacker takes over your user (or any user in your forgejo instance) they can execute code on the host server - as you said yourself. In other words, it allows them to achieve remote code execution, so it's a RCE.
bakugo 15 hours ago
rvz 15 hours ago
This means you have no choice but to use AI to defend, find and patch these flaws before attackers quickly build and use these exploits to target users.
You cannot afford to disallow or have a 100% ban on LLM contributions while attackers do not care and will use AI to find the flaws and attack you faster than you can triage it.
pixl97 13 hours ago