Re: [tor-bugs] #30195 [Applications/Tor Browser]: Resize window to default automatically

[Tor Bug Tracker & Wiki]

#30195: Resize window to default automatically
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 And just to add to that, **if** the browser was disabled from being
 resized: that would mean that the sidebar, the toolbar, the menubar, the
 density, the findbar (and maybe a few others I missed) would also need to
 be blocked/locked at a set display/size - because they all change your
 inner window as well. And that's just chrome elements.

--
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] #30001 [Core Tor/Tor]: test failure: dir_handle_get/status_vote_next_bandwidth

[Tor Bug Tracker & Wiki]

#30001: test failure: dir_handle_get/status_vote_next_bandwidth
-+-
 Reporter:  nickm|  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, fast-fix, |  Actual Points:  0.1
  040-backport, 035-backport-maybe   |
Parent ID:  #21377   | Points:  0.1
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 I didn't get to this ticket today, I'll do my revisions first thing
 tomorrow.

--
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] #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:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  no-mainline-merge, regression,   |  Actual Points:  0.1
  consider-backport-after-0404-alpha, fast-fix   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by teor):

 * status:  new => needs_revision
 * version:   => Tor: unspecified
 * points:   => 0.1
 * sponsor:   => SponsorQ
 * actualpoints:   => 0.1
 * keywords:  regression =>
 no-mainline-merge, regression, consider-backport-after-0404-alpha,
 fast-fix


Comment:

 Marking as SponsorQ, because this bug was introduced by a SponsorQ ticket.

 Marking for backport in the current batch, because it's a trivial
 compilation fix that is already in 0.3.4 and later.

 Replying to [ticket:30184 arma]:
 > 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.

 We merged 1da9741bca to master, but I removed the equivalent commit from
 0.2.9, because the CI failed:
 https://trac.torproject.org/projects/tor/ticket/23512#comment:38

 But the extern declaration is slightly different in 0.2.9 and 0.3.4, due
 to merge commit 813019cc57:
 {{{
 ++extern struct bw_array_t *write_array;
 ++#endif
 ++
 ++#ifdef REPHIST_PRIVATE
  +typedef struct bw_array_t bw_array_t;
 - extern bw_array_t *write_array;
 }}}

 I tried cherry-picking 1da9741bca, then adding the `struct` in a separate
 commit. (It was added to 0.3.4 in the merge commit.)

 Here is the pull request:
 * 0.2.9: https://github.com/torproject/tor/pull/957

 But that failed with:
 {{{
 src/test/test_relay.c:22:27: error: must use 'struct' tag to refer to type
   'bw_array_t'
 uint64_t find_largest_max(bw_array_t *b);
   ^
   struct
 src/test/test_relay.c:23:17: error: must use 'struct' tag to refer to type
   'bw_array_t'
 void commit_max(bw_array_t *b);
 ^
 struct
 src/test/test_relay.c:24:18: error: must use 'struct' tag to refer to type
   'bw_array_t'
 void advance_obs(bw_array_t *b);
  ^
  struct
 }}}

 So maybe I should backport the struct tags as well?

 > (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.)

 I'm not sure if that's true.
 You should ask the other torflow operators what they're running?

 (I wish I could tell you, but we didn't think of the tor version when we
 were doing the headers for sbws 1.0 or 1.1. We'll add it in #30196.)

--
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] #30196 [Core Tor/sbws]: Add the tor version to the sbws bandwidth file header

[Tor Bug Tracker & Wiki]

#30196: Add the tor version to the sbws bandwidth file header
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.2.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points:  1  |   Reviewer:
  Sponsor: |
---+---
 See #30184 for a situation where we wanted the tor version.

--
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] #30195 [Applications/Tor Browser]: Resize window to default automatically

[Tor Bug Tracker & Wiki]

#30195: Resize window to default automatically
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 No one is sure yet what the final form will take. It may be that sizing on
 new windows is replaced by letterboxing, or it may be that it is used in
 conjunction. And the letterboxing step sizes (which may be a sliding
 scale) haven't been decided. Until tests are done etc, it's not even known
 if this ticket will even be an issue (don't get me wrong: letterboxing
 will encourage more entropy, and having a set startup size is beneficial,
 as is sticking to it when you can).

 Right now the letterboxing is using a hardcoded 200x100 steps, so your
 situation in future is actually already fixed: e.g
 - you open at 1000x1000 pixels
 - you accidentally drag the window slightly bigger (say 1000x1034)
 - your viewport stays at 1000x1000. You were protected the whole time

 Disabling the browser chrome is most likely going to be a wontfix - I
 can't speak for gk et al, but it adds complexity that isn't needed, even
 if it could be done. And users could still maximize or go full screen.
 Allowing resizing is a usability issue - **all these years** it's just
 been a warning not to resize the browser - why would they suddenly lock
 the size at this stage, esp with letterboxing coming.

 That said, after the final form is decided, it would be kind of nice for a
 preset button that resets a window size - I think there's even another
 ticket open for that

--
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] #30195 [Applications/Tor Browser]: Resize window to default automatically

[Tor Bug Tracker & Wiki]

#30195: Resize window to default automatically
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Letterboxing is good but not a perfect solution to this. Not allowing the
 user to resize at all when using Safest settings is the more secure and
 foolproof solution.

--
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] #30195 [Applications/Tor Browser]: Resize window to default automatically

[Tor Bug Tracker & Wiki]

#30195: Resize window to default automatically
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 If you maximized the browser, just restore it. If you went full screen,
 just escape or F11 out of it. You will return to the previous size and
 position.

 There is a new feature coming in TB version 9 (the one based on Firefox
 68) that will mitigate manually resizing to a large degree, called
 `letterboxing` - it limits the viewport in the inner window, rather than
 relying on the browser and vrious chrome elements.

 Until then, when this happens, open a new window and close the existing
 one (and you will lose your tabs, sorry). NEW windows will open at the
 200x100 pixel inner window sizes

--
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] #30195 [Applications/Tor Browser]: Resize window to default automatically

[Tor Bug Tracker & Wiki]

#30195: Resize window to default automatically
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 The best way could be when using Safest settings to not allow browser
 window to change size.

--
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] #30195 [Applications/Tor Browser]: Resize window to default automatically

[Tor Bug Tracker & Wiki]

#30195: Resize window to default automatically
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  High |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 There are many times when I accidentally resize my browser window. There
 needs to be an option or perhaps when using Safest settings to
 automatically resize the window back to the original dimensions when it
 has been changed by the user.

--
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] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 Replying to [comment:58 sysrqb]:
 > What's the reasoning behind this changing? It is for future-proofing so
 we don't accidentally include other binaries if we add support for another
 arch? or is this for something else?

 We are bringing in multiple tor libraries from 5 different architectures
 in the latest release. So this method is more manageable.

 https://github.com/sisbell/tor-android-
 service/tree/784919d8eb19083cf761b3e7314c49d8befc00cd/service/src/main/jniLibs

 >
 > {{{
 > -
 > -zip -d $apk lib/armeabi/tor.so
 > +unzip $apk lib/*
 > +zip -d $apk lib/\*
 >
 >  [% IF c("var/android-x86") %]
 > -zip -d $apk lib/armeabi-v7a/tor.so
 > +zip $apk lib/x86/*
 >  [% END %]
 >
 >  [% IF c("var/android-armv7") %]
 > -zip -d $apk lib/x86/tor.so
 > +zip $apk lib/armeabi-v7a/*
 >  [% END %]
 >
 > +rm -fR lib
 > +
 > }}}

--
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] #29293 [Obfuscation/Snowflake]: New Design for client -- broker protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29293: New Design for client -- broker protocol for Snowflake
+---
 Reporter:  cohosh  |  Owner:  (none)
 Type:  task| Status:  new
 Priority:  High|  Milestone:
Component:  Obfuscation/Snowflake   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  snowflake, bridges, broker  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor19
+---

Comment (by dcf):

 One of the problems with the current client–broker protocol is its use of
 HTTP response codes to carry some of the information in the broker's
 response.
   https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/client/lib/rendezvous.go?id=6399ef9d4fa7d1dced903b43f329a43d3a80dfc7#n98
 For example, when the client requests /client, the broker returns either a
 200 with a response body, an empty 503, or an empty 400. This is awkward
 when doing rendezvous over non-HTTP channels, or even over AMP cache,
 which doesn't reliably pass through the server's original status code (see
 comment:24:ticket:25985). As it is now, if the client is operating in HTTP
 mode, it needs to look at the status code; but if it's operating in AMP
 cache mode, it needs a separate code path that ignores the status code and
 instead looks for the equivalent information somewhere in the response
 body.

 It would be easier if all the necessary information in the broker's
 response were in the HTTP body, because that's easier to port to other
 channels.

--
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] #30142 [Obfuscation/Snowflake]: Remove serene from snowflake.git commit access?

[Tor Bug Tracker & Wiki]

#30142: Remove serene from snowflake.git commit access?
---+--
 Reporter:  dcf|  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * status:  new => 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] #25985 [Obfuscation/Snowflake]: Snowflake rendezvous using AMP cache

[Tor Bug Tracker & Wiki]

#25985: Snowflake rendezvous using AMP cache
---+--
 Reporter:  twim   |  Owner:  dcf
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * owner:  (none) => dcf
 * status:  needs_revision => assigned


--
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] #29223 [Core Tor/Tor]: List canonical abbreviations to use in Tor functions and identifiers

[Tor Bug Tracker & Wiki]

#29223: List canonical abbreviations to use in Tor functions and identifiers
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .7
Parent ID:| Points:  1
 Reviewer:  teor  |Sponsor:  Sponsor31-must
--+

Comment (by teor):

 I want to make comments on this file, and I'd usually do that through a
 pull request.
 Where is it going to live?
 I think I'll start by dumping it in doc/HACKING, and we can move it to its
 final location later,

 I also have a broader question:

 Are identifiers in the tor specifications in scope?
 Juga and I spent a lot of time trying to name fields for the bandwidth
 file.
 A set of standard abbreviations would have been very useful.

--
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:
 |  merge_ready
 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 => merge_ready


Comment:

 Hexencode isn't very readable, but it's better than nothing.

 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] #30189 [Core Tor/Tor]: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.

[Tor Bug Tracker & Wiki]

#30189: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  035-backport  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Should we add ALL_BUGS_ARE_FATAL to one of our CI jobs?

--
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_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 041-proposed, tor-relay, tor-  |  Actual Points:  0.1
  exit   |
Parent ID:   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision
 * milestone:  Tor: unspecified => Tor: 0.4.1.x-final
 * actualpoints:   => 0.1


Comment:

 This looks good, but we could do a bit of refactoring to make the code
 simpler.
 And we need to update the man page.
 See my comments on the pull request.

--
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] #30194 [Applications/Tor Browser]: Change UserAgent to Chrome because Firefox ESR 60 is only 2% of internet traffic

[Tor Bug Tracker & Wiki]

#30194: Change UserAgent to Chrome because Firefox ESR 60 is only 2% of internet
traffic
--+--
 Reporter:  easymode  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Applications/Tor Browser
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 And rebase Tor Browser to ungoogled-chrome

--
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] #30193 [Applications/Tor Browser]: Add to bypass google capcha

[Tor Bug Tracker & Wiki]

#30193: Add to bypass google capcha
--+--
 Reporter:  easymode  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by easymode):

 Modify Ticket
 Action
 leave as new The owner will remain tbb-team.


 Excuse me how can I edit title

--
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] #30193 [Applications/Tor Browser]: Add to bypass google capcha

[Tor Bug Tracker & Wiki]

#30193: Add to bypass google capcha
---+--
 Reporter:  easymode   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Very High  |  Component:  Applications/Tor Browser
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 https://addons.mozilla.org/en-US/firefox/addon/buster-captcha-solver/

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

Comment (by teor):

 Replying to [comment:28 nickm]:
 > Teor, will this conflict with any other pending test-network changes?
 If not, I'm happy to merge this.

 We don't have any pending changes in test-network.sh in tor: it's a
 minimal wrapper that exec's chutney's test-network.sh.
 And we only add features to test-network.sh in chutney.

 So these changes are fine.
 We'll make further changes in #29689 when we copy the initial parts of
 chutney's test-network.sh into tor's test-network.sh.

--
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] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
-+-
 Reporter:  isabela  |  Owner:
 |  pospeselr
 Type:  project  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, |  Actual Points:
  TorBrowserTeam201806R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by easymode):

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


Comment:

 Can you guys please fix
 https://trac.torproject.org/projects/tor/ticket/30107#comment:9 ?

 Anyone can create custom CA authority and generate self-sign certificate
 signed by custom CA.
 And Tor Browser display pad lock icon.

 Can't you display padlock if the protocol is https:// on .onion?

--
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] #30107 [Applications/Tor Browser]: Self-sign .onion certificate (not CA) does not have padlock icon

[Tor Bug Tracker & Wiki]

#30107: Self-sign .onion certificate (not CA) does not have padlock icon
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by easymode):

 Clearnet env:
 https:// links show pad lock icon

 Onion env:
 Onion icon and Padlock icon, if the protocol is https:.

 > "proper CA cert" = signed by an authority your browser trusts, so, yes.
 >> Create self-sign CA authority.

 TLDR?

--
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] #30107 [Applications/Tor Browser]: Self-sign .onion certificate (not CA) does not have padlock icon

[Tor Bug Tracker & Wiki]

#30107: Self-sign .onion certificate (not CA) does not have padlock icon
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by easymode):

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


Comment:

 The problem here is https:// should be display padlock icon.

 > So, please don't reopen this bug, thanks.

 I suggest you to reopen this and fix your browser properly.
 Current icon is very confusing.

--
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] #30192 [- Select a component]: v3 onion addresses and mirrors

[Tor Bug Tracker & Wiki]

#30192: v3 onion addresses and mirrors
-+--
 Reporter:  user124  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I have been searching for information regarding the use of v3 .onion urls
 and am wondering if you can use the shorter v2 .onion url's as mirrors and
 if so if this will compromise the security of v3 and what the implications
 may be. I have searched the internet for answers but I don't believe
 anyone has asked the question.

--
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] #30053 [Core Tor/Tor]: Allow countrycodes in ExitPolicy

[Tor Bug Tracker & Wiki]

#30053: Allow countrycodes in ExitPolicy
--+--
 Reporter:  tornewuser|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by neel):

 `ExitRelay` and `ExitPolicy` is for exit relay operators, not clients. I
 believe you are talking about clients.

 I think what you're looking for is `ExcludeNodes`. To exclude a country,
 you can use `ExcludeNodes {RU}` if you want to exclude Russian relays.
 Replace `RU` with the country code you want to exclude (e.g. `DE` or `US`,
 just put them inside `{}`). If you want to block multiple countries, you
 can do them in a comma-separated list like `ExcludeNodes {RU}, {US}, {CN}`

 If you are talking about exit relay operators, blocking destinations to a
 country would consume resources, and could lead to false positives as IP
 addresses could be reassigned, transferred, or even allocated to another
 region than what's in the whois (e.g. cloud/VPS providers, multinational
 corporations with their own ASNs).

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

Comment (by starlight):

 According to the vote document it's "software_version=1.1.0", what I say
 above in the description (which you copy in reply), is the current git
 release and you posted about it on tor-relays.  This ticket is under SBWS
 so what doubt inspires the scanner/version question?

 The out-of-whack numbers I observed reverted--SBWS requires a substantial
 ramp-up time before quality is achieved.  Torflow has an explicit
 mechanism to delay publishing until equilibrium is present, suggest that
 SBWS employ something similar.

 My recommendation is to examine raw votes in comparison to the POC scanner
 Matt authored as a QA validation.  I still like the idea, even with the
 vote quality improvement.

--
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] #30191 [Applications]: Tracking files and other browsers

[Tor Bug Tracker & Wiki]

#30191: Tracking files and other browsers
--+--
 Reporter:  Haiweepp  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Applications
  Version:  Tor: unspecified  |   Severity:  Major
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Every page I try to use to contact Tor returns errors.  I register for
 Trac and it refuses to let me login and claims the capcha isn't accepted
 (22 times).  I have no idea what most of the technical terms you use are
 and that makes figuring anything out impossible.  You REALLY need to make
 contact and support/bug reports a hell of a lot easier to file and find.

 When I use Tor, then log out, I always use CCleaner to remove all traces.
 What I **always** find are files appearing in MS Edge and MS Internet
 Explorer and around 40 tracker files that weren't there when I cleaned it
 all prior to opening Tor.  I assumed that Tor would block tracking files
 since those are just highways back to me and I most assuredly assumed that
 no information would be shared with Microsoft browsers.  I've changed no
 settings in Tor after it was downloaded.

 I found nothing under VERSION that's even close to what my browser returns
 which is 8.0.8.  I love Tor and have financially supported it the last few
 years but my assumption about its safety has made me hesitant to use it.
 If tracking files are constantly placed on my system and files are being
 sent to Microsoft then the security that I expected doesn't exist.

--
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] #29276 [Obfuscation/BridgeDB]: Make a release of BridgeDB

[Tor Bug Tracker & Wiki]

#29276: Make a release of BridgeDB
--+--
 Reporter:  ahf   |  Owner:  phw
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 In an ideal world, the goal here would be to make it so a service admin
 (i.e. not a bridgedb dev) can take the instructions and the build artifact
 (tarball, git, etc), and arrive at a correctly deployed bridgedb service.
 Then somebody can install bridgedb somewhere, maintain it, report bugs
 back to the developers, upgrade when a new release is ready, etc.

 It is maybe overkill at this point because we don't have a separate
 service admin who can pick it up and do that -- so putting more structure
 around the release process might be a waste of our precious time for now.

 But going through the process once is probably a good idea even if we
 decide not to put that much formalism around it medium term -- I bet we
 will find a bunch of surprise changes in the deployed bridgedb service,
 that you would be unlikely to guess about given what's in git.

--
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] #30190 [Core Tor/Tor]: Do not warn about compatible OpenSSL upgrades

[Tor Bug Tracker & Wiki]

#30190: Do not warn about compatible OpenSSL upgrades
--+
 Reporter:  teor  |  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:  openssl   |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  nickm |Sponsor:
--+
Changes (by teor):

 * status:  new => 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] #30190 [Core Tor/Tor]: Do not warn about compatible OpenSSL upgrades

[Tor Bug Tracker & Wiki]

#30190: Do not warn about compatible OpenSSL upgrades
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  openssl   |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 I think we've had issues in the past where OpenSSL has promised version
 compatibility, but failed to deliver.

 I've assigned review to nickm, because he knows about our issues with
 OpenSSL library and header versions.

--
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] #30190 [Core Tor/Tor]: Do not warn about compatible OpenSSL upgrades

[Tor Bug Tracker & Wiki]

#30190: Do not warn about compatible OpenSSL upgrades
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  openssl
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:  nickm
  Sponsor:|
--+
 From https://github.com/torproject/tor/pull/951

 When releasing OpenSSL patch-level maintenance updates,
 we do not want to rebuild binaries using it.
 And since they guarantee ABI stability, we do not have to.

 Without this patch, warning messages were produced
 that confused users:
 https://bugzilla.opensuse.org/show_bug.cgi?id=1129411

--
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] #29710 [Core Tor/sbws]: Is it acceptable that SBWS consistently reports 6200 relays, 1000 fewer than Torflow's 7200 universe?

[Tor Bug Tracker & Wiki]

#29710: Is it acceptable that SBWS consistently reports 6200 relays, 1000 fewer
than Torflow's 7200 universe?
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:  sbws: unspecified
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * milestone:   => sbws: unspecified


--
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] #29710 [Core Tor/sbws]: Is it acceptable that SBWS consistently reports 6200 relays, 1000 fewer than Torflow's 7200 universe?

[Tor Bug Tracker & Wiki]

#29710: Is it acceptable that SBWS consistently reports 6200 relays, 1000 fewer
than Torflow's 7200 universe?
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:  sbws: unspecified
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 Hi, we deployed sbws 1.1.0 to bastet and longclaw.
 sbws 1.1.0 fixes some bugs, and adds extra error reporting to the
 bandwidth file.
 (It generates file format version 1.4.0.)

 Can you please re-do your analysis with the latest votes and bandwidth
 files from longclaw?

 The bandwidth file for longclaw is available at:
 http://199.58.81.140/tor/status-vote/next/bandwidth

 sbws now reports all of the relays in the bandwidth file.
 Some relays will be excluded from the vote, their bandwidth lines contain
 "vote=0".
 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n886

--
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] #30125 [Obfuscation/Snowflake]: Port server's log sanitization to client, broker, and proxy-go

[Tor Bug Tracker & Wiki]

#30125: Port server's log sanitization to client, broker, and proxy-go
---+-
 Reporter:  dcf|  Owner:  cohosh
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+-
Changes (by dcf):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:6 cohosh]:
 > Replying to [comment:4 dcf]:
 > > The refactoring looks good. I have a few ideas about deployment to
 save us some trouble later. My main goal is that there should be a clean
 break between the old unsanitized logs and the new sanitized logs, so that
 we don't later have to trawl through a log file and figure out where the
 change happened. This is because I'd like us to extract what we need from
 the old logs and then delete them.
 >
 > Thanks! This looks reasonable to me. Do you have something in mind for
 extracting useful data from the unsanitized logs? I suppose we could write
 a separate scrubber to sanitize them retroactively.

 For myself, I just want to make graphs showing the number of client and
 proxy requests per second, like these from flash proxy:
  * https://people.torproject.org/~dcf/graphs/fp-facilitator-201601.png
  * https://people.torproject.org/~dcf/graphs/fp-num-proxies-201601.png

 I'm fine with keeping/publishing a scrubbed version of the old logs, or
 e.g. CSV files derived from them. I don't think we should keep the
 originals indefinitely. I'll add this topic to the agenda for the next
 check-in meeting.

 > > For proxy-go, it will be similar, except that there are several /home
 /snowflake-proxy/*.log.d log directories. Also /home/snowflake-proxy
 /snowflake-proxy-*.log{,.xz} are unsanitized logs from before we started
 using runit log directories (happened in #28390).
 > I've noticed that there are a lot of old logs from different proxy-go
 instances. I'll set up the tarball to keep the directory structure, but I
 guess my question is the same as above about what we're planning on using
 these logs for.

 Yeah, the log structure changed in the past in order to allow compression
 and rotation, because we ran out of disk space using single files :/ (That
 was #28390.) For me personally, I don't have any use in mind for the old
 proxy-go logs and would be fine with just deleting them.

 > > For the client, we'll need a Tor Browser ticket to pick up the
 upgrade. A sample ticket and patch that can serve as a template is #26795.
 I know you are interested in the reproducible build and this would be a
 good introduction to
 [[doc/TorBrowser/Hacking#BuildingOfficialTorBrowserReleaseBinaries|rbm]]
 if you haven't used it yet. Basically, you just need to edit
 projects/snowflake/config and update `git_hash`, then run `make testbuild`
 to make sure it still builds, then open a ticket in the Applications/Tor
 Browser component.
 > Cool! I also wanted to ask you about thoughts you have about when to
 make snowflake client releases. I'm assuming it's just whenever there are
 changes we think are important to have people start using. But I also
 don't want to overwhelm the applications team.

 Yes, so far it's whenever there's a change we want people to start using.
 Doing it once per alpha release is not too much. As long as you test that
 the build works across all platforms (that's what `make testbuild` does),
 it's not so much trouble for the Tor Browser devs--it's when something
 breaks the build and they have to start backing out changes that it's
 cumbersome. IMO it's justified in this case and also a good excuse to file
 a first Tor Browser 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] #28403 [Metrics/Consensus Health]: Link to bandwidth files from Consensus Health

[Tor Bug Tracker & Wiki]

#28403: Link to bandwidth files from Consensus Health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 longclaw returns the bandwidth file at:
 http://199.58.81.140/tor/status-vote/next/bandwidth

--
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] #30001 [Core Tor/Tor]: test failure: dir_handle_get/status_vote_next_bandwidth

[Tor Bug Tracker & Wiki]

#30001: test failure: dir_handle_get/status_vote_next_bandwidth
-+-
 Reporter:  nickm|  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, fast-fix, |  Actual Points:  0.1
  040-backport, 035-backport-maybe   |
Parent ID:  #21377   | Points:  0.1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * status:  assigned => 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] #30001 [Core Tor/Tor]: test failure: dir_handle_get/status_vote_next_bandwidth

[Tor Bug Tracker & Wiki]

#30001: test failure: dir_handle_get/status_vote_next_bandwidth
-+-
 Reporter:  nickm|  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, fast-fix, |  Actual Points:  0.1
  040-backport, 035-backport-maybe   |
Parent ID:  #21377   | Points:  0.1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * keywords:  fast-fix, 040-backport, 035-backport-maybe => tor-ci-fail-
 sometimes, fast-fix, 040-backport, 035-backport-maybe
 * owner:  nickm => teor
 * version:   => Tor: 0.4.0.4-rc
 * status:  needs_revision => assigned
 * reviewer:   => nickm


Comment:

 Hi Nick, I'm going to revise this CI failure ticket today, so we can get
 it merged.
 I think I'll also need to update the changes file, because we released
 this bug in 0.4.0.4-rc.

--
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] #29200 [Webpages/Website]: Make more accessible Core Tor documentation

[Tor Bug Tracker & Wiki]

#29200: Make more accessible Core Tor documentation
+--
 Reporter:  juga|  Owner:  pili
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  website redesign
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:
 Keywords:  documentation, ux-team  |  Actual Points:
Parent ID:  #24132  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gaba):

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #26671, #26644, #26937, #27342, ...

[Tor Bug Tracker & Wiki]

Batch modification to #26671, #26644, #26937, #27342, #27512, #27916, #27917, 
#27918, #28105, #28267, #28268, #28497, #28600, #29707 by teor:
milestone to sbws: 1.0.x-final

Comment:
Moving closed sbws tickets to sbws: 1.0.x-final.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #29710, #30067

[Tor Bug Tracker & Wiki]

Batch modification to #29710, #30067 by teor:
milestone to sbws: unspecified

Comment:
Moving sbws tickets without a milestone to sbws: unspecified.

--
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] #29699 [Core Tor/Tor]: INTRO2 replay warn logs with v3 onions

[Tor Bug Tracker & Wiki]

#29699: INTRO2 replay warn logs with v3 onions
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by s7r):

 Yes, this might be a dup of #26806. I get it from time to time on my v3
 onions (like today for example). I was on `Tor 0.4.0.1-alpha-dev`
 installed from deb.tpo tor-nightly-master-stretch. This is a public v3
 onion, so it gets some usage.

 {{{
 Apr 15 00:05:32.000 [warn] Possible replay detected! An INTRODUCE2 cell
 with thesame ENCRYPTED section was seen 5 seconds ago. Dropping cell.
 }}}

--
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] #29565 [Obfuscation/Snowflake]: Fix broker robots.txt to disallow crawling

[Tor Bug Tracker & Wiki]

#29565: Fix broker robots.txt to disallow crawling
---+-
 Reporter:  dcf|  Owner:  cohosh
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by dcf):

 * status:  needs_review => merge_ready


Comment:

 Looks good, thanks for doing 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #28547, #28563, #28565, #28567, ...

[Tor Bug Tracker & Wiki]

Batch modification to #28547, #28563, #28565, #28567, #29750, #29751, #29775, 
#29853, #29854 by teor:
milestone to sbws: 1.1.x-final

Comment:
Move sbws 1.1.0 tickets into 1.1.x-final, to match Tor's milestone scheme.

--
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] #29276 [Obfuscation/BridgeDB]: Make a release of BridgeDB

[Tor Bug Tracker & Wiki]

#29276: Make a release of BridgeDB
--+--
 Reporter:  ahf   |  Owner:  phw
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:
--+--
Changes (by phw):

 * owner:  catalyst => phw


Comment:

 Taking this off of catalyst's plate after a brief discussion on IRC.

--
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] #29278 [Obfuscation/Pluggable transport]: Assess HTTP proxy

[Tor Bug Tracker & Wiki]

#29278: Assess HTTP proxy
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+---
Changes (by phw):

 * cc: phw (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] #29276 [Obfuscation/BridgeDB]: Make a release of BridgeDB

[Tor Bug Tracker & Wiki]

#29276: Make a release of BridgeDB
--+--
 Reporter:  ahf   |  Owner:  catalyst
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:
--+--
Changes (by phw):

 * cc: phw (added)


Comment:

 BridgeDB has a [https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG
 CHANGELOG] file that lists changes for each version, and its git
 repository also has tags for each version; the latest being
 [https://gitweb.torproject.org/bridgedb.git/tag/?h=bridgedb-0.6.9
 bridgedb-0.6.9]. What else do we need to close this 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] #29565 [Obfuscation/Snowflake]: Fix broker robots.txt to disallow crawling

[Tor Bug Tracker & Wiki]

#29565: Fix broker robots.txt to disallow crawling
---+--
 Reporter:  dcf|  Owner:  cohosh
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cohosh):

 * 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] #29565 [Obfuscation/Snowflake]: Fix broker robots.txt to disallow crawling

[Tor Bug Tracker & Wiki]

#29565: Fix broker robots.txt to disallow crawling
---+--
 Reporter:  dcf|  Owner:  cohosh
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cohosh):

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


Comment:

 Fixed: https://github.com/cohosh/snowflake/compare/ticket29565

--
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] #29607 [Core Tor/Tor]: 2019 Q1: Denial of service on v2 and v3 onion service

[Tor Bug Tracker & Wiki]

#29607: 2019 Q1: Denial of service on v2 and v3 onion service
+
 Reporter:  pidgin  |  Owner:  pidgin
 Type:  defect  | Status:  needs_information
 Priority:  Immediate   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs tor-dos  |  Actual Points:
Parent ID:  | Points:  10
 Reviewer:  |Sponsor:  Sponsor27-can
+

Comment (by asn):

 HelpDOS I don't know what 'librarytask' is. Also, feel free to send us any
 additional information over email. My email is `a...@torproject.org` or use
 tor-secur...@lists.torproject.org .

--
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] #30168 [Applications/Tor Browser]: Clean up e.g. tor-browser-build after shipping TOPL

[Tor Bug Tracker & Wiki]

#30168: Clean up e.g. tor-browser-build after shipping TOPL
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201904   |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Making a note here, `android-dependencies.patch` should be a commit on
 tor-browser instead. We don't need to patch our own code for this purpose
 (`e0c5b567242d1bbfaab5a7aaa8e1b76c992cceb2`).

--
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] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 What's the reasoning behind this changing? It is for future-proofing so we
 don't accidentally include other binaries if we add support for another
 arch? or is this for something else?

 {{{
 -
 -zip -d $apk lib/armeabi/tor.so
 +unzip $apk lib/*
 +zip -d $apk lib/\*

  [% IF c("var/android-x86") %]
 -zip -d $apk lib/armeabi-v7a/tor.so
 +zip $apk lib/x86/*
  [% END %]

  [% IF c("var/android-armv7") %]
 -zip -d $apk lib/x86/tor.so
 +zip $apk lib/armeabi-v7a/*
  [% END %]

 +rm -fR lib
 +
 }}}

--
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] #30007 [Core Tor/Tor]: refactor control.c output to be more abstract

[Tor Bug Tracker & Wiki]

#30007: refactor control.c output to be more abstract
+--
 Reporter:  catalyst|  Owner:  catalyst
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  #29210  | Points:  3
 Reviewer:  |Sponsor:  Sponsor31-can
+--

Comment (by catalyst):

 Pull request at https://github.com/torproject/tor/pull/956

--
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] #29607 [Core Tor/Tor]: 2019 Q1: Denial of service on v2 and v3 onion service

[Tor Bug Tracker & Wiki]

#29607: 2019 Q1: Denial of service on v2 and v3 onion service
+
 Reporter:  pidgin  |  Owner:  pidgin
 Type:  defect  | Status:  needs_information
 Priority:  Immediate   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs tor-dos  |  Actual Points:
Parent ID:  | Points:  10
 Reviewer:  |Sponsor:  Sponsor27-can
+

Comment (by HelpDOS):

 Replying to [comment:44 pidgin]:
 > Problem is still not solved, still the same error.
 > I have provided everything i could to you guys i have no clue what to do
 else.

 Via "librarytask"

--
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_review
 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 nickm):

 * status:  needs_revision => needs_review


Comment:

 I've tried to do the requested changes.  I couldn't log an identifier for
 the MD, since a lot of the code that calls warn_if_nul has no concept of
 individual microdescs, and the code that does have a concept of them
 doesn't know anything about MD identity until after the point when it's
 called.

--
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] #29607 [Core Tor/Tor]: 2019 Q1: Denial of service on v2 and v3 onion service

[Tor Bug Tracker & Wiki]

#29607: 2019 Q1: Denial of service on v2 and v3 onion service
+
 Reporter:  pidgin  |  Owner:  pidgin
 Type:  defect  | Status:  needs_information
 Priority:  Immediate   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs tor-dos  |  Actual Points:
Parent ID:  | Points:  10
 Reviewer:  |Sponsor:  Sponsor27-can
+

Comment (by HelpDOS):

 Replying to [comment:44 pidgin]:
 > Problem is still not solved, still the same error.
 > I have provided everything i could to you guys i have no clue what to do
 else.

 I found a complete solution but it needs more work to be reliable enough.
 Get in touch with me via your onion.

 Will provide the solution here also but it is a novel method of
 identifying offending connections so they can then be dropped, which would
 likely not be implemented into core 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] #30114 [Core Tor/Tor]: Also fetch tor-github when we git-pull-all.sh

[Tor Bug Tracker & Wiki]

#30114: Also fetch tor-github when we git-pull-all.sh
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  git-scripts, fast-fix  |  Actual Points:  0.1
Parent ID: | Points:  0.1
 Reviewer:  nickm  |Sponsor:
---+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 lgtm

--
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:  nickm|Sponsor:
-+-

Comment (by nickm):

 Looks good to me.  I've put it in a branch called `ticket30176`, and added
 a changes file and a comment.  For CI purposes I've made a PR at
 https://github.com/torproject/tor/pull/955 .  If CI passes, let's merge.

--
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] #28655 [Obfuscation/BridgeDB]: If a bridge supports obfs4, don't give out its other flavors

[Tor Bug Tracker & Wiki]

#28655: If a bridge supports obfs4, don't give out its other flavors
--+--
 Reporter:  arma  |  Owner:  phw
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  Sponsor19
--+--

Comment (by phw):

 So far, all of leekspin's generated descriptors included obfs2, obfs3,
 obfs4, and scramblesuit. This broke BridgeDB's unit tests because all
 descriptors included a probing-resistant PT (obfs4 and scramblesuit), so
 BridgeDB wouldn't hand out its obfs2, obfs3, and vanilla bridges. To fix
 this, I made leekspin generate descriptors with various combinations of
 pluggable transports:
 
https://gitweb.torproject.org/user/phw/leekspin.git/commit/?id=9af6c71b3b4aeb56c509df9ae6a16650f9b58dd2
 Let me know if this patch looks good to you.

 Unfortunately, the HTTPS unit tests still break -- apparently randomly.
 Here's one of my recent, failed builds: https://travis-
 ci.org/NullHypothesis/bridgedb/jobs/520411314

 Since my leekspin patch creates pluggable transport combinations
 deterministically, I believe that the issue is somewhere in BridgeDB's
 HTTPS distribution mechanism.

--
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] #30189 [Core Tor/Tor]: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.

[Tor Bug Tracker & Wiki]

#30189: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  035-backport  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 (Note that master will still be broken with ALL_BUGS_ARE_FATAL until
 #30179 is merged on top of 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] #30179 [Core Tor/Tor]: Building with 'ALL_BUGS_ARE_FATAL' fails because of formatted assertion changes.

[Tor Bug Tracker & Wiki]

#30179: Building with 'ALL_BUGS_ARE_FATAL' fails because of formatted assertion
changes.
--+
 Reporter:  gvanem|  Owner:  (none)
 Type:  defect| Status:  merge_ready
 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:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 I put this in a branch as `bug30179`.  It's based on `bug30189_035`, since
 otherwise there would be conflicts.  PR at
 https://github.com/torproject/tor/pull/954 .

 We can merge this once #30189 is merge_ready.

--
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] #30189 [Core Tor/Tor]: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.

[Tor Bug Tracker & Wiki]

#30189: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  035-backport  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 There's a merge conflict with master, resolved in `bug30189_041` with PR
 at https://github.com/torproject/tor/pull/953

 I recommend no backport to 0.3.4, since this is a pretty rare
 configuration for anybody to build 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] #29796 [Internal Services/Tor Sysadmin Team]: synchronize puppet and LDAP hosts

[Tor Bug Tracker & Wiki]

#29796: synchronize puppet and LDAP hosts
-+
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by anarcat):

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


Comment:

 i don't remember how hyalinum was removed, but geyeri and gillii have both
 been cleaned up by ln5, and the remaining ones are windows machines so
 there's nothing much we can do 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] #30179 [Core Tor/Tor]: Building with 'ALL_BUGS_ARE_FATAL' fails because of formatted assertion changes.

[Tor Bug Tracker & Wiki]

#30179: Building with 'ALL_BUGS_ARE_FATAL' fails because of formatted assertion
changes.
--+
 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:  nickm |Sponsor:
--+

Comment (by nickm):

 I opened #30189 for the other issue.

--
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] #30189 [Core Tor/Tor]: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.

[Tor Bug Tracker & Wiki]

#30189: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  035-backport  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * component:  - Select a component => Core Tor/Tor
 * actualpoints:   => .1


Comment:

 Branch `bug30189`; bugfix on https://github.com/torproject/tor/pull/952

--
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] #30189 [- Select a component]: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.

[Tor Bug Tracker & Wiki]

#30189: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  035-backport
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Found while reviewing #30179:

 We don't include stdlib.h in util_bugs.h, which is sometimes a problem,
 since the macros declared there can call abort().

 This problem is particularly bad for the nonfatal assertions, since they
 don't call abort() unless ALL_BUGS_ARE_FATAL is defined, which it only
 rarely 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

Re: [tor-bugs] #30179 [Core Tor/Tor]: Building with 'ALL_BUGS_ARE_FATAL' fails because of formatted assertion changes. (was: Building with 'ALL_BUGS_ARE_FATAL')

[Tor Bug Tracker & Wiki]

#30179: Building with 'ALL_BUGS_ARE_FATAL' fails because of formatted assertion
changes.
--+
 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:  nickm |Sponsor:
--+

--
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:  nickm |Sponsor:
--+

Comment (by nickm):

 Hm. There's an older bug in this code, in that it calls abort() without
 including stdlib.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] #29864 [Internal Services/Tor Sysadmin Team]: consider replacing nagios with prometheus

[Tor Bug Tracker & Wiki]

#29864: consider replacing nagios with prometheus
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by anarcat:

Old description:

> As a followup to the Prometheus/Grafana setup started in #29681, I am
> wondering if we should also consider replacing the Nagios/Icinga server
> with Prometheus. I have done a little research on the subject and figured
> it might be good to at least document the current state of affairs.
>
> This would remove a complex piece of architecture we have at TPO that was
> designed before Puppet was properly deployed. Prometheus has an
> interesting federated design that allows it to scale to multiple machines
> easily, along with a high availability component for the alertmanager
> that allows it to be more reliable than a traditionnal Nagios
> configuration. It would also simplify our architecture as the Nagios
> server automation is a complex mix of Debian packages and git hooks that
> is serving us well, but hard to comprehend and debug for new
> administrators. (I managed to wipe the entire Nagios config myself on my
> first week on the job by messing up a configuration file.) Having the
> monitoring server fully deployed by Puppet would be a huge improvement,
> even if it would be done with Nagios instead of Prometheus, of course.
>
> Right now the Nagios server is actually running Icinga 1.13, a Nagios
> fork, on a heztner machine (`hetzner-hel1-01`). It's doing its job
> generally well although it feels a *little* noisy, but that's to be
> expected form Nagios servers. Reducing the number of alerts seems to be
> an objective, explicitely documented in #29410, for example.
>
> Both Grafana and Prometheus can do alerting, with various mechanisms and
> plugins. I haven't investigated those deeply, but in general that's not a
> problem in alerting: you fire some script or API and the rest happens. I
> suspect we could port the current Nagios alerting scripts to Prometheus
> fairly easily, although I haven't investigated our scripts in details.
>
> The problem is reproducing the check scripts and their associated alert
> threshold. In the Nagios world, when a check is installed, it *comes*
> with its own health ("OK", "WARNING", "CRITICAL") threshold and TPO has
> developed a wide variety of such checks. According to the current Nagios
> dashboard, it monitors 4612 services on 88 hosts (which is interesting
> considering LDAP thinks there are 78). That looks terrifying, but it's
> actually a set of 9 commands running on the Nagios server, including the
> complex `check_nrpe` system, which is basically a client-side nagios that
> has its own set of checks. And that's where the "cardinal explosion"
> happens: on a typical host, there are 315 such checks implemented.
>
> That's the hard part: convert those 324 checks into Prometheus alerts,
> one at a time. Unfortunately, there are no "built-in" or even "third-
> party" "prometheus alert sets" that I could find in my
> [https://anarc.at/blog/2018-01-17-monitoring-prometheus/ original
> research], although that might have changed in the last year.
>
> Each check in Prometheus is basically a YAML file describing a Prometheus
> query that, when it evaluates to "true" (e.g. disk_space > 90%), sends an
> alert. It's not impossible to do that conversion, it's just a lot of
> work.
>
> To do this progressively while allowing us to make new alerts on
> Prometheus instead of Nagios, I suggest to proceed the same way
> Cloudflare did, which is to establish a "Nagios to Prometheus" bridge, by
> which Nagios doesn't send the alerts on its own and instead forwards them
> to the Prometheus server, a plugin they called
> [https://github.com/cloudflare/promsaint Promsaint].
>
> With the bridge in place, Nagios checks can be migrated into Prometheus
> alerts progressively without disruption. Note that Cloudflare documented
> their experience with Prometheus in [https://promcon.io/2017-munich/talks
> /monitoring-cloudflares-planet-scale-edge-network-with-prometheus/ this
> 2017 promcon talk]. Cloudflare also made an alert dashboard called
> [https://github.com/cloudflare/unsee unsee] (see also the fork called
> [https://github.com/prymitive/karma karma]) and
> [https://github.com/cloudflare/alertmanager2es elasticsearch integration]
> which might be good to investigate further.
>
> Another useful piece

[tor-bugs] #30188 [Webpages/Website]: Jagannath Industries

[Tor Bug Tracker & Wiki]

#30188: Jagannath Industries
-+-
 Reporter:  VishalTailor |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:
 |  Webpages/Website
  Version:   |   Severity:  Normal
 Keywords:  DWC pipe, HDPE Corrugated Pipes  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Jagannath Industries is a renowned corrugated pipe manufacturer and
 supplier company in India offering a wide range of HDPE pipes including
 single wall corrugated and double wall corrugated pipes for cable
 protection, sewer drainage and structural post-tensioning applications.
 Apart from being a well-established corrugated pipe supplier, Jagannath
 Industries is also into manufacture of duct accessories like pipe
 couplers, push fit coupler, end plug, end cap and duct cable sealing plug
 and warning tape in India. We can supply the finest range of high density
 polyethylene pipe polymers in various sizes according to the needs of our
 customers. For more http://www.jagannathindustries.co.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] #26154 [Obfuscation/BridgeDB]: Remove apt-get update from BridgeDB's .travis.yml to avoid SHA1 signature error

[Tor Bug Tracker & Wiki]

#26154: Remove apt-get update from BridgeDB's .travis.yml to avoid SHA1 
signature
error
--+---
 Reporter:  isis  |  Owner:  phw
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  bridgedb-ci ci|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:  Sponsor19
--+---
Changes (by phw):

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


Comment:

 At a second glance, the error in isis's build was not caused by the "weak
 digest" problem (which was only a warning), but rather by:
 {{{
 E: Failed to fetch http://mirror.jmu.edu/pub/ubuntu/dists/trusty-
 updates/universe/i18n/Translation-en  Writing more data than expected
 (243993 > 243863)
 }}}
 This problem seems to have disappeared, which is good.

 [https://travis-ci.org/NullHypothesis/bridgedb/jobs/519417613#L568 A
 recent build of mine] still has the "weak digest" warning, though. Since
 it's just a warning, it doesn't affect our builds, which is why I'm
 closing 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] #30171 [Applications/Tor Browser]: Always accepting third party cookies seems to break first party isolation

[Tor Bug Tracker & Wiki]

#30171: Always accepting third party cookies seems to break first party 
isolation
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201904, tbb-   |  Actual Points:
  linkability|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 Replying to [comment:3 mcs]:
 >... as far as I know — in recent versions of Tor Browser there is no GUI
 to allow someone to set `privacy.firstparty.isolate` to false

 And no GUI for it (or RFP) in Firefox either: upstream FYI
 - https://bugzilla.mozilla.org/show_bug.cgi?id=1397624 - FPI gui
 - https://bugzilla.mozilla.org/show_bug.cgi?id=1404017 - RFP gui

 This UI is a long way off, so you'll be sweet until at least ESR76

--
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:  asn   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => asn


--
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:  nickm |Sponsor:
--+
Changes (by asn):

 * reviewer:   => nickm


--
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] #30151 [Core Tor/Tor]: Fix memory leak in tor-resolve

[Tor Bug Tracker & Wiki]

#30151: Fix memory leak in tor-resolve
+
 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:  040-backport??  |  Actual Points:
Parent ID:  #30146  | Points:
 Reviewer:  catalyst|Sponsor:
+
Changes (by asn):

 * reviewer:   => catalyst


--
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:  nickm|Sponsor:
-+-
Changes (by asn):

 * reviewer:   => nickm


--
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] #30149 [Core Tor/Tor]: Fix "medium" and "low" impact coverity false positives outside of tests.

[Tor Bug Tracker & Wiki]

#30149: Fix "medium" and "low" impact coverity false positives outside of tests.
--+
 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:
Parent ID:  #30146| Points:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => ahf


--
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] #30148 [Core Tor/Tor]: Fix infrequent, unlikely memory leak on failure to create keys directory

[Tor Bug Tracker & Wiki]

#30148: Fix infrequent, unlikely memory leak on failure to create keys directory
-+-
 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:  034-backport 035-backport|  Actual Points:
  040-backport   |
Parent ID:  #30146   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by asn):

 * reviewer:   => mikeperry


--
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] #30120 [Core Tor/Tor]: pre-commit.git-hook doesn't check for changes files correctly.

[Tor Bug Tracker & Wiki]

#30120: pre-commit.git-hook doesn't check for changes files correctly.
--+
 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:
Parent ID:| Points:  0
 Reviewer:  ahf   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => ahf


--
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] #30147 [Core Tor/Tor]: Fix "high-impact" coverity false-positive warnings outside of tests.

[Tor Bug Tracker & Wiki]

#30147: Fix "high-impact" coverity false-positive warnings outside of tests.
--+
 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:  .1
Parent ID:  #30146| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by asn):

 * reviewer:   => mikeperry


--
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] #30114 [Core Tor/Tor]: Also fetch tor-github when we git-pull-all.sh

[Tor Bug Tracker & Wiki]

#30114: Also fetch tor-github when we git-pull-all.sh
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  git-scripts, fast-fix  |  Actual Points:  0.1
Parent ID: | Points:  0.1
 Reviewer:  nickm  |Sponsor:
---+
Changes (by asn):

 * reviewer:   => nickm


--
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] #30109 [Core Tor/Tor]: Document that MapAddress is automatically strict, but does not handle redirects

[Tor Bug Tracker & Wiki]

#30109: Document that MapAddress is automatically strict, but does not handle
redirects
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, security-low, tor-|  Actual Points:  0.3
  client, tor-exit, 040-backport |
Parent ID:  #29989   | Points:  0.1
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by asn):

 * reviewer:   => mikeperry


--
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] #30112 [Core Tor/Tor]: Fix outdated comments in dirserv_read_measured_bandwidths()

[Tor Bug Tracker & Wiki]

#30112: Fix outdated comments in dirserv_read_measured_bandwidths()
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  doc, comment, technical-debt, tor-   |  Actual Points:  0.1
  bwauth |
Parent ID:   | Points:  0.1
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by asn):

 * reviewer:   => mikeperry


--
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] #30092 [Core Tor/Tor]: Add a probability-to-apply field for circuitpadidng machines

[Tor Bug Tracker & Wiki]

#30092: Add a probability-to-apply field for circuitpadidng machines
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 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:  0.5
  padding, 041-proposed  |
Parent ID:  #28634   | Points:  2
 Reviewer:  asn  |Sponsor:
 |  Sponsor2-can
-+-
Changes (by asn):

 * reviewer:   => asn


--
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] #30091 [Core Tor/Tor]: Unify parsing code for control.c

[Tor Bug Tracker & Wiki]

#30091: Unify parsing code for control.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  3
Parent ID:  #29210| Points:  3
 Reviewer:  catalyst  |Sponsor:  Sponsor31-can
--+
Changes (by asn):

 * reviewer:   => catalyst


--
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] #29209 [Core Tor/Tor]: Reduce visibility of more data type internals

[Tor Bug Tracker & Wiki]

#29209: Reduce visibility of more data type internals
+--
 Reporter:  nickm   |  Owner:  (none)
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt refactoring  |  Actual Points:  3.5
Parent ID:  | Points:  15
 Reviewer:  nickm   |Sponsor:  Sponsor31-can
+--
Changes (by asn):

 * reviewer:   => nickm


--
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] #29223 [Core Tor/Tor]: List canonical abbreviations to use in Tor functions and identifiers

[Tor Bug Tracker & Wiki]

#29223: List canonical abbreviations to use in Tor functions and identifiers
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .7
Parent ID:| Points:  1
 Reviewer:  teor  |Sponsor:  Sponsor31-must
--+
Changes (by asn):

 * 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] #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:  teor |Sponsor:
-+-
Changes (by asn):

 * 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] #29136 [Core Tor/Tor]: PT_LOG and PT_STATUS event fields unspecifed

[Tor Bug Tracker & Wiki]

#29136: PT_LOG and PT_STATUS event fields unspecifed
--+
 Reporter:  atagar|  Owner:  atagar
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-pt  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:  Sponsor19-can
--+
Changes (by asn):

 * reviewer:   => ahf


--
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:  asn   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => asn


--
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] #29034 [Core Tor/Tor]: circuit: Cleanup an HS circuit when it is being re-purposed

[Tor Bug Tracker & Wiki]

#29034: circuit: Cleanup an HS circuit when it is being re-purposed
-+-
 Reporter:  dgoulet  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs-reachability, 029-backport-   |  Actual Points:
  maybe, 034-backport-maybe, 035-backport,   |
  040-backport, postfreeze-ok|
Parent ID:  #29995   | Points:  3
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * reviewer:   => asn


--
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] #27821 [Core Tor/Tor]: HTTPTunnelPort "405 Method Not Allowed" page should say "this is not an HTTP Proxy"

[Tor Bug Tracker & Wiki]

#27821: HTTPTunnelPort "405 Method Not Allowed" page should say "this is not an
HTTP Proxy"
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by asn):

 * 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] #30171 [Applications/Tor Browser]: Always accepting third party cookies seems to break first party isolation

[Tor Bug Tracker & Wiki]

#30171: Always accepting third party cookies seems to break first party 
isolation
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201904, tbb-   |  Actual Points:
  linkability|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:2 acat]:
 > Is this pref syncing still logic necessary? If that's not the case, here
 is a patch which just removes this dependency between those two prefs,
 which should solve this issue:
 https://github.com/acatarineu/torbutton/commit/30171

 The patch looks good to me and Kathy (brade). Georg should confirm, but we
 think you are correct that the syncing logic is no longer necessary
 (especially since — as far as I know — in recent versions of Tor Browser
 there is no GUI to allow someone to set `privacy.firstparty.isolate` to
 false).

--
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 Jaym):

 Replying to [comment:3 arma]:
 > I believe that we are currently doing things as intended. That is, I
 think when we built the thing that is happening now, we meant to build it
 that way.
 >
 > But I agree with you that we should consider changes. See ticket #11327
 for what I think is the same ticket as this one (and even mentions the
 same issue with the Fast flag too, as Aaron points out).
 >
 > The problem stems from the fact that we deployed the bwauth measurement
 concept, but then only some authorities started measuring, which creates
 an imbalance where some authorities are more important (and more
 influential) than others.

 Allow me to draw a parallel: I see the Tor ecosystem a bit like a
 representative but auditable democracy, where some trusted people vote
 upon inputs. This problem looks like if one of the elected individuals was
 casting vote over project/law that they did not even read. It sounds like
 the trusted person does not make an educated opinion about the question
 but comply with (potentially) malicious party to cast an uneducated vote.
 If such a thing was verifiable IRL, that would really be upsetting no?

 That's why I wonder if we should not make uneducated opinions to back off
 for this kind of feature. And as you said, it creates imbalance. Yet, we
 could come up with some rules like if "half of the trustees have educated
 opinions on security features, let's trust them". That looks reasonable
 and fairly easy to implement.

--
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.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  nickm-merge, consider-backport-  |  Actual Points:  0.1
  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 nickm):

 * milestone:  Tor: 0.4.1.x-final => Tor: 0.3.5.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] #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:
-+-

Comment (by nickm):

 Teor, will this conflict with any other pending test-network changes?  If
 not, I'm happy to merge 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] #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:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 (It is not by an means urgent)

--
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] #29315 [Metrics/Website]: Write down guidelines for adding new stats

[Tor Bug Tracker & Wiki]

#29315: Write down guidelines for adding new stats
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_revision
 Priority:  Very High|  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:  irl  |Sponsor:
-+

Comment (by irl):

 I would like for these systems to be as open/transparent as is possible.
 The demarcation between a system that collects metrics and Tor Metrics
 should not just be for Tor Metrics. Anyone should be able to do what Tor
 Metrics does. This means that services publish data, and we pull from the
 service.

 It does not need to be a web server. If there is not already a webserver
 then a Gopher server or TCP port that dumps out the document are also fine
 as far as I'm concerned, maybe karsten has other opinions.

 Increasingly I'm thinking that the Tor directory protocol meta format is a
 good format to have metrics in. We already have parsers for these that are
 fast and efficient, and it's easier to detect errors due to the strict
 format (even if #30105 and similar things sometimes slip through). The
 document format also provides for signing of documents, which I'd like to
 see more of our data sources doing. #29624 is looking at defining a new
 format for exit lists, and is using the meta format with Ed25519
 signature.

--
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] #29696 [Metrics/Statistics]: Fix platform dependencies in data-processing modules

[Tor Bug Tracker & Wiki]

#29696: Fix platform dependencies in data-processing modules
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 I have not been able to test this yet with metrics-test, but the commits
 make sense.

 I think we can merge this. I'll leave it to you to decide if you want to
 wait for me to run metrics-test though.

--
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] #30187 [Core Tor/Tor]: 100% cpu usage in winthreads tor_cond_wait

[Tor Bug Tracker & Wiki]

#30187: 100% cpu usage in winthreads tor_cond_wait
--+
 Reporter:  bolvan|  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:
 Keywords:  windows 035-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 One possible fix here would be to use ConditionVariable instead; it's been
 in Windows since Vista.

 If we don't that route, here is a part that looks suspicious to me: the
 generation count getting stuck at 28 suggests to me that we are using
 generation wrong.  In any case, we should really be either waking up or
 sleeping with each time through the loop, I think.

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