Get push API key from environment variable

[zivkan]

NuGet Product(s) Involved

dotnet.exe

The Elevator Pitch

When someone wants to push a package, particularly in a CI or deployment script, they don't want secrets like API keys to be used on the command line or output to logs. At the time of writing this feature request, the dotnet CLI doesn't have an equivalent of setapikey, but even if it did, it would require the API key to be passed on the command line. Additionally, API keys currently can only be encrypted, and dur to NuGet using .NET's ProtectedData API, which is Windows only, it also means that this doesn't work on Linux or Mac.

While we have issues for all the above limitations, I believe the need for most of those other work items will be significantly reduced if push itself could read the API key from an environment variable. Since API key is only used for push, not restore or other actions, there often isn't a benefit (at least in a CI script) to store the apikey in a nuget.config file. So, we can eliminate one extra step from customer's scripts if push can read the environment variable directly.

Proposal: Add a `--use--environment-variable` argument to `dotnet nuget push`, which when used will treat the values provided to `--api-key` and `--symbol-api-key` as envionrment variable names, rather than as the secret values.

Therefore, an example usage would be:

dotnet nuget push *.nupkg --use-environment-variable --api-key NUGET_ORG_API_KEY

Thanks to @AraHaan for the better idea below:

Push should prefer --api-key and --symbol-api-key, if provided. If not provided, try to get a saved API key from nuget.config (all of this is existing behaviour). Finally, if an API key is still not found, get the environment variable NUGET_API_KEY and NUGET_SYMBOL_API_KEY.

Additional Context and Details

Relevant other issues:

• nuget source password encryption story #1851
• Environment variables in setapikey #7145
• Allow unecrypted API keys in nuget.config #12354

[zivkan]

`--use-environment-variable` is a very long argument name, which is bad since it's easy to typo (even if customers use tab completion on their command lines, when writing scripts you probably won't have tab completion).

Is --use-env-var ok? Normally it's not good to use contractions and abbriviations, unless very well known. Is env for environment and var for variable ok?

irrelevant if we just use hardcoded environment variable names. If there are customers who push to multiple feeds and need different API keys find this difficult to work with, they can give us feedback after the hardcoded variable names feature ships.

And in full transparency, this comment had two 👍 reactions before I edited this comment.

[AraHaan]

Or better yet, skip adding a switch to tell it to use environment variables and jump right straight into expecting that --api-key be optional instead and have it automatically pick it up as NUGET_API_KEY and NUGET_SYMBOL_API_KEY respectively (and hard coded as those names on lookup when it sees that --api-key was not passed into the command and it not being in the nuget.config file).

This not only works cross-platform, but also works without ProtectedData which is windows only.