Sometimes I call the numbers on missing dog posters and just bark into the phone. I learn from the mistakes of those who take my advice.
They are pushing hard on the developer experience because greenfield projects aren’t being built using Windows centric tooling anymore. If it’s server it’s Linux, and if it’s client it’s either electron or a web app. What will kill Windows is when there is no reason to buy Windows. MS recognizes this fact and has been pivoting to service offerings for that reason. They want users to make an MS account so they can herd people into their ecosystem.
Don’t give them ideas 😂
If Canonical and RedHat weren’t backing different horses (Snap vs Flatpak), I could see the app containerization system coming under systemD as well fairly soon. The Cosmic DE project uses functionality from systemD to overlay changes onto the system that are reversible, so that alpha versions of Cosmic can be tested without permanently changing the base system. Imagine apps shipping on whatever container runtime, and dynamically overlaying system-level changes as needed for things that tap into the host system via systemd-sysext.
A lot (and I mean a lot) of criticism can be leveled at systemD. One of the upsides of it becoming popular is the standardization of much of things from the developers’ perspective. It’s easier to target multiple distros when you can rely on systemD’s single implementation of the feature. Over the next decade, I forsee systemD eating more and more of the userspace, until you are only left with managing the differences between DEs and which display server they are using. We’re already headed towards immutable base systems with apps shipping with their own dependencies, which we reduce the differences between distros even further.
“hello system” is pretty nice to look at, and has some Mac-isms I find helpful. FreeBSD has a new release recently, so maybe Nomad or GhostBSD could be worth trying. You’ll find FreeBSD is a lot more “consistent” compared to Linux, but be prepared for random hardware to not work.
Honestly it isn’t. Support for anything front-end related is way more sparse compared to Linux.
Man I wish FreeBSD hadn’t fallen to the wayside. It’s really cohesive and feels put together in a way not Linux distro ever has.
Haha Mint was my first distro! I wiped Windows 7 and installed Mint, then quickly learned that a tarball is in fact more work than an exe. Good times and a great learning experience! Back then it was the only thing not slow, ugly, or wildly unfamiliar.
I admire your gusto! I think it’s doable, and you can definitely pull it off if you want to. To replace MD5 and implement signatures you need to do the following, as a high level overview:
Extend dpkg to know what SHA2 is, and reliably detect it. (maybe measure hash length or specifying a new version using the control file?)
dpkg must also know what a signature is. More on that below.
Providing automatic/mandatory signing will require code to handle PKI as well as a place to store the signing information. I would do it by signing the two archives found within Deb packages, then placing information about the signing in the top-level of the package. Existing tools need to be able to ignore or handle whatever you implement as a rule of thumb.
Note that this is just my approach and maybe you can do better.
I also recommended looking into https://lists.debian.org/debian-dpkg/2001/03/msg00024.html. This is the thread I mentioned earlier, in which package signatures were discussed and ultimately turned down. Maybe the easiest approach is to re-implement what the contributor was trying to do back then, but with modern code and standards? If you want more resources, including my presentation on the topic to HackCFL and CitrusSec, let me know. I am here for whatever technical assistance or industry contacts I can provide. The white paper might be done in a month, minus peer review. I’m very busy and so is he. Good luck in any case!
To save you some effort, they do not consider it a priority to fix. Code was attempted to merge that would make package signatures the default, but it was removed because it “was a waste of cpu cycles” when “md5 and the https was just as good”. I’m not kidding, you can find the whole conversation in the Debian mailing archives. So instead I’m going to make it known how dumb it is, and encourage people to use something else.
In theory (whitepaper is still being written), if you MITM the connection to the APT mirror it’s using you can also carry out the attack over the network by injecting it into the package on the fly. Cert pinning might be a blocker, but local (LAN) package mirrors might still be valid attack targets. Enterprises often use MITM certs for things like DLP and packet inspection we might be able to leverage at least.
The use of MD5 becomes a bigger issue when paired with the lack of package signatures. You can inject code into a package and find a colliding digest absurdly fast. I and a friend from Threatlocker created a Metasploit module to use Deb packages for local privesc based on the concept. If it touches the filesystem outside of the APT cache it becomes a vector.
Did they ever make good on this plan?
RPM must accept SHA-1 hashes and DSA keys for Fedora 38, ideally with a deprecation warning that it will be disabled in F39.
And MD5 for package integrity checking, and not using per-package PKI signatures.
Because software monocultures are bad. The vast majority of browsers are Chromium based. Since Google de-facto decides what gets in Chromium, sooner or later the downstream forks are forced to adopt their changes. Manifest V3 is a great example of this. You can only backport for so long, especially when upstream is being adversarial to your changes. We need an unaffiliated engine that corrects the mistakes we made with KHTML/Webkit.