-
Notifications
You must be signed in to change notification settings - Fork 136
PowerShellGet 2.1.4: Credential Providers | Authentication is STILL BROKEN #619
Comments
Getting out a PackageMangement release today that will fix this! |
I just got version 2.1.5 of PowershellGet but I'm still not truly able to use it with AzureDevops feeds at all as described in here. Here's what I did in my repro: 1). Install Windows 10 1903 from scratch What am I doing wrong here? I am passing a Credential parameter. Isn't this a supported use case for version 2.1.4 or newer? I obtained a new token and used that instead to create $vscred. My issue appears to have been caused by a token which expired on June 14th. Sorry for the confusion. |
Thanks for all the feedback, and patience--we've released updates to both PackageManagement and PowerShellGet yesterday to fix this and I wanted to see if that had resolved the issues you are facing? CC: @alerickson |
still having a lot of trouble using Publish-Script and Publish module from an azure devops pipeline... here's the relevant snippets from my azure-pipelines.yml jobs:
- job: PublishScripts
pool:
vmImage: 'vs2017-win2016'
steps:
- pwsh: |
Install-Module -Name PackageManagement -Force -AllowClobber
Install-Module -Name PowerShellGet -Force -AllowClobber
displayName: Update PackageManagement
- pwsh: |
Import-Module -Name 'PackageManagement' -RequiredVersion '1.4.2'
Import-Module -Name 'PowerShellGet' -RequiredVersion '2.1.5'
$galleryName = '****'
$galleryUrl = 'https://pkgs.dev.azure.com/****/_packaging/****/nuget/v2'
#get azuredevops credentials
$password = ConvertTo-SecureString $env:SYSTEM_ACCESSTOKEN -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential $env:BUILD_REQUESTEDFOREMAIL, $password
$regparams = @{
Name = $galleryName
InstallationPolicy = 'Trusted'
SourceLocation = $galleryUrl
PublishLocation = $galleryUrl
ScriptPublishLocation = $galleryUrl
Credential = $creds
}
Register-PSRepository @regparams -Verbose -Debug
displayName: Register-PSGallery
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken) even though I have specified the Credential, I am getting the device flow prompt
|
When specifying the credentials using the environment variable, I also get an error. jobs:
- job: PublishScripts
pool:
vmImage: 'vs2017-win2016'
steps:
- pwsh: |
Install-Module -Name PackageManagement -Force -AllowClobber
Install-Module -Name PowerShellGet -Force -AllowClobber
displayName: Update PackageManagement
- pwsh: |
Import-Module -Name 'PackageManagement' -RequiredVersion '1.4.2'
Import-Module -Name 'PowerShellGet' -RequiredVersion '2.1.5'
$Env:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS = @"
{"endpointCredentials":[{"endpoint":"https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2","username":"ignored","password":"$($Env:SYSTEM_ACCESSTOKEN)"}]}
"@
$galleryName = '***'
$galleryUrl = 'https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2'
$regparams = @{
Name = $galleryName
InstallationPolicy = 'Trusted'
SourceLocation = $galleryUrl
PublishLocation = $galleryUrl
ScriptPublishLocation = $galleryUrl
}
Register-PSRepository @regparams -Verbose -Debug
displayName: Register-PSGallery
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
|
As a workaround for this broken azure devops / azure artifacts powershell repository experience you can use a local repo and the builtin nuget commands in Azure DevOps to publish. You will need to handle the dependencies by publishing them first or specifying as externalDependencies. I created a gist here of a pipeline that uses this workaround. |
@SydneyhSmith the new release is so much better, but still broken. EVERY TIME I search for a module that is not in the authenticated feed, I get prompted for credentials.Simple repro: Assuming I have installed the Nuget Credential provider using the script from their github in an elevated console: #requires -RunAsAdministrator
iwr https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1 -out ~\Downloads\installcredprovider.ps1
~\Downloads\installcredprovider.ps1 -AddNetfx And I have updated to the current versions of both relevant modules: Install-Module PackageManagement -RequiredVersion "1.4.2" -SkipPublisherCheck
Install-Module PowerShellGet -RequiredVersion "2.1.5" In a new window ...Register-PSRepository -Name PoshCode -SourceLocation https://pkgs.dev.azure.com/poshcode/_packaging/PowerShell/nuget/v2 -InstallationPolicy Trusted
# Find a module that's in that feed, it works! Huzzah!
Find-Module ModuleBuilder But then ...# Find a module that's NOT in that feed:
Find-Module PowerShellGet At this point, it appears that whenever it fails to find a module in the Azure feed that requires credentials, it re-prompts for credentials, and regenerates a new PAT token. If I again search for a module that does exist in my feed, it works fine. But the next time I search for one that does not exist in my feed, it prompts for credentials! |
Ok, update ... # -Force to install latest credential provider
iwr https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1 -out ~\Downloads\installcredprovider.ps1
~\Downloads\installcredprovider.ps1 -AddNetfx -Force
# Update to latest modules
Find-Module PackageManagement, PowerShellGet -Repository PSGallery | ForEach {
Install-Module -Name $_.Name -RequiredVersion $_.Version -Repository PSGallery -SkipPublisherCheck -AllowClobber
} After exiting all PowerShell windows and re-opening, I was able to register and search for modules both in my feed and the PSGallery feed. Register-PSRepository -Name PoshCode -SourceLocation https://pkgs.dev.azure.com/poshcode/_packaging/PowerShell/nuget/v2 Additionally, putting JSON in |
Ugh. Ok, maybe not. I don't understand. I tested this in PS5 earlier today and it worked. Just now I ran a Find-Module without thinking in PS6, and it went back to requesting credentials when it couldn't find a module in our repo -- and NOW, PS5 seem broken again too. I don't understand at all. |
I'm not sure this should be closed. I'm hitting all the same errors you're hitting. |
@nhudacin we just published PowerShellGet and PackageManagement to our int gallery (www.poshtestgallery.com/api/v2) to resolve these errors. Please feel free to test these out and see if behavior is working appropriately. The credential provider should only be prompted if the -credential parameter is not passed in. You can register the int gallery and install the respective modules by running:
|
Thanks @SydneyhSmith. I installed the two modules from your int gallery, closed all of my powershell windows, and opened up a fresh one. I'm getting all sorts of errors now:
|
@nhudacin you’ll need the credential provider itself installed (see: https://devblogs.microsoft.com/powershell/using-powershellget-with-azure-artifacts/#). That error isn't the most helpful but if you don’t have the credential provider installed you’ll need to use the -credential parameter |
I fully agree with Jaykul : it is not really working as it should, is it ? We are talking about these cmdlets when the the parameter "-Credential" is not used.
For this reason, until it works properly, I have done the following :
Now, I pass this credential returned by my function every time I browse my private PSRepository. If I don't pass the credential, I can get a warning, but I don't loose my token ! Find-Module -Repository myPSRepository -Credential (get-myCredential myPSRepository)
Publish-Module -Name myModule -NuGetApiKey (new-GUID) -Repository myPSRepository -Credential (get-myCredential myPSRepository) |
@clientFDJ thanks for reporting this, sorry that you are still hitting these issues...you mentioned that
You are correct that this is certainly not intended...in fact calls to the Gallery do not use the credential provider so this is a bit of a strange behavior we are investigating... Are you able to tell if the cache is clearing itself? The credentials should be storing at |
I'm not able to get anything to work without -Credential being passed. I tried Jaykul's install method with setting VSS_NUGET_EXTERNAL_FEED_ENDPOINTS.
returns
If I pass -Credential, it registers the repo. Once registered with -Credential, I try
which returns
If I pass -Credential, it returns my modules. Since I can use a credential object, I know my PAT is good. What am I doing wrong? Module versions:
|
@tcpaddock sorry to hear that you are hitting issues, thanks for commenting on this issue. Could you try running |
@SydneyhSmith with
|
I logged in to Azure DevOps through IE and cached credentials. I'm no longer receiving access denied. Find-Module now returns
There are some private functions like Resolve-Location and Ping-Endpoint that only look at the credential object being passed through. At some level, it looks like a credential object needs to be built from the VSS_NUGET_EXTERNAL_FEED_ENDPOINTS environment variable to be passed to these support functions. |
Yeah. This is broken again in 2.2 and 1.4.3 I have When I install and load the new versions ( Obviously I can't successfully pass credentials, they require MFA or a token... |
Is there any update of this? When using version 2.2.1 and 1.4.4 and the device authentication method the modules can't be found or installed. When using 2.1.5 and 1.4.2 it is possible to find modules however I am unable to download modules |
Any news on that topic? It still seems buggy to me, I'm using Powershell core on Linux.
Furthermore when trying to find a module I constantly get:
If I manually pass the credentials with -Credential then it works. @SydneyhSmith Shouldn't we get the devicelogin, once only, and then subsequent calls are automatically allowed? |
@molinch thanks for commenting on this, would it be possible for you to give us the output of running |
What is the solution to this issue? I'm trying to connect to an Azure Artifact from a DevOps pipeline but can't do it without receiving the Device Flow prompt. |
Same here, is there a functioning work around or a path forward? |
Ok... This has been working for me since my initial comment. When I passed it over to a colleague, they couldn't get Install-Module/Update-Module to work with our Powershell feed in Azure Devops. I spent a significant amount of time troubleshooting why my box worked but his didn't. Here's what I have, it's ugly but it works. I was able to test this on (several) Windows10 VMs to confirm. The order is VERY important here because as @Jaykul called out above, you must If you've already monkey'ed with this stuff and tried to sign in with the device workflow before, you MUST reset this before proceeding:
Ordered Step by StepThis will need to be executed in an admin console and it's called out when you should close & re-open this console. If not called out, then run the commands in the same console.
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass -Force
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Install-Module PowerShellGet -RequiredVersion 2.1.5 -Force -AllowClobber
Install-Module PackageManagement -RequiredVersion 1.4.2 -Force -AllowClobber
# use both modules
Import-Module PowershellGet -RequiredVersion 2.1.5 -Force -ErrorAction Stop
Import-Module PackageManagement -RequiredVersion 1.4.2 -Force -ErrorAction Stop
iwr https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1 -out ~\Downloads\installcredprovider.ps1
~\Downloads\installcredprovider.ps1 -AddNetfx -Force
$Env:NUGET_PLUGIN_PATHS = "$($env:UserProfile)/.nuget\plugins\netfx\CredentialProvider.Microsoft\CredentialProvider.Microsoft.exe"
Register-PSRepository -Name 'MyPoshFeed' -SourceLocation 'https://pkgs.dev.azure.com/my_org/_packaging/powershell/nuget/v2' -InstallationPolicy Trusted
.\downloads\nuget sources add -Name InternalPowershellv2 -Source https://pkgs.dev.azure.com/my_org/_packaging/powershell/nuget/v2
Update-Module PackageManagement
Update-Module PowershellGet
At this point you can now use Azure Devops like you expect to be able to use them. Unfortunately for me and others, this is not a very clean process and will limit the adoption across my internal teams to use Azure Devops as a Powershell module repo. This information was sourced from as many issues and blog posts I could find around this and I spent several days creating and destroying fresh Windows 10 VM's to confirm the process. Even 1 step out of order throws the whole darn thing off. |
I've finally managed to get this working in a Azure DevOps Release pipeline by including a 'NuGet authenicate' task. This now works without a Device Flow prompt in the task output:
Script:
If you are trying to connect from a local machine, make sure you have installed the cred provider https://github.com/microsoft/artifacts-credprovider/blob/master/README.md#setup and that 'netcore' and 'netfx' have been copied to %UserProfile%/.nuget/plugins/ Hope this helps others. |
Oh, what a thread. Noticed one of my issues referenced here. After battling https://github.com/PowerShell/PowerShellGet/issues/584 for several days to get a custom module published locally and then exploring Azure artifacts as a distribution channel custom modules, here are some learning:
Regarding Azure artifacts as a distribution channel:
Overall, I gave up and packed a custom module as a docker container to make sure that:
Well, the only challenge is limited workloads which come via mapped folders to do the work and ability to actually install the module on the target system. But can only be done with downgrading dotnet at the moment with PS Core. |
The easiest and most consistent way I have found to publish modules to Azure Artifacts is packing and pushing the module with the FSharp package manager paket - since it is a replacement for nuget it bypasses the problems with inconsistent versions and requirements, and it is a single lightweight executable. I wrote a build task for Invoke-Build that generates a paket.template file from the module manifest, and use that to create the .nupkg file. Some things to note:
The full workflow I'm using is:
|
Seem to have hit this today. I can't find anyway to enable command line auth. I've created a PAT and whatever route I do, Environment variable, credential in PSreposirtory, credential in ALL module calls, I get prompted for the devicelogin flow. I swear this was working yesterday, so wondering what has changed. |
Fwiw, we've resolved our publishing problems by using the PSPublishHelper module to package it, and then pushing the package with the nuget client. |
Seeing the same behavior
Repeatable when spinning up a linux container with Credentials must be provided for every command (Register... Install-Module...) and the |
When trying PowershellGet 3.0 beta8, I also had to provided a 218 is resolved in Beta10. |
Just wondering if this is planned to be fixed in v2 or if we need to wait for v3? Damn, this issue has been going on for almost 4 years and is stunting adoption of Azure Artifacts where I work |
Managed to workaround |
This worked for me. Adding the -SkipValidate was the trick. |
- addressing issue with noise around repository usage discussed in PowerShell/PowerShellGetv2#619
@SydneyhSmith : would you have an update on where this falls on the roadmap? The only work around I've found for this is by adding in the PowerShell repository as a |
Thanks @andyfeller, we are integrating credential persistence and will likely have this out with the next release. We are integrating with Secret Management with PowerShellGet. Here is some blog posts describing Secret Management: |
Thanks, @StevenBucher98! ✨ This came up on my radar while trying to put this PoC together but just trying to get something working, so I hadn't delved deeper, you know? Let me dig into this and see how to incorporate to GitHub Actions. |
Don't know if anybody at Microsoft still cares, but the issue persists. BUT I furthermore found out that on my buildservers registering a repository behaves differently on dev vs buildservers. #Param
$ArtifactSource = $env:PackageFeedEndpointV2
$RegisterAs = $env:PowerShellRepositoryName
$Credential = [pscredential]::new($env:COMPUTERNAME,($env:SYSTEM_ACCESSTOKEN | ConvertTo-SecureString -AsPlainText -Force))
Register-PsRepository -Name $RegisterAs -SourceLocation $ArtifactSource -PublishLocation $ArtifactSource -InstallationPolicy Trusted -Credential $Credential On my buildservers it runs just fine. I also found the fix via Add-Packagesource here: https://andrewmatveychuk.com/how-to-access-private-powershell-repository-from-azure-pipeline/ I still think it's sad to see that the issue has persisted for years, costs the community loads of time and frustration and nobody is bothering to fix it (reliably)... |
I ran into the same problem as many here, where you are constantly taken to the device flow even thought it seems like you should not be. But using the troubleshooting tips for the Azure Artifacts Credential Provider I figured out that our Azure DevOps authentication setup required multifactor authentication. Maybe that's why I was getting the device flow so much? But even if that's not it, I found a reasonable alternative that means I don't need to enter credentials all the time. The key is to setup the So basically this:
Setting up the |
@twinter-amosfivesix can you try using our latest prerelease version (can be found here). There is an integration with the SecretMangement module that allows for a smoother experience with handling credentials and credential persistence. |
@twinter-amosfivesix that's a pretty hefty amount of prerequisites. I was just trying to come up with some simple instructions for people to install a utility module from our Azure Artifacts. For CI/CD that's fine, but just to get a module that's a lot of hoops. @alerickson I tried the latest prerelease and couldn't get it working but maybe the steps are different since all the commands changed in psg 3.0. IDK... I'm giving up on this and telling people to store their pat in a file and pass -Credential everywhere. Nothing else works. |
@CodyBatt Yes credential management is different in PowerShellGetV3. It relies on Microsoft.PowerShell.SecretsManagement module, and you can look at this blogpost to get familiar with SecretsManagement, install that module and set up a vault. In order for credential persistence to work with PSGet, it needs SecretsManagement, otherwise if it's not there it will automatically give an error. After the vault is set up with SecretsManagement then all you need to do is create a PSCredentialInfo object like this example here (which assumes you have a vault named You should register (or set) the repository with the We'll put out a blogpost by end of this month to show all the steps for working with Credentials in PSGetV3, thank you for sharing this feedback! |
@anamnavi Right, I tried to set it up with SecretsManagment and didn't get anywhere. Succinct documentation for getting it set up will be a big help. |
@twinter-amosfivesix In case you rely on the command during a pipeline, you don't even need to do it manually. It suffices to add a NuGet Authenticate step which creates the environment variable for you. |
Sorry I never got any notifications about replies. I was just trying this again recently and I was not getting the repeated prompt for credentials. Still using PSGetV2. So not sure what was going on there. And yes NuGet Authenticate is what you'd use in an Azure DevOps pipeline. I haven't gotten there yet. |
@twinter-amosfivesix are you able to try using PowerShellGetV3? If so, please see my earlier message about using credential management with PSGetV3, thanks! |
I did a deep dive today to come up with a cleaner process for using Azure Artifact Feeds that I could hand off to non-technical people. During that dive I found that the "easiest" work-around may just be to have Visual Studio installed. There's more detail below if anyone is interested. The cleaner process for downloading from feeds using PowerShellGet v2 that I came up with today follows. One time do this:
That gets you the latest version of PowerShellGet and installs the Azure Artifacts Credential Provider. You will need to restart your PowerShell window after you've done the above steps. Then in PowerShell you can do this:
The VssCredentialProvider variable can have "netfx" replaced with "netcore" if you're running in PowerShell Core. You can get around the credentials request by installing Visual Studio due to a bug where PowerShellGet presumes that Windows thus always fails the first check for the credential provider and falls back to "vswhere" to locate the provider. If you don't have Visual Studio installed then the check fails. However, even if you solve the problem by pointing $env:NUGET_PLUGIN_PATHS to the credential provider you've only won half the battle. Your registration will work and even I hope this helps anyone else having the same issue. |
@anamnavi did the blog post get created? Can you link it here? |
What is the status of this? It seems that The What's worse though is it seems that the latest version 3.0.23 of PowerShellGet has broken the I created the AzureArtifactsPowerShellModuleHelper module a while back to help solve this issue, but found that sometimes even with that module PowerShellGet 2.2.5 still couldn't access the feed and we'd need to use the prerelease v3 version. With v3.0.23 broken though, and older v3 versions delisted and thus can't be installed, there's not much we can do when v2.2.5 has issues. Here's a screenshot showing the issue. If you need any other information for troubleshooting let me know; I'm happy to provide anything that can help get this issue resolved. |
I noticed afterward that this issue is for PowerShellGet v2. I've opened this new issue in the PSResourceGet repo: PowerShell/PSResourceGet#1601 |
I don't know why #133 was closed when this is still so COMPLETELY BROKEN
We cannot work with repositories that require credentials unless we ...
... pass credentials
... with every,
... single
... call.
That's not how any of this is supposed to work.
For example, following the docs for the Azure Artifacts CredProvider, and the blog post from earlier this month we should be able to install the credential provider:
Set something like this:
Register the feed:
And get a list of modules:
But what actually happens is that with no error I get no results.
But if I try it with nuget:
It works fine, and I get a list of modules...
YOU'RE DOING IT WRONG
The problem is that PowerShellGet isn't looking up the credentials against the feed address.
Instead, it's looking up (or rather, relying on nuget to) the credentials against the final url with all the parameters in it. So we can make the
Find-Module
command work if we change the stored endpoint to this:And then re-run:
But this is because I've hard-coded the token to a particular search.
Of course the result is that when we don't use the environment variable (i.e.
Remove-Item ENV:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS
) and do aFind-Module
we get a "devicelogin" from the credential provider, but the credentials are cached for that specific URL, so if weFind-Module
for any other specific module, or try anything else (likeInstall-Module
), they will fail to find the cached credentials, and require going through the "devicelogin" again...The worst part is that each time we go through the device login, you're creating a new PAT token that you'll never re-use...
Please, fix it again.
The text was updated successfully, but these errors were encountered: