dotnet list package --vulnerable requires constant login to 3rd party nuget feed

[ChristophHornung]

NuGet Product Used

dotnet.exe

Product Version

.NET SDK 7.0.200

Worked before?

No response

Impact

It's more difficult to complete my work

Repro Steps & Context

On calling dotnet list package --interactive --vulnerable I have to constantly sign in via the web browser for an internal nuget feed.

Without the --vulnerable switch it seems to use my cached login and I don't even need to login once.

Expected behavior:

I would expect to login at most once for the command to finish.

Log Output: log.txt

Verbose Logs

No response

[kartheekp-ms]

Azure DevOps doesn't support marking packages as vulnerable or deprecated like nuget.org does. There are feature requests for Azure DevOps team to support these features.

• https://developercommunity.visualstudio.com/t/Publish-deprecated-and-vulnerable-packag/10094621
• https://developercommunity.visualstudio.com/t/Vulnerability-report-for-upstream-pack/596311
• https://developercommunity.visualstudio.com/t/Mark-packages-as-deprecated-in-Azure-Art/1267756#T-ND10299217

To prove that AzDo doesn't support vulnerable packages yet, I tried following steps.

• Created a sample class library project
• Added nuget.org and an Azure DevOps feed as package sources
• Both these sources have Newtonsoft.json package.

• 12.0.3 version of the package is marked as vulnerable in nuget.org but not on Azure DevOps feed.

  VS displays the package version as vulnerable for nuget.org package source.

VS doesn't display the package version as vulnerable for Azure DevOps feed because they don't support package vulnerability metadata.

I am closing as not a bug. Please feel free to reopen this bug if you think otherwise.

[ChristophHornung]

@kartheekp-ms I think you misunderstood. The issue is not about azure devops or their support for vulnerable packages.

This issue is about dotnet list package constantly requesting a login if a private feed is added as a package soruce. That feed for me does not contain any official packages, just private ones. I additionally have nuget.org as a package source.

So to replicate:

• Create a few projects in a solution
• Add both nuget.org and a private feed (e.g. azure devops nuget) in the NuGet.Config
• Run dotnet list package --interactive --vulnerable

Expectation: Should request a login only once.

Reality: Requests a login for every project again and again.

It seems to be a variant of a similar bug as described in #12077 Can you please reopen this issue?

[kartheekp-ms]

(Reopening the issue because the customer has a follow-up question)

I forgot to mention one statement in my previous response. In general, NuGet retries HTTP requests 3 times when the response is not 200 (there are few cases this retry count may vary, I don't remember all of them now). Given that the feed is private the server challenges for credentials (401 response) for the first request. NuGet then invokes Credential Provider with IsRetry=False to obtain credentials. With IsRetry=False, Credential Provider returns the session token from the cache. When NuGet sends this token to the private feed then authentication succeeds but feed does not provide the necessary information because of the feature limitation. Now NuGet retries that request with IsRetry=true. With this setting, Credential Provider clears the cache and provides you with a device login information to authenticate with the feed. The response still may not have the correct information. I think this explains why NuGet requests a login for every project again and again. That is my understanding for now. We explained the credential provider behavior in https://github.com/NuGet/Home/issues/11210#issuecomment-1132240645 if you are interested to learn more.

Given that we already fixed https://github.com/NuGet/Home/issues/12090 issue, I assume NuGet retry logic is causing these authentication prompts because the vulnerability information is not present in the feed.

I will try to reproduce the issue sometime next sprint following the steps mentioned in above comment and validate my assumptions.

I additionally have nuget.org as a package source.

Given that you have a combination of public and private NuGet feed in NuGet.Config file, I highly recommend onboarding on to Package Source Mapping feature as per the best practices. This feature also reduces the restore time because the sources are queried for packages only if configured correctly.

[cremor]

@kartheekp-ms Could you please give an update about this bug? The explanation you gave in your last comment makes sense, but have you confirmed it?

edit: Or maybe not. According to your explanation only dotnet list package --vulnerable/deprecated should be affected. But I also get the same problem with dotnet list package --outdated.

I'm also running into this problem right now with the current SDK version (7.0.302). I already use Package Source Mapping like you suggested in your comment, but I don't see how this helps in this case. I still always get a login request when running a dotnet list package --vulnerable/deprecated/outdated command.

Is there any workaround available?

Example of my NuGet.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="mysource" value="https://pkgs.dev.azure.com/myorg/_packaging/mysource/nuget/v3/index.json" />
  </packageSources>

  <packageSourceMapping>
    <packageSource key="nuget.org">
      <package pattern="*" />
    </packageSource>
    <packageSource key="mysource">
      <package pattern="somepackage" />
      <package pattern="myprefix.*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

[cremor]

@kartheekp-ms Any news on this bug?

For now, I have to use a user-specific NuGet.config file (in %appdata%\NuGet\config\) that contains the packageSourceCredentials (Azure DevOps access token).

[ZhekaZeh]

Idk if this issue still valid here, but in case you have dotnet restore successful but separate dotnet commands like "dotnet list package vulnerable" failing with 401, there seems to be a solution.

Use this authentication task prior to the analysis.

- task: NuGetAuthenticate@1 inputs: forceReinstallCredentialProvider: false More info is at: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/nuget-authenticate-v1?view=azure-pipelines

[cremor]

@ZhekaZeh This bug is about calling dotnet list package locally (not in a build pipeline).

[nimro]

I'm seeing the same behaviour, when an Azure DevOps Artifacts feed is configured, dotnet list package --vulnerable requires authentication seperately for every project in the solution. As well as being tedious, it creates a lot of unnecessary PATs in Azure DevOps.

dotnet restore works with the cached credentials and doesn't re-auth, so this does look like a bug in dotnet list package.

[nimro]

Also, FWIW, I see this behaviour on both Linux and Windows so it doesn't appear to be environmental in origin.

[kartheekp-ms]

Duplicate of https://github.com/NuGet/Home/issues/11210. Please refer to the linked issue for updates on this bug.

[kartheekp-ms]

My apologies for closing this issue as a duplicate of #11210. Upon further investigation, I found that they are unrelated. Hence reopening this issue.

[cremor]

@kartheekp-ms Thanks for fixing this! Which version will include the fix?

[kartheekp-ms]

@cremor - This fix will be part of preview versions of the .NET 8 SDK (especially 8.0.3xx and above) that can be downloaded from GitHub. If you want this fix in the previous LTS versions of the .NET SDK, please upvote this comment and also let us know which version of the SDK you are interested in getting this fix.

[ciarancolgan]

Hi @kartheekp-ms, this is definitely not fixed for me using the latest .NET 8.0.400 SDK. I have exactly the same scenario as described in this issue:

• 2 package feeds; nuget.org and a private cache one in ADO

• dotnet restore works fine, the various dotnet list package --<XX> commands all fail with a 401. I understand that i can add a PAT token to my package source in the nuget.config but I dont want to as that makes the CI/CD pipeline more complicate than it should be. So - is this issue not actually fixed or am I missing something? Thanks!