Initially, my_envp equals to *new_envp, then it is modified. Those
modifications are lost when *new_envp is used after that.
The (possibly) discarted modifications to env. variables affect
SBOX_DISABLE_MAPPING, SBOX_DISABLE_ARGVENVP and __SB2_REAL_BINARYNAME.
Regarding SBOX_DISABLE_MAPPING, consider a host executable being
executed by sb2 and trying to execute another host executable. With
mapping not disabled, the other executable may be mapped to a different
executable under target/tools root instead. In most cases this is likely
to happen unnoticed. It breaks when there is an incompatibility between
those, e.g., when the host executable is a GCC compiler trying to
execute some of its internal tools - an i486 host compiler may end up
executing an arm assembler this way.
Trying to explain why *new_envp was used here, I don't believe it was a
typo. At the same time I don't believe it was intentional to change the
logic this way. I can't think of a reason to discard changes to the
afforementioned env. vars. To me it seems inevitable to keep them set.
Also, change was introduced with commit
3f042f36 (Execs: Postprocess native
dynamic binaries with C code) whose only objective seems to be
reimplementation of some Lua code in C. Maybe it was done to deal with
some compiler bug and no one noticed it breaks things, as this only
breaks in rather special cases like the one mentioned above.