This one came real close to affecting me. I run arch and had the affected xz package for a little while. Thankfully for me, so far it looks like this was going after deb and rpm package managers exclusively. Obscurity has some practical security advantages. Hopefully it stays that way with more scrutiny.
A lot of ink has been spilled on this topic, but I’ll give my thoughts here. Maybe this can be an open journal for me to think through my choice for rolling release. It’s been on my mind the last 24 hours.
I like rolling releases for a number of good reasons, but there are two big concerns. The potential for more bugs and supply chain attacks. The bugs thing hasn’t been an issue for me given my setup. I snapshot, run minimal mainline software, and update once a month - so not even as frequently as some point release setups, or auto update setups. Bugs just aren’t an issue for me.
My concern is much more about supply chain attacks like this one. We all are at risk of supply chain attacks but a rolling release will typically get them first, assuming it is upstream supply chain attack. I don’t know how to dodge this with my current setup beside run as little software on my host OS as possible and containerize like crazy. I only have 220 packages on my host server OS, but still got caught with this one. I can reduce my attack surface only so much, xz is just too foundational.
So I am mulling over my choice for using a rolling release for my host OS. In containerized or vm environments where snapshots are available, I think a rolling release is a solid choice. But for the host OS, I wonder if debian stable is a better choice just for this one relatively small risk exposure. I don’t like the idea of doing big upgrades every two years and to a lessor extend always being behind on features. Plus, I like arch’s assume nothing policy on everything, but that is small potatoes. … At this point I think doing nothing is the best course of action, but if this sort of thing happens more frequently to the 220 packages I completely rely on I may have to strongly reconsider my host OS. Changing out my desktop OS would be harder, but I think fedora would be my likely new home. Which would also potentially suffer from the leading edge problem here. I don’t know if I could do debian stable for my workstation. Anyway, that is something I’ll push off until or if this upstream threat model becomes more common.
I think that helped me think this through. Feel free to tell me where my thinking is wrong.
Even that a server reports xz version 5.2.2 let’s say, the new pulled Docker images used for developing purposes, use system wide xz libs or use the latest version?
https://twitter.com/TomLawrenceTech
Lawrence Systems's Amazon Page
lawrencesystems | creating Tech Tutorials & Reviews | Patreon