Protecting Packer from bad plugins

The release cycle is important with plugins. Developing a plugin locally is one thing but using it in production should require a signed release. You can tag and release a version of your repo for the community to use. You should always sign releases to ensure malicious code doesn’t make its way into your plugin. GPG keys can be used to sign a release, and public keys can verify that the plugin matches what you shipped it with.

In addition to plugin signatures, it’s important to make sure your Packer template pins the correct, or at least minimal, release for your plugin in case the functionality changes. Remember, this can be specified at the top of a template. Also, for machines that don’t have the source code for building your plugin, it’s important to configure the source path. This will require a packer init command before the first build you attempt so that Packer can download the right release into the $HOME/...