This repository has been archived by the owner on Dec 18, 2024. It is now read-only.
Sync/upstream + upgrade/security #21
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Not sure why this was defined and returned, but the value was set, but never used, as such this is not useful to keep in the code, so let's simplify this now.
Since datasources are recursively evaluated depending on their dependencies, we don't need to pre-execute those that depend on nothing, as the recursive traversal of the datasources will take care of that for us.
When a datasource fails to be evaluated because a cycle has been detected, we point out one of the links of the chain now so that users have a better idea of what to look at.
Datasources use their attribute's expressions to determine whether or not they depend on another datasource, in order to get the list of dependencies and execute them before executing a datasource. This code may be useful later on for figuring out the dependencies for any block, so we move this code to the utils.go file, and use this for datasources.
The previous implementation of the GetVarsByType function worked only on top-level attributes, ignoring the nested blocks in the structure. This implies that if a datasource depends on another through an expression within a nested block, we may not execute it first, and then executing this datasource before its dependent is possible, resulting in an error in the end. This commit is an attempt at making this more reliable for HCL configs, but only works on configs lifted from HCL files for now. We need to make this more reliable for later iterations.
The enumeration for FlagSetFlags, which presumably was added when the Meta structure was introduced, aims to pre-populate the flagset for a subcommand with a series of arguments. However, despite it being documented, it is actually not used, and therefore can safely be removed from the codebase.
Bumps [@babel/traverse](https://github.com/babel/babel/tree/HEAD/packages/babel-traverse) from 7.17.9 to 7.23.2. - [Release notes](https://github.com/babel/babel/releases) - [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md) - [Commits](https://github.com/babel/babel/commits/v7.23.2/packages/babel-traverse) --- updated-dependencies: - dependency-name: "@babel/traverse" dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
With the removal of vendored_plugins we are no longer interested in tacking bundled plugins usage. For plugins such as file, null, or anything bultin into Packer we don't track because there is no way to install them outside of Packer, for now.
…ot installed This change updates hcl2_upgrade to not flag known plugin components, those used for generating the required plugins block, when upgrading a legacy JSON template to HCL2. Any unknown plugins will be installed after running packer init on the generated template so we don't error. We may want to suggest running packer init to install any missing plugins. * Move knownPluginPrefixes into the hcl2_upgrade command
When invoking `packer plugins install' to install a plugin, or `packer init', the checksum file would be installed with 0555 permissions. This led in turn to further attempts at installing the plugin will succeed, but the checksum file would not be updated, as it was marked non-writable by the owner of the file, leading potentially to a situation where the plugin binary and the checksum would be out-of-sync, but could not be updated unless the user changed it. To avoid such a problem, we write the checksum file with 0644 permissions, so the owner can read/write, while the other users can only read it.
When a user invokes `packer plugins remove', the plugin binary gets removed, but not the corresponding SHA256SUM file. This patch changes this so that when a binary is removed, so is its SHA256SUM file.
* Add BUSL 1.1 license badge * Update links to learn tutorials * Removed dated getting started example
The HCL2 docs on built-in functions contains a link to a non-existent section of the expressions page, so we update it to link to the general page, and to the string interpolation section, since it is a common use case.
If a user attempts to remove a plugin through the `packer plugins remove' subcommand, and the specified plugin is not installed, the command succeeds, but does nothing, and exits silently. This is not clear what is happening, and arguably, calling a command that does nothing, not even explain what went wrong, is not intuitive. Because of that, this commit changes how the command behaves in this case, stating what went wrong, and exiting with a non-zero status.
Just a simple doc title fix.
This change uses the GitHub CLI to obtain all pull-requests merged after the latest release to help with updating the Packer CHANGELOG.
If a plugin is installed in the PACKER_PLUGIN_PATH, and its version contains metadata, we reject it. This is because metadata is free-form data, which could then make it possible to have multiple conflicting versions of a plugin installed, so we don't support it and explicitely reject plugins like those. A valid plugin with metadata in its version information should be installed without its metadata part, so there can only be one variant of the plugin installed at a specific version.
Listing installed plugins on Windows requires the extension to be set in the ListOptions, otherwise they are not discovered. While working on the discovery code, and consolidating it in a single location, we've forgotten to pass the argument to ListInstallations, so that makes it impossible to automatically discover installed components on Windows. This commit fixes this issue for the plugins required, and the general discovery process during build/validate.
When Discovering plugins installed through the `Discover` function, we use the base name of the plugin binary we discovered preliminarly, then we match its name against a regex to extract the prefix for the plugin's components. Extracting the base path used to be done with `path.Base`, which while working perfectly on UNIX systems, does not on Windows as it uses `\\` as their path separator. To circumvent this problem, we use the `filepath` package to extract the base name of the plugin instead, making the discovery logic work again on Windows.
Packer does not rely on CGO and is not susceptible to CVE-2024-24787 vulnerabilities, but we are upgrading as a safeguard.
When updating the docs in prevision for Packer 1.11.0, we changed the templates that show how plugins are installed/discovered with commands like packer init. While doing so, a template had its component renamed to coolcloud, but the following prose did not change, making the text inconsistent. Since there are other mentions of myawesomecloud in the codebase, we choose to settle on this one for that example too.
Bumps [github.com/hashicorp/hcp-sdk-go](https://github.com/hashicorp/hcp-sdk-go) from 0.95.0 to 0.96.0. - [Release notes](https://github.com/hashicorp/hcp-sdk-go/releases) - [Changelog](https://github.com/hashicorp/hcp-sdk-go/blob/main/CHANGELOG.md) - [Commits](hashicorp/hcp-sdk-go@v0.95.0...v0.96.0) --- updated-dependencies: - dependency-name: github.com/hashicorp/hcp-sdk-go dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
When a server returns a code that is not 200, we error in the current state. This is not conformant to the HTTP norm, as anything in the 2xx range is considered a success, so the datasource should not error in this case. Therefore, this commit fixes the condition in which we report an error, so that anything in the 2xx range is now considered a success by the datasource.
Compared to Terraform, Packer was lacking a capability to encode/decode strings to/from base64-encoded text encoded with another encoding. This could be problematic in some cases, mainly when working with Windows, as most of the OS uses UTF-16LE as its standard encoding for many operations. Therefore, we take a page from Terraform here, and add those functions to what Packer supports in an HCL2 context.
The global `PACKER_CONFIG` config file was already deprecated from Packer core, but now with 1.11.0 since we remove support for mono-component plugins, we are also removing the capability for that config file to declare them. Instead of silently not using those, Packer will now error with a message pointing to the web docs on how to manage their plugins with the updated workflows for Packer 1.11 and above.
When remotely installing a plugin, constraints are used by Packer to determine which version of a plugin to install. These constraints can be arbitrarily complex, including operators and ranges in which to look for valid versions. However, the versions specified in those constraints should always be final releases, and not a pre-release since we don't explicitly support remotely installing pre-releases. This commit therefore addds checks to make sure these are reported ASAP, even before the source is contacted to list releases and picking one to install.
Since the release will happen soon, we are updating the changelog to list all the changes before that happens.
This got committed by accident into another PR, and since the change was not approved to begin with, its inclusion was a mistake, so we revert it now.
* IPE-727 first commit, adds release notes * content for the 1.11 release notes * updates to init CLI reference * updates to install plugins CLI reference * updates to source information on the packer block configuration reference * updated Packer configuration page * updated plugins installation overview page * updated plugins installation usage page * added Upgrades section * added outline for an upgrade page for this version * added comments for upgrade page outline * renamed install plugins mdx and added redirects * Apply suggestions from code review Co-authored-by: Lucas Bajolet <[email protected]> * fix nav * fix bad links * applying additional feedback * Apply suggestions from code review Co-authored-by: Lucas Bajolet <[email protected]> * integrated rationale into release notes * removed 'upgrade from older version' section in the upgrade instructions * docs: fill-in the upgrade/1.11 document * Apply suggestions from code review Co-authored-by: Wilken Rivera <[email protected]> * edits to upgrade 1.11 and release note * Apply suggestions from code review Co-authored-by: Lucas Bajolet <[email protected]> * Apply suggestions from code review Co-authored-by: Lucas Bajolet <[email protected]> --------- Co-authored-by: Lucas Bajolet <[email protected]> Co-authored-by: Lucas Bajolet <[email protected]> Co-authored-by: Wilken Rivera <[email protected]>
Since we released 1.11.0 today, we need to have main point to the next minor release of Packer so CI succeeds, otherwise we get an unexpected output for the version being out-of-date.
…_+_upgrade/security
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
It sync with upstream and upgrades the dependencies using dependabot as reference. The latter means it was just update what was strict necessarily apart what already was update by the upstream.
Why?
To fix security issues.
Output
https://github.com/inloco/packer/releases/tag/v1.12.0