I don't get why we're having a "real name" discourse over the xz-utils backdoor... the person who took over used a real-looking name!

Maybe we should worry about how this person had very little online footprint when they took over the project, not what name they used... ^^;;

@lina these people will point in every direction other than themselves for why a backdoored update got ingested. at the end of the day, it is on the distro maintainer to be checking what is in the updates. sadly, this is not realistic.

i think arch linux's work on reproducible source tarballs is an interesting step forward though.

@lina and the other people who hounded and harassed the other maintainer into giving that entity co-maintainership

@kevin There's a theory that those were sock puppets...

@lina @kevin if you're a state actor or similar, i am sure paying a few people on fiverr to spin up some sockpuppets for you wouldn't be out of the budget

@lina yeah, I was gonna use the word "entities" there too but it would be too confusing 😅

@ariadne @lina
I don't know what exactly Arch does about reproducible source tarballs (quick googling didn't turn up anything interesting), but fun related story:
Apparently OpenBSD ports also wants reproducible builds, and as part of that source tarballs that always have the same checksum (for the same version). At first this sounds trivial, but it turns out that the source .tar.gz that you can download at Github can change over time, as it apparently is generated on the fly

@ariadne @lina
.. so if for example Github update gzip or zlib on their servers, the source .tar.gz you can download will (or at least might) have a different sha256sum than it had a week before.
Because of this I was asked to manually upload source tarballs for dhewm3 releases, because those won't change over time (just like binary packages I upload with releases).

I did (still do) this because it sounded like a reasonable thing to do, but of course xz showed that this also has risks..

@Doomed_Daniel @ariadne GitHub's archive format change a while back caused issues for build systems because of hash mismatches, this is why the content hash is a solution.

But anyway the backdoor could also have been committed to the repo and if it was obfuscated enough could have slipped through (and parts of it were in git).

@slyecho @Doomed_Daniel that, and also reproducible source tarballs are only one defense of several you would really need to find everything all the time

@ariadne @lina

the other bit about this is... I kinda don't like the idea of denying a pull request or contribution just because someone's not got a facebook or a linkedin profile

now.... to become a distro maintainer... maybe it's better if they have their own blog or you've seen them in IRC logs or video calls...

but individual contributors prior to becoming a library maintainer... that seems invasive / exclusionary to deny contributions from relatively shy folk.

especially considering how fedi freaks out at some developers, or that swatting exists.

@risottobias @ariadne It's fine for individual contributors! But you'd also review their contributions a bit more closely. The issue is someone rising to a position of trust (maintainer, signing tarballs, all that) without almost any presence other than their work on that project...

It's not just trust too, it's also contingency! Sometimes you have to contact a maintainer in an emergency, they may be offline... it helps if someone knows their phone number, stuff like that. It doesn't have to be public, just having a private trust network and people who can vouch for you is enough.

@lina I see a lot of blame, user verification, systemd link in too many libraries, upstream maintainers are overworked, underpaid, not paid at all, etc. (I certainly agree with this one) open source is too open etc. I see this as a WIN for open source. xz 5.6 was released ~a month ago, this was detected days after downstream repos started inheriting these new upstream releases. It didn't hit Debian stable, it didn't even hit a Fedora release which is impressive as Fedora is a bleeding edge distribution (40 beta, rawhide, etc. don't count they are pre-release versions).

And yes this is down to one engineer who discovered it. Major kudos @AndresFreundTec And this is what open-source is all about, the combined engineering efforts from all sorts of different people and companies helping each other out for the greater good.

There is room for improvement, and it's important to reflect and improve. But lets not get too carried away, IMO, open source won against this bad actor/backdoor for the most part.

This exploit had a lot of hurdles to cross before it hit distributions like RHEL, etc.

@ecurtin @AndresFreundTec It was only caught due to a performance issue though, not because people were auditing the code... it's scary that it was so close to actually sneaking into stable distros over time.

@risottobias @lina i’ve never denied a contribution based on that, nor do i have any plans to.

@lina
Does everyone that contributes need to have online footprint?

@lewiscowles1986 No, but this wasn't a contributor, it was a maintainer... what I'm saying is that maintainers in a position of trust should have a trust network to back them up!

It doesn't have to be a large public presence, but they should have links to the community (other friends in similar trust positions, people who know them personally and have their contact info, and things like that). It's really weird when someone rises to a position of trust but somehow nobody really knows who they are, not even privately (and I don't mean their legal identity, just as a person)...

@lina @niconiconi or the fact that the maintainer of a lynch-pin OSS library was so overworked and undersupported that they were just overjoyed to pass some work off to anyone that would take it

@neatchee @niconiconi Yeah ...

@brothercheng Yeah, pretty much! I also met the DRM maintainers and a bunch of other people IRL at XDC ^^