Why is there no 'dotnet nuget setApiKey' command?

[jamesqo]

I remember that before, I could write nuget.exe setApiKey XXX, and then do nuget push in a script without specifying my API key so other people couldn't see it in the script. Now, it's necessary to specify the API key as a parameter when you do dotnet nuget push, and there is no dotnet nuget setApiKey command. Is there a reason for this?

[PatoBeltran]

Hey @jamesqo thanks for your feedback. nuget.exe setApiKey was a simple command that only added the given api key (encrypted) to your nuget.config (which is read by the others nuget commands). There is no specific reason why it hasn't been ported to dotnet.exe. I will tag this issue as a feature request an send it to the backlog.

As a workaround you could use nuget.exe setApiKey (or set the values manually in your nuget.config and then use dotnet nuget push. dotnet.exe should read the nuget.config and use the api keys found there.

[dangershony]

FYI I had to go to \AppData\Roaming\NuGet\nuget.config and delete the previous key for the new key to take effect

[FlorianHockmann]

or set the values manually in your nuget.config

@PatoBeltran Is there any information on how the API key needs to be encrypted? What is used as the key to encrypt the API key?

[rrelyea]

I believe this might be similar to encrypting credentials...we don't have cross platform APIs for this available via Dotnet Core.

[FlorianHockmann]

So, it is really not possible right now to push NuGet packages to nuget.org on non-Windows platforms without Mono?

[lucastheisen]

@PatoBeltran ,

As a workaround you could use nuget.exe setApiKey (or set the values manually in your nuget.config and then use dotnet nuget push. dotnet.exe should read the nuget.config and use the api keys found there.

This does not appear to work. I tried:

nuget setApiKey <OMITTED> \
    -ConfigFile ~/.nuget/NuGet/Nuget.Config \
    -Source  https://pastdev.com/artifactory/api/nuget/pastdev-local

Verified it was added:

  <apikeys>
    <add key="https://pastdev.com/artifactory/api/nuget/pastdev-local" value="OMITTED" />
  </apikeys>

Then attempted a push:

bash-4.2$ dotnet nuget push artifacts/Pastdev.Cli.1.0.0.nupkg
error: Encryption is not supported on non-Windows platforms.

However, if i use use dotnet push -k

bash-4.2$ dotnet nuget push -k "<OMITTED>" artifacts/Pastdev.Cli.1.0.0.nupkg
info : Pushing Pastdev.Cli.1.0.0.nupkg to 'https://pastdev.com/artifactory/api/nuget/pastdev-local'...
info :   PUT https://pastdev.com/artifactory/api/nuget/pastdev-local/
info :   Created https://pastdev.com/artifactory/api/nuget/pastdev-local/ 502ms
info : Your package was pushed.

[zihotki]

Can confirm that it still doesn't work. Stumbled upon this issue and spent a lot of time trying to fix it without any good solution (-k option may work for command line but not for build scripts, api keys don't belong there).

[nojava4u]

Wow, one rabbit hole after another ... can't use apikeys for restore, only push; can't use the credentials for push only restore; apikeys can't be encrypted depending on platform; -k is only supported on push but not restore... in a CI/CD environment you end up with credentials AND apikeys in both your nuget.config AND your build/publish scripts... assuming you figure all this out.

[Caldas]

This is a mess, any plan for a real solution?

[NicolasDorier]

Please somebody fix this... :(

[another-guy]

I stumbled upon this github issue during my attempt to marry dotnet nuget to Azure DevOps. Is there any progress or update on this?

[NicolasDorier]

@another-guy I guess unless somebody can go to redmond and bang on the door of devs, nobody will look at it.

[jinweijie]

On Linux, the nuget version is quite old, not compatible with current nuget servers. So we have to use dotnet nuget push. But unfortunately, the setapikey is missing for the CLI, quite annoying. A workaround is to use environment variables, like:

dotnet nuget push ./nupkgs/*.nupkg -k $NUGET_AUTH_KEY -s https://api.nuget.org/v3/index.json

and in your .bashrc or .zshrc:

export NUGET_AUTH_KEY=oy12929292929292922....

[ckolumbus]

I'm using summon to inject all credentials as environment variables into the builds. Env variables work in most scenarios and summon helps me to keep secrets managed without the danger of accidentally committing them with my code.

[AraHaan]

I have a question, what encryption did setApiKey use exactly?

I could look into an implementation that could properly decrypt the keys if possible.

[loic-sharma]

@AraHaan API keys are encrypted using Windows Data Protection API: https://docs.microsoft.com/en-us/dotnet/standard/security/how-to-use-data-protection

This only works on Windows and is not supported by macOS or Linux. We may be able to draw inspiration from how Chrome encrypts cookies on macOS and Linux.

[smarts]

I believe this might be similar to encrypting credentials...we don't have cross platform APIs for this available via Dotnet Core.

@rrelyea regarding cross-platform APIs in .NET Core, can NuGet use the credential store implementations here?
i.e., Windows cred manager, macOS keychain, secret service (libsecret) on linux-based OSes

Of course, I understand if the setApiKey command on Windows has to stick to what it does currently, but does it need to work exactly that way across all platforms? IMHO having something (even if it's different than Windows) is better than having nothing.

[AraHaan]

I agree, I feel like the keys should be stored in the credential store instead, on iCloud Keychain (on MacOS), or on the secret service on other *nix based OS's. For those without any of the 3, I would then fallback to throwing saying they need a way to store credentials securely.

Alternatively one could use encryption apis like BlowFish to secure the keys that has a cross platform implementation as well. I could see if I can propose for one in the BCL (if it does not have a BlowFish encryption class already that is) and the best part is it works for all OS's in a single go so is portable. Although I would encrypt it in a way with randomly generated keys so it can be secured.

Although if it was me, I would encrypt it in multiple different algorithms and passes so it would be harder for bad people to get the api key.

[smarts]

@AraHaan does iCloud keychain work when disconnected from the internet? Because I'm fairly confident that's a necessity.

[silkfire]

Is there the inverse of this command? How does one go about removing an API key programmatically? From a security perspective it would be good for credentials not to linger longer than necessary after they’re no longer needed.

[AraHaan]

@AraHaan does iCloud keychain work when disconnected from the internet? Because I'm fairly confident that's a necessity.

I think it stores a local copy of it yes.

[zivkan]

I created a spec for a dotnet nuget apikey set command: #12321

Anyone interested, please have a look and provide feedback

[zivkan]

I created the following issue, which I think would be a better alternative for most customers (anyone pushing in a CI script) than this proposed dotnet nuget apikey command:

• Get push API key from environment variable #12539

If you like the idea, please upvote (add a 👍 reaction) to that issue, so we can prioritize the order to work on these new features.

[nhoefer2]

I want to add my voice to this issue as I'm also significantly affected by the absence of the dotnet nuget setApiKey command in the dotnet CLI. It's been quite frustrating trying to securely automate the pushing of NuGet packages to our private repository from within Jenkins builds that run in Docker containers on Linux.

The lack of this feature makes it challenging to handle API keys securely in a cross-platform CI/CD environment. Workarounds often involve insecure practices like exposing API keys in scripts or configurations, which is far from ideal.

Performing these tasks on Linux should not be so difficult, especially given the widespread use of Linux in build environments and the push towards cross-platform development. Better support for secure credential management in the dotnet CLI on non-Windows platforms would greatly improve developer productivity and security.

I hope this issue can be given higher priority, as it impacts many in the community who rely on automated, secure, and cross-platform build processes.