Re: [tor-bugs] #18958 [Applications/Tor Browser]: screen.orientation should lie

[Tor Bug Tracker & Wiki]

#18958: screen.orientation should lie
+--
 Reporter:  mcs |  Owner:
 Type:  defect  |  arthuredelstein
 Priority:  Medium  | Status:  accepted
Component:  Applications/Tor Browser|  Milestone:
 Severity:  Normal  |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--
Changes (by arthuredelstein):

 * status:  new => accepted
 * owner:  tbb-team => arthuredelstein


--
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] #18988 [Core Tor/Tor]: log error level messages if relay (self) is not in consensus

[Tor Bug Tracker & Wiki]

#18988: log error level messages if relay (self) is not in consensus
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Replying to [comment:2 cypherpunks]:
 > What do you think about having a more serious log entry for such "hard
 failures"? (relay dropped out of consensus)
 I think it would be technically easy. For example using 'warning' instead:

 {{{
 --- a/src/or/status.c
 +++ b/src/or/status.c
 @@ -100,7 +100,7 @@ log_heartbeat(time_t now)
return -1; /* Something stinks, we won't even attempt this. */
  else
if (!node_get_by_id(me->cache_info.identity_digest))
 -log_fn(LOG_NOTICE, LD_HEARTBEAT, "Heartbeat: It seems like we are
 not "
 +log_fn(LOG_WARN, LD_HEARTBEAT, "Heartbeat: It seems like we are
 not "
 "in the cached consensus.");
}

 }}}

 However I disagree about it being a 'hard failure', IMO is not even a
 failure, the system is working fine.

 > And wouldn't it make sense to check if we are in the consensus every
 hour regardless of HeartbeatPeriod? (is that check that expensive?)
 Dunno.

--
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] #18986 [- Select a component]: Tor Not Start in Slackware 13.37

[Tor Bug Tracker & Wiki]

#18986: Tor Not Start in Slackware 13.37
--+---
 Reporter:  br4v37|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by br4v37):

 the same problem with the new version.. anyway 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] #18988 [Core Tor/Tor]: log error level messages if relay (self) is not in consensus

[Tor Bug Tracker & Wiki]

#18988: log error level messages if relay (self) is not in consensus
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 What do you think about having a more serious log entry for such "hard
 failures"? (relay dropped out of consensus)

--
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] #18989 [Metrics/Atlas]: No Country image for Lativa

[Tor Bug Tracker & Wiki]

#18989: No Country image for Lativa
---+-
 Reporter:  alenan |  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 arma):

 * owner:  Sebastian => phw
 * component:  User Experience/Website => Metrics/Atlas


Comment:

 In fact, it appears to be trying to embed an image with the url
 https://atlas.torproject.org/img/cc/.png

--
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] #18989 [User Experience/Website]: No Country image for Lativa

[Tor Bug Tracker & Wiki]

#18989: No Country image for Lativa
-+---
 Reporter:  alenan   |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 As it looks,
 lativa has currently no image icon. See at:
 https://atlas.torproject.org/#details/7884A5CD96F3EBDDD56A5894D9563250103BB140

--
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] #18988 [Core Tor/Tor]: log error level messages if relay (self) is not in consensus

[Tor Bug Tracker & Wiki]

#18988: log error level messages if relay (self) is not in consensus
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Replying to [ticket:18988 cypherpunks]:
 > Is HeartbeatPeriod (default 6 hours) relevant for that?
 Yes. The log severity is 'notice'. The manual is very clear.

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

 Replying to [comment:7 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.

 Getting the stdout/stderr would have been helpful in this case, yeah.

 Also I wonder if somewhere down the line we might have some way in
 particular for Tor to report this kind of error so the Launcher can say
 something like, "Tor found a problem with your configuration.  It said,
 "[message here]". Retry with a fresh configuration?"


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

 I think that no 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

[tor-bugs] #18988 [Core Tor/Tor]: log error level messages if relay (self) is not in consensus

[Tor Bug Tracker & Wiki]

#18988: log error level messages if relay (self) is not in consensus
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Tor (relay mode) should check once an hour if his fingerprint is included
 in the consensus and if that is not the case log a prominent error level
 entry telling the operator about the problem.

 In the past I noticed such a log but apparently it is not done every hour.

 I.e. relay dropped out of consensus >4 hours ago, but there is no log
 entry about it.

 Is HeartbeatPeriod (default 6 hours) relevant for that?

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

Re: [tor-bugs] #13953 [Core Tor/Tor]: Self-test reachability test - Listen address from ORPort is ignored, it uses default address unless specified via Address argument

[Tor Bug Tracker & Wiki]

#13953: Self-test reachability test - Listen address from ORPort is ignored, it
uses default address unless specified via Address argument
--+
 Reporter:  s7r   |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.10
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  3 hours
Parent ID:  #17782| Points:  medium
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review
 * actualpoints:   => 3 hours


Comment:

 My first attempt at this is in my branch bug13953 on
 https://github.com/teor2345/tor.git

 It could do with some testing, and maybe some unit tests.

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

Re: [tor-bugs] #18987 [Core Tor/Tor]: Ship a cached-certs file with Tor, to speed first bootstrap

[Tor Bug Tracker & Wiki]

#18987: Ship a cached-certs file with Tor, to speed first bootstrap
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:   => 029-proposed
 * points:   => small
 * milestone:  Tor: unspecified => Tor: 0.2.???


Comment:

 I think we could do this by distributing a default-certs file with Tor,
 like we distribute the geoip databases.

 In fact, if we refreshed this file every time we refreshed the geoip
 databases, that would streamline the process (and be about the right
 amount of time).

 I think this requires a few lines of code to look for a default-certs file
 in the static tor files, when no cached-certs file exists. Or do we need a
 torrc option for its file path, like with geoip?

--
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] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
+
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  must-fix-before-028-rc  |  Actual Points:
Parent ID:  | Points:  small
 Reviewer:  nickm   |Sponsor:
+

Comment (by arma):

 Separate from the short-term fixes here, I filed a long-term improvement
 as #18987.

--
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] #18987 [Core Tor/Tor]: Ship a cached-certs file with Tor, to speed first bootstrap

[Tor Bug Tracker & Wiki]

#18987: Ship a cached-certs file with Tor, to speed first bootstrap
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Motivated by #18816: it looks like in
 networkstatus_check_consensus_signature() we return success if there are
 "enough" signature on the consensus we get. So we could cut out the cert
 fetching step in initial bootstrap for all new Tors, by having an "if
 there is no cached-cert file, use this string instead" step.

 And this string would continue being good enough until quite a few of the
 authorities have rotated to a new cert.

 Minor issue #1: Tor 0.2.7.6 has now been out for five months. I bet quite
 a few of the certs have rotated by now. So we should keep in mind that
 this feature in stable releases will decay over time (and maybe we want a
 new stable every 4-6 months or something anyway). A fancier option would
 be to use an external file, and then Tor Browser could just make an
 updated version of the file as part of its release process.

 Minor issue #2: As the stables are decaying, does this feature open the
 user up to a partitioning attack? I think the answer might be "yes but a
 very minor one, so let's not worry about 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] #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   |  needs_review
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 teor):

 * 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] #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   |  needs_review
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 teor):

 * 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] #18986 [- Select a component]: Tor Not Start in Slackware 13.37

[Tor Bug Tracker & Wiki]

#18986: Tor Not Start in Slackware 13.37
--+---
 Reporter:  br4v37|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arma):

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


Comment:

 A) Whatever you are running is very old. You should not be running it. Get
 a recent Tor Browser from the Tor website.

 B) Read the [warn] line, which tells you what the problem is for you.
 (Maybe there are other problems after that, but this is your first one.)

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

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:  needs_review
 Priority:  Low|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:  Tor:
 Severity:  Minor  |  0.2.4.5-alpha
 Keywords:  easy logging 029-proposed  | Resolution:
Parent ID: |  Actual Points:  1 hour
 Reviewer: | Points:  small
   |Sponsor:
---+---
Changes (by teor):

 * status:  new => needs_review
 * keywords:  easy logging => easy logging 029-proposed
 * version:   => Tor: 0.2.4.5-alpha
 * actualpoints:   => 1 hour


Comment:

 See my branch bug18982 on https://github.com/teor2345/tor.git

 It's a 2-line, 4-character 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

[tor-bugs] #18986 [- Select a component]: Tor Not Start in Slackware 13.37

[Tor Bug Tracker & Wiki]

#18986: Tor Not Start in Slackware 13.37
--+-
 Reporter:  br4v37|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Hi,

 i try to use tor in slackware 13.37. but not work

 i got this


 {{{
 bash-4.1$ ./start-tor-browser -verboseLaunching Tor Browser for Linux in
 /etc/pmad/Desktop/tor-browser_en-US4/tor-browser_en-US/Browser...
 Xlib:  extension "RANDR" missing on display ":1.0".
 May 07 11:47:32.092 [notice] Tor v0.2.5.8-rc (git-cc2477cc002ac542)
 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1i and Zlib
 1.2.5.
 May 07 11:47:32.092 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 May 07 11:47:32.092 [notice] Read configuration file "/etc/pmad/Desktop
 /tor-browser_en-US4/tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc-
 defaults".
 May 07 11:47:32.092 [notice] Read configuration file "/etc/pmad/Desktop
 /tor-browser_en-US4/tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc".
 May 07 11:47:32.094 [notice] Opening Control listener on 127.0.0.1:9151
 May 07 11:47:32.094 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 May 07 11:47:32.000 [notice] Parsing GEOIP IPv4 file /etc/pmad/Desktop
 /tor-browser_en-US4/tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip.
 May 07 11:47:32.000 [notice] Parsing GEOIP IPv6 file /etc/pmad/Desktop
 /tor-browser_en-US4/tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip6.
 May 07 11:47:32.000 [notice] Bootstrapped 0%: Starting
 May 07 11:47:32.000 [warn] Our clock is 1 hours, 12 minutes behind the
 time published in the consensus network status document (2016-05-07
 11:00:00 UTC).  Tor needs an accurate clock to work correctly. Please
 check your time and date settings!
 May 07 11:47:32.000 [notice] Delaying directory fetches: DisableNetwork is
 set.
 May 07 11:47:32.000 [notice] New control connection opened from 127.0.0.1.
 May 07 11:47:32.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 May 07 11:47:32.000 [notice] New control connection opened from 127.0.0.1.
 May 07 11:47:42.000 [notice] Opening Socks listener on 127.0.0.1:9150
 May 07 11:47:43.000 [notice] Bootstrapped 5%: Connecting to directory
 server
 May 07 11:47:43.000 [notice] Bootstrapped 10%: Finishing handshake with
 directory server
 May 07 11:47:43.000 [notice] Bootstrapped 15%: Establishing an encrypted
 directory connection
 May 07 11:47:43.000 [notice] Bootstrapped 20%: Asking for networkstatus
 consensus
 May 07 11:47:43.000 [notice] Bootstrapped 25%: Loading networkstatus
 consensus
 May 07 11:47:43.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no recent usable consensus.
 May 07 11:48:44.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no recent usable consensus.
 May 07 11:49:45.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no recent usable consensus.
 May 07 11:50:46.000 [warn] Received http status code 404 ("Not found")
 from server '192.42.115.101:9003' while fetching
 "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".
 May 07 11:51:47.000 [warn] Received http status code 404 ("Not found")
 from server '62.210.122.179:9001' while fetching
 "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".

 }}}

--
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] #18985 [Internal Services/Service - git]: Move some gitweb entries to the attic?

[Tor Bug Tracker & Wiki]

#18985: Move some gitweb entries to the attic?
-+
 Reporter:  arma |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 On https://gitweb.torproject.org/ I see apaf, brdgrd, soon-to-be-globe,
 stormy, tor-browser-pre24.3.0, tor-cloud, tor-history, torbel, torouter,
 vidalia*, which could all plausibly be moved to attic.

 Maybe there are more too?

--
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] #18984 [User Experience/Website]: List 64-bit Linux Tor Browser first on download pages?

[Tor Bug Tracker & Wiki]

#18984: List 64-bit Linux Tor Browser first on download pages?
-+---
 Reporter:  arma |  Owner:  Sebastian
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by sojka):

 I can confirm that Assumption 1 is somewhat true: the user needs some
 32bit libraries on his 64bit system to have Tor browser work and people
 often don't have it because majority of all software is installed through
 package managers which automatically fetch the right package for the users
 architecture.

 By the way, the closed-source Google Chrome browser (as opposed to the
 opensource Chromium) ends support for 32 bit by Chrome 47.
 [https://threatpost.com/google-ends-chrome-support-on-32-bit-linux-
 releases-chrome-47/115526/]

--
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] #18984 [User Experience/Website]: List 64-bit Linux Tor Browser first on download pages?

[Tor Bug Tracker & Wiki]

#18984: List 64-bit Linux Tor Browser first on download pages?
-+---
 Reporter:  arma |  Owner:  Sebastian
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 On https://www.torproject.org/download/download-easy and
 https://www.torproject.org/download/download we list the 32-bit Tor
 Browser first, and the 64-bit Tor Browser second.

 Assumption 1: they don't work if you fetch the wrong one. specifically, I
 think the 32-bit one does not work on 64-bit systems. I just checked this
 again and it seems to be true.

 Assumption 2 (Karsten or Sebastian can learn whether this is true, e.g.
 from the same analysis as on #18768): The 64-bit bit one is more used,
 since a lot of people are 64-bit people nowadays.

 If both of these assumptions turn out to hold, I think we should list the
 64-bit one 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] #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:
-+-

Comment (by arma):

 Replying to [comment:8 dgoulet]:
 >   DG1: Just after we set `answer = 1`, we should break. There is no need
 to continue the loop.

 Sounds good. I've pushed another commit that does this.

 > * Commit `a9012a61fafae3ca8c6ae40ba5f433dcf12aad71`
 >
 >   DG2: There is an awful lot of code removal in there but the commit
 message doesn't tell me why nor what is being removed here. This is an
 interesting change, we go from a callback every second trying to cleanup
 to a function call only done when we successfully receive a consensus.

 Yes, correct. The comments for the new
 connection_dir_close_consensus_fetches() function are probably the best
 description of what's going on here. Should I try to clarify more?

 > The whole logic of this patch seems OK to me. Let's fix those unit tests
 :).

 If somebody wants to grab this and fix the unit tests, please 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] #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 cypherpunks):

 I (reporter of this bug) am actually fine with the current fix within
 Qubes OS.
 So this ticket shouldn't take away your resources.

 I would also be fine to close this ticket.

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