[tor-bugs] #31411 [Webpages/Support]: trac having a "two generals" problem

[Tor Bug Tracker & Wiki]

#31411: trac having a "two generals" problem
--+--
 Reporter:  nullbulous|  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Very Low  |  Component:  Webpages/Support
  Version:|   Severity:  Minor
 Keywords:  trac, capcha  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 when i created an account to make my bug reports trac identified me as
 spam [? probably set to default here] and so made me do a captcha. after
 doing captcha i got two little infobars. one said capcha failed, one said
 success account created. somethings getting hung up in the inbetween here
 and somebody aint getting their "message received" message. now im an
 amateur so i have NO clue as to the root of the issue but it sure is a
 weird one from the outset

--
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] #31410 [Core Tor]: issues following troubleshooting guides re:"the proxy server is refusing connections"

[Tor Bug Tracker & Wiki]

#31410: issues following troubleshooting guides re:"the proxy server is refusing
connections"
-+--
 Reporter:  nullbulous   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor
  Version:  Tor: unspecified |   Severity:  Critical
 Keywords:  program nonfunction  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 the troubleshooting guides all inform me that when i first instal and open
 tor there should be a wizard/dialogue box.
 there is no wizard
 there is no dialogue box. it just unpack and asks if i want to run it
 then if i say yes it just opens.
 can not find in settings ANY option for setting a bridge or anything of
 the like.
 i am completely baffled. tor is completely nonfunctional to me because of
 this.
 there is a 60% chance im missing something big and am just a barely
 computer literate fool when it comes to this but like? when i fail step
 one of the troubleshooting guide hosted on the FAQ i tend to feel like its
 Probably not actually my fault.

 any advice or help welcome. feel free to be an ass about it if i've been
 an idiot.

--
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] #31409 [Webpages/Website]: Tor Project support; TBB how to verify signature instructions incorrect for Windows.

[Tor Bug Tracker & Wiki]

#31409: Tor Project support; TBB how to verify signature instructions incorrect 
for
Windows.
+--
 Reporter:  0brand  |  Owner:  hiro
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Webpages/Website
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Verifing Tor Browser for Windows at [https://support.torproject.org/tbb
 /how-to-verify-signature/] gives the incorrect TBB package name for the
 Cli verification.

 I download Windows TBB package from Tor Project downloads page:

 `https://www.torproject.org/dist/torbrowser/8.5.4/torbrowser-install-
 win64-8.5.4_en-US.exe`

 Verification page instructions:

 For Windows users:

 `gpgv --keyring .\tor.keyring Downloads\torbrowser-install-win64-8.5.4_en-
 US.exe.asc Downloads\torbrowser-win64-install-8.5.4_en-US.exe`


 **Correct package name**


 `win64-install` should be switched to `install-win64`

--
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] #31088 [Core Tor/Tor]: Check IPv4 and IPv6 private addresses in descriptors, first hops, and extends

[Tor Bug Tracker & Wiki]

#31088: Check IPv4 and IPv6 private addresses in descriptors, first hops, and
extends
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, tor-client, tor-|  Actual Points:
  dirauth|
Parent ID:  #24403   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 A test for `dirserv_router_has_valid_address()` has been implemented.
 However, `dirserv_router_has_valid_address()` does not mark null IPv6 as
 internal as relays may not have IPv6 addresses.

 An internal IPv6 address in `dirserv_router_has_valid_address()` logic is
 when it passes `tor_addr_is_internal()` and isn't null (so we don't flag
 IPv4-only relays as internal).

 A `circuit_extend()` test would not be trivial because it would involve
 circuit extending logic, but this is tested in the chutney tests.
 `circuit_extend()` is only called in
 `connection_edge_process_relay_cell()` on these use cases:

 {{{
 case RELAY_COMMAND_EXTEND:
 case RELAY_COMMAND_EXTEND2:
 }}}

 And I did not see these be tested outside of chutney.

 Setting as 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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by pospeselr):

 * Attachment "torNetworkIcon.svg" added.

 temp stand-in icon

--
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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--

Comment (by pospeselr):

 Hey antonela, I'll need a flat svg version of the Tor Browser icon please
 :)

 Here's the 'gear' settings icon as an example:
 https://share.riseup.net/#0hzHYFROPIbENP_d45_IiA

--
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] #24403 [Core Tor/Tor]: Propose and implement IPv6 ORPort reachability checks on relays

[Tor Bug Tracker & Wiki]

#24403: Propose and implement IPv6 ORPort reachability checks on relays
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #5940| Points:  48
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * points:   => 48


--
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] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 Replying to [comment:2 phw]:
 > Replying to [comment:1 hiro]:
 > > There is also another aspect to consider, in the case of a service
 like gettor, monitoring the https endpoint will only give us some info
 about the static html we are serving with apache. Gettor itself (the
 service sending emails) is a twisted service instead.
 > [[br]]
 > Gotcha. We have a similar problem with BridgeDB because it is exposed
 over an Apache reverse proxy and you cannot directly talk to BridgeDB.
 However, if BridgeDB is down, bridges.torproject.org responds with an
 internal server error if I remember correctly, so we can still monitor
 BridgeDB despite the reverse proxy, right?

 Should, yes.

 > To monitor BridgeDB, we need to set up an exporter, right?

 In Prometheus, yes. This could be a simple configuration in a "blackbox
 exporter":

 https://github.com/prometheus/blackbox_exporter/

 > > Maybe we can consider an approach in which services expose an http
 endpoint that we can use to know that the service is alive. Otherwise I
 think we could do some other monitoring via nagios checks.
 >
 > I think we already have that for BridgeDB and snowflake's website but
 not for GetTor.

 From what I can tell, we check bridges.torproject.org:

 {{{
   -
 name: bridges.tpo web service
 nrpe: "/usr/lib/nagios/plugins/check_http -H bridges.torproject.org -S
 --string=bridge"
 hosts: polyanthum
 depends: network service - https
 }}}

 We also check onionoo:

 {{{
  # non-tpa services
  
   -
 name: network service - onionoo backend
 nrpe: "/usr/lib/nagios/plugins/tor-check-onionoo 127.0.0.1:8080"
 hostgroups: onionoo-backend
 depends: "process - haproxy - master"
 contacts: +metrics
   -
 name: network service - onionoo varnish
 nrpe: "/usr/lib/nagios/plugins/tor-check-onionoo 127.0.0.1:6081"
 hostgroups: onionoo-backend
 depends: "process - haproxy - master"
 contacts: +metrics
   -
 name: network service - onionoo haproxy
 nrpe: "/usr/lib/nagios/plugins/tor-check-onionoo -s
 onionoo.torproject.org"
 hostgroups: onionoo-backend
 depends: "process - haproxy - master"
 contacts: +metrics
 }}}

 ... but those are all TPA machines, so they can be monitored by Nagios.

--
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] #31232 [Internal Services/Tor Sysadmin Team]: Migrate default snowflake broker (and bridge?) to TPA machines

[Tor Bug Tracker & Wiki]

#31232: Migrate default snowflake broker (and bridge?) to TPA machines
-+-
 Reporter:  cohosh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 alright, added the following to the torproject.net zone:

 {{{
 ; https://trac.torproject.org/projects/tor/ticket/31232
 snowflake-brokerIN  A   37.218.240.96
 snowflake   IN  A   37.218.242.151
 IN  2a00:c6c0:0:151:4:8f94:69f5:7c01
 }}}

 This should propagate through the DNS with time:

 {{{
 root@nevii:~# dig snowflake-broker.torproject.net +short
 37.218.240.96
 root@nevii:~# dig snowflake.torproject.net +short
 37.218.242.151
 root@nevii:~# dig snowflake.torproject.net +short 
 2a00:c6c0:0:151:4:8f94:69f5:7c01
 }}}

 Leaving this ticket open for the rest of the conversation, which is
 probably "do we move stuff to TPA now?"

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

Re: [tor-bugs] #31232 [Internal Services/Tor Sysadmin Team]: Migrate default snowflake broker (and bridge?) to TPA machines

[Tor Bug Tracker & Wiki]

#31232: Migrate default snowflake broker (and bridge?) to TPA machines
-+-
 Reporter:  cohosh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cohosh):

 Replying to [comment:11 anarcat]:
 > sorry for my dumb questions, but should we make those CNAMEs to
 snowflake.bamsoftware.com and so on, or A/ records? if the former, you
 need to ask bamsoftware to make changes, if the latter, you need to ask
 us.
 >
 > i'd assume you want the latter, but wanted to double-check.
 No worries, thanks for asking. We want the latter so that if the IP
 addresses of the broker/bridge have to change for any reason we can make
 those changes.

--
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] #31232 [Internal Services/Tor Sysadmin Team]: Migrate default snowflake broker (and bridge?) to TPA machines

[Tor Bug Tracker & Wiki]

#31232: Migrate default snowflake broker (and bridge?) to TPA machines
-+-
 Reporter:  cohosh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 sorry for my dumb questions, but should we make those CNAMEs to
 snowflake.bamsoftware.com and so on, or A/ records? if the former, you
 need to ask bamsoftware to make changes, if the latter, you need to ask
 us.

 i'd assume you want the latter, but wanted to double-check.

--
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] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Replying to [comment:14 arma]:
 > Replying to [comment:12 cohosh]:
 > > if the client has already sent its upstream bytes, those bytes are
 lost forever and so all subsequent snowflakes will look like they are
 failing even if their connection to the bridge is fine. This is what the
 sequencing layer in #29206 is for.
 >
 > Would it be smart, while we don't have the sequencing layer in place
 yet, for Snowflake to have some keepalive or timeout feature, where it
 notices that it's sent its bytes, and things aren't looking good, and it
 should abort that connection so Tor can try a new one?
 >
 > If we can do it in a simple way, it might help people in the short term.
 And in the long term, we might still need some sort of similar "gosh that
 channel looks like it has failed" feature to know when it's time to launch
 a new one.
 I'm working on #29206 this week. I'll keep this in mind, but the answer
 might be that it's just as fast to go ahead and implement the sequencing
 layer (which is already a very simple version of what we'll actually want
 in the future).

--
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] #31408 [Core Tor/Tor]: torrc : ClientOnionAuthDir after include directives breaks client to v2 services

[Tor Bug Tracker & Wiki]

#31408: torrc : ClientOnionAuthDir after include directives breaks client to v2
services
-+-
 Reporter:  xaho |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  torrc include ClientOnionAuthDir |  Actual Points:
  order  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by xaho):

 n.b. if it matters, all of these 5 services are set with an auth/stealth
 key

--
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] #31408 [Core Tor/Tor]: torrc : ClientOnionAuthDir after include directives breaks client to v2 services

[Tor Bug Tracker & Wiki]

#31408: torrc : ClientOnionAuthDir after include directives breaks client to v2
services
-+-
 Reporter:  xaho |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core
 |  Tor/Tor
  Version:  Tor: 0.4.0.5 |   Severity:  Normal
 Keywords:  torrc include ClientOnionAuthDir |  Actual Points:
  order  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 If I append these two statements to torrc, in this order :

 ClientOnionAuthDir /etc/tor/auth/
 %include /etc/tor/torrc.d/

 and restart tor.service, I can connect to 1 × v3 and 4 × v2 services,
 within seconds.

 But if I reverse their order ( %include first ), I can only connect to the
 v3 service -- all other connections will eventually time out.

 In man, I missed to find any recommandation about ordering these
 statements.

 ( this is on Debian Stretch with torproject's stretch repo )

 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] #29461 [Metrics/CollecTor]: Add a Snowflake module

[Tor Bug Tracker & Wiki]

#29461: Add a Snowflake module
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-august, anti-|  Actual Points:
  censorship-roadmap-september   |
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-

Comment (by cohosh):

 Replying to [comment:7 karsten]:
 > One quick comment on the spec after writing the metrics-lib part: The
 `"snowflake-stats-end"` line should have multiplicity `"[At start, exactly
 once.]"` rather than `"[At most once.]"`. Other than that, everything
 seemed reasonable from a parsing perspective. (I didn't start with the
 CollecTor part, yet.)
 >
 Thanks! Filed a PR for torspec in #31407 with this change.
 > To answer your earlier question above: having just the last 24 hours of
 data might be problematic if the metrics host goes down for, say, a
 weekend. Ideally, there would be at least a week of statistics available.
 Or maybe just accumulate new statistics forever, given the tiny amount of
 statistics per day.
 Okay great, I have a implementation of this in #31376 that will respond
 with all logged metrics data.

--
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] #31376 [Circumvention/Snowflake]: Make a /metrics handle at the snowflake broker for the stats collector

[Tor Bug Tracker & Wiki]

#31376: Make a /metrics handle at the snowflake broker for the stats collector
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics, stats, broker   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor28
-+--
Changes (by cohosh):

 * status:  needs_information => needs_review


Comment:

 After talking to karsten in #29461, here's a better way of providing all
 previously logged metrics:
 https://github.com/cohosh/snowflake/compare/ticket31376_v2

--
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] #31140 [Applications/Tor Browser]: Tor Browser for Android 60.8.0 crash on aarch64

[Tor Bug Tracker & Wiki]

#31140: Tor Browser for Android 60.8.0 crash on aarch64
-+-
 Reporter:  j3tracey |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  TorBrowserTeam201907   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:17 sysrqb]:
 > Replying to [comment:15 sysrqb]:
 > > Maybe: https://bugzilla.mozilla.org/show_bug.cgi?id=1455709
 >
 > This is looking positive. Debug build fully bootstraps and the browser
 works. Now building a release build and will test that.

 Yep, not related at all.

 {{{
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 24193]
 0x00c98570 in ?? ()
 (gdb) bt
 #0  0x00c98570 in ?? ()
 #1  0x in ?? ()Program received signal SIGSEGV, Segmentation
 fault.
 [Switching to Thread 24193]
 0x00c98570 in ?? ()
 (gdb) bt
 #0  0x00c98570 in ?? ()
 #1  0x in ?? ()
 (gdb) info all-reg
 r0 0xb6d7a550   3067585872
 r1 0xb6d7a550   3067585872
 r2 0xfa545390   4199830416
 r3 0xb9c5a470   3116737648
 r4 0x1f595f832871928
 r5 0x1  1
 r6 0x30d5c8851207304
 r7 0x0  0
 r8 0xb9c5a368   3116737384
 r9 0x2f65e4049700416
 r100xffe6   4294967270
 r110x30d634851209032
 r120xb7232a60   3072535136
 sp 0x0  0x0
 lr 0x0  0
 pc 0xc98570 0xc98570
 f0 0(raw 0xaae3be70)
 f1 0(raw 0xaae3be70)
 f2 0(raw 0xaae3be70)
 f3 0(raw 0xaae3be70)
 f4 0(raw 0xaae3be70)
 f5 0(raw 0xaae3be70)
 f6 0(raw 0xaae3be70)
 f7 0(raw 0xaae3be70)
 fps0x0  0
 cpsr   0x2000   536870912
 }}}


 But, my current guess is this garbage is due to using a 32-bit adb with a
 64-bit binary.

--
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] #30924 [Core Tor/Tor]: hs-v3: Implement proposal 305 - ESTABLISH_INTRO Cell DoS Defense Extension

[Tor Bug Tracker & Wiki]

#30924: hs-v3: Implement proposal 305 -  ESTABLISH_INTRO Cell DoS Defense 
Extension
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-spec, prop305, network-  |  Actual Points:
  team-roadmap-august|
Parent ID:  #2   | Points:  7
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review
 * reviewer:   => asn


Comment:

 Branch: ticket30924_042_01
 PR: https://github.com/torproject/tor/pull/1232

 This is working well with chutney. On today git master, the HS won't send
 the extension since no relay supports it.

 The service side only honors the torrc options, it does NOT look at the
 consensus parameters. The intro point is the one looking at those if the
 cell extension is not seen.

--
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] #31392 [Core Tor/Tor]: Explain Padding 1 and 2 in tor-spec.txt

[Tor Bug Tracker & Wiki]

#31392: Explain Padding 1 and 2 in tor-spec.txt
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:  #31356   | Points:  0.1
 Reviewer:  mikeperry|Sponsor:  Sponsor2
-+
Changes (by asn):

 * status:  new => needs_review
 * reviewer:   => mikeperry


Comment:

 Please see https://github.com/torproject/torspec/pull/89 .

--
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] #31407 [Core Tor/Tor]: Create a broker spec for metrics collection

[Tor Bug Tracker & Wiki]

#31407: Create a broker spec for metrics collection
--+--
 Reporter:  cohosh|  Owner:  cohosh
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  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] #31407 [Core Tor/Tor]: Create a broker spec for metrics collection

[Tor Bug Tracker & Wiki]

#31407: Create a broker spec for metrics collection
--+--
 Reporter:  cohosh|  Owner:  cohosh
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cohosh):

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


--
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] #31407 [Core Tor/Tor]: Create a broker spec for metrics collection

[Tor Bug Tracker & Wiki]

#31407: Create a broker spec for metrics collection
--+
 Reporter:  cohosh|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cohosh):

 * Attachment "0001-Added-snowflake-broker-metrics-spec.patch" added.


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

[tor-bugs] #31407 [Core Tor/Tor]: Create a broker spec for metrics collection

[Tor Bug Tracker & Wiki]

#31407: Create a broker spec for metrics collection
--+--
 Reporter:  cohosh|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We're in the process of creating a module for the collection of snowflake
 metrics (#21315, #29461). We need a better place to put the spec for the
 metrics data output by the snowflake broker than a comment in the source
 code (see https://trac.torproject.org/projects/tor/ticket/29461#comment:5)

 A spec for the broker will also be useful to expand upon later to specify
 how the broker interacts with other pieces of either Snowflake or the Tor
 ecosystem in the case that the broker assumes more of the responsibilities
 of BridgeDB.

--
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] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=2
---+
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.4.0.5
 Severity:  Normal | Resolution:
 Keywords:  wtf-pad, 041-must  |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  asn|Sponsor:  Sponsor2
---+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me!

 I tested this both on the real network (and verified that a client with
 this patch will consider 041-alpha relays as unsupportive of padding), and
 also on chutney (and verified that padding will flow between a client and
 relays with this patch).

 Thanks for the work everyone!

--
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] #29461 [Metrics/CollecTor]: Add a Snowflake module

[Tor Bug Tracker & Wiki]

#29461: Add a Snowflake module
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-august, anti-|  Actual Points:
  censorship-roadmap-september   |
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-

Comment (by karsten):

 One quick comment on the spec after writing the metrics-lib part: The
 `"snowflake-stats-end"` line should have multiplicity `"[At start, exactly
 once.]"` rather than `"[At most once.]"`. Other than that, everything
 seemed reasonable from a parsing perspective. (I didn't start with the
 CollecTor part, yet.)

 To answer your earlier question above: having just the last 24 hours of
 data might be problematic if the metrics host goes down for, say, a
 weekend. Ideally, there would be at least a week of statistics available.
 Or maybe just accumulate new statistics forever, given the tiny amount of
 statistics per day.

--
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] #24653 [Applications/Tor Browser]: Apply security slider improvements made on desktop back to mobile

[Tor Bug Tracker & Wiki]

#24653: Apply security slider improvements made on desktop back to mobile
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-torbutton, tbb-  |  Actual Points:
  security-slider, tbb-parity,   |
  TorBrowserTeam201908R  |
Parent ID:  #10760   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * status:  new => needs_review
 * keywords:
 tbb-mobile, tbb-torbutton, tbb-security-slider, tbb-parity,
 TorBrowserTeam201908
 =>
 tbb-mobile, tbb-torbutton, tbb-security-slider, tbb-parity,
 TorBrowserTeam201908R


Comment:

 Patches in https://github.com/acatarineu/torbutton/commits/24653 (last two
 commits) and https://github.com/acatarineu/tor-browser/commit/24653.

--
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] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 @cohosh: did you try to setup a Firefox WebExt 0.0.9 vs 0.0.8 test to
 determine if it's not due to the recent patch in #31100?

--
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] #31164 [Circumvention]: Set up default bridge at Karlstad University

[Tor Bug Tracker & Wiki]

#31164: Set up default bridge at Karlstad University
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges|  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by ln5):

 I've been using
 {{{
 EntryStatistics 1
 ExtraInfoStatistics 1
 }}}
 for gathering more metrics and
 {{{
 HeartbeatPeriod 1 hour
 }}}
 for my own sake.

 I've been using various `ServerTransportOptions`, most notably `iat-mode`
 to obfs4, by request from dcf and others.

 Some of the obfs bridges I run have `AssumeReachable 1` together with a
 local IP filter blocking traffic to the ORPort, to not expose the ORPort.

--
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] #31322 [Applications/Tor Browser]: Fix about:tor assertion failure in esr68 linux debug builds

[Tor Bug Tracker & Wiki]

#31322: Fix about:tor assertion failure in esr68 linux debug builds
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 About about: pages: https://bugzilla.mozilla.org/show_bug.cgi?id=1430748

--
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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--

Comment (by acat):

 >I'm also personally in favor of nuking the existing 'Network Settings' in
 the General panel. For most users, it's just an easily accessible footgun.
 I think we can expect that users doing clever things with a custom Tor
 setup should be clever enough to edit network.proxy.socks and
 network.proxy.socks_port directly.
 +1

 >If we keep Firefox's Network Settings in General Preferences, do we still
 need local proxy settings in Tor Network Settings?
 If I'm not mistaken, proxy in Firefox Network settings means the proxy
 that Firefox will use to connect to Internet (which should always be the
 local Tor client), while proxy in Tor Network Settings means the proxy
 that the Tor client will use to connect to the Internet.

 So I think yes, if we were to keep Firefox Network settings, I think we
 still would need local proxy in Tor Network Settings (unless we want to
 repurpose the Firefox proxy settings UI, which I think might be
 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