Env variable value exposure using multienv with incorrect variable in the chain

[bazilmarkov]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Overview of the Issue

By utilizing atlantis multienv configuration, exposing the entire chain of environmental variables values is possible if one of the variables has an invalid definition.

Reproduction Steps

test.sh returning the multiple environmental variables

#!/bin/bash
set -eu
set -o pipefail

VAR1=value1
VAR2="{\"error\":[\"error:\n\t*\"]}"
echo "VAR1=$VAR1,VAR2=$VAR2"

Repo.yaml

workflows:
  terraform:
    plan:
      steps:
        - multienv:
            command: './test.sh'
            shell: bash

Logs

Invalid environment variable definition: VAR1=value1,VAR2={"error":["error:\n\t*"]}

As a result, the VAR1 value is exposed. Expected behavior - only VAR2-related error is returned

Environment details

• Atlantis version: 0.33.0
• Deployment method: docker

[dosubot]

Hey @bazilmarkov 👋, I'm here to help you with any bugs, questions, or contributions you have. Let's work on resolving your issue together!

I found a similar open issue titled "multienv should not read from stderr" which might be related to your concern about error handling in the multienv command. This issue was last updated on October 09, 2024, but it currently has no comments or references ^[1].

Regarding your issue, the multienv command in Atlantis is designed to handle environment variable parsing and error reporting. If an invalid environment variable definition is encountered, it should return an error message indicating the invalidity, such as "Invalid environment variable definition" followed by the problematic input. However, it seems that in your case, the error handling is exposing the value of VAR1 when VAR2 has an invalid definition ^[2].

This behavior might be due to how the parseMultienvLine function processes the input string and handles errors. The function is supposed to return specific errors for invalid syntax, misquoted values, or remaining unparsed data, and the Run method formats these errors into a user-friendly message ^[2].

To address this, you might want to ensure that the error handling logic in your script or configuration is correctly set up to prevent exposure of valid environment variable values when an error occurs. If this is a bug or unexpected behavior, it might be worth reporting it as an issue in the Atlantis repository for further investigation.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}