-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi weasel,
following your comment [1] about your plans to use systemd instead of
init.d scripts I prepared unit files [2] - tested with debian jessie.
Would be great if you could comment on them.
Since it feels a bit as if I would use the wrong communication channel
(trac), please let me know if I should move this elsewhere.
thanks,
Nusenu
[1] https://trac.torproject.org/projects/tor/ticket/14995#comment:14
[2] https://trac.torproject.org/projects/tor/ticket/14995#comment:24
https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian…
https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian…
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVFqosAAoJEFv7XvVCELh0AjgQAIlLflC6f+mqUUiAyvQsTO/4
+fNK1MBFUNJUpEws3gqD/3OQfBnhuV9Po4SiRMPfQo0IHuLSB0jNHslOexVBWzpY
s4ypeNAH+Eu58Pomexo9xOMCZTmM7Jmhm8HdCodSXBMSKlK1jMwqqmRRQDnijf3T
hYos6yeJydwXnV2yDaeF6AOiuAzIQC2s+Mwu+tynX3ETCIyDzsDcQEOaDiwnmWBX
76kIqz0sF0N7tOeMiLoMvK1J9HhW+sMH4aaGwZFXPCMLEpziIB5spEmgvpa+SoQ0
dG2q3Hd7ryBaac/KSeX/Dyidur8LxheA9slVqwkdcorXWBdQd7Xnom2WTOs/2cSf
Dy3ZFJD1vi3/y6Gq0DsWY3Z4XhPPs4gTVOL056Xc/GyZXmPvAVI5mk8EdtU7ezbu
NxXqjVoEcX59IWhyMOjh2eaeEZvaxmyfP38ek2f6nH5pZv9FtmjKZ61LwYtL8qJx
wEn+qIVXy1Zl+qU/NhUpMeUqn029Ci+mL+6x/JfNpaka81Rtqsb+6SKQQwPwGGu7
2SwsDjM+B6YsWSf3niL3rp23XWaT1mM830QBnTrMpE+kht/4b1ytgs7NV72E30+5
Ibi5y/F/TkTc6yExJd1qxKkpXY0gnEWIgf0l4ik5FOD3DK47lQgKYg4feAcPxLUo
qFDT5Y0Fnhezh5DVnRp+
=mtYl
-----END PGP SIGNATURE-----
Hello all,
Yesterday I released and deployed BridgeDB-0.3.2, which has several major
fixes and changes.
Major changes visible to users include: changing the default pluggable
transport to obfs4, and users requesting bridges will note that they are again
normally receiving the maximum number (3) of bridges.
The temporary decrease in bridges was due to the fact that, while rewriting
BridgeDB's bridge descriptor parsers (#9380), I implemented full verification
of all cryptographic data involved, including signatures and descriptor
digests, in order to validate the chain of bridge information from the
networkstatus document (produced by the BridgeAuthority), to bridge
server-descriptors, and finally to bridge `extrainfo` descriptors (which
contain information on a bridge's pluggable transports). This turned out to
be somewhat of a bad idea, because the BridgeAuthority appears to not
producing good networkstatus documents (see #11216, #12254, #15707, and
#15866).
Changes in version 0.3.2 - 2015-05-01
* FIXES a problem with the calculation of Levenshtein distances
between blacklisted email addresses and those on incoming
email. This fixes a problem with the fuzzy matching implemented in
#9385: https://bugs.torproject.org/9385.
* FIXES #1839 https://bugs.torproject.org/1839
BridgeDB's distributors now rotate their hashrings at
configurable scheduled intervals.
* FIXES #4771 https://bugs.torproject.org/4771
BridgeDB now records which of the HTTPS Distributor's
sub-hashrings are used for clients coming from Tor Exit nodes and
other known proxies.
* FIXES #12504 https://bugs.torproject.org/12504
Which Pluggable Transports BridgeDB distributes is now easily
configurable via the bridgedb.conf configuration file.
* FIXES #13202 https://bugs.torproject.org/13202
Old bridges running Tor-0.2.4.x with Pluggable Transports like
scramblesuit and obfs4proxy have a bug which causes them to not
include the PT arguments in the `transport` line they submit to
the BridgeAuthority in their extrainfo descriptors. This causes
BridgeDB to have broken bridge lines for these bridges.
For example, scramblesuit requires a `password=` in the
`ClientTransportPlugin` for clients to connect to it. If BridgeDB
receives a line in that bridge's extrainfo which says
`transport scramblesuit 1.2.3.4:1234` (without a password), then
when BridgeDB gives clients a bridge line for that bridge, it'll
look like "Bridge scramblesuit 1.2.3.4:1234" - meaning that it won't
work. This fixes the issue by excluding broken transports from
being distributed to clients.
* FIXES #15517 https://bugs.torproject.org/15517
For all clients who are coming from IPv6 addresses and are not
using Tor, who go to https://bridges.torproject.org, BridgeDB now
groups these clients together by /32. This "grouping" causes all
IPv6 clients within the same IPv6 /32 to get the same bridges.
Previously, BridgeDB grouped IPv6 clients by /64 (which is
ridiculously small, considering standard IPv6 allocation sizes).
For all clients who are coming from IPv4 addresses and are not
using Tor, BridgeDB now groups these clients together by /16.
Previously, BridgeDB grouped IPv4 clients by /24. (This latter
change was technically made as part of #4771.)
* FIXES #15464 https://bugs.torproject.org/15464
The setup procedure for creating a BridgeDB Continuous Integration
build machine is now simplified and generalised to include build
environments like Jenkins, not just TravisCI.
* FIXES #15866 https://bugs.torproject.org/15866
BridgeDB now ignores nearly all the information in the
networkstatus-bridges file created by the BridgeAuthority.
* ADDS benchmark tests to BridgeDB's test suite, and some of
BridgeDB's algorithms have been revised to improve their speed.
As per usual, the full CHANGELOG is available here:
https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG
--
♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
