Re: [tor-bugs] #28475 [Community/Tor Support]: Update support portal on Tor Browser for Android

[Tor Bug Tracker & Wiki]

#28475: Update support portal on Tor Browser for Android
---+---
 Reporter:  emmapeel   |  Owner:  phoul
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by emmapeel):

 Also https://support.torproject.org/tbb/tbb-31/  Which platforms is Tor
 Browser available for?

--
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] #27538 [Community/Tor Support]: Hi i try to open up tor brwser and i get the error(establishing an encrypted directory connection failed

[Tor Bug Tracker & Wiki]

#27538: Hi i try to open up tor brwser and i get the error(establishing an
encrypted directory connection failed
---+---
 Reporter:  mohammedsadiq  |  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by emmapeel):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 It seems Tor is blocked.

 Try using bridges: https://support.torproject.org/censorship/censorship-7/

--
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] #30175 [Applications/Tor Browser]: Manually whitelist extensions removed from AMO for purely political reasons in Tor Browser to fight Mozilla's censorship

[Tor Bug Tracker & Wiki]

#30175: Manually whitelist extensions removed from AMO for purely political 
reasons
in Tor Browser to fight Mozilla's censorship
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Replying to [comment:3 cypherpunks]:
 > >How would that work? There's no need for a "whitelist" since there is
 no "blocklist" in the first place, one can easily install that extension
 by manually downloading it for instance.
 >
 > Once installed, it only becomes a temporary add-on that is disabled at
 the next browser restart. That sounds like demoting it to a second-class
 citizen to me. My proposed fix would allow it to be upgraded to a full
 add-on.
 >
 > >Yep. Apart from that we strongly discourage installing random
 extensions from the internet (even from Mozilla's extensions' store) as
 they contain unknown risks to the privacy and anonymity of Tor Browser
 users. Thus, this is a won't fix.
 >
 > If the Tor Project doesn't wish to fix the technical problems with
 Firefox's extension system (which people are going to use regardless of
 the warnings against them), then the Tor Project should at least issue a
 statement against Mozilla's actions here.

 That's not a Tor Browser bug then. Thus, please leave this ticket closed,
 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] #29032 [Applications/Tor Browser]: Tor Browser 8.0.4 stops working correctly in Virtualbox on Windows

[Tor Bug Tracker & Wiki]

#29032: Tor Browser 8.0.4 stops working correctly in Virtualbox on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Thorin):

 * Attachment "onmi804-vs-803.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] #29032 [Applications/Tor Browser]: Tor Browser 8.0.4 stops working correctly in Virtualbox on Windows

[Tor Bug Tracker & Wiki]

#29032: Tor Browser 8.0.4 stops working correctly in Virtualbox on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 following from gk's comment,
 https://blog.torproject.org/comment/280752#comment-280752

 I unpacked the 11mb sized omni.ja's from windows 64 bit en-US and compared
 the directories, the following are the only files that changed size. If
 you want, I can run a hash check on all files and out the results.
 Otherwise the attached pic shows 14 files for you to think about

 FWIW, I run VMs of 4 Linux and 2 Windows (on Windows 7 64bit) in
 VirtualBox 6.0 and have never seen OPs issue.

 I wonder what Werner's VirtualBox release is?

--
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] #30179 [Core Tor]: Building with 'ALL_BUGS_ARE_FATAL'

[Tor Bug Tracker & Wiki]

#30179: Building with 'ALL_BUGS_ARE_FATAL'
--+--
 Reporter:  gvanem|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Building with **ALL_BUGS_ARE_FATAL** should AFAICS normally be
 reserved for Coverty and/or analysers. But just for kicks, I've
 added **-DALL_BUGS_ARE_FATAL** to my CFLAGS.

 This causes errors like these (from clang using a git-checkout from
 today):
 {{{
 buf/buffers.c(531,7):  error: too few arguments to function call, expected
 at least 5, have 4
   if (BUG(buf->datalen >= INT_MAX))
   ^~~~
 ..\lib/log/util_bug.h(151,70):  note: expanded from macro 'BUG'
(tor_assertion_failed_(SHORT_FILE__,__LINE__,__func__,"!("#cond")"), \
 ~^
 ..\lib/log/util_bug.h(242,1):  note: 'tor_assertion_failed_' declared here
 void tor_assertion_failed_(const char *fname, unsigned int line,
 ^
 buf/buffers.c(533,7):  error: too few arguments to function call, expected
 at least 5, have 4
   if (BUG(buf->datalen >= INT_MAX - string_len))
   ^
 ...
 }}}
 I've used this patch to fix it:
 {{{
 --- a/src/lib/log/util_bug.h 2019-04-14 03:56:41
 +++ b/src/lib/log/util_bug.h 2019-04-14 11:31:23
 @@ -148,7 +148,7 @@
  #define tor_assert_nonfatal_once(cond) tor_assert((cond))
  #define BUG(cond)   \
(ASSERT_PREDICT_UNLIKELY_(cond) ? \
 -   (tor_assertion_failed_(SHORT_FILE__,__LINE__,__func__,"!("#cond")"), \
 +   (tor_assertion_failed_(SHORT_FILE__,__LINE__,__func__,"!("#cond")",
 NULL), \
  abort(), 1) \
 : 0)
  #elif defined(TOR_UNIT_TESTS) && defined(DISABLE_ASSERTS_IN_UNIT_TESTS)
 }}}


 W/o knowing what the correct fix would 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] #30179 [Core Tor]: Building with 'ALL_BUGS_ARE_FATAL'

[Tor Bug Tracker & Wiki]

#30179: Building with 'ALL_BUGS_ARE_FATAL'
--+--
 Reporter:  gvanem|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gvanem):

 There is another issue with how **tor_assertf_nonfatal()** is defined when
 **ALL_BUGS_ARE_FATAL** is defined.

 So my above patch is now:
 {{{
 --- a/src/lib/log/util_bug.h 2019-04-14 03:56:41
 +++ b/src/log/util_bug.h 2019-04-14 14:45:15
 @@ -143,12 +143,12 @@
  #ifdef ALL_BUGS_ARE_FATAL
  #define tor_assert_nonfatal_unreached() tor_assert(0)
  #define tor_assert_nonfatal(cond) tor_assert((cond))
 -#define tor_assertf_nonfatal(cond, fmt, ...) tor_assertf(cond, fmt, ...)
 +#define tor_assertf_nonfatal(cond, fmt, ...) tor_assertf(cond, fmt,
 ##__VA_ARGS__)
  #define tor_assert_nonfatal_unreached_once() tor_assert(0)
  #define tor_assert_nonfatal_once(cond) tor_assert((cond))
  #define BUG(cond)   \
(ASSERT_PREDICT_UNLIKELY_(cond) ? \
 -   (tor_assertion_failed_(SHORT_FILE__,__LINE__,__func__,"!("#cond")"), \
 +   (tor_assertion_failed_(SHORT_FILE__,__LINE__,__func__,"!("#cond")",
 NULL), \
  abort(), 1) \
 : 0)
  #elif defined(TOR_UNIT_TESTS) && defined(DISABLE_ASSERTS_IN_UNIT_TESTS)
 }}}

--
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] #30179 [Core Tor/Tor]: Building with 'ALL_BUGS_ARE_FATAL'

[Tor Bug Tracker & Wiki]

#30179: Building with 'ALL_BUGS_ARE_FATAL'
--+
 Reporter:  gvanem|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * component:  Core Tor => Core Tor/Tor
 * milestone:   => Tor: 0.4.1.x-final


Comment:

 Looks like a recent bug in the formatted-assert code.

--
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] #30174 [Core Tor/sbws]: possible SBWS measurement quality regression

[Tor Bug Tracker & Wiki]

#30174: possible SBWS measurement quality regression
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  new => needs_information
 * version:   => sbws: 1.1.0
 * milestone:   => sbws: unspecified


Comment:

 Hi starlight,

 Thanks for reporting this.

 Replying to [ticket:30174 starlight]:
 > With the release of v1.1 to longclaw seeing evidence of measurement
 quality degradation, regression.  > Have not had time to work up an
 analysis.
 If you have time it would be great to know:
 - respect to which scanner and version you see degradation and regression
 - where/how do you see that

 > Recommend running Matt's original scanner and comparing raw bandwidth
 results.
 - which is Matt's original scanner. I guess you mean sbws < 1.x.x?. Most
 of the changes respect to previous versions have been done on the scaling
 part, not the measuring one.

--
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] #30180 [Core Tor/Tor]: CID 1444641: REVERSE_INULL in test_hs_cache.c

[Tor Bug Tracker & Wiki]

#30180: CID 1444641: REVERSE_INULL in test_hs_cache.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0 |   Reviewer:
  Sponsor:|
--+
 Just reported today.
 {{{
 ** CID 1444641:  Null pointer dereferences  (REVERSE_INULL)
 /src/test/test_hs_cache.c: 265 in helper_fetch_desc_from_hsdir()
 259 &received_desc, &body_used,
 HS_DESC_MAX_LEN, 0);
 260 tor_free(headers);
 261   }
 262
 263  done:
 264   tor_free(hsdir_query_str);
 >>> CID 1444641:  Null pointer dereferences  (REVERSE_INULL)
 >>> Null-checking "conn" suggests that it may be null, but it has
 already been dereferenced on all paths leading to the check.
 265   if (conn)
 266 connection_free_minimal(TO_CONN(conn));
 267
 268   return received_desc;
 269 }
 270
 }}}

--
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] #30180 [Core Tor/Tor]: CID 1444641: REVERSE_INULL in test_hs_cache.c

[Tor Bug Tracker & Wiki]

#30180: CID 1444641: REVERSE_INULL in test_hs_cache.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:  0
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * actualpoints:   => 0


Comment:

 See branch `ticket30180` with PR at
 https://github.com/torproject/tor/pull/943 .

 This is not actually a bug, so I recommend no backport.

--
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] #30180 [Core Tor/Tor]: CID 1444641: REVERSE_INULL in test_hs_cache.c

[Tor Bug Tracker & Wiki]

#30180: CID 1444641: REVERSE_INULL in test_hs_cache.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:  0
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => 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] #30164 [Core Tor/Tor]: Inconsistent Guard flag assignment

[Tor Bug Tracker & Wiki]

#30164: Inconsistent Guard flag assignment
--+--
 Reporter:  Jaym  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 (Changing component: we usually use "DirAuth" for something that the
 directory authorities need to take action on, and "Tor" for something
 about the Tor software.)

--
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] #30176 [Core Tor/Tor]: Clear memory in smartlist_remove_keeporder.

[Tor Bug Tracker & Wiki]

#30176: Clear memory in smartlist_remove_keeporder.
-+-
 Reporter:  paldium  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Minor| Resolution:
 Keywords:  035-backport? 040-backport?  |  Actual Points:
  defense-in-depth?  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_review
 * keywords:   => 035-backport? 040-backport? defense-in-depth?
 * milestone:   => Tor: 0.4.1.x-final


--
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] #28269 [Core Tor/Tor]: Repeated HSFETCH queries fail with QUERY_NO_HSDIR

[Tor Bug Tracker & Wiki]

#28269: Repeated HSFETCH queries fail with QUERY_NO_HSDIR
--+
 Reporter:  atagar|  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, tor-control tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  tor-hs, tor-control => tor-hs, tor-control tor-spec
 * milestone:  Tor: unspecified => Tor: 0.4.1.x-final


--
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] #30173 [Core Tor/Tor]: Ensure circuit padding can be safely disabled from consensus

[Tor Bug Tracker & Wiki]

#30173: Ensure circuit padding can be safely disabled from consensus
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed  |
Parent ID:  #28634   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2-can
-+-
Changes (by nickm):

 * milestone:   => Tor: 0.4.1.x-final


--
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] #29613 [Core Tor/Tor]: Make relays into exits when ExitRelay is auto and IPv6Exit is 1

[Tor Bug Tracker & Wiki]

#29613: Make relays into exits when ExitRelay is auto and IPv6Exit is 1
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 041-proposed, tor-relay, tor-  |  Actual Points:
  exit   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 PR is here: https://github.com/torproject/tor/pull/944

--
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] #30181 [Applications/Tor Browser]: Tor Browser exit code 139 when closing normally

[Tor Bug Tracker & Wiki]

#30181: Tor Browser exit code 139 when closing normally
---+--
 Reporter:  adrelanos  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Applications/Tor Browser
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 When closing Tor Browser, it exists with code 139 even no error happened.
 (Just when closing Tor Browser normally at the end of a browsing session.)

 8.0.8: can't reproduce

 8.5a10: affected

--
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] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
+
 Reporter:  mttp|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by holin):

 My maint-8.0-armhf branch is now a bit cleaner and the x86 stuff should
 build like it did originally without the arm changes interfering.

 I also uploaded a set of binaries to
 https://sourceforge.net/projects/tor-browser-ports/
 in case there's someone who'd like to test it out. So far, I've only
 tested basic functionality on an ARM laptop running Debian stretch.

 Going forward, I'll probably import the changes over to master and try to
 get nightly to build. However, in the grand scheme of things, Rust and
 Firefox are heavy beasts and, I think, assuming tor project even considers
 native build an option, supporting 32-bit build platforms is not the way
 to go unless the said behemoths suddenly lose some serious weight.

--
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] #28514 [Core Tor/Tor]: Open NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated

[Tor Bug Tracker & Wiki]

#28514: Open NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor-bwauth, 035-backport,   |  Actual Points:
  034-backport-maybe, 033-backport-maybe, 029|
  -backport-maybe-not, 033-backport-unreached|
Parent ID:  #22453   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  new => assigned
 * owner:  (none) => neel


--
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] #30164 [Core Tor/Tor]: Inconsistent Guard flag assignment

[Tor Bug Tracker & Wiki]

#30164: Inconsistent Guard flag assignment
--+--
 Reporter:  Jaym  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by amj703):

 Roger, I agree that this duplicates #11327, which is more general in that
 it includes the Fast flag.

--
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] #30051 [Core Tor/Tor]: Add practracker as a post-commit git hook for frequent coders

[Tor Bug Tracker & Wiki]

#30051: Add practracker as a post-commit git hook for frequent coders
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  practracker tech-debt tor-ci git-|  Actual Points:
  scripts|
Parent ID:  #29792   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 Replying to [comment:5 asn]:
 > An important thing here is that this script won't abort the commit when
 practracker finds issues, which seems like a reasonable idea since maybe
 you want to fix all the practracker issues on a subsequence commit.
 However, this might be a problem for people using git wrappers (like me)
 that ignore git-commit output, since they might not notice the failure.
 Personally, I turned this into a pre-commit hook for this reason, but this
 might not work for other people.
 >
 > Tim, Nick, any opinions here?

 If CI will fail when we push, git should also fail locally.

 But I don't really mind *when* we fail.

 Perhaps we should make it:
 * a pre-commit hook, to encourage frequent coders to write better code
 * a pre-push hook, so mergers don't push branches that will fail CI

 I think some other tickets might do what I want here.

--
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] #30122 [Core Tor/Stem]: Make stem's unit tests propagate the backtrace signals to child processes

[Tor Bug Tracker & Wiki]

#30122: Make stem's unit tests propagate the backtrace signals to child 
processes
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.4
Parent ID:  #29437 | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:2 atagar]:
 > Hi teor. Moving over from irc...
 >
 > {{{
 > 20:56 <+atagar> teor4: Hi teor. Concerning the 'ignore signals while
 >   in a signal handler' part of your stem signaling patch could you
 >   please provide repro steps for a case in which the
 disable_signal_handlers()
 >   call is helpful? I just tried sending SIGUSR1s both with and without
 >   doing that and in practice the dumps seem to have the same stacktraces
 >   but I probably simply need to adjust what I'm doing somehow.
 > }}}

 Signals are delivered asynchronously, so it is possible to have a signal
 arrive while python is executing a signal handler. Ignoring signals in a
 signal handler is a standard Unix precaution against these kinds of race
 conditions.

 From the Python documentation:

 Although Python signal handlers are called asynchronously as far as
 the Python user is concerned, they can only occur between the “atomic”
 instructions of the Python interpreter. This means that signals arriving
 during long calculations implemented purely in C (such as regular
 expression matches on large bodies of text) may be delayed for an
 arbitrary amount of time.

 https://docs.python.org/2/library/signal.html#module-signal

 For more information, see:

 https://en.wikipedia.org/wiki/Unix_signal#Risks

 I'm not sure if you can trigger a race condition with the current code. I
 wrote it carefully, so the outcome of each line (and most expressions)
 wouldn't be affected by multiple signals. But you can definitely get
 different stack traces, if the timing is just right.

 If you want to simulate a race condition, you can patch the pull request
 to signal the process itself:

 {{{
 -  # propagate the signal to any multiprocessing children
 -  pgid = os.getpgid(pid)
 -  for p in multiprocessing.active_children():
 -# avoid race conditions
 -if p.is_alive():
 -  os.kill(p.pid, sig)
 +  import time
 +  for _ in range(0, 10):
 +# cause a race condition by repeating the signal to this process
 +os.kill(pid, sig)
 +  # now keep the stack around, so it appears in future traces
 +  time.sleep(5)
 }}}

 Or you can just add a time.sleep(10) somewhere in the signal handler,
 after it prints the stack trace and flushes the buffer.

--
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] #30122 [Core Tor/Stem]: Make stem's unit tests propagate the backtrace signals to child processes

[Tor Bug Tracker & Wiki]

#30122: Make stem's unit tests propagate the backtrace signals to child 
processes
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.4
Parent ID:  #29437 | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Gotcha. Figured this was the case. I asked because I suspect checking the
 executing thread (rather than de-registering signals) will be a cleaner
 approach and I was unsure how you exercised that part of the patch.

 I'll experiment a bit later.

--
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] [Tor Bug Tracker & Wiki] Batch modify: #19009, #22453, #28509, #28510, ...

[Tor Bug Tracker & Wiki]

Batch modification to #19009, #22453, #28509, #28510, #28511, #28512, #28514 by 
teor:


Comment:
These tickets need a proposal before we write any code.

The two competing proposals in #22453 are:
1. Remove the bandwidth self-test
2. Increase the bandwidth self-test so it measures a reasonable amount of 
bandwidth

--
Tickets 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] #22453 [Core Tor/Tor]: Relays should regularly do a larger bandwidth self-test

[Tor Bug Tracker & Wiki]

#22453: Relays should regularly do a larger bandwidth self-test
-+-
 Reporter:  arma |  Owner:  juga
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328, tor-bwauth,  |
  035-backport, 034-backport-maybe, 033  |
  -backport-maybe, 029-backport-maybe-not, 033   |
  -backport-unreached, needs-proposal|
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 Here's how we might calculate a reasonable bandwidth for the self-test:
 1. Use 2 * NUM_SECONDS_ROLLING_MEASURE * min(RelayBandwidthRate,
 AuthDirGuardBWGuarantee) bytes
 2. Split those bytes into CIRCWINDOW_START cells per circuit
 3. But keep the number of circuits well below the DoS limits
 4. If there are extra cells left over, just split them evenly across the
 circuits

--
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] #30122 [Core Tor/Stem]: Make stem's unit tests propagate the backtrace signals to child processes

[Tor Bug Tracker & Wiki]

#30122: Make stem's unit tests propagate the backtrace signals to child 
processes
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.4
Parent ID:  #29437 | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:4 atagar]:
 > Gotcha. Figured this was the case. I asked because I suspect checking
 the executing thread (rather than de-registering signals) will be a
 cleaner approach and I was unsure how you exercised that part of the
 patch.
 >
 > I'll experiment a bit later.

 Our priority is fixing Tor's CI, and we need this patch to find out why
 test-stem is failing.

 Can you merge this patch as-is, and fix it later?
 Or can you merge this patch without the parts that disable signals, and
 add them later?

--
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] #29060 [Core Tor/Tor]: shellcheck: test-network.sh issues

[Tor Bug Tracker & Wiki]

#29060: shellcheck: test-network.sh issues
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, regression,  |  Actual Points:
  041-must   |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Looks good.

--
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] #30033 [Core Tor/Tor]: The pre-push hook should call the pre-commit hook on the final pushed commit

[Tor Bug Tracker & Wiki]

#30033: The pre-push hook should call the pre-commit hook on the final pushed
commit
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:  #29792| Points:
 Reviewer:  ahf   |Sponsor:
--+--
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Looks good. As far as I can tell it should only be called once now.

--
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] #28794 [Core Tor/Fallback Scripts]: Run an opt-in process for relay operators to become fallbacks in 2019

[Tor Bug Tracker & Wiki]

#28794: Run an opt-in process for relay operators to become fallbacks in 2019
---+
 Reporter:  teor   |  Owner:  phoul
 Type:  task   | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  assigned => needs_revision


Comment:

 An operator emailed me and asked me to remove this relay from the
 whitelist:
 
https://metrics.torproject.org/rs.html#details/36B9E7AC1E36B62A9D6F330ABEB6012BA7F0D400

--
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] #30033 [Core Tor/Tor]: The pre-push hook should call the pre-commit hook on the final pushed commit

[Tor Bug Tracker & Wiki]

#30033: The pre-push hook should call the pre-commit hook on the final pushed
commit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:  #29792| Points:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.4.1.x-final


--
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] #28223 [Core Tor/Tor]: Unparseable microdescriptor on public relay

[Tor Bug Tracker & Wiki]

#28223: Unparseable microdescriptor on public relay
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  040-roadmap-proposed, regression?,   |  Actual Points:  .2
  035-can, postfreeze-ok, 040-deferred-20190220  |
Parent ID:   | Points:  .2
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 CI failed on Windows, it looks like there's some duplicate code, and we
 could log some more useful information about the context of the NUL.

--
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] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  authority-test-done, consider-   |  Actual Points:  0.2
  backport-after-040-stable, tor-dirauth,|
  metrics-needs, tor-bwauth, |
  035-removed-20180711, 040-roadmap-proposed,|
  035-backport-maybe, 040-backport   |
Parent ID:  #25925   | Points:  0.2
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * keywords:
 consider-backport-after-authority-test, consider-backport-
 after-040-stable, tor-dirauth, metrics-needs, tor-bwauth,
 035-removed-20180711, 040-roadmap-proposed, 035-backport-maybe,
 040-backport
 =>
 authority-test-done, consider-backport-after-040-stable, tor-dirauth,
 metrics-needs, tor-bwauth, 035-removed-20180711, 040-roadmap-proposed,
 035-backport-maybe, 040-backport


Comment:

 We have tested this code on moria1 and longclaw.

--
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] #27199 [Core Tor/Tor]: panic inside rust extern "C" function is undefined behavior

[Tor Bug Tracker & Wiki]

#27199: panic inside rust extern "C" function is undefined behavior
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  asn-merge, nickm-merge, consider-|  Actual Points:  0.1
  backport-after-0404-alpha, rust,   |
  034-backport, 035-backport, 040-backport,  |
  041-proposed, 033-backport-unreached   |
Parent ID:   | Points:  0.1
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * keywords:
 rust, 034-backport, 035-backport, 040-backport, 041-proposed, 033
 -backport-unreached
 =>
 asn-merge, nickm-merge, consider-backport-after-0404-alpha, rust,
 034-backport, 035-backport, 040-backport, 041-proposed, 033-backport-
 unreached
 * points:   => 0.1
 * actualpoints:   => 0.1


Comment:

 Here are the pull requests:
 * 0.3.3: https://github.com/torproject/tor/pull/945
   * clean merge, unsupported release, testing only
 * 0.3.4: https://github.com/torproject/tor/pull/946
   * clean merge, testing only
 * 0.3.5: https://github.com/torproject/tor/pull/947
   * trivial merge
 * 0.4.0: https://github.com/torproject/tor/pull/948
   * clean merge, testing only
 * master: https://github.com/torproject/tor/pull/949
   * clean merge, testing only

 I'll merge PR 945 to maint-0.3.4, and PR 947 to maint-0.3.5. This change
 seems safe enough to backport in the next backport group.

 Please merge PR 947 to maint-0.4.0 and merge forward to master.

--
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] #27199 [Core Tor/Tor]: panic inside rust extern "C" function is undefined behavior

[Tor Bug Tracker & Wiki]

#27199: panic inside rust extern "C" function is undefined behavior
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  asn-merge, nickm-merge, consider-|  Actual Points:  0.1
  backport-after-0404-alpha, rust,   |
  034-backport, 035-backport, 040-backport,  |
  041-proposed, 033-backport-unreached   |
Parent ID:   | Points:  0.1
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * status:  needs_review => merge_ready
 * version:   => Tor: 0.3.3.1-alpha


--
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] #24490 [Core Tor/Tor]: Stop setting bridges running in networkstatus_getinfo_by_purpose()

[Tor Bug Tracker & Wiki]

#24490: Stop setting bridges running in networkstatus_getinfo_by_purpose()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, refactor, code- |  Actual Points:
  correctness|
Parent ID:   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.4.1.x-final


--
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] #24490 [Core Tor/Tor]: Stop setting bridges running in networkstatus_getinfo_by_purpose()

[Tor Bug Tracker & Wiki]

#24490: Stop setting bridges running in networkstatus_getinfo_by_purpose()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, refactor, code- |  Actual Points:
  correctness|
Parent ID:   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by teor):

 There are two pull requests in this ticket:
 Code: https://github.com/torproject/tor/pull/889
 Spec: https://github.com/torproject/torspec/pull/76

--
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] #23545 [Applications/Tor Browser]: UX improvement: Tor Browser should handle bogus HSv3 addresses

[Tor Bug Tracker & Wiki]

#23545: UX improvement: Tor Browser should handle bogus HSv3 addresses
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, ux-team,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  | Points:
Parent ID:  #30022   |  network-team: 5-10
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 Replying to [comment:17 asn]:
 > Unfortunately, currently TB does not use the HTTP CONNECT proxy, so we
 would need to do some tinkering especially when it comes to first-party
 isolation etc. Supposedly the little-t-tor side supports first-party
 isolation using the `X-Tor-Stream-Isolation` header or the `Proxy-
 Authorization` header, but it's been widely untested.

 I think this should generally just-work, as long as firefox implements
 HTTP CONNECT correctly without leaking DNS queries. (I've used HTTP
 Connect with other applications without any noticeable problems,
 personally). I also found in my inbox a [https://tools.ietf.org/html
 /draft-nottingham-proxy-status-00 new draft RFC] for standardizing an HTTP
 response header from a proxy, some of them seem nearly appropriate for
 this use case (Destination IP Unroutable?). Maybe we can take this
 opportunity and get a more general error status added for our use case
 now, instead.

 One other thought I had was tor can emit a controller event with
 information about a malformed onion address, too. This may be a way for
 providing error handling for applications using SOCKS, too. It'll be
 asynchronous, so the application/controller will need to correlate the
 request with the controller event.

--
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] #30182 [Core Tor/Chutney]: IPv6 Exits succeed on Travis Linux, but Travis Linux doesn't support IPv6

[Tor Bug Tracker & Wiki]

#30182: IPv6 Exits succeed on Travis Linux, but Travis Linux doesn't support 
IPv6
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core |Version:
  Tor/Chutney|   Keywords:  chutney-ci, network-team-
 Severity:  Normal   |  roadmap-2019-Q1Q2
Actual Points:   |  Parent ID:  #30066
   Points:  1|   Reviewer:
  Sponsor:   |
-+-
 So maybe we're not actually testing IPv6 traffic?

 See also #20067.

--
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] #20067 [Core Tor/Chutney]: Chutney should verify IPv6 SOCKSPorts

[Tor Bug Tracker & Wiki]

#20067: Chutney should verify IPv6 SOCKSPorts
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  testing, ipv6 |  Actual Points:
Parent ID:  #17011| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:5 teor]:
 > The exit part of this has been implemented: chutney has performed
 IPv6-only exit tests for a while now.

 But ipv6-exit doesn't seem to be testing IPv6 traffic, see #30182.

--
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] #29670 [Applications/Tor Launcher]: Could not create SOCKS args string

[Tor Bug Tracker & Wiki]

#29670: Could not create SOCKS args string
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

 * Attachment "debug.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] #29670 [Applications/Tor Launcher]: Could not create SOCKS args string

[Tor Bug Tracker & Wiki]

#29670: Could not create SOCKS args string
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 reproduced with a clean copy.
 debug log attached, I just hope there isn't anything sensitive...

--
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] #30183 [Core Tor/Chutney]: Consider using --offline by default, to improve stability

[Tor Bug Tracker & Wiki]

#30183: Consider using --offline by default, to improve stability
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:
Component:  Core |Version:
  Tor/Chutney|   Keywords:  chutney-ci, network-team-
 Severity:  Normal   |  roadmap-2019-Q1Q2
Actual Points:   |  Parent ID:  #29729
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 If we use --offline for most runs of most networks, we should be able to
 increase stability.

--
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] #29280 [Core Tor/Tor]: Use Chutney in Tor's CI

[Tor Bug Tracker & Wiki]

#29280: Use Chutney in Tor's CI
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  CI, PTs 029-backport 034-backport|  Actual Points:  1
  035-backport 040-backport, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #29267   | Points:
 Reviewer:  teor |Sponsor:
 |  Sponsor19
-+-

Comment (by teor):

 I've just finished #29729, and discovered a lot of interesting things
 about chutney, tor, and Travis in the process.

 I'll have some feedback on these pull requests tomorrow (~18 hours).

--
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] #29729 [Core Tor/Chutney]: Work out which networks to run in Chutney's CI

[Tor Bug Tracker & Wiki]

#29729: Work out which networks to run in Chutney's CI
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  chutney-ci, network-team-|  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 I think the latest branch should work.

 Please review:
 * https://github.com/torproject/chutney/pull/24

 I'll squash all the Travis commits before merging.

 Also check CI on the branch:
 * https://travis-ci.org/teor2345/chutney/builds/520124726
 And the previous version of the branch, before tuning:
 * https://travis-ci.org/teor2345/chutney/builds/520120778
 * https://travis-ci.org/torproject/chutney/builds/520120842

 If it's still unstable, my next step is --offline by default (#30183).

--
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] #29787 [Metrics/Onionperf]: Enumerate possible failure cases and include failure information in .tpf output

[Tor Bug Tracker & Wiki]

#29787: Enumerate possible failure cases and include failure information in .tpf
output
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Looks like they are all contained in the same file. Are you missing that
 one maybe?

 {{{
 $ grep -m1 "transfer5m,572," *.log
 onionperf_2019-01-13_23:59:59.tgen.log:2019-01-12 11:33:05
 1547292785.630821 [info] [shd-tgen-transfer.c:363]
 [_tgentransfer_changeState] transfer transfer5m,572,op-
 ab,GET,5242880,(null),0,state=COMMAND,error=NONE moving from state COMMAND
 to state RESPONSE
 $ grep -m1 "transfer50k,563," *.log
 onionperf_2019-01-13_23:59:59.tgen.log:2019-01-12 10:47:59
 1547290079.082864 [info] [shd-tgen-transfer.c:363]
 [_tgentransfer_changeState] transfer transfer50k,563,op-
 ab,GET,51200,(null),0,state=COMMAND,error=NONE moving from state COMMAND
 to state ERROR
 $ grep -m1 "transfer50k,581," *.log
 onionperf_2019-01-13_23:59:59.tgen.log:2019-01-12 12:19:58
 1547295598.455009 [info] [shd-tgen-transfer.c:363]
 [_tgentransfer_changeState] transfer transfer50k,581,op-
 ab,GET,51200,(null),0,state=COMMAND,error=NONE moving from state COMMAND
 to state ERROR
 }}}

--
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] #30184 [Core Tor/Tor]: release-0.2.9 doesn't compile on old rhel

[Tor Bug Tracker & Wiki]

#30184: release-0.2.9 doesn't compile on old rhel
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 On rhel6, building release-0.2.9 (git commit ca008906), I get
 {{{
   CC src/or/src_or_libtor_testing_a-rephist.o
 src/or/rephist.c:91: error: redefinition of typedef ‘bw_array_t’
 src/or/rephist.h:120: note: previous declaration of ‘bw_array_t’ was here
 make[1]: *** [src/or/src_or_libtor_testing_a-rephist.o] Error 1
 }}}

 Looks like when we backported some stuff, we didn't backport all of the
 subsequent fixes on the stuff.

 Here is a fix that lets it compile again (there could for sure be a better
 fix than this):
 {{{
 index dc86fad..d8f7eb2 100644
 --- a/src/or/rephist.c
 +++ b/src/or/rephist.c
 @@ -88,7 +88,6 @@
  static void bw_arrays_init(void);
  static void predicted_ports_init(void);

 -typedef struct bw_array_t bw_array_t;
  STATIC uint64_t find_largest_max(bw_array_t *b);
  STATIC void commit_max(bw_array_t *b);
  STATIC void advance_obs(bw_array_t *b);
 diff --git a/src/or/rephist.h b/src/or/rephist.h
 index c464b34..072987f 100644
 --- a/src/or/rephist.h
 +++ b/src/or/rephist.h
 @@ -114,10 +114,10 @@ void rep_hist_log_link_protocol_counts(void);

  extern uint64_t rephist_total_alloc;
  extern uint32_t rephist_total_num;
 +typedef struct bw_array_t bw_array_t;
  #ifdef TOR_UNIT_TESTS
  extern int onion_handshakes_requested[MAX_ONION_HANDSHAKE_TYPE+1];
  extern int onion_handshakes_assigned[MAX_ONION_HANDSHAKE_TYPE+1];
 -typedef struct bw_array_t bw_array_t;
  extern bw_array_t *write_array;
  #endif
 }}}

 (My bwauth still runs on 0.2.9, since I'm under the impression that's the
 last version that works well with bwauths. That's how I noticed.)

--
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