5 ms·

Reproducible builds are applicable not only to respond to ‘attacks’, a subject you seem to be bikeshedding, but also for other reasons too. Anyone having to ma

Reproducible builds are applicable not only to respond to ‘attacks’, a subject you seem to be bikeshedding, but also for other reasons too. Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go. Reproducible builds are about longevity as much as they are about security. Please don’t make bold claims about ‘no reason and little benefit’ while demonstrating ignorance of this hard fact: reproducible builds should have been the norm, in computing, from the get-go.

bluGill 6mo ago
I longevity is harmed though. Your certs need to expire in a few years we think that your toolchain will not be downloadable.
- MomsAVoxell 6mo ago
  Those problems need to be solved as well.
  - bluGill 6mo ago
    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.
    - iamnothere 6mo ago
      A warning is sufficient. Old tech should continue to work, for preservation and archival reasons.
      - PunchyHamster 6mo ago
        just archiving binary artifacts and source packages is enough Reproducibility adds nothing here
        MomsAVoxell 6mo ago
        It sure does: no need to keep the binaries around if they are reproducible.
      - tardedmeme 6mo ago
        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.
        iamnothere 6mo ago
        That depends on your user base. If your group of target users includes professional, corporate, or governmental use, then you absolutely need to build in signing and archival for legal reasons. If your users include people who may only connect occasionally or with flaky connections, then you need a robust way to ensure that messages are held for delivery and that all messages are delivered in order. Basic chat (without delivery guarantees or archival) is already solved by IRC, long ago.
    - MomsAVoxell 6mo ago
      You’re not thinking like an industrial user but rather as a consumer. Maybe you should extend your scope a little bit.
      - bluGill 6mo ago
        Industry is learning - often the hard way that out of date software is only acceptable if the device is not connected to a network at all. Even government labs with a separate top secret network that isn't supposed to be connected to anything else get hacked from the internet. Not that you are wrong, industry keeps thinking they can make themselves immune and so long term reproducibility is useful, but I submit they are wrong.
        MomsAVoxell 6mo ago
        Disclaimer: I work in the safety-critical/industrial sector of software. Literally none of your statements are applicable to that realm, sorry. Rail operators have long since been operating their air-gapped infrastructure with 99.999% safety results, literally not adhering to any of the policies you claim are endemic to the industry.
    - MomsAVoxell 6mo ago
      You probably don’t know how industrial computing works. Toolchains absolutely need to be maintained with some degree of longevity. The whole world doesn’t march to your consumer-user beat. Sometimes it functions at industrial-user tempo’s, too ..
- yjftsjthsd-h 6mo ago
  > your toolchain will not be downloadable. Why not? Debian has a fantastic track record of providing old versions, for instance here's the build tools from Debian 2.0 from 1998: https://mirrors.accretive-networks.net/debian-archive/debian/dists/hamm/main/binary-i386/devel/ https://mirrors.accretive-networks.net/debian-archive/debian...
PunchyHamster 6mo ago
> Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go. Just baking in build ID and commit is enough. What you think reproducible builds add ? > Please don’t make bold claims about ‘no reason and little benefit’ while demonstrating ignorance of this hard fact: reproducible builds should have been the norm, in computing, from the get-go. So far not a single person in the thread gave me concrete example (as in existing project, existing problem, no other solution can solve it). Just claiming it's better based on their feelings. Come on, be the first one.
- MomsAVoxell 6mo ago
  I already gave you an example, you dismissed it because you know better, but it is clear that you haven’t thought this through from the perspective of systems designers who have to deploy a base OS, with expected lifetimes of years, across a large fleet of devices. Think industrial applications, such as rail and heavy industry transportation. We use reproducible builds here as part of a wider safety-critical protocol which guarantees that what we are running is what we expect to run - nothing more, nothing less. Reproducible builds are certifiable. They can be relied on in environments where certification costs millions and takes years. Think outside your consumer box for a minute.

bluGill 6mo ago

I longevity is harmed though. Your certs need to expire in a few years we think that your toolchain will not be downloadable.

MomsAVoxell 6mo ago
Those problems need to be solved as well.
- bluGill 6mo ago
  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.
  - iamnothere 6mo ago
    A warning is sufficient. Old tech should continue to work, for preservation and archival reasons.
    - PunchyHamster 6mo ago
      just archiving binary artifacts and source packages is enough Reproducibility adds nothing here
      - MomsAVoxell 6mo ago
        It sure does: no need to keep the binaries around if they are reproducible.
    - tardedmeme 6mo ago
      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.
      - iamnothere 6mo ago
        That depends on your user base. If your group of target users includes professional, corporate, or governmental use, then you absolutely need to build in signing and archival for legal reasons. If your users include people who may only connect occasionally or with flaky connections, then you need a robust way to ensure that messages are held for delivery and that all messages are delivered in order. Basic chat (without delivery guarantees or archival) is already solved by IRC, long ago.
  - MomsAVoxell 6mo ago
    You’re not thinking like an industrial user but rather as a consumer. Maybe you should extend your scope a little bit.
    - bluGill 6mo ago
      Industry is learning - often the hard way that out of date software is only acceptable if the device is not connected to a network at all. Even government labs with a separate top secret network that isn't supposed to be connected to anything else get hacked from the internet. Not that you are wrong, industry keeps thinking they can make themselves immune and so long term reproducibility is useful, but I submit they are wrong.
      - MomsAVoxell 6mo ago
        Disclaimer: I work in the safety-critical/industrial sector of software. Literally none of your statements are applicable to that realm, sorry. Rail operators have long since been operating their air-gapped infrastructure with 99.999% safety results, literally not adhering to any of the policies you claim are endemic to the industry.
  - MomsAVoxell 6mo ago
    You probably don’t know how industrial computing works. Toolchains absolutely need to be maintained with some degree of longevity. The whole world doesn’t march to your consumer-user beat. Sometimes it functions at industrial-user tempo’s, too ..
yjftsjthsd-h 6mo ago
> your toolchain will not be downloadable. Why not? Debian has a fantastic track record of providing old versions, for instance here's the build tools from Debian 2.0 from 1998: https://mirrors.accretive-networks.net/debian-archive/debian/dists/hamm/main/binary-i386/devel/ https://mirrors.accretive-networks.net/debian-archive/debian...

PunchyHamster 6mo ago

> Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go. Just baking in build ID and commit is enough. What you think reproducible builds add ? > Please don’t make bold claims about ‘no reason and little benefit’ while demonstrating ignorance of this hard fact: reproducible builds should have been the norm, in computing, from the get-go. So far not a single person in the thread gave me concrete example (as in existing project, existing problem, no other solution can solve it). Just claiming it's better based on their feelings. Come on, be the first one.

MomsAVoxell 6mo ago
I already gave you an example, you dismissed it because you know better, but it is clear that you haven’t thought this through from the perspective of systems designers who have to deploy a base OS, with expected lifetimes of years, across a large fleet of devices. Think industrial applications, such as rail and heavy industry transportation. We use reproducible builds here as part of a wider safety-critical protocol which guarantees that what we are running is what we expect to run - nothing more, nothing less. Reproducible builds are certifiable. They can be relied on in environments where certification costs millions and takes years. Think outside your consumer box for a minute.