The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:59:59Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17839doc/HACKING/ReleasingTor.md doesn't emphasize updating Makefile and versions....2020-06-27T13:59:59ZRoger Dingledinedoc/HACKING/ReleasingTor.md doesn't emphasize updating Makefile and versions.wmi enough?Based on the tor-talk thread where people were thinking that Tor 0.2.6.x was still the stable release, I went to investigate and found that website's Makefile and versions.wmi both said 0.2.6.10 was the stable version.
I updated them, a...Based on the tor-talk thread where people were thinking that Tor 0.2.6.x was still the stable release, I went to investigate and found that website's Makefile and versions.wmi both said 0.2.6.10 was the stable version.
I updated them, and then went to file a ticket about how the release documentation doesn't include that step.
But it does!
So now I am filing a ticket saying that the step wasn't followed. Maybe it can be made more prominent? Or maybe we can investigate what failed in the process, so we can avoid this particular failure mode next time?
Thanks!Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/178380.2.7.6 not building on OpenBSD 5.8 (Makefile parse errors)2020-06-27T14:00:00ZTrac0.2.7.6 not building on OpenBSD 5.8 (Makefile parse errors)Current version 0.2.7.6 is not building on OpenBSD 5.8, due to the following error when running "make" (procedure: ./configure && make).
*** Parse error in /home/user/tor-0.2.7.6: Need an operator in 'TESTING_TOR_BINARY=./src/or/tor' (...Current version 0.2.7.6 is not building on OpenBSD 5.8, due to the following error when running "make" (procedure: ./configure && make).
*** Parse error in /home/user/tor-0.2.7.6: Need an operator in 'TESTING_TOR_BINARY=./src/or/tor' (Makefile:6772)
*** Parse error: Need an operator in 'PYTHON=' (Makefile:6794)
*** Parse error: Need an operator in 'SHELL=/bin/sh' (Makefile:6795)
*** Parse error: Need an operator in 'abs_top_srcdir=/home/user/tor-0.2.7.6' (Makefile:6796)
*** Parse error: Need an operator in 'builddir=.' (Makefile:6797)
**Trac**:
**Username**: chooCoh1Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17837Move SOCKSPort open proxy warning to a more sensible location2021-07-22T16:25:32ZteorMove SOCKSPort open proxy warning to a more sensible locationThe SOCKSPort open proxy warning in the manual page is just below PreferIPv6.
It should probably be just under the first SOCKSPort paragraph. (Or, perhaps, right at the end of the flags.)
Here is what it says:
```
NOTE: Although this o...The SOCKSPort open proxy warning in the manual page is just below PreferIPv6.
It should probably be just under the first SOCKSPort paragraph. (Or, perhaps, right at the end of the flags.)
Here is what it says:
```
NOTE: Although this option allows you to specify an IP address
other than localhost, you should do so only with extreme
caution. The SOCKS protocol is unencrypted and (as we use it)
unauthenticated, so exposing it in this way could leak your
information to anybody watching your network, and allow anybody
to use your computer as an open proxy.
```Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17835Make ClientPreferIPv6ORPort smarter2020-07-27T18:24:51ZteorMake ClientPreferIPv6ORPort smarterIt's hard for users on dual-stack machines to know whether their IPv4 or IPv6 connections provides better connectivity or censorship-resistance.
Tor could help with this by:
* Making ClientPreferIPv6ORPort/DirPort into an autobool, and ...It's hard for users on dual-stack machines to know whether their IPv4 or IPv6 connections provides better connectivity or censorship-resistance.
Tor could help with this by:
* Making ClientPreferIPv6ORPort/DirPort into an autobool, and setting the default to auto (infer), rather than 0 (IPv4)
* Infer initial IPv4/IPv6 preference by looking at the machine's network interfaces, and:
* Ignoring localhost (tor_addr_is_localhost) and link-local addresses (a new tor_addr_is_link_local)
* Checking for (other) private addresses (tor currently considers link-local addresses private, this shouldn't change in the rest of the codebase, but it is important to distinguish here, as IPv4/IPv6 hosts with no IPv6 connectivity still auto-configure a link-local IPv6 address)
* Checking for publicly routable addresses
* Preferring IP versions that have a public address, over those that have a private address
* (I'd also say to avoid IP versions that only have localhost or link-local addresses, and don't use IP versions that have no addresses, but that might cause issues with proxies, or with machines that prohibit enumeration of local addresses.)
* Repeat these checks every N minutes in case the network interfaces have changed (relays do this every 20 minutes at the moment)
* Infer a preference for IPv4 or IPv6 based on the number of failed connections
* Globally track counts of attempted IPv4 and IPv6 connections
* Globally track failures of attempted IPv4 and IPv6 connections
* If there have been at least M attempts (2? 3?) on (one? each?) IP version, then:
* If an IP version has 100% failure, avoid it
* IP an IP version has a significantly (2x?) larger failure rate, avoid it
I'm deferring this to 0.2.9 because:
* IPv4/IPv6 Tor clients might work fine without any of these changes.
* It's complex code, and it's not clear that it's the best way to determine preferred IP versions. (Let's get some experience with dual-stack clients first.)
* We only have 4/9 authorities and ~25% of fallback directory mirrors on IPv6, so let's prefer IPv4 by default at the moment for load-balancing reasons. (For similar reasons, ClientUseIPv6 could default to 1 in future, but now might not be a good time to do that. However, Tor Browser sets it to 1 at the moment.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17834Add ClientPreferIPv6DirPort2020-06-27T14:00:00ZteorAdd ClientPreferIPv6DirPortAdd ClientPreferIPv6DirPort to express a preference for IPv6 directory connections over IPv4 directory connections.
Tor already has ClientPreferIPv6ORPort, which expresses a preference for IPv6 OR connections over IPv4 OR connections.
...Add ClientPreferIPv6DirPort to express a preference for IPv6 directory connections over IPv4 directory connections.
Tor already has ClientPreferIPv6ORPort, which expresses a preference for IPv6 OR connections over IPv4 OR connections.
(ClientUseIPv6 allows the use of IPv6 connections, ClientPreferIPv6ORPort/ClientPreferIPv6DirPort are the tie-breakers if IPv4 and IPv6 are both equally likely.)
While we're doing this, let's warn on nonsensical situations like ClientPreferIPv6* 1 ClientUseIPv6 0. (Although ClientPreferIPv6* 0 ClientUseIPv6 1 should be an info or notice, as ClientPreferIPv6* 0 is the default.)Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17832tor (dev) build failure on NetBSD built against bleeding edge OpenSSL2020-06-27T14:00:00ZTractor (dev) build failure on NetBSD built against bleeding edge OpenSSLI'm tracking and building the development git branch of tor against the development git branch of OpenSSL on NetBSD 6_Stable...
When building tor I receive the following compile and build errors - assume this is related to OpenSSL 1.1.d...I'm tracking and building the development git branch of tor against the development git branch of OpenSSL on NetBSD 6_Stable...
When building tor I receive the following compile and build errors - assume this is related to OpenSSL 1.1.dev, but not sure...also understand this will be low priority if so...
CC src/common/crypto.o
src/common/crypto.c: In function 'crypto_global_init':
src/common/crypto.c:374:7: warning: implicit declaration of function 'ENGINE_get_default_ECDH'
src/common/crypto.c:374:7: warning: passing argument 2 of 'log_engine' makes pointer from integer without a cast
src/common/crypto.c:171:1: note: expected 'struct ENGINE *' but argument is of type 'int'
src/common/crypto.c:375:7: warning: implicit declaration of function 'ENGINE_get_default_ECDSA'
src/common/crypto.c:375:7: warning: passing argument 2 of 'log_engine' makes pointer from integer without a cast
src/common/crypto.c:171:1: note: expected 'struct ENGINE *' but argument is of type 'int'
[...]
CC src/common/src_common_libor_crypto_testing_a-crypto.o
src/common/crypto.c: In function 'crypto_global_init':
src/common/crypto.c:374:7: warning: implicit declaration of function 'ENGINE_get_default_ECDH'
src/common/crypto.c:374:7: warning: passing argument 2 of 'log_engine' makes pointer from integer without a cast
src/common/crypto.c:171:1: note: expected 'struct ENGINE *' but argument is of type 'int'
src/common/crypto.c:375:7: warning: implicit declaration of function 'ENGINE_get_default_ECDSA'
src/common/crypto.c:375:7: warning: passing argument 2 of 'log_engine' makes pointer from integer without a cast
src/common/crypto.c:171:1: note: expected 'struct ENGINE *' but argument is of type 'int'
[...]
CCLD src/or/tor
src/common/libor-crypto.a(crypto.o): In function `crypto_global_init':
/usr/local/src/tor/src/common/crypto.c:374: undefined reference to `ENGINE_get_default_ECDH'
/usr/local/src/tor/src/common/crypto.c:375: undefined reference to `ENGINE_get_default_ECDSA'
Makefile:2662: recipe for target 'src/or/tor' failed
gmake[1]: *** [src/or/tor] Error 1
gmake[1]: Leaving directory '/usr/local/src/tor'
Makefile:1868: recipe for target 'all' failed
gmake: *** [all] Error 2
**Trac**:
**Username**: yancmTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/17831investigate, if using java.nio would improve metrics-lib2020-06-27T14:23:44Ziwakehinvestigate, if using java.nio would improve metrics-libsee [Oracle NIO in J7](http://docs.oracle.com/javase/7/docs/technotes/guides/io/enhancements.html#jdk7)see [Oracle NIO in J7](http://docs.oracle.com/javase/7/docs/technotes/guides/io/enhancements.html#jdk7)Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/17830use StringBuilder correctly2020-06-27T14:23:44Ziwakehuse StringBuilder correctlyThis is not java 7 related, but should be included here:
Code like this
```
crypto = new StringBuilder();
crypto.append(line + "\n");
```
defeats the purpose of using StringBuilder, because String concatenation using `+` will interna...This is not java 7 related, but should be included here:
Code like this
```
crypto = new StringBuilder();
crypto.append(line + "\n");
```
defeats the purpose of using StringBuilder, because String concatenation using `+` will internally be accomplished by using another StringBuilder (see Javadoc).
This should also be added to the coding guidelines (or did we write these for Onionoo only?).Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17829Spoof plugin list2020-06-27T14:39:53ZTracSpoof plugin listAdd spoof plugin list and preferences
## Preferences
plugin.spoof.enable: bool
plugin.spoof.list: str (see example)
## For example:
```
"mimeTypes": [
"description": "Random",
"suffixes": "random",
"...Add spoof plugin list and preferences
## Preferences
plugin.spoof.enable: bool
plugin.spoof.list: str (see example)
## For example:
```
"mimeTypes": [
"description": "Random",
"suffixes": "random",
"type": "application/random"
],
"plugins": [
"application/random": {},
"description": "Random BLah",
"filename": "shaurma.dll",
"version": "454654.077",
"name": "Random",
"length": 1
]
```
**Trac**:
**Username**: hakimhttps://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/17828no traffic graph for 3 days and for one weeks traffic2020-06-27T14:25:20ZTracno traffic graph for 3 days and for one weeks traffichttps://atlas.torproject.org/#details/9BDF3EEA1D33AA58A2EEA9E6CA58FB8A667288FC
There is no graph for the traffic during the last 3 days and no traffic graph for for one week.
This happens for every tor server I looked at and happened ...https://atlas.torproject.org/#details/9BDF3EEA1D33AA58A2EEA9E6CA58FB8A667288FC
There is no graph for the traffic during the last 3 days and no traffic graph for for one week.
This happens for every tor server I looked at and happened with sereval browses (Iceweasel/Debian Stable, Chromium/Debian stable, Chromium/Windows)
**Trac**:
**Username**: niehausPhilipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/17827Different return type of backtrace function on FreeBSD2020-06-27T14:00:00ZcypherpunksDifferent return type of backtrace function on FreeBSDJenkins is failing compilation on FreeBSD because its backtrace function is returning `size_t` instead of `int`. This leads to the compilation errors such as
```
../tor/src/common/backtrace.c:98:11: error: implicit conversion loses integ...Jenkins is failing compilation on FreeBSD because its backtrace function is returning `size_t` instead of `int`. This leads to the compilation errors such as
```
../tor/src/common/backtrace.c:98:11: error: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Werror,-Wshorten-64-to-32]
depth = backtrace(cb_buf, MAX_DEPTH);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../tor/src/common/backtrace.c:130:11: error: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Werror,-Wshorten-64-to-32]
depth = backtrace(cb_buf, MAX_DEPTH);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../tor/src/common/backtrace.c:177:17: error: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Werror,-Wshorten-64-to-32]
int depth = backtrace(cb_buf, MAX_DEPTH);
~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17826tor not make-jobs safe2020-06-27T14:00:00ZTractor not make-jobs safeI just tried building tor from git (f3ed5ec0cac4719e249e629760756314d7cfecba) from scratch with 'make -j10' and got:
--- src/common/src_common_libor_testing_a-log.o ---
src/common/log.c:272:28: fatal error: micro-revision.i: No such fil...I just tried building tor from git (f3ed5ec0cac4719e249e629760756314d7cfecba) from scratch with 'make -j10' and got:
--- src/common/src_common_libor_testing_a-log.o ---
src/common/log.c:272:28: fatal error: micro-revision.i: No such file or directory
#include "micro-revision.i"
^
Seems there are some dependencies missing.
**Trac**:
**Username**: wizTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/17825Jenkins marks failed FreeBSD builds as successful2020-06-27T14:19:38ZcypherpunksJenkins marks failed FreeBSD builds as successfulOne example is the latest build at https://jenkins.torproject.org/job/tor-ci-freebsd-amd64-master/285/. This build is marked successful but the logs shows several errors and the build is incomplete.One example is the latest build at https://jenkins.torproject.org/job/tor-ci-freebsd-amd64-master/285/. This build is marked successful but the logs shows several errors and the build is incomplete.https://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/17824switch on string instead of many if-else with String comparison2020-06-27T14:23:44Ziwakehswitch on string instead of many if-else with String comparisonexample from BridgeNetworkStatusImpl (there are many more and longer ones):
```
switch(keyword){
case "published":
this.parsePublishedLine(line, parts);
case "flag-thresholds":
this.parseFlagThresholdsLine(...example from BridgeNetworkStatusImpl (there are many more and longer ones):
```
switch(keyword){
case "published":
this.parsePublishedLine(line, parts);
case "flag-thresholds":
this.parseFlagThresholdsLine(line, parts);
}
if (this.failUnrecognizedDescriptorLines) {
throw new DescriptorParseException("Unrecognized line '" + line
+ "' in bridge network status.");
} else {
if (this.unrecognizedLines == null) {
this.unrecognizedLines = new ArrayList<String>();
}
...
```
instead of
```
if (keyword.equals("published")) {
this.parsePublishedLine(line, parts);
} else if (keyword.equals("flag-thresholds")) {
this.parseFlagThresholdsLine(line, parts);
} else if (this.failUnrecognizedDescriptorLines) {
throw new DescriptorParseException("Unrecognized line '" + line
+ "' in bridge network status.");
} else {
if (this.unrecognizedLines == null) {
this.unrecognizedLines = new ArrayList<String>();
}
```Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/17823use diamond operator2020-06-27T14:23:44Ziwakehuse diamond operatorexample:
```
List<byte[]> rawDescriptors = new ArrayList<>();
```
instead of
```
List<byte[]> rawDescriptors = new ArrayList<byte[]>();
```example:
```
List<byte[]> rawDescriptors = new ArrayList<>();
```
instead of
```
List<byte[]> rawDescriptors = new ArrayList<byte[]>();
```Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/17822use java 7 features in metrics-lib2020-06-27T14:23:45Ziwakehuse java 7 features in metrics-libThis is the summary issue.
Each topic is added as a child issue.This is the summary issue.
Each topic is added as a child issue.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/17821adapt metrics-lib to actual tordnsel format2020-06-27T14:23:45Ziwakehadapt metrics-lib to actual tordnsel formatCurrently metrics-lib only reads tordnsel descriptors that contain
exactly one ExitAddress entry. This does not reflect the torperf data,
which can contain several ExitAddress entries [TorDNSEL description](https://collector.torproject.o...Currently metrics-lib only reads tordnsel descriptors that contain
exactly one ExitAddress entry. This does not reflect the torperf data,
which can contain several ExitAddress entries [TorDNSEL description](https://collector.torproject.org/#exit-lists) (see also legacy/trac#17701), i.e.
```
ExitNode D41C2006D7C461BDC22B9D236CC93F5D366C1388
Published 2015-12-11 12:28:41
LastStatus 2015-12-11 13:02:32
ExitAddress 37.48.65.71 2015-12-10 19:10:50
ExitAddress 37.48.74.44 2015-12-11 13:06:36
```
=== solution
metrics-libs should process tordnsel descriptors with an arbitrary count (but finite ;-) of ExitAddress lines.
(I could only find entries with one and two ExitAddress lines, but there is no limit stated in the spec.)
=== proposed changes
The interface needs to be changed:
I suggest that the current getExitAddress is marked deprecated and
returns one of the addresses read for backward compatibility
```
/**
* Return one IP address that was determined in the scan.
* @deprecated use getExitAddresses()
*/
public String getExitAddress();
```
In addition, a new method should be added
```
/* Return the IP addresses that were determined in the scan. */
public List<String> getExitAddresses();
```
Is this ok? Should anything be added or changed?Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/17820trac.torproject.org loads missing images2020-06-27T14:19:38Zcypherpunkstrac.torproject.org loads missing imagesvisiting the bug tracker, trac.torproject.org loads a few images which return 404:
trac.torproject.org/desc.png
trac.torproject.org/topbar_gradient2.png
trac.torproject.org/feed.png
trac.torproject.org/favicon.icovisiting the bug tracker, trac.torproject.org loads a few images which return 404:
trac.torproject.org/desc.png
trac.torproject.org/topbar_gradient2.png
trac.torproject.org/feed.png
trac.torproject.org/favicon.icoJens KubiezielJens Kubiezielhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17819pthread_condattr_setclock() used without checking its existence2020-06-27T14:00:00ZTracpthread_condattr_setclock() used without checking its existenceIn 0.2.7.5 (compare to 0.2.6.x) a call to pthread_condattr_setclock() was added without checking for its existence. This breaks compilation on NetBSD-6.x.
A configure check for that function should be added.
**Trac**:
**Username**: wizIn 0.2.7.5 (compare to 0.2.6.x) a call to pthread_condattr_setclock() was added without checking for its existence. This breaks compilation on NetBSD-6.x.
A configure check for that function should be added.
**Trac**:
**Username**: wizTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17818weird "export"s in Makefile break old BSD make2020-06-27T14:00:01ZTracweird "export"s in Makefile break old BSD makeWith the 0.2.7.5 (compared to 0.2.6.*) there's a new build problem with older BSD makes.
There is a bug report against pkgsrc in http://gnats.netbsd.org/50521
The problem are weird targets that have:
foo:
export BAR=baz
where the expo...With the 0.2.7.5 (compared to 0.2.6.*) there's a new build problem with older BSD makes.
There is a bug report against pkgsrc in http://gnats.netbsd.org/50521
The problem are weird targets that have:
foo:
export BAR=baz
where the export is not indented with a tab
I'm not sure what's intended here.
They look like empty targets, but then what should the exports do?
In particular:
micro-revision.i
#export TESTING_TOR_BINARY=$(top_builddir)/src/or/tor-cov
export TESTING_TOR_BINARY=$(top_builddir)/src/or/tor
and another few export lines following "FORCE:" about 10 lines below that.
Using newer BSD makes or GNU make is a workaround, but it's not clear
to me what is even the intention here.
**Trac**:
**Username**: wizTor: 0.2.7.x-finalcypherpunkscypherpunks