Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:25:49Zhttps://gitlab.torproject.org/legacy/trac/-/issues/3015Enhance bucket functionality2020-06-13T18:25:49ZChristian FrommeEnhance bucket functionalityThe bucket mechanism in BridgeDB currently lacks two important features:
a) Only give out bridges that are `fresh`, meaning those that have been seen recently enough to be considered worth giving out.
b) Give the user the opportunity to...The bucket mechanism in BridgeDB currently lacks two important features:
a) Only give out bridges that are `fresh`, meaning those that have been seen recently enough to be considered worth giving out.
b) Give the user the opportunity to add a number of fresh bridges to a certain bucket pool each time BridgeDB -d is run. This makes it much easier to only mail a delta to a given bridge distributor person plus gives that user a predictable number of new bridges each time.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/12600Save retrieved bridge information in our state file2020-06-13T14:37:31ZGeorge KadianakisSave retrieved bridge information in our state fileCurrently, Tor clients don't remember anything about bridges after a restart.
So for example, if there was a torrc Bridge line without a fingerprint specified, and Tor retrieves the fingerprint from the descriptor, it won't save it on th...Currently, Tor clients don't remember anything about bridges after a restart.
So for example, if there was a torrc Bridge line without a fingerprint specified, and Tor retrieves the fingerprint from the descriptor, it won't save it on the disk.
Or, if a bridge changed IP:PORT, but we managed to get its new ip:port using the bridge authority (see #12599), we will not save this down either.
Fortunately, Sebastian wrote proposal192 about this issue:
https://gitweb.torproject.org/torspec.git/tree/proposals/192-store-bridge-information.txt
We should re-read the proposal, revise it as needed and implement it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12931TOR_PT_SERVER_TRANSPORT_OPTIONS are not escaped according to pt-spec.txt2020-06-13T14:38:03ZYawning AngelTOR_PT_SERVER_TRANSPORT_OPTIONS are not escaped according to pt-spec.txtpt-spec.txt:
```
"TOR_PT_SERVER_TRANSPORT_OPTIONS" -- A semicolon-separated list
of <key>:<value> pairs, where <key> is a transport name and
<value> is a k=v string value with options that are to be passed
to t...pt-spec.txt:
```
"TOR_PT_SERVER_TRANSPORT_OPTIONS" -- A semicolon-separated list
of <key>:<value> pairs, where <key> is a transport name and
<value> is a k=v string value with options that are to be passed
to the transport. Colons, semicolons, equal signs and backslashes
MUST be escaped with a backslash. TOR_PT_SERVER_TRANSPORT_OPTIONS
is optional and might not be present in the environment of the
proxy if no options are need to be passed to transports.
```
or/transports.c:get_transport_options_for_server_proxy()
```
char *escaped_opts = tor_escape_str_for_pt_args(options, ":;\\");
```
Equal signs are not escaped. I'm not sure if anything will break with different behavior.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17193Don't print bridge IPs/fingerprints in WARN/NOTICE log messages2020-06-13T14:49:42ZIsis LovecruftDon't print bridge IPs/fingerprints in WARN/NOTICE log messagesBy default, we currently print out bridge IP:ports and fingerprints in tor's log messages at the notice and warn levels. Users often [copy+paste these logs to various public places](https://lists.torproject.org/pipermail/tor-talk/2015-Se...By default, we currently print out bridge IP:ports and fingerprints in tor's log messages at the notice and warn levels. Users often [copy+paste these logs to various public places](https://lists.torproject.org/pipermail/tor-talk/2015-September/039143.html) when trying to debug why their connection isn't working.
I understand that this is probably useful information to give to the support desk for debugging why tor isn't working… but would it be doable to have the support people ask, _"Hey could you add `SafeLogging 0` to your torrc?"_ or something?
I think the default should be to sanitise bridge IP:ports and fingerprints at these levels.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18329Let bridges indicate when they don't want BridgeDB to distribute their address2020-06-13T18:28:59ZKarsten LoesingLet bridges indicate when they don't want BridgeDB to distribute their addressRight now, bridges can decide whether they want to be a public bridge that gets distributed via BridgeDB or a private bridge that only gets used by clients who learn its address via some other, private channel. The default is that a bri...Right now, bridges can decide whether they want to be a public bridge that gets distributed via BridgeDB or a private bridge that only gets used by clients who learn its address via some other, private channel. The default is that a bridge is a public bridges, unless it sets `PublishServerDescriptor 0` in its `torrc` file. This works fine with respect to BridgeDB not distributing private bridges. But a lesser known problem is that a bridge that doesn't publish its descriptor also does not contribute to bridge usage statistics on Metrics that are based on bridge extra-info descriptors.
The major use case that comes to mind is a bundled bridge whose address is shipped together with Tor Browser or another application. In the past we tried to remind operators of these bridges to also publish descriptors, so that their statistics are included on Metrics. But it turns out that some censors, who carefully scrape bridge addresses from BridgeDB, do not extract bridge addresses from the various bundles. Still, bundled bridges see a large number of bridge users and we should really include them in the statistics.
Another use case could be private bridges that somebody sets up for themselves and their friends. Maybe these operators would be fine contributing to the statistics if that doesn't automatically mean they need to share their bridge with other users.
I think this feature is relatively easy to build. We would need:
- a new descriptor line "bridgedb off", or something even more intuitive and extensible, that tells BridgeDB that this bridge's address should not be distributed,
- a new torrc option or extension of an existing option, maybe "PublishServerDescriptor bridge-auth" or, again, something more intuitive, to include the line above in the descriptor, and
- an extension of BridgeDB to ignore bridges with this line when parsing descriptors.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20532Make sure directory_initiate_request handles pluggable transports correctly2020-06-13T15:23:13ZteorMake sure directory_initiate_request handles pluggable transports correctlyWhen a relay is configured as a bridge, a user reports this can lead to direct connections being made to the relay/bridge, even when a pluggable transport is configured. We have been unable to confirm this.
https://lists.torproject.org...When a relay is configured as a bridge, a user reports this can lead to direct connections being made to the relay/bridge, even when a pluggable transport is configured. We have been unable to confirm this.
https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html
We should check directory_initiate_command_rend (the linked connection case), and connection_or_connect to make sure it is not possible for a connection to go directly to a configured bridge when a transport is set up.Tor: 0.3.2.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22871Implement backend for moat2020-06-13T18:28:49ZIsis LovecruftImplement backend for moatWe'll need to finish #15967 and also the following:
- change BridgeDB to request captchas from the new server
- create an API for handing captchas to Tor LauncherWe'll need to finish #15967 and also the following:
- change BridgeDB to request captchas from the new server
- create an API for handing captchas to Tor LauncherIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/22998Update BridgeDB's .travis.yml to run tests for Debian buster dependency versions2020-06-13T18:28:49ZIsis LovecruftUpdate BridgeDB's .travis.yml to run tests for Debian buster dependency versionsweasel updated polyanthum today to Debian stretch. In keeping with running BridgeDB's CI with the currently used versions of Twisted and PyOpenSSL as well as the versions slated for the next Debian release, we'll need to update some vers...weasel updated polyanthum today to Debian stretch. In keeping with running BridgeDB's CI with the currently used versions of Twisted and PyOpenSSL as well as the versions slated for the next Debian release, we'll need to update some version numbers.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/23011Update leekspin's requirements.txt2020-06-13T18:28:50ZSamdneyUpdate leekspin's requirements.txtIn a fresh python2 virtualenv enviroment, I cloned and installed leekspin and the requirements with "pip install -r requirements.txt". After running "leekspin -n 20" I received the following error:
```
Code highlighting:
{{{#!python ...In a fresh python2 virtualenv enviroment, I cloned and installed leekspin and the requirements with "pip install -r requirements.txt". After running "leekspin -n 20" I received the following error:
```
Code highlighting:
{{{#!python
Traceback (most recent call last):
File "/mypath/python2env/bin/leekspin", line 37, in <module>
from leekspin import generator
File "/mypath/python2env/lib/python2.7/site-packages/leekspin/generator.py", line 27, in <module>
import OpenSSL
File "/mypath/python2env/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
from OpenSSL import rand, crypto, SSL
File "/mypath/python2env/lib/python2.7/site-packages/OpenSSL/SSL.py", line 105, in <module>
SSL_ST_INIT = _lib.SSL_ST_INIT
AttributeError: 'module' object has no attribute 'SSL_ST_INIT'
}}}
```
I changed in "requirements.txt" the entry
PyOpenSSL==0.14
to
PyOpenSSL==16.2.0
Now it works fine :)Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/23032BridgeDB's email server stopped working upon upgrade to Debian 92020-06-13T18:28:50ZIsis LovecruftBridgeDB's email server stopped working upon upgrade to Debian 9At least one of the problems stems from changes to Twisted made somewhere between 14.0.2 and 16.6.0, including that some classes/modules are missing/moved:
```
Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2...At least one of the problems stems from changes to Twisted made somewhere between 14.0.2 and 16.6.0, including that some classes/modules are missing/moved:
```
Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 103, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 86, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext
return func(*args,**kw)
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 597, in _doReadOrWrite
why = selectable.doRead()
File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 208, in doRead
return self._dataReceived(data)
File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 214, in _dataReceived
rval = self.protocol.dataReceived(data)
File "/usr/lib/python2.7/dist-packages/twisted/protocols/basic.py", line 454, in dataReceived
self.lineReceived(line)
File "/usr/lib/python2.7/dist-packages/twisted/mail/smtp.py", line 389, in lineReceived
return getattr(self, 'state_' + self.mode)(line)
File "/usr/lib/python2.7/dist-packages/twisted/mail/smtp.py", line 630, in dataLineReceived
m.eomReceived() for m in self.__messages
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.4.0+0.g62b17e8.dirty-py2.7.egg/bridgedb/email/server.py", line 238, in eomReceived
self.message = self.getIncomingMessage()
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.4.0+0.g62b17e8.dirty-py2.7.egg/bridgedb/email/server.py", line 257, in getIncomingMessage
return smtp.rfc822.Message(rawMessage)
exceptions.AttributeError: 'module' object has no attribute 'rfc822'
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/23033BridgeDB's tests are failing due to Twisted Trial changing the way modules ar...2020-06-13T18:28:51ZIsis LovecruftBridgeDB's tests are failing due to Twisted Trial changing the way modules are calledThis is happening after the upgrade to Debian 9, because Twisted was upgraded from 14.0.2 to 16.6.0. Relative imports of helper functions in the unittests directory [are now broken](https://travis-ci.org/isislovecruft/bridgedb/jobs/25626...This is happening after the upgrade to Debian 9, because Twisted was upgraded from 14.0.2 to 16.6.0. Relative imports of helper functions in the unittests directory [are now broken](https://travis-ci.org/isislovecruft/bridgedb/jobs/256269715):
```
[ERROR]
Traceback (most recent call last):
File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/twisted/trial/runner.py", line 602, in loadByNames
things.append(self.findByName(name))
File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/twisted/trial/runner.py", line 405, in findByName
return filenameToModule(name)
File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/twisted/trial/runner.py", line 96, in filenameToModule
return _importFromFile(fn)
File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/twisted/trial/runner.py", line 119, in _importFromFile
module = imp.load_source(moduleName, fn, fd)
File "./test/test_translations.py", line 14, in <module>
from .https_helpers import DummyRequest
exceptions.ValueError: Attempted relative import in non-package
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/23034Running `python setup.py test` for BridgeDB is broken2020-06-13T18:28:51ZIsis LovecruftRunning `python setup.py test` for BridgeDB is brokenDue to #23033. :(
The fix is to move the top-level `tests/` directory back to `bridgedb/tests`. :(Due to #23033. :(
The fix is to move the top-level `tests/` directory back to `bridgedb/tests`. :(Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/23598Bump pyOpenSSL in BridgeDB to 16.2.02020-06-13T18:28:57ZGeorg KoppenBump pyOpenSSL in BridgeDB to 16.2.0When doing e.g. `pip install -r .test.requirements.txt` (with OpenSSL 1.1.0f) one gets
```
Traceback (most recent call last):
File "/home/thomas/.virtualenvs/bridgedb/bin/pip", line 7, in <module>
from pip import main
File "/home...When doing e.g. `pip install -r .test.requirements.txt` (with OpenSSL 1.1.0f) one gets
```
Traceback (most recent call last):
File "/home/thomas/.virtualenvs/bridgedb/bin/pip", line 7, in <module>
from pip import main
File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-packages/pip/__init__.py", line 21, in <module>
from pip._vendor.requests.packages.urllib3.exceptions import DependencyWarning
File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-packages/pip/_vendor/__init__.py", line 64, in <module>
vendored("cachecontrol")
File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-packages/pip/_vendor/__init__.py", line 36, in vendored
__import__(modulename, globals(), locals(), level=0)
File "/home/thomas/.virtualenvs/bridgedb/share/python-wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/__init__.py", line 9, in <module>
File "/home/thomas/.virtualenvs/bridgedb/share/python-wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/wrapper.py", line 1, in <module>
File "/home/thomas/.virtualenvs/bridgedb/share/python-wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/adapter.py", line 4, in <module>
File "/home/thomas/.virtualenvs/bridgedb/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/__init__.py", line 52, in <module>
File "/home/thomas/.virtualenvs/bridgedb/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/packages/__init__.py", line 59, in <module>
File "/home/thomas/.virtualenvs/bridgedb/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/packages/__init__.py", line 32, in vendored
File "/home/thomas/.virtualenvs/bridgedb/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/contrib/pyopenssl.py", line 47, in <module>
File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
from OpenSSL import rand, crypto, SSL
File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-packages/OpenSSL/SSL.py", line 105, in <module>
SSL_ST_INIT = _lib.SSL_ST_INIT
AttributeError: 'module' object has no attribute 'SSL_ST_INIT'
```
This is essentially https://github.com/pyca/pyopenssl/issues/525.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/23957Add support for bridge-distribution descriptor lines in BridgeDB2020-06-13T18:28:59ZIsis LovecruftAdd support for bridge-distribution descriptor lines in BridgeDBBridgeDB should be capable of allowing operators to choose if/how to distribute their bridges, which is possible after #18329. Already #21177 is in Stem, so we just need to update BridgeDB to the latest Stem master and add some handling ...BridgeDB should be capable of allowing operators to choose if/how to distribute their bridges, which is possible after #18329. Already #21177 is in Stem, so we just need to update BridgeDB to the latest Stem master and add some handling in the descriptor parsing and distribution code.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/24264Enable IPv6 reachability testing for the Bridge Authority2020-06-13T16:03:47ZIsis LovecruftEnable IPv6 reachability testing for the Bridge AuthorityWe'll need to set `AuthDirHasIPv6Connectivity 1`.We'll need to set `AuthDirHasIPv6Connectivity 1`.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24432The meek<->moat tunneling isn't set up correctly2021-07-29T15:07:40ZIsis LovecruftThe meek<->moat tunneling isn't set up correctlyThe apache config has:
...The apache config has:
ProxyPass /meek/ http://127.0.0.1:2000/
ProxyPass /moat/ http://127.0.0.1:3881/moat/
ProxyPass / http://127.0.0.1:3880/ retry=10
ProxyPassReverse / http://127.0.0.1:3880/
(BridgeDB's HTTPS distributor is a Python process listening on port 3880, and the moat distributor is listening on 3881.)
The moat-server is run with the following:
∃!isisⒶwintermute:(master $>)~/code/torproject/bridgedb-admin ∴ cat bin/run-meek
#!/usr/bin/env bash
export TOR_PT_MANAGED_TRANSPORT_VER=1
export TOR_PT_SERVER_BINDADDR=meek-0.0.0.0:2000
#export TOR_PT_SERVER_BINDADDR=meek-78.47.38.229:2000
export TOR_PT_SERVER_TRANSPORTS=meek
export TOR_PT_ORPORT=127.0.0.1:443
/srv/bridges.torproject.org/bin/meek-server --disable-tls & disown
The moat distributor has two pages, /moat/fetch and /moat/check. In my Tor Browser, if I go to https://4-dot-tor-bridges-hyphae-channel.appspot.com/meek/moat/fetch I get a "301 Permanent Redirect" from the Apache server telling me to go to https://bridges.torproject.org/meek/meek/moat/fetch.
Probably I've just configured all the URIs wrong?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/24433moat isn't returning bridges on successful CAPTCHA completion2020-06-13T18:29:03ZIsis Lovecruftmoat isn't returning bridges on successful CAPTCHA completionPearl Crescent reported that moat isn't returning bridges upon successful CAPTCHA completion. This needs to be debugged/investigated.Pearl Crescent reported that moat isn't returning bridges upon successful CAPTCHA completion. This needs to be debugged/investigated.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/24443moat gives out QRcodes when we didn't ask for them2020-06-13T18:29:04ZIsis Lovecruftmoat gives out QRcodes when we didn't ask for themFrom #24433:
> Actually, heh. From the above output, there's another bug (although it shouldn't stop testing). It's giving a QR when we said we didn't need one. I guess it's nice to know the server is enthusiastic about sending images...From #24433:
> Actually, heh. From the above output, there's another bug (although it shouldn't stop testing). It's giving a QR when we said we didn't need one. I guess it's nice to know the server is enthusiastic about sending images anyway (and that it works).
We'll need to make sure that JSON requests with `{"qrcode": "false"}` are actually respected before we release this to actual clients, since (if Tor Launcher doesn't need the QRcode) it's a waste of bandwidth and memory.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/24460Fix unhandled error due to twisted changes in URLPath class2020-06-13T18:29:05ZIsis LovecruftFix unhandled error due to twisted changes in URLPath classNot sure when this started happening (probably when we upgraded to Twisted-16.x.x), and it doesn't seem to have any actual effect from the users' point of view, but, on the BridgeDB server, using version 0.6.0, there's this error traceba...Not sure when this started happening (probably when we upgraded to Twisted-16.x.x), and it doesn't seem to have any actual effect from the users' point of view, but, on the BridgeDB server, using version 0.6.0, there's this error traceback:
```
Unhandled Error
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/protocols/basic.py", line 571, in dataReceived
why = self.lineReceived(line)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/web/http.py", line 1688, in lineReceived
self.allContentReceived()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/web/http.py", line 1767, in allContentReceived
req.requestReceived(command, path, version)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/web/http.py", line 768, in requestReceived
self.process()
--- <exception caught here> ---
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/web/server.py", line 183, in process
self.render(resrc)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/web/server.py", line 234, in render
body = resrc.render(self)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/web/resource.py", line 250, in render
return m(request)
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.6.0+0.gb4d32c7.dirty-py2.7.egg/bridgedb/distributors/https/server.py", line 612, in render_POST
return CaptchaProtectedResource.render_POST(self, request)
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.6.0+0.gb4d32c7.dirty-py2.7.egg/bridgedb/distributors/https/server.py", line 478, in render_POST
if self.checkSolution(request) is True:
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.6.0+0.gb4d32c7.dirty-py2.7.egg/bridgedb/distributors/https/server.py", line 538, in checkSolution
challenge, solution = self.extractClientSolution(request)
File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-packages/bridgedb-0.6.0+0.gb4d32c7.dirty-py2.7.egg/bridgedb/distributors/https/server.py", line 414, in extractClientSolution
return redirectTo(request.URLPath(), request)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/web/util.py", line 73, in redirectTo
""" % {'url': nativeString(URL)}
File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-packages/twisted/python/compat.py", line 361, innativeString
raise TypeError("%r is neither bytes nor unicode" % s)
exceptions.TypeError: URLPath(scheme='http', netloc='127.0.0.1:3880', path='/bridges', query=_, fragment=_) is neither bytes nor unicode
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/25127Rust implementation of protover_get_supported_protocols() leaks memory2020-06-13T15:21:32ZNick MathewsonRust implementation of protover_get_supported_protocols() leaks memoryThe src/rust/protover/ffi.rs version of protover_get_supported_protocols returns a newly allocated char*. But the C version of it returns a const char *, and doesn't allocate. This difference causes a memory leak when the C code uses t...The src/rust/protover/ffi.rs version of protover_get_supported_protocols returns a newly allocated char*. But the C version of it returns a const char *, and doesn't allocate. This difference causes a memory leak when the C code uses the rust.Tor: 0.3.3.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/25185Create utilities for using Rust static strings in C2020-06-13T15:32:55ZIsis LovecruftCreate utilities for using Rust static strings in CThis is a continuation of #25127, to provide some utilities for working with static strings across the FFI boundary without accidentally introducing leaks.This is a continuation of #25127, to provide some utilities for working with static strings across the FFI boundary without accidentally introducing leaks.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/25246Devise a way to dump all the unallocated bridges into the moat distributor2020-06-13T18:29:09ZIsis LovecruftDevise a way to dump all the unallocated bridges into the moat distributorWe'll need to write some SQL to reassign the bridges and there should probably be a script to do this, since "dumping them into another distributor" is why they were ostensibly put in reserve in the first place.We'll need to write some SQL to reassign the bridges and there should probably be a script to do this, since "dumping them into another distributor" is why they were ostensibly put in reserve in the first place.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/25271Remove duplicate #include onion_ntor.h from src/test//test.c2020-06-13T15:22:06ZIsis LovecruftRemove duplicate #include onion_ntor.h from src/test//test.cThere's two of them. It set off an immediate gut reaction to Ctrl-K the line.There's two of them. It set off an immediate gut reaction to Ctrl-K the line.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25310Document our policy for Rust dependencies2020-06-13T15:23:51ZIsis LovecruftDocument our policy for Rust dependenciesWe should document what our (experimental, subject to change) policies are w.r.t. new Rust dependencies in tor, somewhere in the `doc/HACKING/` directory.We should document what our (experimental, subject to change) policies are w.r.t. new Rust dependencies in tor, somewhere in the `doc/HACKING/` directory.Tor: 0.3.4.x-final