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

221–230 of 482 posts

Re: Timeline of the xz open source attack

#221

Post by hyperman1 »

kibwen wrote: post #197
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 a great first step, but ready your pitchforks for this next take, because the next step is to completely eliminate Turing-complete languages and arbitrary I/O access from standard build systems. 99.9% of all projects have the capability to be built with trivial declarative rulesets.

Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left.

There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverage, source code generation,...

Today, a maven project without plugins is rare. Maven brought us 95%, but there is a long tail left to cover.

Re: Timeline of the xz open source attack

#222

Post by gregwebs »

maclockard wrote: post #208
gregwebs wrote: post #203

I think this can be made much more difficult by enforcing a policy of open builds for open source. It shouldn't be possible to inject build files from a local machine. All build assets should come from the source repository. Artifacts should come from Github Actions or some other tool that has a clear specification of where all inputs came from. Perhaps Github could play a role in helping to automate any inconvenienc…

I think that trust needs to be 'pushed deeper' than that so to speak. While this would be an improvement, what happens if there is a malicious actor at Github? This may be unlikely, but would be even harder to detect since so much of the pipeline would be proprietary. Ideally, we would have a mechanism to verify that a given build _matches_ the source for a release. Then it wouldn't matter where it was built, we woul…

Vendor independent build providence is certainly the long-term goal. In the immediate-term moving away from mystery tarballs towards version control gets us a step closer.

One of the best things about Golang is that packages are shared direct via source repositories (Github) rather than a package repository containing mystery tarballs. I understand the appeal of package repositories, but without proper security constraints it's a security disaster waiting to happen.

Re: Timeline of the xz open source attack

#223

Post by Sammi »

Dalewyn wrote: post #213
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.

[flagged]

Javascript is pretty much guaranteed to be permanent. It is the language of the web.

(There's webassembly too, but that doesn't remove js)

Re: Timeline of the xz open source attack

#224

Post by kibwen »

hyperman1 wrote: post #221
kibwen wrote: post #197

Earlier quoted context omitted.

That's a great first step, but ready your pitchforks for this next take, because the next step is to completely eliminate Turing-complete languages and arbitrary I/O access from standard build systems. 99.9% of all projects have the capability to be built with trivial declarative rulesets.

Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left. There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverag…

> Findbugs, code coverage, source code generation,...

For the purpose of this conversation we mostly just care about the use case of someone grabbing the code and wanting to use it in their own project. For this use case, dev tools like findbugs and code coverage can be ignored, so it would suffice to have a version of the build system with plugins completely disabled.

Code generation is the thornier one, and we can at least be more principled about it than "run some arbitrary code", and at least it should be trivial to say "this codegen process gets absolutely no I/O access whatsoever; you're a dumb text pipeline". But at the end of the day, we have to Just Say No to things like this. Even if it makes the codebase grodier to check in generated code, if I can't inspect and audit the source code, that's a problem, and arbitrary build-time codegen prevents that. Some trade-offs are worth making.

Re: Timeline of the xz open source attack

#226

Post by dekhn »

Why do I feel like this set of posts by Russ about supply chain security will end up with a proposal/concrete first implementation of a supply-chain-verified-build process that starts at chip making - simple enough to analyze and rebuild independently- to bootstrap a go runtime that provides an environment to do secure builds.

Reflections on Trusting Trust becomes even more interesting if you consider photolithography machines being backdoored.

Re: Timeline of the xz open source attack

#227

Post by rurban »

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.

Great, let the cmake dummies wander off into their own little dreamworld, and keep the professionals dealing with the core stuff.

Re: Timeline of the xz open source attack

#229

Post by phicoh »

dylan604 wrote: post #161
phicoh wrote: post #94

Earlier quoted context omitted.

I think a problem is that there doesn't seem any way to automatically check this. If we assume that anything that is used during build time can be malicious then figuring out those dependencies is already hard enough. Mapping that to organizational stability is one step further.

This is where the but FOSS is reviewable so it is trusted falls down. This situation is a prime example of how that fallacy is misconstrued. By being FOSS didn't make it trustworthy, it just meant that people had a fighting chance to find out why when something does happen. That's closing the barn door after the horses already left. I'm not knocking FOSS at all. I just think some people have the concept twisted. Just…

We should not think in absolutes, but in terms of tools. What risks come with using a certain tool.

In your Rust example, using C is like using a power tool without any safety measures. That doesn't mean that you are going to get hurt, but there is an expectation that a sizable fraction of users of such tools will get hurt.

Rust is then the same tool with safety measures. Of course it is still a power tool, you can get hurt. But the chances of that happening during normal operation is a lot lower.

I think xz is a good example where open source happened to work as intended. Somebody noticed something weird, alerted and other people could quickly identify what other software might have the same problem.

Re: Timeline of the xz open source attack

#230

Post by __float »

deathanatos wrote: post #198

> Evan Boehs observes that Jigar Kumar and Dennis Ens both had nameNNN@mailhost email addresses This is the second time I've read this "observation", but this observation is just wrong? Jigar's email is "${name}${number}@${host}", yes, but Dennis's is just "${name}@${host}" — there's not a suffixed number. (There's a 3, but it's just a "leetcode" substitution for the E, i.e., it's semantically a letter.) (They could…

Where are the email addresses visible? I've also seen this a few times, but never the actual addresses.
Post reply on HN