dependency management problems are a thing irrespective of the license of those dependencies. nobody anywhere is writing assembly code entirely on their own, even then you depend on a compiler. every software project has dependencies. it's a problem solved by version pinning. i can't believe a tech writer wrote this?

here is the article this paragraph is from

it's interesting the author decided to highlight the open source problem and not the fact that mixpanel is in the business of surveillance

that being said, that headline

*slurps your passwords*

@Gargron yeah, didn't you know that software is analogous to chemicals?

Ok didn't open source essentially won and demonstrated being the best way to develop most of the time?

@pasqui023 @Gargron Nothing in that blurb is wrong. It is, after all, why the FOSS community bothered to come up with the Semantic Versioning convention, and a whole ecosystem of tools supporting it.

I think the real issue here is that the blurb, on its own, is somewhat misleading: it implies that there's no support for remediating any incompatibilities that arise (which is, of course, simply not true).

@vertigo @gargron @pasqui023 No, the issue with the blurb is that it implies that this is a problem with free software, rather than a general problem of our systems being so complex that we cannot build them ourselves and need to rely on other people's code.

"build or buy" exists without free software, and choosing how much effort to spend on understanding "bought" (for money or not) code is always a balancing act.

@clacke @pasqui023 @Gargron The real issue with that blurb is that it's too small to get any real context. Clearly, we interpreted it different ways. That's a problem.

@vertigo @gargron @pasqui023 Perhaps. But can we agree that you can strike every "open source" from the blurb and it will remain just as true? That means that phrase is unnecessary and points fingers in the wrong direction.

@clacke @pasqui023 @Gargron Sure, I agree with that.

I guess the reason I didn't take offense to what they wrote is because it's Tech Crunch. They're widely known for horrifically inaccurate and smarmy reporting.

@somarasu @Gargron counterpoint: a text file reading "bug fixes" aren't release patch notes anyway ;p

@somarasu @Gargron all of my pull requests have been totally ignored

@Gargron that's one of the companies that make the Internet a worse place and one the reasons why you need an adblocker these days, and the only thing they talk about is that their product also is buggy? That's like "big problem: the toilets on the death star are not barrier free for people in wheelchairs."

As a popular tech product creator, you surely noticed a wide range of knowledge and opinions among "tech writers", right?
@Gargron version pinning means you are potentially missing important bug fixes during codebase refactoring which were actually vulnerability fixes that didn’t get CVEs assigned

@feld no. you gotta be paying attention to new releases of your dependencies (there are tools for this), but version pinning means you don't get unexpected breaking changes from someone else's code.

I second that, you can't just trust an automatic dependency updater to keep your own software running. A dependency isn't entirely free work you're using from someone else; whatever the license, you have to spend at least some time managing them.
@Gargron I’ve only witnessed it used to freeze that code for eternity because keeping your codebase compatible with the latest releases of your dependencies is “too much work”
@feld @gargron So, you have the choice of auto-updating and violently breaking your thing even when there's no problem, or pinning and silently staying broken when there's a security update. :-)

@clacke @feld @Gargron Exactly. What we need, and really don't quite have yet (in general) is a way for a person or organization to subscribe to the changelogs of the dependency-tree-assuming-you-were-to-update.

I keep thinking about building this, and what it would require. And first, uh... it would require people to keep changelogs. 😭

@clacke @feld @Gargron ok first of all because I am a jerk, #semver

second of all is that really worse than *not* using open source? I mean, if you're not tracking security holes that other people find, I can't imagine you're actively looking for security holes in code only you can see

@ajordan @gargron @feld Yeah, semver intends to tell you what contracts you have with your dependencies.

But even elm, which enforces that API signatures don't change without bumping versions, cannot enforce that semantics don't change underneath the API signatures.

Short of perfect formal verification, there is no technological solution, because this is a human problem.

@clacke @feld @ajordan @Gargron Pesky, pesky humans. They always get in the way of glorious progress! 😁 In a less sarcastic vein, I have been questioning the resilience of these sprawling dependency chains after that leftpad accident with npm.

@skellat @clacke @feld @Gargron meh. Point taken, but you're going to have that problem no matter what, and there are relatively simple solutions to it. Mirroring the parts of the npm registry you depend on, for example.

npm also changed its policies after that so an incident like that can't happen in the future.

@clacke @feld @Gargron oh absolutely, semver is not without its flaws. IMO it's better than anything before it but it doesn't replace e.g. testing. This is why lockfiles exist.

@ajordan @gargron @feld Thank you, and I agree.

I think semver is a good idea and I like it. But even with semver we need lockfiles. But then with lockfiles we need to not fire-and-forget but keep up to date on things.

Belts and braces, people. Goes along with the gum and paper clips we built this stuff on.
@ajordan @feld @gargron

One thing that I want to see more of in the future is what e.g. #rust is doing:

Find the things that depend on your thing -- in their case every single crate published -- and treat them all as integration tests for your API.

#nix and #guix make this easier. I just discovered the brilliant #nox tool, where you can do `nox-review wip` on e.g. a bumped dependency and build and test every dependee.

Imagine if every project did this before releasing their point release! (and at the same time imagine that the dependees have decent tests, of course, otherwise you're just detecting whether you broke API signatures, and that's trivial to do without looking at any code except your own)

@clacke @feld @Gargron fun fact, Node.js actually has some tooling to do this! Though from your description it sounds like it's nowhere near as comprehensive as Rust's.

@clacke lmaoooo I have no idea

Maybe a semver-major change landed in git master and it's expected...? Dunno ¯\_(ツ)_/¯

@Gargron Maybe it makes more sense from a business perspective? If you purchase your dependencies, you can hold those companies liable. If it's open source, you don't even know who to sue.

@Gargron that is the most ridiculous thing I've read in a while. As you point out, nobody writes software from first principles nowadays.

Also, just from a purely practical perspective, a library that's used by millions of people every day is a lot less likely to have security problems than the one your inhouse dev team will be rolling while in a crunch to meet a deadline.

@yogthos @Gargron That's insane, but I think it's possibly a misunderstanding of the kind of problem that's been seen with node/npm, where there are too many casually maintained mini-projects used as dependencies for really important things.

There's a huge difference between say using a well-established language like Python, or a framework like Rails, where you know they'll work hard not to break things; and relying on some string filter written by a 15 yo kid who changes the API at random.

> Increasing reliance on open-source frameworks like React means engineering and security teams can’t just worry about their company’s own code. It has to mingle with changes to open-source projects that can cause unforeseen trouble. It’s like if the ingredients in one of your prescription drugs subtly changed, so your preferred over-the-counter pills suddenly caused a dangerous interaction.

Ugh. Is this writer aware that you can rely on Other People's Code without even having the freedom to view and change the source code? How is that better? Then you probably won't even discover an issue like this.

@clacke @Gargron This argument sounds totally dumb when applied to the entirety of Open Source. This kind of thing really only happens when you have a widely-used project with maybe 3 contributors who all hold domain-specific knowledge.

Or you're doing dumb shit in the NPM ecosystem.

@Gargron it's a bit clumsy but in a way it's right. However the real problem is software is big.

React may get security bug yes. But so could a home grown bit of code that carries out the same function.

Also you want to, if possible, have a single version of dependencies across your fleet. Who wants to solve the same problem multiple times or find out you had embedded dependencies and that bug you have patched isn't because someone embedded an ancient version of it in their own stuff

@Gargron Obviously free security flaws are more dangerous then flaws companies paid for.
Didn' you know that?

@Gargron Now that even Microsoft has embraced open source, the fearmongers who couldn't be retrained had to be employed somewhere.

@Gargron dark analogy... i'd love to hear what's wrong with it (disclosure: i'm a journalist for consumer reports exploring decentralized networks)

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!