Bullseye securedrop-client nightlies symlink Python binary, causing AppArmor failures

[eloquence]

Note the contents of this package:
https://apt-test.freedom.press/pool/nightlies/s/securedrop-client/securedrop-client_0.7.0-dev-20220616-215030%2Bbullseye_all.deb

opt/venvs/securedrop-client/bin/
...
├── python -> /usr/bin/python3
├── python3 -> python
├── python3.9 -> python
...

In contrast, note the contents of the buster version:
https://apt-test.freedom.press/pool/nightlies/s/securedrop-client/securedrop-client_0.7.0-dev-20220616-213732%2Bbuster_all.deb

opt/venvs/securedrop-client/bin/
...
├── python -> python3
├── python3
├── python3.7 -> python3
...

In short, the Bullseye version symlinks to the system Python, while the Buster version links to a binary that's shipped with the package itself.

Our AppArmor rules for the securedrop-client binary just specify the python3 binary that's part of /opt:

https://github.com/freedomofpress/securedrop-client/blob/7357a268fa797cdefce3a92b2ad0b43834831700/files/usr.bin.securedrop-client#L23

When that's a symlink to the system Python, AppArmor will deny execution.

This is similar to what happened with the SecureDrop Client 0.5.0 release: a build environment discrepancy caused the Python binary to be symlinked, which caused AppArmor denials. At the time this was resolved with a hotfix release; see freedomofpress/securedrop-client#1367

Is there a difference in how we use dh-virtualenv between Bullseye and Buster, or a difference in behavior in the versions used to build the different packages?

[legoktm]

Just for reference, this was a change in the new version of virtualenv included in bullseye.

Compare (buster):

root@fd180608f788:/# python3 -m virtualenv -p python3 test && tree test/bin | grep python
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
/usr/lib/python3/dist-packages/virtualenv.py:1091: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
New python executable in /test/bin/python3
Also creating executable in /test/bin/python
Installing setuptools, pip, wheel...done.
|-- python -> python3
|-- python-config
|-- python3
|-- python3.7 -> python3

with bullseye:

root@8ee1348568f2:/# python3 -m virtualenv -p python3 test && tree test/bin | grep python
created virtual environment CPython3.9.2.final.0-64 in 119ms
  creator CPython3Posix(dest=/test, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv)
    added seed packages: pip==20.3.4, pkg_resources==0.0.0, setuptools==44.1.1, wheel==0.34.2
  activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
|-- python -> /usr/bin/python3
|-- python3 -> python
|-- python3.9 -> python

nothing to do with packaging, just one of those subtle changes when everything gets upgraded. Updating the apparmor profile seems like the correct fix to me.