Global or CLI Option to Allow Insecure NuGet Sources in .NET SDK (Needed for CI/CD at Scale)

[alexsajno]

NuGet Product(s) Involved

dotnet.exe

Summary

Many enterprise environments operate in private networks with internal HTTP-based NuGet feeds. With .NET 10, the enforcement of secure sources introduces a breaking change that impacts hundreds of our existing CI pipelines. Updating every nuget.config to include allowInsecureConnections is not feasible at our scale.

We request a global configuration option or CLI flag (e.g., --allow-insecure-connections) for dotnet commands (build / publish / pack / tool) to simplify CI/CD usage and maintain backward compatibility for legacy projects.

---

Problem

We have hundreds of projects built in CI pipelines inside a private, controlled network.

Each build uses its own nuget.config file, and modifying every config to include allowInsecureConnections is impractical.

The .NET 10 SDK introduces a breaking behavior: HTTP sources now fail unless explicitly allowed.

This affects a large portion of our existing projects without providing a centralized override.

Why existing solutions don’t work

We cannot use dotnet nuget add source updating a shared function because Jenkins runs many jobs in parallel, and this command modifies the user-level configuration on the Windows machine, causing cross-job conflicts.

We run dotnet build / dotnet publish on specific projects/solutions while passing a path to a custom nuget.config file.
A CLI-level override would fit naturally into this workflow.

---

Requested Feature

Please consider adding one of the following:

1. CLI Flag (Preferred)

A command-line argument such as:

dotnet build --allow-insecure-connections
dotnet publish --allow-insecure-connections
dotnet pack --allow-insecure-connections
dotnet tool --allow-insecure-connections

2. Machine-Level Setting

A global opt-in configuration:

dotnet config set nuget.allowInsecureConnections=true --global

3. Environment Variable

Support for something like:

NUGET_ALLOW_INSECURE_CONNECTIONS=true

---

Benefits

Restores backward compatibility for legacy projects built with older .NET SDKs.

Avoids modifying hundreds of nuget.config files.

Prevents conflicts in CI systems that execute jobs in parallel (e.g., Jenkins).

Makes .NET 10 adoption far smoother in large enterprise environments.

---

Conclusion

A global or CLI-level opt-in would save considerable maintenance overhead and eliminate CI instability. This is a genuine blocker for large-scale enterprise upgrades to .NET 10, and having an override mechanism would meaningfully improve the developer and CI experience.

[alexsajno]

Duplicate of #14643

I close this.