3 ms·

This comment is baffling. Reproducibility in general is a key part of all sciences. Practically speaking, it’s important from a security perspective. If you c

by dartos 3y ago

This comment is baffling. Reproducibility in general is a key part of all sciences. Practically speaking, it’s important from a security perspective. If you can make a secure configuration of some system you’d want to be 100% certain you can reproduce that same configuration on some other system. Deep and provable reproducibility doesn’t matter too much for most web servers, unless security is a top priority.

Dylan16807 3y ago
Your science comparison is also baffling, to be honest. A typical "non-reproducible" compile meets the scientific standard of "reproducible". Imagine if recreating an experiment was expected to give you the same date points, in the same order, with the same timestamps. The two definitions of "reproducible" are worlds apart.
- dartos 3y ago
  What “scientific standard” are you talking about? I think if it was possible to configure the universe (time included) in the exact same way, save for a single variable, that would be the _only_ way science experiments would be done. We almost have the ability to do that with software, but we just don’t most of the time. That’s okay for many applications, but not all of them.
  - Dylan16807 3y ago
    The standard that real world experiments are held to to qualify as "reproduction". Your hypothetical is interesting but it's clearly a different standard from what we actually use.
Hackbraten 3y ago
Do you know an example for a security property that a reproducible build would be able to guarantee, and where pinning a dependency against a version identifier plus digest of the release tarball wouldn't accomplish the same thing?
- dartos 3y ago
  I think pinning a dependency against a version identifier and a digest of a tarball is a great way to ensure reproducibility. You’re controlling which dependency you’re using very specifically. Reproducibility like this protects against supply chain attacks. This may be a bit contrived, but It could prevent a malicious package maintainer from releasing a modified version of OpenSSL that you depend on without you noticing that change in your dependencies.

by dartos 3y ago

Dylan16807 3y ago

Your science comparison is also baffling, to be honest. A typical "non-reproducible" compile meets the scientific standard of "reproducible". Imagine if recreating an experiment was expected to give you the same date points, in the same order, with the same timestamps. The two definitions of "reproducible" are worlds apart.

dartos 3y ago
What “scientific standard” are you talking about? I think if it was possible to configure the universe (time included) in the exact same way, save for a single variable, that would be the _only_ way science experiments would be done. We almost have the ability to do that with software, but we just don’t most of the time. That’s okay for many applications, but not all of them.
- Dylan16807 3y ago
  The standard that real world experiments are held to to qualify as "reproduction". Your hypothetical is interesting but it's clearly a different standard from what we actually use.

Hackbraten 3y ago

Do you know an example for a security property that a reproducible build would be able to guarantee, and where pinning a dependency against a version identifier plus digest of the release tarball wouldn't accomplish the same thing?

dartos 3y ago
I think pinning a dependency against a version identifier and a digest of a tarball is a great way to ensure reproducibility. You’re controlling which dependency you’re using very specifically. Reproducibility like this protects against supply chain attacks. This may be a bit contrived, but It could prevent a malicious package maintainer from releasing a modified version of OpenSSL that you depend on without you noticing that change in your dependencies.