jimmylewis
commented
3 months ago 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?
Reverts aspnet/LibraryManager#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