Azure trusted signing with service connection

[erijo]

The requirement to set AZURE environment variables interferes with the use of service connection to connect to the service from a devops pipeline (similar to this example).

I've gotten it to work by:

1. First running the AzureCLI@2 task to access the service connection and export the three environment variables.
2. Use az in a separate step to log in using the variables from step 1.
3. Run electron-builder with the environment variables set as this:

• AZURE_TENANT_ID=$(ARM_TENANT_ID)

• AZURE_CLIENT_ID='dummy'

• AZURE_CLIENT_SECRET='dummy'

  and this in azureSignOptions:

• "ExcludeEnvironmentCredential": "-Debug"

That will use the AzureCliCredentials. If the environment variables weren't required I think I wouldn't have to give dummy values nor pass the -ExcludeEnvironmentCredential flag to Invoke-TrustedSigning.

[mmaietta]

Hmmm, this is very interesting. Is there a way to determine that the az login was successful and credentials are valid for Invoke-TrustedSigning?
If there is, then we can hopefully relax the current implementation to detect it instead of relying solely on Env vars. If no easy way to access that data (similar to how azureOptions.publisherName is required since it can't be preemptively fetched), then the Env vars are the only logic flow on which I can rely.

[erijo]

AFAIK there's no way to know that az is logged in except trying to use the credentials.

Wouldn't it be better to just mention the different ways that authentication can be done and leave it to the invoked command to try the different methods? Since the default method can use a number of different methods it's hard to check them all

[mmaietta]

Can you run az account show while logged in and paste the stdout here? (with all values redacted) Just need to understand the structure of the response and what keys exist to see if I can detect and leverage that for checking before env vars need to be checked/enforced.

If not logged in, the stderr I receive is this, which I can definitely detect against:

$ az account show
Please run 'az login' to setup account.

[erijo]

This is the output (on stdout) when running az account show after step 2:

{
  "environmentName": "AzureCloud",
  "homeTenantId": "***",
  "id": "***",
  "isDefault": true,
  "managedByTenants": [],
  "name": "***",
  "state": "Enabled",
  "tenantId": "***",
  "user": {
    "name": "***",
    "type": "servicePrincipal"
  }
}

[mmaietta]

Can you try patching this file with the additional code below? In the initialize() function before this.verifyRequiredEnvVars()
node_modules/app-builder-lib/out/codeSign/windowsSignAzureManager.js

// check if Service Connection authentication is enabled
        try {
            const account = await vm.exec(ps, ["az", "account", "shouw"])
            const loginInfo = JSON.parse(account.trim())
            if (loginInfo.user != null) {
            // no need to check env vars, we're already authenticated
            return
            }
        } catch (error) {
            builder_util_1.log.info({ message: error.message }, "not able to process `az` login info")
        }

[erijo]

I tried it (with the small typo fixed: shouw -> show) but the command failed:

  • executing       file=pwsh.exe args=az account show
  • not able to process `az` login info  message=Exit code: 64. Command failed: pwsh.exe az account show
The argument 'az' is not recognized as the name of a script file. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
                                           Usage: pwsh[.exe] [-Login] [[-File] <filePath> [args]]

[erijo]

An alternative could perhaps be to skip the env check if azureSignOptions contains "ExcludeEnvironmentCredential": true (and update the params string construction to pass such an arg as -ExcludeEnvironmentCredential and not -ExcludeEnvironmentCredential true)?

[mmaietta]

That's a great idea, but I'm hesitant to filter out true for -ExcludeEnvironmentCredential true as I'm not sure I can write generic logic for parsing out true for what is meant to be utilized for custom "verbatim" CLI args. I could hardcode checking for that arg, which is somewhat the last-resort of an approach, so I'd like to exhaust other approaches first if we can come up with any