Comment by nstart | Hacker News Reader

Comment by nstart | Hacker News Reader

I don't quite understand how this is working tbh. I looked at one of the affected repos, ironically named "reworm".

The malicious code was introduced in this commit - https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6...

It says coauthored by dependabot and refers to a PR opened in 2020 (https://github.com/pedronauck/reworm/pull/28).

That PR itself was merged in 2020 here - https://github.com/pedronauck/reworm/commit/df8c1803c519f599...

But the commit with the worm (d50cd8c), re-introduces the same change from df8c180 to the file `yarn.lock`.

And when you look at the history of yarn.lock inside of github, all references to the original version bump (df8c180) are gone...? In fact if you look at the overall commit history, the clean df8c180 commit does not exist.

I'm struggling to understand what kind of shenanigans happened here exactly.

Someone has maintainer/admin access to the repository and has force-pushed to master overwriting the git history.

Notice that the original commit is verified: https://github.com/pedronauck/reworm/commit/df8c1803c519f599...

While the malicious one is not: https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6...

This reveals a deeper flaw in the whole git/npm pipeline (would apply to other systems like PyPI etc, not npm exclusively). These systems should operate on a "pull" model, not a push. The system should have rejected a build that wasn't derived from the latest in its repository. It would be quite easy in concept to set up one's own system to pull every source on npm and alert when the upstream has deviated.

The malicious code was added to package.json, not yarn.lock

Yup. That's correct. And I understand that. I was looking at the changes to yarn.lock that got reintroduced. I couldn't figure out what was happening. It turns out that not only was it force pushed, but GitHub also retains the old commit information even if it's been "deleted".

I still don't quite understand what GitHub is doing to allow someone to say that dependabot coauthored a spoofed commit. This isn't the commit message itself I'm talking about. It's the GitHub interface that officially recognizes this as a dependabot co authored commit. My hunch is that the malicious author squashed two commits, the original good commit to yarn.lock and a malicious change to package.json, and that somehow maintains the dependabot authorship instead of reassigning it fully to the squash-er.

Reply on news.ycombinator.com