Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Hi all, > On 6 Sep 2019, at 12:20, Mike Perry wrote: > > Roman Mamedov: >> >> On Thu, 05 Sep 2019 02:11:00 + >> Mike Perry wrote: >> >>> 1. "I didn't know that Debian's backports repo has latest-stable Tor!" >> >> I only looked to backports when I get a warning on the metrics website that >> my >> versions are not recommended. Aside from that, I thought that running LTS on >> relays is actually beneficial, to prevent any newly introduced bugs in the >> current latest versions from having an impact on the network infrastructure. > > We are moving towards relying on CI for finding functional bugs, and > code review and static analysis for security issues. > > I don't believe that current LTS periods of time will necessarily > provide better results for either of these classes of risk than > investing in better CI and in other forms of diversity than just release > version. > > However, I could see a middle ground where we shorten LTS timescales for > the relay side, but don't eliminate them, as we work towards where we > want to be with CI and security issue risk reduction (or other forms of > diversity). We also have long-term support so that popular software distributions can have a supported version of Tor. (Debian, Ubuntu, and ideally some non-Linux distributions, if they become popular in future.) So it's not just risk that determines our current LTS timeframes. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
> never relied on the OS Package of Tor, mainly because OS’s OpenSSL versions
> are behind the current version of OpenSSL, so I normally compile Tor against
> the latest OpenSSL. Example, FreeBSD 12.0-RELEASE has OpenSSL
> 1.1.1a-freebsd, which generates a slight crypto error during the startup of
> Tor. If you download OpenSSL 1.1.1c and just compile against it, eh, problem
> fixed.
As to realtime, hardly any behind...
ver openssl 12-stable ports-head
1.1.1c 20190528 20190528 20190528
1.1.1b 20190226 20190226 20180227
1.1.1a 20181120 20181120 20181120
... not including any 'responsible disclosure' bs
around any HW / SW that users may or may not
be affected by.
As to release mechanics...
12.0-release base had latest 1.1.1a at release,
release ports tags were one letter rev behind
at 1.0.2p and 1.1.0i, release ports head was
latest at 1.0.2q and 1.1.1a, quarterly was similar.
tor follows same pattern, people can research
and post those datas if they want.
Of course people's boxes will be behind if they never
update them beyond release, that's not fault of any OS.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html
https://download.freebsd.org/ftp/snapshots/
Either update base per binary, snapshot, releng, or stable...
or track and install ports (packages) quarterly, latest / head...
and compile against that as needed.
Or get the upstream sources and do by hand.
If people aren't on FreeBSD or a well supported
Linux distro they should expect their OS to be
laggy in areas.
Many FreeBSD tor users would be fine tracking
base stable and packages latest (ports head).
pkg.conf: url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest";,
If their OS of choice is still a bit laggy for them, they
can join their OS community and start generating
update commits... :)
https://freebsd.org/
https://openbsd.org/
etc
or whatever pump and dump linux distro is hot this year.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Roman Mamedov: > > On Thu, 05 Sep 2019 02:11:00 + > Mike Perry wrote: > >> 1. "I didn't know that Debian's backports repo has latest-stable Tor!" > > I only looked to backports when I get a warning on the metrics website that my > versions are not recommended. Aside from that, I thought that running LTS on > relays is actually beneficial, to prevent any newly introduced bugs in the > current latest versions from having an impact on the network infrastructure. We are moving towards relying on CI for finding functional bugs, and code review and static analysis for security issues. I don't believe that current LTS periods of time will necessarily provide better results for either of these classes of risk than investing in better CI and in other forms of diversity than just release version. However, I could see a middle ground where we shorten LTS timescales for the relay side, but don't eliminate them, as we work towards where we want to be with CI and security issue risk reduction (or other forms of diversity). >> 2. "I didn't see the Tor Project repos mentioned in Tor's Relay docs!" > > I was using them in the past, but then decided not to, as it's adding some > management overhead and also one more potential security weakpoint. These two strike me as being likely to be very high on the list of common reasons, when the choice is deliberately made. What can we do to reduce management overhead? Right now, there are quite a lot of separate pages pointing to different pieces of the steps of adding our repo. Is that the problematic piece? Are there additional things make it more of a hassle than it should be? Someone else mentioned ansible. Would an ansible playbook that add our repositories and their gpg keys make this easier? Or is it better just to keep the steps all on a single page? Where does the security weakpoint risk come from? Does apt-transport-tor/onion service repository availability help in your mind here? -- Mike Perry signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
> On Sep 5, 2019, at 11:44 AM, Matt Traudt wrote: > > On 9/4/19 22:43, teor wrote: >> Hi Mike, >> >> Here's some other reasons that might affect a few operators: >> >>> On 5 Sep 2019, at 12:11, Mike Perry wrote: >>> >>> Unfortunately, we still have something like 2500 relays on either Tor >>> 0.2.9-LTS or Tor 0.3.5-LTS. >>> >>> What are the reasons for this? My guess is the top 5 most common >>> responses are: >>> >>> 1. "I didn't know that Debian's backports repo has latest-stable Tor!" >>> 2. "I didn't see the Tor Project repos mentioned in Tor's Relay docs!" >>> 3. "I'm running a distribution that Tor Project doesn't have repos for." >>> 4. "I rolled my own custom Tor from git and forgot about it." >>> 5. "My relay machine was not getting any updates at all. Oops." >>> >>> Does anyone have a reason that they think many other relay operators >>> also share? >> >> 6. When I tried to update, it didn't work with my old config >> 7. I need features that only exist in older Tors >> - I can think of Tor2web, there may be others >> 8. I am maintaining research or other patches against tor, and rebases >> are difficult >> > > Regarding my relays, which currently are [0] > > - Two were stuck on 0.3.4.11 because I had to install Tor from source on > that machine and am bad about updating it (just updated) > - Two are stuck on 0.3.5.7 because research and rebasing to new versions > is liable to create inconsistencies and general doubt about results > > [0]: https://metrics.torproject.org/rs.html#search/contact:pastly > >>> How can we fix that for you, or at least, how can we make it easier to >>> run the very latest stable series Tor on your relay? > > This is a huge ask and I don't expect anything to come of this > suggestion, but: > > Auto updates from within Tor itself (not relying on distro package > managers). Put it behind a torrc option, allow the authorities to tell > relays with the option enabled to download a new tor binary from $PLACE, > create a bunch of infrastructure that builds Tor for all supported > platforms reliably and efficiently, use a bunch of signatures everywhere > so nothing bad can happen, done. So easy a caveman could do it, nothing > bad could ever happen, absolutely no downsides, it's $CURRENT_YEAR so > why don't we have this, etc. etc. > > -- > Matt This may not matter for LTS versions, but I just wanted to mention it it in reference it to the possible idea that Tor possibly updating itself. I’ve never relied on the OS Package of Tor, mainly because OS’s OpenSSL versions are behind the current version of OpenSSL, so I normally compile Tor against the latest OpenSSL. Example, FreeBSD 12.0-RELEASE has OpenSSL 1.1.1a-freebsd, which generates a slight crypto error during the startup of Tor. If you download OpenSSL 1.1.1c and just compile against it, eh, problem fixed. Sorry, maybe I just don’t like seeing errors :). Anyway, why don’r we try to simplify the update process even further and just ship Tor with some ansible scripts that will replace the binary, check the config file and comment out any settings that will break the new version, then restart? It’s pretty simple to write an sensible script to do this function. --- Conrad Rockenhaus con...@rockenhaus.com https://www.rockenhaus.com/ (254) 292-3350 signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
On 9/4/19 22:43, teor wrote: > Hi Mike, > > Here's some other reasons that might affect a few operators: > >> On 5 Sep 2019, at 12:11, Mike Perry wrote: >> >> Unfortunately, we still have something like 2500 relays on either Tor >> 0.2.9-LTS or Tor 0.3.5-LTS. >> >> What are the reasons for this? My guess is the top 5 most common >> responses are: >> >> 1. "I didn't know that Debian's backports repo has latest-stable Tor!" >> 2. "I didn't see the Tor Project repos mentioned in Tor's Relay docs!" >> 3. "I'm running a distribution that Tor Project doesn't have repos for." >> 4. "I rolled my own custom Tor from git and forgot about it." >> 5. "My relay machine was not getting any updates at all. Oops." >> >> Does anyone have a reason that they think many other relay operators >> also share? > > 6. When I tried to update, it didn't work with my old config > 7. I need features that only exist in older Tors > - I can think of Tor2web, there may be others > 8. I am maintaining research or other patches against tor, and rebases >are difficult > Regarding my relays, which currently are [0] - Two were stuck on 0.3.4.11 because I had to install Tor from source on that machine and am bad about updating it (just updated) - Two are stuck on 0.3.5.7 because research and rebasing to new versions is liable to create inconsistencies and general doubt about results [0]: https://metrics.torproject.org/rs.html#search/contact:pastly >> How can we fix that for you, or at least, how can we make it easier to >> run the very latest stable series Tor on your relay? This is a huge ask and I don't expect anything to come of this suggestion, but: Auto updates from within Tor itself (not relying on distro package managers). Put it behind a torrc option, allow the authorities to tell relays with the option enabled to download a new tor binary from $PLACE, create a bunch of infrastructure that builds Tor for all supported platforms reliably and efficiently, use a bunch of signatures everywhere so nothing bad can happen, done. So easy a caveman could do it, nothing bad could ever happen, absolutely no downsides, it's $CURRENT_YEAR so why don't we have this, etc. etc. -- Matt ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor exit relay in Finland still being attacked
Hi, > On 5 Sep 2019, at 03:54, potlatch wrote: > > I had TorExitFin [0] down for a few days hoping the non-Tor Iranian intruders > would wander off. I restarted it today and before NYX could come up there > were 257 Iranian IPs present (nicely automated!). The IP addresses range > over all of the IP addresses allotted to Iran so their usage must come from a > high authority to get that kind of access. NYX communications page showed > that none of these had hashed fingerprints. At the same time 3 IPs came up > from other countries with fingerprints. Should I leave this shut down for > the security of the network? > -potlatch > [0] 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 It's not an attack. It looks like a bad interaction between tor and Iran's censorship. Or genuine usage of tor by an app or a whole bunch of users. See this ticket for more details: https://trac.torproject.org/projects/tor/ticket/30636 You should do whatever you need to do to keep your relay running. If you can, accept the traffic, rate-limit the traffic, or drop the traffic (without replying at all). We're working on a fix on the tor side. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor exit relay in Finland still being attacked
I had TorExitFin [0] down for a few days hoping the non-Tor Iranian intruders would wander off. I restarted it today and before NYX could come up there were 257 Iranian IPs present (nicely automated!). The IP addresses range over all of the IP addresses allotted to Iran so their usage must come from a high authority to get that kind of access. NYX communications page showed that none of these had hashed fingerprints. At the same time 3 IPs came up from other countries with fingerprints. Should I leave this shut down for the security of the network? -potlatch [0] 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 Sent with [ProtonMail](https://protonmail.com) Secure Email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
