Comment 13 for bug 1860369

Fixing this bug will have impact on the perceived environment variables.

Currently the environment definitions from application-level declarations are appended to the snap-level declarations and inherited environment.

Once this bug is fixed the result will be deterministic across all applications.
Currently the result differs depending on the type of application used.

I've prepared a program naughty-env that can be used to craft environment with duplicate keys and run an arbitrary program with it. I tested three cases: C program, Python 3 program, Bash and Dash (sh).

Programs that use libc for accessing environment key-by-key see the first definition ("old" in the snippet below). Shells seem to build a mapping, overwriting old values, see the last definition ("new in the snippet below).

$ ./naughty-env bash KEY=old KEY=new -c 'echo $KEY'
new
$ ./naughty-env dash KEY=old KEY=new -c 'echo $KEY'
new
$ ./naughty-env python3 KEY=old KEY=new -c "import os; k='KEY'; print(os.environ[k], os.getenv(k))"
old old
$ ./naughty-env $(pwd)/getenv KEY=old KEY=new KEY
KEY=old

Once we fix this bug all applications will behave like shell does. Specifically snap-exec will provide an environment block with just one definition of PATH (or any clashing variable). The value will depend on what is defined at each level in snap.yaml. If the value refers to the old value (e.g. PATH: $SNAP/bin:$PATH) then the result will contain the expanded value. If it doesn't it will just contain the new value.