Hacker News Reader

Comment by xeromal | Hacker News Reader

Sometimes you just say fuck it.

This is exactly what we all do every time we

  cargo update

without reviewing the code changes in each dep (and their deps) wrt how they impact our compiled artifact. Ultimately we're each individually responsible for what we ship, and there's no amount of bureaucracy that will absolve us of the responsibility.

I think it is possible to build infrastructure that will allow entities to spread responsibility. They do it in other fields I think?

For example I can’t imagine Ford checks literally every single individual component that gets put in their cars, right? I assume they have contracts and standards with manufacturers that make the parts, probably including random spot checks, but at some point to handle complexity it is necessary to trust/offload responsibility on some suppliers.

I bet you could get those sort of guarantees from, like, Intel or IBM if people generally were willing to pay them enough (can you now? Not sure, probably depends on the specific package). But nobody would make that sort of promise for free. The transparency of the open source ecosystem is an alternative to that sort of thing, no promises but you can check everything.

Just to be explicit (since I’m sure this looks like needless pedantry), I think it is important to remember that the open source and free software ecosystems are an active rejection of that sort of liability management framework, because that’s the only way to get contributions from a community of volunteers.

There's something very different with software I think. For example, if a mechanism calls for a class 10.9 bolt with a certain diameter and thread pitch (let's say M6x1 for the sake of argument) then there are many different manufacturers who can supply equally suitable parts. They may each be dimensionally different, have different yield strengths, but they're all conforming to class 10.9 and dimensionally within tolerance. As the designer of the mechanical assembly I can trust the manufacturer of the bolts has a quality control procedure that'll make sure their bolts are good.

As a software assembly designer, I don't really have any way to say "this subcomponent remains intact" when I integrate it into my system. The compiler will chew things up and rearrange them at link time. This is a good thing! It makes the resulting binary go brr real good. But it's ultimately my responsibility to make sure the thing I ship--the compiled artifact--is correct. It's not really a valid move to blame one of my dependencies. I was supposed to review those dependencies and make sure they work in the context of the thing I shipped. Wouldn't it be a bit like the mechanical assembly designer blaming the bolt manufacturer for a failure of a bolt they modified while building the assembly (EDIT: or blaming the supplier when the assembler used the bolt in a way it wasn't designed for)? What guarantees can the bolt manufacturer reasonably give in that case?

EDIT: another thing is that source code isn't really analogous to a mechanical component. It's more like the design specification or blueprint for... something that converts electrical potential into heat and also does other stuff.

Technical standards, classes, testing procedures did not always exist for bolts either. For some classes of software I think one could create equivalent levels of standardization, if anyone would care enough. Having a standardized test suite would be a key component of that. I think that a YAML parsing library would be among the better candidates for this.

The chances of cargo update pulling in some updated dependency which is now compromised with malware is low. The chances of a compromised dependency getting past `cargo-audit` are low. The chances of compromised code causing measurable harm are low. The repercussions for me publishing compromised code are low. The effort I would have to expend to manually check the code is high.

So yes, I `cargo update`.

I do too, but I wonder if there's a way we can make it tractable to shoulder the responsibility of maintaining our dependency graphs? More: [1].

[1] https://news.ycombinator.com/item?id=39832559

> Sometimes you just say fork it.

FTFY. And vendoring a dependency is really just a hidden fork.

> FTFY. And vendoring a dependency is really just a hidden fork.

It's not a fork until you start diverging from upstream with local modifications.

That raises the question: what is the current etiquette around deciding whether to pester a dependency's author to include your fixes or just fork it, especially if it looks like you will be the biggest user of that dependency? I'm dealing with that question for a dependency that I want to introduce in one of my crates, but ideally not until at least one of my own fixes is merged.

Obviously fork it, implement your feature, battle-test it, fix and make it more generic, battle-test it again, then ask the maintainer if they would be interested in a pull request.

I mean, implementing your fixes in the first place means you are already inherently forking it.

My thought process is:

1. You find a bug, open an issue. 2. If bug is a minor issue, wait. If I want a fix really bad, offer to fix it. 3. If I still want a fix really bad and author did not respond, or does not want a fix, then fork the project for my own consumption. Using alternative dependencies are also an option.

Yup, and forks don't have to be permanent.

Imo be ready to fork all the things if need be. Get comfortable with it before you're forced to.

In my opinion, you should always ask the author first. Having your changes accessible from the primary repository is much easier and better for everyone, and there is a good chance the author is happy to accept your PRs. On the other hand, they might not agree with your proposal or might want to make significant changes to the design, at which point it becomes a personal tradeoff for you.

Reply on news.ycombinator.com