sync/upstream + upgrade/security #34
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
We used to check if a ssh server returns an empty payload with a len(fi) < 0, which can never succeed as len never returns negative values. This commit changes the condition to an == instead.
Recently, an update to Windows's default SSH implementation added an extra check for the mark-of-the-web to their code, which if in verbose mode, ends-up producing an error log, and terminates the process with a non-zero error code, even if the transfer is successful. Because of this, scp transfers fail all the time in such an environment, and the recommended workaround for now is to set sftp as the transfer protocol, as this one sets the mark-of-the-web successfully, and therefore ends with a 0 error code. Since this is surprising behaviour to users, we add a paragraph to the docs, so they know about this workaround.
- Migrates the formats of links in Markdown content as part of the [Docs Content Link Rewrites project](https://docs.google.com/document/d/1WaSyvoVPS-YCNiSPX0ynGpvc1gySEcpbrRoQVhimQCA/edit)
Commit 34ed5d9 which consists of linting fixes essentially had an error in the code and the error check for `supported_os' was inverted in this commit, making shell-local fail on all supported OSes now. We re-invert this condition so it behaves as it used to.
The DSA signature algorithm is not considered secure anymore, and is actively deprecated in the Go crypto libs. To let users know that they should not use that anymore, we add a notice in the comments for the SSH private key options.
…from linting as the warning is not relevant.
Co-authored-by: Lucas Bajolet <[email protected]>
Go 1.19 has different formatting directives that appears to be causing conflicts with 1.18.
When generating the flattened structures for a HCL2-compatible config, we didn't prevent users from defining duplicate fields or tags, instead warning them. The warning in itself did not prevent the resulting structures from being generated, leading into a situation where the first definition of the arg/tag would have precedence over the subsequent definitions, leading to shadowing their definitions. To prevent this in the future, we immediately return an error when such a conflict is introduced, and signal to the user which attribute is problematic.
* Remove directory from matrix build for Windows config
Update cmd/packer-sdc/internal/mapstructure-to-hcl2/mapstructure-to-hcl2.go Co-authored-by: Lucas Bajolet <[email protected]>
…y for testing purposes This change is being made to allow the invocation of struct-markdown to work against the internal Packer testing repo. The purpose of the repo is to allow for automated testing against unreleased versions of the Packer SDK.
* Remove helper script used for checking go mods * Remove helper script for testing mismatch struct changes
The say/error/ask methods on Ui only accept formatted strings, which is a bit cumbersome to do at callsite every time we need to print out something formatted with dynamic information. To reduce that cumbersomness, we add some convenience alternatives to the Ui implementations in the SDK, so they now expose Sayf, Askf and Errorf in addition to the rest.
As it stands now, plugin developers can only specify a version's core semver-compatible version, and a prerelease. In usage though, some plugins use metadata to add some extra context on the binary that was built, like the git commit, or the delta between the last release and the current HEAD from which a plugin was built. This, coupled with the 1.11.0 changes to plugin loading and version support, means that we cannot support such a workflow with the current code, as we will now start enforcing proper semver for plugins, so we are at risk of having plugins either not load, or lose information when releasing. Therefore as an attempt to address those issues, we are adding official support in the SDK for metadata in versions. That change introduces two new functions: `NewPluginVersion` and `NewRawVersion`. Both are intended as replacements for the now deprecated `InitializePluginVersion`.
Since FormatedVersion was essentially the same thing as `String` with the extra GitCommit if defined, we change its implementation to rely on the code committed for String.
The go-version library we use for parsing versions from the plugin supports 4-segmented versions. This may not be ideal for us, as we want to limit the sprawling nature of plugin installations, which if we start accepting sub-patch version bumps, may become quite strange. The release workflows we offer as template does not take that into account, and I'm not sure our docs do as well. Since there are many unknowns here, 4-segmented version numbers are not semver-valid, and we do not know how tooling will react, we ultimately decide not to allow those in the SDK. If a developer tries to define a 4-segmented version number, the plugin will crash instantly, at least giving users a message quickly that the version number is invalid, and that they need to limit themselves to a 3-segment version number.
The SemVer function of a PluginVersion returns the version.Version instance bound to the PluginVersion. In former implementations of the structure, this could be nil in some cases, as only the version components were being registered, and the code would make sure that they were a valid semver version. Recent changes reorganised this code by making the semVer attribute always present, so while theoretically it could be nil, this would indicate a manipulation error. Therefore, we don't need to perform this check to re-create the semVer attribute, and by that change we fix the underlying issue that made semVer drop its pre-release/metadata parts when doing so.
* Update all tsccr approved actions ```shell tsccr-helper gha update -latest . ``` * Remove unused test coverage files
…nc/upstream_+_upgrade/security
RodrigoCMoraes
force-pushed
the
sync/upstream_+_upgrade/security
branch
from
1289daa
to
c15d441
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
v0.5.4-incognia