Re: [tor-bugs] #28702 [Core Tor/Tor]: bootstrapping slow at times

[Tor Bug Tracker & Wiki]

#28702: bootstrapping slow at times
+--
 Reporter:  weasel  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  s8-bootstrap-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor8-can
+--
Changes (by weasel):

 * Attachment "time-tor-bootstrap" added.


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

Re: [tor-bugs] #1623 [Applications/Tor Browser]: Block protocol handler enumeration

[Tor Bug Tracker & Wiki]

#1623: Block protocol handler enumeration
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-fingerprinting, tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201810R, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-fingerprinting, tbb-torbutton, TorBrowserTeam201810R, tbb-
 backport =>
 tbb-fingerprinting, tbb-torbutton, TorBrowserTeam201810R, tbb-
 backported


Comment:

 Backported to `tor-browser-60.3.0esr-8.0-1` (commits
 d0571f8b98a5a98e59974b4868c0fcccaea17748,
 818556471232f9a9a4caebc3c37cae387a43bbd7, and
 bec054919416df19648702f2af0b9a0be1c384b8)

--
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] #26263 [Applications/Tor Browser]: browser app icon positioned incorrectly in macOS DMG installer window

[Tor Bug Tracker & Wiki]

#26263: browser app icon positioned incorrectly in macOS DMG installer window
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-8.0-issues,|  Actual Points:
  TorBrowserTeam201810R, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff60-esr, tbb-8.0-issues, TorBrowserTeam201810R, tbb-backport
 => ff60-esr, tbb-8.0-issues, TorBrowserTeam201810R, tbb-backported


--
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] #26263 [Applications/Tor Browser]: browser app icon positioned incorrectly in macOS DMG installer window

[Tor Bug Tracker & Wiki]

#26263: browser app icon positioned incorrectly in macOS DMG installer window
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-8.0-issues,|  Actual Points:
  TorBrowserTeam201810R, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Backported to `maint-8.0` (commit
 cb37fc36ffb8d21c99e90a61b6a31a8981b64e41).

--
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] #17962 [Core Tor/Tor]: Cannot connect to Tor

[Tor Bug Tracker & Wiki]

#17962: Cannot connect to Tor
--+--
 Reporter:  talerong  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by omg):

 * status:  new => assigned
 * owner:  tbb-team => (none)
 * component:  Applications/Tor Browser => Core Tor/Tor


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

Re: [tor-bugs] #27218 [Applications/Tor Browser]: Make rebundling faster by generating multiple bundles in parallel

[Tor Bug Tracker & Wiki]

#27218: Make rebundling faster by generating multiple bundles in parallel
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, boklm201810,|  Actual Points:
  TorBrowserTeam201810R, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, boklm201810, TorBrowserTeam201810R, tbb-backport =>
 tbb-rbm, boklm201810, TorBrowserTeam201810R, tbb-backported


Comment:

 Cherry-picked to `maint-8.0` (commit
 2d129f5c6b282c6e9e915339f7b4dfb0f54b5a80).

--
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] #26381 [Applications/Tor Browser]: about:tor page does not load on first start on Windows and browser is stuck in endless reload cycle

[Tor Bug Tracker & Wiki]

#26381: about:tor page does not load on first start on Windows and browser is 
stuck
in endless reload cycle
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-torbutton, ff60-esr, |  Actual Points:
  TorBrowserTeam201809R, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-torbutton, ff60-esr, TorBrowserTeam201809R, tbb-backport
 => tbb-torbutton, ff60-esr, TorBrowserTeam201809R, tbb-backported


Comment:

 Backported to the stable branch (`tor-browser-60.3.0esr-8.0-1`) (commit
 dcf7cc2acd095e27d82b16424d4d23fb9b5d7559).

--
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] #26475 [Applications/Tor Browser]: ESR60-based Tor Browser bundles are not built reproducibly with Stylo enabled using rustc > 1.25.0

[Tor Bug Tracker & Wiki]

#26475: ESR60-based Tor Browser bundles are not built reproducibly with Stylo
enabled using rustc > 1.25.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201810R,  |  Actual Points:
  GeorgKoppen201810, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201810R, GeorgKoppen201810, tbb-
 backport => tbb-rbm, TorBrowserTeam201810R, GeorgKoppen201810, tbb-
 backported


Comment:

 Backported to our stable branch (`maint-8.0`) (commit
 dd1d00a2fed85c8bb22c4f85bbc45da00d0e8c05).

--
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] #28466 [Applications/rbm]: rbm does not correctly apply git submodule URL changes

[Tor Bug Tracker & Wiki]

#28466: rbm does not correctly apply git submodule URL changes
+
 Reporter:  boklm   |  Owner:  boklm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/rbm|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201811R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by gk):

 Cherry-picked for `maint-8.0` as well (commit
 4c37ac5dc9ab4fd66ab151219e208ceecfd947b6).

--
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] #24325 [Applications/Tor Browser]: Add Czech (cs) localization to Tor browser

[Tor Bug Tracker & Wiki]

#24325: Add Czech (cs) localization to Tor browser
-+-
 Reporter:  mstanke  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization, czech, l10n,   |  Actual Points:
  translation|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mstanke):

 Just to confirm, Firefox ESR is OK, so it doesn't seems as an upstream
 bug.

--
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] #24325 [Applications/Tor Browser]: Add Czech (cs) localization to Tor browser

[Tor Bug Tracker & Wiki]

#24325: Add Czech (cs) localization to Tor browser
-+-
 Reporter:  mstanke  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization, czech, l10n,   |  Actual Points:
  translation|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mstanke):

 Thank you emmapeel. I will follow this as a priority list, keeping the
 donation page aside for now.

 I have downloaded the alpha version to click through if everything seems
 right and I have noticed that about:preferences#general is shown in
 English for the linux64-cs build (screenshot above). Search and Privacy &
 Security tabs of Preferences are in Czech. Should I open a new ticket for
 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] #24325 [Applications/Tor Browser]: Add Czech (cs) localization to Tor browser

[Tor Bug Tracker & Wiki]

#24325: Add Czech (cs) localization to Tor browser
-+-
 Reporter:  mstanke  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization, czech, l10n,   |  Actual Points:
  translation|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mstanke):

 * Attachment "Snímek z 2018-12-05 07-49-29.png" added.

 screenshot - English about:preferences#general

--
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] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by loskiq):

 * Attachment "torrc_of_the_bridge.txt" added.

 torrc of the bridge

--
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] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by loskiq):

 * Attachment "log_of_the_bridge.txt" added.

 log of the bridge

--
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] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by loskiq):

 * Attachment "torrc_of_the_client.txt" added.

 torrc of the client

--
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] #28723 [Webpages/Website]: https://www.torproject.org/docs/debian.html.en lists 0.3.4 repo but only 0.3.5 is there

[Tor Bug Tracker & Wiki]

#28723: https://www.torproject.org/docs/debian.html.en lists 0.3.4 repo but only
0.3.5 is there
--+---
 Reporter:  tom   |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

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


Comment:

 This is a duplicate of #27809 which is waiting for 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] #27402 [Core Tor/Tor]: stop reporting "internal paths" during bootstrap

[Tor Bug Tracker & Wiki]

#27402: stop reporting "internal paths" during bootstrap
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s8-bootstrap, tor-spec,  |  Actual Points:  0.1
  035-deferred-20180930  |
Parent ID:  #28018   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor8-can
-+-

Comment (by teor):

 Does this branch fix #27448 as well?

--
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] #27448 [Core Tor/Tor]: router_have_consensus_path() logs an incorrect "no exits in consensus"

[Tor Bug Tracker & Wiki]

#27448: router_have_consensus_path() logs an incorrect "no exits in consensus"
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.7-rc
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #27402| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #27402


Comment:

 Does #27402 fix this issue as well?

--
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] #24838 [Core Tor/Fallback Scripts]: Ignore addresses in the fallback whitelist

[Tor Bug Tracker & Wiki]

#24838: Ignore addresses in the fallback whitelist
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Fallback Scripts|Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, fallback,   |  Actual Points:
  034-triage-20180328, 034-removed-20180328, |
  fast-fix, 035-roadmap-subtask, 035-triaged-|
  in-20180711|
Parent ID:  #24786   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 I will do this ticket this week.

--
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] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:2 traumschule]:
 > Where can i find the diff? It seems the received diff is not cached on
 disk. The rejected string
 {{{308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308}}}
 can't be found in any file. The folder diff-cache only contains files from
 Aug and Sep - did the file structure change since Tor 0.3.3.7?

 We might not store the diff on disk.

 Look for your CacheDirectory, which might not be the same as your
 DataDirectory.

 > Looking for this line brought up a local log from July, #24300

 Possibly related, set parent to #26310.

 > and
 > comment:7:issue:27315
 > > Downloading consensus from $consensus_guard using /tor/status-
 vote/current/consensus-
 microdesc/0232AF+14C131+23D15D+27102B+49015F+D586D1+E8A9C4+ED03BB+EFCBE7.z

 This is just a normal log when downloading a 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] #24300 [Core Tor/Tor]: Failed to find node for hop #1 of our path. Discarding this circuit

[Tor Bug Tracker & Wiki]

#24300: Failed to find node for hop #1 of our path. Discarding this circuit
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, bootstrap, s8-errors,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #26310   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by teor):

 * parent:   => #26310
 * milestone:  Tor: unspecified => Tor: 0.4.0.x-final


Comment:

 We think the guard part of this is fixed by #24661, and the consensus diff
 part will be fixed in #26310.

--
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] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+

Old description:

> Since todays HUP by lograte these CONSDIFF warnings showed up. Could the
> connection failures be related?
>
> {{{
> Dec 05 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
> Dec 05 00:00:22.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:00:22.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:00:22.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:00:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> <...>
> Dec 05 00:50:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:53:02.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:53:02.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:53:02.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:53:08.000 [notice] {APP} Tried for 120 seconds to get a
> connection to
> 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd:993. Giving up.
> (waiting for rendezvous desc)
> Dec 05 00:58:09.000 [notice] {APP} Tried for 120 seconds to get a
> connection to
> 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd:993. Giving up.
> (waiting for rendezvous desc)
> }}}
>
> Additionally info log shows
> {{{
> Dec 05 00:00:07.000 [info] {DIR} directory_send_command(): Downloading
> consensus from $directory_guard using /tor/status-vote/current/consensus-
> microdesc/0232AF+14C131+23D15D+27102B+49015F+D586D1+E8A9C4+ED03BB+EFCBE7.z
> <...>
> Dec 05 02:00:40.000 [info] {DIR} directory_send_command(): Downloading
> consensus from $directory_guard using /tor/status-vote/current/consensus-
> microdesc/0232AF+14C131+23D15D+27102B+49015F+D586D1+E8A9C4+ED03BB+EFCBE7.z
> }}}
>
> = directory guard versions
> - Tor 0.3.2.10 on Linux
> - Tor 0.3.1.10 on Linux
> - Tor 0.3.4.8 on Linux
>
> To avoid fingerprinting (#10969) addresses are scrubbed and are available
> on request.

New description:

 Since todays HUP by lograte these CONSDIFF warnings showed up. Could the
 connection failures be related?

 {{{
 Dec 05 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
 Dec 05 00:00:22.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:00:22.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:00:22.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:00:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:00:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:00:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:01:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:01:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:01:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:02:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:02:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:02:4

Re: [tor-bugs] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * Attachment "cached-microdesc.tar.xz" added.

 cached-microdesc* files

--
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] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+

Old description:

> Since todays HUP by lograte these CONSDIFF warnings showed up. Could the
> connection failures be related?
>
> {{{
> Dec 05 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
> Dec 05 00:00:22.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:00:22.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:00:22.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:00:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:00:40.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:00:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:01:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:01:40.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:01:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:02:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:02:40.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:02:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:02:58.000 [notice] {APP} Tried for 120 seconds to get a
> connection to
> 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd:993. Giving up.
> (waiting for rendezvous desc)
> Dec 05 00:03:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:03:40.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:03:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:04:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:04:40.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:04:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:05:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:05:40.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:05:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:06:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:06:40.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
> Dec 05 00:06:40.000 [warn] {DIR} Could not apply consensus diff received
> from server '$directory_guard'
> Dec 05 00:07:49.000 [warn] {CONSDIFF} Refusing to apply consensus diff
> because the base consensus doesn't match the digest as found in the
> consensus diff header.
> Dec 05 00:07:49.000 [warn] {CONSDIFF} Expected:
> 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
> 308CC8C02AD1A45612737D112962988069ED9

Re: [tor-bugs] #28702 [Core Tor/Tor]: bootstrapping slow at times

[Tor Bug Tracker & Wiki]

#28702: bootstrapping slow at times
+--
 Reporter:  weasel  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  s8-bootstrap-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor8-can
+--

Comment (by teor):

 How can I see the logs from these instances?
 If we're going to tweak the bootstrap config, it would help to know where
 bootstrap is failing, and the errors that it gives.

--
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] #28703 [Core Tor/Tor]: bootstrapping very slow with filtered network

[Tor Bug Tracker & Wiki]

#28703: bootstrapping very slow with filtered network
+--
 Reporter:  weasel  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  s8-bootstrap-maybe  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor8-can
+--

Comment (by teor):

 How can I see the logs from these instances?
 If we're going to tweak the bootstrap config, it would help to know where
 bootstrap is failing, and the errors that it gives,

--
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] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: nickm (added)
 * parent:   => #26310


Comment:

 It would be really helpful to have the base consensus and the diff that
 was received.
 I wonder if we need to modify these logs to get more useful info.

 I hope nickm can help diagnose 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

Re: [tor-bugs] #27381 [Core Tor/Tor]: Bad consensus diffs on 0.3.4 and later [with chutney]

[Tor Bug Tracker & Wiki]

#27381: Bad consensus diffs on 0.3.4 and later [with chutney]
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-auth  |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by teor):

 * parent:  #27146 => #26310


Comment:

 Looks like #26310

--
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] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * milestone:   => Tor: unspecified


Comment:

 What do the logs on the bridge say?
 Has the bridge bootstrapped?

 Can you attach your bridge and client torrcs?

--
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] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+---
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  consensus
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Since todays HUP by lograte these CONSDIFF warnings showed up. Could the
 connection failures be related?

 {{{
 Dec 05 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
 Dec 05 00:00:22.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:00:22.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:00:22.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:00:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:00:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:00:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:01:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:01:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:01:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:02:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:02:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:02:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:02:58.000 [notice] {APP} Tried for 120 seconds to get a
 connection to
 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd:993. Giving up.
 (waiting for rendezvous desc)
 Dec 05 00:03:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:03:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:03:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:04:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:04:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:04:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:05:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:05:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:05:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:06:40.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:06:40.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:06:40.000 [warn] {DIR} Could not apply consensus diff received
 from server '$directory_guard'
 Dec 05 00:07:49.000 [warn] {CONSDIFF} Refusing to apply consensus diff
 because the base consensus doesn't match the digest as found in the
 consensus diff header.
 Dec 05 00:07:49.000 [warn] {CONSDIFF} Expected:
 6630240AA7F1F643B7DCEFCD0B402F4860D1129C810927F0F6774DA51D7BC75E; found:
 308CC8C02AD1A45612737D112962988069ED9A8F78EEDD8CDF5D532CC5747308
 Dec 05 00:07:49.000 [warn] {DIR} Could not apply consensus diff 

Re: [tor-bugs] #28 [Mixminion-Client]: move .mixminionrc to .mixminion/

[Tor Bug Tracker & Wiki]

#28: move .mixminionrc to .mixminion/
--+-
 Reporter:  weasel|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:  0.0.8 final
Component:  Mixminion-Client  |Version:  unspeficied
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  assigned => closed
 * resolution:  None => wontfix


Old description:

> [Moved from bugzilla]
> Reporter: pe...@palfrader.org (Peter Palfrader)
> Description:
> Opened: 2004-03-23 00:16
>

>
> Tue 00:14:45  nickm: I think .mixminionrc should move to
> ~/.mixminion/options or ~/.mixminion/mixminion.conf or something like
> that
> Tue 00:15:06  weasel: reasonable.  Not for 0.0.7.
> Tue 00:15:12  file a bug report.
>

> --- Additional Comments From Peter Palfrader 2004-03-23 00:27 ---
>
> This of course makes the UserDir option in mixminionrc option rather
> useless.
> The MIXMINIONRC environment variable should be superseded by a
> MIXMINIONHOME
> enviornent var, to choose a dir instead of ~/.mixminion/
>
> [Automatically added by flyspray2trac: Operating System: Linux]

New description:

 [Moved from bugzilla]
 Reporter: pe...@palfrader.org (Peter Palfrader)
 Description:
 Opened: 2004-03-23 00:16



 Tue 00:14:45  nickm: I think .mixminionrc should move to
 ~/.mixminion/options or ~/.mixminion/mixminion.conf or something like that
 Tue 00:15:06  weasel: reasonable.  Not for 0.0.7.
 Tue 00:15:12  file a bug report.


 --- Additional Comments From Peter Palfrader 2004-03-23 00:27 ---

 This of course makes the UserDir option in mixminionrc option rather
 useless.
 The MIXMINIONRC environment variable should be superseded by a
 MIXMINIONHOME
 enviornent var, to choose a dir instead of ~/.mixminion/

 [Automatically added by flyspray2trac: Operating System: Linux]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #28353 [Metrics/Website]: Use Guard & Exit, Guard only, Exit only, and Middle only on all bandwidth by flag graphs

[Tor Bug Tracker & Wiki]

#28353: Use Guard & Exit, Guard only, Exit only, and Middle only on all 
bandwidth
by flag graphs
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28328   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:12 antonela]:
 > I used ColorOracle to imitate commons colorblind issues. Check the
 attachements. I think you will need a better contrast between that magenta
 and that blue. A #FF blue will works better.
 >
 > Nice process! we will have this in mind for #28629

 Here's a previous ticket on graphs for color vision deficiencies: #6463.

 For my version of colorblindness,
  * comment:6 (purple green gray) is great, A+.
  * comment:8 (red magenta blue gray) is only a little worse, the red and
 magenta are closer but still distinguishable. The bottom three colors are
 good. I know karsten said it's not gray but it looks gray to me :)
  * comment:10 (magenta blue lightblue gray) is not good, I have to look
 twice to distinguish the magenta and blue. The bottom three colors are
 good.

--
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] #28732 [Obfuscation/Snowflake]: Standardize on ArrayBuffer as the type of WebRTC messages

[Tor Bug Tracker & Wiki]

#28732: Standardize on ArrayBuffer as the type of WebRTC messages
---+--
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * status:  new => needs_review


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

[tor-bugs] #28732 [Obfuscation/Snowflake]: Standardize on ArrayBuffer as the type of WebRTC messages

[Tor Bug Tracker & Wiki]

#28732: Standardize on ArrayBuffer as the type of WebRTC messages
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Two problems:
  1. The proxy receives binary messages over an
 [https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel
 RTCDataChannel] without specifying what the type of those messages should
 be. Some debugging code is written to handle the type
 [https://developer.mozilla.org/en-US/docs/Web/API/ArrayBuffer
 ArrayBuffer], but when I tried it the type was actually
 [https://developer.mozilla.org/en-US/docs/Web/API/Blob Blob], which
 crashed the debug code.
  1. Snowflake uses exclusively binary WebRTC data, but the test code uses
 strings as message contents rather than one of the binary data types.

 This wasn't a huge problem, because strings `ArrayBuffer`s and `Blob`s are
 all valid to pass to `WebSocket.send`. The only other thing we do other
 than `send` them is take their length for the purpose of rate limiting,
 and that ''is'' broken.

 
https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=arraybuffer&id=73f328fef8a9351afc47bb65a68b549fbab90cad
 
https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=arraybuffer&id=73f328fef8a9351afc47bb65a68b549fbab90cad&id2=5817c257c1568c403a41e108d195b209e4e5f589

 This branch sets [https://developer.mozilla.org/en-
 US/docs/Web/API/RTCDataChannel/binaryType binaryType = "arraybuffer"] so
 that we don't get unexpected `Blob` objects. It then makes changes to the
 test and rate-limiting code to standardize on the ArrayBuffer interface
 everywhere.

--
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] #27049 [Core Tor/Tor]: "No circuits are opened" messages with onion services

[Tor Bug Tracker & Wiki]

#27049: "No circuits are opened" messages with onion services
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by teor):

 I don't think #28714 will fix it either.

 Maybe we should log something different when the circuit is not a user
 circuit?

--
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] #28731 [Core Tor/Tor]: log bootstrap tag name for easier troubleshooting

[Tor Bug Tracker & Wiki]

#28731: log bootstrap tag name for easier troubleshooting
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-bootstrap  |  Actual Points:
Parent ID:  #28018| Points:  0.1
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by catalyst):

 * status:  new => assigned
 * owner:  (none) => catalyst
 * points:   => 0.1


--
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] #27102 [Core Tor/Tor]: decouple bootstrap progress numbers from BOOTSTRAP_STATUS enum values

[Tor Bug Tracker & Wiki]

#27102: decouple bootstrap progress numbers from BOOTSTRAP_STATUS enum values
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by catalyst):

 Replying to [comment:8 mcs]:
 > catalyst, can you clarify what is meant by "decouple?" Would control
 port clients potentially receive different `PROGRESS` numbers each time
 bootstrapping occurs? For example, would it ever be the case that
 `BOOTSTRAP PROGRESS=80` would mean something different across different
 runs of tor? Or is this ticket concerned with an internal renumbering
 and/or rearchitecture, after which the `PROGRESS` numbers would be
 continue to be stable and predictable?
 Some discussion about the renumbering approach is in #28281.  We might not
 try to do the decoupling in the 0.4.0 timeframe.

 Could you please describe what risks you see from having the numbering
 possibly change from one run to another?

--
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] #28731 [Core Tor/Tor]: log bootstrap tag name for easier troubleshooting

[Tor Bug Tracker & Wiki]

#28731: log bootstrap tag name for easier troubleshooting
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  s8-bootstrap
Actual Points:|  Parent ID:  #28018
   Points:|   Reviewer:
  Sponsor:  Sponsor8-can  |
--+
 We might change what specific bootstrap progress numbers mean from time to
 time.  We should log the tag name, to make troubleshooting easier,
 especially when users report problems.  Right now we have to interpret the
 numeric progress numbers from users, which isn't great.  We send the tag
 name to the control port, but we don't log 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #28415, #28416, #26698

[Tor Bug Tracker & Wiki]

Batch modification to #28415, #28416, #26698 by teor:
reviewer to teor

Comment:
Taking over reviews from Mike, because he's busy with WTF-PAD.

--
Tickets URL: 

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

Re: [tor-bugs] #28223 [Core Tor/Tor]: Unparseable microdescriptor on public relay

[Tor Bug Tracker & Wiki]

#28223: Unparseable microdescriptor on public relay
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  040-roadmap-proposed, regression?,   |  Actual Points:
  035-can|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  035-roadmap-proposed, regression?, 035-can => 040-roadmap-
 proposed, regression?, 035-can
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.4.0.x-final


Comment:

 This is a ticket for better logging, it can go in 0.4.0.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #26469, #28241

[Tor Bug Tracker & Wiki]

Batch modification to #26469, #28241 by teor:


Comment:
These tickets need more information, so they can't be in 0.3.5.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #25347, #26295, #26369, #26478, ...

[Tor Bug Tracker & Wiki]

Batch modification to #25347, #26295, #26369, #26478, #26737, #26738, #26743, 
#28036 by teor:
milestone to Tor: 0.4.0.x-final

Comment:
These features or long-term bug fixes probably won't make it into 0.3.5

--
Tickets URL: 

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

Re: [tor-bugs] #28612 [Core Tor/Tor]: Tor start via Windows service fails

[Tor Bug Tracker & Wiki]

#28612: Tor start via Windows service fails
-+-
 Reporter:  Vort |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  windows nt-service regression|  Actual Points:
  035-backport 035-rc-blocker|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  windows nt-service regression 035-backport 035-rc-must =>
 windows nt-service regression 035-backport 035-rc-blocker


--
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] #28619 [Core Tor/Tor]: hs-v3: Do not close RP circuits when deleting an ephemeral service

[Tor Bug Tracker & Wiki]

#28619: hs-v3: Do not close RP circuits when deleting an ephemeral service
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 034-backport, 033-backport,  |  Actual Points:
  035-rc-blocker?|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-hs, 034-backport, 033-backport, 035-rc => tor-hs,
 034-backport, 033-backport, 035-rc-blocker?


--
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] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


--
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] #28656 [Core Tor/Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
-+-
 Reporter:  meejah   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, 035-rc-blocker?, |  Actual Points:
  034-backport, 035-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  regression, 035-rc-must?, 034-backport, 035-backport =>
 regression, 035-rc-blocker?, 034-backport, 035-backport


--
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] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => 1


Comment:

 This was comparatively simple.  PR in
 https://github.com/torproject/tor/pull/564

--
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] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  GeorgKoppen201812, TorBrowserTeam201812R   |
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_revision => needs_review
 * keywords:  tbb-mobile, TBA-a2, GeorgKoppen201811, TorBrowserTeam201812 =>
 tbb-mobile, TBA-a2, GeorgKoppen201812, TorBrowserTeam201812R


Comment:

 `bug_26483_v7` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26843_v7&id=44b98f26ac3ebe6f170be8ed6bf2f740997eeef7)
 should have the fixups.

--
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] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 {{{
 -
 +mv $rootdir/[% c('input_files_by_name/keystore') %] .
 +
 }}}
 contains a trailing whitespace at the end of the last line. Please remove
 that one.

 Why do we need to touch the extensions here? There were no differences in
 that regard when looking at the 8.5a5 diff of boklm's and my .apk.

--
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] #26529 [Applications/Tor Browser]: TBA - Notify user about possible proxy-bypass before opening external app

[Tor Bug Tracker & Wiki]

#26529: TBA - Notify user about possible proxy-bypass before opening external 
app
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:  #24855   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-mobile, tbb-torbutton, TorBrowserTeam201811 => tbb-mobile,
 tbb-torbutton, TorBrowserTeam201812


--
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] #27701 [Applications/Tor Browser]: Tor Browser on Android fails to download files

[Tor Bug Tracker & Wiki]

#27701: Tor Browser on Android fails to download files
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-mobile, TorBrowserTeam201811R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * cc: babs4 (added)


Comment:

 Resolved #28072 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] #28072 [Applications/Tor Browser]: Torbutton addon prohibits saving media to storage

[Tor Bug Tracker & Wiki]

#28072: Torbutton addon prohibits saving media to storage
---+---
 Reporter:  babs4  |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  tbb-mobile, tbb-torbutton  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

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


Comment:

 Duplicate of #27701 (and fixed in Tor Browser 8.5a5 for Android).

--
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] #28696 [Applications/Tor Browser]: Changing paths to Gradle dependencies are included in build

[Tor Bug Tracker & Wiki]

#28696: Changing paths to Gradle dependencies are included in build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:  #25164   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * status:  new => needs_review


Comment:

 Fixed in android-1203

  * Uses a hard-coded grade-dependencies location (as suggested by boklm)

--
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] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+
Changes (by sisbell):

 * status:  new => needs_review


Comment:

 Fixed in android-1203

  * Use pre-generated keystore
  * touch extension files so that timestamps remain same across builds
  * Use faketime with jarsigner to fix the timestamp of signatures

 Verified checksums match across builds

--
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] #28730 [Core Tor]: Reduced availability of HS v3 services compared with that of v2

[Tor Bug Tracker & Wiki]

#28730: Reduced availability of HS v3 services compared with that of v2
--+--
 Reporter:  jchevali  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I serve sshd behind HS v2 and v3 services and I have done for a long time.
 I've used both alpha, beta, and release builds of Tor 0.3.4 and 0.3.5 for
 this.

 Per my experience, HS v2 services are almost always available for the
 client to connect to, but HS v3 services not so much.  There are periods
 in which the client can't connect to v3 services (high CPU at client for a
 minute, then give up), while for the corresponding v2 service the
 connection is almost instant.

 Of course I would prefer to use v3 services if I can, if I observe they
 have the same degree of availability, but while I can't, I keep defining
 them in pairs (v3 + v2), because I know the time will come for some
 unspecified reason I can't use them (for hours at a time), and I want to
 keep for myself a workable alternative.

 If I'm the only one to notice this, perhaps it's because I like to exclude
 lots of countries in ExcludeNodes, both at server and client side, and
 perhaps this affects v3 services only, or not only but disproportionally
 (and perhaps no one uses like this so they don't know).  But that's the
 focus on my other ticket, #27811, and I won't postulate that here again.

 For the moment I've got no solution, other than in my experience HS v3
 services are less available therefore less dependable than v2 services.

--
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] #28707 [Applications/Tor Browser]: [meta] Backport Mozilla Security Patches (was: [meta] Backport Mozilla Secuity Patches)

[Tor Bug Tracker & Wiki]

#28707: [meta] Backport Mozilla Security Patches
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

Re: [tor-bugs] #28075 [Applications/Tor Browser]: Torbutton WARN: no SOCKS credentials found for current document.

[Tor Bug Tracker & Wiki]

#28075: Torbutton WARN: no SOCKS credentials found for current document.
-+-
 Reporter:  traumschule  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-torbutton, GeorgKoppen201810,|  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks! Cherry-picked to `master` (commit
 0b60f61087b514f74ea21513f14e691c2bd30493).

--
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] #28608 [Applications/Tor Browser]: Disable HTTP response throttling by default

[Tor Bug Tracker & Wiki]

#28608: Disable HTTP response throttling by default
--+--
 Reporter:  omg   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201812R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Thanks. Cherry-picked to `tor-browser-60.3.0esr-8.5-1` and `tor-
 browser-60.3.0esr-8.0-1` (commits d69efa2fe8f1fcb625d74251283cfa0e4f25cc01
 and 2789cecf98cd603f835711378d76ed06b4369609).

--
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] #28182 [Core Tor/Tor]: spec: Add to control-spec.txt some pluggable transport events

[Tor Bug Tracker & Wiki]

#28182: spec: Add to control-spec.txt some pluggable transport events
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 040-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * owner:  (none) => dgoulet
 * 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] #28182 [Core Tor/Tor]: spec: Add to control-spec.txt some pluggable transport events

[Tor Bug Tracker & Wiki]

#28182: spec: Add to control-spec.txt some pluggable transport events
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 040-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * 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] #25794 [Applications/Tor Browser]: Sanitize PointerEvent

[Tor Bug Tracker & Wiki]

#25794: Sanitize PointerEvent
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-fingerprinting, TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. Cherry-picked to `tor-browser-60.3.0esr-8.5-1` (commit
 c20210b1a017c4e94157c1acfbef18e878202ff4) and `tor-browser-60.3.0es-8.0-1`
 (commit 3c03aad30d2b2b0e92359f15a1a95cfb2354544e). I opened #28729 for
 thinking about how we should deal with that for Firefox 68 ESR.

--
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] #28729 [Applications/Tor Browser]: Think about enabling pointer events again in Tor Browser based on esr68

[Tor Bug Tracker & Wiki]

#28729: Think about enabling pointer events again in Tor Browser based on esr68
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff68-esr, tbb-
 Severity:  Normal   |  fingerprinting
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In #25794 we disabled pointer events for the time being as parts of
 Mozilla's defense were not ready yet and/or were largish backports.

 We should think about switching to Mozilla's defense and enabling pointer
 events again where they are enabled by a default Firefox.

--
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] #24325 [Applications/Tor Browser]: Add Czech (cs) localization to Tor browser

[Tor Bug Tracker & Wiki]

#24325: Add Czech (cs) localization to Tor browser
-+-
 Reporter:  mstanke  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization, czech, l10n,   |  Actual Points:
  translation|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by emmapeel):

 mstanke thanks for your patience! the browser is already in Czeck in the
 alpha version, and you can download it at
 https://dist.torproject.org/torbrowser/8.5a5/

 My personal opinion is that, if a user starts using Tor Browser because it
 has been localized for his or her language, and faces a problem... What is
 going to do?

 So the Support portal [1], which is a general FAQ, and the manual[2] ,
 seem for me interesting to have a real growth of the user base. And this
 gives me the reason to, for example, ask for more disk space to add more
 locales to the Browser.

 The Tor animation [3] is a great resource to translate, and is quite
 short. Helps users get familiarized with Tor.

 Then, there is the donate page, with a lot of content. I don't think this
 page is needed to introduce Tor Browser to a new user.

 [1] https://www.transifex.com/otf/tor-project-support-community-portal
 /support-portal/ - https://support.torproject.org/
 [2] https://www.transifex.com/otf/tor-project-support-community-portal
 /tbmanual-contentspot/ - https://tb-manual.torproject.org/
 [3] https://www.transifex.com/otf/tor-project-support-community-portal
 /tor-misc-tor_animationsrt/ -
 https://www.youtube.com/playlist?list=PLwyU2dZ3LJErtu3GGElIa7VyORE2B6H1H

--
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] #28669 [Core Tor/Tor]: Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc

[Tor Bug Tracker & Wiki]

#28669: Bug: ../src/feature/hs/hs_client.c:280:
retry_all_socks_conn_waiting_for_desc
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 Branch: `ticket28669_035_01`
 PR: https://github.com/torproject/tor/pull/563

--
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] #505 [Mixminion-Client]: mixminion flush: option -n not recognized

[Tor Bug Tracker & Wiki]

#505: mixminion flush: option -n not recognized
--+-
 Reporter:  tcr   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Client  |Version:  unspeficied
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  new => closed
 * resolution:  None => wontfix


Old description:

> minor issue: with "mixminion flush" the short name "-n " does
> not seem to work instead of "--count=".
>
> = Beginn =
>
> $ mixminion flush -n 1
> Mixminion version 0.0.8alpha3
> This software is for testing purposes only.  Anonymity is not guaranteed.
> option -n not recognized
> Usage: mixminion flush [options] [servername] ...
>   -h, --help Print this usage message and exit.
>   -v, --verbose  Display extra debugging messages.
>   -f , --config= Use a configuration file other than
> ~/.mixminionrc
>(You can also use MIXMINIONRC=FILE)
>   -n , --count=Send no more than  packets from the
> queue.
>
> EXAMPLES:
>   Try to send all currently queued packets.
>   mixminion flush
>   Try to send at most 10 currently queued packets, chosen at random.
>   mixminion flush -n 10
>   Try to send all currently queued packets for the server named
> 'Example1', or
>   for the server whose hostname is 'minion.example.com'.
>   mixminion flush Example1 minion.example.com
> $ mixminion flush --count=1
> Mixminion version 0.0.8alpha3
> This software is for testing purposes only.  Anonymity is not guaranteed.
> Sep 18 10:20:49.455 +0200 [INFO] Flushing packet queue
> Sep 18 10:20:49.502 +0200 [INFO] Found 1 pending packets
> Sep 18 10:20:49.588 +0200 [INFO] Sending 1 packets to server at [...]...
> Sep 18 10:20:49.590 +0200 [INFO] Connecting...
> Sep 18 10:20:50.032 +0200 [INFO] ... 1 sent
> Sep 18 10:20:50.633 +0200 [INFO] Queue flushed
>
> = Ende =
>
> BTW: there's no option to report for version 0.0.8alpha3
>
> [Automatically added by flyspray2trac: Operating System: Linux]

New description:

 minor issue: with "mixminion flush" the short name "-n " does
 not seem to work instead of "--count=".

 = Beginn =

 $ mixminion flush -n 1
 Mixminion version 0.0.8alpha3
 This software is for testing purposes only.  Anonymity is not guaranteed.
 option -n not recognized
 Usage: mixminion flush [options] [servername] ...
   -h, --help Print this usage message and exit.
   -v, --verbose  Display extra debugging messages.
   -f , --config= Use a configuration file other than
 ~/.mixminionrc
(You can also use MIXMINIONRC=FILE)
   -n , --count=Send no more than  packets from the queue.

 EXAMPLES:
   Try to send all currently queued packets.
   mixminion flush
   Try to send at most 10 currently queued packets, chosen at random.
   mixminion flush -n 10
   Try to send all currently queued packets for the server named
 'Example1', or
   for the server whose hostname is 'minion.example.com'.
   mixminion flush Example1 minion.example.com
 $ mixminion flush --count=1
 Mixminion version 0.0.8alpha3
 This software is for testing purposes only.  Anonymity is not guaranteed.
 Sep 18 10:20:49.455 +0200 [INFO] Flushing packet queue
 Sep 18 10:20:49.502 +0200 [INFO] Found 1 pending packets
 Sep 18 10:20:49.588 +0200 [INFO] Sending 1 packets to server at [...]...
 Sep 18 10:20:49.590 +0200 [INFO] Connecting...
 Sep 18 10:20:50.032 +0200 [INFO] ... 1 sent
 Sep 18 10:20:50.633 +0200 [INFO] Queue flushed

 = Ende =

 BTW: there's no option to report for version 0.0.8alpha3

 [Automatically added by flyspray2trac: Operating System: Linux]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #28728 [Applications/Tor Browser]: Update the Hacking wiki page

[Tor Bug Tracker & Wiki]

#28728: Update the Hacking wiki page
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should update the Hacking wiki pages with new instructions for partial
 builds. It is large and doesn't fully reflect the current state of Tor
 Browser.

 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking

--
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] #28727 [Obfuscation/Snowflake]: Remove `broker` and `relay` query string parameters from Snowflake proxy

[Tor Bug Tracker & Wiki]

#28727: Remove `broker` and `relay` query string parameters from Snowflake proxy
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 The browser proxy allows overriding the default
 [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/proxy/snowflake.coffee?id=596d28b57628dc57dd44080bb50b435c27c48861#n241
 broker] and [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/proxy/snowflake.coffee?id=596d28b57628dc57dd44080bb50b435c27c48861#n254
 relay] using query string parameters. This is a security vulnerability
 because it can turn browser proxies into a DoS vector against some third
 party. An attacker only has to get a massive number of browsers to visit a
 URL like
 !https://snowflake.example/embed.html?broker=https://victim.example and
 those browsers will start sending HTTPS requests to victim.example.

 This same vulnerability existed in flash proxy; here are the commits
 removing the feature there:
  *
 
[https://gitweb.torproject.org/flashproxy.git/commit/?id=a6af0da52a1c534799e563beba047ef02cc0a9e8
 Remove "facilitator" query string parameter.]
  *
 
[https://gitweb.torproject.org/flashproxy.git/commit/?id=d518f2615d977475dabaf4a46fbbe83c5a52801c
 Remove "client" and "relay" query string parameters.]

--
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] #315 [Mixminion-Client]: Incomplete installation

[Tor Bug Tracker & Wiki]

#315: Incomplete installation
--+-
 Reporter:  flynets   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Client  |Version:  0.0.8alpha2
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  new => closed
 * resolution:  None => wontfix


Old description:

> on make command i receive a big list of error, the with the catch "make
> >> file" i receive this error
>
> python setup.py build
> Using OpenSSL from ./contrib/openssl
> Host is little-endian
> /usr/lib/python2.4/config/Makefile
> running build
> running build_py
> running build_ext
> building 'mixminion._minionlib' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-
> prototypes -fPIC -DMM_L_ENDIAN=1 -I./contrib/openssl/include -Isrc
> -I/usr/include/python2.4 -c src/crypt.c -o
> build/temp.linux-i686-2.4/src/crypt.o -Wno-strict-prototypes
>
> can help me?
>
> [Automatically added by flyspray2trac: Operating System: Linux]

New description:

 on make command i receive a big list of error, the with the catch "make >>
 file" i receive this error

 python setup.py build
 Using OpenSSL from ./contrib/openssl
 Host is little-endian
 /usr/lib/python2.4/config/Makefile
 running build
 running build_py
 running build_ext
 building 'mixminion._minionlib' extension
 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-
 prototypes -fPIC -DMM_L_ENDIAN=1 -I./contrib/openssl/include -Isrc
 -I/usr/include/python2.4 -c src/crypt.c -o
 build/temp.linux-i686-2.4/src/crypt.o -Wno-strict-prototypes

 can help me?

 [Automatically added by flyspray2trac: Operating System: Linux]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #215 [Mixminion-Client]: mixminion creates path shorter than 3 nodes

[Tor Bug Tracker & Wiki]

#215: mixminion creates path shorter than 3 nodes
--+-
 Reporter:  simono|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Client  |Version:  0.0.7.1
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  new => closed
 * resolution:  None => wontfix


Old description:

> I was testing the new 0.0.8alpha1 server on laforge. To my
> understanding a message should pass at least three nodes to ensure my
> anonymity. I wanted to test the laforge node, so I sent the messages
> with -P laforge,~2  ( send the message through laforge and about two
> other nodes). As you can see in the output below the mixminion client
> selected to send my message through laforge and use laforge a a swap
> point. So the message will only go through 1 node. In my opinion the
> ~ option should calculate a minimum number of nodes so a
> message will go through at least three nodes. I have verified the bug on
> windows and FreeBSD, and I assume that the bug exists on all platforms.
>
> D:\mixminion\Mixminion-0.0.7.1>mixminion.exe send -t
> smtp:sim...@ostengaard.dk -
> i data -P laforge,~2
> Mixminion version 0.0.7.1
> This software is for testing purposes only.  Anonymity is not guaranteed.
> Dec 04 19:39:37.789 +0100 [INFO] Downloading directory from
> http://mixminion.net
> /directory/Directory.gz
> Dec 04 19:39:44.579 +0100 [INFO] Validating directory
> Dec 04 19:39:45.139 +0100 [WARN] This software is newer than any version
> on the
> recommended list.
> Dec 04 19:39:45.139 +0100 [INFO] Generating payload(s)...
> Dec 04 19:39:45.149 +0100 [INFO] Selected path is laforge:laforge
> Dec 04 19:39:45.229 +0100 [INFO] Packet queued
> Dec 04 19:39:45.229 +0100 [INFO] Connecting...
> Dec 04 19:39:47.743 +0100 [INFO] ... 1 sent
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 I was testing the new 0.0.8alpha1 server on laforge. To my
 understanding a message should pass at least three nodes to ensure my
 anonymity. I wanted to test the laforge node, so I sent the messages
 with -P laforge,~2  ( send the message through laforge and about two
 other nodes). As you can see in the output below the mixminion client
 selected to send my message through laforge and use laforge a a swap
 point. So the message will only go through 1 node. In my opinion the
 ~ option should calculate a minimum number of nodes so a
 message will go through at least three nodes. I have verified the bug on
 windows and FreeBSD, and I assume that the bug exists on all platforms.

 D:\mixminion\Mixminion-0.0.7.1>mixminion.exe send -t
 smtp:sim...@ostengaard.dk -
 i data -P laforge,~2
 Mixminion version 0.0.7.1
 This software is for testing purposes only.  Anonymity is not guaranteed.
 Dec 04 19:39:37.789 +0100 [INFO] Downloading directory from
 http://mixminion.net
 /directory/Directory.gz
 Dec 04 19:39:44.579 +0100 [INFO] Validating directory
 Dec 04 19:39:45.139 +0100 [WARN] This software is newer than any version
 on the
 recommended list.
 Dec 04 19:39:45.139 +0100 [INFO] Generating payload(s)...
 Dec 04 19:39:45.149 +0100 [INFO] Selected path is laforge:laforge
 Dec 04 19:39:45.229 +0100 [INFO] Packet queued
 Dec 04 19:39:45.229 +0100 [INFO] Connecting...
 Dec 04 19:39:47.743 +0100 [INFO] ... 1 sent

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #206 [Mixminion-Client]: Failure to create user data on single-users win32 systems

[Tor Bug Tracker & Wiki]

#206: Failure to create user data on single-users win32 systems
--+-
 Reporter:  quicksilver   |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Client  |Version:  0.0.7.1
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  assigned => closed
 * resolution:  None => wontfix


Old description:

> Hi,
>
> There is a problem when running mixminion on single-user win32 systems.
> Some systems have never been setup with any accounts at all. When
> mixminion tries to place the user data in the expected user directory
> (c:\documents and settings\[username]), it fails because the directory
> does not exist. It is customary on these systems to put the user data in
> the application's directory.
>
> We have a work-around, discovered by Ed Langenback, that if you put a
> subdir in the mixminion dir called "~" (no quotes) it will fool mixminion
> into using that directory for user data. One requirement in using this is
> that mixminion must always be started and used from it own directory.
>
> [Automatically added by flyspray2trac: Operating System: Windows]

New description:

 Hi,

 There is a problem when running mixminion on single-user win32 systems.
 Some systems have never been setup with any accounts at all. When
 mixminion tries to place the user data in the expected user directory
 (c:\documents and settings\[username]), it fails because the directory
 does not exist. It is customary on these systems to put the user data in
 the application's directory.

 We have a work-around, discovered by Ed Langenback, that if you put a
 subdir in the mixminion dir called "~" (no quotes) it will fool mixminion
 into using that directory for user data. One requirement in using this is
 that mixminion must always be started and used from it own directory.

 [Automatically added by flyspray2trac: Operating System: Windows]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #3663 [Mixminion-Client]: Fatal error on Mixminion

[Tor Bug Tracker & Wiki]

#3663: Fatal error on Mixminion
--+
 Reporter:  nito  |  Owner:  nito
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Mixminion-Client  |Version:  Mixminion: 0.0.7.1
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

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


Comment:

 mixminion is dead; long live mixminion

--
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] #24838 [Core Tor/Fallback Scripts]: Ignore addresses in the fallback whitelist

[Tor Bug Tracker & Wiki]

#24838: Ignore addresses in the fallback whitelist
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Fallback Scripts|Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, fallback,   |  Actual Points:
  034-triage-20180328, 034-removed-20180328, |
  fast-fix, 035-roadmap-subtask, 035-triaged-|
  in-20180711|
Parent ID:  #24786   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by phoul):

 * cc: phoul (added)


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

Re: [tor-bugs] #1071 [Mixminion-Server]: Variable undefined in sendSMTPMessage

[Tor Bug Tracker & Wiki]

#1071: Variable undefined in sendSMTPMessage
--+-
 Reporter:  zax   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Server  |Version:  unspeficied
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  new => closed
 * resolution:  None => wontfix


Old description:

> In lib/mixminion/server/Modules.py - sendSMTPMessage
>
> In initial clause of the conditional
>
> if cfgSection['SendmailCommand'] is not None:
>
> res is not defined and causes the return statement to fail.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 In lib/mixminion/server/Modules.py - sendSMTPMessage

 In initial clause of the conditional

 if cfgSection['SendmailCommand'] is not None:

 res is not defined and causes the return statement to fail.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #1070 [Mixminion-Server]: Missing space between command and opts

[Tor Bug Tracker & Wiki]

#1070: Missing space between command and opts
--+-
 Reporter:  zax   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Server  |Version:  CVS
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  new => closed
 * resolution:  None => wontfix


Old description:

> There is a space missing between the command and options in Modules.py
> sendSMTPMessage.
>
> --- Modules.py.old  2009-08-26 09:58:39.0 +0100
> +++ Modules.py  2009-08-26 09:58:56.0 +0100
> @@ -1463,7 +1463,7 @@
>  #  messages in a row.
>  if cfgSection['SendmailCommand'] is not None:
>  cmd, opts = cfgSection['SendmailCommand']
> -command = cmd + (" ".join(opts))
> +command = cmd + " " + (" ".join(opts))
>  f = os.popen(command, 'w')
>  f.write(message)
>  f.close()
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 There is a space missing between the command and options in Modules.py
 sendSMTPMessage.

 --- Modules.py.old  2009-08-26 09:58:39.0 +0100
 +++ Modules.py  2009-08-26 09:58:56.0 +0100
 @@ -1463,7 +1463,7 @@
  #  messages in a row.
  if cfgSection['SendmailCommand'] is not None:
  cmd, opts = cfgSection['SendmailCommand']
 -command = cmd + (" ".join(opts))
 +command = cmd + " " + (" ".join(opts))
  f = os.popen(command, 'w')
  f.write(message)
  f.close()

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #214 [Mixminion-Server]: IOError when flushing log

[Tor Bug Tracker & Wiki]

#214: IOError when flushing log
--+-
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Server  |Version:  0.0.7.1
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  assigned => closed
 * resolution:  None => wontfix


Old description:

> Reported by Marco Calamari.
>
> Sometimes, it seems, trying to flush the logfile descriptor gives an
> IOError (errno 5: EIO).
>
> I have no idea why this is happening, but it has been reported on
> multiple hosts.
>
> File "/usr/lib/python2.3/site-packages/mixminion/TLSConnection.py",
> line 435, in process
> self.__close(gotClose=1)
> File "/usr/lib/python2.3/site-packages/mixminion/TLSConnection.py",
> line 256, in __close
> LOG.warn("Couldn't connect to %s",self.address)
> File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
> 1010, in warn
> self.log("WARN", message, *args)
> File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
> 974, in log
> self._log(severity, message, args)
> File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
> 995, in _log
> h.write(severity, m)
> File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
> 841, in write
> self.file.flush()
>   IOError: [Errno 5] Input/output error
> Oct 17 07:58:50.750 +0200 [FATAL] Shutting down because of exception:
> exceptions.IOError
>

> [Automatically added by flyspray2trac: Operating System: All]

New description:

 Reported by Marco Calamari.

 Sometimes, it seems, trying to flush the logfile descriptor gives an
 IOError (errno 5: EIO).

 I have no idea why this is happening, but it has been reported on multiple
 hosts.

 File "/usr/lib/python2.3/site-packages/mixminion/TLSConnection.py",
 line 435, in process
 self.__close(gotClose=1)
 File "/usr/lib/python2.3/site-packages/mixminion/TLSConnection.py",
 line 256, in __close
 LOG.warn("Couldn't connect to %s",self.address)
 File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
 1010, in warn
 self.log("WARN", message, *args)
 File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
 974, in log
 self._log(severity, message, args)
 File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
 995, in _log
 h.write(severity, m)
 File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
 841, in write
 self.file.flush()
   IOError: [Errno 5] Input/output error
 Oct 17 07:58:50.750 +0200 [FATAL] Shutting down because of exception:
 exceptions.IOError


 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #39 [Mixminion-Server]: Certificate rotation sometimes does not happen.

[Tor Bug Tracker & Wiki]

#39: Certificate rotation sometimes does not happen.
--+-
 Reporter:  weasel|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Server  |Version:  0.0.7
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  assigned => closed
 * resolution:  None => wontfix


Old description:

> [Moved from bugzilla]
> Reporter: ni...@alum.mit.edu (Nick Mathewson)
>
> Description:
> Opened: 2004-06-06 21:54
>

>
> Sometimes, Mixminion servers become inoperable because they do not rotate
> their TLS certificates when they expire.
>
> The cause for this bug is unknown. The bug has existed since at least
> 0.0.6.
>
> You can tell that *another* server has come down with this bug because
> your log says something like:
>
> Jun 06 00:55:08.643 -0400 [WARN] Certificate error: Invalid certificate
> from 'lakshmi' at mixminion.pseudonymity.net:48099 (fd 9):
> Certificate has expired [at Jun  6 00:05:00 2004 GMT]. Shutting down
> connection.
>
> There are no such obvious signs on the failing server side, AFAIK.
>
> As a band-aid, I could make TLS certificates get roatated daily, no
> matter what.  (Right now, their rotation interval is tied to
> packet key rotation.)  This is probably the right thing to do, but before
> I do it, I want to understand why on earth it is happening.
>

> --- Additional Comments From Nick Mathewson 2004-06-23 21:51 ---
>
> Actually, the diagnosis may be completely wrong.  Looking at
> ServerKeys.py, it seems like (by default)
> certificates only have 5 minutes of sloppiness on either side of their
> lifetime.  Thus, if anybody is
> skewed by more than 5 minutes, their certificate will be invalid for the
> amount of their clock skew.
>
> Hm... I'll up the interval for now, but I really need a way to detect
> relative skew.
>

> --- Additional Comments From Nick Mathewson 2004-08-26 05:12 ---
>
> I think I might have it nailed now -- I changed the code to warn about
> clock skew when it downloads a directory, bumped up the
> skew tolerance, and rewrote the event scheduling code to be less clever
> and more obviously reliable.  I also improved the warning
> messages so we can find out how badly expired certs are expired.
>
> If anybody sees this problem when running CVS code, please let me know.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 [Moved from bugzilla]
 Reporter: ni...@alum.mit.edu (Nick Mathewson)

 Description:
 Opened: 2004-06-06 21:54



 Sometimes, Mixminion servers become inoperable because they do not rotate
 their TLS certificates when they expire.

 The cause for this bug is unknown. The bug has existed since at least
 0.0.6.

 You can tell that *another* server has come down with this bug because
 your log says something like:

 Jun 06 00:55:08.643 -0400 [WARN] Certificate error: Invalid certificate
 from 'lakshmi' at mixminion.pseudonymity.net:48099 (fd 9):
 Certificate has expired [at Jun  6 00:05:00 2004 GMT]. Shutting down
 connection.

 There are no such obvious signs on the failing server side, AFAIK.

 As a band-aid, I could make TLS certificates get roatated daily, no matter
 what.  (Right now, their rotation interval is tied to
 packet key rotation.)  This is probably the right thing to do, but before
 I do it, I want to understand why on earth it is happening.


 --- Additional Comments From Nick Mathewson 2004-06-23 21:51 ---

 Actually, the diagnosis may be completely wrong.  Looking at
 ServerKeys.py, it seems like (by default)
 certificates only have 5 minutes of sloppiness on either side of their
 lifetime.  Thus, if anybody is
 skewed by more than 5 minutes, their certificate will be invalid for the
 amount of their clock skew.

 Hm... I'll up the interval for now, but I really need a way to detect
 relative skew.


 --- Additional Comments From Nick Mathewson 2004-08-26 05:12 ---

 I think I might have it nailed now -- I changed the code to warn about
 clock skew when it downloads a directory, bumped up the
 skew tolerance, and rewrote the event scheduling code to be less clever
 and more obviously reliable.  I also improved the warning
 messages so we can find out how badly expired certs are expired.

 If anybody sees this problem when running CVS code, please let me know.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 mixminion is dead; long live mixminion

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
__

Re: [tor-bugs] #6 [Mixminion-Server]: Confused server clocks can screw up timing

[Tor Bug Tracker & Wiki]

#6: Confused server clocks can screw up timing
--+-
 Reporter:  weasel|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Mixminion-Server  |Version:  0.0.4
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  assigned => closed
 * resolution:  None => wontfix


Old description:

> [Moved from bugzilla]
> Reporter: ni...@alum.mit.edu (Nick Mathewson)
> Description:
> Opened: 2003-08-29 20:44
>

>
> Some users have reported that the mixminion server has a nasty failure
> mode when
> a server's clock moves backwards by a large interval.  When the server
> asks
> "when did we last (do something)", the answer "tomorrow" can cause
> crashes or
> weird behavior.
>
> I'm deferring this for a while, because (a) I want to get 0.0.5 put to
> bed, and
> (b) the workaround is trivial: keep your clock set right.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 [Moved from bugzilla]
 Reporter: ni...@alum.mit.edu (Nick Mathewson)
 Description:
 Opened: 2003-08-29 20:44



 Some users have reported that the mixminion server has a nasty failure
 mode when
 a server's clock moves backwards by a large interval.  When the server
 asks
 "when did we last (do something)", the answer "tomorrow" can cause crashes
 or
 weird behavior.

 I'm deferring this for a while, because (a) I want to get 0.0.5 put to
 bed, and
 (b) the workaround is trivial: keep your clock set right.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 mixminion is dead; long live mixminion

--
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] #28726 [Obfuscation/Snowflake]: Loosen restrictions on message sizes in WebSocket server

[Tor Bug Tracker & Wiki]

#28726: Loosen restrictions on message sizes in WebSocket server
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 ahf couldn't bootstrap beyond 25% when running his own client, broker, and
 WebSocket server (i.e., not using the public infrastructure). I asked him
 to try relaxing the message size limit in server.go:
 {{{
 -const maxMessageSize = 64 * 1024
 +const maxMessageSize = 10 * 1024 * 1024
 }}}
 This enabled him to bootstrap to 100% at least once, but "it still doesn't
 work most of the times i bootstrap from a clean tor instance."

 What I suspect is happening is that the browser proxy is sending WebSocket
 messages larger than 64 KB, which is causing the WebSocket server to error
 and tear down the connection. How much larger than 64 KB, I don't know.
 The underlying websocket package [https://gitweb.torproject.org/pluggable-
 
transports/websocket.git/tree/websocket/websocket.go?id=e0bb5efd8d78d372711652ec061923debe7f5cb0#n143
 returns an error] like
 {{{
 "frame payload length of %d exceeds maximum of %d"
 }}}
 but we currently [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/server/server.go?id=596d28b57628dc57dd44080bb50b435c27c48861#n115
 throw away that error message] as a precaution until we've [ticket:21304
 audited error logs] to ensure that IP addresses don't appear.

 As an alternative to allowing larger messages at the server, we could try
 to ensure that proxies don't produce such over-large messages.
 [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/proxy/proxypair.coffee?id=596d28b57628dc57dd44080bb50b435c27c48861#n133
 Here], in `onClientToRelayMessage`, we could break `recv` into 64 KB
 chunks before pushing them onto `@c2rSchedule`. In proxy-go, I suspect we
 are succeeding by accident: the code [https://gitweb.torproject.org
 /pluggable-transports/snowflake.git/tree/proxy-
 go/snowflake.go?id=596d28b57628dc57dd44080bb50b435c27c48861#n211 uses]
 [https://golang.org/pkg/io/#Copy io.Copy], which must use an internal
 buffer smaller than 64 KB.

 Taking a longer view, there's no good reason for a message size limit to
 exist at all. It [https://gitweb.torproject.org/pluggable-
 transports/websocket.git/tree/doc/websocket-
 transport.txt?id=e0bb5efd8d78d372711652ec061923debe7f5cb0#n178 stems from
 a time] when I was naive in Go and didn't know how to provide an
 implementation that didn't buffer the entirety of each message in memory.
 The reason I wrote my own WebSocket implementation was that the other one
 that existed at the time, golang.org/x/net/websocket, had no limits on
 message size at all, and you could trivially DoS it (out of memory) by
 sending a 1 TB message. (Looks like
 [https://github.com/golang/net/commit/6dba816f1056709e29a1c442883cab1336d3c083
 #diff-bf56d570e62cdb573c86b18526296117 this got fixed] in 2016.) A good
 solution would be to rewrite our WebSocket library to provide a streaming
 interface without message buffering, so to investigate whether other
 WebSocket libraries like https://godoc.org/github.com/gorilla/websocket
 can 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] #28725 [Applications/Tor Browser]: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557

[Tor Bug Tracker & Wiki]

#28725: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557
-+-
 Reporter:  dcf  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake tbb-rbm,   |  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  snowflake tbb-rbm => snowflake tbb-rbm, TorBrowserTeam201812R


--
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] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  GeorgKoppen201811, TorBrowserTeam201812|
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:19 boklm]:
 > Replying to [comment:17 gk]:
 > > Okay, I have an updated branch for review, `bug_26843_v6`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26843_v6&id=1313336490abb4773e20d40347db79e46c26727e).
 > >
 > > Compared to `bug_26843_v5` it is rebased on the latest `master` and
 contains an indication in the bundle name that the .apk is actually not a
 single-locale one, using "multi" as Mozilla does.
 >
 > It seems that when we are running `AB_CD=multi ./mach package`, the
 variable `MOZ_CHROME_MULTILOCALE` contains all the locales we want.
 However, when we run `./mach build chrome-[% lang %]`, only the current
 and previous locales are included in `MOZ_CHROME_MULTILOCALE`. Is `./mach
 build chrome-[% lang %]` ignoring the variable `MOZ_CHROME_MULTILOCALE`
 (and in this case it doesn't matter if it doesn't contain all the
 locales), or should we add all the locales before running the first
 `./mach build chrome-[% lang %]`?

 Yeah, `./mach build` is ignoring it. But `./mach package` needs it. I used
 the `FOREACH` loop to populate the env variable while cycling through the
 locales anyway.

 > We could use this line to set all the locales in
 `MOZ_CHROME_MULTILOCALE`:
 > {{{
 > export MOZ_CHROME_MULTILOCALE='[% tmpl(c('var/locales').join(' ')) %]'
 > }}}

 That's probably better, yes. I'll take that approach instead of my clumsy
 one.

 > An other minor thing: I think it would be better to extract the locales
 in a sub-directory (such as `/var/tmp/dist/locales`) instead of directly
 in `/var/tmp/dist`.

 Okay, fine with me.

--
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] #28498 [Core Tor/Nyx]: Unable to refresh connection circuit

[Tor Bug Tracker & Wiki]

#28498: Unable to refresh connection circuit
--+---
 Reporter:  cyberpunks|  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Connection|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi cyberpunks, sorry about the long delay! Been busy dealing with Stem
 additions. Please run 'nyx --debug' and attach the debug output when you
 encounter this issue (minus any data you feel is sensitive). This should
 help me see why the display isn't being refreshed in a timely fashion for
 you.

--
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] #28628 [Applications/Tor Browser]: Introduce New Security Settings to users

[Tor Bug Tracker & Wiki]

#28628: Introduce New Security Settings to users
---+--
 Reporter:  antonela   |  Owner:  dunqan
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID:  #25658 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by antonela):

 Dunqan both options looks great. I'll loop the comms team to review this
 copy and i'll update the prototype once is ready.
 Thanks a lot for working on this!!!

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

Re: [tor-bugs] #28725 [Applications/Tor Browser]: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557

[Tor Bug Tracker & Wiki]

#28725: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake tbb-rbm |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


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

Re: [tor-bugs] #28725 [Applications/Tor Browser]: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557

[Tor Bug Tracker & Wiki]

#28725: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake tbb-rbm |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "0001-Bug-28725-Upgrade-go-webrtc-to-
 dcbfc825aa33471253a5d.patch" added.


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

[tor-bugs] #28725 [Applications/Tor Browser]: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557

[Tor Bug Tracker & Wiki]

#28725: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557
--+---
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  snowflake tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 The primary goal of this upgrade was to simplify by removing
 `-D_GLIBCXX_USE_CXX11_ABI=1`, which is [https://github.com/keroserene/go-
 webrtc/commit/a3140c36f9933013ad2e66bc21358a1bfea95a95 no longer required]
 in go-webrtc. The upgrade also required upgrades of the dependencies
 webrtc and depot_tools.

 I tested this with `make testbuild` and running the linux-x86_64 build. I
 haven't run the linux-i686 and osx-x86_64 builds.

--
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] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  GeorgKoppen201811, TorBrowserTeam201812|
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_review => needs_revision
 * keywords:  tbb-mobile, TBA-a2, GeorgKoppen201811, TorBrowserTeam201812R
 => tbb-mobile, TBA-a2, GeorgKoppen201811, TorBrowserTeam201812


Comment:

 Replying to [comment:17 gk]:
 > Okay, I have an updated branch for review, `bug_26843_v6`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26843_v6&id=1313336490abb4773e20d40347db79e46c26727e).
 >
 > Compared to `bug_26843_v5` it is rebased on the latest `master` and
 contains an indication in the bundle name that the .apk is actually not a
 single-locale one, using "multi" as Mozilla does.

 It seems that when we are running `AB_CD=multi ./mach package`, the
 variable `MOZ_CHROME_MULTILOCALE` contains all the locales we want.
 However, when we run `./mach build chrome-[% lang %]`, only the current
 and previous locales are included in `MOZ_CHROME_MULTILOCALE`. Is `./mach
 build chrome-[% lang %]` ignoring the variable `MOZ_CHROME_MULTILOCALE`
 (and in this case it doesn't matter if it doesn't contain all the
 locales), or should we add all the locales before running the first
 `./mach build chrome-[% lang %]`?

 We could use this line to set all the locales in `MOZ_CHROME_MULTILOCALE`:
 {{{
 export MOZ_CHROME_MULTILOCALE='[% tmpl(c('var/locales').join(' ')) %]'
 }}}

 An other minor thing: I think it would be better to extract the locales in
 a sub-directory (such as `/var/tmp/dist/locales`) instead of directly in
 `/var/tmp/dist`.

--
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] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Very High  |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.1-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-doc, tor-hs, 035-must  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by dgoulet):

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


Comment:

 Merged!

--
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] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Very High  |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, tor-hs, 035-must  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by dgoulet):

 * status:  needs_review => merge_ready


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

Re: [tor-bugs] #28724 [Core Tor/sbws]: sbws doesn't actually read config files given as an argument

[Tor Bug Tracker & Wiki]

#28724: sbws doesn't actually read config files given as an argument
---+---
 Reporter:  pastly |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by pastly):

 * status:  new => needs_review


Comment:

 https://github.com/torproject/sbws/pull/306

 DIdn't add to changelog because IDR if I'm supposed to.

--
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] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sisbell):

 Replying to [comment:3 gk]:


 > I guess the second-best (or third-best :) ) solution would be using
 tools like `faketime` (which we do at some places to deal with timestamp
 issues).
 Yes this works. Thanks.

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

[tor-bugs] #28724 [Core Tor/sbws]: sbws doesn't actually read config files given as an argument

[Tor Bug Tracker & Wiki]

#28724: sbws doesn't actually read config files given as an argument
---+---
 Reporter:  pastly |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Major  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 `sbws -c foo.ini scanner` doesn't read `foo.ini` because
 [https://gitweb.torproject.org/sbws.git/tree/sbws/util/config.py#n67 when
 we determine that it exists in _get_user_config() we don't actually do
 anything with 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] #28721 [- Select a component]: Tor Disabled

[Tor Bug Tracker & Wiki]

#28721: Tor Disabled
--+--
 Reporter:  seamusf   |  Owner:  (none)
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  user disappeared
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by seamusf):

 * status:  new => closed
 * resolution:   => user disappeared


--
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] #24325 [Applications/Tor Browser]: Add Czech (cs) localization to Tor browser

[Tor Bug Tracker & Wiki]

#24325: Add Czech (cs) localization to Tor browser
-+-
 Reporter:  mstanke  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization, czech, l10n,   |  Actual Points:
  translation|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 We are done here. This shipped in 8.5a4 and should be actually working in
 8.5a5.

--
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] #28636 [Core Tor/Tor]: Address WTF-PAD comments by Nick (2018-11-27 over IRC)

[Tor Bug Tracker & Wiki]

#28636: Address WTF-PAD comments by Nick (2018-11-27 over IRC)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28632   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:3 nickm]:
 > To be more clear: I'd be happy to help with some/all of these, and I am
 not 100% sure that they all need to go in before WTF-pad is merged if any
 of them will be very hard... though it should really go in before it's
 turned on by default.

 Yep, agreed. That's why I made this ticket a child of #28632 and not of
 #28142.
 Like you said, we MUST address the above before turning it on by default,
 but not necessarily before merging the big branch.

--
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] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Very High  |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, tor-hs, 035-must  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by asn):

 * reviewer:  asn => dgoulet


Comment:

 Counterproposal in my `ticket28275_035_01` branch:
 https://github.com/torproject/tor/pull/562

--
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] #28723 [Webpages/Website]: https://www.torproject.org/docs/debian.html.en lists 0.3.4 repo but only 0.3.5 is there

[Tor Bug Tracker & Wiki]

#28723: https://www.torproject.org/docs/debian.html.en lists 0.3.4 repo but only
0.3.5 is there
--+--
 Reporter:  tom   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Compare https://deb.torproject.org/torproject.org/dists/ with
 https://www.torproject.org/docs/debian.html.en

 The webpage has 0.3.4 experimental in the dropdown; but only 0.3.5
 experimental is on deb.tpo

--
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] #28608 [Applications/Tor Browser]: Disable HTTP response throttling by default

[Tor Bug Tracker & Wiki]

#28608: Disable HTTP response throttling by default
--+--
 Reporter:  omg   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201812R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 r=brade, r=mcs
 The patch looks good to us.

--
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] #24325 [Applications/Tor Browser]: Add Czech (cs) localization to Tor browser

[Tor Bug Tracker & Wiki]

#24325: Add Czech (cs) localization to Tor browser
-+-
 Reporter:  mstanke  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  localization, czech, l10n,   |  Actual Points:
  translation|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mstanke):

 Hi emmapeel.

 I already started working on that after advice from Erin McConnell,
 however compared to the product itself it will take some extra time
 probably. We already have quite hard time keeping up with Mozilla SUMO.

 Are all the four files in Transifex of the same priority as indicated
 there, or is some of the content more visible and likely to be visited by
 users of 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] #28075 [Applications/Tor Browser]: Torbutton WARN: no SOCKS credentials found for current document.

[Tor Bug Tracker & Wiki]

#28075: Torbutton WARN: no SOCKS credentials found for current document.
-+-
 Reporter:  traumschule  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, GeorgKoppen201810,|  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 The patch looks good and the change seems like a good 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

[tor-bugs] #28722 [Webpages/Website]: Add cs el hu ka locales to the Tor Browser download pages

[Tor Bug Tracker & Wiki]

#28722: Add cs el hu ka locales to the Tor Browser download pages
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  TorBrowserTeam201812
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #28082 we added 4 new locales to Tor Browser. We should also add them
 to the alpha download pages.

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