4 ms·

Signatures are not technically pointless, they mean you only have to trust the developer - not the mirror operators. Reproducibility is technically pointless,

by taviso 5y ago

Signatures are not technically pointless, they mean you only have to trust the developer - not the mirror operators. Reproducibility is technically pointless, because you still have to trust the developer, and they can still add backdoors.

dane-pgp 5y ago
Reproducibility means you don't have to worry that the developer might have a backdoored toolchain (which also means that they can't pretend that a malicious toolchain added the malicious code without their knowledge). A talented developer might still be able to create a bugdoor which gets past code review, but that takes more effort and skill than just putting the malicious code into a local checkout and then saying "How did that get there?".
- taviso 5y ago
  Every major vendor has vulnerabilities introduced all the time, by accident! No talent is necessary to introduce a bugdoor, just malice. You can already verify that a toolchain wasn't backdoored today, reproducible builds aren't necessary for that.
  - wildfire 5y ago
    > You can already verify that a > toolchain wasn't backdoored ) > today How, exactly? If we both compiled hello.c (a prototypical hello world program), and exchanged binaries; how would you verify my build wasn't malicious?
    - taviso 5y ago
      I think the workflow you're proposing is to take some trusted source code, then compile it to make a trusted binary. Now compare the trusted binary to the untrusted binary provided by the vendor - If they're the same - then it must have been made by an uncompromised toolchain. That does require reproducible builds, but here is how to do it without reproducible builds: Take the trusted source code, then compile it to make a trusted binary. Now put the untrusted binary in the trash, cause you already have a trusted binary :)
      - squiggleblaz 5y ago
        How about if the system will only run signed builds? Couldn't you use it to verify the signed build by stripping the signature and comparing them?
sayrer 5y ago
Is it technically pointless if you view it as a check on your own build, rather than a check on the work of others? You are obviously familiar with Bazel/Blaze etc. Wouldn't reproducibility be necessary for those systems to work well most of the time? I can think of exceptions (like PGO), but it seems useful to produce at least some binaries this way. Also covered in this: https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html https://security.googleblog.com/2021/06/introducing-slsa-end...
- taviso 5y ago
  > Is it technically pointless if you view it as a check on your own build, rather than a check on the work of others? That depends, I think it's difficult and mostly still pointless. I wrote about this a bit in the blog post I linked to. It's a big trade off, for questionable benefit. > Wouldn't reproducibility be necessary for those systems to work well most of the time? Yes, there are definitely some good non-security reasons to want deterministic builds. My gripe is only with the security arguments, like claims it can reduce threats of violence against developers (!?!).
franga2000 5y ago
> Reproducibility is technically pointless, because you still have to trust the developer, and they can still add backdoors. Builder != developer - and with reproducible builds, you no longer beed to trust the builder. CI is commonly used for the final distributable builds and you can't always trust the CI server. Even if you do, many rely on third party thingd like docker images - if the base build image gets compromised, code could trivially be injected into builds running on it and without reproducible builds, that would not be detectable. As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with. As a bonus, distro maintainers who have their own CI can also check against my hashes to verify their build systems aren't doing something fishy (malicious or otherwise).
- taviso 5y ago
  > As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with. That makes sense! However, this is not a good argument for reproducible builds, because you can already do that today. You already have to build a trusted binary locally for testing right? You're dreaming of being able to compare that against the untrusted binary so that you can make sure it's a trusted binary too - but you already have a trusted binary! Okay - but it's a hassle, you don't want to have to do that, right? Too bad - reproducible builds only work if someone reproduces them. You're still going to have to replicate it somewhere you trust, so you gained practically nothing.
  - eru 5y ago
    With the reproducible build, you can start using the untrusted binary while you are still building your trusted one. You can also have ten people on the internet verify the untrusted binary. With signatures, adding more people doesn't help.
    - taviso 5y ago
      > With the reproducible build, you can start using the untrusted binary while you are still building your trusted one. That's not how it works, you have to reproduce it before it becomes trusted. > You can also have ten people on the internet verify the untrusted binary. Sure, then we have to build a complex consensus system that introduces a bunch of unsolved problems. My opinion is that this just isn't worth it, there is practically nothing to gain and it's really really hard.

by taviso 5y ago

dane-pgp 5y ago

Reproducibility means you don't have to worry that the developer might have a backdoored toolchain (which also means that they can't pretend that a malicious toolchain added the malicious code without their knowledge). A talented developer might still be able to create a bugdoor which gets past code review, but that takes more effort and skill than just putting the malicious code into a local checkout and then saying "How did that get there?".

taviso 5y ago
Every major vendor has vulnerabilities introduced all the time, by accident! No talent is necessary to introduce a bugdoor, just malice. You can already verify that a toolchain wasn't backdoored today, reproducible builds aren't necessary for that.
- wildfire 5y ago
  > You can already verify that a > toolchain wasn't backdoored ) > today How, exactly? If we both compiled hello.c (a prototypical hello world program), and exchanged binaries; how would you verify my build wasn't malicious?
  - taviso 5y ago
    I think the workflow you're proposing is to take some trusted source code, then compile it to make a trusted binary. Now compare the trusted binary to the untrusted binary provided by the vendor - If they're the same - then it must have been made by an uncompromised toolchain. That does require reproducible builds, but here is how to do it without reproducible builds: Take the trusted source code, then compile it to make a trusted binary. Now put the untrusted binary in the trash, cause you already have a trusted binary :)
    - squiggleblaz 5y ago
      How about if the system will only run signed builds? Couldn't you use it to verify the signed build by stripping the signature and comparing them?

sayrer 5y ago

Is it technically pointless if you view it as a check on your own build, rather than a check on the work of others? You are obviously familiar with Bazel/Blaze etc. Wouldn't reproducibility be necessary for those systems to work well most of the time? I can think of exceptions (like PGO), but it seems useful to produce at least some binaries this way. Also covered in this: https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html https://security.googleblog.com/2021/06/introducing-slsa-end...

taviso 5y ago
> Is it technically pointless if you view it as a check on your own build, rather than a check on the work of others? That depends, I think it's difficult and mostly still pointless. I wrote about this a bit in the blog post I linked to. It's a big trade off, for questionable benefit. > Wouldn't reproducibility be necessary for those systems to work well most of the time? Yes, there are definitely some good non-security reasons to want deterministic builds. My gripe is only with the security arguments, like claims it can reduce threats of violence against developers (!?!).

franga2000 5y ago

> Reproducibility is technically pointless, because you still have to trust the developer, and they can still add backdoors. Builder != developer - and with reproducible builds, you no longer beed to trust the builder. CI is commonly used for the final distributable builds and you can't always trust the CI server. Even if you do, many rely on third party thingd like docker images - if the base build image gets compromised, code could trivially be injected into builds running on it and without reproducible builds, that would not be detectable. As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with. As a bonus, distro maintainers who have their own CI can also check against my hashes to verify their build systems aren't doing something fishy (malicious or otherwise).

taviso 5y ago
> As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with. That makes sense! However, this is not a good argument for reproducible builds, because you can already do that today. You already have to build a trusted binary locally for testing right? You're dreaming of being able to compare that against the untrusted binary so that you can make sure it's a trusted binary too - but you already have a trusted binary! Okay - but it's a hassle, you don't want to have to do that, right? Too bad - reproducible builds only work if someone reproduces them. You're still going to have to replicate it somewhere you trust, so you gained practically nothing.
- eru 5y ago
  With the reproducible build, you can start using the untrusted binary while you are still building your trusted one. You can also have ten people on the internet verify the untrusted binary. With signatures, adding more people doesn't help.
  - taviso 5y ago
    > With the reproducible build, you can start using the untrusted binary while you are still building your trusted one. That's not how it works, you have to reproduce it before it becomes trusted. > You can also have ten people on the internet verify the untrusted binary. Sure, then we have to build a complex consensus system that introduces a bunch of unsolved problems. My opinion is that this just isn't worth it, there is practically nothing to gain and it's really really hard.