Environment variable password does not authenticate private feed during convert-from-nuget

[john-patterson]

Description

I am converting a project from NuGet to Paket using the convert-from-nuget command. As per this page I should be able to authenticate a private feed through the %PRIVATE_FEED_USER% and %PRIVATE_FEED_PASS% variables, but I cannot. Supplying the credentials as plaintext in the file works and I have verified that the variables do exist in the executing environment as echo %PRIVATE_FEED_USER% and echo %PRIVATE_FEED_PASS% return the correct values.

The --creds-migrations options are not satisfactory as I would not like to have plaintext passwords in source control, but for a multi-user environment, it does not make sense to encrypt one user's credentials and put it under source control. Users should be able to supply their own credentials for the private (TeamCity) NuGet feed.

Repro steps

1. Have a non-Paket project that consumes a private NuGet feed (this one is TeamCity) for a dependency.
2. Create a .paket directory with paket.exe, paket.bootstrap.exe, and paket.targets
3. Create a paket.dependencies file to specify the source with source </path/to/feed/uri> username: "%PRIVATE_FEED_USER%" password: "%PRIVATE_FEED_PASS%"
4. Set the PRIVATE_FEED_USER and PRIVATE_FEED_PASS to valid credentials
5. Ensure that these are in effect in the current executing environment with echo
6. Run .paket/paket.exe convert-from-nuget --force or .paket/paket.exe convert-from-nuget in the main project directory.

Expected behavior

Environmental variables should authenticate private feeds with convert-from-nuget.

Actual behavior

Paket fails to retrieve package listing when using convert-from-nuget with environmental variables for a private NuGet feed, but succeeds when using plaintext credentials.

Known workarounds

Put plaintext credentials in the paket.dependencies file.

Related information

• Operating system: Windows 7 Professional SP1
• Branch: Paket master tagged 3.8.0
• .NET Runtime, CoreCLR or Mono Version: .NET Framework 4.5.1
• Performance information, links to performance testing scripts

I can spend some more time on this later, but I want to make sure this is not "expected behavior" and I'm just missing something.

[forki]

@theimowski any ideas?

[forki]

Just one thing: the convert process is a one time process. so there it should not be a problem to have the password in plaintext in deps file during that process (don't commit it ;-) ) - after the process is done you can switch to the %PRIVATE_FEED_PASS% option and commit that.
I mean after the initial convert you will never run convert again, right?

[john-patterson]

@forki For sure, I was mainly using this to ensure I understood the environmental variable configuration correctly. I understand if it is an issue that doesn't touch enough workflows to justify fixing. If that is the case, I can just do a PR to the docs for that page that explains the caveat.

[forki]

no I'd love to see what @theimowski says. But in any case a PR which improves docs would be a good start

[theimowski]

convert-from-nuget can migrate only those credentials that are present in your Nuget.config files, and this happens only when you don't yet have paket.dependencies file (i.e. don't need to run with --force flag)
So the credentials are not migrated when you already have paket.dependencies file.

Re encrypting credentials - they are stored in machine local paket config file so you won't be prompted to commit those.

When convert-from-nuget is invoked with --force, the packages are added to the main group - if the private source is specified in main group, install should use it.

Does it make any sense?

[john-patterson]

@theimowki makes sense to me. Should I still do a PR against that docs section to add a small note of this? The whole thing came up when I ran it on a project with private feeds, but it failed as my credentials were not in my NuGet.config.

I then looked up how to add credentials for a private feeds, saw that article, and so I added that line to the paket.dependencies. Boom.

I'm not sure if this workflow is common enough to warrant much attention in the document, but I think a note should help the fumbling oafs of the world like myself. :)

[blumu]

FYI: I'm hitting the same issue when running dotnet restore with .Net Core CLI, following instructions at https://fsprojects.github.io/Paket/paket-and-dotnet-cli.html Shall I file a separate bug for this?