4 ms·

> It was a good intention, but the ramifications of it I don't think are great. as always, the road to hell is paved with good intentions the term "Trusted Pu

by blibble 9mo ago

> It was a good intention, but the ramifications of it I don't think are great. as always, the road to hell is paved with good intentions the term "Trusted Publishing" implies everyone else is untrusted quite why anyone would think Microsoft is considered trustworthy, or competent at operating critical systems, I don't know https://firewalltimes.com/microsoft-data-breach-timeline/ https://firewalltimes.com/microsoft-data-breach-timeline/

woodruffw 9mo ago
> the term "Trusted Publishing" implies everyone else is untrusted No, it just means that you're explicitly trusting a specific party to publish for you. This is exactly the same as you'd normally do implicitly by handing a CI/CD system a long-lived API token, except without the long-lived API token. (The technique also has nothing to do with Microsoft, and everything to do with the fact that GitHub Actions is the de facto majority user demographic that needs targeting whenever doing anything for large OSS ecosystems. If GitHub Actions was owned by McDonalds instead, nothing would be any different.)
- pamcake 9mo ago
  I mean, if it meant the infrastructure operated under a franchising model with distributed admin like McD, it would look quite different! There is more than one way to interpret the term "trusted". The average dev will probably take away different implications than someone with your expertise and context. I don't believe this double meaning is an unfortunate coincidence but part of clever marketing. A semantic or ideological sleight of hand, if you will. In the same category: "Trusted Computing", "Zero trust" and "Passkeys are phishing-resistant"
  - woodruffw 9mo ago
    > I don't believe this double meaning is an unfortunate coincidence but part of clever marketing. A semantic or ideological sleight of hand, if you will. I can tell you with absolute certainty that it really is just unfortunate. We just couldn’t come up with a better short name for it at the time; it was going to be either “Trusted Publishing” or “OIDC publishing,” and we determined that the latter would be too confusing to people who don’t know (and don’t care to know) what OIDC is. There’s nothing nefarious about it, just the assumption that people would understand “trusted” to mean “you’re putting trust in this,” not “you have to use $vendor.” Clearly that assumption was not well founded.
    - fc417fc802 9mo ago
      Maybe signed publishing or verified publishing would have been better terms?
      - woodruffw 9mo ago
        It’s neither signed or verified, though. There’s a signature involved, but that signature is over a JWT not over the package. (There’s an overlaid thing called “attestations” on PyPI, which is a form of signing. But Trusted Publishing itself isn’t signing.)
        fc417fc802 9mo ago
        Re signed - that is a fair point, although it raises the question, why is the distributed artifact not cryptographically authenticated? Maybe I'm misunderstanding but I thought the whole point of the exercise was to avoid token compromise. Framed another way that means the goal is authentication of the CI/CD pipeline itself, right? Wouldn't signing a fingerprint be the default solution for that? Unless there's some reason to hide the build source from downstream users of the package? Re verified, doesn't this qualify as verifying that the source of the artifact is the expected CI/CD pipeline? I suppose "authenticated publishing" could also work for the same reason.
        woodruffw 9mo ago
        > why is the distributed artifact not cryptographically authenticated? With what key? That’s the layer that “attestations” add on top, but with Trusted Publishing there’s no user/package—associated signature. > Maybe I'm misunderstanding but I thought the whole point of the exercise was to avoid token compromise. Framed another way that means the goal is authentication of the CI/CD pipeline itself, right? Wouldn't signing a fingerprint be the default solution for that? Yes, the goal is to authenticate the CI/CD pipeline (what we’d call a “machine identity”). And there is a signature involved, but it only verifies the identity of the pipeline, not the package being uploaded by that pipeline. That’s why we layer attestations on top. (The reasons for this are unfortunately nuanced but ultimately boil down to it being hard to directly sign arbitrary inputs with just OIDC in a meaningful way. I have some slides from talks I gave in the past that might help clarify Trusted Publishing, the relationship with signatures/attestations, etc.[1][2]) > I suppose "authenticated publishing" could also work for the same reason. I think this would imply that normal API token publishing is somehow not authenticated, which would be really confusing as well. It’s really not easy to come up with a name that doesn’t have some amount of overlap with existing concepts, unfortunately. [1]: https://yossarian.net/res/pub/packagingcon-2023.pdf https://yossarian.net/res/pub/packagingcon-2023.pdf [2]: https://yossarian.net/res/pub/scored-2023.pdf https://yossarian.net/res/pub/scored-2023.pdf
- fc417fc802 9mo ago
  > This is exactly the same as you'd normally do implicitly by handing a CI/CD system a long-lived API token, except without the long-lived API token. The other difference is being subjected to a whitelisting approach. That wasn't previously the case. It's frustrating that seemingly every time better authentication schemes get introduced they come with functionality for client and third party service attestation baked in. All we ever really needed was a standardized way to limit the scope of a given credential coupled with a standardized challenge format to prove possession of a private key.
  - woodruffw 9mo ago
    > The other difference is being subjected to a whitelisting approach. That wasn't previously the case. You are not being subjected to one. Again: you can always use an API token with PyPI, even on a CI/CD platform that PyPI knows how to do Trusted Publishing against. It's purely optional. > All we ever really needed was a standardized way to limit the scope of a given credential coupled with a standardized challenge format to prove possession of a private key. That is what OIDC is. Well, not for a private key, but for a set of claims that constitute a machine identity, which the relying party can then do whatever it wants with. But standards and interoperability don't mean that any given service will just choose to federate with every other service out there. Federation always has up-front and long-term costs that need to be balanced with actual delivered impact/value; for a single user on their own server, the actual value of OIDC federation versus an API token is nil.
    - fc417fc802 9mo ago
      Right, I meant that the new scheme is subject to a whitelist. I didn't mean to imply that you can't use the old scheme anymore. > Federation always has up-front and long-term costs Not particularly? For example there's no particular cost if I accept email from outlook today but reverse that decision and ban it tomorrow. I don't immediately see a technical reason to avoid a default accept policy here. > for a single user on their own server, the actual value of OIDC federation versus an API token is nil. The value is that you can do away with long lived tokens that are prone to theft. You can MFA with your (self hosted) OIDC service and things should be that much more secure. Of course your (single user) OIDC service could get pwned but that's no different than any other account compromise. I guess there's some nonzero risk that a bunch of users all decide to use the same insecure OIDC service. But you might as well worry that a bunch of them all decide to use an insecure password manager. > Well, not for a private key, but for a set of claims that constitute a machine identity What's the difference between "set of claims" and "private key" here? That last paragraph in GP was more a tangential rant than directly on topic BTW. I realize that OIDC makes sense here. The issue is that as an end user I have more flexibility and ease of use with my SSH keys than I do with something like a self hosted OIDC service. I can store my SSH keys on a hardware token, or store them on my computer blinded so that I need a hardware token or TPM to unlock them, or lots of other options. The service I'm connecting to doesn't need to know anything about my workflow. Whereas self hosting something like OIDC managing and securing the service becomes an entire thing on top of which many services arbitrarily dictate "thou shalt not self host". It's a general trend that as new authentication schemes have been introduced they have generally included undesirable features from the perspective of user freedom. Adding insult to injury those unnecessary features tend to increase the complexity of the specification. In contrast, it's interesting to think how things might work if what we had instead was a single widely accepted challenge scheme such as SSH has. You could implement all manner of services such as OIDC on top of such a primitive while end users would retain the ability to directly use the equivalent of an SSH key.

by blibble 9mo ago

woodruffw 9mo ago

> the term "Trusted Publishing" implies everyone else is untrusted No, it just means that you're explicitly trusting a specific party to publish for you. This is exactly the same as you'd normally do implicitly by handing a CI/CD system a long-lived API token, except without the long-lived API token. (The technique also has nothing to do with Microsoft, and everything to do with the fact that GitHub Actions is the de facto majority user demographic that needs targeting whenever doing anything for large OSS ecosystems. If GitHub Actions was owned by McDonalds instead, nothing would be any different.)

pamcake 9mo ago
I mean, if it meant the infrastructure operated under a franchising model with distributed admin like McD, it would look quite different! There is more than one way to interpret the term "trusted". The average dev will probably take away different implications than someone with your expertise and context. I don't believe this double meaning is an unfortunate coincidence but part of clever marketing. A semantic or ideological sleight of hand, if you will. In the same category: "Trusted Computing", "Zero trust" and "Passkeys are phishing-resistant"
- woodruffw 9mo ago
  > I don't believe this double meaning is an unfortunate coincidence but part of clever marketing. A semantic or ideological sleight of hand, if you will. I can tell you with absolute certainty that it really is just unfortunate. We just couldn’t come up with a better short name for it at the time; it was going to be either “Trusted Publishing” or “OIDC publishing,” and we determined that the latter would be too confusing to people who don’t know (and don’t care to know) what OIDC is. There’s nothing nefarious about it, just the assumption that people would understand “trusted” to mean “you’re putting trust in this,” not “you have to use $vendor.” Clearly that assumption was not well founded.
  - fc417fc802 9mo ago
    Maybe signed publishing or verified publishing would have been better terms?
    - woodruffw 9mo ago
      It’s neither signed or verified, though. There’s a signature involved, but that signature is over a JWT not over the package. (There’s an overlaid thing called “attestations” on PyPI, which is a form of signing. But Trusted Publishing itself isn’t signing.)
      - fc417fc802 9mo ago
        Re signed - that is a fair point, although it raises the question, why is the distributed artifact not cryptographically authenticated? Maybe I'm misunderstanding but I thought the whole point of the exercise was to avoid token compromise. Framed another way that means the goal is authentication of the CI/CD pipeline itself, right? Wouldn't signing a fingerprint be the default solution for that? Unless there's some reason to hide the build source from downstream users of the package? Re verified, doesn't this qualify as verifying that the source of the artifact is the expected CI/CD pipeline? I suppose "authenticated publishing" could also work for the same reason.
        woodruffw 9mo ago
        > why is the distributed artifact not cryptographically authenticated? With what key? That’s the layer that “attestations” add on top, but with Trusted Publishing there’s no user/package—associated signature. > Maybe I'm misunderstanding but I thought the whole point of the exercise was to avoid token compromise. Framed another way that means the goal is authentication of the CI/CD pipeline itself, right? Wouldn't signing a fingerprint be the default solution for that? Yes, the goal is to authenticate the CI/CD pipeline (what we’d call a “machine identity”). And there is a signature involved, but it only verifies the identity of the pipeline, not the package being uploaded by that pipeline. That’s why we layer attestations on top. (The reasons for this are unfortunately nuanced but ultimately boil down to it being hard to directly sign arbitrary inputs with just OIDC in a meaningful way. I have some slides from talks I gave in the past that might help clarify Trusted Publishing, the relationship with signatures/attestations, etc.[1][2]) > I suppose "authenticated publishing" could also work for the same reason. I think this would imply that normal API token publishing is somehow not authenticated, which would be really confusing as well. It’s really not easy to come up with a name that doesn’t have some amount of overlap with existing concepts, unfortunately. [1]: https://yossarian.net/res/pub/packagingcon-2023.pdf https://yossarian.net/res/pub/packagingcon-2023.pdf [2]: https://yossarian.net/res/pub/scored-2023.pdf https://yossarian.net/res/pub/scored-2023.pdf
fc417fc802 9mo ago
> This is exactly the same as you'd normally do implicitly by handing a CI/CD system a long-lived API token, except without the long-lived API token. The other difference is being subjected to a whitelisting approach. That wasn't previously the case. It's frustrating that seemingly every time better authentication schemes get introduced they come with functionality for client and third party service attestation baked in. All we ever really needed was a standardized way to limit the scope of a given credential coupled with a standardized challenge format to prove possession of a private key.
- woodruffw 9mo ago
  > The other difference is being subjected to a whitelisting approach. That wasn't previously the case. You are not being subjected to one. Again: you can always use an API token with PyPI, even on a CI/CD platform that PyPI knows how to do Trusted Publishing against. It's purely optional. > All we ever really needed was a standardized way to limit the scope of a given credential coupled with a standardized challenge format to prove possession of a private key. That is what OIDC is. Well, not for a private key, but for a set of claims that constitute a machine identity, which the relying party can then do whatever it wants with. But standards and interoperability don't mean that any given service will just choose to federate with every other service out there. Federation always has up-front and long-term costs that need to be balanced with actual delivered impact/value; for a single user on their own server, the actual value of OIDC federation versus an API token is nil.
  - fc417fc802 9mo ago
    Right, I meant that the new scheme is subject to a whitelist. I didn't mean to imply that you can't use the old scheme anymore. > Federation always has up-front and long-term costs Not particularly? For example there's no particular cost if I accept email from outlook today but reverse that decision and ban it tomorrow. I don't immediately see a technical reason to avoid a default accept policy here. > for a single user on their own server, the actual value of OIDC federation versus an API token is nil. The value is that you can do away with long lived tokens that are prone to theft. You can MFA with your (self hosted) OIDC service and things should be that much more secure. Of course your (single user) OIDC service could get pwned but that's no different than any other account compromise. I guess there's some nonzero risk that a bunch of users all decide to use the same insecure OIDC service. But you might as well worry that a bunch of them all decide to use an insecure password manager. > Well, not for a private key, but for a set of claims that constitute a machine identity What's the difference between "set of claims" and "private key" here? That last paragraph in GP was more a tangential rant than directly on topic BTW. I realize that OIDC makes sense here. The issue is that as an end user I have more flexibility and ease of use with my SSH keys than I do with something like a self hosted OIDC service. I can store my SSH keys on a hardware token, or store them on my computer blinded so that I need a hardware token or TPM to unlock them, or lots of other options. The service I'm connecting to doesn't need to know anything about my workflow. Whereas self hosting something like OIDC managing and securing the service becomes an entire thing on top of which many services arbitrarily dictate "thou shalt not self host". It's a general trend that as new authentication schemes have been introduced they have generally included undesirable features from the perspective of user freedom. Adding insult to injury those unnecessary features tend to increase the complexity of the specification. In contrast, it's interesting to think how things might work if what we had instead was a single widely accepted challenge scheme such as SSH has. You could implement all manner of services such as OIDC on top of such a primitive while end users would retain the ability to directly use the equivalent of an SSH key.