[Bug] gemini-enterprise deploy.sh silently installs tfenv, pins Terraform to 1.12.2, and mutates the user's PATH/.bashrc — overriding a newer Terraform with no opt-out

[JohnHales]

Bug Description

deploy.sh's check_dependencies() (lines 51–108) unconditionally installs tfenv if absent (git-cloning it to ~/.tfenv), prepends ~/.tfenv/bin to PATH, appends that PATH export to ~/.bash_profile and ~/.bashrc, and runs tfenv install 1.12.2 && tfenv use 1.12.2 — hardcoding Terraform 1.12.2 for the entire deployment. On a machine where the operator already installed a different Terraform (e.g. 1.15.7 in /usr/bin), this silently shadows it: after the script runs, terraform in any new login shell resolves to the tfenv shim (1.12.2), because the injected PATH entry precedes /usr/bin. There is no flag, prompt, or opt-out, and the override is barely surfaced in the script's output. If tfenv's default pin is later cleared, the operator is left in a broken state (tfenv: No default set) where terraform version fails outright.

Environment and Deployment Context

• Stellar Engine Version/Commit: main at commit 3728fc98
• Deployment Type:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Medium
  • FedRAMP High
  • DoD IL4
  • DoD IL5
  • Stand-alone / Custom
• FAST Stage (if applicable): N/A — blueprint tooling
• Affected Component: blueprints/fedramp-high/gemini-enterprise/deploy.sh (check_dependencies(), lines 51–108)
• Terraform Version: 1.15.7 pre-existing in /usr/bin (overridden to 1.12.2 by the script)
• GCP Provider Version: N/A

Steps to Reproduce

1. On a fresh VM, install Terraform 1.15.7 to /usr/bin (no tfenv present). Confirm terraform version → 1.15.7.
2. Run deploy.sh.
3. Open a new shell (or source ~/.bashrc). Run terraform version.
4. It now reports 1.12.2 — the tfenv shim, injected ahead of /usr/bin on PATH.

Expected Behavior

The script respects an already-installed, constraint-satisfying Terraform, or at minimum warns before installing tfenv, pinning an older version, and editing shell rc files — with a documented opt-out. (Declared constraints across the stages and blueprints are >= 1.7.4 / >= 1.10.2, which 1.15.7 satisfies, so the downgrade is not required for compatibility.)

Actual Behavior

tfenv is installed unprompted, Terraform is pinned to 1.12.2, and ~/.bashrc/~/.bash_profile and PATH are modified, silently shadowing the operator's newer Terraform. A later cleared pin leaves terraform non-functional.

Relevant Logs and Errors

tfenv is installed. Setting Terraform version to 1.12.2...
# later, in a fresh shell after the pin is cleared:
sed: can't read /home/<user>/.tfenv/version: No such file or directory
tfenv: [ERROR] Version could not be resolved (set by ... or tfenv use <version>)

Additional Context

Two operator-facing consequences worth fixing together: (1) unexpected environment mutation (PATH, rc files) and a silent Terraform downgrade with no opt-out; (2) the hardcoded 1.12.2 is well behind current stable and is applied even when a newer, constraint-satisfying Terraform is present. Suggested fixes: detect and respect an existing constraint-satisfying terraform; make the tfenv/version-pin behavior opt-in or warn + confirm before editing rc files; centralize the pinned version in a documented variable rather than hardcoding it. Same deploy.sh surface as the CMEK-discovery issue filed alongside this one. Especially impactful in a Stellar Engine environment where different versions of Terraform may be used between Stellar Engine and Gemini Enterprise if existing Stellar Engine Terraform Deployments need to be updated in the future.