5 ms·

Isn’t this what OAuth and OIDC supposed to handle? Thank you for not wrapping this up in docker image. Unless there’s a specific purpose for it, those kind of

by hk1337 4y ago

Isn’t this what OAuth and OIDC supposed to handle? Thank you for not wrapping this up in docker image. Unless there’s a specific purpose for it, those kind of actions are annoying to use. EDIT also, kudos to putting a version on it. An action dealing with authentication and telling you to use it with “@master” is suspect, IMO.

woodruffw 4y ago
Yes, pretty much. The advantage to something like OIDC is that it requires virtually no trust except the trust already established: you trust GitHub to host your code and NPM (or whoever) to publish it; OIDC allows GitHub to share a machine identity that NPM can verify and grant publishing rights to (e.g. via a temporary API token). The downside to that approach is that it requires the consuming side (NPM in this case) to understand and verify OIDC tokens (which are really just JWTs). But we're currently working on exactly that on PyPI, and hopefully other package ecosystems will follow our progress there.
ljharb 4y ago
npm doesn’t offer these things, so it’s not a useful comparison.
GauntletWizard 4y ago
Versions don't matter in GitHub actions; it takes "Tags" as the highest priority, which maintainers can update at will. Yes, they have to delete the tag first, but there's a UI button for that. Yes, anyone who's cloned the repo will receive a warning, but have you ever cloned an external GitHub actions repo? Advice to use external GitHub actions, especially security actions, should pin to a sha instead.
- hk1337 4y ago
  That's good advice. My biggest issue were when examples show using the action as `my-action@master`.
varunsharma07 4y ago
OIDC that is a good alternative. This GitHub Action uses OIDC to authenticate the workflow to confirm secrets are only given to the authorized job. The differences between OIDC and MFA for publishing credentials are: 1) More control: each release gets gated by human intervention, requiring MFA to publish. 2) Separation of duties: Just because one has "write" access to the code/ workflow does not automatically permit them to publish. 3) Less management overhead: With MFA, there is no need to set up OIDC trust policies (which need to be configured accurately). This removes the need to manage a separate set of deployment credentials/ policies.

by hk1337 4y ago

woodruffw 4y ago

Yes, pretty much. The advantage to something like OIDC is that it requires virtually no trust except the trust already established: you trust GitHub to host your code and NPM (or whoever) to publish it; OIDC allows GitHub to share a machine identity that NPM can verify and grant publishing rights to (e.g. via a temporary API token). The downside to that approach is that it requires the consuming side (NPM in this case) to understand and verify OIDC tokens (which are really just JWTs). But we're currently working on exactly that on PyPI, and hopefully other package ecosystems will follow our progress there.

ljharb 4y ago

npm doesn’t offer these things, so it’s not a useful comparison.

GauntletWizard 4y ago

Versions don't matter in GitHub actions; it takes "Tags" as the highest priority, which maintainers can update at will. Yes, they have to delete the tag first, but there's a UI button for that. Yes, anyone who's cloned the repo will receive a warning, but have you ever cloned an external GitHub actions repo? Advice to use external GitHub actions, especially security actions, should pin to a sha instead.

hk1337 4y ago
That's good advice. My biggest issue were when examples show using the action as `my-action@master`.

varunsharma07 4y ago

OIDC that is a good alternative. This GitHub Action uses OIDC to authenticate the workflow to confirm secrets are only given to the authorized job. The differences between OIDC and MFA for publishing credentials are: 1) More control: each release gets gated by human intervention, requiring MFA to publish. 2) Separation of duties: Just because one has "write" access to the code/ workflow does not automatically permit them to publish. 3) Less management overhead: With MFA, there is no need to set up OIDC trust policies (which need to be configured accurately). This removes the need to manage a separate set of deployment credentials/ policies.