[Feature]: API support for managing Trusted Publishing Policies

[JamesDawson]

Related Problem

We manage 60+ open source projects, most of which publish NuGet packages. We would like to adopt trusted publishing policies, to no longer manage API keys, but the manual effort involved in creating each policy via the web site is too much.

The Elevator Pitch

The ability to efficiently onboard existing and new repositories without relying on a manual data entry task, that when performed at scale has the potential to be error prone.

Additional Context and Details

We prefer to build auditable, automated processes around these types of security-sensitive operations which we cannot do without this functionality being available via an API.

[joelverhagen]

Just to make sure I understand -- the issue is the toil involved in creating 60+ trust policies for your 60+ repositories? Do these all have the same GitHub owner?

In a hypothetical script that creates trust policies, how do you get the list of 60+ trust policies you need to create? The point I'm getting at is how do you ensure you create a trust policy for the exact right list, no more no less?

Would a UI improvement be an alternate approach? One of the reasons some features are UI-only is because it forces the user to use a 2FA-secured session. We see the creation of a trust policy as a critical operation and therefore additional security measures are needed. This one of the reasons is why the API keys page is UI only and there is no API to renew API keys.

[JamesDawson]

Thanks for the response @joelverhagen. In our case they are spread across a handful of GitHub owners and we already have a process whereby the repos under management are defined (and new ones can be enrolled), so we're looking to expand that GitOps process to include this step.

However, I take your point that automation can be an effective way to shoot your foot off at scale - we did wonder whether the security sensitive nature of it was a factor. A bulk registration UI (e.g. upload a CSV with all the details) would help with the initial onboarding, but less so streamlining ongoing ops, like setting-up new repos.

Would it be possible for an imagined new API endpoint to require a new dedicated scope, so that it would have to be an intentional action to create an API key to use it?