Cabal 3.14.1.0 invokes test binaries with a corrupt (duplicated) environment variable list

[Rufflewind]

Describe the bug

cabal 3.14.1.0 invokes test binaries with with an invalid environment variable list that contains duplicate entries.

As documented by POSIX: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html

If more than one string in an environment of a process has the same name, the consequences are undefined.

This is causing the directory CI tests to fail: https://github.com/haskell/directory/actions/runs/12595046406

The bug is not found in cabal 3.12.1.0.

To Reproduce

-- Main.hs
module Main where
import Data.List (sort)
import System.Environment (getEnvironment)
main = print =<< fmap sort getEnvironment

-- foo.cabal
cabal-version:      3.0
name:               foo
version:            0.1.0.0
build-type:         Simple

test-suite test
    build-depends:    base
    default-language: Haskell2010
    main-is:          Main.hs
    type:             exitcode-stdio-1.0

$ cabal test

Actual output

[("COLORTERM","truecolor"),("COLORTERM","truecolor"),("DBUS_SESSION_BUS_ADDRESS",...),("DBUS_SESSION_BUS_ADDRESS",...),...

Expected behavior

There should not be any duplicates, i.e.

[("COLORTERM","truecolor"),("DBUS_SESSION_BUS_ADDRESS",...),...

System information

• Operating system: Tested on Ubuntu (Github Actions) + WSL Debian
• Reproducible on cabal 3.14.1.0. Not reproducible on cabal 3.12.1.0.
• Reproducible on several GHC versions.

[ulysses4ever]

Hey! Thanks for the report! Presumably, this issue doesn't lead to a failure in any case, does it? I'm asking because it'd be good to understand how severe it is. On the surface it looks rather benign to me.

[Rufflewind]

It may cause uses of environment variables in tests to behave incorrectly. In the theoretical worst-case scenario, it could lead to security risks, e.g.

• https://wiki.sei.cmu.edu/confluence/display/c/ENV02-C.+Beware+of+multiple+environment+variables+with+the+same+effective+name
• https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html#ENV-STORAGE-DANGEROUS

The severity of this issue in practice is unclear. The most probable scenario I can think of is that a fragile piece of code that scrubs sensitive data out of environment variables could misbehave due to the duplication, causing credentials to get leaked through, say, logs. A bit of a stretch but not impossible.

[mpickering]

I have written a test and you are right that with 3.14, many duplicates are passed.

With 3.12, the p_datadir variable is passed twice.

[mpickering]

I see the issue was introduced in ee11ac6