remora.n621.de
This is the about page of remora.n621.de, an instance of litewitness, which is a piece of software that follows the progression of a transparency log and certifies that it has been operating in an append-only fashion. Remoras are a family of fish that attach to other marine animals and follow them around.
remora is primarily intended as a test setup to grease the wheels of operating a larger network of witnesses in the sigsum ecosystem and gain some operational experience in running a witness, but is open to witnessing other compatible logs.
Feel free to reach out if you want to add your log or have any further questions.
Why should I trust remora as the user of a log?
When you rely on the cosignatures of a witness (for example by allowing them to contribute to the quorum of your trust policy), there are two aspects to consider: Trustworthiness and availability.
Trustworthiness means: How sure can you be that a cosignature produced by a witness for a given tree head does actually imply that the log has behaved correctly for the entire time the witness has been observing the log? I.e. how likely is it that either a third party or the operator themselves can compromise (intentionally or by accident), trick or coerce it into signing checkpoints in spite of incorrect log behavior?
Availability means: How sure can you be that a witness you chose to rely on won't disappear intermittently or entirely and possibly break your quorum?
In the case of remora, you probably shouldn't rely on either. It is a test instance that runs on a VM on a random host on the internet and is operated by a random person you probably do not know. In particular:
- While I do operate the VM host, I don't control the hardware it runs on or the physical access to it (it runs in a Hetzner data center)
- This also means that the witness signing key is not particularly protected (e.g. stored in an HSM). It is encrypted at rest but other than that it's trivial to clone if somebody gains access to the VM. The same goes for access to the database that tracks the state of the logs.
- There is no redundancy or any kind of on-call rotation. If something goes down while I am asleep or offline, it might take a while to get fixed.
That being said, there are some extenuating circumstances that might still make it worth your while:
- Neither I nor my employer are operating any transparency logs or are affiliated with any entities that do. Thus, it truly is an independent third party.
- The machine it runs on hosts a lot of my other infrastructure, so I am incentivized to keep it healthy and secure.
- My main goal with running this instance is to practice operational procedure for running a witness, so I'm trying to run it as if it were a staging/production instance.
Why should I as an operator have remora witness my log?
Similar considerations to the previous section apply.
Naively, adding more witnesses to a log is at least neutral and possibly positive. However, stuffing your log with witnesses of uncertain provenance might have the opposite effect. Also, there is an operational cost associated with integrating more witnesses (especially ones that might be less reliable than you'd like), but the whole point of this instance is to exercise this operational procedure, so maybe that's your thing too.
Operational characteristics/policy
- remora is a standalone Debian VM, running litewitness behind a Caddy reverse proxy. System time is synchronized using NTP. Automatic updates of the operating system are enabled, kernel updates do not get applied automatically. The litewitness installation will get updated manually as needed.
- The availability of the
add-checkpoint endpoint is monitored by a different VM on the same host and I will get an alert if it fails.
- Large-scale changes to availability (e.g. the intention to take down the service permanently) will be announced below as early as possible, but at least a month in advance.
- Medium-scale changes to availability (e.g. planned maintenance inducing a downtime ≥10 minutes) will be announced below as early as possible, but at least a week in advance.
- Small-scale changes to availability (e.g. service restarts/reboots inducing a downtime less than 5 minutes) will not be announced.
- Significant changes to this about page will also be announced in the operational log below.
- I will also proactively reach out to log operators if I feel there is a need to coordinate on anything.
See /status for the litewitess status page.
remora configures all new logs from the Witness Network testing list once per hour.
Cosignatures for configured logs can be requested on the /add-checkpoint endpoint and will be signed using the following pubkey (in vkey, SSH and plain hex formats respectively):
remora.n621.de+da77ade7+BOvN63jn/bLvkieywe8R6UYAtVtNbZpXh34x7onlmtw2
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOvN63jn/bLvkieywe8R6UYAtVtNbZpXh34x7onlmtw2
ebcdeb78e7fdb2ef9227b2c1ef11e94600b55b4d6d9a57877e31ee89e59adc36
Operational log (feed)
2025-10-25 14:35Z #
Announcing a maintenance window on 2025-11-02 from 14:00 to 16:00 UTC due to
work on the VM host. The expected downtime within that window barring
complications is around 15 minutes. Neither this page nor the witness itself
will be reachable during the downtime.
Reachability via email and IRC will also be affected. If necessary, please
contact me via Matrix or Signal.
2025-10-17 10:39Z #
pull-logs has been switched over to the new list URL.
2025-10-16 21:21Z #
litewitness has been updated to version 605418c4b1e9c7d77d7b8c92d1fbca162a9c9225 and an hourly pull-logs job has been set up for the Witness Network testing list.
The main body of the about page has been updated to reflect this too.
2025-10-09 00:29Z #
Initial instance setup completed using Debian trixie and commit 15c8e8b7946ed97be3dfe772436785151b690cab of the torchwood repo.