On 7 Aug 2017, at 21:50, Ralph Seichter tor-relays-ml@horus-it.de wrote:
On 07.08.2017 08:32, teor wrote:
This would be a single point of failure (and possibly compromise). We try to avoid those by having people involved in the updates.
Since Tor configuration is text file based, I generally use Cron jobs to pull shared config data from a central repository. The changes, which I verify using "diff", don't come into effect until I manually send a HUP signal to the Tor processes.
This is better, but still insecure: if an adversary can cause the tor process to crash, or the machine to restart, or logrotate is turned on, the config will be applied without human intervention.
Perhaps something similar would work for the Tor directory authorities as well, to avoid recommended-version- hiccups? If a central repository is not desirable for security reasons, how about using Git to sync changes between shared Tor directory auth servers, akin to Linux Kernel changes?
This is already how some changes are distributed.
Security is of course more important than automation, but this is not a black or white kind of situation, and I think it would be help if the Tor directory authorities were kept in sync here.
Distributing changes conveniently is different to deciding whether to apply them. Machines are good at the first task, but the second task needs multiple people.
Otherwise, it's a single point of failure.
(Or, we can decide that some kinds of changes *don't* need multiple people involved. That's ok, too.)
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------