Thanks for checking this out.
I could see how full environment expansion likely has security issues, but @zyga-snapd’s question seems valid.
If there are security issues, would it be possible to create a clean environment with the appropriate $SNAP* variables in it, and use that to do expansion in snap-exec (I think this is fairly common pattern)? Or some similar mechanism where at least $SNAP* variables can be interpolated.
2 quick arguments for this idea
simplicity and principle of least surprise. In general there seems to be a move to treat apps and hooks as similarly as possible (e.g. snapctl in apps, etc).
My use case is to define a constant set of paths, based below SNAP/SNAP_DATA/SNAP_COMMON, in one place. Then my hooks and my apps can use that as the one source of truth, keeping it DRY. I did have an env file that I manually sourced in each and every app wrapper and in the configure hook wrapper, but I would prefer to have that in the snap.yaml, where it’s more visible and less manual.
Also, the issue of the appended new line is quite annoying. I don’t know where there is coming from, but it isn’t from the yaml.