The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:09:44Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1160AllowSingleHopExits setting can be bypassed by client2020-06-27T14:09:44ZTracAllowSingleHopExits setting can be bypassed by clientUsing the software Tortunnel
http://www.thoughtcrime.org/software/tortunnel/
it is easy to setup a 1-hop proxy through a selected exit node,
even if the node has AllowSingleHopExits set to 0 (default).
Maybe i'm being alarmist, but thi...Using the software Tortunnel
http://www.thoughtcrime.org/software/tortunnel/
it is easy to setup a 1-hop proxy through a selected exit node,
even if the node has AllowSingleHopExits set to 0 (default).
Maybe i'm being alarmist, but this seems like abuse waiting to happen -
a disaster for exit node operators and for network capacity re:p2p.
If this isnt fixable in a few days i'll be switching to non-exit.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1162cant start a relay2020-06-27T14:09:44ZTraccant start a relayHello . I just tried your software. It works ok as long as I use it as a client but not if I try to relay : it crashes every time, it says tor as unexpedly exits.
here the log :
déc. 02 19:20:13.594 [Notice] Tor v0.2.1.20. This is experi...Hello . I just tried your software. It works ok as long as I use it as a client but not if I try to relay : it crashes every time, it says tor as unexpedly exits.
here the log :
déc. 02 19:20:13.594 [Notice] Tor v0.2.1.20. This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
déc. 02 19:20:15.454 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
déc. 02 19:20:15.454 [Notice] Opening Socks listener on 127.0.0.1:9050
déc. 02 19:20:15.454 [Notice] Opening Control listener on 127.0.0.1:9051
déc. 02 19:20:28.766 [Notice] Parsing GEOIP file.
déc. 02 19:20:28.766 [Notice] We now have enough directory information to build circuits.
déc. 02 19:20:28.766 [Notice] Bootstrapped 80%: Connecting to the Tor network.
déc. 02 19:20:28.766 [Notice] Bootstrapped 85%: Finishing handshake with first hop.
déc. 02 19:20:28.766 [Notice] Bootstrapped 90%: Establishing a Tor circuit.
déc. 02 19:20:28.766 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
déc. 02 19:20:28.766 [Notice] Bootstrapped 100%: Done.
déc. 02 19:20:28.766 [Notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
déc. 02 19:20:28.766 [Notice] Opening OR listener on 0.0.0.0:443
déc. 02 19:20:28.766 [Notice] Opening Directory listener on 0.0.0.0:9030
déc. 02 19:20:28.766 [Notice] Your Tor server's identity key fingerprint is 'Unnamed AC09D7B124DE36F537AD17F586BF41C397F0B67F'
déc. 02 19:20:28.766 [Error] libevent call with win32 failed: Socket operation on nonsocket [WSAENOTSOCK ] [10038]
No matter what I try the last line always occur and crash the software.
Im under xp sp3 pro.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tedtedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1172ORPort found reachable, but I have no routerinfo2020-06-27T14:09:44ZTracORPort found reachable, but I have no routerinfoHello,
Today i update the git version on master branch : commit d086c9a7f73ce5b9b7cf4add07fa7d071b829081
Merge: 9e6225a 28b29e0
and a bug are signaled on my log about the "router_or:port"
déc. 12 17:00:28.456 [Warning] router_orport_f...Hello,
Today i update the git version on master branch : commit d086c9a7f73ce5b9b7cf4add07fa7d071b829081
Merge: 9e6225a 28b29e0
and a bug are signaled on my log about the "router_or:port"
déc. 12 17:00:28.456 [Warning] router_orport_found_reachable(): Bug: ORPort found reachable, but I have no routerinfo yet. Failing to inform controller of success.
libevent: 2.03 alpha Repository UUID: ce677c24-8c1a-0410-9497-a30ef3a96221
Revision: 1557
libc6: 2.10.1 (ubuntu15) (amd64)
OS: kubuntu karmic 9.10 on x86 64 ,Linux moon 2.6.31-17-generic legacy/trac#54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
vidalia: 2.7svn Repository UUID: 819a2799-b909-0410-be78-af92f3896072
Revision: 4177
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1173crypto.c:613: error: comparison of unsigned expression >= 0 is always true2020-06-27T14:09:44ZRoger Dingledinecrypto.c:613: error: comparison of unsigned expression >= 0 is always truehttps://buildbot.vidalia-project.net/builders/kore.fc12.tor-master/builds/0/steps/compile/logs/stdio
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-ar...https://buildbot.vidalia-project.net/builders/kore.fc12.tor-master/builds/0/steps/compile/logs/stdio
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wbad-function-cast -Wswitch-enum -Werror -Winit-self -Wmissing-field-initializers -Wdeclaration-after-statement -Wold-style-definition -Waddress -Wmissing-noreturn -Wnormalized=id -Woverride-init -Wstrict-overflow=1 -Wextra -Warray-bounds -MT crypto.o -MD -MP -MF .deps/crypto.Tpo -c -o crypto.o crypto.c
cc1: warnings being treated as errors
crypto.c: In function ‘crypto_pk_write_key_to_string_impl’:
crypto.c:613: error: comparison of unsigned expression >= 0 is always true
make[3]: *** [crypto.o] Error 1
Line is
tor_assert(buf->length >= 0);
where buf is
BUF_MEM *buf;
I bet fc12's openssl has a different BUF_MEM.
edmanm> [edmanm@kore ~]$ openssl version
edmanm> OpenSSL 1.0.0-fips-beta4 10 Nov 2009
Sebastian> the line hasn't been changed since r2461
Nick, any opinions?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1175Current Tor bundle crashing on Mac OS X 10.4.11/Intel2020-06-27T14:09:43ZTracCurrent Tor bundle crashing on Mac OS X 10.4.11/IntelI'm downloading the regular recommended Tor bundle from the web site. When it crashes, I find this in the Vidalia log:
http://pastebin.com/m35b7f26d
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
...I'm downloading the regular recommended Tor bundle from the web site. When it crashes, I find this in the Vidalia log:
http://pastebin.com/m35b7f26d
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: wAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1176server_port_flush looks strange2020-06-27T14:09:43ZSebastian Hahnserver_port_flush looks strangeCoverity (cid 424) complains about us using a freed variable inside the
while loop. Technically we're not doing anything dangerous, because
we explicitly set that variable to null, but while looking at the loop, it
seems that it can neve...Coverity (cid 424) complains about us using a freed variable inside the
while loop. Technically we're not doing anything dangerous, because
we explicitly set that variable to null, but while looking at the loop, it
seems that it can never be executed more than once, because
port->pending_replies is never updated. It appears to me that a patch
like this should fix the problem:
diff --git a/src/or/eventdns.c b/src/or/eventdns.c
index 83bff67..70cf28c 100644
--- a/src/or/eventdns.c
+++ b/src/or/eventdns.c
@@ -1303,6 +1303,12 @@ server_port_flush(struct evdns_server_port *port)
return;
log(EVDNS_LOG_WARN, "Error %s (%d) while writing response to port; dropping", tor_socket_strerror(err), err);
}
+ if (req->next_pending && req->next_pending != req) {
+ port->pending_replies = req->next_pending;
+ } else {
+ port->pending_replies = NULL;
+ }
+
if (server_request_free(req)) {
/* we released the last reference to req->port. */
return;
But maybe I'm missing some subtleties here?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1177Segfault in unit tests on Mac OS X Panther2020-06-27T14:09:43ZedmanmSegfault in unit tests on Mac OS X Pantherhttps://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit bu...https://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 102948 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 102948
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 65671 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 65671
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 55 buildtimes.
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 57 buildtimes.
process killed by signal 11
program finished with exit code -1
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1181evdns_server_request_format_response() sets TC flag wrong2020-06-27T14:09:43ZRoger Dingledineevdns_server_request_format_response() sets TC flag wrongkenobi> evdns_server_request_format_response() with dnsname_to_labels()
wrongly implements part of rfc1035 about logic for sets of TC bit.
kenobi> " Messages carried by UDP are restricted to 512 bytes (not counting
the IP or UDP headers)...kenobi> evdns_server_request_format_response() with dnsname_to_labels()
wrongly implements part of rfc1035 about logic for sets of TC bit.
kenobi> " Messages carried by UDP are restricted to 512 bytes (not counting
the IP or UDP headers). Longer messages are truncated and the TC bit is set
in the header"
kenobi> TC bits should be sets only if lenght of all message via UDP was more
than 512 bytes. Not alone lables or names.
kenobi> for now TC bit sets for wrongly lengthed labels, which stricly limits
for 63, but those means transmited error not signaling truncate bit.
> do you have a patch? :)
kenobi> I do not have patch, because it's should be designed for future tcp
transport too, so it's slightly hard for patch by one line.
> (does this affect anything in practice, or is it just a theoretical
correctness issue?)
kenobi> It's can be exploit via exotic attack, if reverse lookup was
controled by attacker and exit relay was too. And resolv.conf contained ISP's
DNS.
> what would the attack achieve, in that case?
kenobi> ip address of ISP's DNS
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1184Sending useless relay cells after the destroy cell2020-06-27T14:09:43ZRoger DingledineSending useless relay cells after the destroy cellr9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call con...r9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call connection_or_send_destroy().
The first is in relay.c, where we unlink the circ from the n_conn
immediately after.
The second is in command.c, where we refuse new circuits for various
reasons. No cells queued yet.
The third is in circuitlist.c, during circuit-mark-for-close. So the
question is, if the circuit is marked, do we really want to still be
trying to send its cells? Either it got marked from the other side,
in which case the other side has already decided it doesn't want to hear
from us. Or it got marked from our side, in which case either that was
an error (circuit needs to die) or it has no streams on it, in which
case there's no harm in clearing its queue.
Did I miss anything?
Perhaps we should check, in main.c when we're considering whether to mark
it because it's idle, whether there are any cells still in its queue.
Or maybe we should just pass an argument into connection_or_send_destroy()
from the truncate case in relay.c saying "clear the queue please". Then we
can remain ambiguous in the cases above where I said "no harm because surely
the queue has nothing in it". That's certainly the safest approach, but
wouldn't it be nice to simplify rather than complexify? :)
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1187getinfo bridge status2020-06-27T14:09:43ZRoger Dingledinegetinfo bridge statusA user from China suggests at
http://blog.torproject.org/blog/bridge-distribution-strategies#comment-3336 :
"I have a fairly long list of bridges in my settings tab now, and I have no
idea which are actually of any use to me, and which ...A user from China suggests at
http://blog.torproject.org/blog/bridge-distribution-strategies#comment-3336 :
"I have a fairly long list of bridges in my settings tab now, and I have no
idea which are actually of any use to me, and which are dead. Would it be
possible to have some visual indicator in the Vidalia bridge config dialog
that shows which bridges are healthy and which are not?"
This is a great idea, and we should do it. Perhaps Tor should expose this info
via a 'getinfo bridge-status' or equivalent, and then we can show which ones
are configured, which we have a fresh descriptor for, which we've found
reachable, etc. Once we've got the Tor side figured out, then Vidalia could
ask for the bridge status when you open the bridge config window, and mark them
as appropriate.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1190Renegotiation bug still present on OpenBSD 4.6 stable2020-06-27T14:09:43ZTracRenegotiation bug still present on OpenBSD 4.6 stableRenegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works wit...Renegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works without the patch, but that
leaves the whole system vulnerable.
[warn] TLS error: unexpected close while renegotiating
same exact problem with 0.2.2.6-alpha
OpenBSD 4.6 ships with OpenSSL 0.9.8k
What is the work-around?
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: nixmlistsTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1191renegotiation bug still present in 0.2.2.6-alpha on OpenBSD 4.6 stable2020-06-27T14:09:43ZTracrenegotiation bug still present in 0.2.2.6-alpha on OpenBSD 4.6 stableRenegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in 0.2.2.6-alpha, and prevents it from working....Renegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in 0.2.2.6-alpha, and prevents it from working. Works without the patch, but that
leaves the whole system vulnerable.
[warn] TLS error: unexpected close while renegotiating
same exact problem with 0.2.1.21
OpenBSD 4.6 ships with OpenSSL 0.9.8k
What is the work-around?
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: nixmlistshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1194crypto_rand_uint64: Assertion max > 0 failed2020-06-27T14:09:42ZTraccrypto_rand_uint64: Assertion max > 0 failedI'm running tor-0.2.1.21 on an embedded device, a Sagem F@st 3464 modem/router.
some specs:
busybox-1.15.3
uclibc-0.9.26
libevent-1.4.12
openssl-0.9.8l
When starting tor it always fails with following error message:
[err] Bug: crypto.c...I'm running tor-0.2.1.21 on an embedded device, a Sagem F@st 3464 modem/router.
some specs:
busybox-1.15.3
uclibc-0.9.26
libevent-1.4.12
openssl-0.9.8l
When starting tor it always fails with following error message:
[err] Bug: crypto.c:1876: crypto_rand_uint64: Assertion max > 0 failed; aborting.
Is there anything I can do to locate the problem?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: cygeushttps://gitlab.torproject.org/tpo/core/tor/-/issues/1195manpage doesn't talk about mbytes and friends2020-06-27T14:09:42ZSebastian Hahnmanpage doesn't talk about mbytes and friendsMaking this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
...Making this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
the examples values all are "KBytes", e.g. "RelayBandwidthRate 100 KBytes"
Sebastian| you can use either one
waltman| cool, thanks
Sebastian| we should fix that in the manpage.
Sebastian| we're thinking about how we can make the manpage easier to
understand for the average use. Hopefully we'll find something.
In our efforts to make the manpage less confusing and more usable for people
with less *nix experience, we might want to explore explaining what we mean
when we allow the user to specify some amount of bandwidth in one section,
and the refer to that section from all the options.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1196upgrade log level of "Authenticated control connection" message to notice2020-06-27T14:09:42ZTracupgrade log level of "Authenticated control connection" message to noticeIt is important for normal operation and security
to know when something connects to the control port.
Don't really want to see all the other info logging
under normal circumstances though.
Suggest upgrading the message from log_info to...It is important for normal operation and security
to know when something connects to the control port.
Don't really want to see all the other info logging
under normal circumstances though.
Suggest upgrading the message from log_info to log_notice.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1197Graceful shutdown doesn't seem so graceful2020-06-27T14:09:42ZTracGraceful shutdown doesn't seem so gracefulMay be by design: When doing a graceful shutdown, bandwidth graph shows data still flowing at full BW when relay's plug is pulled.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: sponge...May be by design: When doing a graceful shutdown, bandwidth graph shows data still flowing at full BW when relay's plug is pulled.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: sponge_bob_128https://gitlab.torproject.org/tpo/core/tor/-/issues/1198Solaris 10 compile error "RLIMIT_MEMLOCK undeclared"2020-06-27T14:09:42ZTracSolaris 10 compile error "RLIMIT_MEMLOCK undeclared"When trying to compile tor-0.2.2.6-alpha I get the following error:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .de...When trying to compile tor-0.2.2.6-alpha I get the following error:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function `tor_set_max_memlock':
compat.c:2224: error: `RLIMIT_MEMLOCK' undeclared (first use in this function)
compat.c:2224: error: (Each undeclared identifier is reported only once
compat.c:2224: error: for each function it appears in.)
gmake[3]: *** [compat.o] Error 1
gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
This is not an issue with tor-0.2.1.21, I have compiled and running tor-0.2.1.21.
The Solaris 10 is the latest release "5.10 Generic_127112-10 i86pc i386 i86pc" (Nov. 2009) with all recommended
patches.
The details for configure and compiling are as follows:
usmine:/usr/local/lib/tor-0.2.2.6-alpha>
usmine:/usr/local/lib/tor-0.2.2.6-alpha> ./configure --with-libevent-dir=/opt/csw \
> --with-tor-user=tor \
> --with-tor-group=guest \
> --enable-eventdn \
> --sysconfdir=/home/tor
checking for a BSD-compatible install... /opt/sfw/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/sfw/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
configure: You are running Solaris; Sometimes threading makes
cpu workers lock up here, so I will disable threads.
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... ranlib
checking for sed... sed
checking for sha1sum... /opt/sfw/bin/sha1sum
checking for openssl... /usr/local/ssl/bin/openssl
checking for win32... no
checking for MIPSpro compiler... no
checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep
checking for egrep... /usr/sfw/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for library containing socket... -lsocket
checking for library containing gethostbyname... -lnsl
checking for library containing dlopen... none required
checking for library containing inet_aton... -lresolv
checking for gettimeofday... yes
checking for ftime... yes
checking for socketpair... yes
checking for uname... yes
checking for inet_aton... yes
checking for strptime... yes
checking for getrlimit... yes
checking for strlcat... yes
checking for strlcpy... yes
checking for strtoull... yes
checking for getaddrinfo... yes
checking for localtime_r... yes
checking for gmtime_r... yes
checking for memmem... no
checking for strtok_r... yes
checking for writev... yes
checking for readv... yes
checking for flock... no
checking for prctl... no
checking for mallinfo... no
checking for malloc_good_size... no
checking for malloc_usable_size... no
checking for sys/types.h... (cached) yes
checking for u_int64_t... no
checking for u_int32_t... no
checking for u_int16_t... no
checking for u_int8_t... no
checking for libevent directory... /opt/csw
checking whether we need extra options to link libevent... (none)
checking for event_get_version... yes
checking for event_get_version_number... no
checking for event_get_method... yes
checking for event_set_log_callback... yes
checking for evdns_set_outgoing_bind_address... no
checking for event_base_loopexit... yes
checking for struct event.min_heap_idx... no
checking event2/event.h usability... no
checking event2/event.h presence... no
checking for event2/event.h... no
checking event2/dns.h usability... no
checking event2/dns.h presence... no
checking for event2/dns.h... no
checking for openssl directory... /usr/local/ssl
checking whether we need extra options to link openssl... (none)
checking for zlib directory... (system)
checking whether we need extra options to link zlib... (none)
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for unistd.h... (cached) yes
checking for string.h... (cached) yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking for sys/stat.h... (cached) yes
checking for sys/types.h... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/fcntl.h usability... yes
checking sys/fcntl.h presence... yes
checking for sys/fcntl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking for stdint.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for inttypes.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/limits.h usability... no
checking sys/limits.h presence... no
checking for sys/limits.h... no
checking for netinet/in.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking machine/limits.h usability... no
checking machine/limits.h presence... no
checking for machine/limits.h... no
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for sys/time.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for inttypes.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking sys/utime.h usability... yes
checking sys/utime.h presence... yes
checking for sys/utime.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking netinet/in6.h usability... no
checking netinet/in6.h presence... no
checking for netinet/in6.h... no
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/syslimits.h usability... no
checking sys/syslimits.h presence... no
checking for sys/syslimits.h... no
checking malloc/malloc.h usability... no
checking malloc/malloc.h presence... no
checking for malloc/malloc.h... no
checking linux/types.h usability... no
checking linux/types.h presence... no
checking for linux/types.h... no
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking malloc_np.h usability... no
checking malloc_np.h presence... no
checking for malloc_np.h... no
checking sys/prctl.h usability... no
checking sys/prctl.h presence... no
checking for sys/prctl.h... no
checking for declaration of malloc_good_size... no
checking for net/if.h... yes
checking for net/pfvar.h... no
checking for linux/netfilter_ipv4.h... no
configure: Transparent proxy support enabled, but missing headers.
checking for struct timeval.tv_sec... yes
checking for int8_t... yes
checking size of int8_t... 1
checking for int16_t... yes
checking size of int16_t... 2
checking for int32_t... yes
checking size of int32_t... 4
checking for int64_t... yes
checking size of int64_t... 8
checking for uint8_t... yes
checking size of uint8_t... 1
checking for uint16_t... yes
checking size of uint16_t... 2
checking for uint32_t... yes
checking size of uint32_t... 4
checking for uint64_t... yes
checking size of uint64_t... 8
checking for intptr_t... yes
checking size of intptr_t... 4
checking for uintptr_t... yes
checking size of uintptr_t... 4
checking for char... yes
checking size of char... 1
checking for short... yes
checking size of short... 2
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for long long... yes
checking size of long long... 8
checking for __int64... no
checking size of __int64... 0
checking for void *... yes
checking size of void *... 4
checking for time_t... yes
checking size of time_t... 4
checking for size_t... yes
checking size of size_t... 4
checking for uint... yes
checking for u_char... yes
checking for ssize_t... yes
checking for struct in6_addr... yes
checking for struct sockaddr_in6... yes
checking for sa_family_t... yes
checking for struct in6_addr.s6_addr32... no
checking for struct in6_addr.s6_addr16... no
checking for struct sockaddr_in.sin_len... no
checking for struct sockaddr_in6.sin6_len... no
checking for rlim_t... yes
checking whether time_t is signed... yes
checking for socklen_t... yes
checking size of socklen_t... 4
checking for cell_t... no
checking size of cell_t... 0
checking whether memset(0) sets pointers to NULL... yes
checking whether we can malloc(0) safely.... yes
checking whether we are using 2s-complement arithmetic... yes
checking whether to use dmalloc (debug memory allocation library)... no
checking for mlockall... yes
checking for getresuid... no
checking for getresgid... no
checking for gethostbyname_r... yes
checking how many arguments gethostbyname_r() wants... 5
checking whether the C compiler supports __func__... yes
checking whether the C compiler supports __FUNC__... no
checking whether the C compiler supports __FUNCTION__... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tor.spec
config.status: creating Doxyfile
config.status: creating contrib/tor.sh
config.status: creating contrib/torctl
config.status: creating contrib/torify
config.status: creating contrib/tor.logrotate
config.status: creating contrib/Makefile
config.status: creating contrib/osx/Makefile
config.status: creating contrib/osx/TorBundleDesc.plist
config.status: creating contrib/osx/TorBundleInfo.plist
config.status: creating contrib/osx/TorDesc.plist
config.status: creating contrib/osx/TorInfo.plist
config.status: creating contrib/osx/TorStartupDesc.plist
config.status: creating src/config/torrc.sample
config.status: creating doc/tor.1
config.status: creating src/Makefile
config.status: creating doc/Makefile
config.status: creating doc/design-paper/Makefile
config.status: creating doc/spec/Makefile
config.status: creating src/config/Makefile
config.status: creating src/common/Makefile
config.status: creating src/or/Makefile
config.status: creating src/test/Makefile
config.status: creating src/win32/Makefile
config.status: creating src/tools/Makefile
config.status: creating contrib/suse/Makefile
config.status: creating contrib/suse/tor.sh
config.status: creating orconfig.h
config.status: executing depfiles commands
usmine:/usr/local/lib/tor-0.2.2.6-alpha> gmake
gmake all-recursive
gmake[1]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha'
Making all in src
gmake[2]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha/src'
Making all in common
gmake[3]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT address.o -MD -MP -MF .deps/address.Tpo -c -o address.o address.c
mv -f .deps/address.Tpo .deps/address.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT log.o -MD -MP -MF .deps/log.Tpo -c -o log.o log.c
log.c:95: warning: 'log_mutex' defined but not used
mv -f .deps/log.Tpo .deps/log.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
mv -f .deps/util.Tpo .deps/util.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function `tor_set_max_memlock':
compat.c:2224: error: `RLIMIT_MEMLOCK' undeclared (first use in this function)
compat.c:2224: error: (Each undeclared identifier is reported only once
compat.c:2224: error: for each function it appears in.)
gmake[3]: *** [compat.o] Error 1
gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha'
gmake: *** [all] Error 2
usmine:/usr/local/lib/tor-0.2.2.6-alpha>
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: ottohttps://gitlab.torproject.org/tpo/core/tor/-/issues/1200Add port share option to host HTTPS Server and Tor on same port2020-06-27T14:09:42ZTracAdd port share option to host HTTPS Server and Tor on same portOpenVPN includes a "port share" option that allows OpenVPN to run on port 443 and to pass through HTTPS
connections to a Web server running on the same machine (see http://christophe.vandeplas.com/2008/06/01/portsharing-with-openvpn). Th...OpenVPN includes a "port share" option that allows OpenVPN to run on port 443 and to pass through HTTPS
connections to a Web server running on the same machine (see http://christophe.vandeplas.com/2008/06/01/portsharing-with-openvpn). Thus, both applications are able to use
port 443 at the same time.
Implementing such a feature for Tor may allow to make it harder to detect Tor bridges from the outside, as they could
behave to non-Tor clients such as a regular Web server (and even include legitimate Web content).
Furthermore, such a feature may make it easier for people running bridges to run these bridges on port 443, as it is
still possible to run a HTTPS server at the same IP.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: gstTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1201mapaddress broken2020-06-27T14:09:41ZTracmapaddress brokenSince an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Since an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1202tor slow loading network status2020-06-27T14:09:41ZTractor slow loading network statustor getting slow on loading network status
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tomlietor getting slow on loading network status
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tomlie