nuget source password encryption story

[yishaigalatzer]

Rob adding text on 2/10/2017:
nuget.exe | dotnet.exe can now use encrypted passwords in nuget.config files -- when running on windows ONLY.
Ideally, we'd support dotnet.exe on other platforms too, so they don't need to store passwords via cleartext.

This would need APIs from .NET Core. See the related https://github.com/dotnet/corefx/issues/6746

[yishaigalatzer]

CC @anurse @davidfowl

[emgarten]

Is this needed for xplat?

[yishaigalatzer]

Yes but not for rc, and debatable for rtm

[yishaigalatzer]

@emgarten when RC is out the door, please start a thread with Stephen Toub

[stunney]

@mrward can you help light a fire under a Product Manager to get this resolved?

[BrianMcBrayer]

Agreed. This is a critical feature.

[JonDouglas]

Hi all,

This is the first time i've seen this issue so please bear with me.

As far as I'm aware, this issue is dependent on ProtectedData having cross-platform support. Currently the API has notes of:

https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.protecteddata?view=windowsdesktop-5.0#remarks

and

.NET Core and .NET 5+ only: Calls to the Protect method are supported on Windows operating systems only

The use of this class is in the following code:

https://github.com/nuget/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Configuration/Utility/EncryptionUtility.cs#L15-L39

This API has no plans to support cross-platform cases which means that we(NuGet) will need to use another approach for each platform as noted by the comment author. It is possible that we may be able to adopt a similar implementation that Mono has for these non-windows platforms.

In the meantime, please upvote the original comment on this issue with a 👍 so we can understand the need for this feature. Or even create a new issue specific to the scenario you're interested in since this issue captures many other authentication scenarios in addition.

Thank you.

[psmulovics]

There are multiple scenarios where you would need this - e.g. connecting to enterprise hosted package manager endpoints where you would need to store password or API key in your nuget.config and you would like to do it encrypted.

As a cascade effect, if the actual underlying protecteddata API would be solved for other scenarios (e.g. for Linux it could have a dependency on libcrypt, or the actual .NET package for a particular Linux distribution could have the distro specific implementation of the relevant crypto DLL), it would enable the use of some pwsh scripts that also fail on the lack of protecteddata support, etc. So fixing the underlying problem would have a positive cascade on a much wider set of the .NET ecosystem.

[aortiz-msft]

@dtivel - Would you please summarize our current state? Also, if we are blocked on a crypto API, we need to create an issue against the proper team to drive the conversation.

cc @JonDouglas

[tmds]

We had a discussion about this with Microsoft 2 years back.

Two points came up:

• The solution can not be as-secure as on Windows.
• Depending on what you are encrypting, there are different requirements, which means using algorithms, key lengths, ...

The first is something we need to accept. We can make it as secure as it is on Linux. That means the key for encrypting/decrypting is stored under the user folder and accessible only to that user.
(My private ssh key is at ~/.ssh/id_rsa 😉).

The second means framework won't provide ProtectedData because there is no generic solution. NuGet needs to take care of it itself.

This is some code @bartonjs wrote as part of the discussion. It may be usable as a base for NuGet's implementation.

cc @GrabYourPitchforks

[hamarb123]

I just started getting this warning:

<path to .csproj> : warning NU1803: You are running the 'restore' operation with an 'HTTP' source, 'http://<rest of link>'. Non-HTTPS access will be removed in a future version. Consider migrating to an 'HTTPS' source.

I'm currently using http on macOS (on localhost, which probably should never be blocked imo since it's not really insecure in the same way per-se) because it doesn't support encrypting the client-cert certificate for some reason. This should be able to be very secure on macOS using keychain, I have no idea why this isn't supported yet other than low priority (which is understandable), but I need to be able to keep using http for localhost until client-cert is implemented on macOS - will disallowing http be delayed until this is implemented on all platforms?

Is there a timeline for this? Will it be properly secure using keychain (if I'm not mistaken keychain will prompt every time access is requested until allow every time is pressed, and then it should allow for the dotnet executable to access its keychain data)?

[zivkan]

@hamarb123 this issue (source password encryption, for private/authenticated feeds) is not related to http/https. Please create a new issue for that.

[hamarb123]

I know it's not related directly. As I said (I think), I'm using a client-cert certificate that runs over https, I'm currently having to use the http version (which doesn't have client-cert or encryption) though because I don't want to store the client-cert certificate password unencrypted. I could probably set up a https proxy that doesn't require client-cert as well, but I don't want to accidentally expose it outside of the machine so I have intentionally used the http one on localhost instead of doing that. Ideally I'd like this feature to be implemented so I don't have to use the http one or find a different solution at all.

[tmds]

Fgcgdgdfggfhfn go look g me fkzgv Op zo 24 jul. 2022 01:29 schreef Hamish Arblaster ***@***.***

…

: I just started getting this warning: <path to .csproj> : warning NU1803: You are running the 'restore' operation with an 'HTTP' source, 'http://<rest of link>'. Non-HTTPS access will be removed in a future version. Consider migrating to an 'HTTPS' source. I'm currently using http on macOS (on localhost, which probably should never be blocked imo since it's not really insecure in the same way per-se) because it doesn't support encrypting the client-cert certificate for some reason. This should be able to be very secure on macOS using keychain, I have no idea why this isn't supported yet other than low priority (which is understandable), but I need to be able to keep using http for localhost until client-cert is implemented on macOS - will disallowing http be delayed until this is implemented on all platforms? Is there a timeline for this? Will it be properly secure using keychain (if I'm not mistaken keychain will prompt every time access is requested until allow every time is pressed, and then it should allow for the dotnet executable to access its keychain data)? — Reply to this email directly, view it on GitHub <#1851 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH2LEEGBTNPX5N2XNVD3Q3VVR57LANCNFSM4BW7LB2Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[p10tyr]

Still a problem today. OS's have built-in key chain managers so I wonder why it's not compatible?
We can't be moving developers over to Linux / Mac if we MSFT is forcing them to store plain text.

[p10tyr]

https://learn.microsoft.com/en-us/nuget/consume-packages/consuming-packages-authenticated-feeds