Closed legoktm closed 1 year ago
Thanks for investigating this. Do you think there are any additional guardrails we can/should add (eg in the sync-wheels
script, in developer documentation, etc) to avoid potentially contaminated or stale build environments? AIUI making sure the virtual environment is up to date before building is still a manual process.
Yes -- I think that should be part of containerizing the build process (https://github.com/freedomofpress/securedrop-engineering/pull/20) so we can just automate/script that the venv is up-to-date, it's using a non-root user, etc., instead of implementing checks everywhere and complaining.
Makes sense. I'm going to approve https://github.com/freedomofpress/securedrop-builder/pull/458 without any additional guardrails then since the readme mentions removing and rebuilding the venv already, and since the container.sh
stuff exists and can be adapted. The no-build-isolation
feels a bit like an extra footgun, but we have a proposed direction in mind already to mitigate. Thank you!
Confusingly the
pip download
command in build-sync-wheels tries to build the packages we're downloading, except it does not use our bootstrap, so if the package is currently broken when building from source (as pyyaml currently is - https://github.com/freedomofpress/securedrop-client/issues/1681) then the download command will fail!The solution is to pass
--no-build-isolation
to the download command so it will build the package using our bootstrapped virtualenv, which already contains all the build dependencies at the versions we want.