Why does it seem like so many open source developers suffer from chronic mental health issues? as shown here, in TempleOS, etc. It's a weird but sad pattern I see all of the time.
Timeline of the xz open source attack
201–210 of 482 posts
Re: Timeline of the xz open source attack
#202I guess that Lasse Collin will have more mental health issues after all of this :-)
Do we know who really is Jia Tan? Any photo of him? The email addresses he has been using? His location?
Re: Timeline of the xz open source attack
#203I 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 inconveniences here.
Re: Timeline of the xz open source attack
#204One 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.
Can you explain more in-depth what you mean? I'm also unaware of how you could have declarative rulesets in a non turing-complete language.
Sounds like it would be impossible but maybe my thinking is just enclosed and not free.
Re: Timeline of the xz open source attack
#205Earlier quoted context omitted.
You don't think every nation state has people inside private software shops? Especially big tech? Look at stuff getting signed with MS keys, hardware vendors with possible backdoors. Social engineering is social engineering and it can happen anywhere no matter the profit motivation or lack there of. Money interest in software won't save you any more than Foss.
It'd be naive to assume that nation state actors are not trying to penetrate the supply chain at all levels, as it just takes a single weak link in the chain. That weak link could be behind corporate doors or in the open. The main issue is that this attack shows how a relatively unknown component, as part of a much larger and more critical infrastructure, is susceptible to pressure as a result of "this is a hobby pro…
> this attack shows how a relatively unknown component
why just this one? do we collectively have the memory of a gold fish? just recently, log4j had a similar blast radius. is it because one was seemingly malicious that the other doesn't count?
Re: Timeline of the xz open source attack
#206> merges hidden backdoor binary code well hidden inside some binary test input files. [...] Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves. So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware. It's either in source form and reproducable or it's not there.
>It's either in source form and reproducable or it's not there. Wanna know how I know you haven't read into the discussion much? There are a whole lot of binary test cases in software. Especially when you're dealing with things like file formats and test cases that should specifically fail on bad data of particular types.
> There are a whole lot of binary test cases in software.
That's not how I read GP's point. If even binary blobs in test cases are a place where backdoors are, now as a matter of fact, hidden then, certainly, among the folks advocating for binary drivers in FOSS, there are some who are already --or planning to-- add backdoors there.
Binary blobs are all terrible, terrible, terrible ideas.
Builds should be 100% reproducible from source, bit for bit. At this point it's not open up for discussion anymore.
Re: Timeline of the xz open source attack
#207I guess that Lasse Collin will have more mental health issues after all of this :-) Do we know who really is Jia Tan? Any photo of him? The email addresses he has been using? His location?
What makes you think they are an actual person?
Re: Timeline of the xz open source attack
#208I 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 would be able to independently verify nothing funky happened.
Re: Timeline of the xz open source attack
#209What are the chances this is the first such attack, not just the first one discovered. Presumably every library or service running as root is open to attack and maybe also some running in userspace. The attack surface is massive. Time for better sandboxing? Once attackers get into the build systems of Debian and others is it game over?
Re: Timeline of the xz open source attack
#210I 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…
Yes the whole "let's take a mystery meat tarball from a repo that isn't the project repo" seems suspect.
Github+ even has a scheme for signing artifacts such that you have some level of trust they came from inside their Actions system, derived from some git commit. This would allow the benefits of a modular build for a large product like a distro, while preserving a chain of trust in its component parts.
+Not advocating a dependency on Github per se -- the same sort of artifact attestation scheme could be implemented elsewhere.