Support for HTTPS basic authorization?

[noomorph]

Does Chocolatey have support for basic authorization?

If not - do you have any ideas how to implement it clearly and well?
Need your adivce..

[ferventcoder]

The only thing I think would be acceptable is to pass those items through the command line and have them passed as header values when making the request (if they are there).

That would get you into the src/helpers/Get-WebFile.ps1 (I think it is called)

[rismoney]

speaking of get-webfile, i swapped in several newer ones for testing - http://poshcode.org/?lang=&q=get-webfile. I was troubleshooting what I perceive to be slow x-fers on a 10g network. v 4.1 is significantly SLOWER than the 3.x series. The issue turned out to be tweaking autotuninglevel and ramping up the buffers from 4096... but whatever was done in 4.1 is slower.

Back on topic - I HATE passing passwords directly from cli. get-credential requires interaction...maybe something with securestring would work?

[noomorph]

Sorry, is there any chocolatey global configuration file? I can store credentials there at least.

[rismoney]

No config file as of yet, except for sources.

I apologize. I don't hate pw at cli. I actually had a conversation with someone on the topic of pw in files that ended up in version control... You can guess where that went.

What you are describing does sound reasonable.

Does the getweb file support http://user:pw@url syntax? I know modern browsers disallow it...

[ferventcoder]

Short answer: I'd like to stay away from storing sensitive information in a file with chocolatey (at least for now).

tl;dr

There is a config file, but I don't want passwords in a file. Some folks put chocolatey in a dropbox folder so they can move it easily between computers. I don't quite agree with this b/c it gets things out of sync (what do you really have natively installed on this computer?) and can cause confusion when updating all of your packages. Some folks like it though. While I don't agree with it/support it, I don't want to introduce changes to chocolatey that limit their ability to do so. If we had some kind of encrypted string in a file it may not translate between computers (depending on the algorithm used). In the past (in other projects) we've used X509 certificates to get a good algorithm between machines. I don't want to take chocolatey in this direction of complexity (using certificates) unless it is absolutely required (read: it's probably not).

I could be wrong, but the way you save secure string to a file is still machine specific (http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/d4557d9b-6e7d-4695-bfd0-a22a08e06160/ | http://stackoverflow.com/a/6982430/18475). To save the securestring to a file you would use some algorithm which usually ties you to the machine (or store the IV you would need somewhere, which still gets us into the same issue if we want to store that with chocolatey's directory). Or use X509 certificates, which opens up even more complexity than the other methods (how to install, where to install, what about permissions to the private key, how to sync between machines, etc).

One of Chocolatey's tenants is simplicity. Note that simplicity is not the opposite of complex, only the opposite of complicated. I don't want a complicated experience for users. So whatever answer we come up with, it should not impact the user experience in a detrimental way.

[StuartWhelan]

In order to use our local nuget repository (hosted in artifactory) we need to use basic authentication.

nuget.exe supports -username and -password when running sources add, but this is not exposed the the chocolately wrapper of the sources command.

Would passing through the -username and -password functionality to the nuget sources add solve this problem?

I solved in myself by calling the nuget sources add directly, then copying the resulting config entries.

[skyguy94]

My understanding of the problem is that there isn't a way to do:
choco inst MyPackageThatNeedsAuthentication

because Chocolatey won't store credentials to pass to NuGet. Since you can do credentials with NuGet, this breaks expected behavior.

One of Chocolatey's tenants is simplicity. Note that simplicity is not the opposite of complex, only the opposite of complicated. I don't want a complicated experience for users. So whatever answer we come up with, it should not impact the user experience in a detrimental way.

I'm not certain I get the argument here. If my summary is correct, then Chocolatey complicates behavior by breaking a NuGet feature.

There was some mention of using NuGet to set the credentials, and that seems to be a successful workaround, but that requires adding a Source to the users global nuget file with the appropriate credentials so that they happen to get picked up when NuGet is invoked by chocolatey.

If storing the secure string is really an issue, adding an "interactive" switch to choco, or the global settings, as well as detecting a 401 Error with the BitsTransfer or WebGit, rather than letting the interactive error message show and fail the script, would go a long way towards simplifying the issue.

[ferventcoder]

With choco.exe, this is already resolved. This closes when we switch in the new repository.

[ferventcoder]

@skyguy94

I'm not certain I get the argument here. If my summary is correct, then Chocolatey complicates behavior by breaking a NuGet feature.

Chocolatey != NuGet

You are also treading on a 2 year old comment. ;)

[skyguy94]

I get that the issue was opened two years ago, but it appears to be active/unresolved.

From your responses, it sounds like you have an unreleased version of Chocolatey written in C# that will handle this issue.

I thought it was 'Chocolatey NuGet'. The inference between the two tools seemed appropriate, especially since the workaround says to use NuGet directly.

[ferventcoder]

Chocolatey uses the NuGet packaging infrastructure.

Per the comments on active/unresolved: This is unresolved in current releases of choco b/c the code to do so could have been very painful in POSH, and we've been holding off on some things we knew were painful until the rewrite. Although this is an issues list, some things are enhancements (although this one is not marked as one though...) :/.

This has sat because we didn't have a good solution at the time. Apologies, hopefully many of the current issues will be cleaned up.

[skyguy94]

Awesome. I look forward to getting my hands on the new bits. Thanks for the response and your hard work.

[codearoo]

Hi... also bumping into this.. but I wanted to clarify something... Are you suggesting that Chocolatey in the future will not use NuGet? Meaning that all the NuGet packages created will no longer work?

[ferventcoder]

@codearoo clarification - choco.exe uses nuget.core.dll, not nuget.exe.

[ferventcoder]

All nuget packages will continue to work. That would be unwise of us without a long term deprecation. I would assume that we tend to handle compatibility well on the team and deprecations. But with your concern, maybe that is not the case?

[codearoo]

I was just making sure I had the same understanding just in case. I've seen stranger things. :)