OIDC API Key Role RFC

[segiddins]

RFC for rubygems/rubygems.org#3716

[indirect]

This is a great start! The motivation section does a great job with "why", and the guide section does a great job with "what". I think most of what's in the "guide" section right now is actually implementation/reference details, and the guide should be something like "You are a RubyGems developer with MFA enabled, and you want to automated publishing gems. Here's how you do that: Step 1, 2, 3."

For reference/comparison, here is the PyPi parallel effort, called "Trusted Publishers":

• Announcement blog post: https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/
• Internal details docs: https://docs.pypi.org/trusted-publishers/internals/
• End-user documentation: https://docs.pypi.org/trusted-publishers/
• Implementation code: https://github.com/pypi/warehouse/tree/main/warehouse/oidc

If it's easier to compare/contrast using the Python version as a base, that seems reasonable.

[segiddins]

@indirect is what I added what you have in mind?

[indirect]

Yes! I think that's close enough to discuss and approve the overall idea. 👍🏻

To ship the implementation as completed, I think we'll need the "guide" to be a bit more fleshed out, including the actual steps that are needed. For example, what are the gem publishers supposed to do with the example JSON documents? Where does the ID that they supply to the GitHub Action come from? etc. Feel free to either flesh out the guide here and then copy it into the docs later, or include the more complete docs alongside the implementation once you are more sure about how it will work.

[segiddins]

including the actual steps that are needed

I think I included that? To start with, I plan on shipping the OIDC work without a public facing UI, which means the way to get set up will be through an admin using the admin interface.

Once we have some beta users and confirm the implementation (and with it, associated data structures) works for all involved, I was planning to build a UI at that point.

If that doesn't work for you, then I have to go back and build all that now, which will delay getting the core implementation released.

[indirect]

It's fine to ship it for testing with manual setup by maintainers. 👍 I just mean the actual docs, even if setup is manual by admins, will need to explain more granular detail about e.g. how to get the ID you put into the GitHub Action config.

[segiddins]

Would it be better if i changed it to use the provider URL instead of the ID, and added in a unique index on the URL?

[indirect]

I'm not sure, but probably, if that makes it clearer what the config value is for?

[segiddins]

OK never mind, I mis-understood. We end up using the ID because we need something to look up that uniquely identifies the API Key Role, without a priori being able to scope to a user.

I suppose we could do something like a user-supplied label that is combined with the account handle? But that's not great since the handles can change...

I think using the ID is fine for now. You will get it back (eventually) when you POST to create the API Key Role, you can find it when GETing the list of the current users API Key Roles, etc.

[jenshenny]

This is great - happy to see this being introduced! 🚀 Planning to take a look at rubygems/rubygems.org#3716 shortly

[jenshenny]

How would users submit a support request? Would this just be via email/slack or would it be a request form (asking for scopes, gem, etc) in RubyGems.org? I'm assuming the form could be slightly altered when it's released for the general audience.

[segiddins]

for now, via a support request (email) or in slack. when ready to release to GA, there will be an API and web form for this

[jenshenny]

To be transparent, Shopify's publishing infrastructure is not using Github Actions currently though the goal is to migrate over. We would love to use this feature org-wide once the migration is completed, however it's to be determined where it is on the roadmap.

[segiddins]

do you have an OIDC provider available to your publishing infra? If so, I'm happy to add it as another supported provider in the beta period

[jenshenny]

Not readily available, we're currently using shipit-engine. No need to add another provider, as Github Actions is what we're moving towards (just the timeline is a bit unknown at the moment).

[thepwagner]

References:

• Related discussion in PyPI - Provide Trusted Publisher information pypi's API pypi/warehouse#14799
• Claims available from GitHub Actions in particular: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token

---

I'm most interested in the repository and job_workflow_ref claim, like octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main.

I want that so:

• I can compare to the repository specified by the gem.
• I can compare the refs/tags/v1.2.3 portion to the version of the gem that was generated. That makes me comfortable the gem wasn't published by an issue_comment event that allowed script injection.
• I can fetch and analyze the workflow file that produced the release
  • Maybe I'll make sure there is only one .jobs[] with .permissions["id-token"]: write
  • Maybe I'll look at the .job[].steps[].uses and match against an allowlist (e.g. I want the workflow to contain only actions/checkout@.*, ruby/setup-ruby@.* and rubygems/release-gem@.* steps.
  • The code in https://github.com/ossf/scorecard-webapp/blob/main/app/server/verify_workflow.go is a good implementation of ways one might want to verify the workflow file doesn't contain any shenaningans.
• I especially like how this attribute works with reusable workflows. If https://github.com/rubygems/release-gem included a reusable workflow for users instead of an example workflow to copy/paste, then I could match against job_workflow_ref: rubygems/release-gem/.github/workflows/release.yml@.* to allow any gems published using the "approved" workflow.

Please redirect if there is a better place for this discussion ❤️ .