service/BTCpayserver.md

@@ -457,10 +457,6 @@ There is no issue tracker specifically for this project, [File][] or
  [File]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new
  [search]: https://gitlab.torproject.org/tpo/tpa/team/-/issues?label_name%5B%5D=BTCpayserver
 
-In the long term, given the sensitive matter of hosting a payment
-service, we should have this in our tpa managed infrastructure, see
-[issue tpo/tpa/team#33750](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750) for details.
-
 Upstream has *set* of [GitHub repositories](https://github.com/btcpayserver/) with its own issues.
 
 ## Maintainer, users, and upstream
@@ -572,61 +568,71 @@ Upstream has [documentation](https://docs.btcpayserver.org/).
 
 # Discussion
 
-TODO: document why this project exists
+This section aims at documenting more in-depth issues with the current
+setup and possible solutions.
 
 ## Overview
 
-TODO: more in-depth audit
-
-<!-- describe the overall project. should include a link to a ticket -->
-<!-- that has a launch checklist -->
-
-<!-- if this is an old project being documented, summarize the known -->
-<!-- issues with the project. to quote the "audit procedure":
-
- 5. When was the last security review done on the project? What was
-    the outcome? Are there any security issues currently? Should it
-    have another security review?
-
- 6. When was the last risk assessment done? Something that would cover
-    risks from the data stored, the access required, etc.
-
- 7. Are there any in-progress projects? Technical debt cleanup?
-    Migrations? What state are they in? What's the urgency? What's the
-    next steps?
-
- 8. What urgent things need to be done on this project?
-
--->
-
-## Goals
-
-<!-- include bugs to be fixed -->
-
-TODO: Go over the essentials of the [launch ticket](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750) and describe
-what is the requirements for this project
-
-### Must have
-
-### Nice to have
-
-### Non-Goals
-
-## Approvals required
-
-accounting, finance, TPA, hiro.
-
-## Proposed Solution
-
-TODO: summarize the strategy we have taken to maintain this thing
-
-## Cost
-
-TODO: cost
-
-## Alternatives considered
-
-<!-- include benchmarks and procedure if relevant -->
-TODO: briefly cover alternative systems (e.g. "generate a bunch of
-bitcoin addresses periodically and have a button to show one at a
-time")
+BTCpay has a somewhat obscure and complicated history at Tor, and is
+in itself a rather complicated project, as explained above in the
+[design section](#design).
+
+## Deployment history
+
+The BTCpay server was originally setup, hosted, and managed by the
+BTCpay people themselves. Back in March 2020, they suggested we host
+it ourselves and, [in November 2020](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750#note_2714987), hiro had it deployed on a
+Lunanode.com VM, at the recommendation of the BTCPay people.
+
+Since then, an effort was made to move the VM inside TPA-managed
+infrastructure, which is the setup that is documented in this
+page. That effort is tracked in the above ticket,
+[tpo/tpa/team#33750](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750).
+
+The VM at Lunanode was setup with Ubuntu 16.04 which became EOL
+(except for extended support) on 2021-04-30 (extended support stops in
+2026). A quick audit in February 2022 showed that it didn't actually
+have the extended support enabled, so that was done with anarcat's
+personal Ubuntu credentials (it's not free).
+
+Around April 2022, more effort was done to finally move the VM to TPA
+infrastructure, but in doing so, significant problems were found with
+BTCpay in particular, but also with our cryptocurrency handling in
+general.
+
+## Security review
+
+There was never a security review performed on BTCpay by Tor
+people. As far as we can tell, there was no security audit performed
+on BTCpay by anyone.
+
+The core of BTCpayserver is written in C# should should generally be a
+safer language than some others, that said.
+
+The state of the old VM is concerning, as it's basically EOL. We also
+don't have good mechanisms for automating upgrades. We need to
+remember to go in the machine and run the magic commands to update the
+containers. It's unclear if this could be automated, considering the
+upgrade procedure upstream proposes actually involves dynamically
+regenerating the docker-compose file. It's also noisy so not a good
+fit for a cron job.
+
+Part of the reason this machine was migrated to TPA infrastructure was
+to at least resolve the OS part of that technical debt, so that OS
+upgrades, backups, and basic security (e.g. firewalls) would be
+covered. This still leaves a gaping hole for the update and
+maintenance of BTCpay itself.
+
+## PII concerns
+
+There are no efforts in BTCpay to redact PII from logs. Nginx logs
+keep second-granular timestamps with full IP address and user agent
+information. It's unclear how long invoices are retained in the
+PostgreSQL database nor what information they contain.
+
+BTCpay correctly generates a one-time Bitcoin address for
+transactions, so that is done correctly at least. But right next to
+the BTCpay button on https://donate.torproject.org/cryptocurrency,
+there are static addresses for various altcoins (including bitcoin)
+that are a serious liability, see [tpo/web/donate-static#74](https://gitlab.torproject.org/tpo/web/donate-static/-/issues/74) for
+details.