3 ms·

I'm slightly confused. How does relying on multiple third-party moving parts improve your supply chain ? A quick glance through the blog post shows, for exampl

I'm slightly confused. How does relying on multiple third-party moving parts improve your supply chain ? A quick glance through the blog post shows, for example: - A reliance on github runners to compile (rather than in-house) - A reliance on a third-party signing service (rather than own CA) I'm probably missing something obvious, but I just don't get how this helps ? In my mind it seems to add extra places for security issues to be introduced ?

orthecreedence 5y ago
> I'm probably missing something obvious No, you're not. The article is actually just braindead enough to suggest that shipping your build and cryptographic signing steps to third-parties is more secure. This isn't just wrong, it's almost criminally devious (and blatantly in service to the ever-growing surveillance state).
- hulitu 5y ago
  You are right except with using the adverb "braindead". I really think they are doing it on purpose. The aim is that the netizen gets a licence for everything he has: car, house, devices. The "Companies" control every device and the life of the netizen . And this security theater is just there that the netizen does not interfere with their data collection.
woodruffw 5y ago
> I'm probably missing something obvious, but I just don't get how this helps ? In my mind it seems to add extra places for security issues to be introduced ? The entire point is integrity and a fully auditable chain of actions. Quoting the post: > Performing these steps guarantees to the consumer that the binary was produced in the trusted builder at a given commit hash attested to in the provenance. They can trust that the information in the provenance was non-forgeable, allowing them to trust the build “recipe” and trace their artifact verifiably back to the source. This provides a broad swath of integrity guarantees that are otherwise extremely difficult to assert for builds that you don't control: you know exactly which machine ran the build, that it wasn't tampered with or silently replaced, and that a particular OpenID identity has signed for the build. You can verify all of these steps publicly without having to keep a trusted keychain, and without having to trust that the signing/publishing parties securely store long-lived signing keys (since everything is ephemeral). The critical thing to note here is that GitHub Actions is just the platform here. The techniques are all open, and sigstore is an open specification with an open implementation. You can do it all in-house if you'd like, or ignore it completely if everything you consume is already in-house.
hulitu 5y ago
It really helps with filling checklists. Every Google ( ecosystem) app is an RCE capable app. If they really want to improve security they shall give network access only to apps which really need it.
skybrian 5y ago
This depends on your trust model. If you don't know a project's maintainers and you trust GitHub then this model lets you verify the maintainers' work by looking at the source, while not having to build it yourself. That's a big assumption, but the idea is likely that there are lots of projects and lots of maintainers, too many to vet them all. (But who will vet all that source?) Ideally, though, someone would do the builds independently and then compare the checksums.
- traceroute66 5y ago
  > If you don't know a project's maintainers and you trust GitHub then this model lets you verify the maintainers' work by looking at the source, I'm not sure I follow. GitHub is basically a glorified git repo. So I still have to trust the people who do the git push, no ? If so, then I fail to see how you can do better than git PGP signing ? git PGP signing enforces integrity at the basic level, so you've got a chain of signed git commits. I don't understand the "trust" in saying, "well, we've got too many maintainers to track PGP keys, so instead anybody can commit and we'll abstract the trust away to the build-level where we trust Github to build it without tampering, and we trust someone else to sign it" ... because that's what I read it as.
  - woodruffw 5y ago
    > git PGP signing enforces integrity at the basic level, so you've got a chain of signed git commits. PGP has a handful of issues: you’re now trusting maintainers to manage long-lived signing keys, and you now have to manage your own trusted ring of signers. Both of these break down when dealing with package management ecosystems without a curating authority (e.g., a Linux distribution). (That’s also assuming people actually verify their Git repositories, which I’ve never seen. It also assumes that people make reasonable key selection choices for PGP, which has been a problem in he past.)
  - skybrian 5y ago
    Specifically it protects against someone releasing a binary that doesn't match the source. If you can't trust that the binary was built the normal way then you either have to ignore the source and analyze the binary, or build it yourself.

orthecreedence 5y ago

> I'm probably missing something obvious No, you're not. The article is actually just braindead enough to suggest that shipping your build and cryptographic signing steps to third-parties is more secure. This isn't just wrong, it's almost criminally devious (and blatantly in service to the ever-growing surveillance state).

hulitu 5y ago
You are right except with using the adverb "braindead". I really think they are doing it on purpose. The aim is that the netizen gets a licence for everything he has: car, house, devices. The "Companies" control every device and the life of the netizen . And this security theater is just there that the netizen does not interfere with their data collection.

woodruffw 5y ago

> I'm probably missing something obvious, but I just don't get how this helps ? In my mind it seems to add extra places for security issues to be introduced ? The entire point is integrity and a fully auditable chain of actions. Quoting the post: > Performing these steps guarantees to the consumer that the binary was produced in the trusted builder at a given commit hash attested to in the provenance. They can trust that the information in the provenance was non-forgeable, allowing them to trust the build “recipe” and trace their artifact verifiably back to the source. This provides a broad swath of integrity guarantees that are otherwise extremely difficult to assert for builds that you don't control: you know exactly which machine ran the build, that it wasn't tampered with or silently replaced, and that a particular OpenID identity has signed for the build. You can verify all of these steps publicly without having to keep a trusted keychain, and without having to trust that the signing/publishing parties securely store long-lived signing keys (since everything is ephemeral). The critical thing to note here is that GitHub Actions is just the platform here. The techniques are all open, and sigstore is an open specification with an open implementation. You can do it all in-house if you'd like, or ignore it completely if everything you consume is already in-house.

hulitu 5y ago

It really helps with filling checklists. Every Google ( ecosystem) app is an RCE capable app. If they really want to improve security they shall give network access only to apps which really need it.

skybrian 5y ago

This depends on your trust model. If you don't know a project's maintainers and you trust GitHub then this model lets you verify the maintainers' work by looking at the source, while not having to build it yourself. That's a big assumption, but the idea is likely that there are lots of projects and lots of maintainers, too many to vet them all. (But who will vet all that source?) Ideally, though, someone would do the builds independently and then compare the checksums.

traceroute66 5y ago
> If you don't know a project's maintainers and you trust GitHub then this model lets you verify the maintainers' work by looking at the source, I'm not sure I follow. GitHub is basically a glorified git repo. So I still have to trust the people who do the git push, no ? If so, then I fail to see how you can do better than git PGP signing ? git PGP signing enforces integrity at the basic level, so you've got a chain of signed git commits. I don't understand the "trust" in saying, "well, we've got too many maintainers to track PGP keys, so instead anybody can commit and we'll abstract the trust away to the build-level where we trust Github to build it without tampering, and we trust someone else to sign it" ... because that's what I read it as.
- woodruffw 5y ago
  > git PGP signing enforces integrity at the basic level, so you've got a chain of signed git commits. PGP has a handful of issues: you’re now trusting maintainers to manage long-lived signing keys, and you now have to manage your own trusted ring of signers. Both of these break down when dealing with package management ecosystems without a curating authority (e.g., a Linux distribution). (That’s also assuming people actually verify their Git repositories, which I’ve never seen. It also assumes that people make reasonable key selection choices for PGP, which has been a problem in he past.)
- skybrian 5y ago
  Specifically it protects against someone releasing a binary that doesn't match the source. If you can't trust that the binary was built the normal way then you either have to ignore the source and analyze the binary, or build it yourself.