Since this feature is no longer something we plan to activate later, as
it contradicts with our efforts to remove bundled plugins, and
encouraging users to move to either manually installing plugins, or
managing them through `packer init', we clean-up the code for this
feature.
Since we added support for PLSPs recently, and it will be released as part of 1.9.3, we add some documentation regarding the environment variables we added, and a note regarding their relation to PLSP support.
The version of the golang.org/x/net we used (v0.8.0), is vulnerable to a
rendering issue, potentially escaping text that should not be, which can
enable other attacks then.
Packer itself is not vulnerable to the CVE as we don't render web pages,
but security checks do point it as an issue, so we fix it by updating
the dependencies.
CVE refrerence: GO-2023-1988
The `packer init' command's wording was not clear, so it was changed in
a preceding commit, and this commit aims to add more details on how the
command is meant to be used, along with a simple example.
`packer init' is meant to be invoked on a template file or a directory.
This was described in the command-line help message as
`[template.pkr.hcl|folder]'.
Because this is encapsulated between square brackets, this could be
taken as an option instead of a positional, mandatory argument.
This commit changes the wording to adopt a similar convention as `packer
build', so the two are consistent in how they are invoked, and to avoid
mistaking this argument as optional.
* Add test case for loading plugin in CWD
* Add test case to validate checksume files are ignored
* Update Discover to include CWD "." in PluginFolders if KnowPluginFolders is unset
When copying a plugin's checksum file (packer-plugin-*_SHA256SUM) installed by `packer plugins install` or `packer init`
into a separate directory the file may be copied with the executable bit turned out. If unchanged after the copy, Packer would
discover the checksum file as a possible plugin match and error when trying to execute describe on the plugin look a like. This change
adds a checksum file test to the plugin matching logic. If the discovered plugin name is a checksum it is excluded from the discovered plugin list.
Starting with Go 1.19 the loading of binaries from the current working directory was
deemed as a possible security problem. Thus the use of exec.Command or exec.LookPath no longer resolves
an executable within the current working directory. This change updates the discover logic to return absolute
paths for any discovered plugin, which is called directly when passed to exec.Command or exec.LookPath. By doing
this Packer is able to load a custom plugin sitting in the current working directory as it did in version prior to v1.9.2.
hc-github-team-es-release-engineering
Lucas Bajolet
hc-github-team-packer
Jamie Finnigan
Wilken Rivera
Wilken Rivera
Lucas Bajolet