-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HPR-1281] core: Fix custom plugin loading in current working directory #12544
Conversation
fa6d6d1
to
48a933c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, good catch for the checksum issue and the go 1.19 change
Starting with Go 1.19 the loading of binaries from the current working directory was deemed as a possible security problem. Thus the use of exec.Command or exec.LookPath no longer resolves an executable within the current working directory. This change updates the discover logic to return absolute paths for any discovered plugin, which is called directly when passed to exec.Command or exec.LookPath. By doing this Packer is able to load a custom plugin sitting in the current working directory as it did in version prior to v1.9.2.
When copying a plugin's checksum file (packer-plugin-*_SHA256SUM) installed by `packer plugins install` or `packer init` into a separate directory the file may be copied with the executable bit turned out. If unchanged after the copy, Packer would discover the checksum file as a possible plugin match and error when trying to execute describe on the plugin look a like. This change adds a checksum file test to the plugin matching logic. If the discovered plugin name is a checksum it is excluded from the discovered plugin list.
* Add test case for loading plugin in CWD * Add test case to validate checksume files are ignored * Update Discover to include CWD "." in PluginFolders if KnowPluginFolders is unset
e5b026a
to
2f698e8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested this locally and was able to run my locally built plugins
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Starting with Go 1.19 the loading of binaries from the current working directory was
deemed as a possible security problem. Thus the use of exec.Command or exec.LookPath no longer resolves an executable within the current working directory. This change updates the discover logic to return absolute paths for any discovered plugin, which is called directly when passed to exec.Command or exec.LookPath. By doing this Packer is able to load a custom plugin sitting in the current working directory as it did in version prior to v1.9.2.
When copying a plugin's checksum file (packer-plugin-*_SHA256SUM) installed by
packer plugins install
orpacker init
into a separate directory the file may be copied with the executable bit turned out. If unchanged after the copy Packer would discover the checksum file as a possible plugin match and error when trying to execute describe on the plugin look a like. This change adds a checksum file test to the plugin matching logic. If the discovered plugin name is a checksum it is excluded from the discovered plugin list.Closes #12543