31–40 of 79 posts
TL;DR: These are forks by unknown people containing malware. I see no indication in the linked thread of even a single successful compromise actually occurring, or malicious code making it into legitimate upstream projects.
https://github.com/promonlogicalis/asn1/commit/7bdca06d0edf8...
Earlier quoted context omitted.
They have something under Settings > SSH and GPG keys where you can enable Vigilant mode. While that still allows pushing unsigned commits, it will flag them with a warning batch. I had this on for a while, but unfortunately as some open source projects tend to rebase commits before pushing them, this was causing warnings to be shown (as the rebase breaks my signature), so I turned it off again as to not scare people…
Good to know, I was not aware. The squash/rebase issue is definitely problematic, though a tree of signatures could be appended to each commit. Now... this does break how commits are currently signed.
Earlier quoted context omitted.
Good to know, I was not aware. The squash/rebase issue is definitely problematic, though a tree of signatures could be appended to each commit. Now... this does break how commits are currently signed.
Would this be a problem if commits were stored in a blockchain? Rebase would effectively fork the chain.
note that it's 35,613 code results, not 35k repos and 13K of the search results come from this org https://github.com/redhat-operator-ecosystem
TL;DR: These are forks by unknown people containing malware. I see no indication in the linked thread of even a single successful compromise actually occurring, or malicious code making it into legitimate upstream projects.
Here is a commit with malicious code from a Microsoft employee: https://github.com/promonlogicalis/asn1/commit/7bdca06d0edf8...
Earlier quoted context omitted.
That would change the commit hash, at least if you want it to survive a clone of the repo. Of you'd store it externally so that it would only be able to be shown in the webui then it's of limited use, but maybe better than nothing.
I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. GitHub could then make use of this data to populate whatever. (Not sure if such a field already exists in the commit blob)
That's not how git works.
TL;DR: These are forks by unknown people containing malware. I see no indication in the linked thread of even a single successful compromise actually occurring, or malicious code making it into legitimate upstream projects.
Here is a commit with malicious code from a Microsoft employee: https://github.com/promonlogicalis/asn1/commit/7bdca06d0edf8...
Earlier quoted context omitted.
Let me ask a few questions about this scheme: 1. What happens when someone needs to resolve a merge conflict involving your commit? Let's say I maintain a fork of an open source repo to add some feature, and I periodically merge back in upstream changes... that necessarily involves resolving conflicts. By default, git retains author ownership, and now the commit is unsigned, but it's really your work. What do we do?…
And now we’re on the fast track to adopt a blockchain as a tamper evident mechanism.
Oh dear. This is a gigantic disaster. If lots of software released today haven't been pinning their versions on release (especially Electron apps) or signing their commits if they are open-source, then this is a chaotic supply chain attack waiting to happen and is more worse than I thought. But really it is yet, another reason to avoid GitHub entirely and just self-host using GitLab or Gitea.
so this will send data to the hacker's network if we clone and build the wrong repo right?