Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disrupting supply chain attacks on NPM and GitHub Actions

github.blog

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#51

Post by summarybot »

insanitybit wrote: post #39
summarybot wrote: post #34

Earlier quoted context omitted.

In my opinion, things like scanners should not need to exist if npm's parent company, GitHub, were to take responsibility for what was published to npm. If Walmart sells you an item that ends up being a handgrenade there would be hell to pay. In this example, Walmart cannot simply say that Walmart is not in charge of what goes into the item and therefore "buyer beware." Yet, this is precisely what GitHub does with ev…

Walmart and Github are so different. Walmart doesn't let anyone come in and set up a booth to sell things, Github does. Thinking that Github should take responsibility for what's hosted on it is... well, radical, to say the least. What you're suggesting is a radical departure from how free software has been distributed historically. That goes well beyond Github and NPM.

You say "free software" but npm is no longer a small open-source project with a federated rulership, it is owned and operated by a for-profit technological giant. There was a radical departure already, when Github acquired npm. It sounds like your stance is "if something is given away for free, consumer protections are not necessary." But if I get poisoned by free samples given away at a grocery store, who is on the hook? Buyer beware? The onus is on the organization that distributes the food, in the case of the grocery store. It is unreasonable for every person to become a food chemist to be able to ascertain the safety of every single food product. Rather, we as a society agree to put that onus on the distribution. This is no different.

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#52

Post by insanitybit »

summarybot wrote: post #51
insanitybit wrote: post #39

Earlier quoted context omitted.

Walmart and Github are so different. Walmart doesn't let anyone come in and set up a booth to sell things, Github does. Thinking that Github should take responsibility for what's hosted on it is... well, radical, to say the least. What you're suggesting is a radical departure from how free software has been distributed historically. That goes well beyond Github and NPM.

You say "free software" but npm is no longer a small open-source project with a federated rulership, it is owned and operated by a for-profit technological giant. There was a radical departure already, when Github acquired npm. It sounds like your stance is "if something is given away for free, consumer protections are not necessary." But if I get poisoned by free samples given away at a grocery store, who is on the…

This isn't about npm, it's about who publishes to npm. This isn't a grocery story.

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#53

Post by zzo38computer »

acdha wrote: post #46
zzo38computer wrote: post #36

My only use of GitHub Actions specifies permissions that only allow it to write to the issue tracker, so if the program it executes (which is the "gh" program) is malicious then the only damage it can cause is to the issue tracker and not to the repository itself (unless GitHub Actions itself is compromised). Furthermore, there are no private files (I do not host private files on remote services such as GitHub), so t…

> I think one thing that would help is to support mutual TLS, with X.509 certificate chains for authentication. This is more secure than personal access tokens This adds an large amount of overhead and complexity (i.e. you now need to manage a revocation list) but you didn’t really explain any benefit which isn’t already present except for the possibility of restricting access to the private key. That can have some b…

I agree that benefits come from fine-grained permissions; however, for the fine permissions of user authentication (and API authentication), I think it would help to use X.509 certificate chains. The certificate can include a extension for specifying the permissions that it grants (a permission will only be granted if all certificates in the chain grant that permission). This avoids needing to login or use 2FA in order to set up new API keys or access tokens, and prevents problems with misauthentication with the wrong server (personal access tokens don't help much compared with passwords, but X.509 does help). Merely using X.509 won't cause it to have fine-grained permissions, but they can be combined in the way that I described. (This use of X.509 can also be used to allow someone else to operate on your behalf with limited permissions; in this case, a client would issue a certificate to a server, and that server would then also be a client to GitHub.)

If there is a broken design of GitHub Actions, that is another issue, and neither TLS nor X.509 is the issue with that. (Also, GitHub Actions could hopefully be made to allow finer permissions if the existing permissions are not fine enough; that is not related to X.509 at all.)

Avoiding too many dependencies, is another thing to do.

And, signed releases is another thing to do, and is helpful for additional reasons (unrelated to authentication with GitHub, but useful for knowing that you published it rather than someone else (without having to trust GitHub with it)). The key used to sign the release might or might not match that in the X.509 certificate used to authenticate with TLS; there are some benefits if it does (such as if you have published your certificates that someone else can check, or your mention of Yubikey), but it doesn't have to (e.g. because you have multiple certificates, because multiple people are publishing releases, because you have some other reason to not use the same certificate for the other purpose, etc).

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#54

Post by lrvick »

inigyou wrote: post #43
lrvick wrote: post #40

Earlier quoted context omitted.

I paid $8 for the recently expired email domain of the sole author of NPM package "foreach", so then control to ship any code I wanted to 70k companies was just a support ticket or password reset away. 72 hours would not make a difference here. Talked to NPM about this when it went viral, and once again all they could say was enabling package signing, even optionally, would discourage inexperienced people from contri…

Who chose to depend on "foreach"? Millions of ill-advised people did. The author did not choose that.

If an author is not willing to do responsible release engineering they should lose their publishing ability and have their project marked as unmaintained. This would force people to migrate to better maintained code, or find responsible volunteer maintainers to maintain it. Everyone wins.

Even when you drop off food at a food pantry for consumption by strangers there is a basic expectation it is not spoiled or dangerous.

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#55

Post by lrvick »

acdha wrote: post #49
lrvick wrote: post #37

It is fascinating how far people will go to do anything else at all other than having authors cryptographically sign their packages like every Linux package manager that matters since 1996. Linux package managers like debian/apt also ship hundreds of signed NPM packages. In other words the unpaid Linux community has once again solved a problem Microsoft fundamentally failed to. Some things never change.

What keeps Linux distributions safer is that fewer people are able to push updates and there’s a time delay. The compromises are because people exploit release pipelines and if your build infrastructure is compromised it’ll merrily sign the compromised packages as well.

Which is why automated signatures in release pipelines are usually meaningless. Authors must sign their code on their own hardware before it is published so we can tell when the signing key changes and pay extra special attention to that, and maybe a longer delay.

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#56

Post by summarybot »

insanitybit wrote: post #52
summarybot wrote: post #51

Earlier quoted context omitted.

You say "free software" but npm is no longer a small open-source project with a federated rulership, it is owned and operated by a for-profit technological giant. There was a radical departure already, when Github acquired npm. It sounds like your stance is "if something is given away for free, consumer protections are not necessary." But if I get poisoned by free samples given away at a grocery store, who is on the…

This isn't about npm, it's about who publishes to npm. This isn't a grocery story.

I don't appreciate a pedantic interpretation of the analogy; consider any marketplace where the sellers are not the platform: Amazon, FB Marketplace, Etsy, eBay, and so forth. When a consumer gets burned, who gets in trouble?

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#57

Post by insanitybit »

summarybot wrote: post #56
insanitybit wrote: post #52

Earlier quoted context omitted.

This isn't about npm, it's about who publishes to npm. This isn't a grocery story.

I don't appreciate a pedantic interpretation of the analogy; consider any marketplace where the sellers are not the platform: Amazon, FB Marketplace, Etsy, eBay, and so forth. When a consumer gets burned, who gets in trouble?

I don't appreciate analogies at all. If you want to make a point about Github, talk about Github.

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#58

Post by hinkley »

TacticalCoder wrote: post #42
hinkley wrote: post #32

Earlier quoted context omitted.

At this rate I'm going to have "npm is by far the worst thing about NodeJS" printed on my gravestone.

> "npm is by far the worst thing about NodeJS" I'll come and add: "after JavaScript" .

That's the cover charge. It's like showing up at a karaoke bar and then complaining about all the drunken covers being terrible.

Re: Disrupting supply chain attacks on NPM and GitHub Actions

#59

Post by summarybot »

insanitybit wrote: post #57
summarybot wrote: post #56

Earlier quoted context omitted.

I don't appreciate a pedantic interpretation of the analogy; consider any marketplace where the sellers are not the platform: Amazon, FB Marketplace, Etsy, eBay, and so forth. When a consumer gets burned, who gets in trouble?

I don't appreciate analogies at all. If you want to make a point about Github, talk about Github.

Already did.

Github owns and controls NPM, npm is no longer a community-controlled project. Therefore, Github should [happily] take on the duties, responsibilities, and obligations of a software publisher to provide either: trust ratings on packages and code, or literally and not figuratively scan every single package-and-version on npm for appropriateness.

But obviously you already got that point and just wanted to exert some modicum of bossiness and control by having me regurgitate my well-formulated thoughts for a third time while painting inside the lines you insist are relevant.

Post reply on HN