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

Debian must ship reproducible packages

lists.debian.org

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Debian must ship reproducible packages

#141

Post by jcranmer »

uecker wrote: post #123
jcranmer wrote: post #109

Earlier quoted context omitted.

The xz utils compromise is a very good example... of why reproducible packages doesn't actually solve anything security-wise! The backdoor relied first on a difference between building a package in a packaging environment versus building the package on your own. And also, it relied on the very common practice of checking in unreviewable artifacts into the source tree (e.g., the configure script, malicious binary test…

An attack would be far easier without reproducible packages. One could upload a compromised binary to debian by becoming a debian developer, blackmail a debian developer to so, or compromise the computer of a debian developer or the distribution. At the time of xz attack, the package was already reproducible.

I'll give an analogy to email and spam. A lot of effort has been spent making sure that if an email is from x@example.com, it actually came from x@example.com, giving us things like SPF, DKIM, and DMARC. And it turns out that the most eager adopters of the newest technology are... the spammers themselves! Because they don't need to lie about their email address; they can have that be completely honest, and instead resort to other tricks to mislead users as to who they are (e.g., the display name, which most email clients blindly trust and happily display).

Similarly for package managers, the biggest issues are typo-squatting or maintainer credentials compromise. And in neither case does the attacker have any incentive to take advantage of it in a way that breaks reproducibility--they can be completely honest about what they're doing. Now even if I were an attacker who had compromised a maintainer's machine, I'd still probably go for compromising the source rather than compromising the final artifact-generation process... simply because compromising the source makes the exploit live longer.

As xz shows, once you have a compromised maintainer, there's basically nothing you can do to fix it except by having someone else discover the compromise and locking out the maintainer.

Re: Debian must ship reproducible packages

#142

Post by uecker »

PunchyHamster wrote: post #136
uecker wrote: post #125

Earlier quoted context omitted.

A hardware key does not help if the developer's machine is compromised, as there is no change to understand what is signed anymore, or do you think the hardware key will show all the source code on its little display before signing? With reproducible builds, you do not need to trust that the system that build the binary was not compromised, because this would be detected immediately. Source compromises are still an i…

The way at least YK works is that you can set it up that pressing a key is requires for signing so at least "silently steals creds and sends malicious code" case (which is vast majority of compromises) gets handled > Also if there is a compromise, reproducible builds allow you to later track it to the source. They do not. Git log and build logs allow for that. Reproductive builds only have value after the source. The…

If your compiler (or other tool or automatic build environment) is compromised and inserts a backdoor in the binary during building, the fact that you need to hold a key while signing or not is completely irrelevant.

git log and build logs do not help you at all, if you can not even determine that the compromised binary has any relation to the build log or the source you may want to look it. This is what reproducible builds give you. You are right that it does not protect against compromised sources.

Re: Debian must ship reproducible packages

#143

Post by uecker »

jcranmer wrote: post #141
uecker wrote: post #123

Earlier quoted context omitted.

An attack would be far easier without reproducible packages. One could upload a compromised binary to debian by becoming a debian developer, blackmail a debian developer to so, or compromise the computer of a debian developer or the distribution. At the time of xz attack, the package was already reproducible.

I'll give an analogy to email and spam. A lot of effort has been spent making sure that if an email is from x@example.com, it actually came from x@example.com, giving us things like SPF, DKIM, and DMARC. And it turns out that the most eager adopters of the newest technology are... the spammers themselves! Because they don't need to lie about their email address; they can have that be completely honest, and instead re…

Typo-squatting attacks are more of an issue for non-curated software collections, not so much for Debian. If you use npm or cargo or similar, then you have indeed far bigger worries. Compromising the source has the disadvantage for the attacker that it much easier to detect. Again, if you always install the newest things from an non-curated collection that may not matter much, but for something such as Debian, this increases the probability of detection a lot. One can argue that xz shows that it is possible to hide things in the source, but it also shows how much effort was needed to do this. (and the xz package was reproducible, so compromising the debian system and uploading a binary would have a high risk of detection. That this was not done can therefor not serve as evidence that binary attacks are not an issue. )

Re: Debian must ship reproducible packages

#144

Post by kkfx »

kakwa_ wrote: post #37
kkfx wrote: post #15

Debian, like any other legacy distro, mush became declarative, because the '80s model of manual deploy and the absurd pain of D/I and Preseed must end.

In the end, Nix is just a thin veneer on this stuff. Given how many quick & dirty sed patching or exec commands I've seen in the few nix package/modules I've read, I would not exactly bet my life on it being completely idempotent & reproducible.

it's the best option after IllumOS (OpenSolaris) IPS integrated with ZFS. Far less powerful not imposing zfs (only well supported for root, swap, encryption etc), so not integrated in the package system and bootloader management (BEs, Boot Environments).

It's not reproducible bit by bit, it fetch the current version of anything, but it's still easy to reproduce enough, stable enough and complete enough, while classic distros need a fresh install every major release or facing issues an keeping a system in unknown state for long until it explode.

Re: Debian must ship reproducible packages

#145

Post by rstuart4133 »

PunchyHamster wrote: post #113
savolai wrote: post #49

Earlier quoted context omitted.

” If you are wondering why we are doing this at all, then hopefully the Reproducible Builds website will explain why this is useful.” https://reproducible-builds.org/ Could you perhaps respond to the argumentation here?

I know why they are useful. I am arguing they are waste of time for effort involved. Forcing devs to use hardware keys to sign commits/CI requests would be actual security improvement, thwarting many supply chain attacks that only worked coz the attacker got to developer credentials. Hardware keys at least have option to make some operations require physically pressing the key so there is chance developer will notice…

> I know why they are useful. I am arguing they are waste of time for effort involved.

Not being reproducible is a bug.

There is no reason for a build to not be reproducible, but somehow we let the built binaries become infested with timestamps, login names and file system paths. We recently moved to reproducible builds at work, and discovered that our login names and local home directory paths were being shipped in every release. No one was was very happy about leaking PPI like that.

You may not consider it worth the effort, but you aren't the one putting in the effort so I'm not sure why that matters to you. It is very much worth the effort to those people doing the work. Debian is a do-orcracy and so the people doing the work get to make the decisions.

Re: Debian must ship reproducible packages

#146

Post by tardedmeme »

iamnothere wrote: post #91
bluGill wrote: post #79

Earlier quoted context omitted.

I don't think they do, actually. Longevity sounds good, but in reality anything that's old probably has critical security holes and so you shouldn't use it anyway.

A warning is sufficient. Old tech should continue to work, for preservation and archival reasons.

I've long ago realized that archival needs to be a separate task left to archivists and archive systems. If you take it into account when designing a live system it's liable to seriously compromise your system design.

Say you're making a chat app - you wouldn't incorporate a delete feature, and you might be tempted to use some kind of blockchain to prove all messages were delivered without gaps. But if you ignore archival needs you design something similar to IRC which is much simpler.

Re: Debian must ship reproducible packages

#147

Post by matttttttttttt »

lrvick wrote: post #32
jaypatelani wrote: post #14

Good thing. NetBSD has fully reproductible build since 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

While we are bragging, stagex was the first to hit 100% full source bootstrapped deterministic and hermetic builds last year and the first to make multiple signed reproductions by different maintainers on their own hardware mandatory for every release. Debian has come along way, but when Debian says reproducible they mean they grab third party binaries to build theirs. When we say reproducible we mean 100% bootstrapp…

Stage -1: `hexdump`, `xxd`, or whatever you use to write files to your filesystem.

Re: Debian must ship reproducible packages

#148

Post by casey2 »

This fights against "opensource-washing" which is the practice of large companies claiming to release open source code, but the compile takes so long (as well as being overly-convoluted) that most people and many distros can't afford to maintain the package.

It feels like AI and traditional software are converging in complexity.

Re: Debian must ship reproducible packages

#149

Post by charcircuit »

LtWorf wrote: post #75
charcircuit wrote: post #48

Earlier quoted context omitted.

But how many of those attackers also had the ability to publish a github commit but didn't to remain more stealthy.

This question is meaningless. Attackers will pick the best attack if they have more at their disposal. The fact that they didn't push a commit shows it's better not to. So closing that attack is good.

There is meaning. The difference in detection time does have meaning. If the improvement of detection time was marginal there may have been a different project time could have been invested in to make it even faster to catch such things than reproducible builds.

Re: Debian must ship reproducible packages

#150

Post by theteapot »

PunchyHamster wrote: post #114
fsflover wrote: post #97

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/XZ_Utils_backdoor

that's example of attack reproducible packages do not protect from, why you are linking it ?

In xz-utils hack the attacker slipped changes into the Github release tarball that were not present in the Github version / git commit history. The Debian maintainer built from the release tarball instead of just pulling from the git repo directly. Shouldn't have been doing that but good luck convincing him not to use the workflow he's been using for the last X years (I tried). With repro builds we can clone the git directly confirm we get the same build.
Post reply on HN