Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 952d25c

Browse files
authored
Add Trusted Publishing doc (#3442)
1 parent 5f4514e commit 952d25c

File tree

3 files changed

+112
-0
lines changed

3 files changed

+112
-0
lines changed
112 KB
Loading

docs/nuget-org/overview-nuget-org.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -33,6 +33,10 @@ Once you have a NuGet package (*.nupkg* file) to publish, you publish it to NuGe
3333

3434
When you [publish a package](../create-packages/creating-a-package.md), you include the API key value in the CLI command.
3535

36+
## Trusted publishing
37+
38+
NuGet.org supports [Trusted Publishing](trusted-publishing.md), which is a secure and streamlined way to publish NuGet packages.
39+
3640
## ID prefixes
3741

3842
When you publish packages, you can reserve and protect your identity by [reserving ID prefixes](id-prefix-reservation.md). When installing a package, package consumers are provided with additional information indicating that the package they are consuming is not deceptive in its identifying properties.
Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
---
2+
title: Trusted Publishing
3+
description: Trusted Publishing on nuget.org
4+
author: etvorun
5+
ms.author: evgenyt
6+
ms.date: 07/01/2025
7+
ms.topic: conceptual
8+
---
9+
10+
# Trusted Publishing on nuget.org
11+
12+
Trusted Publishing is a better way to publish NuGet packages. You don’t need to manage long-lived API keys anymore. Instead, you use short-lived credentials issued by your CI/CD system, like GitHub Actions.
13+
14+
This makes your publishing process safer by reducing the risk of leaked credentials. It also makes automation easier because you don’t need to rotate or store secrets. This approach is part of a broader industry shift toward secure, keyless publishing. If you're curious, check out the OpenSSF initiative: https://repos.openssf.org/trusted-publishers-for-all-package-repositories.
15+
16+
> ⚠️ **Heads up:** If you don’t see the **Trusted Publishing** option in your nuget.org account, it might not be available to you yet. We’re rolling it out gradually.
17+
18+
## How it works
19+
20+
Here’s the basic flow:
21+
22+
1. Your CI/CD system (like GitHub Actions) runs a workflow.
23+
2. It issues a short-lived token.
24+
3. That token is sent to nuget.org.
25+
4. NuGet verifies it and returns a temporary API key.
26+
5. Your workflow uses that key to push the package.
27+
28+
![Screenshot that shows Trusted Publishing page.](media/trusted-publishing.png)
29+
30+
NuGet’s temporary API keys are valid for **15 minutes**, so your workflow should request the key shortly before publishing.
31+
If you request it too early, it might expire before the push happens.
32+
33+
Each short-lived token can only be used once to obtain a single temporary API key—one token, one API key.
34+
35+
This setup gives you a secure and automated way to publish packages, without the risks that come with long-lived secrets.
36+
37+
38+
## GitHub Actions Setup
39+
40+
To get started:
41+
42+
1. Log into nuget.org.
43+
2. Click your username and choose **Trusted Publishing**.
44+
3. Add a new trusted publishing policy. You’ll need to provide your GitHub org, repo, workflow file, and few other details.
45+
4. In your GitHub repo, update your workflow to request a short-lived API key and push your package.
46+
47+
Here’s a basic example:
48+
49+
```yaml
50+
jobs:
51+
build-and-publish:
52+
permissions:
53+
id-token: write # enable GitHub OIDC token issuance for this job
54+
55+
steps:
56+
# Build your artifacts/my-sdk.nupkg package here
57+
58+
# Get a short-lived NuGet API key
59+
- name: NuGet login (OIDC → temp API key)
60+
uses: NuGet/login@v1
61+
id: login
62+
with:
63+
user: ${{secrets.NUGET_USER}}
64+
65+
# Push the package
66+
- name: NuGet push
67+
run: dotnet nuget push artifacts/my-sdk.nupkg --api-key ${{steps.login.outputs.NUGET_API_KEY}} --source https://api.nuget.org/v3/index.json
68+
```
69+
70+
71+
## Policy Ownership
72+
73+
When you create a Trusted Publishing policy, you need to choose who owns it. The owner can be either:
74+
75+
- **You (an individual user)**
76+
- **An organization you belong to**
77+
78+
The policy will apply to all packages owned by the selected owner. That means it controls who can publish or modify those packages using Trusted Publishing.
79+
80+
If you choose an organization, make sure you're an active member. If you leave the org later, the policy may become inactive until you're added back.
81+
82+
Choosing the right owner helps ensure your publishing setup stays secure and aligned with your team’s structure.
83+
84+
85+
## Policies Pending Full Activation
86+
87+
Sometimes when you create a Trusted Publishing policy, it starts out as temporarily active for 7 days. This usually happens with private GitHub repos. You’ll see this status in the UI. During that time, it behaves like a regular policy. But if no publish happens within those 7 days, the policy automatically becomes inactive. You can restart the 7-day window at any time—even after it expires.
88+
89+
Why is this temporary period necessary? Because NuGet needs GitHub repository and owner IDs to lock the policy to the original repo and owner. That helps prevent resurrection attacks. Without those IDs, someone could delete a repo, recreate it with the same name, and try to publish as if nothing changed.
90+
91+
Once a successful publish provides the IDs (as part of GitHub’s short-lived token), the policy becomes permanently active.
92+
93+
94+
## Policy Ownership Warnings
95+
96+
Trusted Publishing policies are tied to a specific owner—either an individual user or an organization.
97+
If something changes with that ownership, the policy might become inactive. When that happens, you'll see a warning in the UI.
98+
99+
### Common cases
100+
101+
- **User removed from organization**
102+
If a policy is owned by an organization and the user who created it is later removed from that org, the policy becomes inactive.
103+
If the user is added back to the organization, the policy will be active again automatically.
104+
105+
- **Organization is no longer active**
106+
If the organization that owns the policy is locked or deleted, the policy becomes inactive.
107+
108+
These warnings help make sure that only active, secure policies are used when publishing packages.

0 commit comments

Comments
 (0)