[tor-bugs] #24631 [Applications/Tor Browser]: Update Tor Browser toolchains for ESR 59

[Tor Bug Tracker & Wiki]

#24631: Update Tor Browser toolchains for ESR 59
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This is the tracking bug for the toolchain updates for the next ESR.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
--+
 Reporter:  maddoctor |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by maddoctor):

 I don't use a distribution.

 This is how I build libevent:

 tar -xf libevent-release-2.1.8-stable.tar.gz
 cd libevent-release-2.1.8-stable
 cmake -DEVENT__BUILD_SHARED_LIBRARIES=ON -DCMAKE_INSTALL_PREFIX=/usr
 make
 make test
 make install
 cd ..
 rm -rf libevent-release-2.1.8-stable
 strip -S build/usr/lib/*
 mv build/usr/lib/libevent* /usr/lib64/

 That symbol is in the library (see comment above) and in the headers
 (event2/dns_compat.h).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
--+
 Reporter:  maddoctor |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  evdns_shutdown =>
 * version:  Tor: 0.3.1.8 => Tor: 0.3.1.9


Comment:

 It looks like libevent isn't exporting that symbol.
 Which distribution are you using, and how did you install your libevent?

 The solution to this may be that Tor needs to check for that symbol at
 configure time, and avoid using it if it is not present.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
+
 Reporter:  maddoctor   |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.8
 Severity:  Normal  | Resolution:
 Keywords:  evdns_shutdown  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by maddoctor):

 This is with source tor-0.3.1.9:

 gcc  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all
 -Wstack-protector --param ssp-buffer-size=1 -fPIE -fasynchronous-unwind-
 tables -Wall -fno-strict-aliasing -Waddress -Warray-bounds -Wdate-time
 -Wdouble-promotion -Wduplicate-decl-specifier -Wduplicated-cond -Wextra
 -Wfloat-conversion -Wignored-attributes -Wimplicit-fallthrough -Winit-self
 -Wlogical-op -Wmissing-field-initializers -Wmissing-format-attribute
 -Wmissing-noreturn -Wnormalized=id -Wnull-dereference -Woverlength-strings
 -Woverride-init -Wshadow -Wshift-count-negative -Wshift-count-overflow
 -Wshift-negative-value -Wshift-overflow=2 -Wsizeof-array-argument
 -Wstrict-overflow=1 -Wsuggest-attribute=format -Wsuggest-
 attribute=noreturn -Wswitch-bool -Wsync-nand -Wtrampolines -Wunused-but-
 set-parameter -Wunused-but-set-variable -Wunused-const-variable=2
 -Wunused-local-typedefs -Wvariadic-macros -W -Wfloat-equal -Wundef
 -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings
 -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings
 -Wnested-externs -Wbad-function-cast -Wswitch-enum -Waggregate-return
 -Wpacked -Wunused -Wunused-parameter  -Wold-style-definition -Wmissing-
 declarations  -pie -z relro -z now -rdynamic -o src/or/tor
 src/or/tor_main.o src/or/libtor.a src/common/libor.a src/common/libor-
 ctime.a src/common/libor-crypto.a src/ext/keccak-tiny/libkeccak-tiny.a
 src/common/libcurve25519_donna.a src/ext/ed25519/ref10/libed25519_ref10.a
 src/ext/ed25519/donna/libed25519_donna.a src/common/libor-event.a
 src/trunnel/libor-trunnel.a src/trace/libor-trace.a -lz -lm -levent -lssl
 -lcrypto -L/usr/lib64 -llzma  -lcap -lpthread -ldl
 src/or/libtor.a(main.o): In function `tor_free_all':
 /building/tor/tor-0.3.1.9/src/or/main.c:3211: undefined reference to
 `evdns_shutdown'
 collect2: error: ld returned 1 exit status
 make[1]: *** [Makefile:4215: src/or/tor] Error 1
 make[1]: Leaving directory '/building/tor/tor-0.3.1.9'
 make: *** [Makefile:3106: all] Error 2

 You see, -levent *is* there.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19984 [Core Tor/Tor]: Use a better set of comparison/evaluation functions for deciding which connections to kill when OOS

[Tor Bug Tracker & Wiki]

#19984: Use a better set of comparison/evaluation functions for deciding which
connections to kill when OOS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  dos, sockets  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  SponsorV-can
--+

Comment (by Hello71):

 in other words, it's impossible to, using netblocks only, distinguish
 between "real" clients behind some mobile network's carrier-grade NAT and
 a bunch of regular clients on a VPS somewhere.

 hm... upon further consideration though, perhaps it would be possible to
 use a memory-hard proof of work algorithm here. even phones under $100
 have at least 2 GB of RAM, so completing an occasional 1 GB POW should
 only momentarily slow the device. should be easy on battery life too,
 unlike a CPU POW. I did a quick calculation and an attacker would need s =
 cfn, where s is the required server RAM, c is the challenge difficulty, f
 is the frequency, and n is the number of connections to be held, and if c
 = 1 GB * 3 sec, f = 1/10 min, n = 200, then s = 1 GB, or around $5/month
 per 200 connections, which seems sufficiently expensive to deter this
 particular attack. however, there are a number of downsides to this plan.
 not only does it require additional protocol design (time which could be
 spent doing something else, like IPv6 support), I hear the iOS Tor people
 are limited to 15 MB, so even if the device has 10 GB of RAM that won't
 help. I figure "you must reopen the Tor app every ten minutes to maintain
 your connection" is not a good solution.

 hm... perhaps we could use both: clients that require long-running
 connections for things like IRC must submit proofs of work (either CPU or
 memory), and iOS clients just have to live with occasionally re-
 establishing their connections if the relay is under DoS.

 regardless, in the short to medium term, we should probably implement the
 bandwidth method. this latest surge in fake clients has noticeably
 increased number of "users": https://metrics.torproject.org/userstats-
 relay-country.html?start=2017-12-01&end=2017-12-15&country=all&events=on.
 fortunately, performance has not yet been seriously affected, but it is
 plausible that they will get more servers online and the curve will
 continue going up.

 in terms of implementation, is it correct that right now, only OR
 connections count recent traffic?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24630 [Core Tor/Tor]: Stop initialising rust git submodules, travis does this automatically

[Tor Bug Tracker & Wiki]

#24630: Stop initialising rust git submodules, travis does this automatically
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_revision


Comment:

 Ok, I've run out of time for this, there are commits for this issue and
 #24629 in my branch  travis-osx-v2. Feel free to keep hacking on it!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Ok, I've run out of time for this, there are commits for this issue and
 #24630 in my branch  travis-osx-v2. Feel free to keep hacking on it!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by Hello71):

 I think we should do:

 - Linux:
   - gcc, rust online
   - gcc, rust offline
   - gcc, no rust
   - clang, no rust
 - macOS:
   - gcc, rust online
   - clang, no rust

 with a view to changing number five to offline, whenever that gets fixed.
 this will utilise all of the allowed parallel build slots (4/6 Linux, 2/6
 macOS) and ensure the best immediate feedback. for better immediate
 feedback, we could also enable cargo cache (https://docs.travis-
 ci.com/user/caching/#Rust-Cargo-cache).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
+
 Reporter:  maddoctor   |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.8
 Severity:  Normal  | Resolution:
 Keywords:  evdns_shutdown  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Please try:
 {{{
 make V=1
 }}}
 And provide the linker output for tor.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by teor):

 I think we could do rust / gcc and plain c / clang, and call it done.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by Hello71):

 we should try to minimize the number of macOS jobs that run, both to be a
 better netizen and pragmatically because they are limited to two at a
 time, so if you have a bunch they will not run in a good order.

 for example, I think it is probably unnecessary to test three ways of
 compiling rust with both gcc *and* clang.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
+
 Reporter:  maddoctor   |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.8
 Severity:  Normal  | Resolution:
 Keywords:  evdns_shutdown  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by maddoctor):

 Firefox, which is a huge project, compiled and linked against
 my installed libevent, BTW

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
+
 Reporter:  maddoctor   |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.8
 Severity:  Normal  | Resolution:
 Keywords:  evdns_shutdown  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by maddoctor):

 linux, kernel 4.12.4, glibc 2.26, gcc 7.1.0

 PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig \
 ./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc

 ...
 checking for libevent directory... (system)
 checking whether we need extra options to link libevent... (none)
 checking event2/event.h usability... yes
 checking event2/event.h presence... yes
 checking for event2/event.h... yes
 checking event2/dns.h usability... yes
 checking event2/dns.h presence... yes
 checking for event2/dns.h... yes
 checking event2/bufferevent_ssl.h usability... yes
 checking event2/bufferevent_ssl.h presence... yes
 checking for event2/bufferevent_ssl.h... yes
 checking for library containing event_new... -levent
 checking for library containing evdns_base_new... none required
 checking for evutil_secure_rng_set_urandom_device_file... yes
 checking for evutil_secure_rng_add_bytes... yes
 checking whether Libevent is new enough... yes
 ...

 readelf -a /usr/lib64/libevent.so | grep dns_shutdown
392: 0004605068 FUNCLOCAL  DEFAULT   11 evdns_shutdown

 I do not know what command is being used to link the binary.
 The Makefile is over 1 lines long and refers back to things
 like LIB and CCLD that I cannot track down.

   CCLD src/or/tor
 src/or/libtor.a(main.o): In function `tor_free_all':
 /building/tor/tor-0.3.1.8/src/or/main.c:3211: undefined reference to
 `evdns_shutdown'
 collect2: error: ld returned 1 exit status
 make[1]: *** [Makefile:4215: src/or/tor] Error 1
 make[1]: Leaving directory '/building/tor/tor-0.3.1.8'
 make: *** [Makefile:3106: all] Error 2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24630 [Core Tor/Tor]: Stop initialising rust git submodules, travis does this automatically

[Tor Bug Tracker & Wiki]

#24630: Stop initialising rust git submodules, travis does this automatically
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 isis told me to do this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 This rust failure shows that the fast_finish comment is wrong:
 https://travis-ci.org/teor2345/tor/jobs/316721014

 The other builds continued despite the failure.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  assigned => needs_information
 * type:  defect => enhancement


Comment:

 Replying to [comment:2 teor]:
 > I wish auto-cancellation was available as a default in the travis config
 file.

 I just checked my travis settings, and auto-cancellation is on by default.
 I don't think we need to do anything here.

 > Also, I am not sure we want to make osx "allow_failures" just so we can
 set "fast_finish" on it.

 The comments in travis.yml don't seem to match the documentation.

 > Are there any other options?

 Apparently not.

 See my branch travis-osx, building now at https://travis-
 ci.org/teor2345/tor

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by teor):

 I wish auto-cancellation was available as a default in the travis config
 file.

 Also, I am not sure we want to make osx "allow_failures" just so we can
 set "fast_finish" on it.

 Are there any other options?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Ok, a whole bunch of fixups are now at mikeperry/bug13837. I replied to
 all of the comments on oniongit with the commit hash that addresses them,
 or with a comment if I didn't think that the change was a good idea (or
 not a good idea right as part of this ticket).

 I am kind of itching to rebase this on top of master, and #23101 on top of
 it, to minimize conflicts between the two sets of fixups. Let me know if
 now is a good time to do that, or if we should wait for more fixups.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  not-just-linux, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by Hello71):

 this can be configured by:

 - uncommenting the "osx" line
 - turning on the Auto Cancellation feature https://docs.travis-ci.com/user
 /customizing-the-build/#Building-only-the-latest-commit
 - setting the osx job in allow_failures https://docs.travis-ci.com/user
 /customizing-the-build/#Rows-that-are-Allowed-to-Fail AND setting
 fast_finish: true https://docs.travis-ci.com/user/customizing-the-build
 /#Fast-Finishing

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  not-just-linux, tor-ci
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 We want to activate osx builds on Travis CI.
 But they can be very slow, so we need to customise the settings.

 If possible, we want osx builds to behave as follows:
 * if there is a pending build, and more commits are pushed to the branch,
 cancel the pending build and re-queue the latest commits
 * let travis show builds as "complete" if osx takes a long time, but still
 show osx failures eventually

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24566 [Applications/Tor Browser]: When I open TorBrowser 7.0.11 the popup goes completely white

[Tor Bug Tracker & Wiki]

#24566: When I open TorBrowser 7.0.11 the popup goes completely white
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:12 gk]:
 > Replying to [comment:11 Dbryrtfbcbhgf]:
 > > Replying to [comment:10 gk]:
 > > > Replying to [comment:9 Dbryrtfbcbhgf]:
 > > > > Here is the video
 > > > >
 ​https://filenurse.com/download/048ee301b1d2c7c3c164cd8fd5f2df5a.html
 > > > > I reported this bug to mozilla.
 > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1424945
 > > >
 > > > Thanks. Does this affect a clean Firefox 57.0.2 as well? If so,
 might be worth mentioning on the Mozilla ticket. That said, it seems to me
 7.0.10 worked for you a couple of days/weeks ago but suddenly now you are
 seeing this problem even with that version? Or am I misunderstanding you?
 > > The bug does Not effect 57.0.2 (64-bit). The issue only started after
 I updated my Mac to 10.13.2 (17C88) up from 10.13.1
 >
 > Okay, so it affects Firefox 52.5.2esr but not Firefox 57.0.2. Could you
 figure out which Firefox version fixed this bug? Maybe we can backport the
 patch for ESR 52? All Firefox versions are at:
 https://ftp.mozilla.org/pub/firefox/releases/
 The earliest version that the bug does not occur is 57.0b3 (64-bit).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23975 [Core Tor/Tor]: Make node_get_*_orport() check addresses in the right order

[Tor Bug Tracker & Wiki]

#23975: Make node_get_*_orport() check addresses in the right order
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  1
Parent ID:  #20916| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This branch rapidly got out of control.
 I want to split it into:
 * a branch that avoids using microdesc IPv6 addresses when the consensus
 method is high enough
 * a branch that gets rid of IPv6 DirPorts
 * a branch that deals with the bridge stuff
 * a branch that does any other stuff

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24613 [Core Tor/Tor]: Avoid monotime_coarse_absolute_msec in channelpadding code

[Tor Bug Tracker & Wiki]

#24613: Avoid monotime_coarse_absolute_msec in channelpadding code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by mikeperry):

 * status:  needs_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24628 [Metrics/Consensus Health]: bwauth= bug in consensus health

[Tor Bug Tracker & Wiki]

#24628: bwauth= bug in consensus health
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 We seem to be a small maybe-consistent value off of the correct value, and
 it makes the bwauth match not work.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22781 [Core Tor/Tor]: hs: Unify link specifier API/ABI

[Tor Bug Tracker & Wiki]

#22781: hs: Unify link specifier API/ABI
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-cell, tor-relay, ipv6  |  Actual Points:
Parent ID:  #24403 | Points:  1
 Reviewer:  teor   |Sponsor:  SponsorV-can
---+---
Changes (by teor):

 * status:  needs_information => needs_revision
 * reviewer:   => teor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22781 [Core Tor/Tor]: hs: Unify link specifier API/ABI

[Tor Bug Tracker & Wiki]

#22781: hs: Unify link specifier API/ABI
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-cell, tor-relay, ipv6  |  Actual Points:
Parent ID:  #24403 | Points:  1
 Reviewer: |Sponsor:  SponsorV-can
---+---

Comment (by teor):

 Replying to [comment:6 dgoulet]:
 > I want to make sure we nail down an interface that we like/want before
 going further.
 >
 > 1. EXTEND cell: The `extend_cell_t` object contains basically all the
 possible ways to extend. Through `extend_cell_format()`, we take what's in
 it and create `link_specifier_t` (trunnel).
 >
 >  The relationship is:
 >  - `extend_cell_format(): extend_cell_t -> link_specifier_t`
 >  - `extend_cell_parse(): link_specifier_t -> extend_cell_t` (Note that
 this is for EXTEND2).

 What about CREATE[2] cells?
 extend_info_t is used for them, too.

 > 2. HSv3: We have `hs_desc_link_specifier_t` which represent only one
 possible way to extend (IPv4, IPv6, Legacy ID or ed25519).
 >
 >  Relationship is:
 >  - `encode_link_specifiers(): hs_desc_link_specifier_t ->
 link_specifier_t`
 >  - `decode_link_specifiers(): link_specifier_t ->
 hs_desc_link_specifier_t`
 >
 > That is what we have right now using link specifiers interface (trunnel)
 and some intermediate object. I think a good move forward would be so
 abstract the high level link specifier object to something generic that
 every subsystem could use. In other words, replace
 `hs_desc_link_specifier_t` and `extend_cell_t` to be the same object.
 >
 > They differ right now because the HS one contains *one* specific link
 specifier and the extend cell object contains *all* possible link
 specifiers. In the spirit of reducing memory allocation, I think it is
 reasonable to have one generic object containing all possible link
 specifiers. Something like:
 >
 > {{{
 > tor_addr_port_t addrport_v4;
 > tor_addr_port_t addrport_v6;
 > uint8_t legacy_id[DIGEST_LEN];
 > ed25519_public_key_t ed_id;
 > }}}
 >
 > We mandate that v4 and legacy_id be present which means we could either
 check for "mem zero" on IPv6 and ed_id to decide to include them or we add
 a flag saying "v6 defined" to maybe be more efficient. Parsing cells is
 certainly part of our fast path in my opinion so any optimization is a
 win.

 I'm all for avoiding premature optimisations.
 Let's define accessor functions that do the zero-checks and then profile
 CPU and RAM.
 Then we can add flags, and profile again.

 > Downside here is if we ever want to include more than one type of
 specifiers in a cell/descriptor that is for example 2 different IPv4?

 The Prop224 spec says that we should pass on all link specifiers, even
 unknown link specifier types.
 So I think we need a final member `extra_spec_list` that's a smartlist
 pointer.
 On the fast path, it doesn't get used, because it's NULL.

 This could handle extra addresses, too, if we ever did that.

 > My original branch (`ticket22781_032_01`) has already some work started
 there with `lspec_t` being a generic higher level object that encodes to a
 `link_specifier_t` and vice versa. However, it would need to contain all
 the possible links.
 >
 > Am I on a path that we like?

 I like this idea.

 I think this makes it easier to push all the details of choosing addresses
 deep down the stack. Then we can choose the remote address just before we
 go to connect to it. It makes a whole lot of code much easier, and much
 more generic. And we can finally implement tickets like #6772, and try
 another ORPort if the first one fails.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24613 [Core Tor/Tor]: Avoid monotime_coarse_absolute_msec in channelpadding code

[Tor Bug Tracker & Wiki]

#24613: Avoid monotime_coarse_absolute_msec in channelpadding code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by mikeperry):

 The netflow bits look good to me. The various platform-specific monotime
 diffs I am less confident about, but the unit tests look mostly convincing
 there. One potential improvemnt to the tests: add 1337 three times, so
 that we can also be sure that we properly overflow the internal sub-second
 values into a whole second on platforms that differentiate seconds and
 sub-seconds internally?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24425 [Core Tor/Tor]: Set the hsdir_spread_store parameter to 4 (or maybe even 5)

[Tor Bug Tracker & Wiki]

#24425: Set the hsdir_spread_store parameter to 4 (or maybe even 5)
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27, 031-backport-maybe  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by dgoulet):

 * component:  Core Tor/DirAuth => Core Tor/Tor


Comment:

 Ok _wrong_ component... This needs to go in 032. I'm emailing the dirauth
 list to ask about setting this consensus param.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24561 [Applications/Tor Browser]: Add authenticode/marsigning check scripts to tor-browser-build

[Tor Bug Tracker & Wiki]

#24561: Add authenticode/marsigning check scripts to tor-browser-build
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201712R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Thanks, applied to `master` as commit
 c0915fc6a4b51418ace4d5a59f77bb63b57da3d2.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Ok, let's go with this!
 Can you group the icons by concept (rows?) and IP version (columns?) in
 the final set?
 That will help people see the visual similarities.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
+
 Reporter:  maddoctor   |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.8
 Severity:  Normal  | Resolution:
 Keywords:  evdns_shutdown  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_information
 * severity:  Blocker => Normal
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 We need some more information to help diagnose this:

 What OS are you on? What distribution?
 What configure command-line are you running?
 What does configure say about libevent?
 Is the missing function actually defined in your libevent?
 What command-line is being used to link the binary that fails?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
+
 Reporter:  maddoctor   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.8
 Severity:  Blocker | Resolution:
 Keywords:  evdns_shutdown  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by maddoctor):

 Same error with 0.3.1.9 sources.
 libevent is installed correctly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by teor):

 After the bridges and PT are changed, this is what happens:
 {{{
 Dec 14 19:48:33.000 [info] register_client_proxy(): Successfully
 registered transport obfs2
 918 Dec 14 19:48:33.000 [info] register_client_proxy(): Successfully
 registered transport obfs3
 919 Dec 14 19:48:33.000 [info] register_client_proxy(): Successfully
 registered transport obfs4
 920 Dec 14 19:48:33.000 [info] register_client_proxy(): Successfully
 registered transport scramblesuit
 921 Dec 14 19:48:34.000 [notice] Our directory information is no
 longer up-to-date enough to build circuits: We're missing descriptors for
 2/2 of our primary entry guards (total microdescriptors: 6474/6486).
 922 Dec 14 19:48:34.000 [info] launch_descriptor_downloads():
 Launching 1 request for 12 microdescs, 12 at a time
 923 Dec 14 19:48:34.000 [info] select_entry_guard_for_circuit():
 Selected primary guard [bridge]
 ($00DC6C4FA49A65BD1472993CF6730D54F11E0DBB) at 154.35.22.12:80 for
 circuit.
 924 Dec 14 19:48:34.000 [notice] Ignoring directory request, since no
 bridge nodes are available yet.
 }}}

 Notice how we're missing bridge descriptors, but we try to fetch
 microdescriptors?

 So all that code asn wrote to fetch microdescs harder isn't going to help
 here. Instead, we need to try bridges harder when we are missing bridge
 descriptors. Maybe we should start by resetting their download statuses?

 Also, we should think about whether this code works when we are not using
 microdescriptors. DOes it specifically trigger a microdesc fetch? Or is it
 just triggering descriptor fetches?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by catalyst):

 Replying to [comment:22 gk]:
 > Replying to [comment:21 nickm]:
 > > I've tried the first approach you suggested, and didn't get
 signed/unsigned warnings, so lt's try it out.
 > >
 > > gk, does my `stack_again_032` branch fix the warning for you?
 >
 > Looks good now. Just the warning in `test` is still there (see comment:4
 and the respective attachment).
 That looks like another instance of `tor_malloc_zero()` (called from
 `new_fake_channel()`) always returning non-`NULL` (assuming the line
 numbers on maint-0.3.2 are still correct), so this conditional in
 `test_channel_flushmux()` is always true:
 {{{
 762   if (ch)
 763 circuitmux_free(ch->cmux);
 }}}
 Even better, there's also
 {{{
 718   ch = new_fake_channel();
 719   tt_assert(ch);
 }}}
 so that's another reason why it can't be `NULL`, along with other
 unconditional dereferences.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24627 [Webpages/Website]: DisableNetwork is set - Rend stream is 120 seconds late

[Tor Bug Tracker & Wiki]

#24627: DisableNetwork is set - Rend stream is 120 seconds late
--+
 Reporter:  stevensondhiem|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I'm using Windows 10 with a VPN.
 I was able to access a specific site fine for weeks, I don't remember
 doing anything special to let me get there, but yesterday the connection
 timed out. I've found similar issues on this site but no fixes worked.

 I've tried:
 -clean installing my entire computer
 -factory resetting my router
 -using BridgeDB to add bridges
 -using new Identity, new circuit, several times

 Here's my logs:
 12/14/2017 20:00:12 PM.100 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 12/14/2017 20:00:14 PM.900 [NOTICE] Closing no-longer-configured Socks
 listener on 127.0.0.1:9150
 12/14/2017 20:00:14 PM.900 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 12/14/2017 20:00:14 PM.900 [NOTICE] Closing old Socks listener on
 127.0.0.1:9150
 12/14/2017 20:00:15 PM.300 [NOTICE] Delaying directory fetches:
 DisableNetwork is set.
 12/14/2017 20:00:24 PM.700 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 12/14/2017 20:00:24 PM.700 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 12/14/2017 20:00:24 PM.700 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 12/14/2017 20:00:24 PM.700 [NOTICE] Opening Socks listener on
 127.0.0.1:9150
 12/14/2017 20:00:26 PM.700 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 12/14/2017 20:00:26 PM.700 [NOTICE] Bootstrapped 100%: Done
 12/14/2017 20:00:29 PM.800 [NOTICE] New control connection opened from
 127.0.0.1.
 12/14/2017 20:00:30 PM.100 [NOTICE] New control connection opened from
 127.0.0.1.
 12/14/2017 20:03:11 PM.200 [NOTICE] Rend stream is 120 seconds late.
 Giving up on address '[scrubbed].onion'.

 help and thank you!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22781 [Core Tor/Tor]: hs: Unify link specifier API/ABI

[Tor Bug Tracker & Wiki]

#22781: hs: Unify link specifier API/ABI
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-cell, tor-relay, ipv6  |  Actual Points:
Parent ID:  #24403 | Points:  1
 Reviewer: |Sponsor:  SponsorV-can
---+---
Changes (by dgoulet):

 * status:  needs_revision => needs_information


Comment:

 I want to make sure we nail down an interface that we like/want before
 going further.

 1. EXTEND cell: The `extend_cell_t` object contains basically all the
 possible ways to extend. Through `extend_cell_format()`, we take what's in
 it and create `link_specifier_t` (trunnel).

  The relationship is:
  - `extend_cell_format(): extend_cell_t -> link_specifier_t`
  - `extend_cell_parse(): link_specifier_t -> extend_cell_t` (Note that
 this is for EXTEND2).

 2. HSv3: We have `hs_desc_link_specifier_t` which represent only one
 possible way to extend (IPv4, IPv6, Legacy ID or ed25519).

  Relationship is:
  - `encode_link_specifiers(): hs_desc_link_specifier_t ->
 link_specifier_t`
  - `decode_link_specifiers(): link_specifier_t ->
 hs_desc_link_specifier_t`

 That is what we have right now using link specifiers interface (trunnel)
 and some intermediate object. I think a good move forward would be so
 abstract the high level link specifier object to something generic that
 every subsystem could use. In other words, replace
 `hs_desc_link_specifier_t` and `extend_cell_t` to be the same object.

 They differ right now because the HS one contains *one* specific link
 specifier and the extend cell object contains *all* possible link
 specifiers. In the spirit of reducing memory allocation, I think it is
 reasonable to have one generic object containing all possible link
 specifiers. Something like:

 {{{
 tor_addr_port_t addrport_v4;
 tor_addr_port_t addrport_v6;
 uint8_t legacy_id[DIGEST_LEN];
 ed25519_public_key_t ed_id;
 }}}

 We mandate that v4 and legacy_id be present which means we could either
 check for "mem zero" on IPv6 and ed_id to decide to include them or we add
 a flag saying "v6 defined" to maybe be more efficient. Parsing cells is
 certainly part of our fast path in my opinion so any optimization is a
 win. Downside here is if we ever want to include more than one type of
 specifiers in a cell/descriptor that is for example 2 different IPv4?

 My original branch (`ticket22781_032_01`) has already some work started
 there with `lspec_t` being a generic higher level object that encodes to a
 `link_specifier_t` and vice versa. However, it would need to contain all
 the possible links.

 Am I on a path that we like?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24561 [Applications/Tor Browser]: Add authenticode/marsigning check scripts to tor-browser-build

[Tor Bug Tracker & Wiki]

#24561: Add authenticode/marsigning check scripts to tor-browser-build
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201712R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 This patch looks good to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * priority:  Medium => High
 * status:  needs_information => new


Comment:

 Ok, I just noticed 4 of those today in a span of ~3 hours. IPs there are
 public relays (and some we know personally so I doubt this is malicious):

 {{{
 Dec 14 14:49:57.994 [warn] Attempt by 137.205.124.35:30658 to open a
 stream on first hop of circuit. Closing.
 Dec 14 15:44:01.534 [warn] Attempt by 109.105.109.162:36601 to open a
 stream on first hop of circuit. Closing.
 Dec 14 17:08:05.864 [warn] Attempt by 217.182.196.67:64478 to open a
 stream on first hop of circuit. Closing.
 Dec 14 17:11:09.928 [warn] Attempt by 85.25.43.31:443 to open a stream on
 first hop of circuit. Closing.
 }}}

 Something is clearly not right and I fear we might have a more important
 bug than we originally thought especially if this is linked to relay
 authentication. Those 4 relays above are on 0.3.1.x series.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by antonela):

 * Attachment "24399-review2.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by antonela):

 Replying to [comment:11 teor]:
 > These look good, but Fallback Directory needs a distinguishing symbol.
 > I also think that V2Dir does not, because it is the base concept.

 Gotcha!
 
https://trac.torproject.org/projects/tor/attachment/ticket/24399/24399-review2.png

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by antonela):

 * Attachment "24399-review2.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by gk):

 * Attachment "04f4f30af76cdedff990601a2e2f6387077290a3_24367.log" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by gk):

 The particular error seems to be gone but now I am stuck at
 {{{
 Dec 14 18:04:18.000 [notice] Opening Socks listener on 127.0.0.1:9150
 Dec 14 18:04:20.000 [notice] Our directory information is no longer
 up-to-date enough to build circuits: We're missing descriptors for
 2/2 of our primary entry guards (total microdescriptors: 6502/6502).
 }}}
 Attached is the debug log.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_revision


Comment:

 These look good, but Fallback Directory needs a distinguishing symbol.
 I also think that V2Dir does not, because it is the base concept.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by antonela):

 Thanks for the review irl and teor!

 I re-worked IPv4, iPv6, and Directories

 The reviewed icons are here

 
https://trac.torproject.org/projects/tor/attachment/ticket/24399/24399-review.png

 Some notes:
 - Running + IPv4/6 is a good idea.
 - Unreachable states now have a specific icon. We can use a warning color
 too.
 - I'm including IPv4/6 alone glyphs just in case.
 - FallbackDir, v2Dir, and HSDir now are part of the same concept :)

 If everything goes ok, I'll update the set officially :)
 Let me know what do you think!

 Thanks!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by antonela):

 * Attachment "24399-review.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24626 [Metrics]: Release ExoneraTor and Metrics-Web

[Tor Bug Tracker & Wiki]

#24626: Release ExoneraTor and Metrics-Web
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 There should be releases of ExoneraTor and Metrics-Web, b/c releases
 contain all necessary libraries and enable a better way of reproducing the
 productive environment as well as a faster start for a development
 environment.

 The accompanying documentation could state that the main purpose of these
 releases is the above.  And, the public release cycle could be limited to
 only put out releases that change dependencies of the product.

 Thoughts?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24175 [Metrics/Website]: Use an embedded Jetty in metrics-web and use metrics-base as build environment.

[Tor Bug Tracker & Wiki]

#24175: Use an embedded Jetty in metrics-web and use metrics-base as build
environment.
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 See [https://trac.torproject.org/projects/tor/ticket/23830#comment:8
 ticket 23830 comment 8] for a complete list of debian stretch packages.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23830 [Metrics/Website]: Update README to get a development environment for metrics-web going

[Tor Bug Tracker & Wiki]

#23830: Update README to get a development environment for metrics-web going
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 The list of packages won't be part of the future 'readme', b/c releases
 contain all necessary libraries and enable a better way of reproducing the
 productive environment as well as a faster start for a development
 environment.  The debian packages also contain way more libraries than
 necessary.

 All referenced jar (except metrics-lib) are available on debian stretch
 and their packages can be identified with the following query:
 
`https://packages.debian.org/search?suite=stretch&searchon=contents&keywords=xyz.jar`

 Here the list of debian packages for jetty based metrics-web:
 {{{
 libcommons-codec-java
 libcommons-lang3-java
 libcommons-lang-java
 libcommons-compress-java
 liblogback-java
 libslf4j-java
 libgoogle-gson-java
 r-cran-rserve or r-cran-rjava both supply REngine.jar and Rserve.jar
 libservlet3.1-java
 libxz-java
 libjetty9-java
 libjetty9-extra-java
 libasm-java
 libtaglibs-standard-spec-java
 libtomcat8-embed-java
 libecj-java
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24451 [Core Tor/Tor]: Put IPv6 link specifiers in client EXTEND cells

[Tor Bug Tracker & Wiki]

#24451: Put IPv6 link specifiers in client EXTEND cells
-+
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6 tor-client  |  Actual Points:
Parent ID:  #24403   | Points:  3
 Reviewer:   |Sponsor:  SponsorV-can
-+
Changes (by teor):

 * parent:  #23493 => #24403


Comment:

 Looks like we'll do this after the relay stuff

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24300 [Core Tor/Tor]: Failed to find node for hop #1 of our path. Discarding this circuit

[Tor Bug Tracker & Wiki]

#24300: Failed to find node for hop #1 of our path. Discarding this circuit
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-client bootstrap s8-errors  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor8-can
+--

Comment (by dgoulet):

 I just want to point out that this thing is still really annoying... I get
 that every week where my tor client can't do anything because I have a
 pinned `EntryNodes` but seems no descriptor for it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24625 [Metrics/Consensus Health]: Detailed and Summary pages of consensus health showed shared random in black/red

[Tor Bug Tracker & Wiki]

#24625: Detailed and Summary pages of consensus health showed shared random in
black/red
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 They have the same timestamp

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24624 [Applications/Tor Launcher]: tbb-logo.svg may cause network access

[Tor Bug Tracker & Wiki]

#24624: tbb-logo.svg may cause network access
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam201712R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by gk):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Fixed with commit c22a773ffaeb0398d8be0119f6e89f3c8161e4aa on `master`,
 thanks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24623 [Applications/Tor Launcher]: revise "country that censors Tor" text

[Tor Bug Tracker & Wiki]

#24623: revise "country that censors Tor" text
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam201712R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by gk):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Fixed with commit 12baf2b089479b3e043dbfad8ac246a5226feeae on `master`,
 thanks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21847 [Applications/Tor Browser]: Update copy for security slider to be consistent with the mobile experience

[Tor Bug Tracker & Wiki]

#21847: Update copy for security slider to be consistent with the mobile 
experience
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201712R, GeorgKoppen201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 The changes look fine to me, except we should replace the word "tap" with
 "click" for desktop. I think it is only the
 `torbutton.prefs.sec_tap_to_play_media` entity which needs to be updated.

 We should make sure that any minor text changes flow back to mobile (other
 than "tap" -> "click").

 Also, I wanted to compare to the Orfox interface but I could not figure
 out how to open the security slider on Android. Either it is not there or
 I cannot find it (but I am pretty sure I have seen it in the past). I
 tried with the version from Google Play (1.4rc3?) as well as this release
 candidate:
 
https://github.com/guardianproject/Orfox/releases/tag/Fennec-52.2.0esr%2FTorBrowser-7.0-1%2FOrfox-1.4.1-RC-1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24554 [Core Tor/Tor]: sched: Have per-scheduler type data in a channel_t

[Tor Bug Tracker & Wiki]

#24554: sched: Have per-scheduler type data in a channel_t
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Quick note. Moving `sched_heap_idx` out of `channel_t` and into
 `sched_info_t` is a bit more difficult because we use this `offsetof()`
 strategy with priority list so `sched_heap_idx` needs to offset from the
 `channel_t` object which is what is stored in the list. One possible
 solution would be to keep a pointer to the channel inside the
 `sched_info_t` and store those objects instead.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24554 [Core Tor/Tor]: sched: Have per-scheduler type data in a channel_t

[Tor Bug Tracker & Wiki]

#24554: sched: Have per-scheduler type data in a channel_t
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * reviewer:  pastly =>


Comment:

 (Removing pastly since he did a first review and might not want to do a
 second ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24554 [Core Tor/Tor]: sched: Have per-scheduler type data in a channel_t

[Tor Bug Tracker & Wiki]

#24554: sched: Have per-scheduler type data in a channel_t
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:  pastly|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 See branch: `ticket24554_033_02`.
 Oniongit MR: https://oniongit.eu/dgoulet/tor/merge_requests/13

 One thing to notice is that the top commit is actually the commit for
 #23579. It ain't very complicated, removes code duplication and lays the
 ground work for future tickets like #23744 and the work to move the
 scheduler state from the `channel_t` object into `sched_info_t` *only* for
 Vanilla because KIST doesn't need it.

 This is a slow and complicated work towards getting the scheduler
 subsystem much simpler, robust and easier to test. All this is part of
 #23993 parent ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24624 [Applications/Tor Launcher]: tbb-logo.svg may cause network access

[Tor Bug Tracker & Wiki]

#24624: tbb-logo.svg may cause network access
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201712 => TorBrowserTeam201712R
 * status:  new => needs_review


Comment:

 Here is a patch for review:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug24624-01&id=846bf09a22bcbc87687c528e618e83e8b8d034f3

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 (These branches are a little ugly; I should revise and comment more before
 review)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 So, I have a few theories now based on this log information: one was
 something I had suspected before, and one was something I hadn't realized.

 All of the fixes are in a branch `24367_some_more_030` in my public
 repository.  But instead of testing that one, I recommend that you test
 `24367_example_merge_032`, which also has the log improvements I made
 before, as well as being merged to 0.3.2 in order to make sure Teor's
 fixes are in.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by karsten):

 * cc: irl (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24624 [Applications/Tor Launcher]: tbb-logo.svg may cause network access

[Tor Bug Tracker & Wiki]

#24624: tbb-logo.svg may cause network access
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
   |  TorBrowserTeam201712
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor4   |
---+---
 While working on other areas of Tor Launcher, Kathy and I noticed what
 looked like an attempt by Tor Browser to access www.w3.org. It seems to be
 caused by this line within tbb-logo.svg, which we should remove (it is not
 needed and most of the SVGs that are part of Firefox omit it):
  http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24623 [Applications/Tor Launcher]: revise "country that censors Tor" text

[Tor Bug Tracker & Wiki]

#24623: revise "country that censors Tor" text
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * sponsor:   => Sponsor4


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 >  But also, I don't see us launching requests for any of the new primary
 guards! Something's going wrong there.

 Ah, we are sort-of-trying.  But the first time we try, at 11:46:32, we
 delay dir fetches because "pt proxies still configuring", and 2 seconds
 later, at 11:46:34, we delay dir fecthes because DisableNetwork is set.
 So there's no real chance to fetch better descriptors.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Updated all the patches to include the associated Mozilla bug numbers

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0005-Bug-23970-Printing-to-a-file-is-broken-with-Linux-
 co.patch" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0004-Bug-23970-Printing-to-a-file-is-broken-with-Linux-
 co.patch" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0003-Bug-23970-Printing-to-a-file-is-broken-with-Linux-
 co.patch" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0002-Bug-23970-Printing-to-a-file-is-broken-with-Linux-
 co.patch" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Bug-23970-Printing-to-a-file-is-broken-with-Linux-
 co.patch" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Bug-23970-Printing-to-a-file-is-broken-with-Linux-
 co.patch" removed.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 >  I think this is an artifact of looking at conn->addr instead of
 conn->real_addr.

 Wait. In this case, addr and real_addr will be the same.  The problem is
 that there is no real_port, maybe?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24623 [Applications/Tor Launcher]: revise "country that censors Tor" text

[Tor Bug Tracker & Wiki]

#24623: revise "country that censors Tor" text
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * keywords:   => TorBrowserTeam201712R
 * status:  new => needs_review


Comment:

 Here is a patch for review:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug24623-01&id=12baf2b089479b3e043dbfad8ac246a5226feeae
 It would be good to merge this soon so that our translators have a chance
 to update their translations of the text.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * status:  needs_revision => needs_review


Comment:

 All done! I didn't know
 aboutget_ext_or_auth_cookie_file_name()andget_controller_cookie_file_name(),
 thank you! :-)

 Check my github [https://github.com/ffmancera/tor/tree/github/bug23271
 ​branch bug23271.]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 > 1. Why did we pick LeifEricson for our connection the second time, after
 we had chosen 3 other primary guards?

 So, what should have happened here is that we should have tried to fetch
 our primary guards' descriptors before building circuits, and not fallen
 back to this entry far down later in the guard set.  The logic that's
 supposed to stop that is in
 guard_selection_get_err_str_if_dir_info_missing().  But also, I don't see
 us launching requests for any of the new primary guards! Something's going
 wrong there.

 > 2.  So we're looking up the wrong transport entirely.

 I think this is an artifact of looking at `conn->addr` instead of
 `conn->real_addr`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24623 [Applications/Tor Launcher]: revise "country that censors Tor" text

[Tor Bug Tracker & Wiki]

#24623: revise "country that censors Tor" text
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: isabela (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23016 [Applications/Tor Browser]: "Print to File" does not create the expected file in non-English locales

[Tor Bug Tracker & Wiki]

#23016: "Print to File" does not create the expected file in non-English locales
-+-
 Reporter:  intrigeri|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s, TorBrowserTeam201712R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 The changes in XPCOM do not need to be uplifted (and *technically* is not
 required in Tor Browser) since those set_locale calls occur before the
 final call added by Arthur which checks the use_english_locale pref.

 In fact (if I understood comments made by mozilla devs in nsAppRunner.cpp)
 the issue that check is meant to fix (per OS date formatting) goes away as
 JavaScript date formatting is no longer supported (
 https://bugzilla.mozilla.org/show_bug.cgi?id=818634 ).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24623 [Applications/Tor Launcher]: revise "country that censors Tor" text

[Tor Bug Tracker & Wiki]

#24623: revise "country that censors Tor" text
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 The alpha Tor Launcher UI includes the following text on the first setup
 screen:
  Click “Configure” to adjust network settings if you are in a country that
 censors Tor (such as China, Iran, Syria) or if you are connecting from a
 private network that requires a proxy.

 We should change this text based on data from OONI, which as of early
 December 2017 indicates that the primary countries where vanilla Tor is
 blocked are Egypt, China, and Turkey.

 Related ticket: #24527.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 Okay!  Let's look through these logs to see what happens to our favorite
 bridge, A09D536DD1752D542E1FBB3C9CE4449D51298239, at 82.212.101.3.

 {{{
 Dec 14 11:46:18.000 [info] get_transport_by_bridge_addrport(): Looked up
 transport for 83.212.101.3:80: found obfs3.
 ...
 Dec 14 11:46:19.000 [info] make_guard_confirmed(): Marking [bridge]
 ($A09D536DD1752D542E1FBB3C9CE4449D51298239) at 83.212.101.3:80 as a
 confirmed guard (index 0)
 Dec 14 11:46:19.000 [info] entry_guards_update_primary(): Primary entry
 guards have changed. New primary guard list is:
 Dec 14 11:46:19.000 [info] entry_guards_update_primary():   1/3: [bridge]
 ($A09D536DD1752D542E1FBB3C9CE4449D51298239) at 83.212.101.3:80 (confirmed)
 Dec 14 11:46:19.000 [info] entry_guards_update_primary():   2/3: [bridge]
 ($4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A) at 109.105.109.163:47779
 Dec 14 11:46:19.000 [info] entry_guards_update_primary():   3/3: [bridge]
 ($1E05F577A0EC0213F971D81BF4D86A9E4E8229ED) at 109.105.109.163:38980
 ...
 Dec 14 11:46:19.000 [notice] new bridge descriptor 'LeifEricson' (fresh):
 $A09D536DD1752D542E1FBB3C9CE4449D51298239~LeifEricson at 83.212.101.3
 ... (time passes; tor bootstraps; we change the options) ...
 Dec 14 11:46:31.000 [info] options_act(): Changed to using entry guards or
 bridges, or changed preferred or excluded node lists. Abandoning previous
 circuits.
 Dec 14 11:46:31.000 [info] sampled_guards_update_from_consensus():
 Updating sampled guard status based on received consensus.
 ...
 Dec 14 11:46:31.000 [info] sampled_guards_update_from_consensus(): Sampled
 guard [bridge] ($A09D536DD1752D542E1FBB3C9CE4449D51298239) at
 83.212.101.3:80 is now unlisted.
 ...
 Dec 14 11:46:31.000 [info] entry_guards_update_primary(): Primary entry
 guards have changed. New primary guard list is:
 Dec 14 11:46:31.000 [info] entry_guards_update_primary():   1/3: [bridge]
 ($91A6354697E6B02A386312F68D82CF86824D3606) at 85.31.186.26:443
 Dec 14 11:46:31.000 [info] entry_guards_update_primary():   2/3: [bridge]
 ($C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716) at 154.35.22.9:12166
 Dec 14 11:46:31.000 [info] entry_guards_update_primary():   3/3: [bridge]
 ($A832D176ECD5C7C6B58825AE22FC4C90FA249637) at 154.35.22.11:80
 ...
 Dec 14 11:46:33.000 [info] sample_reachable_filtered_entry_guards():
 Trying to sample a reachable guard: We know of 20 in the USABLE_FILTERED
 set.
 Dec 14 11:46:33.000 [info] sample_reachable_filtered_entry_guards():
 (After filters [17], we have 1 guards to consider.)
 Dec 14 11:46:33.000 [info] sample_reachable_filtered_entry_guards():
 (Selected [bridge] ($A09D536DD1752D542E1FBB3C9CE4449D51298239) at
 83.212.101.3:50002.)
 Dec 14 11:46:33.000 [info] select_entry_guard_for_circuit(): No primary or
 confirmed guards available. Selected random guard [bridge]
 ($A09D536DD1752D542E1FBB3C9CE4449D51298239) at 83.212.101.3:50002 for
 circuit. Will try other guards before using this circuit.
 Dec 14 11:46:33.000 [info] get_transport_by_bridge_addrport(): Looked up
 transport for 83.212.101.3:80: no such bridge found.
 ...
 Dec 14 11:46:33.000 [info] connection_or_note_state_when_broken():
 Connection died in state 'handshaking (TLS) with SSL state SSLv3/TLS write
 client hello in HANDSHAKE'
 Dec 14 11:46:33.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing
 handshake with first hop. (DONE; DONE; count 1; recommendation warn; host
 A09D536DD1752D542E1FBB3C9CE4449D51298239 at 83.212.101.3:80)
 }}}

 So, two interesting things here:

 1. Why did we pick LeifEricson for our connection the second time, after
 we had chosen 3 other primary guards?  The line `After filters [17], we
 have 1 guards to consider.` is suggestive here.  Note that 17 is hex here,
 so we are setting every SAMPLE_EXCLUDE_CONFIRMED, SAMPLE_EXCLUDE_PRIMARY,
 SAMPLE_EXCLUDE_PENDING, an

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor2
--+
Changes (by dgoulet):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Putting in 032 so we don't miss it. This notice level is something that is
 quite present in a normal relay logs. I get maybe 20-30 a day on a fast
 relay.

 Shouldn't we put it to info log? Not sure this is something worth telling
 the operator when it happens because the operator can't do anything or at
 best sync its clock?...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24555 [Core Tor/Tor]: Bug: tor_gmtime_r overflow - gmtime(9223372036854775807) failed with error No error

[Tor Bug Tracker & Wiki]

#24555: Bug: tor_gmtime_r overflow - gmtime(9223372036854775807) failed with 
error
No error
-+-
 Reporter:  s7r  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  integer-overflow time-overflow tor-  |  Actual Points:
  relay 2038-problem |
Parent ID:  #18480   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Oups... I put that in 032 but maybe this is in master actually? What did
 we get in that might have touched the time values?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [Webpages]: .Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: .Onion everywhere?: increasing the use of onion services through 
automatic
redirects and aliasing
--+--
 Reporter:  linda |  Owner:  linda
 Type:  project   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by asn):

 Pushed fixes to the Onion-Location proposal based on tjrs comments:
 https://gitweb.torproject.org/user/asn/torspec.git/log/?h=onion-location
 https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=onion-
 location&id=09de86045e99337548f404f96d79ce9a0c4bd7b1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24513 [Webpages/Website]: Guerrilla user test of support.torproject.org

[Tor Bug Tracker & Wiki]

#24513: Guerrilla user test of support.torproject.org
--+--
 Reporter:  isabela   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #24129| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 Hi! I started a pad to start a discussion about it :)

 Just WIP for now
 https://pad.riseup.net/p/User_Testing_Guerrilla

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

[Tor Bug Tracker & Wiki]

#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 We shouldn't think comment:2 is accurate also. After working on this, a
 simpler edge-case to trigger this became apparent so what you describe is
 really what should be considered as "the problem" of this ticket.

 > The first commit should fix this scenario because now
 can_client_refetch_desc() will return HS_CLIENT_FETCH_PENDING instead of
 HS_CLIENT_FETCH_HAVE_DESC. I wonder if there are any other such weird
 edge-cases this patch won't fix :S

 As you noticed, I left the BUG() there and even added a non fatal assert
 so if this is triggered again, we can investigate more. At least, in both
 cases, the tor client is fine and recovers.

 > Do we have a way to test this fix btw?

 I would love to come up with a test case. It is a bit difficult because we
 kind of need to artificially inject the race in a unit test. I think a
 useful unit test overall would be to make sure we can *NOT* launch 2
 directory requests in parallel for the same service. The
 `can_client_refetch_desc()` is really our safeguard there.

 The other thing we can unit test probably easily is have a pending
 directory request, after set a descriptor usable and call
 `hs_client_dir_info_changed()` to see that we don't get that usable
 descriptor.

 Both seems very doable. In the timeframe of 032 release candidate, dunno
 but definitely short term, this is needed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * status:  needs_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Here is a review:

 1) In `tor_remove_file(char *file)` you can constify `file` as follows:
 `tor_remove_file(const char *file)`. Also perhaps worth renaming to
 `filename`.

 2) This will slightly complicate the patch, but you probably need to use
 `get_ext_or_auth_cookie_file_name()` and
 `get_controller_cookie_file_name()` to get the right filename, since those
 files will be created even if the `CookieAuthFile` torrc option is not set
 but the control port is enabled.

 I suggest the following way to do this: Use `file_status()` to check if
 the filename that those functions returned exists, and unlink it if so.
 It's fine to do this extra overhead since this will happen only on
 shutdown. Example usage:
 {{{
   if (file_status(fname) == FN_FILE) {
 if (tor_unlink(fname) != 0) {
 }}}

 3) Consider using `tor_unlink()` instead of `unlink()`, so that it's more
 easily testable in the future if need be.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

[Tor Bug Tracker & Wiki]

#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 Both commits look reasonable to me. I think we could do a better job at
 explaining the edge-case in the first commit message because I got quite
 confused reading it (it also seems to be a different issue than the one
 described in comment:2).

 Here is the edge-case I consider:

 1) Network trouble and we end up with unreachable intro points on an HS
 desc.
 2) We start fetching new HS desc.
 3) `rend_cache_failure_clean_callback()` triggers unluckily before
 receiving new HS desc, and makes the descriptor usable again.
 4) We receive some leftover mds/consensus we asked for a few moments ago.
 This triggers `hs_client_dir_info_changed()` and we try to refetch the
 desc, but seems like the desc is now usable! Ugh bug triggers.

 The first commit should fix this scenario because now
 `can_client_refetch_desc()` will return `HS_CLIENT_FETCH_PENDING` instead
 of `HS_CLIENT_FETCH_HAVE_DESC`. I wonder if there are any other such weird
 edge-cases this patch won't fix :S

 Do we have a way to test this fix btw?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24537 [Internal Services/Service - git]: Please create a tor-browser-build user repo for sysrqb

[Tor Bug Tracker & Wiki]

#24537: Please create a tor-browser-build user repo for sysrqb
-+
 Reporter:  sysrqb   |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 [x]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24536 [Internal Services/Service - git]: Please create a tor-browser user repo for sysrqb

[Tor Bug Tracker & Wiki]

#24536: Please create a tor-browser user repo for sysrqb
-+
 Reporter:  sysrqb   |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 [x]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24622 [Applications/Tor Browser]: Torcrazybutton can't decipher website s3.amazonaws.com

[Tor Bug Tracker & Wiki]

#24622: Torcrazybutton can't decipher website s3.amazonaws.com
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-circuit-display


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23016 [Applications/Tor Browser]: "Print to File" does not create the expected file in non-English locales

[Tor Bug Tracker & Wiki]

#23016: "Print to File" does not create the expected file in non-English locales
-+-
 Reporter:  intrigeri|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s, TorBrowserTeam201712R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 The patch good to me and nice work! I fixed the typo's mentioned in
 comment:34 and some more and committed the patch to `tor-
 browser-52.5.2esr-7.5-2` (commit
 8ea9839478bfddd4f078f16c9268edf1755e9cb0). Leaving it open for now to
 address mcs's questions in comment:34.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24622 [Applications/Tor Browser]: Torcrazybutton can't decipher website s3.amazonaws.com

[Tor Bug Tracker & Wiki]

#24622: Torcrazybutton can't decipher website s3.amazonaws.com
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Go to https://s3.amazonaws.com/bucket/filled/with/pile/of/onions

 Then click on the Torbutton and you should see this:

 {{{
 -
 | @ |
 -
 |
  | New Identity   Ctrl+Shift+U | Tor circuit for this site
 |
  | New Tor Circuit for this Site  Ctrl+Shift+L | (--unknown--)
 |
  | | o This browser
 |
  | Security Settings...| o China  (xx.xx.xx.xx)
 |
  | Tor Network Settings... | o Russia (xx.xx.xx.xx)
 |
  | | o North Korea
 (xx.xx.xx.xx) |
  | Check for Tor Browser Update... | o Internet
 |
  | |
 |
 -
 }}}

 The relevant part is `Tor circuit for this site (--unknown--)`. Meaning
 that it can't decipher `amazonaws.com` it seems... 🤔

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24281 [Webpages/Website]: Make css changes to styleguide as per designs

[Tor Bug Tracker & Wiki]

#24281: Make css changes to styleguide as per designs
--+--
 Reporter:  isabela   |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #24280| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by antonela):

 Still WIP

 Updates are here
 
https://oniongit.eu/infra/styleguide/commit/84de29288b35a66a6075a9157eee14ffba2d

 Open To-do List for remaining things
 https://pad.riseup.net/p/styleguide-todos

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23966 [Core Tor/Tor]: Refactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()

[Tor Bug Tracker & Wiki]

#23966: Refactor node_has_curve25519_onion_key() to use
node_get_curve25519_onion_key()
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  |Sponsor:
+
Changes (by aruna1234):

 * Attachment "0005-Indentation-error-fixed.patch" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * status:  needs_information => needs_review


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ffmancera):

 Here is the update:

 After searching in the docs and combine chutney with strace, I came up
 with this new list of ephimeral files:

  * !PidFile
  * !ControlPortWriteToFile
  * !CookieAuthFile
  * ExtORPortCookieAuthFile

 Also, I have splitted tor_cleanup() function into a new function that
 removes a specified file. I think that is nice to reuse code.

 I hope everything is fine, check my github
 [https://github.com/ffmancera/tor/tree/github/bug23271 branch bug23271.]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile tbb-fingerprinting,   |  Actual Points:
  TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-mobile tbb-fingerprinting, TorBrowserTeam201712 => tbb-
 mobile tbb-fingerprinting, TorBrowserTeam201712R
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Thanks for all three fixups. The patches got applied to `tor-
 browser-52.5.2esr-7.5-2` as commit
 a1beadc5b70e1b6e4727506656723684cf3225bf and
 a72faadea544a71ae5ca95ec816f2684c205b56a).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24373 [Internal Services/Service - git]: Please create git repository user/irl/metrics-web

[Tor Bug Tracker & Wiki]

#24373: Please create git repository user/irl/metrics-web
-+
 Reporter:  irl  |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 [x]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Oh, and just for posterity: part of the proposed backport (of
 2797f193a147) already landed in ESR 52 previously, see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1343813 and
 https://hg.mozilla.org/releases/mozilla-esr52/rev/90f870bbec29).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs