howto/gitlab.md

@@ -303,6 +303,41 @@ plus](https://github.com/helloworld1/FreeOTPPlus/), see also this [list from the
 hardware token must implement the U2F protocol, which is supported by
 security tokens like the [YubiKey](https://en.wikipedia.org/wiki/YubiKey), [Nitrokey](https://www.nitrokey.com/), or similar.
 
+## Deleting sensitive attachments
+
+If a user uploaded a secret attachment by mistake, just deleting the
+issue is not sufficient: it turns out that doesn't remove the
+attachments from disk!
+
+To fix this, ask a sysadmin to find the file in the
+`/var/opt/gitlab/gitlab-rails/uploads/` directory. Assuming the
+attachment URL is:
+
+<https://gitlab.torproject.org/anarcat/test/uploads/7dca7746b5576f6c6ec34bb62200ba3a/openvpn_5.png>
+
+There should be a "hashed" directory and a hashed filename in there,
+which looks something like:
+
+    ./@hashed/08/5b/085b2a38876eeddc33e3fbf612912d3d52a45c37cee95cf42cd3099d0a3fd8cb/7dca7746b5576f6c6ec34bb62200ba3a/openvpn_5.png
+
+The second directory (`7dca7746b5576f6c6ec34bb62200ba3a` above) is the
+one visible in the attachment URL. The last part is the actual
+attachment filename, but since those can overlap between issues, it's
+safer to look for the hash. So to find the above attachement, you
+should use:
+
+    find /var/opt/gitlab/gitlab-rails/uploads/ -name 7dca7746b5576f6c6ec34bb62200ba3a
+
+And delete the file in there. The following should do the trick:
+
+    find /var/opt/gitlab/gitlab-rails/uploads/ -name 7dca7746b5576f6c6ec34bb62200ba3a | sed 's/^/rm /' > delete.sh
+
+Verify `delete.sh` and run it if happy.
+
+Note that GitLab is working on an [attachment manager](https://gitlab.com/gitlab-org/gitlab/-/issues/16229) that should
+allow web operators to delete old files, but it's unclear how or when
+this will be implemented, if ever.
+
 ## Pager playbook
 
 <!-- information about common errors from the monitoring system and -->