NuGet private registry authorization fails with "Access denied" error

I am trying to setup a Windows build with access to the GitHub Package Registry, specifically for NuGet packages. When you attempt to authorize the registry as documented [1] and pasted in here, an Access denied. error occurs…

nuget sources Add -Name "GPR" \
     -Source "https://nuget.pkg.github.com/OWNER/index.json" \
     -UserName USERNAME -Password TOKEN

Running this with the -Verbosity detailed flag yields the error:

Access is denied.
System.Security.Cryptography.CryptographicException: Access is denied.

   at System.Security.Cryptography.ProtectedData.Protect(Byte[] userData, Byte[] optionalEntropy, DataProtectionScope scope)
   at NuGet.Configuration.EncryptionUtility.EncryptString(String value)
   at NuGet.Configuration.PackageSourceCredential.FromUserInput(String source, String username, String password, Boolean storePasswordInClearText, String validAuthenticationTypesText)
   at NuGet.CommandLine.SourcesCommand.AddNewSource()
   at NuGet.CommandLine.Command.ExecuteCommandAsync()
   at NuGet.CommandLine.Command.Execute()
   at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args)

I was able to work around this by adding the -StorePasswordInClearText flag, which avoids this codepath, but am confused as to why I need to do that in the first place.

Is there some configuration available to me that allows the use of these cryptographic functions in the CircleCI environment?

[1] https://help.github.com/en/github/managing-packages-with-github-package-registry/configuring-nuget-for-use-with-github-package-registry#authenticating-to-github-package-registry

I think this falls into a general category of things that you cannot do because there is no concept of sudo in powershell or cmd.exe. I’ve been struggling myself with this type of issue.

I am curious if anyone has any suggestions for a good way to replicate sudo in a windows world.

1 Like

Is there any workaround for this kind of sudo/windows agent issue? I’m facing the same problem, the same exception is thrown by some Redgate DB deployment PowerShell cmdlets I wanna use.

An ugly workaround is to use the -StorePasswordInClearText flag when adding the source.