Missing NuGetApiKey should not throw exceptions on Publish-Module

[Jaykul]

The NuGetApiKey is not marked mandatory on Publish-Module.

In point of fact, there are NuGet repositories, like the Visual Studio Online package repositories, which require credentials rather than API keys, so this error (with id "NuGetApiKeyIsRequiredForNuGetBasedGalleryService") is technically incorrect anyway.

You should just try the publish and provide proper errors when and if the authentication fails.

[bmanikm]

I agree with you.

[jzabroski]

Now that PowerShell/PowerShellGetv2#335 is refactored thanks to @Benny1007 , this should be re-considered

[heidarj]

Hey, I would like to try my hand at making an open source contribution, shouldn't this be as simple removing the "[ValidateNotNullOrEmpty()]" from the NuGetApiKey parameter and then replacing this:

if (-not $NuGetApiKey.Trim()) {
	if (Microsoft.PowerShell.Management\Test-Path -Path $DestinationLocation) {
	$NuGetApiKey = "$(Get-Random)"
	}
	else {
		$message = $LocalizedData.NuGetApiKeyIsRequiredForNuGetBasedGalleryService -f ($Repository, $DestinationLocation)
		ThrowError -ExceptionName "System.ArgumentException" `
			-ExceptionMessage $message `
			-ErrorId "NuGetApiKeyIsRequiredForNuGetBasedGalleryService" `
			-CallerPSCmdlet $PSCmdlet `
			-ErrorCategory InvalidArgument
	}
}

with this:

if (-not $NuGetApiKey.Trim()) {
	$NuGetApiKey = "$(Get-Random)"
}

As I stated I am not familiar with the open source contribution workflow, but I have forked the repo and have tested the change on my machine and it seems to work, I am currently trying to run the tests but am not familiar with pester and testing in general.

[jzabroski]

No, You should require credentials or a NuGetApiKey, or possibly both. Can you explain why you would pass a random api key? It's interesting that you report it works - what happens if you don't pass any key?

In our environment, we use Idea ProGet. They explain their rational for not using NuGetApiKey here: https://inedo.com/support/documentation/proget/feeds/nuget#nuget

NuGet API Key

NuGet client tools (such as nuget.exe and NuGet Package Explorer) have the option to use a "NuGet API Key" as an authentication mechanism for publishing packages. This makes a lot of sense for the NuGet Gallery, as it's a community-run site where anyone can publish packages they own. But in enterprise environments, the notion of "individual package ownership" doesn't quite translate.

With ProGet, a principal (user or group) either has privileges to publish a package to a feed, or does not. This allows ProGet administrators to more easily control access and usage through LDAP and Groups instead of through community mechanisms like API Keys. However, if you wish to use a NuGet API key when pushing to ProGet, you have two options:

• username:password as API Key - ProGet will allow users to authenticate in this mode using an API Key in the format: username:password. For example, you can push a package to a Feed with the default Admin account in ProGet using the -ApiKey Admin:Admin option with nuget.exe
• Create ProGet API Key - you can create an API Key in ProGet (Admin &; API Key &; Access Logs) with Feed Access; you can further restrict this key by associating it to a user you've already given specific permissions

[heidarj]

Well in my case, I was interested in ease of use for "helpdesk" users to discover modules and publish their own modules and scripts to an internal repo (only accessible from inside corporate network). I was planning on deploying BaGet and not requiring any authentication or API key. To test it I deployed BaGet (also tried it with NuGet.Server with no apikey enforcement), registered it as a PSrepo, used Publish-Module to push to the api and it failed with:

Publish-Module : NuGetApiKey is required for publishing a module or script file to the specified repository 'baget' whose publish location is 'http://localhost:50561/api/v2/package'. Try again after specifying a valid value for the NuGetApiKey parameter. To get your API key, view your profile page.

If I try again and give the cmdlet a random string as an NuGetApiKey (just to satisfy the ValidateNotNullOrEmpty validation on the param), the cmdlet succeeds.

Since the api does not require authentication or an API key, the cmdlet that interfaces with it shouldn't either.

After implementing the changes I suggested on my machine, I successfully invoked Publish-Module without the NuGetApiKey param against my BaGet API and when I tried to publish the same module to the gallery for example (which requires an api key) the cmdlet throws the following error:

Publish-PSArtifactUtility : Failed to publish module 'PSPasswordTools': 'dotnet cli failed to nuget push info : Pushing PSPasswordTools.0.2.0.nupkg to 'https://www.powershellgallery.com/api/v2/package/'...
info :   PUT https://www.powershellgallery.com/api/v2/package/
info :   Forbidden https://www.powershellgallery.com/api/v2/package/ 1237ms
error: Response status code does not indicate success: 403 (The specified API key is invalid, has expired, or does not have permission to access the specified package.).

This is the same error that I get when I try to publish with an invalid API key to the gallery and seems like what @Jaykul mentioned as a solution in the original issue comment

[jzabroski]

This is the same error that I get when I try to publish with an invalid API key to the gallery and seems like what @Jaykul mentioned as a solution in the original issue comment

@heidarj Sorry, I don't see where @Jaykul suggested creating a random api key?

I believe the expected behavior is:

• If a command is not required using [ValidateNotNullOrEmpty()] and [ValidateNotNull()], then it shouldn't throw an exception. (Basic expectation - the interface should document whether nulls are OK or not.)
• We know from Visual Studio Online repositories that NuGetApiKey is not required, so it should be possible to be null and not be passed on the command line if null.
• It also seems perfectly reasonable to use LDAP for authentication to an endpoint, but also a secret key to confirm the action. This is called multi-factor authentication. In our ProGet server, we have now configured an API key but also restrict package publishing to members of an LDAP group called ProGet-Publishers. (We used to do it anonymously, which is the default behavior when you set it up, but we have since fixed that.)

[heidarj]

Ok, maybe not what @Jaykul suggested verbatim, but keep in mind this is the implemented behaviour when publishing to fileshare repos, which dont require API keys, as you can see in the published source code.

I disagree that the cmdlet shouldn't throw an exception just because some parameters aren't marked [ValidateNotNullOrEmpty()] or [ValidateNotNull()] and in fact it currently does throw an exception even if the parameters is not null or empty, i.e. if the parameter is not valid.

It should not be the responsibility of the cmdlet to make sure the user authenticates be it with an API key or other credentials. When the API that the cmdlet is interfacing with offers access without any authentication, the cmdlet should do the same.

It also seems beyond the scope of this issue to comment on NuGet server implementations. The user or enterprise should be able to use NuGet without authentication and then thats their prerogative. If that is not best practice from a security perspective or what ever then the onus is on them.

[jzabroski]

@heidarj I see your point of view. You're saying that the published source code as it exists today checks for fileshare repos! Ah! That's an excellent point.

So I guess the problem is that Test-Path only works on fileshare repos, and there is no equivalent test for web-based repos. The question then becomes, how do we consistently handle this across different repository provider types (fileshare, web)?

Frankly, I think this whole module needs to be re-written since it's so complex. How can someone write 571 lines of code in one method and understand what it does? Life is a mystery.

[SydneyhSmith]

@heidarj love to hear that you are hoping to contribute, we have a limited amount of documentation on contributing to PowerShell Get but feel free to reach out to me or @alerickson with questions you have on the process etc. the best way to get started is probably with a PR and we can give feedback etc. from there

[SydneyhSmith]

This is resolved as of 3.0-beta8