libspf2 has had at least one 9.8 CVE advisory.
Upstream is pretty unresponsive, and while it has been announced that the advisory is fixed in the following version, no version was ever released.
This prompted me and @ajs124 to fork the library, release a new version, and add some more patches from the PR tracker that were laying around for months or years (stuff like use-after-free fixes).
This was almost one month ago and upstream has still not added any commits to master, added any git tags, or released any new version on their website.
So since our fork has fixed at least one CVE and probably more bugs with the PRs we also pulled in, @ckauhaus asked in the relevant GitHub issue whether we should get our forked version into nixpkgs. In my opinion, this should replace the current libspf2 since security fixes shouldn’t be opt-in and should not require building downstream packages yourself. The reason I opened this thread is a that I’m not sure if it is seen as good style to replace upstream packages by forks created by oneself. We could also pack in the relevant patches with fetchpatch but we’d probably just end up with the exact same code that is already in the fork and that can just be fetchFromGitHub’ed.
So what’s the general view on this kind of behaviour? Can I just replace the entire library or should something different be done?
For libappindicator, we follow the ubuntu maintained one as it has many compatibility patches applied to it. I don’t think anyone would object when following a fork is strictly better.
It would be nice to see the project have somewhat of a community around the fork, as divergent efforts cause duplication of effort and bugs.
I think switching to a custom fork is great option for abandoned repositories but it should only be used as a last resort, and special care should be taken to prevent the issues Jon mentions.
As for libspf2, sure, not many PRs seem to have been merged, or even reviewed, but the upstream does not look completely dead (last update in June) – did you try contacting the maintainer by other means (e-mail) and perhaps asking for co-maintainership?
When that fails, switching the package to a hard fork might be in order. Do not forget to decide and declare what the maintenance status of your fork is – will you continue with the development? Just actively fix CVEs? Only merge patches from others? Would you suggest other distros to switch? And if your versions diverge, what will happen when the original upstream is revived and tries to use the same version string?
Coordination with other distros is especially useful to avoid polluting Repology with invalid versions.
Switching packages to a custom fork might also be useful for projects that require heavy patching. But that repo would closely follow upstream so it avoids many pitfalls of the above situation. We did that for systemd for a while but eventually decided against it since people would not be able to work on systemd without access to the repo.
The repository of the original project features new commits made last June.
The version number has even been bumped in configure.ac, but no new official
release has been added to the project’s website at: https://www.libspf2.org/download.html
did you try contacting the maintainer by other means (e-mail) […]?
I sent an email to the owner of the original project (@shevek on GitHub) on
2021-12-04 about the state of the project and the missing release. I did not
receive any reply so far.