Why is that accepted? Serious question

Presumably because they're one of the two maintainers: https://web.archive.org/web/20240329182607/https://xz.tukaan...

He had unfettered access to xz’s git?

Isn’t it a bit ironic with how much code everyone depends on that can freely be altered by some unknown party, while so much time goes into code reviews to verify internal changes at most companies.

you can have ten comments about the name of a variable, but no one bats an eye at a new npm package introduced. Also, devs that wrote code that Google depends on can't pass the leetcode gate check to get a job there.

Our industry is a laughingstock.

The last sentence is an overreach to me, but I have experienced much of the same bike-shedding during code reviews. 95% of them are useless. Read that twice; I am not joking, sadly. I am not against code reviews, but in my experience(!), the reviewers are not incentivized to do a thorough job. Seriously, if you deliver a new feature vs do a deep, difficult code reviews, which one benefits you more? To repeat: I don't like it; I am only pointing out the perverse incentives to rush during code reviews.

One more thing that I don't see enough people talking about here: Writing good software is as much about human relationships (trust!) as it is about the computer code itself. When you have a deeply trusted, highly competent teammate, it is normal to put less effort into the review. And to be clear, I am talking about the 99% scenarios of writing the same old CRUD corporate code that no one gets excited about here. Please don't reply to this post with something like, "Well, I work on Dragon at SpaceX and all branches have 2x code coverage and the QA team has 600 years of combined experience... Yada..."

That heavily depends on the individual developer and the organization in question.

In general, the most highly skilled developers who are most capable of doing a thorough code review are also the ones who are most likely to be genuinely over capacity as is.

That is very subjective, and far from what I’ve seen.

I'm not sure about your experience, but companies which have strong code review practices also have strong controls on the third party code. In terms of review granularity, it makes more sense to be critical of maintenance/readability for code you actually own and maintain. Third party code has a lower bar and should, although I also believe it needs to be reviewed

Yeah I think this is the common case. I think we usually trust that dependency A took a look at their dependency B and C before releasing a new version of A. And even if properly reviewing our bump of A, how often do we check out changes in B and C

Edit: yes for FAANG-ish companies this is usually a bit different, for this reason. And licenses..

>while so much time goes into code reviews to verify internal changes at most companies

Maybe at FAANGs, but I work at a massive company and code review is non-existent.

I think this almost the default even outside of FAANG, of course there’s companies not applying it.

Some might say RMS was right all along.

I would actually say that he is completely wrong in this case. Open source created this problem.

The problem niver would have been fixed in proprietary software. And it's unlikely the problem would have been considered anything more than a 0.5s startup delay in some situations if xz were proprietary; it would have been reported as a performance issue to the malicious maintainer, who would have treated it as such and improved the startup time.

And you think proprietary code doesn't have this problem?

Can you prove it? Where's the evidence? ;)

Lack of proof in any direction is approaching the core issue here.

> while so much time goes into code reviews to verify internal changes at most companies

Very easy claim to make. Difficult to verify.

Yes, this is anecdotal, but I think there’s a fair share invested into it (from my experience)

And he was in the project for just 2 years.

Only on Github. Not on the Tukaani mirror.

Because nobody’s really paying attention.

“LGTM!”

Generally yes, but ripping all conditions out of SECURITY.md should at least raise an eyebrow?

Nobody was watching. Plain and simple.

If you have commit access to it, and nobody is there to see, nothing stops you.

Yes but if that’s the sentiment how is this not as problematic as the npm ecosystem.

It’s similarly problematic but on a somewhat smaller scale and with fewer levels of nested dependencies.

I’m not sure this would be smaller scale? At least probably too early to tell?

I just mean fewer total packages and fewer maintainers. Linux libraries and packages don’t have the culture of making a package out of a single small function and importing it everywhere, which is part of the reason why NPM is a good case study in opportunities for supply chain attacks.

Yes but the distribution likely depends on it, making it wider spread even without the middleman dependencies.