The http removal will break private NuGet servers (NU1803 warning)

[peymanr34]

I completely support the effort to force users to use https, however I'm concerned about not being able to use private NuGet servers (such as BaGet) on my local machine since:

In November 2024, we will throw an error when a non-HTTPS source is used. You will not be able to opt-out of this behavior. https://devblogs.microsoft.com/nuget/https-everywhere

Please consider keeping the opt-out option permanently or suggest an alternative solution.

[nkolev92]

@peymanr34

NU1803 is a warning. It is likely that your project is elevating it to an error.

[erdembayar]

Do we dup to #12013?

[peymanr34]

@nkolev92

NU1803 is a warning. It is likely that your project is elevating it to an error.

Yes, I'm well aware that currently it's a warning but it will become an error in the future (Nov 2024) without an option to opt-out.

[nkolev92]

@nkolev92

NU1803 is a warning. It is likely that your project is elevating it to an error.

Yes, I'm well aware that currently it's a warning but it will become an error in the future (Nov 2024) without an option to opt-out.

My bad, I misread it because of the title.

Do you mind tweaking the title to something that indicates that this issue is about the complete removal of non-https feeds?

I can take a stab at it if you'd like me to.

[peymanr34]

My bad, I misread it because of the title.

Do you mind tweaking the title to something that indicates that this issue about the complete removal of non-https feeds?

I can take a stab at it if you'd like me to.

Sorry about that, please kindly do so.

[timmydo]

Should this throw when the hostname is localhost?

[mika76]

Totally agree with this - we have a totally private nuget server which does not even connect to the internet so please don't make me have to secure it for no reason. This should be an operational decision and not something a tool forces on you.

[mhsimkin]

I agree with @mika76. We are running ProGet internally.

I need a way to indicate that a nuget source is allowed to use HTTP instead of HTTPS. That can be done via domain suffixes or flagging specific feeds.

To go through the process of either purchasing a cert or getting a cert issued internally, then added to all the windows workstations, and finally, working with my network security team to allow HTTPS traffic to a specific server is a BIG ask.

[ITaluone]

+1 from me..

Running an internal nuget feed (internal gitlab instance) with no internet connection. This enforcement for internal and private nuget feeds has not much value.. + it breaks all build pipelines in CI/CD (at least in our environment ;)).

A possible solution would be an additional command line parameter (e.g. --insecure). This approach would have advantages in case you are running multiple CI/CD runners and not have to change every configuration

[jeffkl]

Team triage: Take into account the upvotes on #12013

[michalkowal]

+1

Same here as above - we have private NuGet feed in intranet.
Proposal with --insecure option looks great

[pedoc]

Yes, we would also like to be able to disable this feature in the global config file (or local Nuget.config)

[lonix1]

Please add CLI switch, e.g. --allow-http.

[LMP-Ryan]

+1

As many others have said, we run our own internal server for distributing library packages amongst the development team. The server is only available via the local LAN or VPN connection and isn't exposed to the wider internet.

Support for some form of override to continue to use a http connection would be fantastic.

[sylvainonweb]

+1 We are running a local nuget repository (baget) who don't need to be https.

[heifer1981]

+1 please team we have private CI/CD and some form of override would be very helpful!

[jm3105]

+1 we have also an internal NuGet repo server, only reachable in our local network. HTTPS isn't necessary there

[dilandau2001]

+1 here too. We would prefer to keep using our private http nuget feed.

[AntonioParroni]

+1

[blowdart]

Darn it y'all, best laid plans :)

OK, so nuget folks can we do a double pronged approach.

1. Allow an optout in nuget.config in a server specific manner, defaulting the setting to false and ignore it for file system based feeds

<packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="Intranet" value="http://internal-nuget" allowInsecureHttpProtocol="true" />
    <add key="Test Source" value="c:\packages" />
</packageSources>

2. A command line flag --allowInsecureHttpProtocol=true which would affect any configured server.
3. If a server is an intranet server, i.e. one without an fully qualified domain name, only a host name (e.g. http://nuget as opposed to http://nuget.contoso.com, so without . characters, allow http by default. I would avoid over complicating this by trying to figure out if the domain portion of the server matches the domain portion of the client, which would be unreliable.

In all cases output a warning for every server you try with http

[BartVanBeurden]

Would be nice if this could be configured in an SDK-style project as well. Something along the lines of:

<RestoreAdditionalProjectSources AllowInsecureHttpProtocol="true">...</RestoreAdditionalProjectSources>

[fourpastmidnight]

What is the status of this "proposal"? I see @blowdart suggestion above. Has this been implemented? What's the "current recommendation"? It's April, and the original blog post stated that by NOVEMBER this would be come "permanent". Is the permanency at least on hold while an alternative is hashed out/implemented? (It might be a good idea to publish a blog article with an update on this proposal for wider informational purposes.)

Clarifications on the current status of this is greatly appreciated!

For the record, we're using an internal server with a fully qualified, internal domain name. So @blowdart proposal #3 wouldn't work for us. And really, #3 doesn't make sense. I don't like this whole push of HTTPS everywhere for all the reasons others state. I do understand the why, and when working over public networks, I 100% agree. And, to further that goal, I think proposal #3 just adds additional complexity/ambiguity around when a secure connection should/should not be used. #1 and #2 are probably enough. The only place where #3 might help would be for those who are using only a hostname in their URL for older commits using an older build process--but really, how many people do you think this would actually cover, and is "the juice worth the squeeze"?

[JonDouglas]

Hi all,

I'm working on a proposal. The challenge I see here is that there are two camps. One to solve today's challenge in the .NET 8 timeframe. The other to solve the long term challenge of being on a HTTPS source, but wanting more flexibility until you have an established chain of trust.

1. I have a HTTP server and don't want the HTTPS warning/error. I want to opt-out.
2. I have a HTTPS server and I want to ignore SSL/TLS certification validation. I want to opt-out.

For 1. this could likely be solved by a proposed AllowInsecureConnections or AllowHttp type of flag.
For 2. this could likely be solved by a proposed AllowUntrustedCertificates or DisableCertificateValidation type of flag.

There will likely need to be different levers of control here. For example, one might be able to set both of these flags at both the global nuget.config level:

i.e.

<!-- Disables certification validation for all HTTPS sources and allows insecure connections from all  HTTP sources -->
<config>
    <add key="allowInsecureConnections" value="true" />
    <add key="disableCertificateValidation" value="true" />
</config>

For more fine-grain control, you might also do this at the package source level.

<!-- Disables certification validation on a specific https source and allows insecure connections on a specific http source -->
<packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" disableCertificateValidation="true" />
    <add key="Contoso" value="http://contoso.com/packages/" allowInsecureConnections="true" />
    <add key="Test Source" value="c:\packages" />
</packageSources>

The challenge with this would be an additional metadata item on a traditional key/pair value. Another way this could look is(not as intuitive in my opinion and would give less individual control):

<!-- Allows insecure http source and ignores certificate validation for https source -->
<insecurePackageSources>
    <add key="Contoso" value="true" />
</insecurePackageSources>

Lastly, there could be an environment variable for the local machine such as NUGET_ALLOW_INSECURE_CONNECTIONS and NUGET_DISABLE_CERTIFICATE_VALIDATION. Similar to the global nuget.config concept but can be overwritten on a machine basis if there's no desire to check-in an insecure nuget.config to source conrol.

If these scenarios do not cover everything and there's still desire for a dotnet / nuget CLI parameter as well, do feel free to comment. I'm trying to minimize this design while covering both of these primary scenarios in the spirit of getting to "HTTPS Everywhere".

We know this is a disruptive topic and that's why we're hoping to land something in .NET 8 given it is a LTS. Thank you all for your constant feedback on this topic. We'll likely blog about our next steps once we can finalize a proposal.

Any and all feedback here will be appreciated. I will post a pull request here with a proposal headed in the direction of the comments here and some thorough team review.

[LMP-Ryan]

Hi Jon,

Thanks for adding your thoughts to this thread. I really like fine-grain control proposal. I think it is simple and explanatory without having to lookup additional documentation to check what each setting does.

Something like like in the next nuget update would be really appreciated.

Thanks again to all who are looking at the best way to solve this.

[fourpastmidnight]

For the record, I don't want to establish a chain of trust for my strictly internal nuget feeds. It's unnecessary and adds additional cost and complexity to my on-prem CI/CD process. Of course, if I'm pushing packages to an external source, or even sourcing them externally, I'm going to use HTTPS. But when I'm in a walled garden, I don't need this.

Furthermore, how is this really any more secure for internal servers? MITM attacks are prevented...maybe. But, what about the disgruntled employee with access to servers, feeds, and generally being able to insert malicious code into your internal software supply chain? (Hopefully, other security tooling will catch this, but) HTTPS everywhere does not resolve this challenge by itself.

[fourpastmidnight]

@JonDouglas I would still want a command-line switch. We manage a lot (hundreds, nearing 1000) of individual software products, and to have to make a code commit to each and every one of them would be way more difficult than simply adding a command-line switch to our CI/CD build pipeline.

[mterwoord]

I set up a private repository using Proget docker. It's publically available with a valid certificate via https.

When I configure nuget.config to use my url by adding the following line to the packageSources element:

<add key="NAME" value="https://MY_DOMAIN/nuget/nuget/v3/index.json"/> 

Doing a dotnet restore --no-cache --verbosity:normal results in my private repo being tried, but the following output is shown:

GET https://MY_DOMAIN:80/nuget/nuget/v3/flatcontainer/terwoord.extensions/index.json
Retrying 'FindPackagesByIdAsync' for source 'https://MY_DOMAIN:80/nuget/nuget/v3/flatcontainer/terwoord.extensions/index.json'.
The SSL connection could not be established, see inner exception.
Cannot determine the frame size or a corrupted frame was received.

Why is it forcing port 80, resulting in the client using HTTP to a HTTPS server.

I'm adding some extra info:
I'm using SDK version 7.0.306 on Win x64.

[BartVanBeurden]

@mterwoord Your problem doesn't look related to this issue.

What's the output of https://MY_DOMAIN/nuget/nuget/v3/index.json if you view it in the browser? If the endpoints listed here also contain https://MY_DOMAIN:80 it is probably a configuration error in Proget or in a reverse proxy server. If you're behind a reverse proxy, make sure you're properly forwarding the scheme and domain (probably using X-Forwarded-For and X-Forwarded-Proto headers)

[mterwoord]

@BartVanBeurden Not related, but caused: I had proget running over http, but I want to get rid of my build warnings.

Accessing the url in the browser presents me with a Login form. After entering the credentials there I see a json file containing the nuget manigest. So that all looks ok.
Any other suggestions?

[Regenhardt]

A login form is probably not what the nuget client expected as a response to the URL, is it?

[mterwoord]

I should have been more clear. That's basic authentication form, so the form itself is from the browser. I tried with VS code to do a raw http request. Passing Authentication: Basic .. works. According to documentation, this should work in nuget.

[0xced]

Bringing some pieces together here for everybody following this issue.

The Allow insecure connections and disable certificate validation proposal has been implemented in NuGet/NuGet.Client#5343.

It will be available in NuGet 6.8.0.63 and later versions.

It's not available in the .NET SDK 8.0.100-preview.7 because this SDK includes NuGet 6.8.0.41 (dotnet nuget --version).

When a new version of the SDK will be available, the new allowInsecureConnections attribute in NuGet.config will be supported and we will finally get rid of NU1803. 🙏🏻

<add key="Contoso" value="http://contoso.com/packages/" allowInsecureConnections="true" />

I've been adding <NoWarn>$(NoWarn);NU1803</NoWarn> sooooooooo many times during the last year that I don't even have to lookup the NU1803 code, I know it by heart.😭

[0xced]

Well, the pull request mentioned in my previous comment was only about adding an allowInsecureConnections property in NuGet.Config. This new property was not actually used throughout the code until NuGet/NuGet.Client#5411 was merged last week (September 12, 2023).

So contrary to what I predicted, the NU1803 warnings are still happening with the .NET SDK 8.0.100-rc.1. They will disappear in the next SDK version (8.0.100-rc.2) when NuGet 6.8.0.112 or later will be shipped in the SDK. (You can see the tag 6.8.0.112 in commit NuGet/NuGet.Client@15389cd which is the merge commit of
NuGet/NuGet.Client#5411)

[JonDouglas]

Hi friends,

Check out our blog here.

https://devblogs.microsoft.com/nuget/https-everywhere-update/

Thus I am closing this issue as this is shipping soon! 🚢 🐿️

[ITaluone]

Hello everyone

can anyone guide me into the correct usage of this parameter?

• I have added allowInsecureConnections="true" to my nuget.config like in this post: https://devblogs.microsoft.com/nuget/https-everywhere-update/
• I set my project .NET SDK to 8.0.201 (I re-checked on cli dotnet nuget --version, which is 6.9.1.3))
• I set my IDE to use the nuget version from the SDK

But:

• In my nuget.config: Attribute allowInsecureConnections is not allowed here
• When I build my solution I get the NU1803 warnings again.

[JonDouglas]

Hello everyone

can anyone guide me into the correct usage of this parameter?

• I have added allowInsecureConnections="true" to my nuget.config like in this post: https://devblogs.microsoft.com/nuget/https-everywhere-update/
• I set my project .NET SDK to 8.0.201 (I re-checked on cli dotnet nuget --version, which is 6.9.1.3))
• I set my IDE to use the nuget version from the SDK

But:

• In my nuget.config: Attribute allowInsecureConnections is not allowed here
• When I build my solution I get the NU1803 warnings again.

https://learn.microsoft.com/en-us/nuget/reference/nuget-config-file#packagesources

[ITaluone]

Yes 🤷‍♂️.. which is the same as in the nuget-post.. Or do I miss something? 🤔