Skip to content
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

Recommend using NuGet v3 repositories for Nexus and Artifactory #887

Open
9 tasks
pauby opened this issue Nov 17, 2023 · 1 comment
Open
9 tasks

Recommend using NuGet v3 repositories for Nexus and Artifactory #887

pauby opened this issue Nov 17, 2023 · 1 comment
Labels
0 - Backlog Issue is accepted, but is not ready to be worked on or not in current sprint Documentation Issues for changes that only need to change documentation

Comments

@pauby
Copy link
Member

pauby commented Nov 17, 2023

What New Or Updated Would You Like To See?

After investigating an issue raised regarding NuGet v2 repository types in Sonatype Nexus and JFrog Artifactory, we found there was a bug in the API responses. This bug is not present in NuGet v3 repositories. I updated the issue with this information.

Oridnarily we'd suggest raising issues with the repository managers directly. However, with NuGet v2 repository support being reduced / deprecated in Nexus and Artifactory, there's unlikely to be much traction in those being fixed. Other repository managers are likely to follow.

To ensure customers and community have the maximum lifespan from their repositories, we should ensure NuGet v3 repositories are recommended in documentation and other communications.

When troubleshooting a NuGet v2 repository issue we should ensure it can be reproduced in a NuGet v3 repository.

The list below is the work that needs to be done but is not an exhaustitive list. As we find more we will update it:

  • Ensure the Quick Start Environment deploys a NuGet v3 repository.
  • Ensure Chocolatey For Business Azure Environment deploys a NuGet v3 repository.
  • Ensure Chocolatey For Business Ansible Environment deploys a NuGet v3 repository.
  • Ensure any scripts in our documentation setup a NuGet v3 repository.
  • Ensure that any recommendations we make about repository types in our documentation is for a NuGet v3 repository.
  • Ensure when we talk about caching repositories that we make it clear, and reference the souce, that tere may be issues with a NuGet v2 caching repository.
  • Where we talk about internalization, we should ensure it makes it clear that this issue does not affect internalized packages.
  • Produce a migration plan, from NuGet v2 to NuGet v3 repository types, for customers and community.
  • Write a blog post announcing this change to ensure as many customers and community are aware.
@pauby pauby added Documentation Issues for changes that only need to change documentation 0 - Backlog Issue is accepted, but is not ready to be worked on or not in current sprint labels Nov 17, 2023
@pauby pauby changed the title Rwcommend using NuGet v3 repositories for Nexus and Artifactory Recommend using NuGet v3 repositories for Nexus and Artifactory Nov 17, 2023
@TheCakeIsNaOH
Copy link
Member

Our suggestion would be to use Chocolatey CLI with NuGet v3 repositories when using Sonatype Nexus or JFrog Artifactory, if you are seeing these issues.

What is the suggested path for users on Nexus that are proxying CCR?

As Nexus can't mix v2 and v3 feeds when a proxy feed is in the mix. So if I have a chocolatey-hosted hosted repository, a ccr-proxy proxy repository to the ccr v2 api, and a chocolatey-group group repository which includes both chocolatey-hosted and ccr-proxy, there is no v3 feed from chocolatey-group, as Nexus would only provide a v2 feed.

For some users, switching to adding both the chocolatey-hosted and ccr-proxy on client systems would work. That would allow using the v3 feed on the chocolatey-hosted repository.

However, because source priority on Chocolatey CLI is broken, this direct usage wouldn't work for users internalizing or modifying packages (like me). This is because there would be no guarantee that Chocolatey CLI/GUI would pull internalized or modified internal packages on the chocolatey-hosted repository, instead of using the non-internalized/modified version from CCR being used. This would open users to security issues where the wrong packages could be installed in a very similar manner to dependency confusion. When setting the priority in a Nexus group repository, it does work correctly in my testing, so it is not problematic for Nexus group repositories.

Here are some potential solutions:

  • Fix Chocolatey CLI source priority
  • Add a v3 API to CCR
  • Get Sonatype to fix the Nexus bugs with their v2 implementation (which is unlikely as mentioned)
  • Get Sonatype to add a feature to allow mixing v2 and v3 repositories in groups (or more specifically accessing a group repository with v3 while a v2 proxy is in the group)
  • Move away from recommending Nexus as a good option for open source/pro users (C4B users can still use Nexus with hosted repositories only, using the download/internalization pipelines to update the hosted repository)
  • Move downloading (and maybe internalizing packages) to open source, and recommend users purely use hosted repositories and setup a CI to manually download from CCR and push to their hosted repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 - Backlog Issue is accepted, but is not ready to be worked on or not in current sprint Documentation Issues for changes that only need to change documentation
Projects
None yet
Development

No branches or pull requests

2 participants