-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DotNetCore currently does not support using an encrypted Api Key #7160
Comments
Can you detail what you mean by "exposing API key"? Something in a log? Something else? |
@bryanmacfarlane everyone who can read build definition can read the API key. Previously I used NuGet Publisher task, that allowed to pick a preconfigured connection, which would store credentials on the VSTS side. The new dotnet task + nuget push command also allows to pick the same connection, however it fails with the error above. |
If you put the secret in a variable on the variables tab and click the lock, it puts it in a strong box encrypted and readers of the definition can't read it. It's set once. At run time the service will include it in the encrypted job message to the agent and the agent will only make it available to that task. |
@bryanmacfarlane I guess it is a valid workaround. The issue with failing build when configuring dotnet nuget push task for external feed using managed credentials still worth addressing. |
Using an ApiKey is currently not supported in dotnet because the required libraries for encrypting the key are not available, sorry for the inconvenience. You should be able to use a service endpoint configured with a username/password combination. If you can only use an ApiKey, I would suggest using the nuget 2.* task to push. |
Using the NuGet task is the correct workaround here, as @aldoms recommends. We're currently working |
This does not work for us either. |
We must be able to do this through managed external feeds. |
I moved to the NuGet task like recommended by @aldoms and @alexmullans |
The NuGet task can also publish symbols - you just need to remove the |
Ok, I already tried that, but I tried it with TFS. But now I realize this is a restriction of TFS. So you're saying this works with the official NuGet.org? Ok, I'll give that a try. Thanks! |
Closing this due to age and inactivity. |
Why did we close this ticket? The issue is still a valid issue that should get fixed. If you offer a "service" and the "service" doesn't work, then it is a bug and should be fixed one way or another. You can initially offer workarounds, but you should be actively fixing the issue and not just closing it. |
That reply did not solve the issue he was having and now I am having it. It was unprofessional to close this ticket! |
@SpyderHunter03 @ScottyMac52 sorry for the closure, was in a triage pass trying to get a handle on our (substantial) bug count in this area. You're right that we should not have closed this. Since we last updated the .NET Core task's NuGet functions ( |
…ms we can't use an Api key. (microsoft/azure-pipelines-tasks#7160)
Well, this is biting me, too. Pain started, when I wanted to push my nuget package with symbols. Learnt, that the preferred way is the First try, using the nuget task (version 2.*):
Okay, the nuget task is using an outdated nuget.exe. Well, there is
😠 , well, let's do this as a custom task and write the API Key into the params... But:
WTF? copying and pasting the command into a shell works like a charm. So what's going on, at least the last one should work. Sure, I could run a bash script, but this cuts the possibility to use the globbing feature 😢 updateputting a manual Nuget installer task and version 5.1.0 solved the first try |
@marcwittke , in order to fix this please make sure your task looks like this - task: DotNetCoreCLI@2
displayName: Push Nuget Package
inputs:
command: custom
custom: nuget
arguments: >
push $(Build.ArtifactStagingDirectory)/*.nupkg
-s $(NuGetSourceServerUrl)
-k $(NuGetSourceServerApiKey) But yeah, still duplication is needed (nupkg/snupkg), unfortunately :( |
It should also be noted that the |
Any ETA, when we can expect a proper solution to this issue? |
This issue is open now for 531 days, 12 hours, 10 minutes and 23 seconds and there is still no solution? At least throw us an explanation of why it takes so long? |
Previously we were deploying our reusable NuGet packages using the `dotnet nuget push` command, which is idiomatic for .NET Core but [apparently does not support](microsoft/azure-pipelines-tasks#7160) Azure DevOps pipelines' usage of encrypted API keys. This works around the issue by using the legacy `NuGet` client, which is able to consume the encrypted API key. 🔄 Original Commit: https://github.com/foxguardsolutions/Pump/commit/ca55d0b5916db79cf0426bad05188c53222a3420
Hi @Postlagerkarte - sorry for the delay, but I think we do have a solution to your original issue now. We have recently released the NuGetAuthenticate task that can be used in a pipeline to authenticate with Azure Artifacts and/or other NuGet repositories. The design philosophy behind this task is that we would authenticate all the repositories you describe in this task, and get out of the way leaving you fully in control of running your nuget or dotnet commands in the pipeline as you see fit. You can read more about the NuGetAuthenticate task here. It also gives some examples on how to configure the task. In your case, you can create a service connection to nuget.org and add the NugetAuthenticate task at the start of your pipeline with this service connection as input. After that you can add just a regular powershell task to run Aasim |
This is not really a sastisfying solution to the issue. I expect the dotnet commands to work just like on my own machine. Having to use workarounds is quite annoying. |
@aasim That is not correct. The docs state that task also doesn't support service connections using API keys. We basically have to do this. |
@aasim as mentioned by @MarkKoz, NuGetAuthenticate task does not support API key, I am getting the error below while using this task.
|
I can confirm that the NugetAuthenticate task doesn't support APIKeys still. |
So many hoops to jump through just to use a private NuGet feed. So I if I need to build a project that uses X private feeds I'll need to add X tasks like the one above(using restore instead of push)? That seems slow and bloated. |
2 years later and no progress on this. Is this on any roadmap to be addressed? |
Workaround Azure Pipelines deficiency: microsoft/azure-pipelines-tasks#7160
So, you post an article from 8/2019 and then simply close the issue? That's
really poor customer service!
…On Mon, Jun 22, 2020, 9:24 AM Edgar Ruiz ***@***.***> wrote:
Closed #7160
<#7160>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7160 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKNOFHDI2ZLICDEDJYO4UDRX6AVHANCNFSM4E65YI2Q>
.
|
Are we to assume that this will never be addressed now that the issue is
closed?
EDIT: Sorry, didn't mean to reply to @ScottyMac52.
|
That certainly was my reasonable assumption.
On Mon, Jun 22, 2020, 2:31 PM Justin Skiles <notifications@github.com>
wrote:
… Are we to assume that this will never be addressed now that the issue is
closed?
On Mon, Jun 22, 2020, 12:46 PM Scott McIntosh ***@***.***>
wrote:
> So, you post an article from 8/2019 and then simply close the issue?
That's
> really poor customer service!
>
> On Mon, Jun 22, 2020, 9:24 AM Edgar Ruiz ***@***.***>
wrote:
>
> > Closed #7160
> > <#7160>.
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <
>
#7160 (comment)
> >,
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKNOFHDI2ZLICDEDJYO4UDRX6AVHANCNFSM4E65YI2Q
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#7160 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAUY4X4ZS4HGGEVQSAOCG6LRX6DHHANCNFSM4E65YI2Q
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7160 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKNOFDV7P4KGQLA6TNR7U3RX7ES7ANCNFSM4E65YI2Q>
.
|
The nuget solution has been posted over and over. Closing this by saying "ignore this bug, use another method" is a really shitty decission. |
@edgarrs this workaround is the only one that actually works. But it can't be used for CI easily, as you have to know the package version in advance to find the The proper fix would be to: |
Again, this issue is closed but the bug is still here? |
I confirm - the issue is still there. Unfortunately, it's affected my customer. But using NuGetCommand@2 instead of DotNetCoreCLI@2 solved the problem. But I think it is not a solution, just a workaround. |
August, 2021 and the issue still exists. It's horrible that you believe sparsely documented workarounds is a satisfactory solution. Instead you are satisfied to let poor slobs like me waste HOURS fumbling through posts like these to try and find an answer. Shame on you MS! |
Nobody is going to check on this issue as it's closed. |
I created a new issue for the same problem: #15569 |
One thing to note on this workaround - if you are on a windows agent, the slash before *.nupkg has to go the other way. |
Problem: can't push packages to nuget.org with dotnet nuget push task without exposing API key in build definition
Environment
Error logs
Using authentication information for the following URI: https://api.nuget.org/v3/index.json
Error: DotNetCore currently does not support using an encrypted Api Key.
Packages failed to publish
The text was updated successfully, but these errors were encountered: