5 ms·

>I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the

>I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice. This probably should be made clearer, but: Reproducible builds are necessary for the security of any such system. It's outlined in earlier blog posts. Consequently, the inclusion of reproducible build verification is taken as a premise. > The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence. That's true, and should probably be tackled in a future blog post.

Foxboron 5y ago
>This probably should be made clearer, but: Reproducible builds are necessary for the security of any such system. It's outlined in earlier blog posts. >Consequently, the inclusion of reproducible build verification is taken as a premise. That is a bit funny. We have had issues making the PHP package reproducible on Arch Linux for years. And I believe upstream has rejected patches which embeds uname into built artifacts. I'm a bit unsure about the premise considering upstream doesn't seem interested solving this?
- CiPHPerCoder 5y ago
  This is about PHP code (i.e. written in the scripting language, PHP), not the PHP interpreter. Since it's a scripting language, your build artifacts will be one of: - .diff / .patch - .zip / .tar / .tar.gz - .phar (rarely) Of these, only the last (PHP Archives) is mildly persnickety for build reproducibility. But it's easily fixed: https://github.com/paragonie/sodium_compat/blob/08ab867bbb6ab3e2f295d57d7ac0e0024739105e/dist/Makefile#L36-L38 https://github.com/paragonie/sodium_compat/blob/08ab867bbb6a...

Foxboron 5y ago

>This probably should be made clearer, but: Reproducible builds are necessary for the security of any such system. It's outlined in earlier blog posts. >Consequently, the inclusion of reproducible build verification is taken as a premise. That is a bit funny. We have had issues making the PHP package reproducible on Arch Linux for years. And I believe upstream has rejected patches which embeds uname into built artifacts. I'm a bit unsure about the premise considering upstream doesn't seem interested solving this?

CiPHPerCoder 5y ago
This is about PHP code (i.e. written in the scripting language, PHP), not the PHP interpreter. Since it's a scripting language, your build artifacts will be one of: - .diff / .patch - .zip / .tar / .tar.gz - .phar (rarely) Of these, only the last (PHP Archives) is mildly persnickety for build reproducibility. But it's easily fixed: https://github.com/paragonie/sodium_compat/blob/08ab867bbb6ab3e2f295d57d7ac0e0024739105e/dist/Makefile#L36-L38 https://github.com/paragonie/sodium_compat/blob/08ab867bbb6a...