4 ms·

Why, OpenWRT firmware and packages are both signed, of course. You can manually and independently check the image signature before flashing an update. The buil

by nine_k 1y ago

Why, OpenWRT firmware and packages are both signed, of course. You can manually and independently check the image signature before flashing an update. The build infrastructure is, of course, a juicy target: infect the artifact after building but before signing, and pwn millions of boxes before this is detected. This is why bit-perfect reproducible builds are so important. OpenWRT in particular have that: https://openwrt.org/docs/guide-developer/security#reproducible_builds https://openwrt.org/docs/guide-developer/security#reproducib...

tetha 1y ago
Bit-Reproducible infrastructure could also result in some of the wildest build distribution architectures if you think about it. You could publish sources and have people register like in APT mirrors to provide builds, and at the end of the day, the build from the largest bit-equal group is published. I do see the Tor-Issue - a botnet or a well-supplied malicious actor could just flood it. And if you flip it - if you'd need agreement about the build output, it could also be poisoned with enough nodes to prevent releases for a critical security issue. I agree, I don't solve all supply chain issues in one comment :) But that in turn could be helped with reputation. Maybe a node needs to supply 6 months of perfect builds - for testing as well - to become eligible. Which would be defeated by patience, but what isn't? It'd just have to be more annoying to breach the distributed build infrastructure than to plant a malicious developer. This combination of reproducible, deterministic builds, tests across a number of probably-trustworthy sources is quite interesting, as it allows very heavy decentralization. I could just run an old laptop or two here to support. And then come compromise hundreds of these all across the world.
- smt88 1y ago
  The distribution system you're describing exists and has been in use for decades. You just distribute the build using bittorrent.
  - cluckindan 1y ago
    And if someone invests in having >90% of the peers offer a malicious file and serve DHTs matching that file?
    - smt88 1y ago
      Torrent files are hashed, so it's exactly the same risk profile as the comment I was referring to. But generally hashing algorithms are collision-proof enough that what you're describing is basically impossible (requiring many years of compute time).
      - pabs3 1y ago
        IIRC BitTorrent still uses SHA-1, which is becoming more problematic.
        vhcr 1y ago
        BitTorrent v2 uses SHA-256, but in any case SHA-1 is still second-preimage resistant. And the BitTorrent piece hashes are included in the .torrent file, so you would need to find a double collision.
- charcircuit 1y ago
  >It'd just have to be more annoying to breach the distributed build infrastructure than to plant a malicious developer. It really wouldn't. You don't even need a powerful build server since you can mirror whatever someone else built. You can also buy / hack nodes of existing trusted people.
- HumanOstrich 1y ago
  Sounds overly complex and completely unnecessary, like some kind of blockchain/defi scheme shoehorned onto distributed builds.
- nunez 1y ago
  > Try building some common pieces of software in a network isolated environment and you will likely be surprised at how poorly it goes. I have yet to experience a straight shot install or build of anything in an air gapped environment. Always need to hack things to make it work.
- pabs3 1y ago
  Reproducible isn't quite enough, you also need bootstrap from almost-zero binaries. https://bootstrappable.org/ https://bootstrappable.org/
contravariant 1y ago
This exchange is somewhat hilarious. Oh how on earth do we keep things safe and secure if everyone can see the code and verify what it does! Who would keep us safe if we turn our backs to unverifiable, unvetted, unprofitable security fixes, by for-profit companies!
- fc417fc802 1y ago
  > how on earth do we keep things safe and secure if everyone can see the code and verify what it does! That's not always the silver bullet you seem to think it is. Have you ever tried to build something like Chromium, Firefox, or LLVM yourself? It's not realistic to do that on a mid tier let alone low end device. Even when you go to the trouble of getting a local build set up, more often than not the build system immediately attempts to download opaque binary blobs of uncertain provenance. Try building some common pieces of software in a network isolated environment and you will likely be surprised at how poorly it goes. If projects actually took this stuff seriously then you'd be able to bootstrap from a sectorlisp and pure human readable source code without any binary blobs or network access involved. Instead we have the abomination that is npm.
  - pabs3 1y ago
    Debian manages to build Chromium, Firefox, and LLVM on servers of multiple architectures, including quite slow riscv64 machines, without any network access to the builds for any architecture. https://buildd.debian.org/status/package.php?p=firefox-esr https://buildd.debian.org/status/package.php?p=firefox-esr See Bootstrappable Builds for starting from almost nothing, so far only GNU Guix and StageX have worked out how to start from the BB work to get a full distro. Should be fairly trivial for other distros too if they cared. https://bootstrappable.org/ https://bootstrappable.org/ https://guix.gnu.org/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ https://guix.gnu.org/blog/2023/the-full-source-bootstrap-bui... https://stagex.tools/ https://stagex.tools/
  - Etheryte 1y ago
    For context, I once found a bug in Chromium and fixed it, the initial build took a few days on and off on my development laptop that was pretty beefy for the time. I say on and off because I had to interrupt the build if I wanted to do anything else computationally taxing. They have incremental builds and caches all properly set up so you can just continue where you left off after the fact. After the initial build it's pretty fast, 5 minutes or so per build for me. On a low end device you're easily looking at a build time of a week or more if you're starting from scratch.
elAhmo 1y ago
> You can manually and independently check the image signature before flashing an update. Of course you can. You can also read the ToS before clicking accept, but who does that?
- baobun 1y ago
  I'm sure there are dozens of us.
  - DANmode 1y ago
    Ever since that one game with the soul-surrendering clause in the EULA, I read it all now, heh.
- antonvs 1y ago
  People who don't want to find themselves inadvertently participating in a botnet.

by nine_k 1y ago

tetha 1y ago

Bit-Reproducible infrastructure could also result in some of the wildest build distribution architectures if you think about it. You could publish sources and have people register like in APT mirrors to provide builds, and at the end of the day, the build from the largest bit-equal group is published. I do see the Tor-Issue - a botnet or a well-supplied malicious actor could just flood it. And if you flip it - if you'd need agreement about the build output, it could also be poisoned with enough nodes to prevent releases for a critical security issue. I agree, I don't solve all supply chain issues in one comment :) But that in turn could be helped with reputation. Maybe a node needs to supply 6 months of perfect builds - for testing as well - to become eligible. Which would be defeated by patience, but what isn't? It'd just have to be more annoying to breach the distributed build infrastructure than to plant a malicious developer. This combination of reproducible, deterministic builds, tests across a number of probably-trustworthy sources is quite interesting, as it allows very heavy decentralization. I could just run an old laptop or two here to support. And then come compromise hundreds of these all across the world.

smt88 1y ago
The distribution system you're describing exists and has been in use for decades. You just distribute the build using bittorrent.
- cluckindan 1y ago
  And if someone invests in having >90% of the peers offer a malicious file and serve DHTs matching that file?
  - smt88 1y ago
    Torrent files are hashed, so it's exactly the same risk profile as the comment I was referring to. But generally hashing algorithms are collision-proof enough that what you're describing is basically impossible (requiring many years of compute time).
    - pabs3 1y ago
      IIRC BitTorrent still uses SHA-1, which is becoming more problematic.
      - vhcr 1y ago
        BitTorrent v2 uses SHA-256, but in any case SHA-1 is still second-preimage resistant. And the BitTorrent piece hashes are included in the .torrent file, so you would need to find a double collision.
charcircuit 1y ago
>It'd just have to be more annoying to breach the distributed build infrastructure than to plant a malicious developer. It really wouldn't. You don't even need a powerful build server since you can mirror whatever someone else built. You can also buy / hack nodes of existing trusted people.
HumanOstrich 1y ago
Sounds overly complex and completely unnecessary, like some kind of blockchain/defi scheme shoehorned onto distributed builds.
nunez 1y ago
> Try building some common pieces of software in a network isolated environment and you will likely be surprised at how poorly it goes. I have yet to experience a straight shot install or build of anything in an air gapped environment. Always need to hack things to make it work.
pabs3 1y ago
Reproducible isn't quite enough, you also need bootstrap from almost-zero binaries. https://bootstrappable.org/ https://bootstrappable.org/

contravariant 1y ago

This exchange is somewhat hilarious. Oh how on earth do we keep things safe and secure if everyone can see the code and verify what it does! Who would keep us safe if we turn our backs to unverifiable, unvetted, unprofitable security fixes, by for-profit companies!

fc417fc802 1y ago
> how on earth do we keep things safe and secure if everyone can see the code and verify what it does! That's not always the silver bullet you seem to think it is. Have you ever tried to build something like Chromium, Firefox, or LLVM yourself? It's not realistic to do that on a mid tier let alone low end device. Even when you go to the trouble of getting a local build set up, more often than not the build system immediately attempts to download opaque binary blobs of uncertain provenance. Try building some common pieces of software in a network isolated environment and you will likely be surprised at how poorly it goes. If projects actually took this stuff seriously then you'd be able to bootstrap from a sectorlisp and pure human readable source code without any binary blobs or network access involved. Instead we have the abomination that is npm.
- pabs3 1y ago
  Debian manages to build Chromium, Firefox, and LLVM on servers of multiple architectures, including quite slow riscv64 machines, without any network access to the builds for any architecture. https://buildd.debian.org/status/package.php?p=firefox-esr https://buildd.debian.org/status/package.php?p=firefox-esr See Bootstrappable Builds for starting from almost nothing, so far only GNU Guix and StageX have worked out how to start from the BB work to get a full distro. Should be fairly trivial for other distros too if they cared. https://bootstrappable.org/ https://bootstrappable.org/ https://guix.gnu.org/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ https://guix.gnu.org/blog/2023/the-full-source-bootstrap-bui... https://stagex.tools/ https://stagex.tools/
- Etheryte 1y ago
  For context, I once found a bug in Chromium and fixed it, the initial build took a few days on and off on my development laptop that was pretty beefy for the time. I say on and off because I had to interrupt the build if I wanted to do anything else computationally taxing. They have incremental builds and caches all properly set up so you can just continue where you left off after the fact. After the initial build it's pretty fast, 5 minutes or so per build for me. On a low end device you're easily looking at a build time of a week or more if you're starting from scratch.

elAhmo 1y ago

> You can manually and independently check the image signature before flashing an update. Of course you can. You can also read the ToS before clicking accept, but who does that?

baobun 1y ago
I'm sure there are dozens of us.
- DANmode 1y ago
  Ever since that one game with the soul-surrendering clause in the EULA, I read it all now, heh.
antonvs 1y ago
People who don't want to find themselves inadvertently participating in a botnet.