> The attacker creates FAKE orgs/repos and pushes clones of LEGIT projects to github.
Yeah, anyone can push anything to their own GitHub accounts/orgs, including malware. We know that.
Save yourself some time. Flagged.
It's absolutely true that the wording is wrong, but I think it's reasonable to accept a jumped the gun rather than a clickbait explanation.
The presence of large volumes of project copies on typosquats and synonym squats is still a problem, they'll still get indexed by tools, and then the tools boost their page rank, and eventually some make it to users. Given that the Go init payload contains an RCE and not just a data collection, there is still something of note there. Yes it's not 35k compromised projects, but it is a broad deployment of malicious code.
However:
1. The scale is pretty worrying. Given the total number of repos on GitHub (> 100M) it's a drop in the ocean, but still huge.
2. Typo-squatting on, say, PyPI or npmjs is certainly note-worthy, and this is a very similar attack.
3. At least some of the infected forks had several stars, some from ~ 5 year old accounts, so apparently some people were using them.
4. The original Twitter thread did note that infected forks were being created — it just didn't emphasise that this was the only attack surface, probably because the author didn't realise.
> If you flag, please don't also comment that you did.
and 13K of the search results come from this org
> The attacker creates FAKE orgs/repos and pushes clones of LEGIT projects to github.
Pure scaremongering and/or attention seeking.
Edit: Sorry, I posted two similar comments because my first top level one was immediately downvoted to the bottom. It has since come back up.
Fanatics who believe otherwise will still clone those projects so that they are on sacred ground, but the practice should be frowned upon and fought against.
Another detrimental effect of GitHub is that they have trained users to accept public "forks" (a misnomer) as the usual way to contribute even trivial patches. This lowers the bar for accepting and trusting non-official repositories.
GitHub has devalued the brand of large projects and has introduced the age of industrialized software development by creating an addictive environment where software politicians thrive by manipulating their social networks and working on their personal brand.
Seems like the solution is "don't just copy random github urls into your code" ?
Huh? What does that mean?
It's like if I make a copy of the New York Times website but replace the cover image with nudity and put it on a different URL and someone tweets "omg NYT has nudity on the front page" and clarifies, vaguely, 10 tweets down that it was actually not the real NYT but a clone.
I'm not convinced that the author is spinning it this way on purpose (ie for maximum emotional effect / retweets / internet points) or if it just comes from being too close to the subject matter, but it's pretty misleading either way.
But what's the repo for "crypto" or "js"?
GPG signed commits by the legitimate users do not contain the malware
https://github.com/promonlogicalis/asn1/commit/7bdca06d0edf8...
Source: https://mobile.twitter.com/stephenlacy/status/15547180866572...
j19544519 - seems to be the username on this hosting.
so this will send data to the hacker's network if we clone and build the wrong repo right?
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.
Actually yes, this is all about supply chain attacks. Typosquatting is one of the most common methods. It goes under this category.
The whole point of 'Open Source' is that we can use code which might otherwise be a bit 'random'.
It's not 'Institutionalized Open Source' it's just 'Open Source' i.e. we're not all Torvalds.
So, credibility etc. is a very fickle thing otherwise, this is a serious security issue and we really don't have answers.
We used to think about code as 'logic that works' but now we have other criteria, I wonder if our FOSS models need to adapt bit.
I suppose the message is "read the code you're using" but that is hard for big libraries and frameworks.
Obviously using one's code where they are impersonating someone else is a big red flag.
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? Do I have to use a custom merge flow that also rewrites authorship from "Alice <alice@gmail.com>" to "Alice <alice@gmail.com.fake.unsigned.suffix>"?
2. What happens if your gpg key is compromised or expires? Are all your previous repos now invalid? I can't fork it because it contains a commit authored by you, but with a revoked or expired gpg key?
3. What happens to previous commits if I enable this feature? Can all my unsigned commits no longer be pushed to github? I made a commit in a project at work 5 years ago with my email, but didn't sign it.. if that company wants to open source that project on github, do they now have to rewrite history to change the author on my unsigned commits?
4. What does the "squash merge" button on github PRs do for your PRs?
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 when looking at the commit history of a project and seeing warnings after my contributions were merged in.
I'm not sure if it's a me issue or a PGP issue or a GitHub issue, but it's a pretty broken system.
Also does not help that enough percentage of repo owners would accept then signed PRs to their projects.
The fake accounts can be created with gpg signed fake commits too.
You're just adding an extra step that's hardly going to stop someone.
I don't know what the answer is, but the model has to be changed.
If you impersonated all these real repos, made npm, pypi packages for them etc and also updated the readme I think you could catch some people off guard.
https://www.theregister.com/2022/07/06/npm_supply_chain_atta...
It seemed pretty clear to me that GGP misunderstood this as malicious code being inserted into existing trusted repositories, which is a common misunderstanding in the rest of the comments, and seems to be encouraged by the poor wording of the tweets.
It is attack regardless. Someone has made something malicious which affects for the process for the end-user acquiring the final software.
> it seemed pretty clear to me that GGP misunderstood this as malicious code being inserted into existing trusted repositories, which is a common misunderstanding in the rest of the comments, and seems to be encouraged by the poor wording of the tweets.
I think the author just wanted to get attention and be sensational. He deliberately did not mention that they are forks. Just rushed to report findings.
These repos were not taken over but cloned and made to look like another repo via similar naming.
I think what you're looking for is more "all accounts must be verified via payment/identity" then you really know who is making "random clones" and "look-a-likes" w/ malware.
But you've got a whole host of other problems in the process.
The check is that commits at the point of merge have a valid signature. Historical commits are part of the history and as such cannot be changed without an additional commit (with a valid signature). Previous unsigned commits are deemed trusted at the point you begin signing and checking.
Squash merge breaks stuff and shouldn't be used. To complete things, the restricted set of operations exposed through the GUI should sign using gitlab's or github's key (or some accepted bot key we've set), with the check happening on the input commits, but AFAICT that's not supported yet.
IMO I don't see how this is desirable enough to be worth it.
Wider adoption of GPG signatures would be much more impactful.
It could make sense to use a blockchain for key distribution/key discovery/revocation, effectively as a replacement of PKI, though.
(Not sure if such a field already exists in the commit blob)
That's not how git works.
This design doesn’t preclude the usage of additional information in the commit blob that isn’t used to compute the hash.
(Think for example how file access times do not affect its hash)
https://git-scm.com/docs/git-notes
"Adds, removes, or reads notes attached to objects, without touching the objects themselves."