Unable to install an unverifiable plugin without interactive confirmation

[kyle-blair]

Note
Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI.
• You've searched both open and closed issues for related posts.
• You've used the doctor command to diagnose common issues.
• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

This is somewhat an extension of #2540. The workaround stated in that issue works on local machines but not from our build servers. The plugin install fails trying to verify signature because the requests to developer.salesforce.com are blocked. I see two approaches to work around this:

1. Bypass signature verification via a config file.
2. Install the plugin via the git url (which also requires bypassing signature verification).
   The problem with both is that signature verification is not bypassed. Per the documentation, I placed the following file in both "$HOME/.config/sf and $HOME/.config/sfdx:

[
	"sfdmu",
	"https://github.com/forcedotcom/SFDX-Data-Move-Utility",
	"SFDX-Data-Move-Utility"
]

With option 1, using sfdmu as the plugin, it still tries to verify the signature which fails due to the firewall restriction. With option 2, I'm not sure what value to use to identify the plugin when installing via git url. As you can see, I tried several options and none of them work.

Steps To Reproduce

Steps 1-3 are the same for both options.

Option 1

1. Configure a proxy/firewall that blocks access to developer.salesforce.com.
2. Place the following contents in a file at "$HOME/.config/sf following the documentation.

[
	"sfdmu",
	"https://github.com/forcedotcom/SFDX-Data-Move-Utility",
	"SFDX-Data-Move-Utility"
]

4. Run sf plugins install sfdmu.

Option 2

1. Configure a proxy/firewall that blocks access to developer.salesforce.com.
2. Place the following contents in a file at "$HOME/.config/sf following the documentation.

[
	"sfdmu",
	"https://github.com/forcedotcom/SFDX-Data-Move-Utility",
	"SFDX-Data-Move-Utility"
]

4. Run sf plugins install https://github.com/forcedotcom/SFDX-Data-Move-Utility.

Expected result

With either option, the verification override mechanism should result in the verification being skipped, or at least a failed verification being ignored.

Actual result

With both options, the verification is still performed, and still results in a failure of the plugin installation. For option 1, it tries to hit developer.salesforce.com for verification of a known plugin and that fails due to the firewall. This causes the whole command to fail, even though I've configured it to skip verification. For option 2, it interactively prompts to accept installation of an unverified plugin which fails when run non-interactively (i.e. from a build server that's running that command while building a docker image). Further, it is unclear what value to use to skip verification when you're installing a plugin via a git url. As you can see, I have tried several options.

System Information

{
  "architecture": "darwin-x64",
  "cliVersion": "@salesforce/cli/2.17.14",
  "nodeVersion": "node-v20.9.0",
  "osVersion": "Darwin 22.6.0",
  "rootPath": "/Users/user/.nvm/versions/node/v20.9.0/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.1 (core)",
    "@oclif/plugin-commands 3.0.6 (core)",
    "@oclif/plugin-help 6.0.5 (core)",
    "@oclif/plugin-not-found 3.0.3 (core)",
    "@oclif/plugin-plugins 4.1.7 (core)",
    "@oclif/plugin-search 1.0.6 (core)",
    "@oclif/plugin-update 4.1.3 (core)",
    "@oclif/plugin-version 2.0.6 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.2 (core)",
    "@oclif/plugin-which 3.0.8 (core)",
    "@salesforce/cli 2.17.14 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.26 (core)",
    "community 2.4.6 (user)",
    "custom-metadata 2.2.8 (user)",
    "data 2.6.3 (core)",
    "deploy-retrieve 1.20.0 (core)",
    "info 3.0.1 (core)",
    "limits 3.0.1 (core)",
    "login 2.0.1 (core)",
    "marketplace 1.0.2 (core)",
    "org 2.11.8 (core)",
    "packaging 1.26.4 (user)",
    "schema 3.0.1 (core)",
    "settings 2.0.2 (core)",
    "sobject 0.2.15 (core)",
    "source 2.11.0 (core)",
    "telemetry 3.1.0 (core)",
    "templates 55.5.18 (core)",
    "trust 3.0.2 (core)",
    "user 2.3.42 (core)",
    "sfdmu 4.32.1 (user)"
  ]
}

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[github-actions]

Hello @kyle-blair 👋 None of the versions of sf you shared match the latest release.

Shared: 2.17.14
Latest: 2.19.8

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue.
You can also try the rc and nightly releases! (docs)

After updating, share the full output of sf version --verbose --json

[mshanemc]

@kyle-blair here's the code that's handling the connection errors when we go to verify the signature. It's looking for a http 403.

What error is your proxy/firewall throwing?

Edit (source link): https://github.com/salesforcecli/plugin-trust/blob/4631c122adeaaf1c98c5eb833ed650082b3677fd/src/shared/installationVerification.ts#L472

[kyle-blair]

@mshanemc thanks for that! I'll have to get better at looking through the source myself first. Unfortunately, it looks like the response I'm seeing is slightly different.

https-proxy-agent:parse-proxy-response got proxy server response: 'HTTP/1.1 403 URLBlocked'
sf:@salesforce/plugin-trust:hooks:plugins:preinstall:verify:signature HTTPError: Response code 403 (URLBlocked)

[kyle-blair]

What do you think about loosening up the 403 comparison like so?

if (err.name === 'NotSigned' || err.message && err.message.includes('Response code 403'))

I could open that pull request if that seems acceptable.

[mshanemc]

yeah, we could handle all 403.

[kyle-blair]

Pull request incoming.

[mshanemc]

it's a pretty small change I can do if doing the PR isn't convenient.

[git2gus]

This issue has been linked to a new work item: W-14581522

[kyle-blair]

it's a pretty small change I can do if doing the PR isn't convenient.

The only delay was waiting for internal approval late yesterday afternoon, which is complete now. I'd love to get an open source contribution under my belt if you can wait an hour until I get online.

[mshanemc]

I made one change and merged it. It'll go into tonight's nightly

[jshackell-sfdc]

This issue is addressed in 2.21.7 (Dec 13, 2023). Thank you!