Repository navigation
fix: add packer as its own opt-in role - #112
Merged
Merged
Conversation
Packer is the one HashiCorp tool we install: it is BUSL with no open-source fork, and image builds need it. It gets its own role, run only by --tags packer and pulled in by no persona, so a default or persona run installs nothing from HashiCorp. Ubuntu and Fedora take HashiCorp's repo. The signing key is staged, checked for exactly one primary key matching the fingerprint HashiCorp publishes (D55C0D1A...CA026560), and only then trusted. A mismatch removes the repo, keeps the previously trusted key and lands in the end-of-run warnings. A host still trusting the expired 798A...E701 key gets the new one, and the legacy hashicorp.list is removed so apt does not see the repo twice. macOS takes hashicorp/tap. --tags removals now takes terraform and vault only. It used to delete the HashiCorp repo, keyrings and tap as well, which broke Packer on every host it ran on. The remediation scenario asserts the repo and keys survive.
A host still trusting the superseded HashiCorp key fails every apt refresh, so the packer role could not get as far as replacing the key. The prerequisite install now drops the HashiCorp sources and retries when that refresh fails, and the repo is written back with the verified key further down. --tags removals unhooks the HashiCorp repo, its key and the tap again, but only where Packer is not installed. It runs before the terraform and vault removal, because that removal refreshes the apt cache too. The remediation scenario checks both branches, with a stand-in packer package on one host. Fedora now also checks the signature on HashiCorp's repo metadata. The molecule matrix converges packer on all four releases.
Contributor
|
Released in v2.24.13 -- https://github.com/hyperi-io/hyperi-developer/releases/tag/v2.24.13 |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Packer now has its own opt-in role.
--tags packerinstalls it from HashiCorp's signed repo, and nothing else ever runs it.tags: ['packer', 'never'].--tags all, every persona and--tags removalslist zero packer tasks.hashicorp.sources. Fedora uses ahashicorpyum repo with gpgcheck and repo_gpgcheck. macOS useshashicorp/tap.--tags packerrun. A failed apt refresh drops the HashiCorp source, retries, then writes it back with the verified key.--tags removalsstill removes terraform and vault. It removes HashiCorp's repo, keys and tap only when Packer is not installed. That fixes apt on hosts left with the old repo and no Packer, and keeps the repo where Packer needs it.Tested in containers:
Not run: macOS, and molecule itself (the scenarios were driven by hand). Also known: a host with Packer AND the old key still fails
--tags removalsat the terraform step until--tags packerruns.Done when
--tags packergives a working Packer from a verified repo and no default run ever touches HashiCorp.