Home: 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

[mountgellert]

Hi @rrelyea , is there any update on this or on https://github.com/dotnet/corefx/issues/6746 ?

[mountgellert]

@mrward , How does your change fix this? Still cannot seem to see a way to use encrypted credentials from a Linux machine.

[mrward]

@mountgellert - For some reason merging the latest code into my fork closed this issue when it should not have. Re-opening.

[psmulovics]

Any news on this item?

[guidobouman]

What's the roadmap on this? Is the NuGet or the dotnet project responsible for this implementation? I can't seem to find anything about this in https://github.com/dotnet/designs/issues/11

[psmulovics]

any news on this item?

[wvh-shanee]

Bump for update.

[koliyo]

Please make this a priority, if Microsoft is serious about true cross-platform .NET application development.

We need both MacOS and Linux support!

[dquist]

Another serious shortcoming here is that, even on Windows, there's no way to securely enter the password. It can only be provided as plain text through the -Password option, in which case it will likely be logged to the shell history.

Come on, this is like CLI authentication 101. There needs to be a way to enter secrets interactively.

See https://github.com/NuGet/Home/issues/8131

[Swoorup]

• Upgrades everything to use dotnet core instead of mono.
• Everything works fine locally.
• Hopes on to build machine, which repulls packages.
• Notices this damn bug.
• Cleans packages locally, notices this damn bug.

[MaxHorstmann]

Please make this a priority, if Microsoft is serious about true cross-platform .NET application development.

We need both MacOS and Linux support!

Friendly +1. We're evaluating GitHub Actions / Packages for our build pipeline. A bit simplified, here's the workflow we have in mind:

name: build

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.300
    - name: Add package source
      run:  dotnet nuget add source https://nuget.pkg.github.com/ourteam/index.json -n GPR --store-password-in-clear-text -u SomeUser -p ${{ secrets.GITHUB_TOKEN }}
    - name: Install dependencies
      run: dotnet restore
    - name: Build
      run: dotnet build --configuration Release --no-restore

So basically, the GitHub Packages NuGet source is injected at build time using the GITHUB_TOKEN. With the entire build running on a Linux image, we're forced to use --store-password-in-clear-text - otherwise, the "Add package source" step fails with the "Encryption is not supported on non-Windows platforms" error.

While GH Actions thankfully doesn't log the cleartext token (shows up as -p ***), it's worrying that it is stored somewhere inside an ephemeral build container (in nuget.config or elsewhere) for a certain period of time. In particular given the wide range of permissions for the GITHUB_TOKEN. Supporting password encryption on non-Windows platforms would alleviate that concern.

[rrelyea]

Had meeting with .net core team today to talk about options for xplat encryption.
Unfortunately, this issue is tracking a solution that would only be able to provide "obfusacted passwords" -- see number 5 in list below.

List of best to lowest security options:

Authentication Options for NuGet clients

• 1 - AVAILABLE SOON: Use Client Certs to secure client<->server communication
  (coming in NuGet 5.7 - available in preview 3 and later) - requires a nuget server that could use client cert as user auth...(not sure if that exists yet)
  hardware security module to store client key

• 2 - POTENTIAL FEATURE WORK: nuget could use a technique like Azure storage...never send credential -- use credential to sign request...then send to server...server verifies signature. credential never goes across wire...which means process doesn't need access to that signature...so it is more secure.

• 3 - AVAILABLE ON WINDOWS: encrypted passwords in a user/machine nuget.config doc page

• 4 - POSSIBLE TODAY: use a hardware security module to store password
  (however, if app can read password, so can root, and manager of HSM)

• 4 - POTENTIAL FEATURE WORK: NuGet uses Azure Key Vault (or similar) for CI scenarios

• 5 - POTENTIAL FEATURE WORK: obfuscated passwords, trying to be like Windows' encrypted password stored in nuget.config on...however, root will always have access...even if we implemented that. (hard drive stolen...put in another computer, root wins!)

• 6 - AVAILABLE TODAY: clear text password in envvar. Nuget.config references env var. doc page

• 7 - AVAILABLE TODAY: clear text password in nuget.config doc page

• ? - credential providers...need to understand where they rank and add to list above.

Communication Options between client and server

1) Client Certs and https
2) https
3) http

[tmds]

root will always have access

This is by design. root is not like a Windows administrator. It is at the same level as the kernel. You can never lock out root.

hard drive stolen

Disk encryption can be used.
(On top of restricting physical access, so disks don't get stolen.)

obfuscated passwords

Probably the 'key' stored to reverse the obfuscation will be stored with the user permissions. That's fine. I want to point it out explicitly.

env var for password in nuget.config or other clever ways

This seems an interesting option for builds in containers.

[dquist]

Point of clarification regarding the encrypted passwords in nuget.config, there's currently no way to set the encrypted password value without entering it as a plaintext value as part of the command. This is not ideal since the plaintext value will most certainly be logged in terminal history.