Credentials not sharable via a common nuget.config file, errors with: Key not valid for use in specified state.

[vihoti]

Details about Problem

Hello,

I create a nuget.config file with a user account with which our build server runs as. Our NuGet repository is an Artifactory server. Pushing/listing to/from the repository works fine when using the nuget.config file with the account with which it was created.
However, if I want to share this 'common' nuget.config file with other colleagues, so that we all use the same file, an error is thrown by nuget.exe: Key not valid for use in specified state. (see verbose output below).

This causes us some problems in that we need to allow anonymous access to all our Nuget repositories in Artifactory, which, in some cases, we do not want.

I wanted to ask if someone can please explain this behaviour? Is this intended behaviour? Is there a workaround or solution to this issue? I tried googling this but search results were not very fruitful.

NuGet.exe version 4.7.1.5393.
OS version Win10.

Steps to reproduce

1. Create a nuget.config file:

• nuget sources Add -Name Artifactory -Source https://artifactoryserver.int/api/nuget/nuget-repo -username user1 -password user1apikey

• nuget setapikey user1:user1apikey -Source Artifactory

2. Give the created nuget.config file to another user.

3. Let the user try to push a .nupkg file: nuget push test_pkg.nupkg -Source Artifactory

4. Push fails with error: Key not valid for use in specified state.

Verbose Logs

.\nuget.exe push .\test.nupkg -source Artifactory -verbosity detailed
NuGet Version: 4.7.1.5393
Key not valid for use in specified state.
System.Security.Cryptography.CryptographicException: Key not valid for use in specified state.

at System.Security.Cryptography.ProtectedData.Unprotect(Byte[] encryptedData, Byte[] optionalEntropy, DataProtectionScope scope)
at NuGet.Configuration.EncryptionUtility.DecryptString(String encryptedString)
at NuGet.Commands.CommandRunnerUtility.GetApiKey(ISettings settings, String endpoint, String source, String defaultApiKey, Boolean isSymbolApiKey)
at NuGet.Commands.PushRunner.<>c__DisplayClass0_0.b__0(String endpoint)
at NuGet.Protocol.Core.Types.PackageUpdateResource.d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at NuGet.Commands.PushRunner.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at NuGet.CommandLine.PushCommand.d__32.MoveNext()

[zivkan]

@vihoti To provide some security for secret values, NuGet uses the ProtectedData.Protect API to encrypt the password/apikey, but this uses a per-user encryption key, so will not work for other users, even on the same machine.

I recommend each developer edit their profile NuGet.config file (%APPDATA%\Roaming\NuGet\NuGet.config on Windows, ~/.nuget/NuGet/NuGet.config on Linux/Mac) and store their credentials in the packageSourceCredentials or apikeys sections. It's a once off configuration per developer, but it minimises the risk of accidentally oversharing secrets like passwords or api keys.

[nkolev92]

Closing as by design.

[gkalnytskyi]

@nkolev92, I'm trying to understand why this important piece of information: "NuGet uses the ProtectedData.Protect API to encrypt the password/apikey, but this uses a per-user encryption key, so will not work for other users, even on the same machine." --- was omitted from the help page https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-sources .

Another point is how you propose to setup the CI process to have access to private Nuget repository when developers don't have access to build agents? Does Microsoft suggest to store password in clear text in Nuget.config as suggested here? Or Credentials provider is "the way" as described in #6486?

Company I work for uses Sonatype Nexus 3 as centralized package storage. Each system has its own set of repositories which are private and require authentication to access. The build agents are hands-off, so only dev support team can update them. Because, Nexus 3 repositories require username/password to access you need to store them somewhere. Storing password in plain text in the repository, in my opinion. defeats the purpose of having private repositories.

In addition, I don't see an option to pass Username/password for repositories in dotnet restore command (link), in case I stored these setting securely in some other place.

[nkolev92]

@nkolev92, I'm trying to understand why this important piece of information: "NuGet uses the ProtectedData.Protect API to encrypt the password/apikey, but this uses a per-user encryption key, so will not work for other users, even on the same machine." --- was omitted from the help page https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-sources .

If you look at the note in https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-sources#options, you will see exactly that.

Another point is how you propose to setup the CI process to have access to private Nuget repository when developers don't have access to build agents? Does Microsoft suggest to store password in clear text in Nuget.config as suggested here? Or Credentials provider is "the way" as described in #6486?

The feed provider is the one that has the ability to integrate with a plugin. That is how Azure DevOps handles auth.

[gkalnytskyi]

@nkolev92, thanks for pointing out the note, sorry I missed it.

The feed provider is the one that has the ability to integrate with a plugin. That is how Azure DevOps handles auth.

I'm not sure what you mean here, but I'll be waiting for this piece of documentation to get more clarity.

[nkolev92]

@gkalnytskyi

In my personal opinion, it'd be nice if the feed provider, in your case sonatype nexus, writes a plugin...their plugin can create limited scope tokens and they can require auth in any way they see convenient.

Note that encrypted pats are usually going to be machine specific and this applies to more than just NuGet.

[gkalnytskyi]

Thank you, @nkolev92! I'll forward your suggestion to our team that maintains Nexus, so that they could talk to Nexus reps directly.