3 ms·

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 on

by 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
- pamcake 9mo ago
  Thanks for replying. I'm certainly not meaning to imply that you are in on some conspiracy or anything - you were already in here clarifying things and setting the record straight in a helpful way. I think you are not representative of industry here (in a good way). Evangelists are certainly latching on to the ambiguity and using it as an opportunity. Try to pretend you are a caveman dev or pointy-hair and read the first screenful of this. What did you learn? https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/ https://github.blog/changelog/2025-07-31-npm-trusted-publish... https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-pu... https://www.techradar.com/pro/security/github-is-finally-tightening-up-security-around-npm-following-multiple-attacks https://www.techradar.com/pro/security/github-is-finally-tig... These were the top three results I got when I searched online for "github trusted publishing" (without quotes like a normal person would). Stepping back, could it be that some stakeholders have a different agenda than you do and are actually quite happy about confusion? I have sympathy for that naming things is hard. This is Trusted Computing in repeat but marketed to a generation of laymen that don't have that context. Also similar vibes to the centralization of OpenID/OAuth from last round. On that note, looking at past efforts, I think the only way this works out is if it's open for self-managed providers from the start, not by selective global allowlisting of blessed platform partners one by one on the platform side. Just like for email, it should be sufficient with a domain name and following the protocol.

by pamcake 9mo ago

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
pamcake 9mo ago
Thanks for replying. I'm certainly not meaning to imply that you are in on some conspiracy or anything - you were already in here clarifying things and setting the record straight in a helpful way. I think you are not representative of industry here (in a good way). Evangelists are certainly latching on to the ambiguity and using it as an opportunity. Try to pretend you are a caveman dev or pointy-hair and read the first screenful of this. What did you learn? https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/ https://github.blog/changelog/2025-07-31-npm-trusted-publish... https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-pu... https://www.techradar.com/pro/security/github-is-finally-tightening-up-security-around-npm-following-multiple-attacks https://www.techradar.com/pro/security/github-is-finally-tig... These were the top three results I got when I searched online for "github trusted publishing" (without quotes like a normal person would). Stepping back, could it be that some stakeholders have a different agenda than you do and are actually quite happy about confusion? I have sympathy for that naming things is hard. This is Trusted Computing in repeat but marketed to a generation of laymen that don't have that context. Also similar vibes to the centralization of OpenID/OAuth from last round. On that note, looking at past efforts, I think the only way this works out is if it's open for self-managed providers from the start, not by selective global allowlisting of blessed platform partners one by one on the platform side. Just like for email, it should be sufficient with a domain name and following the protocol.