pretty interesting that github has only one hammer to respond to incidents like this and it's "block access to the repository so that nobody can see the source code history" apparently
(if i'm being generous, this might be to prevent dogpiling. but it sure does make all the commit references in the oss-security email this morning useless)
After seeing how the XZ maintainer's burnout and mental health decline was exploited to the potential detriment of the whole world, we're totally going to be supporting our developers more, right guys? We're totally going to fund critical OSS and pay maintainers enough to hire on other maintainers to take the burden off of them and reduce burnout, right? Right?
Inevitably, a vuln caused by maintainer burnout and underresourcing is going to spark more arguments about how to pay maintainers (hopefully sustainably).
As a former maintainer, things I would have liked to consider working on projects full-time include:
- a steady paycheque in line with industry salaries
- guaranteed for at least 2 years of employment
- with healthcare & other benefits
- and I can't be the only maintainer.
One thing that the xz compromise also shows; simply having more eyes on something doesn’t make things inherently more secure.
Multiple distributions pulled the vulnerable xz updates. I doubt anyone really vetted the changes. I don’t blame distribution maintainers for that, they do a lot of work typically for free. But a lot of people have bought into the idea that getting your packages through a distro’s official channels somehow makes you safer. It probably helps with unexpected issues due to misaligned dependencies, but it does little for attacks like these.
In truth we got lucky that one person noticed some odd behaviour and decided to investigate.
@tomasekeli The toot is deliberately simplified; the unstated context is "... within the trust model that corporations typically operate in" (which is based on reputation and popularity, and that is where 'insufficiently supported maintainers' are the #1 risk factor).
There are other types of supply chain compromises, but they are often effectively prevented by existing mechanisms already; it's specifically this one that is near-completely immune to those mechanisms.
To expand on this: you don't need to manage them. You don't need to track their progress. You don't need a special team for them, or a 'head of open-source'.
You pay them a salary in the same way that you would pay a salary to eg. someone who you don't really have any work for, but don't want to see leaving for a competitor either: you add them to payroll and just let them do their thing.
They're already a maintainer so they know how to manage the project. There are no further expenses or organizational overhead for you.
Do you want to stop "supply chain compromises" as a company? Here's a very simple way to do so: pay a stipend to a maintainer of something you depend on.
You don't really need dependency tracking tools. You don't need to exactly parcel out the 'right' proportionate amount of money to every maintainer. All of that operational complexity is unnecessary.
It doesn't even matter *which* maintainer you pick, as long as it's one who isn't receiving a stipend yet, and you pay them enough to constitute a salary.
It will cost you exactly one developer salary. If every able company does this, the problem of supply chain compromises is solved tomorrow.
All you need to do is simply *do it*, and talk about it so that other companies will too.
synadm maintainers:
JOJ0 (repo owner)
Ascurius
JacksonChen666 (me)
now the more interesting part is availability in maintaining the project:
JOJ0: pretty busy IRL
Ascurius: no idea what happened to them. their matrix homeserver seems broken and they have done nothing on the synadm repo for maybe about a year.
JacksonChen666: I have been temporarily given the lead for synadm by JOJ0, and did a couple of things recently. so I'm active.
so synadm currently only has 1 active maintainer. the other 2 aren't really available.
xz
@eater (This is basically a 'trusting trust' type of situation, except one we have plausible evidence for)
xz
@eater xz is a part of *the build process itself* in many cases - extracting source archives, that sort of thing. So it could have affected the source of other applications at any point in that process, in a way that's impossible to trace back.
So anything that has come into contact with xz at any point in its build or distribution process, while this new maintainer was involved, is now suspect. That's... a double-digit percentage of packages on a typical system, I suspect.
xz, gloating
@syn Yes, but not for the specific purpose of knowing what packages to rebuild if a backdoor were ever discovered
politiek
@WH Tja. Zo iemand hadden we dus min of meer, in Sylvana Simons, maar dat is geen witte vrouw die voor gevestigde belangen opkomt, en dus werd die in de media en publieke opinie geheel kapot gemaakt.
Deze tactiek werkt alleen maar op deze schaal als je je privileges al mee hebt en niet te ver van de gevestigde orde afligt. Wel radicaal klinken maar vooral niet radicaal zijn, zeg maar.
xz, gloating
@syn (It's kind of hard to classify these things because Nix is in a category of software where "benefits we didn't anticipate" are expected as a category, it's just not known which benefits they will be)
xz, gloating
@syn Yes, though arguably an accidental one, sort of - it's not really what the dependency system was *designed* for afaik, just a consequence of the design choices
Technical debt collector and general hype-hater. Early 30s, non-binary, ND, poly, relationship anarchist, generally queer.
- No alt text (request) = no boost.
- Boosts OK for all boostable posts.
- DMs are open.
- Flirting welcome, but be explicit if you want something out of it!
- The devil doesn't need an advocate; no combative arguing in my mentions.
Sometimes horny on main (behind CW), very much into kink (bondage, freeuse, CNC, and other stuff), and believe it or not, very much a submissive bottom :p
My spoons are limited, so I may not always have the energy to respond to messages.
Strong views about abolishing oppression, hierarchy, agency, and self-governance - but I also trust people by default and give them room to grow, unless they give me reason not to. That all also applies to technology and how it's built.