This article was never meant as a comparison between existing federated and decentralized protocols. But we do take up the challenge for the next, good idea!
thanks for your review! tho you are referring to the tomb-portable unfinished experiment which is about to be dismissed since cross-platform experiments with veracrypt show very bad performance.
you are welcome to share a review of the tomb script, but be warned in that we use a lot of zsh specific features. It is a script that works since 15+ years so it has a discrete amount of patchwork to avoid regressions.
I really appreciate your tone and dialectic reasoning, thanks for your reply. And yes, as simple as it sounds, I believe that shell scripts help a lot to maintain mission critical tools. One hands-on example is https://dyne.org/software/tomb where I took this approach to replace whole disk encryption which is nowadays also dependent on systemd-cryptsetup.
It is 10 and more years that I experience such ad-hominem attacks.
You are so quickly labeling an identifiable professional as troll, while hiding behind your throwaway identity, that I am confident readers will be able to discern.
Our community is swamped by people like you, so I will refrain from answering further provocations, believing I have provided enough details to back my assertion.
You are distracting from facts with speculations and trolling FUD. I refer to what is known and has happened, you are speculating on what is not known.
This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that.
A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and due to systemd's call to dlopen() liblzma library (CVE-2024-3094). The resulting build interferes with authentication in sshd via systemd.