This repository has been archived by the owner on Dec 18, 2024. It is now read-only.
sync/upstream + upgrade/security #18
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
The active plugins that resided in a HashiCorp repository have been migrated to the integrations framework and no longer need to be listed within the plugins-manifest file.
Signed-off-by: guoguangwu <[email protected]>
Signed-off-by: guoguangwu <[email protected]>
When users call `packer init' on a template that does not specify a `required_plugin' block, the command succeeds but does nothing, which is not helpful for users that may expect their plugins to install. To remedy that problem, we now output a message like what `packer plugins required' does on templates without such a block, so that users have an idea of what to change in order to get the command to work.
This change updates the Ubuntu image being from 16.04 to something more recent.
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.
* Document the purpose of a source address * Add a note about non-GitHub source addresses containing one of more sub-folder parts
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.
…_+_upgrade/security
RodrigoCMoraes
force-pushed
the
sync/upstream_+_upgrade/security
branch
from
c806fa2 to
58bf74b
Compare
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?
Why?
To fix security issues.
Release
https://github.com/inloco/packer/releases/tag/v1.11.0