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

We should all be using dependency cooldowns

blog.yossarian.net

Post reply on HN
Print view View original

171–180 of 287 posts

Re: We should all be using dependency cooldowns

#171

Post by buu700 »

xmodem wrote: post #165
buu700 wrote: post #139

Earlier quoted context omitted.

Sure, but that doesn't contradict the case for conservatism in adding new dependencies. A maximally liberal approach is just as bad as the inverse. For example: * Introducing a library with two GitHub stars from an unknown developer * Introducing a library that was last updated a decade ago * Introducing a library with a list of aging unresolved CVEs * Pulling in a million lines of code that you're reasonably confide…

> Introducing a library with two GitHub stars from an unknown developer I'd still rather have the original than the AI's un-attributed regurgitation. Of course the fewer users something has, the more scrutiny it requires, and below a certain threshold I will be sure to specify an exact version and leave a comment for the person bumping deps in the future to take care with these. > Introducing a library that was last…

> I'd still rather have the original than the AI's un-attributed regurgitation.

If what you need happens to be exactly what the library provides — nothing more, less, or different — then I see where you're coming from. The drawback is that the dependency itself remains a liability. With such an obscure library, you'll have fewer eyes watching for supply chain attacks.

The other issues are that 1) an obscure library is more likely to suddenly become unmaintained; and 2) someone on the team has to remember to include it in scope of internal code audits, since it may be receiving little or no other such attention.

> On the other hand, I would be shocked if I had ever used more than 5% of the standard library in the languages I work with regularly.

Hence "non-core". A robust stdlib or framework is in line with what I'm suggesting, not a counterexample. I'm not anti-dependency, just being practical.

My point is that AI gives developers more freedom to implement more optimal dependency management strategies, and that's a good thing.

> unlikely to be improved by that team replicating the parts of the library they need into their own codebase

At no point have I advised copying code from libraries instead of importing them.

If you can implement a UI component that does exactly what you want and looks exactly how you want it to look in 200 lines of JSX with no dependencies, and you can generate and review the code in less than five minutes, why would you prefer to install a sprawling UI framework with one component that does something kind of similar that you'll still need to heavily customize? The latter won't even save you upfront time anymore, and in exchange you're signing up for years of breaking changes and occasional regressions. That's the best case scenario; worst case scenario it's suddenly deprecated or abandoned and you're no longer getting security updates.

It seems like you're taking a very black-and-white view in favor of outsourcing to dependencies. As with everything, there are tradeoffs that should be weighed on a case-by-case basis.

Re: We should all be using dependency cooldowns

#173

Post by nrhrjrjrjtntbt »

layer8 wrote: post #20

People in this thread are worried that they are significantly vulnerable if they don't update right away. However, this is mostly not an issue in practice. A lot of software doesn't have continuous deployment, but instead has customer-side deployment of new releases, which follow a slower rhythm of several weeks or months, barring emergencies. They are fine. Most vulnerabilities that aren't supply-chain attacks are o…

I agree. Pick yout poison. my poison is waiting before upgrades, assess zero days case by case.

Re: We should all be using dependency cooldowns

#174

Post by dudeinjapan »

jerf wrote: post #79
embedding-shape wrote: post #46

Earlier quoted context omitted.

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

I fought off the local imposition of Dependabot by executive fiat about a year ago by pointing out that it maximizes vulnerabilities to supply chain attacks if blindly followed or used as a metric excessively stupidly. Maximizing vulnerabilities was not the goal, after all. You do not want to harass teams with the fact that DeeplyNestedDepen just went from 1.1.54-rc2 to 1.1.54-rc3 because the worst case is that they…

Dependabot only suggest upgrades when there are CVEs, and even then it just alerts and raises PRs, it doesn’t force it on you. Our team sees it as a convenience, not a draconian measure.

Re: We should all be using dependency cooldowns

#175

Post by ozim »

dap wrote: post #86
embedding-shape wrote: post #46

Earlier quoted context omitted.

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

Update at least quarterly so you don’t have them stale an super hard to update

Re: We should all be using dependency cooldowns

#176

Post by weinzierl »

layer8 wrote: post #20

People in this thread are worried that they are significantly vulnerable if they don't update right away. However, this is mostly not an issue in practice. A lot of software doesn't have continuous deployment, but instead has customer-side deployment of new releases, which follow a slower rhythm of several weeks or months, barring emergencies. They are fine. Most vulnerabilities that aren't supply-chain attacks are o…

"The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it."

Yes

"Only then do you need to update that specific dependency right away."

Big no. If you do that it is guaranteed one day you miss a vulnerability that hurts you.

To frame it differently: What you propose sounds good in theory but in practice the effort to evaluate vulnerabilities against your product will be higher than the effort to update plus taking appropriate measures against supply chain attacks.

Re: We should all be using dependency cooldowns

#177

Post by lijok »

cxr wrote: post #34

What everyone should all be doing is practicing the decades-old discipline of source control. Attacks of the form described in the post, where a known-good, uncompromised dependency is compromised at the "supply chain" level, can be 100% mitigated—not fractionally or probabilistically—by cutting out the vulnerable supply chain. The fact that people are still dragging their feet on this and resist basic source control…

Vendoring hasn’t been feasible since CI became free for OSS.

You cannot vendor yourself out of a nuclear waste pile that is the modern OSS ecosystem.

Re: We should all be using dependency cooldowns

#179

Post by alphazard »

nextaccountic wrote: post #167
alphazard wrote: post #160

For some reason everyone wants to talk about all the solutions to supply chain attacks except designing languages to avoid them in the first place. Austral[0] gets this right. I'm not a user, just memeing a good idea when I see it. Most languages could be changed to be similarly secure. No global mutable state, no system calls without capabilities, no manual crafting of pointers. All the capabilities come as tokens o…

How does Austral avoids supply chain attacks?

The typical attack tries to get the victim to load a module which accesses information on the filesystem or in another module's memory, then exfiltrate that information using network access. Other attacks may install backdoors used for infiltration once the service is deployed.

If the module provides some small helper function like `appendSmileEmoji(x: String) -> String` then it shouldn't be accessing the network or the filesystem, and the only memory it should have access to is the string passed into the function. The programmer already provided enough information to explain to the compiler that the function should not do these things but poor language design allows them to happen anyways.

Components which do have access to the network should be vetted thoroughly because they can facilitate infiltration and exfiltration. Most supply chain attacks aren't introduced directly in a high profile project like a web framework, they are introduced deeper in the dependency chain in the long tail of transitively imported modules.

In Austral (or any language using these good ideas) a small poorly vetted function like `appendSmileEmoji` wouldn't be called with access to the filesystem or network. Without access to any resources, the worst it can do is append a frowning face or a null character or something annoying. You can tell by its function signature above, it doesn't take a capability for the network or filesystem, just a String. So trying to ship a change that secretly accesses the filesystem would produce a "variable not found" error. To even get the new version to compile, you would have to add an argument to take a filesystem capability. `appendSmileEmoji(x: String, fs: FS) -> String`. That breaks any dependent modules because they have the wrong number of arguments, and looks very suspicious.

Re: We should all be using dependency cooldowns

#180

Post by o11c »

9dev wrote: post #161
o11c wrote: post #114

Earlier quoted context omitted.

Locally, you can do: apt-cache showpkg 'node-*' | grep ^Package: which returns 4155 results, though 727 of them are type packages. Using these in commonjs code is trivial; they are automatically found by `require`. Unfortunately, system-installed packages are yet another casualty of the ESM transition ... there are ways to make it work but it's not automatic like it used to be.

> Unfortunately, system-installed packages are yet another casualty of the ESM transition ... A small price to pay for the abundant benefits ESM brings.

Honestly, I don't see the value gain, given how many other problems the JS tooling has (even ignoring the ecosystem).

In particular, the fact that Typescript makes it very difficult to write a project that uses both browser-specific and node-specific functionality is particularly damning.

Post reply on HN