NuGet.org login authentication workflow for dotnet nuget push
#10658
Conversation
|
The PR title "first draft" is really unhelpful. |
Oops, I didn't realize that's what the title became, must have made a mistake somewhere 😅 Thanks for the pointer! |
chrisraygill
changed the title
dotnet nuget push
| 2. Login to NuGet.org using MSA. | ||
| 3. Create an API key with the correct permissions/scope. Beginners will be presented with potentially overwhelming options and technical terms like expiration time, scope, unlist, and glob pattern. This is complicated enough, we have an entire [doc on how to do it securely](https://docs.microsoft.com/en-us/nuget/nuget-org/scoped-api-keys). | ||
| 4. Either store the API key securely. Beginners will need to do research on how to do this or may insecurely store the API key in plaintext. The best way to do this in Windows is with `nuget setapikey`, which currently has no support on MacOS or Linux. | ||
| 5. Push the package using the very long `dotnet nuget push <package id> --api-key <api key> --source https://api.nuget.org/v3/index.json` command, which is unlikely to figure out without copying from docs. |
There was a problem hiding this comment.
You really shouldn't do this. You're leaking your API key in plaintext. Remember that most operating systems store your command history to disk (like the .bash_history file).
The nuget setapikey is nominally better as you only need to leak your key once...
There was a problem hiding this comment.
Which part, number 5?
There was a problem hiding this comment.
Sorry, I meant that you should avoid providing the --api-key through the dotnet nuget push command.
|
Ideally use oauth / sign into a NuGet / MSFT account via a link in the CLI which upon callback will authorize & allow a user to push. This would effectively "login" the user to the NuGet account & upon further package management operations can be used as an identity source. In an ideal world, this would effectively mean that two newly introduced commands are needed such as |
| <!-- What other designs have been considered and why weren't they chosen? --> | ||
| <!-- What is the impact of not doing this? --> | ||
|
|
||
| ## Prior Art |
There was a problem hiding this comment.
also consider https://github.com/Microsoft/artifacts-credprovider as prior art. This is Azure Artifact's NuGet credential provider, and I believe already does what this proposal is about, just for Azure Artifacts URLs, rather than nuget.org.
|
|
||
| ## Motivation | ||
|
|
||
| 1. API keys can be a pain to use in many circumstances, especially for beginners. To securely upload a package to NuGet.org via the CLI you need to: |
There was a problem hiding this comment.
Do you think it would be useful to run usability studies on our current nuget push flow to validate this hypothesis?
| 4. Either store the API key securely. Beginners will need to do research on how to do this or may insecurely store the API key in plaintext. The best way to do this in Windows is with `nuget setapikey`, which currently has no support on MacOS or Linux. | ||
| 5. Push the package using the very long `dotnet nuget push <package id> --api-key <api key> --source https://api.nuget.org/v3/index.json` command, which is unlikely to figure out without copying from docs. | ||
| 2. Alleviate pain for authors who are frustrated by expiring API keys. | ||
| 3. Reduce risk of simple mistakes with API keys that lead to security vulnerabilities such as accidental leaks to a public repo or storing the API in plaintext to avoid hassle. |
There was a problem hiding this comment.
This sounds like it is a nice to have. It's really not, we have a rampant API key leak problem. Can/should we spice this up?
I know this is a public spec, but could we add how many API leaks we've detected in the past year to help quantify this problem?
|
I would prefer the --api-key to die out in favor of an |
|
@AraHaan That is an interesting idea. That is something we should definitely consider, especially for the CI scenarios. However, the primary motivation for this spec is to avoid API keys altogether in interactive scenarios as:
|
|
Any volunteers who would like to take this proposal up to get it merged? |
Proposal to create a workflow to push to NuGet.org via the
dotnet nuget pushcommand by NuGet.org account login in the CLI or the browser.Issue: #10657