Maybe not by itself, but it does allow for the ecosystem to be audited, in a way that ultimately benefits the end-user. It really is an important part of a healthy supply chain.
no problem in Debian since the start of the effort would be solved by reproductible builds
This is nice pat yourself on the back achievement for people that prefer security theatre and checking boxes than doing something actually useful, and they wasted thousands man hours of poor victims that had to implement it
That's not what reproducible builds aim to prevent, and no one claims that. When upstream pushes bad code, that's on upstream.
The thing reproducible builds aim to prevent is Debian or individual developers and system administrators with access rights to binary uploads and signing keys to get forced to sign and upload binary packages by attackers - be these governments (with or without court orders) or criminal organizations.
As of now, say if I were an administrator of Debian's CI infrastructure, technically there would be nothing preventing me from running an "extra" job on the CI infrastructure building a package for openssh with a knock-knock backdoor, properly signing it and uploading it to the repository. For someone to spot the attack and differentiate it, they'd have to notice that there is a package in the repository that has no corresponding build logs or has issues otherwise.
But with reproducible builds, anyone can set up infrastructure to rebuild Debian packages from source automatically and if there is a mismatch with what is on Debian's repository, raise alarm bells.
Reproducible builds shows that, within a specific configuration, the code produced the binary, regardless of who signed or published it.
Indeed, this could mitigate an attacker replacing the binary with something that's not produced from the code, but it does not mitigate the tool chain or code itself containing the exploit, creating a malicious binary.
Debian has had a better "software supply chain" posture than any other player in the ecosystem since before the turn of the century. While we all face the risk of malware from upstream, Debian is the least at risk of being affected by it. See for example the stream of issues from npm et al. None of it has affected Debian.
It's npm that's affected, therefore it's not even considered when choosing language/ecosystem for writing distro tools. You'll find no sane distro writing package manager in javascript precisely to avoid this joke of a supply chain.
I quite like the OpenBSD approach to Go and Rust projects in ports. They store all the dependencies and their hashes in the build recipe, not trusting the project ones. And they’re more readable.
Here is jujutsu’s list of dependencies[0] and their hashes[1]. As an aside, that’s why I don’t like those packages managers. Something like Python’s numpy or lib curl, get sliced into atomic portions.
Why should it only be valuable if the effects were to be publicly known?
There are plenty of places in industrial computing where reproducible builds have prevented subterfuge within the organizations themselves. Injecting binaries to do inf-/exfiltration is a long-standing industrial espionage activity which is of immense value to all users of the operating system - not just the consumer users.
My magic beans have prevented thousands of tiger attacks in top secret underground moon bases, never you mind that there's no way for me to actually prove this.
There's a certain irony in pushing for verifiable builds with completely unverifiable claims.
I've worked at several of the biggest targets for espionage, industrial or otherwise, and to the best of my knowledge, the only thing that's ever been discovered by their reproducible build efforts has been failing hardware on build reproducers
You probably don’t have enough experience with professional enterprise IT departments. Rootfs audits are a thing made a lot easier, and more effective, with reproducible builds.
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.
“Hasn’t happened” is quite naive. It happens internally - putting unscrupulous code in a company’s distro before torching the place is a surprisingly regular occurrence in places which have long since adopted Debian as a platform host. IT departments around the globe will benefit from this immensely.
The one single fail point they prevent is infected build hosts.
That might be some reasonable benefit for the company if it is building it on public architecture, but for projects like Debian that insist build hosts are basically offline (package in, package out with no internet access during build process) it is very fringe benefit.
This is some of the best news I've heard recently when it comes to figuring out how to produce high quality Software Bills of Materials for the upcoming EU Cyber Resilience Act, for what it's worth. Reproducible packages are actually worth a great deal when you are selling products with digital elements. Much easier to scan through, audit, etc. with confidence.
If you find yourself holding opinions of the kind: "If it can't be made perfect, it shouldn't be changed at all?" you may want to consider that most things that work well today were incrementally improved.
Reproducable builds are not solving all issues as you rightly observed, but they can be a stepping stone (or even a pre-condition) for further measures.
Well - reproducible also means code guarantee. It may not improve an end-user experience directly, but you get an extra quality control step, as guarantee, here. I think reproducibility is great. If we can achieve that, it should be achieved. See also NixOS; it can guarantee that snapshot xyz works, not just for one user, but ALL users. I see it as hopping from guarantee to guarantee. That's actually a good thing in the long run. Just think differently here.
You could already do that since Debian cryptographically signs all its package indexes, and the indexes contain the hash of all packages. The additional guarantee that reproducible builds bring is that you can re-build the packages in your own controlled environment and verify that the resulting package is bit-for-bit identical to what Debian offers.
Cryptographic signatures only protect against MitM (something extremely rare in the real world) and do nothing against compromised Debian infrastructure and supply chains (the real attack vector 99% of the time).
> Reproducible builds protect against all attacks.
Generic statements like this are always false. As a simple rebuttal, reproducible builds do not protect against source-level attacks such as intentional backdoors or disabled/obfuscated access checks. In fact, I'd say that reproducible builds protect against one class of attacks only: compromise of the build infrastructure.
Certs may still be the right approach, but OpenSSH also supports an AuthorizedKeysCommand which could be a secure HTTPS request to a central server to pull down a dynamically generated authorized_keys file content for the particular user and host.
If your endpoints can securely and reliably reach a central server, this gives you maximum control (your authorized_keys HTTPS server can have any custom business logic you want) without having to deal with certs/CAs.
Exactly. This is really useful in larger organizations where you may want more complex rules on access. For example, you can easily build "break glass" or 2nd party approved access on demand. You can put whatever logic you need in a CA front-end.
You can also make all the certs short-lived (and only store them in ram).
And when your or someone else's infra down to such a degree that you need SSH access, you do not want to depend on being able to touch that machine first. The same is true with custom AuthorizedKeysCommands that phone home.
Child abuse might be a large driver behind dysfunctionality in adulthood, with disability or early retirement as a consequence. There were some big child neglect cases around the millennium, since them, the topic got more attention from researchers.
It used to be that traumatised kids got slapped with a ADHD, autism and/or borderline diagnosis and it got called a day. These are "that's just how you are" style diagnoses. Since 2018 there is CPTSD which finally connects the symptoms to how you got treated as a child. The denial phase is over.
Lawmakers are a bit behind, as usual, but at this point the scale of the problems can't be denied anymore. Its too late for you and me, but I'm optimistic for future generations.
We're in the over-correcting phase, where every person alive is an abuse survivor of varying seriousness.
For what it's worth I'm not a cynical person against psychology, and I read both the DSM and the ICD front to back every time a revision comes out. But with every revision, especially for the DSM, I become more concerned that we're creeping towards the "everybody suffers from a multitude of disorders therefore nobody does" territory which will bring us right back to ignoring people who need help.
> where every person alive is an abuse survivor of varying seriousness
An odd way to frame it but probably true.
> which will bring us right back to ignoring people who need help
That does not follow - if the environmental sources are known, people (especially teachers and social workers) can look out for them and take measures to improve the outcome for the child. And this is what I'm seeing right now.
See it on a societal scale - for the same effort put into raising kids, you get more functional adults.
ADHD and other mental issues are under-diagnosed in dysfunctional or toxic families, and of course exist in very stable caring families, so I would be very curious in which data link the very different symptoms you cite directly to trauma. It feels like going back to the era of shaming mothers for autism.
This is not ruling out a causal link in the opposite direction, that autism increases vulnerability to traumata.
And while researching case reports on child abuse, i couldn't help to notice that many cases do - indeed - start with an autism diagnosis and only escalate later, example: https://pmc.ncbi.nlm.nih.gov/articles/PMC11886450/
While its true that parents don't cause autism... they can surely cause the diagnosis. Extra bad because it delays appropriate treatment.
> It used to be that traumatised kids got slapped with a ADHD, autism and/or borderline diagnosis and it got called a day. These are "that's just how you are" style diagnoses. Since 2018 there is CPTSD which finally connects the symptoms to how you got treated as a child.
This was my childhood.
Unfortunately for some the narrative of the perfect family is too precious for others to step up and intervene. It's taboo to accuse someone of being a bad parent, even if it's the truth.
Even away from my abusers for decades, the resulting issues have continued into my adulthood and led to near daily struggle that seems to have no end. With my family I've had to choose my battles and my therapist is the only one who both believes me and is trained to give me the support I require to mentally survive in the adult world, one I would otherwise be unprepared for. Without a good enough job I wouldn't be able to pay them and that support would evaporate.
Imagine if a huge percentage of the drama and anger that shows up online is rooted in formative trauma that nobody will ever admit out loud, and as a result we're distracted by trying to address completely unrelated sources of outrage.
"secret" not in the sense that it's hidden, but that most people won't know about it. Because approximately nobody actually reads man pages in their entirety, they just get in to find out how a specific flag works and then get out.
the difference is that knowing 2^8 is generally not useful to people who don't know it
this here is something that's pretty useful to most ssh users, yet seldom spoken of
a better analogy would be comparing it to calling a very good, but not well-known restaurant a secret place - using the word to mean a hidden gem rather than an intentionally hidden secret
ModemManager used to open() and probe every tty device attached to the system. I had a 8-channel relay card with an arduino nano wired up with my desk to control the lights and disco ball, interfaced with a custom ascii-based serial protocol. connecting it to an ubuntu machine (where modemmanager was active in the default install) turned the 2nd or 3rd channel on.
This was generally infuriating, there are many arduino forum posts about modemmanager messing up DIY setups.
Upstream fix was changing modemmanager to work on a whitelist / opt-in approach instead of blacklist / out-opt. My fix was to switch to debian.
reply