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?
this post was submitted on 01 Apr 2026
10 points (100.0% liked)
Programming
26316 readers
1089 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
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.
then you should be updating your resume
through patching?
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.
Not sure how are you and @kibiz0r@midwest.social coming up with these concerns.
The only correct way to package such software is to vendor dependencies (packaged together or separately). And you can trivially change the sonames of vendored deps in your build scripts so that there are no conflicts whatsoever (I dual-package some stuff against an upstream and a fork and do just that). So dynamic vs. static is not the crux of the issue. The primary concerns are that distributors hate vendoring, irrespective of whether the vendored libs are linked in statically or dynamically. Distributors also hate potentially diverging forks maintained by random downstreams, which is what "patched dependencies" effectively are.
There is always room for some leeway of course, but that would depend on how relevant your software is, and/or whether a maintainer would want to take that burden on.
And finally, sometimes, such dependencies may provide added value that trumps all these concerns. So judging these things is always situational.
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
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.
Hmmm, it's C++
If the dependency static links the library and doesn't use structs or classes defined in it for its interface then it is fine. If either of those are not true it is asking for trouble
Then you could be forced to vendor everything. And if it's open-source and relevant for distros to pickup, then you will need to find out if distros would be willing to take your library with its vendored libs (or package them separately just for your library)...etc.
And you may need to figure out if there are bus factor concerns with your direct dependency, since such libraries are not necessarily maintenance free, even from a mere compiling/building stand point (what if a patched indirect dependency no longer builds with new compilers...etc).
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.
Not sure if it's clear, but I'm not doing the patching - my dependency is.
Updated post to make it clearer.
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
I'm writing a library, to be distributed, and the library I'm depending on - that patches - is also intended to be distributed.