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

Revert "Use consolidated nuget feed" #731

Closed
wants to merge 2 commits into from
Closed

Conversation

jimmylewis
Copy link
Contributor

Reverts #714

This change caused permissions issues when non-Microsoft users attempt to restore the solution. I was able to reproduce this on my personal (non-MSFT) device, and the restore worked after reverting the change.

It would also be a blocker for proposing a new package or package version, as users not authorized with the ADO feed would not have rights to promote new packages into the consolidated feed. The main security issue with multiple feeds is described at https://learn.microsoft.com/en-us/nuget/consume-packages/package-source-mapping. As long as each package is only requested from a single specific feed, it avoids the risk of a supply chain attack where a package from a one feed is maliciously faked on another feed, so since we previously had packageSource configured for each package, this should not be a concern (also, because we don't use nuget.org, all of these feeds should already be secured).

I doubt that reverting this change will solve the issue of proposing a new package version, as an unauthorized user still won't have permissions to promote packages to the dotnet-public feed either. But at least this should address the restore problem.

Addresses #728

The msft_consupmtion feed does not retail older package versions, so the
build dependencies that were once there are no longer.
@jimmylewis jimmylewis closed this Mar 25, 2024
@jimmylewis
Copy link
Contributor Author

I'm currently able to restore fine with the libman feed, so no need to do this. Reverting the original change failed with some packages no longer available in the source feeds (for Apex and the Web.Editors packages), but succeeded locally because I still had those in my local cache.

I do worry that a future dotnet servicing update may cause some implicit versions (e.g. for the core SDK packages) to get bumped, and then there isn't a way for an external user to restore without being able to ingest the right versions in the feed. For example, in #728 the reported failure is in Microsoft.NETCore.App.Host.osx-x64 version 6.0.27; the libman feed contains 6.0.22, and updated versions for 8.0.2 and 8.0.3. When the sdk servicing bumps that to 8.0.4, what's the recourse?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant