TPA-RFC-78: consider retiring or optimize dangerzone-bot

in #41997, @micah noticed that dangerzone-bot was creating a lot of spurious traffic on the Nextcloud server due to dangerzone-bot. he said:

After some log digging, it was found that dangerzone-bot was connecting a very large amount of times:

0.0.0.0 - dangerzone-bot [28/Jan/2025:00:06:05 +0000] "MKCOL /remote.php/dav/files/dangerzone-bot/AuditRFP/dangerzone/processing/ HTTP/1.1" 405 541 "-" "python-requests/2.28.1"

with a significantly larger amount of users on the system from when the system was originally configured, and dangerzone-bot doing an abnormally large number of connections (several times more requests than most users), the php-fpm processes get exhausted causing 404s.

We've had numerous problems with this bot, the last one being flapping (team#41846 (closed)), but we also had reliability problems (#14), scary shit (#21, #24), other annoyances (#18) and the software is essentially unmaintained (i'm the upstream, essentially).

so let's see if we invest more efforts in this. in #21, @lavamind suggested looking at implementing this with nextcloud extensions (e.g. workflow_script), but we should really consider whether anyone uses this at all and if it's still useful.

dangerzone bot was first built to help people in hiring committees process incoming resumes. previously, this was done by hand by folks like @ahf (i think?) who were doing this kind of processing manually in Qubes. but now that hiring happens over Manatal, which handles resumes and (presumably?!) sanitization, i am not sure we need this tool at all anymore.

next steps

TPA-RFC-78 has been proposed, see https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-78-dangerzone-retirement

once it's adopted:

Edited Mar 05, 2025 by anarcat