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

Tinycolor supply chain attack post-mortem

sigh.dev

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Tinycolor supply chain attack post-mortem

#71

Post by acdha »

arccy wrote: post #69
acdha wrote: post #47

Earlier quoted context omitted.

There’s also a cost that installs take much longer, you need the full toolchain installed, and are no longer reproducible due to variations in the local build environment. If everything you do is a first-party CI build of a binary image you deploy, that’s okay but for tools you’re installing outside of that kind of environment it adds friction.

All not problems for Go: pull through proxy is fast and eliminates the need for a toolchain if you just want to download, and Go builds are fully bit-for-bit reproducible.

That would be an impossible expectation on the Go toolchain. The pull through proxy can’t magically avoid the need to transfer all dependencies to my device, especially including any native code or other resources. Large projects are going to need to download stuff - think about how some cloud clients build code dynamically from API definition or how many codecs wrap native code.

Similarly, newer versions of Go change the compiler–which to be first is a good thing–so even if I start with the same source in Git I might not have the same compiled bytes in the result.

Again, mone of this is a bad thing: it just means that I want to compile binaries and ship those so they don’t unexpectedly change in the future and my CI pipeline doesn’t need to have a full Go build stage when all I want is to use Crane to do something with a container.

Re: Tinycolor supply chain attack post-mortem

#72

Post by acdha »

procaryote wrote: post #62
acdha wrote: post #47

Earlier quoted context omitted.

There’s also a cost that installs take much longer, you need the full toolchain installed, and are no longer reproducible due to variations in the local build environment. If everything you do is a first-party CI build of a binary image you deploy, that’s okay but for tools you’re installing outside of that kind of environment it adds friction.

As a lot of these npm "packages" are glorified code snippets that should never have been individual libraries, perhaps this would drive people to standardise and improve the build tooling, or even move towards having sensibly sized libraries?

Yes, there’s widespread recognition that the small standard library makes JavaScript uniquely dependent on huge trees of packages, and that many of them (e.g. is-arrayish from last week) are no longer necessary but still linger from the era where it was even worse.

However, this isn’t a problem specific to JavaScript – for example, Python has a much richer standard library and we still see the same types of attacks on PyPI. The entire open source world has been built on an concept of trust which was arguably always more optimistic than realistic, and everyone is pivoting – especially after cryptocurrency’s inherent insecurity created enough of a profit margin to incentivize serious attacks.

Re: Tinycolor supply chain attack post-mortem

#73

Post by notTooFarGone »

practorz wrote: post #67
rectang wrote: post #40

Earlier quoted context omitted.

I’ve done all those things myself (past ASF member where all that and more was SOP), so I realize what I’m asking for. It’s not crazy for authors of small packages to form small collectives and serve as each others’ trusted third parties. In any case, if the choice is “frequent supply chain compromise, take it or leave it”, the answer is of course “leave it”. If we need to pay for curated packages because the problem…

>In any case, if the choice is “frequent supply chain compromise, take it or leave it”, the answer is of course “leave it”. There's another choice: vendor your dependencies and manually review and vet updates. That solves all your problems, no need for "trusted third parties", you are the one vetting it, only need to trust yourself.

You just make a problem that a couple of thousand people have to a problem for a couple of million.

Fix it early so the user does not have to deal with the complexity is most often the best approach.

Re: Tinycolor supply chain attack post-mortem

#74

Post by tcoff91 »

klysm wrote: post #58
tcoff91 wrote: post #37

Earlier quoted context omitted.

Publishing a package involves 2 phases: uploading the package to npmjs, and making it availble to users. Right now these 2 phases are bundled together into 1 operation. I think the right way to approach this is to unbundle uploading the packages & publishing packages so that they're available to end-users. CI systems should be able to build & upload packages in a fully automated manner. Publishing the uploaded packag…

npm should require this with packages that have a large enough blast radius

npm should require it for all packages.

Re: Tinycolor supply chain attack post-mortem

#75

Post by whatevaa »

tcoff91 wrote: post #37
mnahkies wrote: post #32

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention. I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code. I'd love to see either npm or GitHub provide an easy, out the box way, for me to…

Publishing a package involves 2 phases: uploading the package to npmjs, and making it availble to users. Right now these 2 phases are bundled together into 1 operation. I think the right way to approach this is to unbundle uploading the packages & publishing packages so that they're available to end-users. CI systems should be able to build & upload packages in a fully automated manner. Publishing the uploaded packag…

Which CI would that be?

Re: Tinycolor supply chain attack post-mortem

#76

Post by whatevaa »

arp242 wrote: post #46
mnahkies wrote: post #32

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention. I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code. I'd love to see either npm or GitHub provide an easy, out the box way, for me to…

I'm feeling that maybe the entire concept of "publishing packages" is something that's not really needed? Instead, the VCS can be used as a "source of truth", with no extra publishing step required. This is how Go works: you import by URL, e.g. "example.com/whatever/pkgname", which is presumed to be a VCS repo (git, mercurial, subversion, etc.) Versioning is done by VCS tags and branches. You "publish" by adding a ta…

Doubt that many read those diffs of dependencies.

Re: Tinycolor supply chain attack post-mortem

#77

Post by whatevaa »

rectang wrote: post #22
Hackbraten wrote: post #19

Earlier quoted context omitted.

How are you supposed to gain collaborators for a project that no one can possibly find?

There are ways, but at a high level, I don't care. I hate how modern package managers have come to value author convenience over downstream user security.

Ahh, the classic I don't care. What if other people don't care about your problems? What if both sides don't care about each other? What then?

Re: Tinycolor supply chain attack post-mortem

#78

Post by rectang »

whatevaa wrote: post #77
rectang wrote: post #22

Earlier quoted context omitted.

There are ways, but at a high level, I don't care. I hate how modern package managers have come to value author convenience over downstream user security.

Ahh, the classic I don't care. What if other people don't care about your problems? What if both sides don't care about each other? What then?

We wait and see whether the supply chain attacks crescendo to a crisis and force NPM's hand. In the meantime I'm doing everything I can to avoid NPM and to uphold "just don't use the software if you don't like it"... but people like myself don't always have a choice.

Re: Tinycolor supply chain attack post-mortem

#79

Post by arccy »

acdha wrote: post #71
arccy wrote: post #69

Earlier quoted context omitted.

All not problems for Go: pull through proxy is fast and eliminates the need for a toolchain if you just want to download, and Go builds are fully bit-for-bit reproducible.

That would be an impossible expectation on the Go toolchain. The pull through proxy can’t magically avoid the need to transfer all dependencies to my device, especially including any native code or other resources. Large projects are going to need to download stuff - think about how some cloud clients build code dynamically from API definition or how many codecs wrap native code. Similarly, newer versions of Go chang…

sometimes i think shipping source + compiler would be faster...

the other day i was wondering why the terraform aws provider binary was now around 800MB compiled https://github.com/hashicorp/terraform-provider-aws/issues/3...

Re: Tinycolor supply chain attack post-mortem

#80

Post by pabs3 »

orphea wrote: post #66
pabs3 wrote: post #60

Earlier quoted context omitted.

mTLS aka TLS client certs seems like the way to go.

How is a client cert not another glorified static password? It would have been stolen from repo secrets the same way.

You don't store them in repos on disk, but in a HSM so they can't be stolen, and then you protect signing access to them based on service/process information.
Post reply on HN