4 ms·

> Has anyone implemented this end-to-end? Yes; I (along with a bunch of other fantastic folks) implemented it end-to-end for both Homebrew[1] and PyPI[2]. This

> Has anyone implemented this end-to-end? Yes; I (along with a bunch of other fantastic folks) implemented it end-to-end for both Homebrew[1] and PyPI[2]. This is at a "lower" level than most corporate uses, however: the goal with integrating Sigstore into these OSS ecosystems is not to build up complex verifiable policies (which OSS maintainers don't want to deal with), but to enable signing with misuse-resistant machine identities. [1]: https://blog.trailofbits.com/2023/11/06/adding-build-provenance-to-homebrew/ https://blog.trailofbits.com/2023/11/06/adding-build-provena... [2]: https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-digital-attestations/ https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-dig...

KennyBlanken 2y ago
[flagged]
- woodruffw 2y ago
  Apart from the snark (which is unwarranted), I can't even parse what you're saying. (Mentioning sudo in the context of Homebrew suggests that you're one of those incoherent threat model people, so I'm going to assume it's that. So I'll say what Homebrew's maintainers have been saying for years: having a user writable Homebrew prefix is no more or less exploitable in the presence of attacker code execution than literally anything else. The attacker can always modify your shell initialization script, or your local Python bin directory, or anything else.)
  - saidinesh5 2y ago
    I'm not much of a Mac user but I'm guessing the parent comment wanted readonly user install path so accidental/malicious rm -rf only affects the user data and not the installed programs? Nothing to do with exploits as part of homebrew etc .
    - woodruffw 2y ago
      > I'm not much of a Mac user but I'm guessing the parent comment wanted readonly user install path so accidental/malicious rm -rf only affects the user data and not the installed programs? That's one possible interpretation, but it's at odds with how most people use the `$PATH` anyways -- there's lots of local read-writable stuff on it in typical cases. And of course, even without that, persistence is trivial for an attacker with local code execution.
arianvanp 2y ago
Is GitHub id tokens a misuse-resistent though? It seems a very weak machine identity. 1. It's a repayable bearer token and not a proof of possession. A compromised action (which 99% of people do not pin to specific hashes) could exfiltrate an id token and use it for 15 minutes. 2. There is no proof of provenance of the build machine attached to it all. No attestation about machine state. The only thing you know is "signed by GitHub" which doesn't really tell you anything interesting. Given Microsofts track record of security vulnerabilities in Azure regarding cross-tenant contamination I'd like to see a stronger attestation statement here. Minimally this provenance stuff should be built on top of some proof of possession mechanism where a challenge is generated and the builder signs the challenge with its machine identity key. Then ideally have an attestation statement that shows you the provenance of the entire machine (what packages , dm-verity hashes, whatever) together with that public key. Sure it's better than nothing what GitHub has now. And an attack is obvious in hindsight and clearly in the transparency log . But its definitely not a misuse resistent machine identity. We need something better for this IMO.
- arccy 2y ago
  it's not just a random token "signed by github", a token containing the runtime context it was requested in (repo, branch / commit, build, etc) see the fields in https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token https://docs.github.com/en/actions/security-for-github-actio... the level of attestation you want (essentially bound to tpms) would probably be very difficult to provide given how all sorts of images run in a typical ci pipeline.
- woodruffw 2y ago
  “Misuse resistant” is contextually sensitive: I would argue that a self-expiring identity token and a self-expiring signing key are significantly more misuse-resistant than “traditional” code signing (where you issue a key once, let the revocation process ossify, and never rotate due to insufficient client adoption). Is it perfect? No, and your point about “true” provenance is a good one: perfect fidelity in provenance would require hardware attestations and a “whole-machine” picture, which is not something that widely adopted CI/CD setups can easily produce at the moment. > Minimally this provenance stuff should be built on top of some proof of possession mechanism where a challenge is generated and the builder signs the challenge with its machine identity key. That’s how Fulcio works: your public identity is bound as a result of a proof of possession for an ephemeral key and an identity token.
crabbone 2y ago
Oh, so this is where the idea of signing Python packages with GitHub Actions comes from... From the bottom of my heart, I wish only the worst things for you in your programming career. Yes, I know that it's still possible to publish packages w/o GitHub, but the technical aspect alone will not convince people in organizations which set policies for how to do this stuff. So, the technical possibility alone doesn't matter. Now a bunch of organizations which advertise themselves as free / OSS have to eat MS proprietary garbage and be grateful... thanks to heroes like you.
- woodruffw 2y ago
  That’s nice. I don’t wish anything bad for you. It isn’t any harder to publish without before this feature than it is now. In fact it’s easier, because I implemented generic API tokens for PyPI years before this feature, and the feature itself isn’t even tied to GitHub or any particular OIDC IdP. We just picked GitHub as the first external IdP because it is unambiguously the most popular one in the Python ecosystem.
  - crabbone 2y ago
    Nobody needed generic API tokens for PyPI either. Not now, not years ago. The problem isn't a technical one. The problem is that when a company / government body hears that the "official way to do X is Y", they'll create an internal policy to do Y all the time, regardless of how evil or stupid Y is. You just destroyed a public good by making a bunch of organizations require the use of GitHub and other MS trash for no technical reason. You are a lot worse than a real estate developer who paved over a community park to build a parking lot for some mega corp. If people saw you doing this in a movie, it would've been so cartoonishly evil, the audience would think the director jumped a shark, yet, real life appears to be worse than the portrayal of evil in art.
    - woodruffw 2y ago
      > Nobody needed generic API tokens for PyPI either. Not now, not years ago. It was one of the most-requested features on PyPI, but OK. The rest of this is just ranting. I think you should develop some more perspective on this, and observe that nobody else is even remotely as bent out of shape as you are over these changes. Which, again, aren't even close to mandatory (and couldn't be even if anybody wanted them to be, which nobody does).

KennyBlanken 2y ago

[flagged]

woodruffw 2y ago
Apart from the snark (which is unwarranted), I can't even parse what you're saying. (Mentioning sudo in the context of Homebrew suggests that you're one of those incoherent threat model people, so I'm going to assume it's that. So I'll say what Homebrew's maintainers have been saying for years: having a user writable Homebrew prefix is no more or less exploitable in the presence of attacker code execution than literally anything else. The attacker can always modify your shell initialization script, or your local Python bin directory, or anything else.)
- saidinesh5 2y ago
  I'm not much of a Mac user but I'm guessing the parent comment wanted readonly user install path so accidental/malicious rm -rf only affects the user data and not the installed programs? Nothing to do with exploits as part of homebrew etc .
  - woodruffw 2y ago
    > I'm not much of a Mac user but I'm guessing the parent comment wanted readonly user install path so accidental/malicious rm -rf only affects the user data and not the installed programs? That's one possible interpretation, but it's at odds with how most people use the `$PATH` anyways -- there's lots of local read-writable stuff on it in typical cases. And of course, even without that, persistence is trivial for an attacker with local code execution.

arianvanp 2y ago

Is GitHub id tokens a misuse-resistent though? It seems a very weak machine identity. 1. It's a repayable bearer token and not a proof of possession. A compromised action (which 99% of people do not pin to specific hashes) could exfiltrate an id token and use it for 15 minutes. 2. There is no proof of provenance of the build machine attached to it all. No attestation about machine state. The only thing you know is "signed by GitHub" which doesn't really tell you anything interesting. Given Microsofts track record of security vulnerabilities in Azure regarding cross-tenant contamination I'd like to see a stronger attestation statement here. Minimally this provenance stuff should be built on top of some proof of possession mechanism where a challenge is generated and the builder signs the challenge with its machine identity key. Then ideally have an attestation statement that shows you the provenance of the entire machine (what packages , dm-verity hashes, whatever) together with that public key. Sure it's better than nothing what GitHub has now. And an attack is obvious in hindsight and clearly in the transparency log . But its definitely not a misuse resistent machine identity. We need something better for this IMO.

arccy 2y ago
it's not just a random token "signed by github", a token containing the runtime context it was requested in (repo, branch / commit, build, etc) see the fields in https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token https://docs.github.com/en/actions/security-for-github-actio... the level of attestation you want (essentially bound to tpms) would probably be very difficult to provide given how all sorts of images run in a typical ci pipeline.
woodruffw 2y ago
“Misuse resistant” is contextually sensitive: I would argue that a self-expiring identity token and a self-expiring signing key are significantly more misuse-resistant than “traditional” code signing (where you issue a key once, let the revocation process ossify, and never rotate due to insufficient client adoption). Is it perfect? No, and your point about “true” provenance is a good one: perfect fidelity in provenance would require hardware attestations and a “whole-machine” picture, which is not something that widely adopted CI/CD setups can easily produce at the moment. > Minimally this provenance stuff should be built on top of some proof of possession mechanism where a challenge is generated and the builder signs the challenge with its machine identity key. That’s how Fulcio works: your public identity is bound as a result of a proof of possession for an ephemeral key and an identity token.

crabbone 2y ago

Oh, so this is where the idea of signing Python packages with GitHub Actions comes from... From the bottom of my heart, I wish only the worst things for you in your programming career. Yes, I know that it's still possible to publish packages w/o GitHub, but the technical aspect alone will not convince people in organizations which set policies for how to do this stuff. So, the technical possibility alone doesn't matter. Now a bunch of organizations which advertise themselves as free / OSS have to eat MS proprietary garbage and be grateful... thanks to heroes like you.

woodruffw 2y ago
That’s nice. I don’t wish anything bad for you. It isn’t any harder to publish without before this feature than it is now. In fact it’s easier, because I implemented generic API tokens for PyPI years before this feature, and the feature itself isn’t even tied to GitHub or any particular OIDC IdP. We just picked GitHub as the first external IdP because it is unambiguously the most popular one in the Python ecosystem.
- crabbone 2y ago
  Nobody needed generic API tokens for PyPI either. Not now, not years ago. The problem isn't a technical one. The problem is that when a company / government body hears that the "official way to do X is Y", they'll create an internal policy to do Y all the time, regardless of how evil or stupid Y is. You just destroyed a public good by making a bunch of organizations require the use of GitHub and other MS trash for no technical reason. You are a lot worse than a real estate developer who paved over a community park to build a parking lot for some mega corp. If people saw you doing this in a movie, it would've been so cartoonishly evil, the audience would think the director jumped a shark, yet, real life appears to be worse than the portrayal of evil in art.
  - woodruffw 2y ago
    > Nobody needed generic API tokens for PyPI either. Not now, not years ago. It was one of the most-requested features on PyPI, but OK. The rest of this is just ranting. I think you should develop some more perspective on this, and observe that nobody else is even remotely as bent out of shape as you are over these changes. Which, again, aren't even close to mandatory (and couldn't be even if anybody wanted them to be, which nobody does).