Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[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

Closed
  • Is something wrong?
#114 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
shell, terraform
Domain
devops, infrastructure

Research direction

Start in blueprints/fedramp-high/gemini-enterprise/deploy.sh, especially check_dependencies() at lines 51–108, and reproduce the PATH and Terraform-version change from the listed steps. Trace how tfenv installation, the 1.12.2 pin, and shell rc-file edits interact. Done means an existing constraint-satisfying Terraform is respected and any tfenv, pinning, or environment mutation is warned about or opt-in with documented behavior.

Written by the indexing model from the issue text.

Description

Bug Gemini - Government Level of Effort - Low Priority - Medium

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.

Dominant language
HCL
Stars
51
Forks
21
Avg merge
1d 17h
Merged PRs (30d)
29

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/stellar-engine

All issues in google/stellar-engine

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.