It’s been quite a journey getting to GA for the Salesforce DX CLI. Thanks to a ton of effort from our Trailblazer Community during our Pilot and through the Beta release, we have made it to GA! To the community members that participated with us to this point a huge thank you! Without your participation and feedback it would have been very difficult to create the product you need to embrace modern software development practices on the Salesforce Platform.
In an effort to create a robust and trusted platform that is the lynchpin for continuous delivery and integration we have implemented a plugin signature verification feature within the CLI.
The Heart of the CLI
Plugins are at the heart of the CLI. Indeed, all of the functionality that you have been using is implemented as a group of plugins. The very core of the Salesforce packaging and scratch org creation and management is handled with a plugin. The CLI also provides the ability for developers to create plugins that run in and leverage features of the CLI.
As Trust is our number one value here at Salesforce, so it is with the tools we provide. Signature verification provides a way to better understand and trust any plugin that you may install for the CLI. The signature provides a level of authenticity and author validation that otherwise might put your organization at risk. You should never install any software on you computer unless you know and trust the creator of the software. The same is true with plugins for the CLI.
As of Winter ’18 you will now see that when running sfdx plugins:install to install a user plugin there is a signature verification process. If the plugins provide a valid signature, they will install as they have done previously. If the plugin is not signed, you can still install it, but must explicitly acknowledge that you are installing an unsigned plugin. Code signing is a tried and true solution in the software industry.
CI and CD Impact
For CI and CD jobs, we have provided a mechanism whereby you can allowlist the plugins that you trust, even if they are not signed. This prevents the CLI from prompting you to explicitly trust the unsigned plugin. If a plugin’s name is listed in the allowlist, then instead of getting a prompt to trust the unsigned plugin, it will be installed automatically with a message indicating the plugin is trusted because it’s allowlisted.
Creating an allowlist is currently a manual process and requires that you add a specific file the CLI configuration directory.
On Linux and Mac this directory is located at
$HOME/.config/sfdx.
For Windows it is located at one of the two places shown below depending on your Windows configuration.
C:\Users\username\.config\sfdx
%LOCALAPPDATA%\sfdx
To add an entry to the allowlist, create a file named unsignedPluginAllowList.json at the correct location for your operating system. The json schema is just a simple array of strings as illustrated below.
A final note about installing plugins. If you are developing your own plugins, the mechanism used to install the plugin during development is to “link” you plugin source. When linking your plugin source signature verification process is not in play.
Keep Calm and CLI
As we get closer to finalizing the developer plugin interface and supporting CLI architecture, we will be providing more information on the steps you, as a plugin developer, need to take to sign your plugins. In the mean time, use the same diligence you would when installing other software on your computers. Carry on and continuously integrate and deploy!
Related Resources:
Salesforce CLI Developer Guide
Trailhead:
App Development with Salesforce DX
Continuous Integration using Salesforce DX