Programming

Yes and no. It depends on how you manage symbol visibility. There is such a thing as a "private" dependency. For example:

• libA uses a patched version of libZ, and breaks ABI compat with the upstream version
• Your program links with libA and upstream libZ dynamically

If LibA links with libZ statically, and doesn't expose any internal libZ structures through its own APIs, then there's absolutely no problem. Your code will never directly interact with the internal libZ of libA.

If LibZ is exposed by LibA, or LibA dynamically links with LibZ, then you have a problem. I'm not an expert on dynamic linkers, but they're might be some platform specific workarounds you can do.

Something else I've seen before is some libraries use preprocessor macros for their namespaces. That way, you can change the namespace (and thus symbol names) at compile time. That way, you can have multiple copies of the same library coexisting, even with type safety at compile time.

Bad form. Breaks SLSA some. Breaks some CVE tracking tools too.

If the patch introduces a vulnerabilty or breaking issue how would it be tracked?

Patching is a reasonable temporary solution while you are actively working to get the patch merged upstream. If you’re not doing that, a better solution is to fork. If you’re not doing that either, then you should be updating your resume.

This would depend on the language/ecosystem. It's worse for C and C++ than for example Rust because of packaging policies and ease of distributability.

If your patching an external library, please try to do what you can in the moment to formulate the patch in such a way that the upstream can accept it.

Patching a library is fine if you’re building a final executable — something where you know what the final dependency graph looks like ahead of time.

It’s not fine if you’re building a library. You don’t know if a consumer will also want to use an unpatched version of that library, and depending on the scenario that could result in duplicated instances (each with their own internal state), failure to build or load, or mismatches in data layout or function definitions.

I would avoid using a library like that if I could.

Of course, sometimes the person who can make that decision is the creator of npm itself, and says “No I don’t believe I will”: https://github.com/isaacs/jackspeak/issues/20

Is this for a personal project or something to be distributed?

If this is a distributed project where reproducibility is important, modifying external dependencies will quickly and greatly complicate things. I think a preferred method would be forking if not doing a pull request, assuming those dependencies are open source. This way you can independently develop on the dependency and source it separately instead of relying on patches