24 ms·

Curious bout your use case for building all software from source, is it because you're worried about the supply chain since nixpkgs builds don't have reproducib

Curious bout your use case for building all software from source, is it because you're worried about the supply chain since nixpkgs builds don't have reproducibility guarantee?

craftkiller 3mo ago
I was already building the vast majority of it from source because I enable CPU optimizations for the specific microarchitecture in the machine (nixpkgs.hostPlatform.gcc.arch and nixpkgs.hostPlatform.gcc.tune), so once I learned about the risk of supply chain attack on the nix cache, disabling it entirely was a pretty small change. So far, I'd say the biggest negative (aside from the build times that I was already experiencing due to the optimizations) is that GNU savannah will temporarily IP ban you when you download too much from them. For example, building the grub that is used for the ISOs downloads like 70+ patches from GNU Savannah which frequently triggers the IP ban.
- BobbyTables2 3mo ago
  I assume you like it more than Gentoo? Building from stage1 with customized CFLAGS was all the rage then…
- chickensong 3mo ago
  > the risk of supply chain attack on the nix cache Do you not trust hydra, the infra hosts, the people, all of it? What could be done to improve the cache's posture?
  - craftkiller 3mo ago
    One suggestion for improving the cache's posture: Give each dedicated builder machine a TPM. On each builder, generate a TPM-backed signing key. Only use those TPM-backed keys for signing packages that end up in the cache. That way we'd ensure that signed packages _must_ have been built on the dedicated build machines (due to the TPM) rather than potentially uploaded from a compromised developer machine using a compromised signing key. It seems the current situation is there is a single signing key that has been in use since 2015 which implies that key is not tied to specific hardware and therefore could be leaked/exfiltrated/copied: https://github.com/NixOS/rfcs/pull/149/files#diff-ac4cc42774897d03700afa5e998e676b494ee685860d9ee08dfa2b14d7566273R22 https://github.com/NixOS/rfcs/pull/149/files#diff-ac4cc42774...
    - chickensong 3mo ago
      A reasonable suggestion, for any code signing system really. We need all the help we can get these days. Have you measured the gains from your source-based approach? I was into Gentoo for tuning a long time ago when hardware wasn't as powerful, but I hadn't considered optimizing at that level with nix.

Curious bout your use case for building all software from source, is it because you're worried about the supply chain since nixpkgs builds don't have reproducibility guarantee?

craftkiller 3mo ago

I was already building the vast majority of it from source because I enable CPU optimizations for the specific microarchitecture in the machine (nixpkgs.hostPlatform.gcc.arch and nixpkgs.hostPlatform.gcc.tune), so once I learned about the risk of supply chain attack on the nix cache, disabling it entirely was a pretty small change. So far, I'd say the biggest negative (aside from the build times that I was already experiencing due to the optimizations) is that GNU savannah will temporarily IP ban you when you download too much from them. For example, building the grub that is used for the ISOs downloads like 70+ patches from GNU Savannah which frequently triggers the IP ban.

BobbyTables2 3mo ago
I assume you like it more than Gentoo? Building from stage1 with customized CFLAGS was all the rage then…
chickensong 3mo ago
> the risk of supply chain attack on the nix cache Do you not trust hydra, the infra hosts, the people, all of it? What could be done to improve the cache's posture?
- craftkiller 3mo ago
  One suggestion for improving the cache's posture: Give each dedicated builder machine a TPM. On each builder, generate a TPM-backed signing key. Only use those TPM-backed keys for signing packages that end up in the cache. That way we'd ensure that signed packages _must_ have been built on the dedicated build machines (due to the TPM) rather than potentially uploaded from a compromised developer machine using a compromised signing key. It seems the current situation is there is a single signing key that has been in use since 2015 which implies that key is not tied to specific hardware and therefore could be leaked/exfiltrated/copied: https://github.com/NixOS/rfcs/pull/149/files#diff-ac4cc42774897d03700afa5e998e676b494ee685860d9ee08dfa2b14d7566273R22 https://github.com/NixOS/rfcs/pull/149/files#diff-ac4cc42774...
  - chickensong 3mo ago
    A reasonable suggestion, for any code signing system really. We need all the help we can get these days. Have you measured the gains from your source-based approach? I was into Gentoo for tuning a long time ago when hardware wasn't as powerful, but I hadn't considered optimizing at that level with nix.