3 ms·

Reproducible builds are one of three components necessary to have a secure code delivery system: https://defuse.ca/triangle-of-secure-code-delivery.htm https://

Reproducible builds are one of three components necessary to have a secure code delivery system: https://defuse.ca/triangle-of-secure-code-delivery.htm https://defuse.ca/triangle-of-secure-code-delivery.htm That Red Hat and Ubuntu aren't interested in delivering trustworthy software means you shouldn't trust them.

nickpsecurity 10y ago
This isnt accurate. High-assurance established the requirements by mid-1980's in TCSEC. Wheeler, inventor of reproducible builds, also has the best page for SCM security which describes such methods. Here's what it takes: 1. Build system that only developers can access, review of their submissions, a trusted compiler that turns them into binary, and then signs both binary and source. 2. That source or binary is distributed with its signature over any medium. Add TLS for defense in depth if you want. 3. User checks their against signature to determine if trustworthy. Source they compile themselves if worried about substitution. Now, maybe that repo is compromised. Decentralized checking approach says let them pull source signatures from many other repos that are all building from same source on diverse platforms and such. Go with what (strongest) majority says while reporting inconsistencies. Compile source yourself for sure. Now, the user might not trust the compiler. If repo is trustworthy, then compiler source should be too with bootstrapping done by experts in diverse ways. However, if one really wants compiler verification, they have to both understand the source and turn it to machine code themselved for at least first run. Ive shown here before how to do that increnentally. Looking at above, it boils down to a secure, signed distribution of source code for compiler and app. That's all you need. Reproducible builds can have benefits but arent good enough to stop subversion that will mostly be 0-days in source or attacks on endpoint. They're not necessary to stop MITM attacks given signed distribution of source handles that. They're not necessary to bootstrap major compilers as distros come with scripting or executable tools by default that can be trusted to do initial source. If you cant trust them, your distro should already be considered subverted. There you go. That's about all of it if we're not talking about eliminating code injection from or formal verification of these components. So, strongest repo security they could build should be FOSS's plan. Repo appliances on microkernels or stripped OpenBSD with append-only storage. Signatures (incl key storage) in HSM's or carefully-done embedded boards. Transport node for Internet connection on its own machine with mediation against device-level attacks on host. Old shit. Would work if they just put work into it. Oh yeah: paper backups hidden in various places. As fail-safe. :)

nickpsecurity 10y ago

This isnt accurate. High-assurance established the requirements by mid-1980's in TCSEC. Wheeler, inventor of reproducible builds, also has the best page for SCM security which describes such methods. Here's what it takes: 1. Build system that only developers can access, review of their submissions, a trusted compiler that turns them into binary, and then signs both binary and source. 2. That source or binary is distributed with its signature over any medium. Add TLS for defense in depth if you want. 3. User checks their against signature to determine if trustworthy. Source they compile themselves if worried about substitution. Now, maybe that repo is compromised. Decentralized checking approach says let them pull source signatures from many other repos that are all building from same source on diverse platforms and such. Go with what (strongest) majority says while reporting inconsistencies. Compile source yourself for sure. Now, the user might not trust the compiler. If repo is trustworthy, then compiler source should be too with bootstrapping done by experts in diverse ways. However, if one really wants compiler verification, they have to both understand the source and turn it to machine code themselved for at least first run. Ive shown here before how to do that increnentally. Looking at above, it boils down to a secure, signed distribution of source code for compiler and app. That's all you need. Reproducible builds can have benefits but arent good enough to stop subversion that will mostly be 0-days in source or attacks on endpoint. They're not necessary to stop MITM attacks given signed distribution of source handles that. They're not necessary to bootstrap major compilers as distros come with scripting or executable tools by default that can be trusted to do initial source. If you cant trust them, your distro should already be considered subverted. There you go. That's about all of it if we're not talking about eliminating code injection from or formal verification of these components. So, strongest repo security they could build should be FOSS's plan. Repo appliances on microkernels or stripped OpenBSD with append-only storage. Signatures (incl key storage) in HSM's or carefully-done embedded boards. Transport node for Internet connection on its own machine with mediation against device-level attacks on host. Old shit. Would work if they just put work into it. Oh yeah: paper backups hidden in various places. As fail-safe. :)