3 ms·
I think this is a really nice and important project, and at a cursory glance the design looks sane from a crypto perspective. But I question the basic UX design
by tkfu 5y ago
I think this is a really nice and important project, and at a cursory glance the design looks sane from a crypto perspective. But I question the basic UX design.
The attestation system seems like it's reproducing one of GPG's UX problems: you have these categories of attestation, and it's seemingly pretty sane as long as everyone uses the attestations right (and there are enough players in the ecosystem doing the work of attesting). GPG's trust levels have the same idea, but in reality people often just pull keys from some public keyserver and then assign them Full trust.
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.
Finally, although I in-theory admire the goal of allowing the user to define their own policy about trusting updates (defining how many attestations of which types are required/sufficient), my experience in software update systems tells me that real people absolutely won't do this. What will happen, if Gossamer sees good adoption, is that (1) there will be a standard trust config that gets distributed and reproduced, (2) everyone will use that config, and (3) it will be very permissive, because users don't want updates to be delayed/denied. 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.
- CiPHPerCoder 5y ago>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 agoThis 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...