Secure Supply Chain Analysis reports NuGet.config with multiple feeds
The Secure Supply Chain Analysis task can end up reporting:
##[warning]NuGet.config - Multiple internal feeds declared, potentially with upstreams.
which fails the build. Example build: https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=11081747&view=logs&j=ab190067-517a-5a94-c757-daef7ad8d495&t=3ff1dbf3-85af-5f2c-161b-1482dd46be87
The problem is that the dependency flow automation inserts internal feeds in our NuGet.config, and then the Secure Supply Chain Analysis can't detect if these feeds have upstreams or not.
Would it be possible for the dependency flow automation to not insert these feeds into our NuGet.config? Note that they're not required, because:
- We're a public project, and shouldn't need/use/depend on internal feeds.
- The feeds are disabled later in the NuGet.config by the dependency flow automation.
Example problematic NuGet.config:
https://github.com/dotnet/macios/blob/2238ec895e7b30e982b030b74583886ac1ba7474/NuGet.config#L50-L55
The internal feeds:
https://github.com/dotnet/macios/blob/2238ec895e7b30e982b030b74583886ac1ba7474/NuGet.config#L19-L24
and they're disabled here:
https://github.com/dotnet/macios/blob/2238ec895e7b30e982b030b74583886ac1ba7474/NuGet.config#L50-L55
Admittedly another potential fix would be to teach the Secure Supply Chain Analysis to ignore disabled feeds, but it seems a better fix would be to just not add disabled feeds in the first place.
References:
- https://stackoverflow.microsoft.com/questions/446149/446750#446750
- https://teams.microsoft.com/l/message/19:[email protected]/1740700343519?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=4d73664c-9f2f-450d-82a5-c2f02756606d&parentMessageId=1740700343519&teamName=.NET%20Core%20Eng%20Services%20Partners&channelName=First%20Responders&createdTime=1740700343519
The reason that dependency flow is adding these is that it believes that these are necessary when building internally. This would happen if you ever built and tested against a monthly servicing build of .NET, which I believe happens in certain cases. You don't build these in public PRs, but you would build them internally and would hit the same error.
I think there was a change in the detector recently. It used to not error on these disabled feeds. I think this should be fixed.
Looks like this change was intentional according to https://dev.azure.com/mseng/AzureDevOps/_git/secure-supply-chain-task/pullrequest/826853 ...
I've commented on the PR.