fix: prevent path traversal in GitHub plugin getter filename

[tanmay-hc]

What

ExpectedFileName in the GitHub plugin getter returned the raw filename from the remote SHA256SUMS release asset unchanged. That string was used directly in filepath.Join to build both the temp execution path and the final install path, allowing a crafted filename containing ../ sequences to escape the plugin directory.

Why it matters

An attacker who controls a GitHub plugin release (malicious plugin, or a compromised legitimate one) could write the plugin binary to an arbitrary path writable by the victim user, and have it executed immediately via exec.Command(path, "describe") at packer init time — before the plugin is ever used in a build.

The release getter (packer/plugin-getter/release/getter.go) was never affected because it already reconstructed the filename from validated fields instead of trusting the remote string.

How

Mirror the release getter's approach: reconstruct the expected filename entirely from the fields Init() already parsed and validated (BinVersion, ProtVersion, Os, Arch, Ext). The raw remote zipFileName argument is ignored.

For a well-formed filename the output is identical to before, so there is no impact on any existing legitimate plugin.

Changes

• packer/plugin-getter/github/getter.go — fix ExpectedFileName
• packer/plugin-getter/github/getter_test.go — update test to use a populated entry; add explicit traversal-filename assertion
• packer/plugin-getter/plugins_test.go — update mockPluginGetter to mirror the real implementation so integration tests exercise the fixed code path

Backward compatibility

No breaking change. A legitimate plugin filename round-trips through Init() → ExpectedFileName() to the identical string as before.