Add additional environment variables

[timrid]

This PR allows briefcase to pass environment variables to the app via org.beeware.ENV, which are added in sys.environ.

The feature can be used, for example, to configure a remote debugger (see beeware/briefcase#2173). The use of org.beeware.ARGV for this purpose is not optimal, as ARGV should pass arguments from the user and briefcase parameters should not influence them.

It is not yet clear whether the environment variables should really be used for the remote debugger. This only makes sense if it is possible on all platforms. The tests on iOS are still pending, so this PR is marked as a draft for now.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

Seems like a reasonable idea. My only suggestion is to be more consistent with the Python standard library by using the name ENVIRON rather than ENV.

[timrid]

I have renamed org.beeware.ENV to org.beeware.ENVIRON.

I also asked myself whether it makes sense to transfer the main module via BRIEFCASE_MAIN_MODULE instead of via a separate resource file. This would be more consistent with Windows, Linux and macOS. Or are there other advantages of the resource file?

[freakboy3742]

I have renamed org.beeware.ENV to org.beeware.ENVIRON.

I also asked myself whether it makes sense to transfer the main module via BRIEFCASE_MAIN_MODULE instead of via a separate resource file. This would be more consistent with Windows, Linux and macOS. Or are there other advantages of the resource file?

There is - and it's related to what I've been saying on the Briefcase --debug ticket.

If the BRIEFCASE_MAIN_MODULE is exposed as an environment variable, then the behavior is controllable by the end user (or, controllable by the end-user's environment). That means an end user can set that environment and get the behavior - or, an attacker can exploit that behavior as a vector for an attack. In this case, an attacker would gain the ability to execute code that would run with the privileges of the main app.

By using a configuration file that has to be shipped (and signed) with the app bundle, that attack vector is reduced (if not eliminated).

I recognise that this is an inconsistency between the Linux, macOS and Windows stub apps, as they currently use environment variables. However, if we're making changes in this area, my inclination would be to move those platforms away from using environment variables. This would be trivial for the macOS case (we can use the same info.plist trick as iOS); Windows and Linux might be a little more difficult as there's no obvious file metadata that can be attached.

[timrid]

Okay, I understand the security concerns for the BRIEFCASE_MAIN_MODULE.

But nevertheless this is a useful feature to support the remote debugger. So I will remove the draft status.

Are there tests for this required in the Python-support-testbed? I could not find tests for org.beeware.ARGV that I could extend.

[freakboy3742]

Are there tests for this required in the Python-support-testbed? I could not find tests for org.beeware.ARGV that I could extend.

Ideally, yes - there would be a test (for both environment and argv handling) - but no, there isn't one at present (for either argv or environment handling).

Such a test is going to be a bit unstable, as it will require the environment invoking the test to use specific environment markers and command line arguments. If you're able to make something work, it would be great to add a test for that behavior; but if a test doesn't fall out reasonably easily, I'd be happy to open a ticket on the testbed repo and leave it at that.

[timrid]

I have not found an easy solution for testing, probably because I'm not that deep into the testbed yet. So I created a ticket.

[mhsmith]

This is a pain to test because of multiple layers of shells and quoting, but it looks like it works fine.