Hello,
We are developing a reputation based bridge distributor called Lox[0] and are preparing to make a call for users to test it in Tor Browser Alpha. In order to do this, we need to have some new bridges that can be distributed by Lox. Do you want to give us a hand running a bridge (or few) for Lox? At the moment we're looking for 10 new bridges for Lox.
Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now, but will instead accept bridges with the 'BridgeDistribution lox' configured in torrc.
To set up a bridge for Lox, configure a normal obfs4 bridge[1] and simply include the following line in torrc: BridgeDistribution lox
As Lox is only going to be released for testing, you might not see a lot of traffic on Lox bridges at the moment. However, these bridges will be very useful for us to improve Lox and see what works and what does not.
Thank you
[0] https://gitlab.torproject.org/tpo/anti-censorship/lox [1] https://community.torproject.org/relay/setup/bridge/
On Dienstag, 27. Februar 2024 14:52:00 CET Corl3ss via tor-relays wrote:
On 26/02/2024 21:03, Toralf Förster via tor-relays wrote:
On 2/26/24 20:07, meskio wrote:
At the moment we're looking for 10 new bridges for Lox.
9 left
And one more added, so 8 left.
+1 = 7 left
Is hidden OR port OK for lox based bridge?
ORPort 127.0.0.1:14255 ORPort [::1]:14255 AssumeReachable 1
Quoting boldsuck (2024-02-27 16:38:59)
Is hidden OR port OK for lox based bridge?
ORPort 127.0.0.1:14255 ORPort [::1]:14255 AssumeReachable 1
Yes, that will be fine as long as your obfs4 port is reachable.
On Dienstag, 27. Februar 2024 17:03:22 CET Toralf Förster via tor-relays wrote:
ServerTransportPlugin obfs4 exec /usr/bin/lyrebird
Ooh, obfs4proxy is renamed to Lyrebird? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyreb...
I do not specified the ipv6 port explicietly: Would it be needed?
¯_(ツ)_/¯ https://gitlab.torproject.org/tpo/core/tor/-/issues/40885 It's probably unnecessary at the moment.
boldsuck wrote:
On Dienstag, 27. Februar 2024 17:03:22 CET Toralf Förster via tor-relays wrote:
ServerTransportPlugin obfs4 exec /usr/bin/lyrebird
Ooh, obfs4proxy is renamed to Lyrebird? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyreb...
Oh, that's new. Don't recall reading anything about this change on the mail lists or on the blog.
Is there anything needed to do with previous setups that use obfs4proxy from it's default previous repository? Or just the name has been changed and everything is backward compatible?
I was waiting to update the entire Tor related stuff when gitlab.torproject.org CI will be fixed so that deb.torproject.org nightly builds will start being shipped again under apt.
On Dienstag, 27. Februar 2024 20:09:17 CET s7r wrote:
Is there anything needed to do with previous setups that use obfs4proxy from it's default previous repository? Or just the name has been changed and everything is backward compatible?
For us on Debian, this will only change with the next release "trixie". Then we may have to change configs or a post-install script will adjust default installations. This will probably be in the release notes.
# Use lyrebird to provide the obfs4 protocol. ServerTransportPlugin obfs4 exec /usr/local/bin/lyrebird
Will take a few more years. Gentoo & FreeBSD-Port Dev's and users are years ahead ;-)
Quoting boldsuck (2024-02-27 21:14:51)
On Dienstag, 27. Februar 2024 20:09:17 CET s7r wrote:
Is there anything needed to do with previous setups that use obfs4proxy from it's default previous repository? Or just the name has been changed and everything is backward compatible?
lyrebird is a fork of obfs4proxy, there is no mayor differences on the obfs4 part that is why we didn't do any call to migrate yet.
For us on Debian, this will only change with the next release "trixie". Then we may have to change configs or a post-install script will adjust default installations. This will probably be in the release notes.
AFAIK lyrebird is not yet packaged for debian and I don't know of anybody working on it. Do you know of some work being done for this to be included in trixie? Will be great to move that forward.
Quoting meskio (2024-02-28 10:40:04)
Quoting boldsuck (2024-02-27 21:14:51)
On Dienstag, 27. Februar 2024 20:09:17 CET s7r wrote:
Is there anything needed to do with previous setups that use obfs4proxy from it's default previous repository? Or just the name has been changed and everything is backward compatible?
lyrebird is a fork of obfs4proxy, there is no mayor differences on the obfs4 part that is why we didn't do any call to migrate yet.
For us on Debian, this will only change with the next release "trixie". Then we may have to change configs or a post-install script will adjust default installations. This will probably be in the release notes.
AFAIK lyrebird is not yet packaged for debian and I don't know of anybody working on it. Do you know of some work being done for this to be included in trixie? Will be great to move that forward.
I just found out there is already an issue in debian's bugtracker for that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063423
On 2/27/24 21:14, boldsuck wrote:
Gentoo & FreeBSD-Port Dev's and users are years ahead ;-)
Whilst I'd agree on that my Tor bridges and Snowflakes do run under a recent Debian. However Tor et al are compiled from sources. [1] [2]
[1] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-tor/tas... [2] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-tor/tas...
-- Toralf
On 2/26/24 20:07, meskio wrote:
Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now, but will instead accept bridges with the 'BridgeDistribution lox' configured in torrc.
BTW by accident I configured "any" but restarted tor with "lox" 2 minutes later. Does that work?
And FWIW:
root@luchs:~# grep lox /var/log/tor/notice.log Feb 26 20:03:50.008 [warn] Unrecognized BridgeDistribution value "lox". I'll assume you know what you are doing...
root@luchs:~# tor --version Tor version 0.4.9.0-alpha-dev (git-b0b943a1613e2f9b). Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma N/A, Libzstd N/A and Glibc 2.36 as libc. Tor compiled with GCC version 12.2.0
-- Toralf
Quoting Toralf Förster via tor-relays (2024-02-26 21:07:50)
On 2/26/24 20:07, meskio wrote:
Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now, but will instead accept bridges with the 'BridgeDistribution lox' configured in torrc.
BTW by accident I configured "any" but restarted tor with "lox" 2 minutes later. Does that work?
Yes, it looks good from here and lox is already aware of it. Thank you for setting it up so fast.
And FWIW:
root@luchs:~# grep lox /var/log/tor/notice.log Feb 26 20:03:50.008 [warn] Unrecognized BridgeDistribution value "lox". I'll assume you know what you are doing...
Yes, you can ignore this log line. Lox is not yet on the list of recognized distributors: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/576
root@luchs:~# tor --version Tor version 0.4.9.0-alpha-dev (git-b0b943a1613e2f9b). Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma N/A, Libzstd N/A and Glibc 2.36 as libc. Tor compiled with GCC version 12.2.0
:)
tor-relays@lists.torproject.org
-
boldsuck -
Corl3ss -
meskio -
s7r -
Toralf Förster