Tor 0.3.0.10 not listed as a recommended version
Hello, after updating to Tor 0.3.0.10, I see the following warning on my nodes: This version of Tor (0.3.0.10) is newer than any recommended version in its series, according to the directory authorities. Could one of the devs please update the relevant data? Thanks. -Ralph
On Sat, Aug 05, 2017 at 12:34:35PM +0200, Ralph Seichter wrote:
Hello,
after updating to Tor 0.3.0.10, I see the following warning on my nodes:
This version of Tor (0.3.0.10) is newer than any recommended version in its series, according to the directory authorities.
Could one of the devs please update the relevant data? Thanks.
Yep -- moria1 is the only one of the three dir auths recommending 0.3.0.10: https://consensus-health.torproject.org/#recommendedversions I just moved things forward a bit to get gabelmoo and tor26 recommending it too. Also, I opened two tickets, one for making this particular situation less likely to happen again, and another for fixing the whole treadmill where people have to edit text files before a new version should come out: https://bugs.torproject.org/23118 https://bugs.torproject.org/23119 Thanks, --Roger
On 05.08.17 22:17, Roger Dingledine wrote:
[...] I opened two tickets, one for making this particular situation less likely to happen again, and another for fixing the whole treadmill where people have to edit text files before a new version should come out [...]
No longer displaying warnings if the Tor version found is newer than the recommended versions is of course one way to do it. Atlas displays the text "Outdated Tor version" in this case, which is decidedly odd and of course incorrect. I'm wondering why directory authorities don't pull their list of recommended Tor versions from a central repository instead of forgoing version checks, with the list being updated automatically when a release build is successfully packaged and made available for public download? Even for my humble set of servers I use a Subversion repository and Cron to distribute policies and other shared information. ;-) -Ralph
Careful. 0.3.0.1 > 0.2.9.14orsomething, but the former is probably too buggy. On Aug 5, 2017 14:59, "Ralph Seichter" <tor-relays-ml@horus-it.de> wrote: On 05.08.17 22:17, Roger Dingledine wrote:
[...] I opened two tickets, one for making this particular situation less likely to happen again, and another for fixing the whole treadmill where people have to edit text files before a new version should come out [...]
No longer displaying warnings if the Tor version found is newer than the recommended versions is of course one way to do it. Atlas displays the text "Outdated Tor version" in this case, which is decidedly odd and of course incorrect. I'm wondering why directory authorities don't pull their list of recommended Tor versions from a central repository instead of forgoing version checks, with the list being updated automatically when a release build is successfully packaged and made available for public download? Even for my humble set of servers I use a Subversion repository and Cron to distribute policies and other shared information. ;-) -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 06.08.17 00:08, Chad MILLER wrote:
Careful. 0.3.0.1 > 0.2.9.14orsomething, but the former is probably too buggy.
I fail to see how that relates to my earlier message. When a new Tor production version is released, it is by definition recommended, or it would not be a production release in the first place. If later it turns out that a particular Tor version is buggy, in can be manually removed from the list of recommended versions. -Ralph
We have several supported lines. Simple greater-than doesn't tell us anything about later-ness. On Aug 5, 2017 15:33, "Ralph Seichter" <tor-relays-ml@horus-it.de> wrote: On 06.08.17 00:08, Chad MILLER wrote:
Careful. 0.3.0.1 > 0.2.9.14orsomething, but the former is probably too buggy.
I fail to see how that relates to my earlier message. When a new Tor production version is released, it is by definition recommended, or it would not be a production release in the first place. If later it turns out that a particular Tor version is buggy, in can be manually removed from the list of recommended versions. -Ralph _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 06.08.17 00:41, Chad MILLER wrote:
We have several supported lines. Simple greater-than doesn't tell us anything about later-ness.
That's common when developing on multiple branches. In any case, I did not say that greater-than is relevant, only newer-than on a production branch, but even that is not crucial. My main point is that I find it surprising that the list of recommended Tor versions is not centrally maintained and distributed automatically once a new production release is made available to the public. -Ralph
On 6 Aug 2017, at 09:20, Ralph Seichter <tor-relays-ml@horus-it.de> wrote:
On 06.08.17 00:41, Chad MILLER wrote:
We have several supported lines. Simple greater-than doesn't tell us anything about later-ness.
That's common when developing on multiple branches. In any case, I did not say that greater-than is relevant, only newer-than on a production branch, but even that is not crucial. My main point is that I find it surprising that the list of recommended Tor versions is not centrally maintained and distributed automatically once a new production release is made available to the public.
This would be a single point of failure (and possibly compromise). We try to avoid those by having people involved in the updates. 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 ------------------------------------------------------------------------
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. 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? 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. -Ralph
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 ------------------------------------------------------------------------
On 08.08.2017 05:36, teor wrote:
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.
Our discussion made me reevaluate my own process of distributing config data. In particular, I've made some tests with the free version of Ansible (https://www.ansible.com/), and set the following up on my notebook: 1. Shared Tor config data is stored locally. The data store is manually synced with a central repository (e.g. Subversion) for version control and backups, but changes could of course also be applied using Git or other mechanisms. It would be easy to verify if somebody else made a change, if multiple people were involved, as per your use-case. 2. I wrote a small Ansible playbook that, after being manually invoked, automatically pushes config data to all my remote Tor nodes that require changes, and sends a HUP signal if changes were made. This method requires Ansible to be installed only on the managing notebook/PC/whatever. There is no additional setup on my Tor nodes (key-based SSH is required anyway). Pushing changes to the Tor nodes requires entering both local SSH key password (ssh-agent can be used, of course) and remote SUDO password, the latter assuming that the remote SSH user is different from the remote Tor user. Changes only happen when manually triggered, but it is still very convenient. Tor processes restarting/reloading don't cause adverse effects. -Ralph
On 06.08.2017 00:33, Ralph Seichter wrote:
On 06.08.17 00:08, Chad MILLER wrote:
Careful. 0.3.0.1 > 0.2.9.14orsomething, but the former is probably too buggy. I fail to see how that relates to my earlier message. When a new Tor production version is released, it is by definition recommended, or it would not be a production release in the first place. If later it turns out that a particular Tor version is buggy, in can be manually removed from the list of recommended versions.
-Ralph I’m not sure if “production version/release” is a term formally defined for Tor releases, but 0.3.0.1 was at least not a “stable” release: the announcement of Tor 0.3.0.6 [1] declares it “the first stable release of the Tor 0.3.0 series”. And indeed, on the consensus health page [2], I can see that several directory authorities don’t recommend any Tor versions between 0.2.9.* and 0.3.0.7 (0.3.0.6 had a “medium-severity security bug” [3], I assume that’s why it’s not recommended either).
Cheers, Lucas [1]: https://lists.torproject.org/pipermail/tor-announce/2017-April/000128.html [2]: https://consensus-health.torproject.org/ [3]: https://lists.torproject.org/pipermail/tor-announce/2017-May/000129.html
participants (5)
-
Chad MILLER -
Lucas Werkmeister -
Ralph Seichter -
Roger Dingledine -
teor