As maintainers of Packer and plugins, we ask our users to provide us
with the versions of Packer and the plugins they use when they open an
issue for us to review.
This is often misunderstood, and may be hidden in the logs, making it
harder for all of us to understand where to look.
This commit adds a log statement that reports the list of plugins used,
their version, and the path they've been loaded from.
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.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at https://hashi.co/license-faq, and details of the license at www.hashicorp.com/bsl.
* Update copyright file headers to BUSL-1.1
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
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 Docker images release-light and release-full are not to be built
locally from a dev build, but from a release, and the commands to build
those images are only referenced in CI, so we don't need to ship them as
part of the makefile.
In addition, those images are not straightforward to build from the
Makefile, as they require quite a few things from the environment, as
well as the binary installed in a specific location, which is never
setup by the rest of the Makefile.
Therefore, we opted to simplify the Makefile so that it only builds
docker-dev for local use.
In addition to the `release-light' target, we add a `release_full'
target to the Dockerfile, so that we can ship an image of Packer with
the official plugins pre-bundled in their latest version.
* 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.
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.
When setting a project id via the HCP_PROJECT_ID env the client will try to validate the project
by checking that it has an associated registry. If the project is invalid or not a valid UUID an error
will be displayed to the user
* Add comment to clarify usage of SDK loaded env. variables
HCP supports two types of service principals: Organization-level and project-level.
When a user tries to publish to an active HCP Packer registry using a plsp the client
fails when configuring the client due to a API permission error; namely plsp do not have
the permissions to query an org for a list of projects. Setting the HCP_PROJECT_ID does
not resolve the issue because the call to ListProjects is still executed.
This changes updates the client configuration params to obtain both the HCP Organization and
Project IDs that will be used for connecting to the HCP Packer registry. With this change
if a user provides a project Id via the HCP_PROJECT_ID environment variable no call to ListProjects will
be made. Instead the value will be take as is and used to create the connection. A user connecting with
a project level service principals must provide a valid HCP_PROJECT_ID in order to connect.
The action currently fails when trying to remove the stale or waiting-reply labels from issues
that do not actually contain the labels in question. This update adds a guard clause to only run the
action on issues containing at least one of the labels.
The GHA action used for adding comments or labels to issues untrusted by TSCCR
have been replaced with an approved set of actions. The updated workflows use
actions/github-script for adding comments or labels to an issue.
Related to: https://github.com/hashicorp/security-tsccr/pull/608
The Makefile would check for executable files inside the Packer
repository, and produce errors if one was detected and not explicitely
whitelisted through the `EXECUTABLE_FILES' Makefile variable.
This check was introduced a while back to avoid having executable files
in the repository, but this check can be problematic sometimes because
of how it is written, namely when building the website, which causes a
lot of JS executable files to appear in the hierarchy, and in turn this
causes the shell expansion to fail because of the large number of
arguments.
Since this test is not necessary for Packer to build or test, and since
it implies that we have to maintain the whitelist regex, we remove it
from the Makefile.
Since bundled plugins will be removed in an upcoming version of Packer,
this commit adds a new warning message whenever a template uses one such
plugin.
This warning has been implemented on build, validate, console and the
inspect subcommands.
In addition to warning about the upcoming change and potential issue
this will cause, this warning message proposes solutions to the user so
they know what they'll have to do in order not to rely on those bundled
plugins later.
In HCL2, if a template contains a `required_plugins' block, but the
required plugins are not installed, we print a warning.
Prior to this commit, this was reported as an error once per missing
plugin, which was redundant.
This commit changes that by gathering all the missing plugins once, and
printing them as a bullet list, so the message isn't redundant anymore.
Lucas Bajolet
Wilken Rivera
hashicorp-copywrite[bot]
Lucas Bajolet
Wilken Rivera
hashicorp-tsccr[bot]
Kévin Dunglas
dependabot[bot]
hashicorp-tsccr[bot]andhashicorp-tsccr[bot]
GaryNgandLucas Bajolet
akkuman