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.

Closes hashicorp#142

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

The Packer SDK relies on encoding/gob for serializing hcldec.ObjectSpec
over RPC. The added test check that types implementing the HCL2Speccer
interface can be encoded/decoded without issue.

Starting in go-cty v1.11.0 support for encoding/gob was removed, which
causes the added tests to fail. This is expected and is meant to help
catch potential regressions moving forward.

Test results running go-cty v1.10.0
```
--- PASS: TestCommonServer_ConfigSpec (0.00s)
    --- PASS: TestCommonServer_ConfigSpec/Builder_Component_Server (0.00s)
    --- PASS: TestCommonServer_ConfigSpec/Datasource_Component_Server (0.00s)
    --- PASS: TestCommonServer_ConfigSpec/Provisioner_Component_Server (0.00s)
=== RUN   TestCommunicatorRPC
```

Test results running go-cty v1.13.1
```
2023/04/21 11:28:05 [WARN] Client is closing mux
--- FAIL: TestCommonServer_ConfigSpec (0.00s)
    --- FAIL: TestCommonServer_ConfigSpec/Builder_Component_Server (0.00s)
panic: ConfigSpec failed: gob: type cty.Type has no exported fields [recovered]
        panic: ConfigSpec failed: gob: type cty.Type has no exported fields

goroutine 299 [running]:
testing.tRunner.func1.2({0x10524fb60, 0x14000486530})
        /usr/local/go/src/testing/testing.go:1389 +0x1c8
testing.tRunner.func1()
        /usr/local/go/src/testing/testing.go:1392 +0x384
panic({0x10524fb60, 0x14000486530})
        /usr/local/go/src/runtime/panic.go:838 +0x204
github.com/hashicorp/packer-plugin-sdk/rpc.(*commonClient).ConfigSpec(0x14000475f08)
        /Users/dev/Development/packer-plugin-sdk/rpc/common.go:48 +0x24c
github.com/hashicorp/packer-plugin-sdk/rpc.TestCommonServer_ConfigSpec.func1(0x140004e5860)
        /Users/dev/Development/packer-plugin-sdk/rpc/common_test.go:44 +0x10c
testing.tRunner(0x140004e5860, 0x14000483dd0)
        /usr/local/go/src/testing/testing.go:1439 +0x110
created by testing.(*T).Run
        /usr/local/go/src/testing/testing.go:1486 +0x300
FAIL    github.com/hashicorp/packer-plugin-sdk/rpc      0.796s
```

```
~> go get github.com/zclconf/[email protected]
~>  go test ./rpc/... -v -run=TestCommonServer
=== RUN   TestCommonServer_ConfigSpec
=== RUN   TestCommonServer_ConfigSpec/Builder_Component_Server
    common_test.go:75: Call to ConfigSpec for Builder Component Server panicked: ConfigSpec failed: gob: type cty.Type has no exported fields
2023/04/21 14:31:27 [WARN] Shutting down mux conn in Server
2023/04/21 14:31:27 [WARN] Client is closing mux
=== RUN   TestCommonServer_ConfigSpec/Datasource_Component_Server
    common_test.go:75: Call to ConfigSpec for Datasource Component Server panicked: ConfigSpec failed: gob: type cty.Type has no exported fields
2023/04/21 14:31:27 [WARN] Shutting down mux conn in Server
2023/04/21 14:31:27 [WARN] Client is closing mux
=== RUN   TestCommonServer_ConfigSpec/Provisioner_Component_Server
    common_test.go:75: Call to ConfigSpec for Provisioner Component Server panicked: ConfigSpec failed: gob: type cty.Type has no exported fields
2023/04/21 14:31:27 [WARN] Shutting down mux conn in Server
2023/04/21 14:31:27 [WARN] Client is closing mux
--- FAIL: TestCommonServer_ConfigSpec (0.00s)
    --- FAIL: TestCommonServer_ConfigSpec/Builder_Component_Server (0.00s)
    --- FAIL: TestCommonServer_ConfigSpec/Datasource_Component_Server (0.00s)
    --- FAIL: TestCommonServer_ConfigSpec/Provisioner_Component_Server (0.00s)
FAIL
FAIL    github.com/hashicorp/packer-plugin-sdk/rpc      0.278s
FAIL
```

When attempting to set the bastion key/certificate for authenticating
with the bastion, we generally fallback to the ones defined by the SSH
configuration.

However, if the bastion SSH key is set, and not the certificate, but the
SSH connection's are, since the conditions are separate, we end-up in a
situation where the bastion's SSH key uses the one from the config, and
the certificate fall backs to the one from the SSH connection.

This in turn fails, as the certificate's public key matches the private
key from the SSH connection, and not the bastion's.

To avoid a situation like this, we only fallback to the SSH connection's
certificate if the bastion's SSH key isn't set.

* Remove module cache

When trying to figure out the exact behaviour of the ssh communicator
when copying directories, I found myself wondering what each log was
conveying.

To make it clearer what's happening on each step, we add some more logs
during the copy steps, and make the `creating directory' log a bit more
explicit, so we understand what's happening.

* boot_command: add menu special key

* Add menu special key

* Add menu special key

* vnc_driver: test menu key

* vnc_driver: test menu key

* Fix formatting generated with 1.20.3

In v1.11.0, the go-cty package dropped support for encoding/gob. Gob support is used
by the SDK to serialize HCL2 object specs over the wire. If a plugin or Packer upgrades
their version of zclconf/go-cty to one that does not contain Gob support the plugin will build
but crash when trying to run a build on an HCL2 template. By adding this check, a consumer of the SDK
will fail to compile if they are using an unsupported version of go-cty. This check is being added
as a guard to prevent Packer SDK consumers from becoming out of sync with unsupported go-cty versions.

```
~> go get github.com/hashicorp/go-cty v1.13.0
~> make dev
rpc/cty_encode.go:15:24 cannot use cty.Value{} (value of type cty.Value) as type gob.GobEncoder
```

* Add link to GitHub Issue

…/go-cty

In an effort to provide Packer plugins access to the github.com/zclconf/go-cty enhancements,
while still providing access to encoding/gob support the Packer team has forked the go-cty package under github.com/nywilken/go-cty.
This is a temporary fork that will be removed once it is no longer needed.

Refer to hashicorp#187

This commit updates github.com/hashicorp/hcl/v2 to the last known release of HCL/v2
that does not rely on v1.13.0 of github.com/zclconf/go-cty.

```
~> go fix ./...
filelock/filelock.go: fixed buildtag
multistep/commonsteps/iso_config_test.go: fixed buildtag
packer/cache_config_unix.go: fixed buildtag
packer/cache_config_unix_test.go: fixed buildtag
packer/cache_config_windows.go: fixed buildtag
packer/cache_config_windows_test.go: fixed buildtag
pathing/config_file_unix.go: fixed buildtag
pathing/config_file_unix_test.go: fixed buildtag
pathing/config_file_windows.go: fixed buildtag
pathing/config_file_windows_test.go: fixed buildtag
sdk-internals/communicator/ssh/communicator_test.go: fixed buildtag
template/parse_test.go: fixed buildtag

```

* Remove extra backticks from HTTP server documentation

* $ make generate

* packer-sdc: Add fix sub-command

Fix rewrites parts of the plugin codebase to address known issues or
common workarounds used within plugins consuming the Packer plugin SDK.

```
~>  ./packer-sdc fix -check ../../../packer-plugin-tencentcloud
Found the working directory
/Users/wilken/Development/linux-dev/packer-plugin-tencentcloud
gocty Unfixed!

```

* Update fix command

This change is major refactor of the fix command, and it's underlying
fixer interface. This change adds support for the `-diff` flag which
displays the diff between the unfixed and fixed files, if available.

Along with the refactor the ability to apply multiple fixes to the same
file without potential write conflicts where previous changes were
removed after reprocessing.

* Add a scan function that returns a list of files to apply a fix on
to provide flexibility in the future for collecting a list of files.

* Replace cmp.Diff with github.com/pkg/diff for better file diffs
* Return error when missing directory argument
* Add error handling when trying to read any scanned files

Old Output
```
~>  ./packer-sdc fix -diff ../../../packer
--- /home/vagrant/Development/packer/go.mod
+++ /home/vagrant/Development/packer/go.mod-fixed
@@ -213,3 +213,5 @@
 )

```

New Output
```
~>  ./packer-sdc fix -diff ../../../packer
--- /home/vagrant/Development/packer/go.mod
+++ Fixed: /home/vagrant/Development/packer/go.mod
@@ -213,3 +213,5 @@
 )

```

The way we install the SDK and its dependencies in plugins, using
go install, is incompatible with replace statements.

Therefore, we remove that statement from the go.mod, and leave the
responsibility of including that replace to plugins that import the SDK.

Before this commit, `packer-sdc fix' would only work on plugins that
import the SDK, but we also need to make `packer-sdc fix' compatible
with the SDK itself, so we add an extra check to packer-sdc so it
doesn't ignore the SDK when applying the replace fix.

Since we remove the `replace' statement from the go.mod, tests will fail
as the updated version of go-cty does not support gob, and some tests
rely on that by default as we init RPC to work with gob-encoded
payloads.

To avoid this failure in CI, we add an extra step to the go-test
workflow so that it amends the go.mod, tidies it to resolve missing
sums, and continues with testing afterwards

In go 1.19 changes to go fmt resulted in slightly different comment formatting for generated code.
Bumping to Go 1.19 ensures that the correct version of Go tooling is used formatting the generated code.

Since the SDK in v0.5.0 contains a release statement in its go.mod,
this makes it impossible to go install packer-sdc from a plugin.

Since those plugins rely on their Makefile to do this, we cannot change
them all at once, so we fixed the problem in the SDK code itself, and
v0.5.0 is broken, so we retract it in this commit.

Since the latest comment introduces a retract statement, with a comment
that contains `replace', the check failed, so we improve it to only
consider `replace' if they're the first thing on a line.

When running an acceptance test, we may need to invoke Packer with
extra flags to ensure it behaves as expected.

Therefore, we add this capability to the TestCase structure so it
injects them verbatim in the command-line.

When the code from a plugin differs from its generated FlatConfig, we
may encounter a nil object spec for the values in the output of a
component.
This translates as a nil dereferencing panic within the hcl library,
caused by a config and tags being out-of-sync.

To avoid users the hassle of delving in this code, and the hcl
library's, we preemptively panic in the SDK code, with a message
suggesting regenerating the code for the component's specs.

This change address the yaml.v3 advisory reported for v0.5.1
https://deps.dev/go/github.com%2Fhashicorp%2Fpacker-plugin-sdk/v0.5.1

The latest available release of github.com/dylanmei/winrmtest removes
its dependency on github.com/satori/go.uuid, which was affected by
CVE-2021-3539 https://deps.dev/advisory/osv/GO-2020-0018

Addresses vulnerability with improper rendering of text nodes in
golang.org/x/net/html

This change was made to address a number of vulnerabilities reported by govulncheck in Go 1.19.13
Support for Go1.19 is removed with this change. Moving forward the minimum Go version will be bumped after a
new Go minor version is released.

```
~>  govulncheck ./...
Scanning your code and 599 packages across 99 dependent modules for known vulnerabilities...

Vulnerability #1: GO-2023-2043
    Improper handling of special tags within script contexts in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-2043
  Standard library
    Found in: html/[email protected]
    Fixed in: html/[email protected]
    Example traces found:
      #1: multistep/commonsteps/step_http_server.go:123:2: commonsteps.StepHTTPServer.Run calls http.Server.Serve, which eventually calls template.Template.Execute
      #2: multistep/commonsteps/step_http_server.go:123:2: commonsteps.StepHTTPServer.Run calls http.Server.Serve, which eventually calls template.Template.ExecuteTemplate

Vulnerability #2: GO-2023-2041
    Improper handling of HTML-like comments in script contexts in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-2041
  Standard library
    Found in: html/[email protected]
    Fixed in: html/[email protected]
    Example traces found:
      #1: multistep/commonsteps/step_http_server.go:123:2: commonsteps.StepHTTPServer.Run calls http.Server.Serve, which eventually calls template.Template.Execute
      #2: multistep/commonsteps/step_http_server.go:123:2: commonsteps.StepHTTPServer.Run calls http.Server.Serve, which eventually calls template.Template.ExecuteTemplate

Your code is affected by 2 vulnerabilities from the Go standard library.

```

…1.13.3

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.

Bumps [github.com/zclconf/go-cty](https://github.com/zclconf/go-cty) from 1.10.0 to 1.14.4.
- [Release notes](https://github.com/zclconf/go-cty/releases)
- [Changelog](https://github.com/zclconf/go-cty/blob/main/CHANGELOG.md)
- [Commits](zclconf/go-cty@v1.10.0...v1.14.4)

---
updated-dependencies:
- dependency-name: github.com/zclconf/go-cty
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>

Bumps [github.com/hashicorp/hcl/v2](https://github.com/hashicorp/hcl) from 2.13.0 to 2.20.1.
- [Release notes](https://github.com/hashicorp/hcl/releases)
- [Changelog](https://github.com/hashicorp/hcl/blob/main/CHANGELOG.md)
- [Commits](hashicorp/hcl@v2.13.0...v2.20.1)

---
updated-dependencies:
- dependency-name: github.com/hashicorp/hcl/v2
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>

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.