Re: [tor-bugs] #18809 [Core Tor/Tor]: Handle linked connections better during bootstrap

[Tor Bug Tracker & Wiki]

#18809: Handle linked connections better during bootstrap
-+-
 Reporter:  teor |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  teor |  Actual Points:
 | Points:
 |Sponsor:
-+-
Changes (by andrea):

 * owner:   => andrea
 * status:  needs_review => 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] #18849 [Core Tor/Tor]: Fix router_picked_poor_directory_log() before 0.2.8 release

[Tor Bug Tracker & Wiki]

#18849: Fix router_picked_poor_directory_log() before 0.2.8 release
-+-
 Reporter:  teor |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:
 |Sponsor:
-+-
Changes (by andrea):

 * status:  new => assigned
 * owner:   => andrea


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

[Tor Bug Tracker & Wiki]

#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  dgoulet, arma|  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by andrea):

 * owner:   => andrea
 * status:  needs_review => 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] #18930 [Core Tor/Tor]: Segmentation fault: entry->parsed->intro_nodes

[Tor Bug Tracker & Wiki]

#18930: Segmentation fault: entry->parsed->intro_nodes
-+-
 Reporter:  juha |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Critical |  0.2.8.x-final
 Keywords:  tor2web, crash, must-fix-|Version:  Tor:
  before-028-rc, TorCoreTeam201605   |  0.2.7.1-alpha
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by andrea):

 * status:  needs_information => assigned
 * owner:   => andrea


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18656 [Core Tor/Tor]: Relay publishing malformed 'dirreq-v3-reqs' line

[Tor Bug Tracker & Wiki]

#18656: Relay publishing malformed 'dirreq-v3-reqs' line
-+-
 Reporter:  atagar   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  029-proposed, memory-corruption, |Version:  Tor:
  TorCoreTeam201605, 029-nickm-unsure|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:
 |Sponsor:
-+-
Changes (by andrea):

 * status:  new => assigned
 * owner:   => andrea


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17427 [Applications/TorBirdy]: Allow preseeding Enigmail options

[Tor Bug Tracker & Wiki]

#17427: Allow preseeding Enigmail options
---+--
 Reporter:  kytv   |  Owner:  ioerror, sukhbir
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by adrelanos):

 I think a generic solution is desirable. Perhaps overwriting these
 variables using User.js and/or about:config. Then it should be hard to
 mess that up inadvertently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #14025 [Applications/TorBirdy]: Make TorBirdy work with SplitGPG setup (qubes os)

[Tor Bug Tracker & Wiki]

#14025: Make TorBirdy work with SplitGPG setup (qubes os)
---+--
 Reporter:  cypherpunks|  Owner:  sukhbir
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by adrelanos):

 Replying to [comment:3 sukhbir]:
 > what would be an easy way to detect that TorBirdy is running in it?

 Check if the tool {{{qvm-run}}} is available on the system.

 We have [https://github.com/QubesOS/qubes-issues/issues/1024 worked
 around] this issue for now, however it's not that great so fixing this
 would be appreciated.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18983 [Applications/Tor Browser]: TBB + Flafox - doesn't work

[Tor Bug Tracker & Wiki]

#18983: TBB + Flafox - doesn't work
--+--
 Reporter:  ikurua22  |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 tbb: doesn't show country icon
 firefox(old): show country code

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

Re: [tor-bugs] #15981 [Applications/Tor Browser]: Message "Tor Browser is already running", when trying to open a link

[Tor Bug Tracker & Wiki]

#15981: Message "Tor Browser is already running", when trying to open a link
--+
 Reporter:  tot-to|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

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


Comment:

 Replying to [comment:3 cypherpunks]:
 > If this interferes with a system firefox, set a unique $LOGNAME for each
 profile, like "export LOGNAME=tor" before you run start-tor-browser.
 I believe that shouldn't happen anymore since the script passes a
 `--class` argument different than Firefox's.

 Also closing this since the ticket is really old, the bug was fixed long
 ago, and the fix seems to work. Duplicates: #15185 #15370 #9344.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #9344 [Applications/Tor Browser]: Cannot set tor browser as default browser nor open any link through it (even command-line)

[Tor Bug Tracker & Wiki]

#9344: Cannot set tor browser as default browser nor open any link through it
(even command-line)
-+-
 Reporter:  ksana|  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.3.x-stable
  Browser|Version:  Tor: 0.2.3.25
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-firefox-patch|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Fixed long ago. Duplicates: #15981 #15185 #15370.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18902 [Core Tor/Tor]: Avoid variable shadowing in Tor

[Tor Bug Tracker & Wiki]

#18902: Avoid variable shadowing in Tor
---+--
 Reporter:  teor   |  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy refactor  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Please be aware that we might take a long time to review, or reject, a
 patch that takes a lot of time to manually verify. It's too easy to
 introduce bugs this way.

 Why not try tools like coccinelle, or a scripting language?
 Most compilers will give you line numbers of shadowing and shadowed
 variables.

 One strategy could be to temporarily change outer and inner names, then
 check using a compiler.
 There is a risk that inner variables will accidentally be changed to the
 outer variable name, but that's the only risk I can see.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18982 [Core Tor/Tor]: Tor should log 1-based hop numbers

[Tor Bug Tracker & Wiki]

#18982: Tor should log 1-based hop numbers
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy logging  |  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+--
Description changed by teor:

Old description:

> The control-spec says hops are 1-based, and we often log "first hop":
> {{{
>   If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
>   circuit as the exit node, rather than the last node in the circuit.
>   Hops are 1-indexed; generally, it is not permitted to attach to hop 1.
> }}}
>
> But the following functions log 0-based hops:
> * choose_good_middle_server
> * onion_extend_cpath (which also logs a 1-based hop message as well)
>
> We need to add 1 to the 0-based hop counts in these functions.

New description:

 The control-spec says hops are 1-based, and we often log "first hop":
 {{{
   If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
   circuit as the exit node, rather than the last node in the circuit.
   Hops are 1-indexed; generally, it is not permitted to attach to hop 1.
 }}}

 But the following functions log 0-based hops:
 * choose_good_middle_server
 * onion_extend_cpath (which also logs a 1-based hop message as well)

 We need to add 1 to the 0-based hop counts in these functions.

 Credit to Xiaofan Li for discovering this 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

[tor-bugs] #18982 [Core Tor/Tor]: Tor should log 1-based hop numbers

[Tor Bug Tracker & Wiki]

#18982: Tor should log 1-based hop numbers
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:  easy logging
Actual Points:|  Parent ID:
   Points:  small |   Reviewer:
  Sponsor:|
--+--
 The control-spec says hops are 1-based, and we often log "first hop":
 {{{
   If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
   circuit as the exit node, rather than the last node in the circuit.
   Hops are 1-indexed; generally, it is not permitted to attach to hop 1.
 }}}

 But the following functions log 0-based hops:
 * choose_good_middle_server
 * onion_extend_cpath (which also logs a 1-based hop message as well)

 We need to add 1 to the 0-based hop counts in these functions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17938 [Metrics/Atlas]: Unable to find my relay

[Tor Bug Tracker & Wiki]

#17938: Unable to find my relay
---+---
 Reporter:  phranck|  Owner:  Frank Gregor
 Type:  defect | Status:  needs_information
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Trivial| Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * component:  Metrics/Globe => Metrics/Atlas


Comment:

 We're shutting down Globe, so changing to the Atlas component.  Admitted,
 Atlas doesn't have this issue yet, but if #15395 gets implemented as I
 suggested a week ago it may have the exact same issue.  Let's only close
 this if we're sure we're not going to run into that issue, because it's
 kinda hard to debug.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17326 [Metrics/Atlas]: Atlas not showing 3-day and 1-week graphs for bytes read/wriiten by node

[Tor Bug Tracker & Wiki]

#17326: Atlas not showing 3-day and 1-week graphs for bytes read/wriiten by node
---+---
 Reporter:  torqc  |  Owner:  phw
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  new => closed
 * resolution:   => duplicate
 * severity:   => Normal


Comment:

 Closing as duplicate of #15453.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15453 [Metrics/Atlas]: Globe's bandwidth graphs over 3 days/1 week do not update for relays running Tor >= 2.5.11

[Tor Bug Tracker & Wiki]

#15453: Globe's bandwidth graphs over 3 days/1 week do not update for relays
running Tor >= 2.5.11
---+-
 Reporter:  gok|  Owner:  phw
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  graphing, ui   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * owner:  isis => phw
 * component:  Metrics/Globe => Metrics/Atlas
 * severity:   => Normal


Comment:

 We're shutting down Globe, but Atlas has the same issue, so switching
 component.

 So, it's correct that this issue is caused by relays reporting bandwidth
 data for 4 hours rather than 15 minutes as before.  That's also why
 Onionoo stopped giving out data covering 3 days and 1 week, because those
 would have been on a granularity of 15 minutes and 1 hour, respectively,
 and data on that granularity level is simply not available anymore.  The
 first data series with 4 hour intervals is 1 month and that is still given
 out by Onionoo.

 What Atlas should do is take the 1 month data series as input and graph
 only the last 3 days or 1 week if it wants to keep its graphs.  They will
 have a lower data resolution, but that's exactly because the data
 resolution provided by relays is now lower.  Or it could remove those two
 graphs and start with 1 month.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11826 [Metrics/Globe]: Distinguish between permanent and temporary Onionoo errors

[Tor Bug Tracker & Wiki]

#11826: Distinguish between permanent and temporary Onionoo errors
---+-
 Reporter:  karsten|  Owner:  isis
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're shutting down Globe, and we still have #8667 for the same issue in
 Atlas.  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11809 [Metrics/Globe]: Globe says "No data available :(" when data is actually available

[Tor Bug Tracker & Wiki]

#11809: Globe says "No data available :(" when data is actually available
---+---
 Reporter:  cypherpunks|  Owner:  cydrobolt
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  assigned => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're shutting down Globe, and there's a similar ticket for the same issue
 in Atlas (#17326).  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16230 [Metrics/Atlas]: same server under same ip address listed on Atlas

[Tor Bug Tracker & Wiki]

#16230: same server under same ip address listed on Atlas
---+--
 Reporter:  bossghetto |  Owner:  phw
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:  Tor: unspecified
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * status:  needs_information => closed
 * resolution:   => not a bug
 * severity:   => Normal


Comment:

 No response in 11 months, and this still sounds like "not a bug".
 Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15417 [Metrics/Atlas]: atlas should point to the actual family instead of displaying relay fingerprints

[Tor Bug Tracker & Wiki]

#15417: atlas should point to the actual family instead of displaying relay
fingerprints
---+-
 Reporter:  cypherpunks|  Owner:  phw
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 I guess this is moot with #16961 being merged.  Closing.  Please re-open
 if you disagree.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11497 [Metrics/Atlas]: Add fractions of bridge clients by country, transport, and IP version

[Tor Bug Tracker & Wiki]

#11497: Add fractions of bridge clients by country, transport, and IP version
---+-
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Oh, I guess this is blocking on #11348 which would have to be implemented
 first.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18954 [Internal Services/Service - trac]: Trac should not make request to next/related bug

[Tor Bug Tracker & Wiki]

#18954: Trac should not make request to next/related bug
--+--
 Reporter:  gk|  Owner:  qbi
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [comment:11 cypherpunks]:
 Restless punky animal, still can't stop thinking about the others' backs?
 > > And what cookie are you talking about
 > Read the source code
 The question was about its relevance to the topic. Or can't you find where
 it's written in the source code?
 > > dirty animal?
 > Is that supposed to be an insult? Hilarious.
 It's just what you shave everyday in the mirror.

 ...

 Wow, nickm came into a discussion!

 nickm:
 It just tries to socialize. And how do you communicate with such an
 animal?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #9913 [Metrics/Atlas]: Explain relay flags in detail view using tooltips

[Tor Bug Tracker & Wiki]

#9913: Explain relay flags in detail view using tooltips
+--
 Reporter:  f3ndot  |  Owner:  f3ndot
 Type:  enhancement | Status:
 Priority:  Medium  |  needs_information
Component:  Metrics/Atlas   |  Milestone:
 Severity:  Normal  |Version:
 Keywords:  flag description tooltip flags  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--
Changes (by karsten):

 * severity:   => Normal


Comment:

 See also #7939 which I just closed as near duplicate of 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] #7939 [Metrics/Atlas]: Add details on what the relay flags mean

[Tor Bug Tracker & Wiki]

#7939: Add details on what the relay flags mean
---+---
 Reporter:  hellais|  Owner:  hellais
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  new => closed
 * resolution:   => duplicate
 * severity:   => Normal


Comment:

 #9913 is a near duplicate with slightly more information.  Closing this
 one as duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #12522 [Metrics/Atlas]: Add sitemap.xml to Globe to make details pages indexed by Google et al.

[Tor Bug Tracker & Wiki]

#12522: Add sitemap.xml to Globe to make details pages indexed by Google et al.
---+-
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * owner:  isis => phw
 * component:  Metrics/Globe => Metrics/Atlas
 * severity:   => Normal


Comment:

 This could be useful for Atlas as well, so let's consider this.  I'm
 moving this ticket to the Atlas component, because we're shutting down
 Globe soon.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13745 [Metrics/Atlas]: Determine which patches to apply from wpapper's Globe fork

[Tor Bug Tracker & Wiki]

#13745: Determine which patches to apply from wpapper's Globe fork
---+---
 Reporter:  isis   |  Owner:  isis
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  needs_review => needs_information
 * component:  Metrics/Globe => Metrics/Atlas
 * severity:   => Normal


Comment:

 We're shutting down Globe, so that these branches are unlikely to be
 merged anymore.  But is there anything interesting in these branches that
 we could create Atlas tickets or even patches for?  Changing to Atlas
 component just in case.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18081 [Metrics/Atlas]: Display a message when Onionoo is unavailable

[Tor Bug Tracker & Wiki]

#18081: Display a message when Onionoo is unavailable
---+-
 Reporter:  cypherpunks|  Owner:  phw
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * owner:  isis => phw
 * component:  Metrics/Globe => Metrics/Atlas


Comment:

 We're shutting down Globe soon, but Atlas is likely affected by the same
 issue.  Moving to the Atlas component.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10883 [Metrics/Atlas]: Globe should explain how users can search for their bridge

[Tor Bug Tracker & Wiki]

#10883: Globe should explain how users can search for their bridge
---+-
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * owner:  isis => phw
 * component:  Metrics/Globe => Metrics/Atlas
 * severity:   => Normal


Comment:

 We're retiring Globe soon, but Atlas could also make use of some better
 documentation in this regard.  Moving to the Atlas component.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11497 [Metrics/Atlas]: Add fractions of bridge clients by country, transport, and IP version

[Tor Bug Tracker & Wiki]

#11497: Add fractions of bridge clients by country, transport, and IP version
---+-
 Reporter:  karsten|  Owner:  phw
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * owner:  isis => phw
 * component:  Metrics/Globe => Metrics/Atlas
 * severity:   => Normal


Comment:

 As we're retiring Globe, I'm moving this ticket to Atlas.  Let's consider
 whether we want to implement this feature in Atlas, because if not, I'll
 remove that feature from Onionoo.  It's only useful to provide this data
 if somebody uses it.  (These fields still have the following warning in
 the spec: "BETA: This field breaks compatibility with the history objects
 contained in other documents pretty badly. It might be removed in the
 future without notice.")

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18048 [Metrics/Atlas]: Update Globe's jQuery

[Tor Bug Tracker & Wiki]

#18048: Update Globe's jQuery
---+-
 Reporter:  cypherpunks|  Owner:  phw
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * owner:  isis => phw
 * component:  Metrics/Globe => Metrics/Atlas


Comment:

 We're about to retire Globe soon, but it looks like Atlas has the same
 issue with an outdated jQuery.  It's using jQuery 1.7.1, I think.
 Changing to the Atlas component.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18009 [Metrics/Globe]: country-flag-atlas.png reference incorrect in country-flags.css

[Tor Bug Tracker & Wiki]

#18009: country-flag-atlas.png reference incorrect in country-flags.css
---+-
 Reporter:  derrickoswald  |  Owner:  isis
 Type:  defect | Status:  closed
 Priority:  Very Low   |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Trivial| Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 We're about to retire Globe, and this issue seems only relevant to Globe
 and not to Atlas.  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16908 [Metrics/Globe]: Warn when Onionoo serves outdated data

[Tor Bug Tracker & Wiki]

#16908: Warn when Onionoo serves outdated data
---+-
 Reporter:  karsten|  Owner:  isis
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're about to retire Globe, and there's already #15178 for the related
 issue in Atlas.  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16834 [Metrics/Globe]: Globe's relay/bridge count is misleading (+paginate results if over 50)

[Tor Bug Tracker & Wiki]

#16834: Globe's relay/bridge count is misleading (+paginate results if over 50)
---+---
 Reporter:  cydrobolt  |  Owner:  cydrobolt
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  assigned => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're about to retire Globe, and this issue is only specific to Globe, not
 to Atlas.  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11195 [Metrics/Globe]: List all three bandwidth values on Globe's details page

[Tor Bug Tracker & Wiki]

#11195: List all three bandwidth values on Globe's details page
---+---
 Reporter:  arma   |  Owner:  cydrobolt
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  assigned => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're about to retire Globe, and the Atlas-specific part of this issue is
 already resolved.  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #9348 [Metrics/Atlas]: Add average/burst/observed bandwidth to Atlas' details page

[Tor Bug Tracker & Wiki]

#9348: Add average/burst/observed bandwidth to Atlas' details page
---+---
 Reporter:  karsten|  Owner:  hellais
 Type:  enhancement| Status:  closed
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  new => closed
 * resolution:   => duplicate
 * severity:   => Normal


Comment:

 Already implemented in the context of #11195 which used to be an Atlas
 ticket before.  Closing as duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13622 [Metrics/Globe]: Limits of sliding window below graph should match limits of graph

[Tor Bug Tracker & Wiki]

#13622: Limits of sliding window below graph should match limits of graph
---+-
 Reporter:  dcf|  Owner:  isis
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're about to retire Globe, and this issue is only related to Globe, not
 to Atlas.  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13274 [Metrics/Globe]: mean uptime (monthly) versus mean uptime (weekly) -one has too big rounding errors

[Tor Bug Tracker & Wiki]

#13274: mean uptime (monthly) versus mean uptime (weekly) -one has too big 
rounding
errors
---+-
 Reporter:  toralf |  Owner:  isis
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're about to retire Globe, and this issue is only specific to Globe and
 not to Atlas.  Closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #12124 [Metrics/Globe]: globe/atlas don't display accept6/reject6 lines

[Tor Bug Tracker & Wiki]

#12124: globe/atlas don't display accept6/reject6 lines
---+---
 Reporter:  arma   |  Owner:  cydrobolt
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  assigned => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 We're about to retire Globe, and this issue is already resolved in Atlas,
 so closing as won't fix.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13769 [Metrics/Globe]: Globe doesn't support + signs in queries

[Tor Bug Tracker & Wiki]

#13769: Globe doesn't support + signs in queries
---+---
 Reporter:  karsten|  Owner:  isis
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Globe  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

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


Comment:

 I just checked this again and it works just fine.  Sorry for the noise.
 Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18947 [Applications/Tor Browser]: 6.0a5 is not starting on OS X if put into /Applications

[Tor Bug Tracker & Wiki]

#18947: 6.0a5 is not starting on OS X if put into /Applications
--+---
 Reporter:  gk|  Owner:  mcs
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201605  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Replying to [comment:6 cypherpunks]:
 > Your old torrc seems to have a Log option whose path wasn't migrated to
 the new bundle data location.  It should probably point to
 `/Users/nickm/Library/Application Support/TorBrowser-Data/Tor/info.log`.
 Maybe this wasn't a Tor Browser profile problem after all?

 It could be argued that this is a migration problem. We could add code to
 Tor Browser that tries to fix up paths inside torrc during profile
 migration. But that seems like a bad idea since Tor Browser currently has
 no knowledge of how to parse a torrc file, including which config file
 directives accept paths.

 In an ideal world we would capture stderr inside Tor Launcher (which would
 have made the problem obvious at least). This also tells me that fixing
 #10059 by providing a mechanism to ask for log messages via the control
 port is perhaps not the best solution; in this case, tor exited to soon
 for such a solution to be effective.

 One thing still confuses me about this ticket though. In the description,
 gk said:
 > Running "tor.real" from the command line is starting it fine.
 Maybe a different torrc was used for that test?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18974 [Metrics/Metrics website]: Feature request for the Metrics website: Bandwidth graph

[Tor Bug Tracker & Wiki]

#18974: Feature request for the Metrics website: Bandwidth graph
-+---
 Reporter:  Torify   |  Owner:
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 You mean a graph like this?  https://metrics.torproject.org/bandwidth.html

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18949 [Obfuscation/BridgeDB]: Update BridgeDB's CI to run tests with next version of Twisted

[Tor Bug Tracker & Wiki]

#18949: Update BridgeDB's CI to run tests with next version of Twisted
---+---
 Reporter:  isis   |  Owner:  isis
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/BridgeDB   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  isis201605 bridgedb-0.3.6  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

 * owner:   => isis
 * component:  - Select a component => Obfuscation/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] #18911 [User Experience/Website]: bitcoin donations via BitPay don't work properly for tor users (BitPay uses Cloudflare)

[Tor Bug Tracker & Wiki]

#18911: bitcoin donations via BitPay don't work properly for tor users (BitPay 
uses
Cloudflare)
-+---
 Reporter:  cypherpunks  |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by cypherpunks):

 * owner:   => Sebastian
 * component:  - Select a component => User Experience/Website


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18981 [Applications/Torbutton]: Torbutton breaks http proxy settings

[Tor Bug Tracker & Wiki]

#18981: Torbutton breaks http proxy settings
+-
 Reporter:  TomasMan|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 You disabled proxy settings in torbutton itself, and i have to set proxy
 in the torbrowser settings or in the about:config, i set all corresponding
 fields including extensions.torbutton.http_proxy to my proxy value which
 is right. And torbutton breaks all connections after that. The mess is
 done within the torbutton addon exactly, because with the torrbutton
 removed all runs properly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  High |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  modularity, tor-modularity,  |Version:
  TorCoreTeam201605, TorCoreTeam-| Resolution:
  postponed-201604   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-

Comment (by cypherpunks):

 Replying to [comment:14 dgoulet]:
 > Replying to [comment:13 cypherpunks]:
 > > It's supposed to be an inter-module facility, remember? Think about
 it.
 >
 > It is but that doesn't mean it has to be used inter-module _all_ the
 time thus controlling the linkage here is cheap and desirable imo.

 Sure, and I conceded as much in the my sentence. But my reminder was also
 directed at your item 2. Your feeling is wrong ;).

 I'll spell it out, now that I've read the whole thing.

 nickm's data structures seem fairly decoupled, I can see a few different
 possibilities.  Let's see if I understood it correctly. (You correct me
 nickm.)

 The more straightforward usage would be 1 publisher, n subscribers.
 {{{
 T-pubsub.h:
 #include "pubsub.h

 DECLARE_PUBSUB_TOPIC(T)

 [...]

 T-publishers-private.h:
 #include "T-pubsub.h"
 DECLARE_NOTIFY_PUBSUB_TOPIC(static, T)

 [...]

 T-publisher.c:
 #include "T-pubsub.h"
 #include "T-publisher-private.h"

 IMPLEMENT_PUBSUB_TOPIC(static, T)

 Use T_notify() and T_clear() here.  But maybe also T_subscribe()
 and
 T_unsubscribe().

 [...]

 any-T-subscriber.c:
 #include "T-publisher.h"

 Implement your T_subscriber_fn_t here, or maybe grab a generic one
 from
 somewhere else (maybe the publisher provides one).

 Use T_subscribe() and T_unsubscribe() here.
 }}}

 But ISTM that n publishers, n subscribers is also possible.
 {{{
 another-T-publisher.c:
 #include "T-pubsub.h"
 #include "T-publisher-private.h"

 // Note: no IMPLEMENT.

 Use T_notify() and T_clear() here.  But maybe also T_subscribe()
 and
 T_unsubscribe().

 [...]
 }}}

 The choice of where to put the definition for `T_event_data_t` and
 `T_subscriber_data_t` seems quite open, since the functions in "pubsub.c"
 only shuffle pointers around and never dereference them.  So it
 effectively depends on what the notification handler does with its
 arguments (plus maybe style and mental health).

 If the T-publisher(s) need to send actual data with the event (the event
 is more than just a "signal"), then, logically, T-publisher(s) and
 T-subscribers need to have the definition for `T_event_data_t` available.
 So it should probably go on the public "T-pubsub.h" header.

 If not, then I don't see why you couldn't always pass NULL.

 If there's a generic T-notification handler somewhere, then the definition
 for `T_subscriber_data_t` should probably be alongside.  If instead every
 T-subscriber implements his own T-notification handler then the definition
 can be in the c unit of each; hell, they could even be all different.

 ---

 Further review comments:

 - I don't think you use "tor_queue.h" included in "pubsub.h".

 - I don't like the `T_subscriber_fn_t` name (nor the "generic" type name
 nor the argument name).  A name that conveys "T notification handler", or
 similar, would be better IMHO.  But T_notification_handler_fn_t is a tiny
 bit unwieldy.

 - Why does `pubsub_subscriber_fn_t` take a single `void*` argument?  Why
 not `(void*, void*)`?  I see that it's going to be casted anyway, but is
 there any reason?

 - In `T_call_the_notify_fn_`, maybe document that the reason this function
 exists is so that the function pointer can be casted back to the
 appropriate type (noting that is not necessary to cast any of the 2 data
 pointers, in C).

 - `T_subscriber_t` is just used as a type tag, memory is never accessed as
 a `T_subscriber_t` (it can't: the type is never defined, only declared),
 instead it is always cast to and from `pubsub_subscriber_t` before and
 after accessing.  Correct?

 - In "pubsub.h", there are quite a number of symbols declared outside of
 any macro.  Why didn't they go inside the implementation macro?  Where
 else are they needed?

 - "Funny" that low priority means high priority ;).

 - Did you think about "interesting" interactions? E.g. unsubscr

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by cypherpunks):

 == Please make CAPTCHAs solvable without a pointing device like mice,
 trackpads or touch panels. ==

 Dumb tech people tend to think that everyone uses software like they do.
 ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rsos, sos, tor2web, tor-hs  |  Actual Points:
Parent ID:  | Points:  small/medium
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:1 teor]:
 > Replying to [ticket:17945 teor]:
 > > Tor2Web clients make a one-hop connection to the rendezvous point.
 Rendezvous Single Onion Services also make a one-hop connection to the
 rendezvous point. (Single Onion Services expect a client to make an extend
 request to the Single Onion Service at the end of a 3-hop path.)
 > The rendezvous point (and possibly the introduction point) could
 terminate the connection if it has a single hop on both ends. This seems
 to be the most correct option.

 This could result in false positives if the consensus gets out of sync.
 Or is there a reliable way for a relay to detect non-relays without using
 the consensus?
 (How does the padding do it?)

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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rsos, sos, tor2web, tor-hs  |  Actual Points:
Parent ID:  | Points:  small/medium
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 This was raised on the tor-project mailing list, and I said:

   We'e yet to arrive at a mechanism to make this happen, but I think we
 will end up adding a line to the onion service descriptor.
   We could make this a configuration parameter (AllowTor2Web?) that
 defaults to 1 for hidden services, and 0 for single onion services.

 https://lists.torproject.org/pipermail/tor-project/2016-May/000333.html

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