Trusted Publishing and shared workflows

[rvdginste]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

I am setting up GitHub Actions workflows for the build and publish of a NuGet package. I want to make use of "Trusted Publishing" so that I can work with short-lived tokens and do not have to keep track of API keys.

How to set this up, is described here:
https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing

I did this, and if I use a straight-forward workflow, this works fine. I create a "publish.yml" workflow, and on nuget.org I register a policy for that specific repo and that specific workflow.

I have a bunch of projects that are set up the same way and that require the exact same publish workflow with some configuration. So, I went ahead and setup a repo for the shared workflows and then I reference those with the "uses" syntax.

After I updated my main repo to use this shared workflow, "trusted publishing" broke. I got an error when performing the "nuget/login" step. See: https://github.com/NuGet/login. The error mentions that my policy refers to my main repo, while the "login" step is coming from the repo with the shared workflows.

So, my conclusion is that I need to create a policy for the workflow that contains the "nuget/login" step and the repo where that workflow file is located. I added a new policy on nuget.org and removed the original policy. However, now I get an error (401) without any explanation about what is going wrong.

I have some questions regarding this:

1. Both my project repo and the shared workflows repo are public. This means that the shared workflows could be used by anyone else. If the policy that I need to create on nuget.org only relies on the shared workflows repo, then that would mean that anyone who uses those shared workflows could publish (my) nuget packages in my name? Or am I missing something?
   It would seem more logical that the needed policy on nuget.org refers to the originating repo and the originating workflow and not the shared workflow that is called as a helper.

2. My next thought was to leave the "nuget/login" step inside the originating workflow and pass the obtained token to the shared workflow as a secret. For this to work, I needed to declare the token as output on the job that obtains the token and pass it to the job that calls the common workflow. This did not work, I got a warning that the output was not passed on as it looked like a secret. How can I pass the token in a safe way?

3. I did this in the context of a .NET project and a nuget package. I did find the following piece of text in the "Trusted Publishing" info on npmjs: "Some GitHub Actions workflows use workflow_call to invoke other workflows that run npm publish, or use workflow_dispatch for manual publishing. When this happens, validation checks the calling workflow's name instead of the workflow that actually contains the publish command, which can cause configuration mismatches." So, I tried to update my policy on nuget.org using this advice, but that, also, failed. With that policy I also received an error (401) without any explanation. How is it actually supposed to work with a shared workflow that obtains a token? What is the best approach to use "Trusted Publishing" with a shared publish workflow?

Kind regards,
Ruben

[andriiafanasiev]

Trusted Publishing currently validates the workflow and repository where the token is actually obtained. When using shared workflows from another repo, the policy on NuGet needs to match the repository that contains the nuget/login step, which can cause 401 errors if it doesn’t.

There isn’t a direct way to pass a secret token safely as an output from one workflow to another due to GitHub restrictions. The most reliable approach is to keep the nuget/login step in the originating repo’s workflow and call shared workflows after obtaining the token, passing non-secret configuration or parameters only. This ensures the policy validation works and your token remains secure.

[rvdginste]

Thanks for your clear answer.

I think it is a pity that validation is not done against the original workflow and the repo that triggers the token request, since currently it is basically unusable for shared workflows.