Travis CI fork pull request builds cannot access encrypted environment variables

Answer to the Core Questions

1. Does Travis CI offer a supported way to grant encrypted variables to a selected fork PR or trusted contributor?

No. The platform‑wide security policy on travis-ci.com explicitly removes all encrypted environment variables—both secure: entries in .travis.yml and variables added via the repository settings—from the environment of any pull‑request build that originates from a fork. There is no per‑variable, per‑contributor, or per‑PR exception.

2. Which documented configuration keeps fork PR builds useful while preserving secret isolation?

• Define only non‑sensitive (public) variables in the repository settings; these are passed through to fork PR builds.
• Move secrets to an external secret store (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) and fetch them at runtime with a short‑lived token or OIDC.
• Guard secret‑dependent jobs with if: fork = false or if: type != pull_request so they run only on trusted commits (e.g., merges to protected branches).
• Disable fork PR builds entirely if they cannot function without secrets.

3. Is the restriction identical for secure: variables and settings‑defined variables?

Yes. Both types are encrypted at rest and are excluded from fork PR build environments.

Likely Explanation

Travis CI’s security model treats any build that can run arbitrary code from an untrusted contributor as a potential attack vector. By withholding encrypted secrets, the platform ensures that the logs of a public repository remain public and that external contributors cannot exfiltrate sensitive data. The "Build fork pull requests" toggle only controls whether the build is triggered; it does not influence secret injection.

Confirmed Facts (verifiable from the docs)

• Encrypted env vars are not injected into fork PR builds (see Travis docs – Environment Variables).
• Public (non‑encrypted) vars are available to fork PR builds.
• The restriction applies uniformly to secure: entries and repository‑settings variables.
• Travis CI offers no opt‑out or per‑PR secret exposure.

Practical Steps for Your Project

1. Audit your .travis.yml and repository settings. Separate public from private vars. Example:

   env:
     global:
       - MY_PUBLIC_VAR=foo
     matrix:
       - secure: # This will be stripped from fork PR builds
   

2. Move secrets to an external store. Example using AWS Secrets Manager:

   before_install:
     - pip install awscli
     - export MY_SECRET=$(aws secretsmanager get-secret-value \
         --secret-id my-secret-id \
         --query SecretString --output text)
   

3. Gate secret‑dependent jobs. In .travis.yml:

   jobs:
     include:
       - stage: integration
         if: fork = false
         script: run-integration-tests.sh
   

4. Consider disabling fork PR builds. In the repository settings under "Build fork pull requests", set to "Off" if the PRs cannot run without secrets.

Ask for Missing Diagnostic Detail

Do you need the secrets for integration tests that run on the fork PR itself, or can you move those tests to run only after the PR is merged into a protected branch?

Diagram Overview

Component	Behavior
Fork PR Build	No Encrypted Vars
Public Vars	Passed Through
External Secret Store	Fetched at Runtime
Job Gating	Run Only on Trusted Builds