Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

Post reply on HN
Print view View original

411–420 of 482 posts

Re: Timeline of the xz open source attack

#411

Post by bigiain »

larntz wrote: post #400
sfjailbird wrote: post #398

Earlier quoted context omitted.

It would be intetesting if Lasse Collin published his off-list interactions with 'Jia Tan' and any of the other pseudonyms, to get an even better angle on the social engineering parts. Apparently a large part of the campaign was via private channels to Lasse.

I was wondering if that would be released also. I hope so but wouldn't blame them if they decide not to.

I wouldn't blame then if they've thrown all their computers into the sea, changed their name, and taken upon a job building timber furniture...

Re: Timeline of the xz open source attack

#412

Post by publius_0xf3 »

sfjailbird wrote: post #398
gawa wrote: post #47

Excellent summary of the events, with all the links in one place. This is the perfect resource for anyone who want to catch up, and also to learn about how such things (especially social engineering) unfold in the wild, out in the open. One thing that could be added, for the sake of completeness: in the part "Attack begins", toward the end, when they are pushing for updating xz in the major distros, Ubuntu and Debian…

It would be intetesting if Lasse Collin published his off-list interactions with 'Jia Tan' and any of the other pseudonyms, to get an even better angle on the social engineering parts. Apparently a large part of the campaign was via private channels to Lasse.

Collin has been writing more extensively on IRC. A screenshot of one of his posts can be seen in [this YouTube video](https://youtu.be/0pT-dWpmwhA?t=1158).

He notes that while he was unsatisfied with some of the changes Tan introduced, Tan was nonetheless extremely helpful.

Re: Timeline of the xz open source attack

#413

Post by nickm12 »

userbinator wrote: post #86

I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.

I don't believe this will result in conservatism around upgrading nor that it would be good if it did. The vast, vast majority of security vulnerabilities are due to regular bugs and once the details are known, they can be exploited. Not patching leaves you open to these exploits.

Supply chain attacks are a real threat too, but being conservative about upgrading to improve your security posture is like saying "I'm worried someone with the key to my house might rob me, so I'm going to remove the lock from my door."

Re: Timeline of the xz open source attack

#414

Post by jtriangle »

bigiain wrote: post #411
larntz wrote: post #400

Earlier quoted context omitted.

I was wondering if that would be released also. I hope so but wouldn't blame them if they decide not to.

I wouldn't blame then if they've thrown all their computers into the sea, changed their name, and taken upon a job building timber furniture...

I, too, have had days like that

Re: Timeline of the xz open source attack

#416

Post by aulin »

cesarb wrote: post #154
jddil wrote: post #121

Earlier quoted context omitted.

Never understood why our industry seems unique in our willingness to do unpaid work for giant corps. Your compression library isn't saving the world, it's making it easier for amazon to save a few bucks. You have the right to be paid for your time. It's valuable. I enjoy coding too... but the only free coding I do is for myself. Use a proper license, charge for your time and stop killing yourself doing unpaid hobby p…

> Never understood why our industry seems unique in our willingness to do unpaid work for giant corps. Your compression library isn't saving the world, it's making it easier for amazon to save a few bucks. The work was not being done "for giant corps"; it was being done for everyone, and giant corps just happen to be a part of "everyone", together with small corps, individual people, government, and so on. > You have…

I'd say you're contributing back. You don't ask anything in return because you live in a ecosystem built on the contributions of everyone, you're just doing your part.

Re: Timeline of the xz open source attack

#417

Post by tripdout »

naikrovek wrote: post #364
tadfisher wrote: post #347

Earlier quoted context omitted.

Ultimately you're going to have to be adept at stuff like the Underhanded C Contest to spot this kind of thing in any Turing-complete language, so the idea of auditing the source is unreliable at worst. So I'd take another page from the Java/Maven ecosystem and require hashed+signed binaries, with the possible addition of requiring builds to be performed on a trusted remote host so that at least we can verify the bin…

reproducible builds never made sense to me. if you trust the person giving you the hash, just get the binary from them. you don't need to reproduce the build at all. if you trust that they're giving you the correct hash, but not the correct binary, then you're not thinking clearly.

But you can build the code yourself, and verify that your hash is the same as theirs, meaning the binary is the same.

Re: Timeline of the xz open source attack

#418

Post by johnny22 »

npteljes wrote: post #291
johnny22 wrote: post #254

Earlier quoted context omitted.

A big problem is that people allow this sort of thing as part of the culture. I've followed the Fedora and PHP development mailing lists a few different times over the years ans this sort of thing was tolerated across the board. It doesn't matter if you crowdsource the moderation if nobody thinks the behavior is bad in the first place. Trying to do something about it was called censorship.

I'm sorry I don't understand your point clearly. Why is it a big problem, and whose problem it is?

The premise of the post I replied to is that the mailing list moderation is currently not great and that it allows people to be abusive. It suggest that we should crowdsource this moderation. I assume they think this will lower the burden.

I myself do not think that this is the actual problem. I think the actual problem is that many FOSS communities have fostered an idea that cracking down on certain types of behavior is censorship. Of course they might all agree to ban somebody who is saying certain well known explicit words or being really really aggressive, but there's a lot of behavior that I would consider bannable but they do not.

I'm trying to avoid mentioning specific cases because I don't wanna either reopen old wounds or cause another similar dustup. I can say that it reminds me a lot of the really old post about the 5 geek social fallacies https://plausiblydeniable.com/five-geek-social-fallacies/ In particular social fallacy #1

Obviously we're not talking about geek culture here (in general anyways). After rereading it, I saw something else that we actually do a see a lot even today.

This in particular has happened on many a mailing list, including the ones I'm not specifically mentioning

>> when nothing smacking of social selectiveness can be discussed in public, people inevitably begin to organize activities in secret.

Well-known annoyances get tolerated for years, and the people who do the work start moving their discussions to bug trackers, irc, or in personal emails to avoid interacting with them.

Re: Timeline of the xz open source attack

#420

Post by ncruces »

psanford wrote: post #193

One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.

That's an improvement, but ultimately not enough, actually. The article hits at this, and you should definitely read it:

Being able to send xz patches to the Linux kernel would have been a nice point of leverage for Jia Tan's future work. We're not at trusting trust [1] levels yet, but it would be one step closer.

[1]: https://research.swtch.com/nih

Post reply on HN