[tor-bugs] #30317 [Obfuscation/BridgeDB]: Update howto on https://bridges.torproject.org/ to take mobile Tor Browser into account

[Tor Bug Tracker & Wiki]

#30317: Update howto on https://bridges.torproject.org/ to take mobile Tor 
Browser
into account
--+
 Reporter:  gk|  Owner:  sysrqb
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:  tbb-parity
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor Browser on Android is a thing and will be even more though shortly
 when we'll release the first stable release. However, the instructions on
 https://bridges.torproject.org/howto are desktop-only. We need to adapt
 the text so that mobile Tor Browser users need to know as well how they
 should add bridges obtained to their Tor Browser.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30166 [Applications/Tor Browser]: If custom bridges are specified, only use those bridges for connecting

[Tor Bug Tracker & Wiki]

#30166: If custom bridges are specified, only use those bridges for connecting
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 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 gk):

 Replying to [comment:8 sisbell]:
 > I updated the TOPL and android-tor-service code to fix this issue:
 >
 > https://github.com/sisbell/tor-android-
 service/commit/30a7a83c5e715eb7ef739870bc0ff615ad52daeb
 >
 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/061b7e52310279cb70a125819d7abed8da66bfbe
 >
 > I verified with Orbot app that it is picking up user-defined bridges
 (using one I pulled from torproject bridges site). When the user does not
 define a bridge but enables bridges, I verified that it is using one of
 the random bridges during startup. The PT entries are also in the torrc
 file.
 >
 > The one case I'm not certain of (and the commits above don't handle), is
 if a user specifies a bridge type (like obfs4) as the first field in the
 'Bridge Addresses' TextField. Is this allowed?

 Yes. If you e.g. test on https://bridges.torproject.org and obtain obfs4
 bridges that way the idea is to copy those lines into your Tor Browser and
 the correct bridges are picked up. (see the howto for instructions, which
 is for now only for desktop, though: https://bridges.torproject.org/howto
 and the bridge options at https://bridges.torproject.org/options).

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

Re: [tor-bugs] #30315 [Applications/Tor Browser]: Unable to get a new bridge from TOR

[Tor Bug Tracker & Wiki]

#30315: Unable to get  a new bridge from TOR
--+---
 Reporter:  SpicyOnion|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:  Bridge|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Yes, this looks good. BridgeDB won't give you out new bridges every time
 you request a new one as that way attackers could easily enumerate all the
 bridges available and block them. (Although it used to give out three
 bridges per request, but maybe there are not enough in the pool to do so
 currently).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30223 [Applications/Tor Browser]: Noscript "Disable restrictions for this tab" no longer working as expected

[Tor Bug Tracker & Wiki]

#30223: Noscript "Disable restrictions for this tab" no longer working as 
expected
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 ma1, any idea?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30314 [Core Tor/Tor]: Relay became Guard with less than 2 weeks of existence

[Tor Bug Tracker & Wiki]

#30314: Relay became Guard with less than 2 weeks of existence
--+---
 Reporter:  crimson_king  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gaba):

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


Comment:

 Thanks crimson_king!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30314 [Core Tor/Tor]: Relay became Guard with less than 2 weeks of existence

[Tor Bug Tracker & Wiki]

#30314: Relay became Guard with less than 2 weeks of existence
--+
 Reporter:  crimson_king  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by crimson_king):

 Thank you for that clarification. I believe this ticket can be closed now.

 After re-reading [https://blog.torproject.org/lifecycle-new-relay], I
 realized the uptime requirement for a relay to become a Guard isn't the
 only thing helping to keep it from being used maliciously.

 It's not my relay.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30166 [Applications/Tor Browser]: If custom bridges are specified, only use those bridges for connecting

[Tor Bug Tracker & Wiki]

#30166: If custom bridges are specified, only use those bridges for connecting
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 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 sisbell):

 I updated the TOPL and android-tor-service code to fix this issue:

 https://github.com/sisbell/tor-android-
 service/commit/30a7a83c5e715eb7ef739870bc0ff615ad52daeb
 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/061b7e52310279cb70a125819d7abed8da66bfbe

 I verified with Orbot app that it is picking up user-defined bridges
 (using one I pulled from torproject bridges site). When the user does not
 define a bridge but enables bridges, I verified that it is using one of
 the random bridges during startup. The PT entries are also in the torrc
 file.

 The one case I'm not certain of (and the commits above don't handle), is
 if a user specifies a bridge type (like obfs4) as the first field in the
 'Bridge Addresses' TextField. Is this allowed?

 I also still need to test this on within the tor-browser-build.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30223 [Applications/Tor Browser]: Noscript "Disable restrictions for this tab" no longer working as expected

[Tor Bug Tracker & Wiki]

#30223: Noscript "Disable restrictions for this tab" no longer working as 
expected
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Sorry for delay.

 Tested all versions from 10.2.2 and the issue was introduced in the last
 version, 10.6.1, Apr 10. Could not replicate the issue in regular Firefox
 although I am not 100% sure all the settings were exactly the same.

 Have not got knowledge to point out which of these changes caused the
 issue:

 v 10.6.1
 =
 x Make RequestGuard's header processing synchronous as needed
 x Fixed inconsistencies handling browser-internal URLs
 x Fixed resetting options works just once per session
   (defaults reference current settings) - issue #69
 x [Locale] Updated Transifex-managed locales (de, fr, it, tr, nl)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30282 [Core Tor/Stem]: bandwidth_file_headers doesn't seem to be working

[Tor Bug Tracker & Wiki]

#30282: bandwidth_file_headers doesn't seem to be working
---+
 Reporter:  tom|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Thanks tom! This was a confusing one. It turns out you found a tor bug -
 reaching out to the network team: #30316

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30316 [Core Tor/Tor]: Vote's 'bandwidth-file-headers' is in wrong order

[Tor Bug Tracker & Wiki]

#30316: Vote's 'bandwidth-file-headers' is in wrong order
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

 * Attachment "moria1_vote.txt" added.

 Cropped copy of moria1's vote.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30316 [Core Tor/Tor]: Vote's 'bandwidth-file-headers' is in wrong order

[Tor Bug Tracker & Wiki]

#30316: Vote's 'bandwidth-file-headers' is in wrong order
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi network team. Moria1's present vote places its "bandwidth-file-headers"
 in the wrong location.

 Tor's dir-spec says: "**Status documents contain a preamble, an authority
 section, a list of router status entries, and one or more footer
 signature, in that order.**"

 The trouble is that our bandwidth-file-headers field is specified as being
 part of the preamble, whereas moria1 places it **after** its authority
 section. Header fields appear in the following order...

 * flag-thresholds (preamble)
 * params (preamble)
 * dir-source (authority section)
 * contact (authority section)
 * shared-rand-participate (authority section)
 * shared-rand-commit (authority section, multiple)
 * shared-rand-previous-value (authority section)
 * shared-rand-current-value (authority section)
 * **bandwidth-file-headers (preamble)**
 * dir-key-certificate-version (key certificate)
 * ... etc...

 As a result Stem does not parse this field: #30282

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2, tor-spec   |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Okay! I have some tiny requests about function names, and I still think
 that code outside relay_crypto shouldn't access its fields.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt control-port  |  Actual Points:
Parent ID:  #29210   | Points:  3
 Reviewer:  nickm|Sponsor:  Sponsor31-can
-+-

Comment (by nickm):

 This still lgtm; let's merge it once #30091 is 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] #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
+--

Comment (by nickm):

 This strategy looks good!

 Also, let's change the identifier so that it's more clearly not reserved;
 I'm not sure that the `## _ ## _private` trick is actually any more legal
 than `##__private`. Instead let's use something like `x ##
 _MODULE_NAME_private_field` maybe?

 The `pvt` version is fine with me.

 If this is going to be a shared macro, lib/cc seems like a decent place
 for it, but I'm not sure we want to use this same macro everywhere: I
 think we'd like to mangle member names differently depending on which
 module owns them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30029 [Applications/Tor Browser]: Objective 2, Activity 5: POC for Human-memorable addresses for .onion services

[Tor Bug Tracker & Wiki]

#30029: Objective 2, Activity 5: POC for Human-memorable addresses for .onion
services
--+
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #30281| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+

Comment (by cypherpunks):

 Responding to the title of this ticket, which includes 'Human-memorable
 addresses for .onion services': we must be careful to consider Zooko's
 trilemma, which argues that names cannot be human-meaningful, global, and
 secure.  In particular, we must not seek to re-implement something like
 DNS, whose requirement of universality implies the creation of hierarchy,
 authorities, and control points, all of which undermine a salient benefit
 of onion services, the ability for all individuals to create and use them
 freely.  Consider the implicit role for authorities in any
 [https://sockpuppet.org/blog/2015/01/15/against-dnssec/ effort to secure
 DNS].

 As an alternative, we might consider adopting an approach more like
 [http://www.skyhunter.com/marcs/petnames/IntroPetNames.html Petnames],
 which encourages individuals to create and use their own meaningful names
 for opaque identifiers, without requiring everyone to agree.

 We might also want to create tools to help users track the provenance of
 addresses learned via introductions, so that they would be empowered to
 make decisions based upon the trustworthiness of those who provided
 introductions.  We could likewise encourage individual users to establish
 multiple identities for their own services this way and use different
 addresses based upon context.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30315 [Applications/Tor Browser]: Unable to get a new bridge from TOR

[Tor Bug Tracker & Wiki]

#30315: Unable to get  a new bridge from TOR
+--
 Reporter:  SpicyOnion  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Critical
 Keywords:  Bridge  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 This is how the bridge reads under:

 Request a bridge from torproject.org
 obs4 93.147.4.253:39339 C14E02fd5612975658413657c7b2f18371d17f1...

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

Re: [tor-bugs] #30175 [Applications/Tor Browser]: Manually whitelist extensions removed from AMO for purely political reasons in Tor Browser to fight Mozilla's censorship

[Tor Bug Tracker & Wiki]

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

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


Comment:

 I said it's a won't fix. Leave this bug closed, thanks!

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