yishaigalatzer commented 8 years ago

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 commented 8 years ago

CC @anurse @davidfowl

emgarten commented 8 years ago

Is this needed for xplat?

yishaigalatzer commented 8 years ago

Yes but not for rc, and debatable for rtm

yishaigalatzer commented 8 years ago

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

mountgellert commented 7 years ago

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

mountgellert commented 7 years ago

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

mrward commented 7 years ago

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

psmulovics commented 7 years ago

Any news on this item?

guidobouman commented 6 years ago

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 commented 6 years ago

any news on this item?

wvh-shanee commented 6 years ago

Bump for update.

koliyo commented 4 years ago

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

We need both MacOS and Linux support!

dquist commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

brphelps commented 3 years ago

I think MSAL has an approach for this for token encryption that nuget should consider using as inspiration -- they try to find a local encryption library on Linux, and only when it isn't present do they fall back to something else.

rrelyea commented 3 years ago

@brphelps - would love a pointer to that approach. sounds promising. link? In all our discussions with net core team (do we call them .net team again?), they didn't think it was easy to solve in runtime.