Zum Inhalt der Seite gehen

If there was malicious code in a legitimate project hosted on #codeberg, would we remove access to it, including for security researchers?

Short: No!

We are considering how to prevent fetching malicious code by accident, though.

In any case, we are open to collaborating with security researchers. Interested? Help us build a malware hunting team: codeberg.org/Codeberg/Contribu…

Background: #GitHub locked access to source code of xz, which was background of active investigation from the community.


[Team] Malware hunting

### About the team This is an idea in case someone is interested to get involved with this topic. Codeberg is abused for spreading malware, like many other places. It is certainly interesting, because a lot of malware we see is either new.
Codeberg.org
#codeberg #github
Als Antwort auf Codeberg.org

Codeberg.org
Codeberg.org
• •
To people looking for an archive of the XZ code, you might want to check out tukaani.org/xz-backdoor/ which links to git.tukaani.org/. GitHub is not the only source of truth, although meta information about the Pull Requests is locked in to this silo.

git.tukaani.org

git.tukaani.org
Als Antwort auf Codeberg.org

Olivier
Olivier
• •
Many thanks for your work on openess. It's another proof that git history is not sufficient and we cannot tolerate a locked silo like Github. PR, issues, comments and everything else are an essential part of the repository, the code is not enough.
Als Antwort auf Codeberg.org

minecraftchest1
minecraftchest1
• •
One idea I have for preventing accidental fetches of malicious code would be to prevent access through the primary domain, and require the use of a seperate (sub)domain such as [caution.codeberg.org](caution.codeberg.org), or [codeberg-caution.org](codeberg-caution.org). Weither this is done throgh a seperate instance it is cloned to, or via special handeling in the forejo would be up to debate.
Als Antwort auf Codeberg.org

Mensh123
Mensh123
• •
Good question... Maybe prevent direct git access for non-contributors and show a banner on the website (where you could still downlad the repo)? There shiuld also be a system to let the maintainers request to get out of this state to allow automated build systems to build the fixed version.
Als Antwort auf Codeberg.org

Dentaku (Thomas Renger)
Dentaku (Thomas Renger)
• •

@necrosis If you don't want people to fetch malicious code by accident:

* create a branch for security researchers to work on (a tag would actually be sufficient, but branches are even easier in git)
* create a commit on the main branch removing everything except a README.md explaining the situation

@Robyn :antifa:
Als Antwort auf Codeberg.org

waldi
waldi
• •
Do you have a process to lock those projects from tampering?
Als Antwort auf waldi

Codeberg.org
Codeberg.org
• •

@waldi We don't have a precedence case yet. The easiest option would be to require users to sign in to Codeberg, so they are forced to see a warning and prevent distribution via automation like CI.

However, it requires everyone to create an account to investigate the code, so we are working on a better solution.

@waldi

Diese Webseite verwendet Cookies. Durch die weitere Benutzung der Webseite stimmst du dieser Verwendung zu. https://inne.city/tos

⇧