ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
13% Positive
Analyzed from 1150 words in the discussion.
Trending Topics
#git#template#repository#forgejo#expansion#llm#code#folder#variable#codeberg

Discussion (21 Comments)Read Original on HackerNews
> 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.
(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.
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?
They may not use AI to check for vulnerabilities but attackers are going to which puts themselves at the disadvantage.
https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36...
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.
you didn't read the comment, did you?
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?
Any mirror?