3 ms·

I'm not sure I understand this line of argument. A system where every user rebuilds all packages themselves, just to use the resulting file hashes to verify whe

I'm not sure I understand this line of argument. A system where every user rebuilds all packages themselves, just to use the resulting file hashes to verify whether they can trust an identical binary they already downloaded from the Internet, is obviously kind of goofy. Instead, I think the use case for reproducibility is allowing multiple trusted parties to independently build and generate signatures for the same binary. In GP's example, open source contributors could run their own builds independently (maybe on air-gapped machines) to produce multiple trustworthy signatures for the resulting binaries. F-Droid does this kind of thing today; you can get apps verified by both the original author and the F-Droid infrastructure. I think the main difference between that and your scheme is your scheme relies on whoever runs the CI/CD machines (Microsoft?) not tampering with them. But the underlying signature technology is probably still useful in a reproducible-builds world—assuming you don't break the reproducibility of the bottles by e.g. embedding the signatures into the binaries somehow.

woodruffw 3y ago
> Instead, I think the use case for reproducibility is allowing multiple trusted parties to independently build and generate signatures for the same binary. In GP's example, open source contributors could run their own builds independently (maybe on air-gapped machines) to produce multiple trustworthy signatures for the resulting binaries. F-Droid does this kind of thing today; you can get apps verified by both the original author and the F-Droid infrastructure. You can do this, but I don’t think it has much of a value (or security) proposition on its own. The ideal world here would be “reproducible signed builds + occasional independent rebuilds with gossiping,” but that is significantly harder to operationalize than just build signing or reproducibility.
- csande17 3y ago
  > You can do this, but I don’t think it has much of a value (or security) proposition on its own. The value prop is pretty straightforward in the open-source space: allowing clients to choose to only trust binaries signed by N independent actors. F-Droid achieves this today: if an application needs to be built/signed by both the original author and F-Droid to be considered valid, neither party can push a compromised binary on their own. ("Compromised" in the sense of "doesn't match the source code it claims to", which AFAICT is all you're targeting with this Homebrew scheme too.) GNU Guix is working on a similar scheme where the client can choose to only accept binaries built by K of N "substitute servers". And even today, they ship a one-click "challenge" command that rebuilds a bunch of binaries to report whether a substitute server is shipping something suspicious; users can then gossip about this via their favorite social media platform. I'd argue that both of these solutions create a lot more value than your scheme, where most of the people who would previously be able to tamper with the single, central instance of the build infrastructure are still able to do that without being detected.
  - woodruffw 3y ago
    > The value prop is pretty straightforward in the open-source space: allowing clients to choose to only trust binaries signed by N independent actors. That’s the gossiping part: unless you’re independently contacting each of those independent actors, you’re doing no more than 1-of-N. As I’ve said in other comments: “can” translates to “won’t” in cryptographic contexts. Gossip does not matter if it doesn’t have controls behind it. > where most of the people who would previously be able to tamper with the build infrastructure are still able to do that without being detected. Could you provide an example scenario? Assuming the people you’re referring to are Homebrew’s own maintainers, this is not true: tampering would require them to modify the workflow, which cascades to a change in claims, which in turn is detectable (and is compelled to be detectable, thanks to both a transparency log and how the underlying identity construction works).
    - csande17 3y ago
      > As I’ve said in other comments: “can” translates to “won’t” in cryptographic contexts. Gossip does not matter if it doesn’t have controls behind it. Yes, so you... code the client to check for the presence of multiple signatures (in the F-Droid case where the F-Droid service knows about the original author signature) or ship the URLs for two of the independent actors in the default configuration (in the GNU Guix case)? This does not seem like a hard problem. > Could you provide an example scenario? Whatever person or company runs the box that builds Homebrew packages tampers with that box. Maybe Microsoft gets a National Security Letter, or has a tenant isolation bug. Or I dunno, the last time I seriously worked with Homebrew they were running Jenkins on a Mac Mini in some random colo facility, and the maintainers definitely had root on that thing.
      - woodruffw 3y ago
        > code the client to check for the presence of multiple signatures (in the F-Droid case where the F-Droid service knows about the original author signature) This trusts the client for both parties, while also treating the client as a potentially malicious party. This puts you back at 1-of-N. > or ship the URLs for two of the independent actors in the default configuration (in the GNU Guix case) This gets very unreliable, very fast: independent verifiers go down, stop verifying, &c. Even extremely well capitalized companies struggle to run reliable timestamping and similar services; I don’t think it would be responsible to tie Homebrew’s availability to the accessibility of a small handful of external, bespoke hosted services. This is all to say: checking multiple points of trust without implicitly collapsing them into a single point of trust is, in fact, a pretty hard problem. Especially when you throw external unreliabilities into the mix. To the best of my knowledge, all Homebrew bottles are currently built on GitHub Actions; there hasn’t been a Jenkins box in a while. The entire point of this work is to bootstrap signatures on the latent identities that GitHub Actions provides, since doing so avoids nearly all of the normal logistical issues that pop up when doing codesigning. The point about tenant isolation is a good one.

woodruffw 3y ago

> Instead, I think the use case for reproducibility is allowing multiple trusted parties to independently build and generate signatures for the same binary. In GP's example, open source contributors could run their own builds independently (maybe on air-gapped machines) to produce multiple trustworthy signatures for the resulting binaries. F-Droid does this kind of thing today; you can get apps verified by both the original author and the F-Droid infrastructure. You can do this, but I don’t think it has much of a value (or security) proposition on its own. The ideal world here would be “reproducible signed builds + occasional independent rebuilds with gossiping,” but that is significantly harder to operationalize than just build signing or reproducibility.

csande17 3y ago
> You can do this, but I don’t think it has much of a value (or security) proposition on its own. The value prop is pretty straightforward in the open-source space: allowing clients to choose to only trust binaries signed by N independent actors. F-Droid achieves this today: if an application needs to be built/signed by both the original author and F-Droid to be considered valid, neither party can push a compromised binary on their own. ("Compromised" in the sense of "doesn't match the source code it claims to", which AFAICT is all you're targeting with this Homebrew scheme too.) GNU Guix is working on a similar scheme where the client can choose to only accept binaries built by K of N "substitute servers". And even today, they ship a one-click "challenge" command that rebuilds a bunch of binaries to report whether a substitute server is shipping something suspicious; users can then gossip about this via their favorite social media platform. I'd argue that both of these solutions create a lot more value than your scheme, where most of the people who would previously be able to tamper with the single, central instance of the build infrastructure are still able to do that without being detected.
- woodruffw 3y ago
  > The value prop is pretty straightforward in the open-source space: allowing clients to choose to only trust binaries signed by N independent actors. That’s the gossiping part: unless you’re independently contacting each of those independent actors, you’re doing no more than 1-of-N. As I’ve said in other comments: “can” translates to “won’t” in cryptographic contexts. Gossip does not matter if it doesn’t have controls behind it. > where most of the people who would previously be able to tamper with the build infrastructure are still able to do that without being detected. Could you provide an example scenario? Assuming the people you’re referring to are Homebrew’s own maintainers, this is not true: tampering would require them to modify the workflow, which cascades to a change in claims, which in turn is detectable (and is compelled to be detectable, thanks to both a transparency log and how the underlying identity construction works).
  - csande17 3y ago
    > As I’ve said in other comments: “can” translates to “won’t” in cryptographic contexts. Gossip does not matter if it doesn’t have controls behind it. Yes, so you... code the client to check for the presence of multiple signatures (in the F-Droid case where the F-Droid service knows about the original author signature) or ship the URLs for two of the independent actors in the default configuration (in the GNU Guix case)? This does not seem like a hard problem. > Could you provide an example scenario? Whatever person or company runs the box that builds Homebrew packages tampers with that box. Maybe Microsoft gets a National Security Letter, or has a tenant isolation bug. Or I dunno, the last time I seriously worked with Homebrew they were running Jenkins on a Mac Mini in some random colo facility, and the maintainers definitely had root on that thing.
    - woodruffw 3y ago
      > code the client to check for the presence of multiple signatures (in the F-Droid case where the F-Droid service knows about the original author signature) This trusts the client for both parties, while also treating the client as a potentially malicious party. This puts you back at 1-of-N. > or ship the URLs for two of the independent actors in the default configuration (in the GNU Guix case) This gets very unreliable, very fast: independent verifiers go down, stop verifying, &c. Even extremely well capitalized companies struggle to run reliable timestamping and similar services; I don’t think it would be responsible to tie Homebrew’s availability to the accessibility of a small handful of external, bespoke hosted services. This is all to say: checking multiple points of trust without implicitly collapsing them into a single point of trust is, in fact, a pretty hard problem. Especially when you throw external unreliabilities into the mix. To the best of my knowledge, all Homebrew bottles are currently built on GitHub Actions; there hasn’t been a Jenkins box in a while. The entire point of this work is to bootstrap signatures on the latent identities that GitHub Actions provides, since doing so avoids nearly all of the normal logistical issues that pop up when doing codesigning. The point about tenant isolation is a good one.