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

Reflections on Distrusting xz

joeyh.name

Post reply on HN
Print view View original

301–310 of 335 posts

Re: Reflections on Distrusting xz

#301

Post by brabel »

iron-s wrote: post #59
brabel wrote: post #50

Earlier quoted context omitted.

Everyone working on important open source code should have a real identity associated with them. The fact that "Jia Tan" was able to become a maintainer without anyone ever trying to figure out their real identity shows a huge weakness in our trust model in OSS (everyone real would have something like a Linked In page, Facebook, Twitter, Instagram, or better, their own website with stuff that could be used to ensure…

What is real identity? Anything online can be faked. A state-issued id? How that protects against nation state?

Nothing protects you if you're up against a state. That doesn't mean we should give up completely.

Do you have a passport? That's a real identity in most places. Soon, it may be possible to use that to link your identity to a set of public keys which you can then use to identify yourself.

There's a lot of work to be done to make this a reality, but work is surely going on right now and this is going to be possible one day.

Check this out, as a starting point: https://curity.io/resources/learn/verifiable-credentials/

Re: Reflections on Distrusting xz

#302

Post by brabel »

nottorp wrote: post #110
brabel wrote: post #50

Earlier quoted context omitted.

Everyone working on important open source code should have a real identity associated with them. The fact that "Jia Tan" was able to become a maintainer without anyone ever trying to figure out their real identity shows a huge weakness in our trust model in OSS (everyone real would have something like a Linked In page, Facebook, Twitter, Instagram, or better, their own website with stuff that could be used to ensure…

Why would I trust an "important open source project" with my identity? It goes both ways. Besides, the 'state actor' the security theater people keep mentioning would have no trouble creating such real identities.

If you don't trust the project, you wouldn't contribute to it.

The state actor may be able to fake identities, but that would still allow tracking the identity to a particular state... and if caught multiple times, that state would start losing credibility and projects may choose to stop trusting people from such nationality, unfortunately, or at least require more strong evidence the person is real and trustworthy if they come from known rogue nations.

Re: Reflections on Distrusting xz

#303

Post by brabel »

selfmodruntime wrote: post #66
brabel wrote: post #50

Earlier quoted context omitted.

Everyone working on important open source code should have a real identity associated with them. The fact that "Jia Tan" was able to become a maintainer without anyone ever trying to figure out their real identity shows a huge weakness in our trust model in OSS (everyone real would have something like a Linked In page, Facebook, Twitter, Instagram, or better, their own website with stuff that could be used to ensure…

Who are you to propose requirements onto people who work for free?

I am not imposing anything on anyone. I am only saying that an OSS project that aims to be used as part of important infrastructure should impose at least some sort of identity vetoing and not just make random anonymous users maintainers of anything.

If your project is not important and you don't care about any of this security stuff, feel free to continue publishing your untrustable projects.

Re: Reflections on Distrusting xz

#304

Post by ahartmetz »

justinsaccount wrote: post #211
loftsy wrote: post #86

I took a look at the diff linked in the article with code that "we are all running". The top of the diff certainly looks interesting. They remove the bounds check in dict_put() and add a safe version dict_put_safe(). This kind of change is difficult to make without mistakes because it silently changes the assumptions made when code calling dict_put() was originally written. ALL call sites would need to be audited to…

Also because the 'safe' version only checks dict->pos == dict->limit and not dict->pos >= dict->limit if you can get one call of dict_put somewhere to pass the limit, all later calls of dict_put_safe will happily overwrite memory and not actually be safe.

Wow, that is 1000% obviously malicious

Re: Reflections on Distrusting xz

#305

Post by nottorp »

brabel wrote: post #302
nottorp wrote: post #110

Earlier quoted context omitted.

Why would I trust an "important open source project" with my identity? It goes both ways. Besides, the 'state actor' the security theater people keep mentioning would have no trouble creating such real identities.

If you don't trust the project, you wouldn't contribute to it. The state actor may be able to fake identities, but that would still allow tracking the identity to a particular state... and if caught multiple times, that state would start losing credibility and projects may choose to stop trusting people from such nationality, unfortunately, or at least require more strong evidence the person is real and trustworthy i…

> If you don't trust the project, you wouldn't contribute to it.

Trust them to merge a bugfix is different from trusting them with my identity isn't it?

There are degrees of trust. For example I have a gmail address in my profile because the spam filter on there is better than what I have on my personal domain. People I've known for longer, business or otherwise, get the other (that I read more often).

Re: Reflections on Distrusting xz

#306

Post by kzrdude »

dspillett wrote: post #256
WesolyKubeczek wrote: post #111

Earlier quoted context omitted.

> If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point. I heard someone calling themselves “Honest Ivan” has just the thing, totally trustworthy.

Given how spread the copies could be, and that we know when the bad actor gained the level of control needed to upset history, or if we want to go further back when that user started making contributions, it is likely that by comparing many claims we can prove to a reasonable level of assurance¹ that a given version is untouched in that regard. Furthermore the original main maintainer seems to have a repository with…

It should be easy to go back to https://snapshot.debian.org/ and one more repository and verify old untainted releases between the two archives.

Re: Reflections on Distrusting xz

#307

Post by kzrdude »

frankjr wrote: post #51
lrem wrote: post #35

Earlier quoted context omitted.

But this suggests reimplementing xz/lzma. Which would cost money. Hence, won't be done.

But there are alternatives, most notably zstd.

sadly, the zstd cli tool links to lzma right now (as installed by some distros) :/

Re: Reflections on Distrusting xz

#308

Post by Gormo »

acdha wrote: post #295
Gormo wrote: post #287

Earlier quoted context omitted.

> It is a national security issue as long as systems which national security depend on are running the code in question. This is itself a category error. By this standard anything and everything upstream of certain government agencies implicates a "national security", and you might as well say that the supply chain for staplers is a national security issue because government officials staple documents together, or th…

> you might as well say that the supply chain for staplers is a national security issue because government officials staple documents together, or that the manufacture of socks is a national security issue because government agents wear socks. You’re leaving out the key part: this only works if there’s a way for a flaw in those staples or socks to impact national security functions. Once you correctly make the analog…

What if a threat actor embedded secret listening devices into staplers? What if wool socks specifically designed to maximize ESD discharge were used to disable sensitive equipment?

Organizations that are concerned with outlandish risks like these implement their own policies and procedures to safeguard against them. They might x-ray office supplies before allowing their use in secure facilities; they might maintain a short list of approved fabrics in an ESD-sensitive environment. The point is that organizations that have exceptional security requirements apply their own policies and procedures to mitigate risk, and don't expect parties upstream of them do so for them.

Re: Reflections on Distrusting xz

#309

Post by acdha »

Gormo wrote: post #308
acdha wrote: post #295

Earlier quoted context omitted.

> you might as well say that the supply chain for staplers is a national security issue because government officials staple documents together, or that the manufacture of socks is a national security issue because government agents wear socks. You’re leaving out the key part: this only works if there’s a way for a flaw in those staples or socks to impact national security functions. Once you correctly make the analog…

What if a threat actor embedded secret listening devices into staplers? What if wool socks specifically designed to maximize ESD discharge were used to disable sensitive equipment? Organizations that are concerned with outlandish risks like these implement their own policies and procedures to safeguard against them. They might x-ray office supplies before allowing their use in secure facilities; they might maintain a…

Socks and staplers are not part of the security infrastructure. Computers are, and that means it’s in the interests of everyone to keep them secure.

Re: Reflections on Distrusting xz

#310

Post by MattPalmer1086 »

XorNot wrote: post #168
MattPalmer1086 wrote: post #124

Earlier quoted context omitted.

Nation state actor is a standard info sec term. Using it does not imply any kind of wizardry. Edit: most threat actors do not have the patience or the motive to behave in this way. It is reasonable to suppose that this is a nation state actor.

There are organised crime networks which buy 0-days to run ransomware, and actively target companies to do it. Why couldn't this be an attempt at finding or selling exploit access on the black market? The problem here is no one is looking properly at the scope. It's more then trivial so everyone is leaping for "nation-state" as though that's the only threat actor with motivation and patience.

Granted, other threat actors remain a possibility, there is no proof.

It looks like the sort of thing nation states would do and develop. It could be some other group hoping to make money as you say.

Whoever they are, they seem to have good opsec, over multiple years.

Post reply on HN