5 ms·

zero improvement on end-user experience. does not solve supply chain issues, debian package will reproducabily contain the malware from upstream.

rlpb 5mo ago
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.
- alkindiffie 5mo ago
  > for example the stream of issues from npm et al. Curious, what distros where affected by npm supply chain attacks?
  - throw_a_grenade 5mo ago
    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.
    - skydhash 5mo ago
      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. [0]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/crates.inc https://github.com/openbsd/ports/blob/master/devel/jujutsu/c... [1]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/distinfo https://github.com/openbsd/ports/blob/master/devel/jujutsu/d...
    - cxr 5mo ago
      ECMA-262 doesn't require the use of NPM or NodeJS. (In fact, they are at odds, even 10+ years after modules were standardized in ES6.)
- suprjami 5mo ago
  You do remember the xz-utils backdoor was found in Sid right? https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
  - Dwedit 5mo ago
    It would have been found in a whole lot more places if it hadn't been for that meddling Microsoft employee.
iveqy 5mo ago
It does not solve all supply chain issues, it do solve some supply chain issues. Not being able to see if the source code shipped is the same as been used for creating the binary is scary
- murderfs 5mo ago
  Has there been a single publicly known attack that would have been prevented by this?
  - PunchyHamster 5mo ago
    Zero in Debian. They have enough other procedures to catch it. Less diligent projects had it but there are easier ways to fix it
  - LtWorf 5mo ago
    Several actually. Pypi is regularly targeted in this way.
    - PunchyHamster 5mo ago
      Hasn't happened in Debian
      - MomsAVoxell 5mo ago
        “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.
        PunchyHamster 5mo ago
        And reproducible builds do not prevent that. 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.
quantummagic 5mo ago
> zero improvement on end-user experience. 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.
- miohtama 5mo ago
  [flagged]
  - testdelacc1 5mo ago
    While taking no stance on your statement, I think “fewer” works better in this context than “less”.
    - gjvc 5mo ago
      "fewer" when the measure is discrete, "less" when it is continuous
  - LtWorf 5mo ago
    NK isn't the hostile superpower I'm most concerned about.
- PunchyHamster 5mo ago
  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
mschuster91 5mo ago
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.
- ownagefool 5mo ago
  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.
shevy-java 5mo ago
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.
hiAndrewQuinn 5mo ago
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.
atoav 5mo ago
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.
otabdeveloper4 5mo ago
> zero improvement on end-user experience The end-user experience is that now you can host your Debian binaries in caches and CDNs without worrying about supply chain hackers. You can verify that file hashes match the ones on Debian's website and sleep much better at night. If you don't trust Debian's website then you can rebuild yourself and check if Debian has been compromised.
- tremon 5mo ago
  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.
  - otabdeveloper4 5mo ago
    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.
    - tremon 5mo ago
      > 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.
MomsAVoxell 5mo ago
Who is this mythical end user? Reproducible builds are good for everyone - not just the average joe.

rlpb 5mo ago

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.

alkindiffie 5mo ago
> for example the stream of issues from npm et al. Curious, what distros where affected by npm supply chain attacks?
- throw_a_grenade 5mo ago
  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.
  - skydhash 5mo ago
    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. [0]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/crates.inc https://github.com/openbsd/ports/blob/master/devel/jujutsu/c... [1]: https://github.com/openbsd/ports/blob/master/devel/jujutsu/distinfo https://github.com/openbsd/ports/blob/master/devel/jujutsu/d...
  - cxr 5mo ago
    ECMA-262 doesn't require the use of NPM or NodeJS. (In fact, they are at odds, even 10+ years after modules were standardized in ES6.)
suprjami 5mo ago
You do remember the xz-utils backdoor was found in Sid right? https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
- Dwedit 5mo ago
  It would have been found in a whole lot more places if it hadn't been for that meddling Microsoft employee.

iveqy 5mo ago

It does not solve all supply chain issues, it do solve some supply chain issues. Not being able to see if the source code shipped is the same as been used for creating the binary is scary

murderfs 5mo ago
Has there been a single publicly known attack that would have been prevented by this?
- PunchyHamster 5mo ago
  Zero in Debian. They have enough other procedures to catch it. Less diligent projects had it but there are easier ways to fix it
- LtWorf 5mo ago
  Several actually. Pypi is regularly targeted in this way.
  - PunchyHamster 5mo ago
    Hasn't happened in Debian
    - MomsAVoxell 5mo ago
      “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.
      - PunchyHamster 5mo ago
        And reproducible builds do not prevent that. 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.

quantummagic 5mo ago

> zero improvement on end-user experience. 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.

miohtama 5mo ago
[flagged]
- testdelacc1 5mo ago
  While taking no stance on your statement, I think “fewer” works better in this context than “less”.
  - gjvc 5mo ago
    "fewer" when the measure is discrete, "less" when it is continuous
- LtWorf 5mo ago
  NK isn't the hostile superpower I'm most concerned about.
PunchyHamster 5mo ago
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

mschuster91 5mo ago

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.

ownagefool 5mo ago
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.

shevy-java 5mo ago

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.

hiAndrewQuinn 5mo ago

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.

atoav 5mo ago

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.

otabdeveloper4 5mo ago

> zero improvement on end-user experience The end-user experience is that now you can host your Debian binaries in caches and CDNs without worrying about supply chain hackers. You can verify that file hashes match the ones on Debian's website and sleep much better at night. If you don't trust Debian's website then you can rebuild yourself and check if Debian has been compromised.

tremon 5mo ago
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.
- otabdeveloper4 5mo ago
  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.
  - tremon 5mo ago
    > 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.

MomsAVoxell 5mo ago

Who is this mythical end user? Reproducible builds are good for everyone - not just the average joe.