feat(Config): read from QubesDB if available; otherwise from environment variables

[cfm]

Status

Work in progress

Description

Updates the Client for compatibility with freedomofpress/securedrop-workstation#956.

• Must be released in tandem with configure VMs via vm-config.* features securedrop-workstation#956
• Blocked on Poetry fails with system-site-packages on bullseye #1882
• Blocked on Drop bullseye support #1958
  • Then rebase from main

Test Plan

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

• I have updated the AppArmor profile
• No update to the AppArmor profile is required for these changes
• I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

• I have written a migration and upgraded a test database based on main and confirmed that the migration is self-contained and applies cleanly
• I have written a migration but have not upgraded a test database based on main and would like the reviewer to do so
• I need help writing a database migration
• No database schema changes are needed

[legoktm]

This is really great, I think it demonstrates the value in this approach pretty well

[cfm]

44cd324 gives a naïve wrapper script with-qubesdb like so:

user@sd:~/securedrop-client$ ./with-qubesdb -h
usage: with-qubesdb [-h] [-k KEY]

Use -k/--key one or more times to read the specified key from QubesDB. All subsequent
arguments will be interpreted as the command to be invoked with those keys set as
environment variables.

optional arguments:
  -h, --help         show this help message and exit
  -k KEY, --key KEY
user@sd:~/securedrop-client$ ./with-qubesdb -k SD_PROXY_ORIGIN env
SD_PROXY_ORIGIN=foobar
user@sd:~/securedrop-client$ ./with-qubesdb -k SD_PROXY_ORIGIN -k NONESUCH env
SD_PROXY_ORIGIN=foobar
NONESUCH=

My claim is that with envsubst this is all we need...

user@sd:~/securedrop-client$ cat > i-know-this-isnt-a-real-tor-config.json <<EOF
{"hidsrv": "\${SD_PROXY_ORIGIN}"}
EOF
user@sd:~/securedrop-client$ cat i-know-this-isnt-a-real-tor-config.json | ./with-qubesdb -k SD_PROXY_ORIGIN envsubst
{"hidsrv": "foobar"}

[legoktm]

I'm not opposed to envsubst but I don't really see the advantage of using it - in the with-qubesdb script, couldn't we use something like basic Python string formatting (or even jinja2) and avoid the indirection of setting things in the environment?

The changes you made to the QubesDB usage in the client LGTM.

[cfm]

On Mon, Mar 11, 2024 at 08:23:59AM -0700, Kunal Mehta wrote: I'm not opposed to envsubst but I don't really see the advantage of using it - in the with-qubesdb script, couldn't we use something like basic Python string formatting (or even jinja2) and avoid the indirection of setting things in the environment?

Perhaps my twelve-factor bias is showing here: I'd much rather use the environment, which is scoped because ephemeral, than deal with files. The counterargument is that scoping the environment this way puts us in subprocess territory, whereas if we deal with files we can just write them and get out of the way. :-) Forthcoming....

[cfm]

At c1734bf:

user@sd:~/securedrop-client$ cat > i-know-this-isnt-a-real-tor-config.json.jinja2 <<EOF
> {"hidsrv": "{{ SD_PROXY_ORIGIN }}"}
> EOF
user@sd:~/securedrop-client$ ./with-qubesdb -k SD_PROXY_ORIGIN i-know-this-isnt-a-real-tor-config.json.jinja2 i-know-this-isnt-a-real-tor-config.json
user@sd:~/securedrop-client$ cat i-know-this-isnt-a-real-tor-config.json
{"hidsrv": "foobar"}

[cfm]

@legoktm, do you see a way around the Any annotation here if Config is populated via setattr()?

[cfm]

Rebased from main; envsubst approach removed in favor of Jinja templating; and typing corrected, with one caveat in https://github.com/freedomofpress/securedrop-client/pull/1883/files#r1550649219.