4 ms·

Once you configure all the CI and everything, following the documentation. Isn't the documentation giving the advice to make it publish automatically on a git t

by guappa 3y ago

Once you configure all the CI and everything, following the documentation. Isn't the documentation giving the advice to make it publish automatically on a git tag? And isn't it true that to do a git tag you only need to steal the private ssh keys of the account, which are commonly stored in the ~/.ssh directory? If I am the attacker, and a project has trusted publishing configured, my target shifts from the token.txt file on the machine of a maintainer, to the .ssh directory on the very same machine. You can do all the complicated authentication schemes between github and pypi, but do I care to attack there when there's a much easier point to attack? I have set up trusted publishers for one of my projects. At least from the point of view of a user I am familiar with it. A git tag followed by a push did indeed trigger a new build+release workflow in my CI.

woodruffw 3y ago
These are different layers: trusted publishing doesn't know how you store your git credentials, and PyPI isn't able to be prescriptive there. The recommendation that you publish from a tag is just normal release hygiene stuff; PyPI cannot make you use the other parts of your computer safely. The scenario you're talking about ("attacker has your SSH private key") is already a "game over" scenario, and is tantamount to the attacker assuming your identity. Trusted publishing is not aimed at that scenario; it's aimed at eliminating other scenarios (such as people using permanent user-scoped tokens everywhere, making it easier for an attacker to move laterally after compromising a single token). Or in other words: not every attacker is empowered to assume my identity by stealing my SSH key (which lives in a security module for me, not in `~/.ssh`). That's a very strong attacker model; there are other, weaker attacker models that are still worth defending against (such as someone who opportunistically compromises a single CI run, or takes advantage of a one-time accidental API token leak). Edit: and note: the documentation for trusted publishing encourages you to use a release environment on PyPI, which can be configured to require multi-user signoff. So you can use it to prevent a stolen SSH key from compromising your uploaded project. But again, that is the strongest possible adversary, and is not the most common one that users need protecting against.
- guappa 3y ago
  I think you are only considering people who use a CI to do an upload. Do you have any data of how many pypi projects are set up this way in total? I upload from my machine, where a token.txt is stored on the same disk as the .ssh file. So your game over scenario is identical in both cases for me. > people using permanent user-scoped tokens everywhere I'd say that's a major design flaw of pypi, that it is impossible to create per-package scoped tokens directly, unless one is configuring trusted publishers (which translates to github). > which lives in a security module for me I am very confident that this is extremely uncommon among authors of projects hosted by pypi. Is this a mandate from your employer? (I don't know who that might be and if it is related at all, just asking.)
  - woodruffw 3y ago
    No, I don’t have those numbers on hand. If you upload from your local machine, none of this applies to you. It only applies to people using CI to upload, who want to reduce the overall scope of their shared access by not relying on permanent credentials. That’s the whole point of trusted publishing; it has nothing to do with locally initiated uploads. > I'd say that's a major design flaw of pypi, that it is impossible to create per-package scoped tokens directly, unless one is configuring trusted publishers (which translates to github). I think you’ve misunderstood. PyPI allows you to create project scoped tokens completely independent of trusted publishing. Trusted publishing is only distinguished in that the scopes are automatic, meaning that the user cannot overscope their token. The point about security modules is a red herring; it was supposed to emphasize that this is outside of PyPI’s domain of interest. But no, I do it for myself, not because my employer requires it.
    - guappa 3y ago
      Well it would be interesting to have the numbers, to know how important it is to focus on defending uploads from CI vs uploads from developer machines. > PyPI allows you to create project scoped tokens It requires the creation of a non-scoped token first, to do that. And since people are lazy I'd bet many have not created a scoped token. Again, this is supposition from my part that could be verified or proven wrong by you.

by guappa 3y ago

woodruffw 3y ago

These are different layers: trusted publishing doesn't know how you store your git credentials, and PyPI isn't able to be prescriptive there. The recommendation that you publish from a tag is just normal release hygiene stuff; PyPI cannot make you use the other parts of your computer safely. The scenario you're talking about ("attacker has your SSH private key") is already a "game over" scenario, and is tantamount to the attacker assuming your identity. Trusted publishing is not aimed at that scenario; it's aimed at eliminating other scenarios (such as people using permanent user-scoped tokens everywhere, making it easier for an attacker to move laterally after compromising a single token). Or in other words: not every attacker is empowered to assume my identity by stealing my SSH key (which lives in a security module for me, not in `~/.ssh`). That's a very strong attacker model; there are other, weaker attacker models that are still worth defending against (such as someone who opportunistically compromises a single CI run, or takes advantage of a one-time accidental API token leak). Edit: and note: the documentation for trusted publishing encourages you to use a release environment on PyPI, which can be configured to require multi-user signoff. So you can use it to prevent a stolen SSH key from compromising your uploaded project. But again, that is the strongest possible adversary, and is not the most common one that users need protecting against.

guappa 3y ago
I think you are only considering people who use a CI to do an upload. Do you have any data of how many pypi projects are set up this way in total? I upload from my machine, where a token.txt is stored on the same disk as the .ssh file. So your game over scenario is identical in both cases for me. > people using permanent user-scoped tokens everywhere I'd say that's a major design flaw of pypi, that it is impossible to create per-package scoped tokens directly, unless one is configuring trusted publishers (which translates to github). > which lives in a security module for me I am very confident that this is extremely uncommon among authors of projects hosted by pypi. Is this a mandate from your employer? (I don't know who that might be and if it is related at all, just asking.)
- woodruffw 3y ago
  No, I don’t have those numbers on hand. If you upload from your local machine, none of this applies to you. It only applies to people using CI to upload, who want to reduce the overall scope of their shared access by not relying on permanent credentials. That’s the whole point of trusted publishing; it has nothing to do with locally initiated uploads. > I'd say that's a major design flaw of pypi, that it is impossible to create per-package scoped tokens directly, unless one is configuring trusted publishers (which translates to github). I think you’ve misunderstood. PyPI allows you to create project scoped tokens completely independent of trusted publishing. Trusted publishing is only distinguished in that the scopes are automatic, meaning that the user cannot overscope their token. The point about security modules is a red herring; it was supposed to emphasize that this is outside of PyPI’s domain of interest. But no, I do it for myself, not because my employer requires it.
  - guappa 3y ago
    Well it would be interesting to have the numbers, to know how important it is to focus on defending uploads from CI vs uploads from developer machines. > PyPI allows you to create project scoped tokens It requires the creation of a non-scoped token first, to do that. And since people are lazy I'd bet many have not created a scoped token. Again, this is supposition from my part that could be verified or proven wrong by you.