Live data from Hacker News

Polyfill supply chain attack hits 100K+ sites

sansec.io

171–180 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#171

Earlier quoted context omitted.

The problem w/ Boeing is not the inability of people to manage complexity but of management's refusal to manage complexity in a responsible way. For instance, MCAS on the 737 is a half-baked implementation of the flight envelope protection facility on modern fly-by-wire airliners (all of them, except for the 737). The A320 had some growing pains with this, particularly it had at least two accidents where pilots tried…

Okay but your entire comment is riddled with mentions of complex systems (flight envelope system?) which proves the point of the parent comment. "Management" here is a group of humans who need to deal with all the complexity of corporate structures, government regulations, etc.. while also dealing with the complexities of the products themselves. We're all fallible beings.

Boeing management is in the business of selling contracts. They are not in the business of making airplanes. That is the problem. They relocated headquarters from Seattle to Chicago and now DC so that they can focus on their priority, contracts. They dumped Boeing's original management style and grafted on the management style of a company that was forced to merge with Boeing. They diversified supply chain as a form of kickbacks to local governments/companies that bought their 'contracts'.

They enshiftified every area of the company, all with the priority/goal of selling their core product, 'contracts', and filling their 'book'.

We are plenty capable of designing Engineering systems, PLMs to manage EBOMs, MRP/ERP systems to manage MBOMs, etc to handle the complexities of building aircraft. What we can't help is the human desire to prioritize enshitfication if it means a bigger paycheck. Companies no longer exist to create a product, and the product is becoming secondary and tertiary in management's priorities, with management expecting someone else to take care of the 'small details' of why the company exists in the first place.

Re: Polyfill supply chain attack hits 100K+ sites

#172
post #91

Earlier quoted context omitted.

> I always prefer to self-host my dependencies Ime this has always been standard practice for production code at all the companies I've worked at and with as a SWE or PM - store dependencies within your own internal Artifactory, have it checked by a vuln scanner, and then called and deployed. That said, I came out of the Enterprise SaaS and Infra space so maybe workflows are different in B2C, but I didn't a differenc…

> I guess my question is why your employer or any other org would not follow the model above? When you look at Artifactory pricing you ask yourself 'why should I pay them a metric truckload of money again?' And then dockerhub goes down. Or npm. Or pypi. Or github... or, worst case, this thread happens.

There are cheaper or free alternatives to Artifactory. Yes they may not have all of the features but we are talking about a company that is fine with using a random CDN instead.

Or, in the case of javascript, you could just vendor your dependencies or do a nice "git add node_modules".

Re: Polyfill supply chain attack hits 100K+ sites

#173
post #52

Earlier quoted context omitted.

I always prefer to self-host my dependencies, but as a developer who prefer to avoid an npm-based webpack/whatever build pipeline it's often WAY harder to do that than I'd like. If you are the developer of an open source JavaScript library, please take the time to offer a downloadable version of it that works without needing to run an "npm install" and then fish the right pieces out of the node_modules folder. jQuery…

> I always prefer to self-host my dependencies Js dependencies should be pretty small compared to images or other resources. Http pipelining should make it fast to load them from your server with the rest The only advantage to using one of those cdn-hosted versions is that it might help with browser caching

> Http pipelining should make it fast to load them from your server with the rest

That's true, but it should be emphasized that it's only fast if you bundle your dependencies, too.

Browsers and web developers haven't been able to find a way to eliminate a ~1ms/request penalty for each JS file, even if the files are coming out of the local cache.

If you're making five requests, that's fine, but if you're making even 100 requests for 10 dependencies and their dependencies, there's a 100ms incentive to do at least a bundle that concatenates your JS.

And once you've added a bundle step, you're a few minutes away from adding a bundler that minifies, which often saves 30% or more, which is usually way more than you probably saved from just concatenating.

> The only advantage to using one of those cdn-hosted versions is that it might help with browser caching

And that is not true. Browsers have separate caches for separate sites for privacy reasons. (Before that, sites could track you from site to site by seeing how long it took to load certain files from your cache, even if you'd disabled cookies and other tracking.)

Re: Polyfill supply chain attack hits 100K+ sites

#174
post #61

> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…

The same concept should be applied to container based build pipelines too. Instead of pulling dependencies from a CDN or a pull through cache, build them into a container and use that until you're ready to upgrade dependencies. It's harder, but creates a clear boundary for updating dependencies. It also makes builds faster and makes old builds more reproducible since building an old version of your code becomes as si…

> The same concept should be applied to container based build pipelines too. Instead of pulling dependencies from a CDN or a pull through cache, build them into a container and use that until you're ready to upgrade dependencies.

Everything around your container wants to automatically update itself as well, and some of the changelogs are half emoji.

Re: Polyfill supply chain attack hits 100K+ sites

#175

The phrase "supply chain attack" makes it sound like it's some big, hard to avoid problem. But almost always, it's just developer negligence: 1. Developer allows some organization to inject arbitrary code in the developer's system 2. Organization injects malicious code 3. Developer acts all surprised and calls it an "attack" Maybe don't trust 3rd parties so much? There's technical means to avoid it. Calling this situ…

What good does this comment do beside allow you to gloat and put others down? Like, Christ. Are you telling me that you’d ever speak this way to someone in person?

I have no doubt that every single person in this thread understands what a supply chain attack is.

You are arguing over semantics in an incredibly naive way. Trust relationships exist both in business and in society generally. It’s worth calling out attacks against trust relationships as what they are: attacks.

Re: Polyfill supply chain attack hits 100K+ sites

#176
post #137

Earlier quoted context omitted.

agreed, but if a company is making millions for the security of software, the incentive is to keep it secure so customers stick with it. Remember the lastpass debacle, big leak and lost many customers...

Directly security-focused products like lastpass are the only things that have any market pressure whatsoever on this, and that's because they're niche products for which the security is the only value-add, marketed to explicitly security-conscious people and not insulated by a whole constellation of lock-in services. The relevant security threats for the overwhelming majority of people and organizations are breaches…

Even for security-related products the incentives are murky. If they're not actually selling you security but a box on the compliance bingo then it's more likely that they actually increase your attack surface because they want to get their fingers into everything so they can show nice charts about all the things they're monitoring.

Re: Polyfill supply chain attack hits 100K+ sites

#177
post #50

Earlier quoted context omitted.

yes you just put integrity="sha384-whatever" and you're good to go

Sure, but why risk a developer making a typo, saying integrty="sha384-whatever", and that attribute simply being ignored in the html?

“A developer could typo something” is kind of weak because you could use this argument for basically anything.

Re: Polyfill supply chain attack hits 100K+ sites

#178

Earlier quoted context omitted.

It's a competence crisis not a complexity one. https://www.palladiummag.com/2023/06/01/complex-systems-wont...

We haven’t gotten smarter or dumber. But we have exceeded our ability to communicate the ideas and concepts, let alone the instructions of how to build and manage things. Example: a junior Jiffy Lube high school dropout in 1960 could work hard and eventually own that store. Everything he would ever need to know about ICE engines was simple enough to understand over time… but now? There are 400 oil types, there are cl…

>Example: a junior Jiffy Lube high school dropout in 1960 c

Nowadays the company wouldn't hire a junior to train. They'll only poach already experienced people from their competitors.

Paying for training isn't considered worthwhile to the company because people wont stay.

People won't stay because the company doesn't invest in employees , it only poaches.

Re: Polyfill supply chain attack hits 100K+ sites

#179
post #52

> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…

I always prefer to self-host my dependencies, but as a developer who prefer to avoid an npm-based webpack/whatever build pipeline it's often WAY harder to do that than I'd like. If you are the developer of an open source JavaScript library, please take the time to offer a downloadable version of it that works without needing to run an "npm install" and then fish the right pieces out of the node_modules folder. jQuery…

I suspect this is more relevant for people who aren't normally JavaScript developers. (Let's say you use Go or Python normally.) It's a way of getting the benefits of multi-language development while still being mostly in your favorite language's ecosystem.

On the Node.js side, it's not uncommon to have npm modules that are really written in another language. For example, the esbuild npm downloads executables written in Go. (And then there's WebAssembly.)

In this way, popular single-language ecosystems evolve towards becoming more like multi-language ecosystems. Another example was Python getting 'wheels' straightened out.

So the equivalent for bringing JavaScript into the Python ecosystem might be having Python modules that adapt particular npm packages. Such a module would automatically generate JavaScript based on a particular npm, handling the toolchain issue for you.

A place to start might be a Python API for the npm command itself, which takes care of downloading the appropriate executable and running it. (Or maybe the equivalent for Bun or Deno?)

This is adding still more dependencies to your supply chain, although unlike a CDN, at least it's not a live dependency.

Sooner or later, we'll all depend on left-pad. :-)

Re: Polyfill supply chain attack hits 100K+ sites

#180

I tend to avoid [other people's] dependencies like the plague. Not just for security, but also for performance and Quality. I think I have a grand total of two (2), in all my repos, and they are ones that I can reengineer, if I absolutely need to (and I have looked them over, and basically am OK with them, in their current contexts). But I use a lot of dependencies; it's just that I've written most of them. What has…

In most professional development contexts your puritan approach is simply unjustified. You’re obviously feeling very smug now, but that feeling is not justified. I note that you say “in all my repos”. What is the context in which these repositories exist? Are they your hobby projects and not of any real importance? Do you have literally anyone that can call you out for the wasted effort of reimplementing a web server in assembly because you don’t trust dependencies? I hope that you’re making your own artisanal silicon from sand you dug yourself from your family farm. Haven’t you heard about all those Intel / AMD backdoors? Sheesh.

EDIT: you’re an iOS developer. Apples and oranges. Please don’t stand on top of the mountain of iOS’s fat standard library and act like it’s a design choice that you made.

Post reply on HN