[DCR]: HTTPS transition warning NU1803 cannot be suppressed

[sleepy-manul]

NuGet Product Used

dotnet.exe

Product Version

MSBuild version 17.3.0+92e077650 for .NET

Worked before?

Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET

Impact

I'm unable to use this version

Repro Steps & Context

Our situation is as following:

• dotnet / msbuild is running in a Kubernetes container (build farm)
• The nuget registry is inside the same Kubernetes cluster (where network traffic is already encrypted by the Kubernetes network plugin). Thus, there is neither sense nor gain in additional encryption

In our case, we don't get the NU1803 as a warning, but instead as an error message which causes our builds to abort. We are using the latest 6.0 dotnet-sdk packages for Debian 10 from the official Microsoft repository.

• git rev-parse --short HEAD
• /usr/bin/dotnet publish --verbosity quiet --version-suffix git-624b07b1b --no-self-contained --configuration Release ***.sln
  MSBuild version 17.3.0+92e077650 for .NET
  ...error NU1803: You are running the 'restore' operation with an 'HTTP' source, 'http://sonatype-nexus-intern.jenkins.svc.cluster.local/repository/***-dev-nuget/'. Non-HTTPS access will be removed in a future version. Consider migrating to an 'HTTPS' source.

The decision to disallow HTTP is short-sighted and ignores that there are several legitimate scenarios where TLS certificates are hard to obtain (internal Kubernetes DNS names) or impossible to implement (the build images are prepared by a central team within our organisation and we are unable to patch it with additional CA certificates).

To my knowledge, there is no public nuget source accessible by HTTP (without TLS) anyway.

Thus, I strongly ask you to revert this injudicious change and please do not repeat it in any patch release. People rely on updates for the stable LTS not to break their systems!

Verbose Logs

No response

[bonza]

Why in the announce they say warning while in fact, it is an error?

[JSkimming]

We build using <TreatWarningsAsErrors>true</TreatWarningsAsErrors>, and this is causing a build failure.

Adding <WarningsNotAsErrors>NU1803</WarningsNotAsErrors> is not suppressing the error.

How can we downgrade the error if our default is to build using TreatWarningsAsErrors?

UPDATE Answer provided by @NiknakSi below.

<NoWarn>$(NoWarn);NU1803</NoWarn>

[NiknakSi]

In my experience of hitting this issue today it's only an error if you've got your project set to upgrade warnings to errors. If you disable that you'll see NU1803 listed as a warning and not an error and the restore/build should work as normal.

Obviously that's not really a solution, but it is hopefully a decent enough temporary workaround.

[NiknakSi]

Adding <WarningsNotAsErrors>NU1803</WarningsNotAsErrors> is not supressing the error.

How can we downgrade the error if your default is to build using TreatWarningsAsErrors

Try <NoWarn>NU1803</NoWarn> - that works for me

[sleepy-manul]

According to https://devblogs.microsoft.com/nuget/https-everywhere/ , it will not be ignorable in the future, so these workarounds, unfortunately, won't help me.

[jmecosta]

In fact this is pita, we have a internal feed that we dont care is it or not https... now we need to pay for a certificate to use it. Also we have shit loads of projects that will now start failing once we upgrade Visual Studio, along with all the developers complaining there builds are broken because we upgrade VS... Plus all the old code will no longer compile on the build farm if we need. This is not a warning this is breaking change.

PS: we have treatwarnignsaserrrors everywhere, because it exists for a very good reason... Another one, is the duplicated package references... You should make this OPT IN, or make this changes on VS 2025 or whatever.

A decent workaround would be for example, to allow us to define a environment variable globally for all projects to disable these... This would allow us to proceed and fix all those problems before we halt production.

PS2: Some of our projects have directory.build.props, some dont meaning NU1803 needs to be set to every project.

[NiknakSi]

In fact this is pita, we have a internal feed that we dont care is it or not https... now we need to pay for a certificate to use it.

At the risk of going slightly off-topic, I would say that's not really the case now with Let's Encrypt. It should be possible to use a wildcard cert for an internal subdomain to cover your internal services. Automate the renewal process, and automate the deployment of the cert to the services that use it.

However I do appreciate that doing this is likely going to be extra work that you didn't ask for. And I also appreciate there are a lot of orgs that still use a .local domain for internal services which this isn't going to work for. It might be time to argue that those environments are long overdue some modernisation.

With all that said, I do still agree with you that for now this change should be opt-in and in the future it should change to be opt-out. Progress with HTTPS everywhere is important, if sometimes painful.

[jmecosta]

On Sat, Aug 13, 2022 at 12:04 PM Simon Hoade ***@***.***> wrote: In fact this is pita, we have a internal feed that we dont care is it or not https... now we need to pay for a certificate to use it. At the risk of going slightly off-topic, I would say that's not really the case now with Let's Encrypt. It should be possible to use a wildcard cert for an internal subdomain to cover your internal services. Automate the renewal process, and automate the deployment of the cert to the services that use it.

Thanks for the hint. At least the cost part is covered :)

However I do appreciate that doing this is likely going to be extra work that you didn't ask for. And I also appreciate there are a lot of orgs that still use a .local domain for internal services which this isn't going to work for. It might be time to argue that those environments are long overdue some modernisation.

The https part on itself is trivial, we just get the cert and install it. And thats it.

With all that said, I do still agree with you that for now this change should be opt-in and in the future it should change to be opt-out. Progress with HTTPS everywhere is important, if sometimes painful.

This is exactly the point, all our builds are broken, because we are strict about warnings. And this is the biggest pita really (also the fact that old commits will no longer build is problematic) But any way, thank you for understanding the opt-in need for this. Cool would be if there was a opt-special for a newly introduced warning, that wouldn't escalate to error when warnings as errors is enabled, because this warning is really valuable and if not here it would hit us in our faces when the HTTP support is removed. —

…

Reply to this email directly, view it on GitHub <#12013 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH6HSE2EBIVH2LMK4MVWFLVY5QIXANCNFSM56CI4FPA> . You are receiving this because you commented.Message ID: ***@***.***>

[lonix1]

Progress with HTTPS everywhere is important, if sometimes painful

Respectfully disagree - sometimes it's not important at all. And it should be up to us to decide how to run our businesses.

Our use case: we use a private nuget server (baget) inside our LAN. There is no need for TLS in this case - so NU1803 is irrelevant.

There should be a switch e.g. --allow-http to avoid this problem.

[lonix1]

Try <NoWarn>NU1803</NoWarn> - that works for me

I believe the safe syntax is <NoWarn>$(NoWarn);NU1803</NoWarn>

[JonDouglas]

Hi friends,

Thanks for the feedback. We're looking for this type of feedback of your various scenarios to better inform our plans as mentioned in the blog.

The warning can be elevated if your build uses TreatWarningsAsErrors / warnaserror which is a common practice for many builds.

Keep providing your perspectives, scenarios, and make sure to 👍 on the original comment so we can track how disruptive this change may be and alter our plans to help alleviate some of the pain you're experiencing when upgrading your tooling.

Thanks for being patient with us as we find the right balance of this effort and how it's brought into the product.

[campersau]

We have an internal on premise Azure DevOps Server which hosts our internal NuGet feed for which we would now need a HTTPS certificate to prevent the warning. Since we are using a .local domain this isn't trivial as we first would have to migrate it.

[domtheluck]

Same problem for us. We are running a local nuget repository who don't need to be https and now, we are getting warnings/errors for all our projects.

For now we ask everyone to return to VS 2019 or a previous version of VS 2022.

What a waste of time and money (more that 100 devs).

We should have the option to "trust" the source or have switch or any other way to get around this.

[tg73]

Same here, internal feeds (proget), no need for or desire to configure https.

[drieseng]

There's also no way to avoid the warning in case of nuget install.

[gbpcor]

I think this is a useful feature but at the very least there should be an opt-out command-line parameter (like @lonix1 proposed).

My work also hosts an internal NuGet source on an intranet. I don't know how much work it'd be for the DevOps team to change to HTTPS but it doesn't make much sense since it's already in a protected network.

[cesarbmx]

Could we get an estimation on the final decision?
Otherwise, I will need to tell infra to configure a certificate to support SSL inside our LAN. Thanks

[jeffkl]

Just closing as a duplicate of #12015

[ToddRopog]

If TreatWarningsAsErrors is true, <NoWarn>NU1803</NoWarn> in the csproj file will suppress the errors (and warnings), but /noWarn:NU1803 on the MSBuild.exe command line does not suppress the errors (it does suppress the warnings).

[fourpastmidnight]

Progress with HTTPS everywhere is important, if sometimes painful

Respectfully disagree - sometimes it's not important at all. And it should be up to us to decide how to run our businesses.

Our use case: we use a private nuget server (baget) inside our LAN. There is no need for TLS in this case - so NU1803 is irrelevant.

There should be a switch e.g. --allow-http to avoid this problem.

Exactly, adding in the complexity of needing to manage/maintain HTTPS certs for an internal server that is never publicly accessible is adding additional complexity to a CI/CD pipeline and violates the KISS principle. The less moving parts, the less there is to break.

This was done without giving much thought to real world usage of Nuget outside of public-cloud-based CI/CD pipelines. Private-cloud environments do not need this extra overhead and complexity. There's enough other crap to do around here.

[robindegen]

I also agree with the above sentiment. Enforcing https for internal servers is absolutely silly and is just forcing us to either spend extra money to buy a proper certificate or self-sign in which case the security is completely out the window because there is no trust authority. Then you might aswell just use http. Please keep things simple. KISS as mentioned.

If you really want to throw this warning; perhaps throw it only if its an external IP. If it is any of the well established internal ip's; it should just be allowed.

[ite-klass]

or self-sign in which case the security is completely out the window because there is no trust authority. Then you might aswell just use http

Other stuff aside, saying self-signed cert is no different to no cert is wrong. In three points/layers:

1. https => encrypted network traffic
2. manually accept certs => be able to notice changes (MITM/impersonation)
3. deliver/set up self-signed cert trust => as good as outside central authority

In your own network you are the central authority.

If you don't have a setup to distribute trust across your network it's a hassle of course.

[robindegen]

or self-sign in which case the security is completely out the window because there is no trust authority. Then you might aswell just use http

Other stuff aside, saying self-signed cert is no different to no cert is wrong. In three points/layers:

1. https => encrypted network traffic
2. manually accept certs => be able to notice changes (MITM/impersonation)
3. deliver/set up self-signed cert trust => as good as outside central authority

In your own network you are the central authority.

If you don't have a setup to distribute trust across your network it's a hassle of course.

And exactly what use is encrypted traffic in an internal lan that is only used by internal employees? If someone is going to spy on that internal traffic, we have a bigger problem wouldn't you say? That's like putting a lockbox inside of a massive vault.

We dont have a distributed trust because we never needed one. The conan package manager doesn't require this either. You either just use http or disable https verification. I feel like we're being enforced extra steps for the sake of a security problem that doesn't exist for us.

[zivkan]

And exactly what use is encrypted traffic in an internal lan that is only used by internal employees?

There have been documented examples of compromised routers and managed switches being sent to customers, before the customer . Other examples of routers (and other "IoT" devices, like network attached cameras) being compromised due to weak passwords (or not changing default passwords), plus the management interface being available externally (maybe it's a company with more than one office, so network admins need remote access, as it's impractical to have a network admin on-site at every location).

Encrypted traffic, within a company network, where certificates are signed by a company-internal trusted CA prevent these types of MitM attacks by whoever controls those compromised routers.

If someone is going to spy on that internal traffic, we have a bigger problem wouldn't you say?

Yes, but security isn't black or white, true or false. Multiple layers of security limit the harm that a successful intrusion can do.

We dont have a distributed trust because we never needed one

The entire "Zero Trust Networking" movement have the opposite opinion. While GPG isn't as popular as X509 certificate chains, it's existed for decades, given there's more than 1 CA, that can be considered distributed too, which also has existed for decades.

If you listen to podcasts, I very highly recommend Darknet Diaries. Anyway, like most things in engineering, there is no perfect solution ("silver bullet"). Particularly in security, it's all about trade-offs, how much convenience you're willing to give up to reduce risks. But most importantly the choice you make will not be the choice that other people make.

[robindegen]

I'm sorry but this is up to our own policies and is completely our own risk that we choose to take. This should not be dictated by a single developer tool. Especially not if other tools have no such enforcements. It is just adding more maintenance and maintenance cost where there really doesn't need to be any.

[lindexi]

Adding allowInsecureConnections="true" to nuget.config like in this post: https://learn.microsoft.com/en-us/nuget/reference/nuget-config-file#packagesources

<packageSources>
    <add key="http-source" value="http://httpsourcetrusted/" allowInsecureConnections="true" />
</packageSources>

allowInsecureConnections: When false, or not specified, NuGet will emit a warning when the source uses http, rather than https. If you are confident that communication with this source will never be at risk of interception attacks, you can set the value to true to suppress the warning. Supported in NuGet 6.8+.