Mistakes were made
When we first published the plan for the effort of HTTPS everywhere, we wanted to get developer community feedback on the various HTTP and HTTPS scenarios that we don’t have much everyday visibility of. After we published that blog, we heard you loud and clear that there was a gap. This plan needed a clear way to suppress the eventual error case when a non-HTTPS source is used due to various scenarios where you are able to accept the security risk.
We’ve recently added such functionality that will allow you to do just that. In NuGet 6.8, you will be able add the allowInsecureConnections
attribute to your respective packageSources
in your nuget.config
to enable or disable this functionality. The default is allowInsecureConnections="false"
.
Here’s an example:
<packageSources>
<clear />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="Contoso" value="http://contoso.com/packages/" allowInsecureConnections="true" />
<add key="Test Source" value="c:\packages" />
</packageSources>
In this example, the insecure http source called Contoso
has the allowInsecureConnections
attribute set to true
and therefore will ignore any default non-HTTPS warnings and errors.
How we’ve made it right
For how we got here, we took all the community feedback to come up with an open source proposal on what we believe will improve this experience. Next, we created an epic of including this functionality in all the various NuGet tooling. You should see this functionality in NuGet 6.8, .NET SDK 8.0.100, and Visual Studio 17.8.
Continuing on
We will continue on the original plan’s trajectory of upgrading this warning into an error when non-HTTPS sources are used. The only difference is that you will now be able to opt-out of this behavior. Keep an eye on the NuGet official release notes for when that will be.
Feedback
Your feedback is important to us. If there are any problems with this experience, check our GitHub Issues and Visual Studio Developer Community for existing issues. For new issues within NuGet, please report a GitHub Issue. For general NuGet experience issues, let us know via the Report a Problem option found in your favorite IDE under Help > Report a Problem
.
I do think giving an ability to override/disable the https requirement was the right choice, but reading that github issue thread does scare me a little bit - the amount of people leaving themselves open to supply-chain-attacks because they're sure that their server has no access to the outside world is slightly mind-boggling.
It doesn't take a huge amount of effort to set up a certificate store, add the CA cert to all your machines and...
Thanks for your perspective!
For sure you are right. Meanwhile here I am still waiting for a valid certificate. The local admin does not care or it costs money, IDK. The topic is up a year and nothing has happened.
It’s good to have a plan B.
Is there something equivalent about the command line interface source parameter?
There is not right now. We typically try to detach the
-Source
parameter behavior fromnuget.config
behavior. Please do feel free to file an issue so we can investigate the interest in this experience.Awesome, thanks for that update! This is a very welcome change, we are too still using a HTTP only feed (on-prem).
Thank you for the comment!