nightroman / Invoke-Build

Build Automation in PowerShell

Home Page:https://github.com/nightroman/Invoke-Build/wiki

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Invoke-BuildExec spitting out service principal secret as current directory

codepic opened this issue · comments

I just found out on one of our build script that Invoke-BuildExec shows part of the command output as cd. Possibly confused by piping into ConvertFrom-Json.

image

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Script     5.9.12                InvokeBuild                         {Build-Checkpoint, Build-Parallel, Invoke-Build}
Name                           Value
----                           -----
PSVersion                      7.3.2
PSEdition                      Core
GitCommitId                    7.3.2
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
azure-cli azure-cli-core azure-cli-telemetry extensions
--------- -------------- ------------------- ----------
2.44.1    2.44.1         1.0.8               @{aks-preview=0.5.117; application-insights=0.1.16; automation=0.2.1; azure-devops=0.25.0; costmanagement=0.2.1; k8s-extension=1.3.7}

exec -echo {...} prints $pwd as cd $pwd, see

Write-Build 8 "cd $pwd"

Is it possible that your $pwd contains such a value? If yes then it all works as expected.

If such "echo" is not welcome then do not use this switch with exec.

Hmm, an idea. Do you by any chance use the PowerShell automatic variable $pwd (current location) as a some sort of password?

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_automatic_variables?view=powershell-7.3#pwd

If yes, I'd say it is not a good idea to mess with PS automatic variables, who knows when and how this bites.
But this is up to the author / script, indeed, no problem.

In the meantime I'll think of printing cd $global:pwd to minimize chances of such issues.

Yes, you're right. There was another function within the same module assigning $script:pwd which within a module means module-wide scope.

The $global:pwd sounds good 👍

Question: Why not Get-Location? Because it's isn't available in PowerShell 2.0?

Benefit from Get-Location would be that it's supported by Pester Mock. Not that I can think off the shelf a scenario where one would want to use it...

Describe "Get-Location" {
	Context "Mocking works..." {
		BeforeEach{
			Mock Get-location { return @{ Path = 'D:\' } }
			$script:result = Get-Location
		}
		
		It "should work" {
			$script:result.Path | Should -Be 'D:\'
		}
	}
}

Why $pwd? Well, why not? Using Get-Location may have some advantages (and disadvantages). Just like using $pwd, some advantages and disadvantages.

Done, v5.10.2