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

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.

@peymanr34

@peymanr34

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

Do we dup to #12013?

@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.

@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.

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.

Should this throw when the hostname is localhost?

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.

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.

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.

@JonDouglas

@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.

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.

@mterwoord

@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)

@BartVanBeurden

@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?

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

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.

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.😭

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)

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! 🚢 🐿️

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.

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

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

Navigation Menu

Repository navigation

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

26 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

nkolev92 commented on Aug 10, 2022

erdembayar commented on Aug 10, 2022

peymanr34 commented on Aug 10, 2022

nkolev92 commented on Aug 10, 2022

peymanr34 commented on Aug 10, 2022

timmydo commented on Aug 16, 2022

mika76 commented on Aug 17, 2022

26 remaining items

LMP-Ryan commented on Apr 13, 2023

fourpastmidnight commented on Jun 2, 2023

fourpastmidnight commented on Jun 2, 2023

mterwoord commented on Jul 28, 2023

BartVanBeurden commented on Jul 29, 2023

mterwoord commented on Jul 30, 2023

Regenhardt commented on Jul 30, 2023

mterwoord commented on Jul 30, 2023

0xced commented on Aug 29, 2023

0xced commented on Sep 19, 2023

JonDouglas commented on Sep 19, 2023

ITaluone commented on Feb 27, 2024

JonDouglas commented on Feb 27, 2024

ITaluone commented on Feb 27, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions