Re: [tor-bugs] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:  1
 Reviewer:  mikeperry  |Sponsor:
---+---

Comment (by juga):

 Replying to [comment:7 mikeperry]:
 > Hrmm. I might need to look at a lot more of the sbws code, but I don't
 think the patch is the best way to address the possibility that the queue
 may be full. If the queue can also be added from another thread, then
 there still can be a race where it ends up full after the loop check but
 before the next statement.

 I've never seen the case where the queue is full and it's very unlikely
 that it'll get full by other thread, since measurement threads take more
 than 5 seconds to complete, and the the `ResultDump` thread is getting
 measurements from the queue every second
 
(https://github.com/torproject/sbws/blob/ada70d4f85ac7ce6f9847eeae832ec7620106470/sbws/lib/resultdump.py#L589)

 > I would instead make it do something like:
 >
 > {{{
 > while True:
 >   try:
 > result_dump.queue.put(measurement_result, timeout=1)
 >   except Full as e:
 > log.info('The results queue is full, after 1 second it should not be
 full')
 > }}}
 >
 > That way, if the timeout hits because the queue is full for a second,
 the exception is thrown, and then you log, and then you try again for
 another second (at which point it should succeed, but in case it does not,
 you just log and try again rather than raise an uncaught Full exception).

 That was my first though, but the `while True` will make this call to
 block forever, and the callback has to return immediately. From
 
https://docs.python.org/3.5/library/multiprocessing.html#multiprocessing.pool.Pool.apply_async:

 "Callbacks should complete immediately since otherwise the thread which
 handles the results will get blocked."

 So something like that will be only possible if there was yet another
 thread handling the callback to don't block the main process (like
 `ResultDump` does), but that would add unneeded complexity.

--
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] #29508 [Core Tor/Tor]: KIST does not check the right channel's sched_heap_idx when readding channels

[Tor Bug Tracker & Wiki]

#29508: KIST does not check the right channel's sched_heap_idx when readding
channels
---+---
 Reporter:  pastly |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, kist, 040-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by dgoulet):

 * keywords:   => tor-sched, kist, 040-backport
 * reviewer:   => dgoulet
 * status:  needs_review => merge_ready


Comment:

 lgtm; Here is a PR and 040 branch:

 Branch: ticket29508_040_01
 PR: https://github.com/torproject/tor/pull/704

--
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] #28940 [Obfuscation/Pluggable transport]: Add support for LOG to goptlib

[Tor Bug Tracker & Wiki]

#28940: Add support for LOG to goptlib
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:  Sponsor19
-+-

Comment (by dcf):

 Replying to [comment:10 ahf]:
 > I lifted out the logger and the STATUS API into a `goptlibext` package
 at https://github.com/ahf/goptlibext

 Would it help if I exposed the [https://gitweb.torproject.org/pluggable-
 transports/goptlib.git/tree/pt.go?h=v1.0.0#n262 pt.line function]? It's
 what's used internally to provide all the line-oriented output for other
 functions like `pt.Cmethod` and `pt.ProxyDone`. Or is writing to
 `pt.Stdout` good enough for your purposes?

--
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] #29378 [Applications/Tor Browser]: Remove 83.212.101.3 from default bridges

[Tor Bug Tracker & Wiki]

#29378: Remove 83.212.101.3 from default bridges
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201902R, tbb-rbm,  |  Actual Points:
  tbb-bridges|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * keywords:  TorBrowserTeam201902R, tbb-rbm => TorBrowserTeam201902R, tbb-
 rbm, tbb-bridges


--
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] #29436 [Core Tor/Tor]: Add scripts to test unit test coverage determinism

[Tor Bug Tracker & Wiki]

#29436: Add scripts to test unit test coverage determinism
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 The goal here is just to output the diff files? The script looks like it
 does that just fine, so merge ready for that.. But what consumes this
 output? Should we have a different script that fails the test if the
 coverage diff is nonzero?

--
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] #29435 [Core Tor/Tor]: coverage script broken by library refactoring

[Tor Bug Tracker & Wiki]

#29435: coverage script broken by library refactoring
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  trivial testing coverage  |  Actual Points:  0
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Looks 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] #29499 [Core Tor/Tor]: permission error: nyx requires executable permission bit for `/var/lib/tor`

[Tor Bug Tracker & Wiki]

#29499: permission error: nyx requires executable permission bit for 
`/var/lib/tor`
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Minor | Resolution:
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

 * component:  - Select a component => Core Tor/Tor


Comment:

 I'm not spotting anything here that's nyx specific. Sending this over to
 the network team. The executable bit shouldn't matter - all that matters
 is that controller applications can read the cookie.

--
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] #29508 [Core Tor/Tor]: KIST does not check the right channel's sched_heap_idx when readding channels

[Tor Bug Tracker & Wiki]

#29508: KIST does not check the right channel's sched_heap_idx when readding
channels
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  new => needs_review


Comment:

 https://gitweb.torproject.org/user/pastly/tor.git/log/?h=bug29508

--
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] #29298 [Core Tor/Tor]: Explicitly specify histogram bin endpoints/widths

[Tor Bug Tracker & Wiki]

#29298: Explicitly specify histogram bin endpoints/widths
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad 041-proposed network-team-   |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #28631   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 Replying to [comment:4 asn]:
 > Spec branch pushed in https://github.com/asn-d6/torspec/tree/bug29298 .
 >
 > Mike do you like it?

 We should provide arrays with the example: https://github.com/mikeperry-
 tor/torspec/tree/bug29298

 There's also the question as to if the infinity bin should be forced to
 have Infinity-1 as its left endpoint, or if we should allow this
 discontinuity as we have there..

--
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] #29508 [Core Tor/Tor]: KIST does not check the right channel's sched_heap_idx when readding channels

[Tor Bug Tracker & Wiki]

#29508: KIST does not check the right channel's sched_heap_idx when readding
channels
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Link to the section of code as of right now:
 https://gitweb.torproject.org/tor.git/tree/src/core/or/scheduler_kist.c#n724

 The buggy code

 {{{
   /* Re-add any channels we need to */
   if (to_readd) {
 SMARTLIST_FOREACH_BEGIN(to_readd, channel_t *, readd_chan) {
   scheduler_set_channel_state(readd_chan, SCHED_CHAN_PENDING);
   if (!smartlist_contains(cp, readd_chan)) {
 if (!SCHED_BUG(chan->sched_heap_idx != -1, chan)) {
   /*  Note that the check above is in theory redundant with
* the smartlist_contains check.  But let's make sure we're
* not messing anything up, and leave them both for now. */
   smartlist_pqueue_add(cp, scheduler_compare_channels,
  offsetof(channel_t, sched_heap_idx),
 readd_chan);
 }
   }
 } SMARTLIST_FOREACH_END(readd_chan);
 smartlist_free(to_readd);
   }
 }}}

 The code wrapped in`SCHED_BUG` should be checking `readd_chan` not `chan`.

 This has never been an issue in mainline-Tor because the scheduler never
 leaves its while loop with channels in `channels_pending`. But if you make
 changes to Tor's code that allow for the scheduler to leave its loop
 without emptying `channels_pending`, then this condition will often fail,
 which cumulates in  tor ultimately seemingly forgetting about the channel
 and letting it sit idle.

 Branch incoming.

--
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] #29495 [Webpages/Website]: Running site fails with python 2.x

[Tor Bug Tracker & Wiki]

#29495: Running site fails with python 2.x
--+--
 Reporter:  atagar|  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Hi Hiro, I installed lector via their
 [https://www.getlektor.com/downloads/ download instructions]. Lector works
 under both python2 or python3, and installs under whatever the first
 'python' executable in your path points to (which for most people is
 python2).

 To reinstall lector with python3 I adjusted their
 [https://www.getlektor.com/install.sh install.sh] a tad to instead pick
 the python3 executable.

 > The idea is that python2 will not be supported in a few months

 That is incorrect. Python will [https://pythonclock.org/ cease to be
 supported in January 2020]. Stem and Nyx remain compatible with Python 2.x
 and will continue to do so until the PSF drops support.

 

 I am **not** suggesting that the site support python 2.x, but I **am**
 suggesting that the site should abort with a useful message saying "python
 2.x is not supported". The code that errors is attempting to support both
 python versions which is why I spent several hours troubleshooting "why is
 our site broken?".

 
https://gitweb.torproject.org/project/web/tpo.git/tree/packages/i18n/lektor_i18n.py#n58

 As others contribute to the site folks will run into this problem again
 and again. It would be much better if 'lector server' aborts with a
 message saying 'python 2.x is unsupported' rather than the confusing
 stacktraces it presently omits.

--
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] #29391 [Core Tor/Tor]: Put git branch-maintenance scripts into scripts directory

[Tor Bug Tracker & Wiki]

#29391: Put git branch-maintenance scripts into scripts directory
--+
 Reporter:  nickm |  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:  0
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by nickm):

 David's versions are much better than mine.  Let's take them and iterate
 based on that.

 Two things to check first:
   1) Should they end with .sh, per rl1987's suggestion above?
   2) Do they pass shellcheck?

--
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] #28848 [Obfuscation/Snowflake]: Document Snowflake broker implementation

[Tor Bug Tracker & Wiki]

#28848: Document Snowflake broker implementation
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, network-team- |  Actual Points:  2
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  8
 Reviewer:  cohosh, arma |Sponsor:
 |  Sponsor19
-+-
Changes (by ahf):

 * reviewer:   => cohosh, arma


--
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] #28848 [Obfuscation/Snowflake]: Document Snowflake broker implementation

[Tor Bug Tracker & Wiki]

#28848: Document Snowflake broker implementation
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, network-team- |  Actual Points:  2
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by ahf):

 * status:  assigned => needs_review


Comment:

 Moving this part to needs_review. Don't close it when you think it's OK.

--
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] #29391 [Core Tor/Tor]: Put git branch-maintenance scripts into scripts directory

[Tor Bug Tracker & Wiki]

#29391: Put git branch-maintenance scripts into scripts directory
--+
 Reporter:  nickm |  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:  0
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by dgoulet):

 * reviewer:  dgoulet => nickm


Comment:

 Here are my enhance scripts: https://github.com/torproject/tor/pull/703

 asn just deployed them and seems working properly for him. I've been using
 them for a while now.

 The entire merging process is _not_ documented whatsoever so this is based
 on "what I know" so far on how to merge ;).

--
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] #29505 [Internal Services/Service - trac]: add new sponsor to trac

[Tor Bug Tracker & Wiki]

#29505: add new sponsor to trac
--+
 Reporter:  gaba  |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


--
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] #29122 [Core Tor/Tor]: Intermittent test failure in circuitpadding/circuitpadding_wronghop

[Tor Bug Tracker & Wiki]

#29122: Intermittent test failure in circuitpadding/circuitpadding_wronghop
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 I think it makes sense to just disable this test until #29298 is done. If
 we want to replace this functionality with something simpler no need to
 devote brain to making this old test work.

--
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] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat utls |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 The code also looks good to me. The uTLS library is neat and I love the
 idea of profiles. Didn't look at the wire part of the uTLS library, but I
 assume others have looked at that?

 Let's get the code in.

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

Re: [tor-bugs] #29070 [Core Tor/Tor]: shellcheck: torify issue

[Tor Bug Tracker & Wiki]

#29070: shellcheck: torify issue
--+-
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Looks 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] #29065 [Core Tor/Tor]: shellcheck: test_switch_id.sh issues

[Tor Bug Tracker & Wiki]

#29065: shellcheck: test_switch_id.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  mikeperry   |Sponsor:
+
Changes (by mikeperry):

 * status:  needs_review => needs_revision


Comment:

 You're missing a $ in the ''if test "(id -u)" != '0'; then'' line.

--
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] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:  1
 Reviewer:  mikeperry  |Sponsor:
---+---
Changes (by mikeperry):

 * status:  needs_review => needs_revision


Comment:

 Hrmm. I might need to look at a lot more of the sbws code, but I don't
 think the patch is the best way to do this. If the queue can also be added
 from another thread, then there still can be a race where it ends up full
 after the loop check but before the next statement. I would instead make
 it do something like:

 {{{
 while True:
   try:
 result_dump.queue.put(measurement_result, timeout=1)
   except Full as e:
 log.info('The results queue is full, after 1 second it should not be
 full')
 }}}

 That way, if the timeout hits because the queue is full for a second, the
 exception is thrown, and then you log, and then you try again for another
 second (at which point it should succeed, but in case it does not, you
 just log and try again rather than raise an uncaught Full exception).

--
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] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat utls |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+--

Comment (by dcf):

 Replying to [comment:22 cohosh]:
 > Hey a did a quick look, here are some comments:
 >
 > - meek-client now requires go version 1.11 or later because of utls. I
 looked but didn't find in the documentation or READMEs the required go
 version for building the client. It's possible I missed it, just wanted to
 point out the required version update.

 Thank you for reviewing.

 Yes, it's a bit of a bummer to require such a recent go... I think it's
 because uTLS is a copy of the stdlib crypto/tls with changes applied on
 top, and the stdlib is not shy about requiring a recent compiler.
 Unfortunately uTLS will put us on more of an update and maintenance
 treadmill. Not only will we have to keep an eye on uTLS to pick up new
 fingerprints, but uTLS will have to stay on top of crypto/tls updates
 ([https://github.com/refraction-networking/utls/pull/12 like this]).
 There's a fair amount of uncertainty yet, I feel.

 > {{{
 > +// otherwise, create an internal http.Transport. In either case, set
 DialTLS on
 > +// the created Transport do a function that dials using uTLS As a
 special case,
 > }}}
 > do-->to
 > uTLS-->uTLS.

 Thanks, fixed these in [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/commit/?h=utls_3=dd26d797b15b8a05262209e07846f7204420e81a
 dd26d797b15b8a05262209e07846f7204420e81a].

--
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] #28848 [Obfuscation/Snowflake]: Document Snowflake broker implementation

[Tor Bug Tracker & Wiki]

#28848: Document Snowflake broker implementation
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, network-team- |  Actual Points:  2
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by ahf):

 * actualpoints:   => 2


Comment:

 Added the (draft) Broker description here:

 https://github.com/ahf/snowflake-notes/blob/master/Broker.markdown

--
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] #28788 [Core Tor/sbws]: Document configuration verify option and disable urllib3

[Tor Bug Tracker & Wiki]

#28788: Document configuration verify option and disable urllib3
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  mikeperry  |Sponsor:
---+---
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 This seems OK.

--
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] #28698 [Core Tor/Tor]: When circuit times are fixed, they can't be "relaxed"

[Tor Bug Tracker & Wiki]

#28698: When circuit times are fixed, they can't be "relaxed"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, log, intro, fast-fix,  |  Actual Points:
  040-proposed   |
Parent ID:   | Points:  0.2
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 This looks good wrt just disabling the loglines.

 (It's also my read of the source that relaxed_timeout doesn't apply if CBT
 is disabled.. This should mean that only the second log message would get
 emitted, not the first. I hope that is the case).

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

Re: [tor-bugs] #27610 [Applications/Tor Browser]: NoScript is broken at .onion pages

[Tor Bug Tracker & Wiki]

#27610: NoScript is broken at .onion pages
--+--
 Reporter:  torbr0|  Owner:  pospeselr
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  browser noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * cc: micahflee (removed)
 * cc: micahlee (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] #28259 [Applications/Tor Browser]: Is not saving history hurting Tor Browser retention rates?

[Tor Bug Tracker & Wiki]

#28259: Is not saving history hurting Tor Browser retention rates?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gallagher2018, ux-team, tbb- |  Actual Points:
  usability  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by kevun):

 Hello! Author of the paper in question, here.

 Addressing the comments of gk and pospeselr, I think if saving history and
 offering a password manager were available in the Tor Browser, it should
 definitely be dependent on the threat model of the user. I think there are
 many threat models in which considering a local adversary makes perfect
 sense, and that the encryption of the information such as history and
 passwords is not always enough to protect people with a local adversary in
 certain regimes, such as the UK and others, where mandatory key disclosure
 is a tool that law enforcement could use to destroy anonymity, or hold
 people who have encrypted histories in prison indefinitely. However, in
 other regimes that do not have mandatory key disclosure laws, such as the
 US, encryption is enough to protect the history and passwords of the
 person using the Tor Browser.

 However, for people who do not have a local adversary, the concept of disk
 avoidance in the TB design document does not make much sense. It makes TTB
 less usable than other browsers for no real benefit.

 The original context in which I proposed this solution in the paper was to
 have an "adversary wizard" such that people could choose their
 adversary/adversaries and have the disk avoidance features turn on and off
 for them, based on their selections. If that is too burdensome or not
 realistic, however, it may simply be sufficient to have an option to allow
 disk avoidance in preferences, with having the safer option (not storing
 history or passwords) as the default. I want TTB to be more usable,
 certainly, but security is most definitely the primary priority in my
 mind.

 Either way, I don't think that this should be an option that remains
 unconfigurable for the average person using Tor. It may be possible to
 have three settings for this:

 1) Default, current setting. Disk avoidance remains.
 2) Disk avoidance is turned off, and all history is encrypted and requires
 a passphrase at TTB launch.
 3) Disk avoidance is turned off, no encryption is used and no passphrase
 is required. (I don't like this one, but I could see some users who
 ***really*** aren't worried about local adversaries requesting it).

 However, there are pros and cons to each of these settings. I think
 they're worth discussing in more detail, for anyone who is interested in
 weighing in.

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

Re: [tor-bugs] #29506 [Applications/Tor Browser]: tag doesn't work when JS is blocked by security slider at Safer

[Tor Bug Tracker & Wiki]

#29506:  tag doesn't work when JS is blocked by security slider at 
Safer
--+--
 Reporter:  micahlee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * keywords:   => tbb-security-slider, ux-team


--
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] #27610 [Applications/Tor Browser]: NoScript is broken at .onion pages

[Tor Bug Tracker & Wiki]

#27610: NoScript is broken at .onion pages
--+--
 Reporter:  torbr0|  Owner:  pospeselr
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  browser noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by micahlee):

 This is also a related issue:
 https://trac.torproject.org/projects/tor/ticket/29506

 And probably it deserves its own separate issue, but when the security
 slider is at Safer, perhaps JavaScript should not get blocked on non-HTTPS
 .onion sites.

--
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] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  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, 041-proposed  |
Parent ID:  #28631   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Was this continually failing or was this the first failure?

 Also do we have instructions for running the unit tests in Wine? I am not
 sure how to reproduce this, especially if it was intermittent, which I
 assume it is.

--
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] #29504 [Webpages/Website]: Add keywords to website

[Tor Bug Tracker & Wiki]

#29504: Add keywords to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by steph:

Old description:

> add global keywords:
> tor, the tor project, tor project, privacy, anonymity, privacy tool,
> censorship, censorship circumvention, private browsing, incognito
> browsing, anonymity network, tor network, onion services, the onion
> router, human rights, free expression, free expression online, free
> speech online, digital rights, activism, digital activist, private
> research, privacy research, technology, privacy technology, anonymity
> technology, tracking, surveillance, online surveillance, website
> tracking, stop website tracking, stop surveillance, online security,
> secure browser, private browser, privacy tool, anonymity tool, hidden
> services, metadata protection, activist tools, internet privacy, online
> privacy, safe browsing, nonprofit, tor browser download, android browser,
> tor browser for android, what is tor, private mode, first amendment, open
> web, private search, private network, decentralized network,
> decentralization, encryption, cryptography, whistleblowers, snowden,
> online safety

New description:

 add global keywords:
 tor, the tor project, tor project, privacy, anonymity, privacy tool,
 censorship, censorship circumvention, private browsing, incognito
 browsing, anonymity network, tor network, onion services, the onion
 router, human rights, free expression, free expression online, free speech
 online, digital rights, activism, digital activist, private research,
 privacy research, technology, privacy technology, anonymity technology,
 tracking, surveillance, online surveillance, website tracking, stop
 website tracking, stop surveillance, online security, secure browser,
 private browser, privacy tool, anonymity tool, hidden services, metadata
 protection, activist tools, internet privacy, online privacy, safe
 browsing, nonprofit, tor browser, tor browser download, android browser,
 tor browser for android, what is tor, private mode, first amendment, open
 web, private search, private network, decentralized network,
 decentralization, encryption, cryptography, whistleblowers, snowden,
 online safety

--

--
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] #29507 [Metrics/Analysis]: Evaluate existing OnionPerf data regarding worst-case performance

[Tor Bug Tracker & Wiki]

#29507: Evaluate existing OnionPerf data regarding worst-case performance
--+--
 Reporter:  karsten   |  Owner:  karsten
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  onionperf |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gaba):

 * keywords:   => onionperf


--
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] #29507 [Metrics/Analysis]: Evaluate existing OnionPerf data regarding worst-case performance

[Tor Bug Tracker & Wiki]

#29507: Evaluate existing OnionPerf data regarding worst-case performance
--+--
 Reporter:  karsten   |  Owner:  karsten
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We're currently showing median and quartiles of our OnionPerf measurements
 on the Tor Metrics website. However, it's equally important to analyze
 worst case performance: failures, timeouts, slowest runs, etc. This ticket
 tracks the progress of this project.

--
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] #29023 [Core Tor/Tor]: prop289: Implement a fast PRNG

[Tor Bug Tracker & Wiki]

#29023: prop289: Implement a fast PRNG
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop289, tor-relay, 041-proposed-|  Actual Points:  3
  on-roadmap |
Parent ID:  #26871   | Points:  3
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by dgoulet):

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


Comment:

 Merged! Thanks.

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

Re: [tor-bugs] #29363 [Core Tor/Tor]: Use fast_rng in place of weak_rng.

[Tor Bug Tracker & Wiki]

#29363: Use fast_rng in place of weak_rng.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay 041-proposed security  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * parent:  #29023 =>


Comment:

 Un-parenting so I can merge the parent.

--
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] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat utls |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+--

Comment (by cohosh):

 Hey a did a quick look, here are some comments:

 - meek-client now requires go version 1.11 or later because of utls. I
 looked but didn't find in the documentation or READMEs the required go
 version for building the client. It's possible I missed it, just wanted to
 point out the required version update.

 Otherwise, I only have some minor copy edit notes for one of the comments:

 in meek-client/utls.go:
 {{{
 +// otherwise, create an internal http.Transport. In either case, set
 DialTLS on
 +// the created Transport do a function that dials using uTLS As a special
 case,
 }}}
 do-->to
 uTLS-->uTLS.

--
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] #29506 [Applications/Tor Browser]: tag doesn't work when JS is blocked by security slider at Safer

[Tor Bug Tracker & Wiki]

#29506:  tag doesn't work when JS is blocked by security slider at 
Safer
--+--
 Reporter:  micahlee  |  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:|
--+--
 The  HTML tag is supposed to be hidden when JavaScript is
 enabled, and get displayed when it's disabled. Websites use it to inform
 users what things are broken without JavaScript.

 When the security slider is set to Safest, all JavaScript is disabled, and
 the  tag works like expected. But when it's set to Safer,
 JavaScript is disabled on non-HTTPS websites (including HTTP .onion
 sites), but the  tag doesn't display, but it should.

--
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] #29295 [Core Tor/sbws]: Remove three consecutive attempts to build a circuit

[Tor Bug Tracker & Wiki]

#29295: Remove three consecutive attempts to build a circuit
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  asn|Sponsor:
---+---
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 OK integration tests pass fine with `tox -e integration`.

 LGTM!

--
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] #25776 [Metrics/Ideas]: Extend OnionPerf to measure pluggable transports

[Tor Bug Tracker & Wiki]

#25776: Extend OnionPerf to measure pluggable transports
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  onionperf  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * keywords:   => onionperf


--
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] #27531 [Applications/Tor Browser]: Tor Browser 8 crashes trying to print on Linux

[Tor Bug Tracker & Wiki]

#27531: Tor Browser 8 crashes trying to print on Linux
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-crash, tbb-8.0-issues, tbb-  |  Actual Points:
  regression, TorBrowserTeam201901R, tbb-rbm,|
  tbb-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by wert2):

 Replying to [comment:25 boklm]:
 > Replying to [comment:23 wert2]:
 > > Sorry didn't see this earlier.  This still crashes for me using 8.0.6
 on an up-to-date Fedora 29 workstation w/ Gnome 3.30.2.
 >
 > Yes, the fix currently is only in the alpha (starting with 8.5a7), but
 not in the stable series yet.
 >
 > I'm adding the `tbb-backport` keyword so we can look at backporting it
 in the next stable release.

 Thank 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] #29026 [Core Tor/Tor]: OpenSSL will not compile without engine support

[Tor Bug Tracker & Wiki]

#29026: OpenSSL will not compile without engine support
-+-
 Reporter:  Mangix   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.10
 Severity:  Normal   | Resolution:  fixed
 Keywords:  040-accepted-20190115,   |  Actual Points:
  040-backport, 035-backport, 034-backport,  |
  033-backport, 029-backport, postfreeze-ok  |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by asn):

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


Comment:

 Merged and backported to 035.

--
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] #24661 [Core Tor/Tor]: accept a reasonably live consensus for guard selection

[Tor Bug Tracker & Wiki]

#24661: accept a reasonably live consensus for guard selection
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  bootstrap, clock-skew, ux, 035   |  Actual Points:
  -backport-maybe, 034-backport-maybe-not, 033   |
  -backport-maybe-not, 033-triage-20180320, 034  |
  -roadmap-proposed, 034-triage-20180328,|
  034-included-20180328, 034-deferred-20180602,  |
  035-removed-20180711   |
Parent ID:  #28018   | Points:  1
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by asn):

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


Comment:

 Backported to maint-0.3.5 and release-0.3.5.

 
https://gitweb.torproject.org/tor.git/commit/?h=maint-0.3.5=9bfe4ed6dd666bb276e35b6e5c8c3de0c218bce0

 https://gitweb.torproject.org/tor.git/commit/?h=release-0.3.5

--
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] #28286 [Core Tor/Tor]: Missing header in freespace.c when building for Android

[Tor Bug Tracker & Wiki]

#28286: Missing header in freespace.c when building for Android
--+
 Reporter:  goapunk   |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.3-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by asn):

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


Comment:

 This patch seems to have been merged to 035 and forward back in January:
 b33bcb1e63c25d9107dfb7b1aa7ecd600674b352

 
https://gitweb.torproject.org/tor.git/commit/?id=b33bcb1e63c25d9107dfb7b1aa7ecd600674b352

 Closing.

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

Re: [tor-bugs] #27845 [Applications/Tor Browser]: Tor Browser 8.0.1 - on MacOS desktop platforms, the default Tor Browser window size is 1000 Wide x 0998 High, not 1000 Wide x 1000 High. Is this a def

[Tor Bug Tracker & Wiki]

#27845: Tor Browser 8.0.1 - on MacOS desktop platforms, the default Tor Browser
window size is 1000 Wide x 0998 High, not 1000 Wide x 1000 High. Is this a
defect?
-+-
 Reporter:  monmire  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  tbb-8.0-issues, tbb-regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 I was just pointing out that it also affects Windows - as the UPSTREAM bug
 already listed in this ticket says. A bug that was filed over a year ago,
 well before your one about MacOS. It doesn't matter if the title of this
 bug says "MacOS" (because that's what you choose), the problem is
 identical (i.e inner window height is not rounded to 100s) in Windows, and
 there is no point in duplicating tickets. The title should have been
 edited, IMO.

 Changing **your** density to compact doesn't mean the problem has been
 solved - it still exists by default for end users.

 The **underlying problem** is not OS specific, it is that icons on the
 toolbar cause the toolbar height to change (compared to a toolbar without
 icons), and that the algorithm used to calculate the chrome for window
 sizing, does so before the toolbar is populated, so it can't detect the
 new height. And this affects more than MacOS. And it has affected Firefox
 with RFP enabled since FF57, and it has affected all 6 releases of TB v8.*
 so far (on windows)

 I honestly would have brought this (see the bugzilla bug) to attention
 months ago, but I just assumed gk et al have it on a low priority, and
 that the viewport solution in ESR68 will suffice. Quite frankly, I'm not
 concerned, given that Mozilla haven't seemed interested in it either. Or
 gk et al have missed the point in glossing your walls of often repeated
 text and posts and full quoting of others in replies. You even bombarded
 the latest blog about the 8.0.6 release with two entries about this.
 Please, tone it down.

 Please don't bother replying to this, especially quoting it all.

 Georg, can you sort out the status (and title) of this bug please, 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] #29505 [Internal Services/Service - trac]: add new sponsor to trac

[Tor Bug Tracker & Wiki]

#29505: add new sponsor to trac
--+-
 Reporter:  gaba  |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Hi!

 We need new sponsors added to trac:

 sponsor27


 sponsor27-must


 sponsor27-can

 and


 sponsor28


 sponsor28-must


 sponsor28-can

 Thanks!

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

Re: [tor-bugs] #29495 [Webpages/Website]: Running site fails with python 2.x

[Tor Bug Tracker & Wiki]

#29495: Running site fails with python 2.x
--+--
 Reporter:  atagar|  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hiro):

 Are you using lektor install as they describe on their webserver? Or the
 debian package?
 I think the debian package doesn't support python2 at all. The idea is
 that python2 will not be supported in a few months (if I am not mistaken).

--
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] #29504 [Webpages/Website]: Add keywords to website

[Tor Bug Tracker & Wiki]

#29504: Add keywords to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 add global keywords:
 tor, the tor project, tor project, privacy, anonymity, privacy tool,
 censorship, censorship circumvention, private browsing, incognito
 browsing, anonymity network, tor network, onion services, the onion
 router, human rights, free expression, free expression online, free speech
 online, digital rights, activism, digital activist, private research,
 privacy research, technology, privacy technology, anonymity technology,
 tracking, surveillance, online surveillance, website tracking, stop
 website tracking, stop surveillance, online security, secure browser,
 private browser, privacy tool, anonymity tool, hidden services, metadata
 protection, activist tools, internet privacy, online privacy, safe
 browsing, nonprofit, tor browser download, android browser, tor browser
 for android, what is tor, private mode, first amendment, open web, private
 search, private network, decentralized network, decentralization,
 encryption, cryptography, whistleblowers, snowden, online safety

--
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] #28286 [Core Tor/Tor]: Missing header in freespace.c when building for Android

[Tor Bug Tracker & Wiki]

#28286: Missing header in freespace.c when building for Android
--+
 Reporter:  goapunk   |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


--
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] #29496 [Core Tor/Tor]: DOS

[Tor Bug Tracker & Wiki]

#29496: DOS
--+---
 Reporter:  bass  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by nickm):

 * status:  new => needs_information


Comment:

 Hi!  This isn't enough information to figure out how to help you here.
 What exactly are you doing, and what is happening when you try?

--
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] #29023 [Core Tor/Tor]: prop289: Implement a fast PRNG

[Tor Bug Tracker & Wiki]

#29023: prop289: Implement a fast PRNG
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, tor-relay, 041-proposed-|  Actual Points:  3
  on-roadmap |
Parent ID:  #26871   | Points:  3
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-

Comment (by nickm):

 Thanks! I've made a squashed version as `fast_rng_squashed`, with new PR
 at https://github.com/torproject/tor/pull/702

--
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] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  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, 041-proposed  |
Parent ID:  #28631   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * priority:  Medium => High
 * milestone:  Tor: unspecified => Tor: 0.4.0.x-final


--
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] #29501 [Core Tor/Tor]: tor: Unhandled OpenSSL errors found

[Tor Bug Tracker & Wiki]

#29501: tor: Unhandled OpenSSL errors found
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.7
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * keywords:   => 041-proposed


Comment:

 Hm. Seems worth looking at.

--
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] #27845 [Applications/Tor Browser]: Tor Browser 8.0.1 - on MacOS desktop platforms, the default Tor Browser window size is 1000 Wide x 0998 High, not 1000 Wide x 1000 High. Is this a def

[Tor Bug Tracker & Wiki]

#27845: Tor Browser 8.0.1 - on MacOS desktop platforms, the default Tor Browser
window size is 1000 Wide x 0998 High, not 1000 Wide x 1000 High. Is this a
defect?
-+-
 Reporter:  monmire  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  tbb-8.0-issues, tbb-regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by monmire):

 Replying to [comment:22 Thorin]:
 > @ monmire. The inner window is only resized when opening a **new**
 window (which includes when you start Tor Browser). **It is not
 dynamically resized as you add/remove/change chrome elements**
 >
 > TB 8.06 (windows7)
 > - density normal, toolbar on with icons: opens at `1000x996`, change
 density to compact and the inner windows is now `1000x1010`
 > - new identity at density compact: opens at `1000x998`
 >
 > I do not have MacOS. It *may* be that compact on MacOS achieves
 1000x1000 on a new window, but then what happens if the toolbar has no
 icons (it will change size, and your *fix* will break). And what about all
 the people who don't use compact theme. This is not a solution, sorry.
 >
 > The problem is the icon padding and/or margins which change the height
 of the toolbar, and this happens after the resizing is calculated on the
 creation of a new window. [[br]]

 This ticket addresses the issue on MacOS, not on Windows 7. I do not know
 a solution for TB 8.0.6 on Windows 7. Perhaps you could submit a new
 ticket addressing the issue on Windows 7. [[br]]

 On MacOS, after selecting /Compact setting and with
 View/Toolbars/Bookmarks Toolbar enabled, but with neither icons nor text
 appearing in the Bookmarks Toolbar beneath the URL bar, inner screen size
 remains `wide:1000 x high:1000`. [[br]]

 However, on MacOS, with /Compact setting and with View/Toolbars/Bookmarks
 Toolbar not enabled, inner screen size is `wide:1000 x high:1020. [[br]]

 On Mac OS platform, if a user prefers to enable /Bookmarks Toolbar with
 icons visible in the Bookmarks Toolbar beneath the URL Bar, /Compact
 appears to be a solution to achieve `wide:1000 x high:1000`. [[br]]

 In comment:14, gk closed the ticket as "closed defect (fixed)" because the
 issue on MacOS resolved itself (see comment:13). [[br]]

 In comment:21, I closed the ticket as "closed defect (fixed)" because
 /Compact resolved the issue on MacOS (not on Windows 7). [[br]]

--
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] #29503 [Webpages/Website]: Add logo to link preview on new site

[Tor Bug Tracker & Wiki]

#29503: Add logo to link preview on new site
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The current preview looks like this and needs an image:
 https://share.riseup.net/#MKKKaVIt6dJG-5nDvwuaEQ

 I'm not sure the exact size to use, but this could work:
 https://share.riseup.net/#0gABIrtrdOO4nwjAKoGJXA

--
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] #29497 [Applications/Tor Browser]: After tor crash, firefox.exe (tor browser) shoots up to 50+% cpu usage and stays there til killed in task list

[Tor Bug Tracker & Wiki]

#29497: After tor crash, firefox.exe (tor browser) shoots up to 50+% cpu usage 
and
stays there til killed in task list
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 The same for non-exe platform.

--
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] #28940 [Obfuscation/Pluggable transport]: Add support for LOG to goptlib

[Tor Bug Tracker & Wiki]

#28940: Add support for LOG to goptlib
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:  Sponsor19
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Let's get your LOG support into `goptlib`. It looks good.

 I lifted out the logger and the STATUS API into a `goptlibext` package at
 https://github.com/ahf/goptlibext

 Let's move it over to Gitlab once the instance is up and running this or
 next 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

[tor-bugs] #29502 [Webpages/Support]: Glossary on the support portal should be moved to the main menu

[Tor Bug Tracker & Wiki]

#29502: Glossary on the support portal should be moved to the main menu
--+--
 Reporter:  emmapeel  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I tried to move the glossary page from Misc/Glossary to Glossary, but
 apparently only the Topics can be rendered on the main page, and I cannot
 seem to make the body of the glossary appear, unless it is under a Topic
 page. I added it under Misc/, but the Glossary should have its own page.

 See:https://support.torproject.org/misc/glossary/

--
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] #29298 [Core Tor/Tor]: Explicitly specify histogram bin endpoints/widths

[Tor Bug Tracker & Wiki]

#29298: Explicitly specify histogram bin endpoints/widths
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad 041-proposed network-team-   |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #28631   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by asn):

 Spec branch pushed in https://github.com/asn-d6/torspec/tree/bug29298 .

 Mike do you like 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] #20842 [Applications/Tor Browser]: Proposal: Improve Tor Browser font whitelist / bundled fonts

[Tor Bug Tracker & Wiki]

#20842: Proposal: Improve Tor Browser font whitelist / bundled fonts
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability, ux-team|  Actual Points:
Parent ID:  #18097| Points:
 Reviewer:|Sponsor:
--+--

Comment (by winterflaw):

 I'd like to request whitelist and packaing support for Linear A, Linear B
 and Cretan Hieroglyphs.

 Of these, there is a 32kb Google Noto font for Linear B, which is a good
 start.

--
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] #29147 [Core Tor/Tor]: Update dir-spec with the correct Tor version when bandwidth-file-digest is merged

[Tor Bug Tracker & Wiki]

#29147: Update dir-spec with the correct Tor version when bandwidth-file-digest 
is
merged
-+-
 Reporter:  teor |  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-spec tor-crypto tor-dirauth  |  Actual Points:
  tor-bwauth 040-proposed|
Parent ID:  #26698   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * status:  new => needs_review


Comment:

 Replying to [comment:3 juga]:
 > hmm, do we only use final versions (not alpha)?.
 > i think we are now in 0.4.0.1-alpha?. It got merged yesterday...
 ah, asn clarified, it's 0.4.0.2-alpha now.

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

Re: [tor-bugs] #29147 [Core Tor/Tor]: Update dir-spec with the correct Tor version when bandwidth-file-digest is merged

[Tor Bug Tracker & Wiki]

#29147: Update dir-spec with the correct Tor version when bandwidth-file-digest 
is
merged
-+-
 Reporter:  teor |  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-spec tor-crypto tor-dirauth  |  Actual Points:
  tor-bwauth 040-proposed|
Parent ID:  #26698   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 hmm, do we only use final versions (not alpha)?.
 i think we are now in 0.4.0.1-alpha?. It got merged yesterday...

--
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] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto tor-dirauth tor-bwauth|  Actual Points:
  041-proposed   |
Parent ID:  #27047   | Points:  0.5
 Reviewer:  nickm|Sponsor:
-+-

Comment (by juga):

 will update the spec, then close

--
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] #29132 [Core Tor/Tor]: Clean up dirserv_read_measured_bandwidths after #26223

[Tor Bug Tracker & Wiki]

#29132: Clean up dirserv_read_measured_bandwidths after #26223
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto tor-dirauth tor-bwauth|  Actual Points:
  041-proposed   |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * parent:  #26698 =>


Comment:

 Unparenting so that #26698 can be closed.

--
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] #29133 [Core Tor/Tor]: Refactor dirserv_read_measured_bandwidths

[Tor Bug Tracker & Wiki]

#29133: Refactor dirserv_read_measured_bandwidths
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt tor-crypto tor-   |  Actual Points:
  dirauth tor-bwauth 041-proposed|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * parent:  #26698 =>


Comment:

 Unparenting so that #26698 can be closed.

--
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] #29122 [Core Tor/Tor]: Intermittent test failure in circuitpadding/circuitpadding_wronghop

[Tor Bug Tracker & Wiki]

#29122: Intermittent test failure in circuitpadding/circuitpadding_wronghop
--+
 Reporter:  nickm |  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:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by asn):

 * status:  reopened => needs_review
 * reviewer:  nickm => mikeperry


Comment:

 Hello, pushed a branch that disables the offending unittest until we do
 #29298:
 https://github.com/torproject/tor/pull/701

 Mike, wanna take a look and see if you like the approach or you would
 prefer something else?

--
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] #29501 [Core Tor/Tor]: tor: Unhandled OpenSSL errors found

[Tor Bug Tracker & Wiki]

#29501: tor: Unhandled OpenSSL errors found
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.7
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 via [[https://bugs.debian.org/922237|Debian#922237]]:

 From syslog:

 {{{
 Feb 13 15:14:33 tglase-nb Tor[1770]: Bootstrapped 80%: Connecting to the
 Tor network
 Feb 13 15:14:33 tglase-nb Tor[1770]: Unhandled OpenSSL errors found at
 ../src/lib/tls/tortls_openssl.c:1043:
 Feb 13 15:14:33 tglase-nb Tor[1770]: TLS error: bad value (in SSL
 routines:ssl_do_config:---)
 Feb 13 15:14:33 tglase-nb Tor[1770]: Bootstrapped 90%: Establishing a Tor
 circuit
 }}}

 It seems to be only a warning, but thought you might wish to know.

--
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] #21039 [Core Tor/Tor]: Refactor and simplify guard code of circuit_send_next_onion_skin()

[Tor Bug Tracker & Wiki]

#21039: Refactor and simplify guard code of circuit_send_next_onion_skin()
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, refactor, |  Actual Points:
  034-triage-20180328, 034-included-20180401,|
  034-removed-20180502, 035-roadmap-subtask, |
  035-triaged-in-20180711|
Parent ID:  #24986   | Points:  0.3
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-
Changes (by asn):

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


--
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] #29295 [Core Tor/sbws]: Remove three consecutive attempts to build a circuit

[Tor Bug Tracker & Wiki]

#29295: Remove three consecutive attempts to build a circuit
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  asn|Sponsor:
---+---

Comment (by asn):

 Patches looks good to me. BTW, what's the way to run the integration test
 added by the final commit?

--
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] #29023 [Core Tor/Tor]: prop289: Implement a fast PRNG

[Tor Bug Tracker & Wiki]

#29023: prop289: Implement a fast PRNG
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, tor-relay, 041-proposed-|  Actual Points:  3
  on-roadmap |
Parent ID:  #26871   | Points:  3
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM after latest fixups. An appveyor build broke because of
 circuitpadding unittests which I reported here #29500. I think we are good
 here.

--
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] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding, 041-proposed
Actual Points:   |  Parent ID:  #28631
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This appveyor built failed two unittests:
 
https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3

 {{{
 circuitpadding/circuitpadding_tokens: [forking]
   FAIL ../src/test/test_circuitpadding.c:1125: assert(mi->histogram[4]
 OP_EQ 2): 0 vs 2
   [circuitpadding_tokens FAILED]
 circuitpadding/circuitpadding_rtt: [forking]
   FAIL ../src/test/test_circuitpadding.c:324:
 assert(relay_side->padding_info[0]->last_received_time_usec OP_NE 0): 0 vs
 0
   [circuitpadding_rtt FAILED]
 }}}

--
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] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed  |
Parent ID:  #28631   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by asn:

Old description:

> This appveyor built failed two unittests:
> https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3
>
> {{{
> circuitpadding/circuitpadding_tokens: [forking]
>   FAIL ../src/test/test_circuitpadding.c:1125: assert(mi->histogram[4]
> OP_EQ 2): 0 vs 2
>   [circuitpadding_tokens FAILED]
> circuitpadding/circuitpadding_rtt: [forking]
>   FAIL ../src/test/test_circuitpadding.c:324:
> assert(relay_side->padding_info[0]->last_received_time_usec OP_NE 0): 0
> vs 0
>   [circuitpadding_rtt FAILED]
> }}}

New description:

 This x86 appveyor build failed two unittests:
 
https://ci.appveyor.com/project/torproject/tor/builds/22350196/job/457arqlgfgf6b0a3

 {{{
 circuitpadding/circuitpadding_tokens: [forking]
   FAIL ../src/test/test_circuitpadding.c:1125: assert(mi->histogram[4]
 OP_EQ 2): 0 vs 2
   [circuitpadding_tokens FAILED]
 circuitpadding/circuitpadding_rtt: [forking]
   FAIL ../src/test/test_circuitpadding.c:324:
 assert(relay_side->padding_info[0]->last_received_time_usec OP_NE 0): 0 vs
 0
   [circuitpadding_rtt FAILED]
 }}}

--

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