Skip to content

Changes

Page history
btcpay: expand on problems, alternatives will be made into a RFC authored by anarcat's avatar anarcat
Hide whitespace changes
Inline Side-by-side
service/BTCpayserver.md
View page @ 2754efc4
......@@ -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.