4 ms·

> 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 s

> 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.
    - csande17 3y ago
      > 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. Is this just the "well how do you get a trustworthy copy of the software you rely on to tell you whether copies of software are trustworthy" question? Since obviously once you have that software, it can download as many different signatures as it wants from the F-Droid service and validate them locally without needing to trust the F-Droid service; that is the point of digital signatures. That seems like it'd be an issue for your thing as well, since the two available ways to install Homebrew itself are curl|bash and downloading/running an installer from a GitHub Releases page. Then again, if the security model here revolves around axiomatically trusting Microsoft (and also believing Microsoft is the only entity in the world capable of running CI/CD infrastructure), I guess that's not an issue.

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.
  - csande17 3y ago
    > 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. Is this just the "well how do you get a trustworthy copy of the software you rely on to tell you whether copies of software are trustworthy" question? Since obviously once you have that software, it can download as many different signatures as it wants from the F-Droid service and validate them locally without needing to trust the F-Droid service; that is the point of digital signatures. That seems like it'd be an issue for your thing as well, since the two available ways to install Homebrew itself are curl|bash and downloading/running an installer from a GitHub Releases page. Then again, if the security model here revolves around axiomatically trusting Microsoft (and also believing Microsoft is the only entity in the world capable of running CI/CD infrastructure), I guess that's not an issue.