The only thing I can really do is try to open eyes
...
saying all this here probably won't change much. Its futility unless enough people wake up though in general.

AKA, lots of preaching with very little doing.

In many cases these frameworks are already optional, via compile-time flags... Something which, for reasons that apparently escape me, you seem completely unwilling to consider.
Where they are not optional at compile-time, patches to upstream code would be required.

There is no standard facilty for making dynamic-linked library dependencies optional at runtime, because that's not how any of this works. The thing that is becoming most tedious of all is your insistence that there shouid be such a feature, and somebody other than you should see to it.

If you want everything built for you and served up in convenient packages, you get whatever the packagers decided on when they built them (or engage in constructive discussion where you disagree).
If you want control over compile-time options and patches, you run Gentoo or some other source-based distro.

Anything else is just blowing smoke. The tools to build a system the way you want already exist, if you're willing to put in the effort to use them.
Have you actually built and used a system without dbus and policykit, or is this all just idological bikeshedding?

All that said, if you want to be taken even remotely seriously on the idea of making such dependencies optional at the package management level (which would entail binary distros maintaining multiple variants of each affected package):
* What is your convincing technical argument for such a change?
* What do you propose replacing the projects on your "evil" list with? You want to drop dbus for example, so how should we do IPC?
* And, how is your proposed replacement (functionally) superior?
* How do you propose convincing 1000 upstream projects to drop features dependent on $evil_library or switch to your replacement?
* Who is going to do all this work, and does the benefit justify it? If upstreams aren't on board, who is going to write and test patches?

Also, my voice alone would not accomplish anything, for government change or corporate change.

The only thing I can really do is try to open eyes or resist that which is ugly and unneeded.

I am not against having more packages, I am merely against automatically assuming everyone should have to have dependencies that aren't necessary,

Ie, required dependencies should only be for packages that actually need them, not packages that optionally use them or need them.

But yeah, saying all this here probably won't change much. Its futility unless enough people wake up though in general.

But I do agree, partially with you. It would be too much work for devuan developers to fix these problems in devuan... well at least without becoming an independent distro anyhow but I don't expect that until all other options become invalid/unworkable.

The bare minimum line should be making all libraries optional for those dependencies I mentioed, the linux frameworks or at least have an option to make them optional.

But this has gotten tedious this comment thread.

how does Devuan avert attack surface expansion while the upstream becomes more dependency permissive to accommodate systemd?  Could it even be done without forking packages expressly for that purpose?

IMO (at least as a general problem), it doesn't and it can't. Most dependencies are decided on at compile-time, and changing them means forking (or at least rebuilding) packages.
Frankly I don't see where Devuan is going to get the manpower for that. It might be feasible to fork some particularly important packages where all that is required is a simple configure flag change or dropping a patch, but deciding where to draw the line is well beyond my pay grade.

IMO the better approach is probably working on projects like elogind, i.e. forking parts of systemd itself, keeping the good bits and replacing all the crap we don't want with ABI-compatible stub functions.
That's something that is and can continue to be a common effort between distros, and so long as it keeps up with systemd changes it should allow most packages from e.g. upstream Debian to be used as-is in Devuan.

The downside of course is that we'll have to keep fending off nutters grinding the "Why does Devuan have libsystemd0" axe without bothering to check where that lib actually comes from or what it does.

You won't get both minimal dependencies and "correct" functionality with any binary distribution that in any way targets mainstream desktop use cases.

Desktop users want, at least for the most part, low-effort GUI support for things like wireless hotspots, VPNs, bluetooth / hotplug audio devices, network discovery, and prompt-free permission elevation for common tasks. In the current ecosystem that means using some or all of the "evil" frameworks you list.
This has nothing to do with "corporate influencers", it's simply the result of trying to cater to end-user expectations without massive code duplication or packaging workload.

That leaves either distributions that cater to minimalism specifically (which discounts most Debian derivatives and general-purpose distros right away) or building from source (i.e. Gentoo and derivatives).

Bitching about "bs corporate" whatever at every opportunity achieves exactly nothing. The only realistic way to have your cake and eat it (aka have only the features and dependencies you want) is to either rebuild all the affected packages yourself or switch to a source-based meta-distro.

So why don't you go do that then. Ranting here is utterly futile, and serves only to bloat the thread with unproductive noise.
If you must vent your non-specific anti-corporate rage, I suggest you write your $government_representative.

This is why devuan cannot be used minimally and still have what i consider to be the correct functionality.

Too many debian inherited crapstorms.  Its not devuan's fault, its debian's and all the other egregious devs who are like, "don't rock the boat" towards these bs corporate influencers. Redhat is a perfect example of why YOU NEED to ROCK THE BOAT! Same with Microsoft and Google and Apple.

They need to be told to suck it and force them to gag on it.

steve_v wrote:

The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Knowing that is to be expected, and thinking out loud, how does Devuan avert attack surface expansion while the upstream becomes more dependency permissive to accommodate systemd?  Could it even be done without forking packages expressly for that purpose?

Devuan packaging may gain a tertiary goal beyond pruning systemd and maintaining user choice ... eliminating permissive bloat.  I understand this is no small task and I imagine there are not yet enough packaging hands to accomplish this.  Still, it feels that is the path Devuan will be given no choice but to follow.

Another caveat under the "Packaging Guide for Devuan" may be necessary under the section "Package Forking Policy" to welcome forks to eliminate permissive bloat as the manpower is found to do so.  https://git.devuan.org/devuan/documenta … ngGuide.md

As a RedHat transplant, I'm not competent yet to provide another set of hands in that arena here.  But I take this adventure with openssh as encouragement to plan ahead, learn more, and reach that level.

--K

Quite so.

Best,

A.

But that's not what this is. Supporting sd_notify is little more than sending a simple datagram to a unix socket, and pulling in libsystemd0 for that one function is just about the definition of gratuitous attack surface.
But hey, why not double down, ignore the fact upstream has already said no because they don't want the dependency bloat, and go and patch it in regardless. The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Then there's that other obvious elephant of course: why does init need an LZMA (de)compressor anyway? Init's job is managing daemons, nothing more... Right?

IMO far too many projects pull in dependencies because it's the easy way to implement a feature, with precious little regard for whether it's a good way... or whether that feature is even worth having to begin with.
That includes distro packagers turning on every optional build-time dependency flag they can find, which is a long-time gripe of mine WRT Debian. Patching upstream sources for even more dependencies is just taking this trend to its (il)logical conclusion.

In my own code projects, I prefer having no dependencies at all.  Of course, this isn't always possible; so the next best thing is shallow dependencies: those that only require 1 level of dependencies. Actually, before I even get to dependencies, my preference is single-file modules that I can just copy into my source directory and use as-is, without declaring any dependencies.  Not many things can be used this way, but when such exist, I prefer it.  Only if I have no choice, I'll go with a shallow dependency.  And of course, the fewer dependencies the better.  Recursive dependencies I try to avoid like the plague unless there's absolutely no way around it.  And I absolutely would not touch an automatic dependency system that will automatically download 500 packages in response to a single dependency on some package that's promiscuous in its recursive dependencies.  Those things are pure evil.

See also this link that describes a lot of the issues that come with dependencies, that people have been ignoring for far too long: https://research.swtch.com/deps

That being said, as I read through the Openwall thread, I have the sense that the author of the backdoor specifically targeted dependency bloat accommodation as the vector for attack.  As "do one thing, well" was set aside for systemd, increased dependencies are not only expected but required, and being non-paranoid about them widens the attack angle, nearly allowing a tangential xz/liblzma to be used as a tool to compromise openssh.  Wow.

If xz/liblzma can be so used, what other dependencies have been introduced that are also tangential, but because they are not systemd specific their inclusion is not pruned out of Devuan?  As Devuan evolves I fear it must not only guard against systemd in the upstream specifically, but also the dependency bloat the upstream has permitted in order to accommodate systemd.

Dependencies of dependencies ... it's a new kind of "dependency hell" :-)

--K

After this fiasco I'm almost ready to switch to a source-only distro, which I'd configure by hand to contain the absolute minimum options I need to do what I need to do, and nothing else.  Even after getting rid of systemd too many Debian packages still come with too many things enabled by default. Mostly useless things that I never actually use.

https://www.redhat.com/en/blog/urgent-s … hide-users
https://gist.github.com/thesamesam/2239 … 78baad9e27