The authenticated onion service stuff is still unmerged
(https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2266),
so we build Arti from the MR and it works! Generating a config.toml file
seems much cleaner than adding to torrc and generating .auth files.
The main upside for this is that using Arti is cool and gets it more
real-world testing. But the downside is that it takes a non-trivial
amount of time to build Arti locally and maybe it's not worth doing
until we have pre-package/downloadable binaries. :thinking:
Testing
How should the reviewer test this PR?
Write out any special testing steps here.
Deployment
Any special considerations for deployment? Consider both:
Upgrading existing production instances.
New installs.
Checklist
If you made changes to the server application code:
[ ] Linting (make lint) and tests (make test) pass in the development container
If you made changes to securedrop-admin:
[ ] Linting and tests (make -C admin test) pass in the admin development container
If you added or removed a file deployed with the application:
[ ] I have updated AppArmor rules to include the change
If you made non-trivial code changes:
[ ] I have written a test plan and validated it for this PR
Choose one of the following:
[ ] I have opened a PR in the docs repo for these changes, or will do so later
[ ] I would appreciate help with the documentation
[ ] These changes do not require documentation
If you added or updated a reference to a production code dependency:
Production code dependencies are defined in:
admin/requirements.in
admin/requirements-ansible.in
securedrop/requirements/python3/requirements.in
securedrop/requirements/python3/translation.in (used in the build
container)
If you changed another requirements.in file that applies only to development
or testing environments, then no diff review is required, and you can skip
(remove) this section.
Choose one of the following:
[ ] I have performed a diff review and pasted the contents to the packaging wiki
[ ] I would like someone else to do the diff review
[ ] I am silencing an alert related to a production dependency, because (please explain below):
Status
Work in progress
Description of Changes
The authenticated onion service stuff is still unmerged (https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2266), so we build Arti from the MR and it works! Generating a config.toml file seems much cleaner than adding to
torrcand generating.authfiles.The main upside for this is that using Arti is cool and gets it more real-world testing. But the downside is that it takes a non-trivial amount of time to build Arti locally and maybe it's not worth doing until we have pre-package/downloadable binaries. :thinking:
Testing
How should the reviewer test this PR? Write out any special testing steps here.
Deployment
Any special considerations for deployment? Consider both:
Checklist
If you made changes to the server application code:
make lint) and tests (make test) pass in the development containerIf you made changes to
securedrop-admin:make -C admin test) pass in the admin development containerIf you made changes to the system configuration:
If you added or removed a file deployed with the application:
If you made non-trivial code changes:
Choose one of the following:
If you added or updated a reference to a production code dependency:
Production code dependencies are defined in:
admin/requirements.inadmin/requirements-ansible.insecuredrop/requirements/python3/requirements.insecuredrop/requirements/python3/translation.in(used in the build container)If you changed another
requirements.infile that applies only to development or testing environments, then no diff review is required, and you can skip (remove) this section.Choose one of the following: