Some suggestions:
- don't copy the ed25519_master_id_public_key file. If it is missing,
Tor will just compute it from the certificate and save it to disk. But, if by accident an user copies the medium term signing keys related to another relay, Tor will detect they don't match the ed25519_master_id_public_key file and exit.
I'm copying ed25519_master_id_public_key to the relay to get rid of the following [warn] level log entries:
[warn] No key found in .../keys/ed25519_master_id_secret_key or .../keys/ed25519_master_id_public_key. [warn] Master public key was absent; inferring from public key in signing certificate and saving to disk.
The goal was to reduce the noise at the warn log level.
- when you run tor --orport [...] just to generate the keys in a
non-interactive way, include a PublishServerDescriptor 0 in the command as well
added
, send the log to /dev/null
done [1]
and terminate the process immediately.
I'm using --list-fingerprint for that.
The descriptor will have to be published by the Tor
process actually running the relay. If the master id private key is not encrypted, --keygen should be able to renew the medium term signing key in a non-interactive way. But it's not a big deal if you decide to do it with tor --orport [...] if it's easier for you this way.
I can switch to --keygen if it generates RSA keys (as long as they are a requirement for a relay) as well and --no-pass is implemented, but I'm also fine with the current way to generate keys.
- make it as hard as you can for users to accidentally mix keys
belonging to different relays. This will be a tough one.
I'm aiming to add a check that aborts if a key is found more than once in ~/.tor/offlinemasterkeys.
thanks, nusenu
[1] https://github.com/nusenu/ansible-relayor/commit/43d52e995abf6b3a311984bd54a...