Re: [tor-bugs] #22819 [Core Tor/Tor]: Choice of compressors seems to be suboptimal

[Tor Bug Tracker & Wiki]

#22819: Choice of compressors seems to be suboptimal
--+-
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yurivict271):

 The valid way to compare compression methods for a particular purpose is
 to take your data samples and run it through lzbench
 (https://github.com/inikep/lzbench).

 Compression method should be a function of the current network speed. When
 the speed is over a certain threshold, no compression is needed. Below the
 threshold compression method is chosen based on the graph for all
 available methods, like the first link above. When the speed is slightly
 below the threshold, fast and slight compressors are appropriate, like
 lz4. With slower speeds, deeper and slower compressors kick in, like zstd,
 and later lzma.

 I didn't see you even considering lz4 in proposal 278 references.

--
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] #22820 [Core Tor/Tor]: Give the Exit flag to Exits that use the secure IRC port 6697

[Tor Bug Tracker & Wiki]

#22820: Give the Exit flag to Exits that use the secure IRC port 6697
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [comment:2 teor]:
 > People send proposals to the tor-dev@ mailing list for discussion.
 > It will help if it has the same structure as other recent proposals.

 In fact, check out proposal 001 for the recommended structure. :)

 https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

--
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] #22820 [Core Tor/Tor]: Give the Exit flag to Exits that use the secure IRC port 6697

[Tor Bug Tracker & Wiki]

#22820: Give the Exit flag to Exits that use the secure IRC port 6697
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 The Exit flag serves two roles:

 A) It allows people to build preemptive circuits, and end them at a relay
 that has a good chance of being able to handle whatever future stream the
 client receives. That is, we want to build a circuit *before* we know what
 stream request is going to arrive, and we want to have a good chance that
 the last hop on that circuit will be able to handle the request. So in
 that sense the Exit flag signifies "is able to handle many of the likely
 requests by users".

 B) It allows clients to shift load away from relays that probably already
 have a lot of load because they're being used as exits. That is, if your
 relay has the Exit flag, then my client will avoid using it in the first
 or second hops of my circuits, because for global load balancing it is
 best to save its bandwidth for being an exit since exit capacity is
 scarce.

 For the first one, I want to know what *this particular client* is likely
 to do, and build circuits that are going to be able to handle those
 requests. That's part of what the "predicted ports" logic is for in
 rephist.c -- see for example {{{rep_hist_note_used_port()}}}.

 Whereas for the second one, I want to know what *most of the other
 clients* are likely to do, so I can take the correct behavior to produce
 the globally optimum load across all the relays.

 Originally, I picked "80, 443, and 6667" as an indication that if you
 accept those three, you probably accept a bunch of other ports too, so
 you're likely to be an exit relay that gets used for exit traffic.

 So as people try to squeeze down their exit policy while retaining the
 Exit flag, they are pushing themselves farther from being the sort of
 relay that is being used a lot for exit traffic.

 If I were to make a change based on (my intuition of) traffic these days,
 I would change it to simply "80 and 443".

--
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] #22814 [Applications/Tor Browser]: Disable clipboard.autocopy in TOR Browser

[Tor Bug Tracker & Wiki]

#22814: Disable clipboard.autocopy in TOR Browser
--+--
 Reporter:  pqrst |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by pqrst):

 Clicking with the scroll wheel on a link is how I usually open a link in a
 new tab (it's probably the same as a middle mouse click). BTW, this is
 also why I encounter the above issue in practice: if I miss the link or
 click on a non-linked area that I expected to be a link, I get redirected
 to some random page that I browsed previously. Instead, I would expect
 nothing to happen if I middle-click on something that can't be opened in a
 new tab, so this is sort of annoying in any case.

 In the case of TOR Browser this is more than just annoying, since it
 periodically causes me to accidentally reopen pages in normal Firefox that
 I may not want to have my ip to be associated with. Even if someone does
 find the above feature convenient, I would say that security takes
 precedence in this case.

 When this occurs, I did not explicitly copy the link in question. It is
 possible that I selected it for the purpose of deleting the old address
 and navigating to a new page. If this is what causes the link to be
 autocopied to the clipboard, I suggest that this be disabled as well: TOR
 Browser imposes far worse inconveniences on the user than having to
 explicitly Ctrl-C when you actually want to copy something.

 And yes, this does sound related to #10089.

--
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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by Vort):

 Replying to [comment:19 cypherpunks]:
 > > Or, maybe, this problem affects regular users too?
 >
 > Please, test it.

 I can't see such a problem in non-relay mode.
 Tested with HTTP upload and the same refEntry and refExit relays.
 Probably, the difference is that in relay case, connection is incoming and
 in non-relay case is outgoing.

--
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] #13014 [Applications/Tor Browser]: copy and paste trick could be used to deanonymise users

[Tor Bug Tracker & Wiki]

#13014: copy and paste trick could be used to deanonymise users
--+--
 Reporter:  cypherpunks   |  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:
--+--
Changes (by arma):

 * severity:   => Normal


Comment:

 I wonder if the browser people (e.g. Firefox or Chrome) have any answers
 for this issue? It is a security issue, which is what allows it to become
 a privacy 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] #22820 [Core Tor/Tor]: Give the Exit flag to Exits that use the secure IRC port 6697

[Tor Bug Tracker & Wiki]

#22820: Give the Exit flag to Exits that use the secure IRC port 6697
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by IgorMitrofanov):

 Thanks! I'll keep it similar to the existing ones and send it to tor-dev@.

--
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] #22820 [Core Tor/Tor]: Give the Exit flag to Exits that use the secure IRC port 6697

[Tor Bug Tracker & Wiki]

#22820: Give the Exit flag to Exits that use the secure IRC port 6697
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 People send proposals to the tor-dev@ mailing list for discussion.
 It will help if it has the same structure as other recent proposals.

--
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] #22820 [Core Tor/Tor]: Give the Exit flag to Exits that use the secure IRC port 6697

[Tor Bug Tracker & Wiki]

#22820: Give the Exit flag to Exits that use the secure IRC port 6697
+--
 Reporter:  teor|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by IgorMitrofanov):

 I can take a shot at describing pros/cons, but I don't know proposals are
 submitted. I could simply paste it all here into the ticket, for somebody
 to pick up?

--
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] #22820 [Core Tor/Tor]: Give the Exit flag to Exits that use the secure IRC port 6697

[Tor Bug Tracker & Wiki]

#22820: Give the Exit flag to Exits that use the secure IRC port 6697
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  needs-proposal
Actual Points:|  Parent ID:
   Points:  3 |   Reviewer:
  Sponsor:|
--+--
 Igor Mitrofano suggests that the Exit flag should be given to relays that
 allow exiting to the default secure IRC port 6697.

 From tor-relays:
 https://lists.torproject.org/pipermail/tor-relays/2017-July/012585.html

 The existing policy is "two ports from [80, 443, 6667]", or these options:
 * 80, 443
 * 80, 6667
 * 443, 6667

 We would change to "two ports from [80, 443, 6667-OR-6697]", adding these
 options:
 * 80, 6697
 * 443, 6697

 We don't need a new consensus method for this, because the way Exit flags
 are combined stays as majority vote.

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

Re: [tor-bugs] #22817 [Core Tor/Tor]: SAFECOOKIE description in control spec does not have verifiable test vectors

[Tor Bug Tracker & Wiki]

#22817: SAFECOOKIE description in control spec does not have verifiable test
vectors
--+
 Reporter:  amphetamine   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by amphetamine):

 Here's a Python session transcript:
 {{{
 python
 Python 2.7.12 (default, Nov 19 2016, 06:48:10)
 [GCC 5.4.0 20160609] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import stem.util.connection
 >>> import binascii
 >>>
 >>> expected_server_hash =
 "f97294895a4c9b3fe04c390f1b3bcda886e54501220726e075140ff636fe0d91"
 >>> expected_client_hash =
 "02b6f2e708dffb47efcddbfdc08d24d3f9f87bb416a057b4cf5e553e56125bbb"
 >>> client_nonce = "f0"
 >>> server_nonce =
 "65634AA3D089F94AD841DF2F35685CCD086CB674D5E9DE2D516BD2E7318B"
 >>> cookie =
 "7aab85f16613633d115be5ea6722b5e0527ae72100bfb0fd64fb5b15a8fcde4b"
 >>> CLIENT_HASH_CONSTANT = "Tor safe cookie authentication controller-to-
 server hash"
 >>> SERVER_HASH_CONSTANT = "Tor safe cookie authentication server-to-
 controller hash"
 >>>
 >>> server_hash = stem.util.connection._hmac_sha256(SERVER_HASH_CONSTANT,
 binascii.unhexlify(cookie + client_nonce + server_nonce)).encode('hex')
 >>> client_hash = stem.util.connection._hmac_sha256(CLIENT_HASH_CONSTANT,
 binascii.unhexlify(cookie + client_nonce + server_nonce)).encode('hex')
 >>>
 >>> expected_server_hash == server_hash
 True
 >>> expected_client_hash == client_hash
 True
 }}}

 There are also passing tests for a Rust implementation starting here:
 https://gitlab.com/amphetamine/puccinia/blob/master/src/authentication.rs#L218

 I used those tests to generate the above vectors used in Stem, so that
 should at least corroborate the two together.

--
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] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Upstream (Old): https://bugzilla.mozilla.org/show_bug.cgi?id=859782

--
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] #22819 [Core Tor/Tor]: Choice of compressors seems to be suboptimal

[Tor Bug Tracker & Wiki]

#22819: Choice of compressors seems to be suboptimal
--+-
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by nickm):

 Whoops. That should have been 278.

--
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] #22819 [Core Tor/Tor]: Choice of compressors seems to be suboptimal

[Tor Bug Tracker & Wiki]

#22819: Choice of compressors seems to be suboptimal
--+-
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yurivict271):

 The list of proposals ends with 279:
 https://gitweb.torproject.org/torspec.git/tree/proposals

--
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] #22819 [Core Tor/Tor]: Choice of compressors seems to be suboptimal

[Tor Bug Tracker & Wiki]

#22819: Choice of compressors seems to be suboptimal
--+-
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by nickm):

 We analyzed the algorithms performance on the actual data we send; see
 proposal 280 and its references for details.

--
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] #22817 [Core Tor/Tor]: SAFECOOKIE description in control spec does not have verifiable test vectors

[Tor Bug Tracker & Wiki]

#22817: SAFECOOKIE description in control spec does not have verifiable test
vectors
--+
 Reporter:  amphetamine   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_revision
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 Let's treat the text after "A possible example of useful information:" as
 a draft patch and add it to torspec in an appendix, and then reference
 that appendix in the sections for each of the commands that are used.

 Here's how I would revise it:
 * provide an example session transcript with commands, so it's clear which
 commands correspond to which test vectors

 Here's how I would test it:
 * run it through at least two existing implementations

--
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] #22819 [Core Tor/Tor]: Choice of compressors seems to be suboptimal

[Tor Bug Tracker & Wiki]

#22819: Choice of compressors seems to be suboptimal
--+-
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * component:  - Select a component => 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

[tor-bugs] #22819 [- Select a component]: Choice of compressors seems to be suboptimal

[Tor Bug Tracker & Wiki]

#22819: Choice of compressors seems to be suboptimal
--+-
 Reporter:  yurivict271   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The latest tor-devel uses 2 compression libraries: zstd and lzma.

 Based on this graph
 https://raw.githubusercontent.com/facebook/zstd/dev/doc/images/DCspeed5.png
 lzma only slightly exceeds zstd in a small range of values.

 Why didn't you choose lz4? Based on this lz4 description
 https://github.com/lz4/lz4 it offers an advantage in a different range of
 values: towards the lower left corner of the first graph. lz4 can compress
 with lower ratio but with much higher speed.

 If you want to choose several libraries, doesn't it make sense to cover a
 wider range of values, rather than choose two libraries that cover a
 similar range?

 zstd + lz4 seems to be a better choice.

--
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] #19521 [Core Tor/Stem]: Update online source to be consistent with onine API

[Tor Bug Tracker & Wiki]

#19521: Update online source to be consistent with onine API
---+
 Reporter:  amj703 |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  website|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Ick, sorry I left this broken so long. On reflection the fix is actually
 really trivial. Turns out it's safe to issue a 'make clean' on staticforme
 (location we build the site) since it apparently doesn't serve live
 content.

 Source information should now stay accurate and up to date. Also, there
 was a bug in the cron causing the site to be republished every hour rather
 than fifteen minutes. Republication is really quick so dropped that to be
 done every five minutes.

 For posterity's sake since I touch site publication so infrequently here's
 what I did...

 {{{
 % ssh -A -t perdulce.torproject.org ssh -A staticiforme.torproject.org

 % sudo -u stem crontab -l
 */5 * * * * /home/stem/build_site

 % sudo -u stem cat /home/stem/build_site
 #!/bin/sh

 export PATH=/home/stem/bin:$PATH
 export PYTHONPATH=/home/stem/lib/python

 cd /home/stem/stem
 git pull

 cd docs
 make clean
 make html

 sudo -u mirroradm static-master-update-component stem.torproject.org
 echo "$(date)" > /home/stem/site_last_built
 }}}

 To test this I temporarily dropped the cron to run every minute and
 hammered reloading the site for ~5 minutes looking for 404s due to the
 clean. Nothing showed up, and pages with source got corrected by the
 introduction of 'make clean'.

--
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] #22818 [Core Tor/Tor]: Improve documentation for building Tor with Rust

[Tor Bug Tracker & Wiki]

#22818: Improve documentation for building Tor with Rust
--+--
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We have documentation that has thus far been a work in progress at
 https://trac.torproject.org/projects/tor/wiki/RustInTor and
 https://trac.torproject.org/projects/tor/wiki/RustInTor/Hacking

 However, we should create a doc/HACKING/RustInTor.md with basic
 information to get people started, as it isn't obvious to look at the
 above wiki pages. Also, there is still missing information, such as which
 dependencies are necessary if someone chooses to build using a specified
 local directory for Rust dependencies.

 For example, we should have:

 1. Which dependencies are needed if someone wants to build using local
 Rust dependencies.
 2. Basic information about how to build and run tests
 3. Links to wiki pages that are still a work in progress

--
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] #22814 [Applications/Tor Browser]: Disable clipboard.autocopy in TOR Browser

[Tor Bug Tracker & Wiki]

#22814: Disable clipboard.autocopy in TOR Browser
--+--
 Reporter:  pqrst |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 If the above is what this ticket is about, see also #10089.

--
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: #21133, #22355, #22722, #22817

[Tor Bug Tracker & Wiki]

Batch modification to #21133, #22355, #22722, #22817 by arma:
keywords to tor-spec

Comment:
switch to tor-spec keyword like most tickets seem to use

--
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] #22817 [Core Tor/Tor]: SAFECOOKIE description in control spec does not have verifiable test vectors

[Tor Bug Tracker & Wiki]

#22817: SAFECOOKIE description in control spec does not have verifiable test
vectors
--+-
 Reporter:  amphetamine   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  torspec   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * keywords:   => torspec
 * component:  - Select a component => 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] #22814 [Applications/Tor Browser]: Disable clipboard.autocopy in TOR Browser

[Tor Bug Tracker & Wiki]

#22814: Disable clipboard.autocopy in TOR Browser
--+--
 Reporter:  pqrst |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 For those of us who don't have a mouse wheel, can you explain what it's
 actually doing?

 Is that the same as "middle mouse click" on X?

 So your issue is that when you middle click, you had highlighted a URL
 before, and you're unhappy that X remembers the text that you had
 highlighted?

 If that's what's going on, I think disabling "you can conveniently copy
 and paste stuff in the browser and in the rest of your applications" would
 be a huge lose for usability.

--
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] #22817 [- Select a component]: SAFECOOKIE description in control spec does not have verifiable test vectors

[Tor Bug Tracker & Wiki]

#22817: SAFECOOKIE description in control spec does not have verifiable test
vectors
--+-
 Reporter:  amphetamine   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The SAFECOOKIE documentation in
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt describes
 the hashing process, but doesn't provide verifiable sample input/output
 pairs that would be hugely helpful for implementing it.

 I worked around this by using the server hash reported by the Tor server
 and access to the Stem code to verify the expected inputs and outputs, but
 this is a lot of extra overhead beyond the spec document.

 A possible example of useful information:

  example server hash:
 F917E3B73CBEDC66A85EBD60F25E100552B89645FDEC87D69E9BD4E81E25B604
  example server nonce:
 F8B52E3424733A4081FCCD2A64FC9C67F0FD3A9639C1E09D5558C3B4B9B973E1
  example client nonce: 3b
  example client hash:
 c6213ce626df95c1b5f5c0b4fe77c8ff1a05c7fd7f5e5a9843d2b4d009b5d340

  The above vectors should be decoded to bytes and input to an HMAC
 initialized with the appropriate server-to-controller initialization key
 described in this spec to produce a matching hex string as provided by the
 Tor process in its AUTHCHALLENGE reply. The same vectors should also be
 decoded to bytes and input to an HMAC initialized with the appropriate
 controller-to-server initialization key described in this spec to produce
 the client hash.

--
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] #22768 [Internal Services/Service - jenkins]: Add building Tor with Rust support to Jenkins

[Tor Bug Tracker & Wiki]

#22768: Add building Tor with Rust support to Jenkins
-+
 Reporter:  isis |  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-ci |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+
Changes (by chelseakomlo):

 * cc: ckomlo (removed)
 * cc: chelseakomlo (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] #22816 [Core Tor/Tor]: Run tests for single Rust module

[Tor Bug Tracker & Wiki]

#22816: Run tests for single Rust module
--+--
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In Tor, we currently have the ability to run tests for a single C module
 (or even a single unit test). As specified in doc/HACKING/WritingTests,
 running tests for the cell format module (for example) can be done via
 `./src/test/test cellfmt/..`

 Rust modules should have a similar option. Currently 'cargo test' can be
 run within a single Rust module, but this will not link against C modules.
 It would be good to be able to do this and retain the ability to test a
 single Rust module. Also, it would be nice to make this similar to running
 single C module tests, to minimize developer confusion.

--
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] #22809 [Applications/Tor Browser]: Tor Browser does not provide red security warning for downloading executable in HTTP

[Tor Bug Tracker & Wiki]

#22809: Tor Browser does not provide red security warning for downloading
executable in HTTP
--+--
 Reporter:  naif  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 The best order of operations here would be for Firefox to fix its bug, and
 merge the fix, and then we can get the fix when we pull in a future
 version of Firefox.

 Another option is, if there is a good patch but Firefox won't take it or
 it will be years until we pull in the version of Firefox that includes it,
 that we could apply the patch to Tor Browser directly, and maintain it
 until things catch up with the Firefox releases.

 But I am unclear on why we should single out exe files here. In the
 mozilla bugtracker, you mention rpm and deb files too. Why not tarballs
 also? Or docx files? Where do we draw the 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] #21604 [Core Tor/Stem]: add descriptor-id calc functionality

[Tor Bug Tracker & Wiki]

#21604: add descriptor-id calc functionality
---+---
 Reporter:  cypherpunks|  Owner:  atagar
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Ewww, four months? Sorry about that. Started taking a peek but realized
 the first thing I'll need is example function input/output for unit tests
 so I can confirm I get it right.

--
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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 > this is a bottleneck in Tor, which leads to system buffers exhaustion on
 the high load, sooner or later.

 No. This test was success because tor_tls_write() can to pass more bytes
 at once to openssl and windows' send() too
 [https://stackoverflow.com/a/28848834 complex]. Increasing of chunks size
 actually could lead to buffers exhaustion, and this ticket not about 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] #22814 [Applications/Tor Browser]: Disable clipboard.autocopy in TOR Browser

[Tor Bug Tracker & Wiki]

#22814: Disable clipboard.autocopy in TOR Browser
--+--
 Reporter:  pqrst |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I absolutely second this, besides the obvious security concerns, it's
 utterly annoying to see it happen.

--
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] #22697 [Core Tor/Tor]: Tor should mandatory require brackets around ipv6 address

[Tor Bug Tracker & Wiki]

#22697: Tor should mandatory require brackets around ipv6 address
--+
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Could we have tor issue a warning and eventually make it mandatory? I wary
 of weird behavior that lingers on forever due only to historical reasons.

--
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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Test in comment:12 shows that this is a bottleneck in Tor, which leads to
 system buffers exhaustion on the high load, sooner or later.

--
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] #22810 [Core Tor/Tor]: prop224: Make the client/service extend properly to the IP/RP

[Tor Bug Tracker & Wiki]

#22810: prop224: Make the client/service extend properly to the IP/RP
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, circuit  |  Actual Points:
Parent ID:  #21888| Points:  1
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 Branch: `ticket22810_032_01`.
 Gitlab review: https://gitlab.com/dgoulet/tor/merge_requests/33

 There are potential controversial changes in _two_ commits here ;).

 Side note, if #22804 is merged upstream before, conflicts will arise.

--
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] #22815 [Core Tor/Chutney]: Chutney tests for IPv6 only bridges

[Tor Bug Tracker & Wiki]

#22815: Chutney tests for IPv6 only bridges
--+---
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #4847
   Points:|   Reviewer:
  Sponsor:|
--+---
 We need an IPv6-only bridge test, so we can test #4847 and make sure there
 are no regressions.

--
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] #4565 [Core Tor/Tor]: Enable relays to talk to other relays via IPv6

[Tor Bug Tracker & Wiki]

#4565: Enable relays to talk to other relays via IPv6
-+-
 Reporter:  karsten  |  Owner:  ln5
 Type:  project  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6 tor-relay needs-design  |  Actual Points:
Parent ID:  #5788| Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #5788


--
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] #4847 [Core Tor/Tor]: Bridges binding only to an IPv6 address doesn't work

[Tor Bug Tracker & Wiki]

#4847: Bridges binding only to an IPv6 address doesn't work
--+-
 Reporter:  ln5   |  Owner:  ln5
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.3.10-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6, tor-bridge  |  Actual Points:
Parent ID:  #5788 | Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Replying to [comment:17 arma]:
 > I think if you set AssumeReachable 1 then your bridge will proceed as
 intended?

 Your bridge will, but clients will never bootstrap, because they can't get
 the bridge descriptor from the bridge, because it doesn't exist.

--
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] #22814 [Applications/Tor Browser]: Disable clipboard.autocopy in TOR Browser

[Tor Bug Tracker & Wiki]

#22814: Disable clipboard.autocopy in TOR Browser
--+--
 Reporter:  pqrst |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On Linux Mint KDE (and possibly other distros) clicking with the mouse
 wheel on an empty (non-linked) area of a web page in Firefox will take you
 back to a previously closed page.

 This also works if the page was in an already closed private window.

 It also works if the page was in a TOR Browser instance after doing
 "create new identity".

 Most hilariously, it is possible to reopen a closed page from before an
 identity change in a separate instance of normal Firefox.

 Changing clipboard.autocopy to false in about:config stops this behavior.

 In my opinion this is a highly questionable "feature" under any
 circumstances, but in the context of TOR Browser this should be considered
 a major security risk. Please disable this option by default.

 This behavior is present in TOR Browser 7.0.2 on Linux Mint 18.2, but I
 have observed it in several older versions of both TOR Browser and Mint
 going back several years.

--
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] #17782 [Core Tor/Tor]: Relays may publish descriptors with incorrect IP address

[Tor Bug Tracker & Wiki]

#17782: Relays may publish descriptors with incorrect IP address
---+---
 Reporter:  fk |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Major  | Resolution:
 Keywords:  intro tor-relay address-detection  |  Actual Points:
Parent ID: | Points:  medium
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:  #17811 =>


--
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] #6939 [Core Tor/Tor]: Missing IPv6 ORPort reachability check

[Tor Bug Tracker & Wiki]

#6939: Missing IPv6 ORPort reachability check
-+-
 Reporter:  shamrock |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, ipv6-relay self-|  Actual Points:
  test   |
Parent ID:  #4565| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #17811 => #4565


--
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] #21311 [Core Tor/Tor]: Exits should resolve IPv6 addresses, regardless of IPv6Exit

[Tor Bug Tracker & Wiki]

#21311: Exits should resolve IPv6 addresses, regardless of IPv6Exit
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 031-deferred-20170425  |  Actual Points:  0.1
Parent ID:  #17811   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #17811


--
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] #22802 [Core Tor/Tor]: Avoid use of "0" with tor_parse_foo()

[Tor Bug Tracker & Wiki]

#22802: Avoid use of "0" with tor_parse_foo()
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 In #22469, tor accepts 0x00 as a port number in the torrc, despite it
 being against the spec. I wonder if we do the same thing when parsing
 ports in other contexts?

--
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] #22469 [Core Tor/Tor]: tor should better validate invalid ipv6 address:port definitions

[Tor Bug Tracker & Wiki]

#22469: tor should better validate invalid ipv6 address:port definitions
--+
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22802| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #22802


Comment:

 This is a benign case of #22802, where we use tor_parse_*() in automatic
 base mode.

--
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] #22697 [Core Tor/Tor]: Tor should mandatory require brackets around ipv6 address

[Tor Bug Tracker & Wiki]

#22697: Tor should mandatory require brackets around ipv6 address
--+
 Reporter:  toralf|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:1 atagar]:
 > 10:21 < atagar> I'd very much favor saying tor should require square
 brackets as it does with the spec. Otherwise your example (reject6
 2a00:1450:4001:0058::7/16:443) is a pita to parse since the '/16' is
 optional, so that means I'd also need to make sense of
 '2a00:1450:4001:0058::7:443'.

 This would break existing torrcs: but we should at least make the brackets
 mandatory when there is a port and no mask.

--
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] #22760 [Core Tor/Tor]: Parse or ignore falback extra-info markers

[Tor Bug Tracker & Wiki]

#22760: Parse or ignore falback extra-info markers
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22759| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We will backport the new fallback list format to 0.2.8 and later, so we
 might need two versions of this code:
 * a backport version that ignores the extrainfo tag
 * a master version that parses the tag, uses it to set the extrainfo type
 via fallback_dir_server_new(), and correctly handles the extrainfo type
 when bootstrapping.

--
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] #22760 [Core Tor/Tor]: Parse or ignore falback extra-info markers

[Tor Bug Tracker & Wiki]

#22760: Parse or ignore falback extra-info markers
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22759| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 There are some more bugs we should fix here:
 * fallback_dir_server_new() shouldn't mark all fallbacks with ALL_DIRINFO
 * SKIP_MISSING_TRUSTED_EXTRAINFO() / router_supports_extrainfo() should
 believe the node, and only use router_digest_is_trusted_dir_type() if the
 node is NULL. (This allows descriptors to override hard-coded settings.)

--
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] #22813 [Applications/Tor Browser]: Multiprocess Firefox hangs! (on Windows)

[Tor Bug Tracker & Wiki]

#22813: Multiprocess Firefox hangs! (on Windows)
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-crash
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Security set to High, but during reading Wikipedia it (7.0.2) hangs
 anyways!
 One of the threads of the main process (with start address
 `firefox.exe+0x14c0`) calls
 {{{
 ntdll.dll!RtlAcquireSRWLockExclusive+0x31 (No unwind info)
 }}}
 and falls into `Wait:Suspended` state.

 P.S.
 Manually resuming the thread brings it back to live.

--
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] #17750 [Core Tor/Tor]: Make bootstrapping clients wait before trying an authority

[Tor Bug Tracker & Wiki]

#17750: Make bootstrapping clients wait before trying an authority
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bootstrap 031-backport   |  Actual Points:  0.3
  030-backport 029-backport  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * keywords:  tor-bootstrap 030-backport 029-backport => tor-bootstrap
 031-backport 030-backport 029-backport


Comment:

 Please see my branch bug17750_029, which also adds some regression tests
 for this bug and #20534.

 I marked this for 0.3.1 backport. If we do backport, we only need to
 backport the squashed commit "Make clients try fallbacks before
 authorities".

 And we might not want to backport at all, given the risk of bugs in older
 versions. The only thing this bug causes is more load on the directory
 authorities.

--
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] #22812 [Core Tor/Tor]: find_dl_min_and_max_delay's DL_SCHED_DETERMINISTIC case is never used

[Tor Bug Tracker & Wiki]

#22812: find_dl_min_and_max_delay's DL_SCHED_DETERMINISTIC case is never used
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.5-alpha
 Severity:  Normal   | Resolution:  not a
 |  bug
 Keywords:  easy technical-debt mostly-harmless  |  Actual Points:  0.1
Parent ID:  #17750   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => closed
 * resolution:   => not a bug
 * parent:   => #17750
 * actualpoints:   => 0.1


Comment:

 Turns out these are actually used, I added comments in my #17750 branch to
 clarify.

--
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] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
-+-
 Reporter:  fredzupy |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.4-alpha
 Severity:  Major| Resolution:
 Keywords:  tor crash inet_pton c99 openbsd  |  Actual Points:
  024-backport 025-backport 026-backport |
  027-backport 028-backport 029-backport |
  030-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 Nothing in C99 7.20.1.4 explicitly says that a string starting with `0x`
 should result in `nptr == *endptr` when `base == 16`.

 It might be ambiguous about whether `0x` is an expected subject sequence
 for `strtol` with `base == 16`.  I think the ambiguity is whether the
 subject sequence is `0` vs `0x`, rather than empty.  7.20.1.4p7 says `nptr
 == *endptr` if the subject sequence "is empty or does not have the
 expected form", but 7.20.1.4p4 defines the subject sequence as "the
 longest initial subsequence of the input string, starting with the first
 non-white-space character, that is of the expected form", so "not have the
 expected form" is redundant because that is impossible for a subject
 sequence as defined.

 It goes on to say that the subject sequence is empty if "the input string
 is empty or consists entirely of white space, or if the first non-white-
 space character is other than a sign or a permissible letter or digit".
 Neither of these is true for a string starting with `0x`, because `0` is a
 permissible digit for `base == 16`.

 This also brings up the question of whether a subject string can consist
 of only a sign prefix.  I think it can be, but the reference to 6.4.4.1
 implies that is not true, at least for `base == 0`, because an ''integer-
 constant'' cannot be empty.

--
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] #22812 [Core Tor/Tor]: find_dl_min_and_max_delay's DL_SCHED_DETERMINISTIC case is never used

[Tor Bug Tracker & Wiki]

#22812: find_dl_min_and_max_delay's DL_SCHED_DETERMINISTIC case is never used
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy technical-debt mostly-harmless  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  easy code-simplification technical-debt mostly-harmless =>
 easy technical-debt mostly-harmless


--
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] #22812 [Core Tor/Tor]: find_dl_min_and_max_delay's DL_SCHED_DETERMINISTIC case is never used

[Tor Bug Tracker & Wiki]

#22812: find_dl_min_and_max_delay's DL_SCHED_DETERMINISTIC case is never used
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core |Version:  Tor: 0.2.9.5-alpha
  Tor/Tor|   Keywords:  easy code-simplification technical-
 Severity:  Normal   |  debt mostly-harmless
Actual Points:   |  Parent ID:
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 find_dl_min_and_max_delay is never called with DL_SCHED_DETERMINISTIC
 schedules. So we should just remove that case entirely. And replace it
 with a BUG() return.

--
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] #22428 [Metrics/CollecTor]: add webstats module to collector

[Tor Bug Tracker & Wiki]

#22428: add webstats module to collector
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_information => accepted


Comment:

 Alright, that makes sense.  I'll add that to the comments for future
 reference.

--
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] #22428 [Metrics/CollecTor]: add webstats module to collector

[Tor Bug Tracker & Wiki]

#22428: add webstats module to collector
---+---
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 No, the goal is to keep Apache's Combined Log Format, so that the
 resulting sanitized logs can still be evaluated using standard tools.

--
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] #22428 [Metrics/CollecTor]: add webstats module to collector

[Tor Bug Tracker & Wiki]

#22428: add webstats module to collector
---+---
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by iwakeh):

 And, second question:  It would probably be more convenient for processing
 to use numbers instead of names for the months.

--
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] #22428 [Metrics/CollecTor]: add webstats module to collector

[Tor Bug Tracker & Wiki]

#22428: add webstats module to collector
---+---
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by iwakeh):

 * status:  accepted => needs_information


--
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] #22428 [Metrics/CollecTor]: add webstats module to collector

[Tor Bug Tracker & Wiki]

#22428: add webstats module to collector
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Currently, treated weblogs contain lines like this:
 {{{
 0.0.0.0 - - [30/May/2017:00:00:00 +] "GET /images/android-icon.png
 HTTP/1.1" 200 21630 "-" "-" -
 }}}

 Could/should that not be reduced to the following?
 {{{
 30/May/2017 "GET /images/android-icon.png HTTP/1.1" 200 21630
 }}}

--
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] #22811 [Metrics/ExoneraTor]: Upgrade libraries to new Debian stable

[Tor Bug Tracker & Wiki]

#22811: Upgrade libraries to new Debian stable
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/exonerator.git/commit/?h=task-22811=f7764a598e6d5b3ef291306ab06bd011f3f736bd
 this commit in my task-22811 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

[tor-bugs] #22811 [Metrics/ExoneraTor]: Upgrade libraries to new Debian stable

[Tor Bug Tracker & Wiki]

#22811: Upgrade libraries to new Debian stable
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 This ticket is the ExoneraTor equivalent of #22800. I'll attach a branch
 as soon as I have a ticket number.

--
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] #22808 [Applications/Tor Browser]: Always apply Do Not Track, and disable checkbox to prevent changing it.

[Tor Bug Tracker & Wiki]

#22808: Always apply Do Not Track, and disable checkbox to prevent changing it.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 It's the opposite actually, DNT is set to false.

 If you're having any concerns about this choice you can search trac for an
 issue relating to this, with special attention to the excellent points
 that mikeperry made.

--
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] #22809 [Applications/Tor Browser]: Tor Browser does not provide red security warning for downloading executable in HTTP

[Tor Bug Tracker & Wiki]

#22809: Tor Browser does not provide red security warning for downloading
executable in HTTP
--+--
 Reporter:  naif  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => ux-team
 * owner:   => tbb-team
 * component:  - Select a component => Applications/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] #21551 [Metrics/Metrics website]: Merge Metrics sub sites into main Tor Metrics website

[Tor Bug Tracker & Wiki]

#21551: Merge Metrics sub sites into main Tor Metrics website
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * priority:  Medium => High


Comment:

 Agreed on moving
 [https://trac.torproject.org/projects/tor/ticket/21551#comment:1 comment 1
 above] to #19754.

 But regarding the original description, not moving forward with this
 ticket is becoming a liability. We're running
 [https://gitweb.torproject.org/karsten/metrics-web.git/log/?h=staging4 my
 staging4 branch] on the Tor Metrics website for a few months now, because
 we haven't merged the `collector.html` and `onionoo.html` pages into
 [https://gitweb.torproject.org/metrics-web.git/log/ master] yet. I'm
 cherry-picking new commits from the master branch and sometimes resolving
 conflicts while doing so. I don't expect it to be much fun to rebase my
 staging4 branch to master, and it'll become even less fun over time.

 Another issue is that I'm avoiding making changes to the CollecTor and
 Onionoo pages, because we'd currently have to make them in two places: in
 their respective repos and in my metrics-web staging4 branch. As a result,
 the typos fixed in #22169 are only fixed on
 https://onionoo.torproject.org/, but not on
 https://metrics.torproject.org/onionoo.html. And I'm holding back the
 #22263 change, because I want to avoid applying that patch twice.

 In short, let's make some decisions here and implement them. Open points,
 and my suggestions, are:

  - How should we support the use case of mirror operators running modified
 versions of Onionoo or CollecTor and wanting to reflect that by providing
 a modified specification page?
- Our original plan was to keep specifications in the Onionoo or
 CollecTor repositories and only include them in metrics-web's `.war` file
 using a Git submodule and some Ant magic. This turns out to be non-
 trivial. While the bulk of pages stays the same, there are a lot of subtle
 differences.
- ''My suggestion:'' How about we kill the `.html` pages in the Onionoo
 and CollecTor repositories and consider the pages in metrics-web as new
 masters? After all, Onionoo and CollecTor are Metrics subprojects and the
 Tor Metrics website is the primary website for Metrics projects. And if
 mirror operators want to adapt these pages, they can quite easily `wget`
 and update them as needed. I feel we're otherwise optimizing for a quite
 special use case here, making the main use case of providing
 specifications for Metrics services unnecessarily hard.
- In the future we could consider providing a schema file on both
 Onionoo and Collector which metrics-web fetches and uses to generate a
 human-readable specification page. This is possibly even a fun project,
 but it's not one that should delay moving away from staging4 much longer.
  - Should we let users browser CollecTor files on the Tor Metrics website
 rather than in Apache-generated directory listings on the CollecTor page?
- ''My suggestion:'' I'd say yes, but that can be done in a subsequent
 patch. Also a fun project.
  - How do we include `.onion` links on the placeholder pages on Onionoo
 and CollecTor?
- We briefly speculated about possible ways to detect how the user
 accesses the placeholder page, and only show the onion or non-onion link.
- ''My suggestion:'' For now, I'd say let's just show both.
  - How do we support the case of different Onionoo hosts running different
 Onionoo protocol versions?
- We said we'd include something like "added in version X" and "removed
 in version Y" in the specification. Sounds totally doable, but maybe in
 the near future as a subsequent patch.
- ''My suggestion:'' For now, let's just show the latest protocol
 version specification, because there's really just one Onionoo protocol
 version deployed.

 If these suggestions sound reasonable, I'll rebase my staging4 branch to
 master, include the #22169 and #22263 fixes, and put it here for review.
 And then we'll create tickets for the suggested follow-up tasks (schema
 files for Onionoo and CollecTor, browse CollecTor files based on
 `index.json`, create placeholder pages with onion and direct link to Tor
 Metrics, include information when an Onionoo document or field was
 added/removed) and do them in the near future as time permits.

 Thoughts, ideas, things that I overlooked? Thanks!

--
Ticket URL: 
Tor 

[tor-bugs] #22810 [Core Tor/Tor]: prop224: Make the client/service extend properly to the IP/RP

[Tor Bug Tracker & Wiki]

#22810: prop224: Make the client/service extend properly to the IP/RP
---+--
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  enhancement| Status:  new
 Priority:  Very High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-hs, prop224, circuit
Actual Points: |  Parent ID:  #21888
   Points:  1  |   Reviewer:
  Sponsor:  SponsorR-must  |
---+--
 For a prop224 service to extend to a rendezvous point (RP) or a client to
 extend to a introduction point (IP), we need two things to change in the
 tor code.

 1) The `extend_info_t` object needs to support a list of "extra" link
 specifiers that should be put in the `EXTEND2` cell if present. From
 proposal 224:

 {{{
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
 }}}

 2) The ed25519 identity link specifier (LSTYPE=03, see prop220), needs to
 be mandatory for both introduction and rendezvous points as detailed in
 prop224. So we need a way to tell the circuit subsystem that "this EXTEND2
 cell is for IP or RP so put the ed25519 id in 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] #22804 [Core Tor/Tor]: Refactor circuit_send_next_onionskin() to be less horribly large

[Tor Bug Tracker & Wiki]

#22804: Refactor circuit_send_next_onionskin() to be less horribly large
-+
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR
-+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm; thanks!

 (Of course, in an ideal world, we would unit tests the hell out of this if
 possible because `circuit_send_next_onion_skin()` has no unit test and
 it's pretty core.)

--
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] #22741 [Core Tor/Torflow]: Make a tool that sends bandwidth to relays stuck with low measurements

[Tor Bug Tracker & Wiki]

#22741: Make a tool that sends bandwidth to relays stuck with low measurements
+
 Reporter:  teor|  Owner:  aagbsn
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Torflow|Version:
 Severity:  Normal  | Resolution:
 Keywords:  bwauth bandwidth tor-relay  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_revision


Comment:

 I'll revise these when I get time.

--
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] #22489 [Core Tor/Tor]: Bridge oftenly reports Failed to find node for hop 0 of our path. Discarding this circuit.

[Tor Bug Tracker & Wiki]

#22489: Bridge oftenly reports Failed to find node for hop 0 of our path.
Discarding this circuit.
+--
 Reporter:  s7r |  Owner:
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-client tor-bridge 030-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by s7r):

 I hit it again few days ago, on the same bridge, 4 times at few minutes
 interval:
 {{{
 Jun 30 12:28:51.000 [warn] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 Jun 30 12:32:27.000 [warn] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 Jun 30 12:39:09.000 [warn] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 Jun 30 12:42:44.000 [warn] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 Jun 30 12:46:57.000 [warn] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 }}}

 The bridge runs in an AS that hosts some other relays. They are in the
 same /24, but part of the same family. Could the bridge try to pick one of
 those relays for its own circuits?

--
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] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
-+-
 Reporter:  fredzupy |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.4-alpha
 Severity:  Major| Resolution:
 Keywords:  tor crash inet_pton c99 openbsd  |  Actual Points:
  024-backport 025-backport 026-backport |
  027-backport 028-backport 029-backport |
  030-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Hmm, cypherpunks write not only truth on Trac...

 Replying to [comment:18 fredzupy]:
 Prefer
 > OpenBSD need to fix something

 Explanation:
 From the common sense PoV: `0` is a valid hexadecimal number.

 Detailed explanation:
 http://www.cplusplus.com/reference/cstdlib/strtol/

--
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] #22809 [- Select a component]: Tor Browser does not provide red security warning for downloading executable in HTTP

[Tor Bug Tracker & Wiki]

#22809: Tor Browser does not provide red security warning for downloading
executable in HTTP
--+-
 Reporter:  naif  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This ticket is to enhance Tor Browser that today does not provide red
 security warning for downloading executable in HTTP in clear text that can
 be easy subject to MITM attacks.

 Actually there's a ticket sitting on Mozilla Firefox to implement exactly
 that https://bugzilla.mozilla.org/show_bug.cgi?id=1303739 .

 The very same should apply for mixed content where from an HTTPS website
 there's download of executable from an HTTP resource.

 Attached the standard warning provided by Firefox that does not explain to
 the end-user how risky is the download of an executable over HTTP in
 clear.

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

Re: [tor-bugs] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
-+-
 Reporter:  fredzupy |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.4-alpha
 Severity:  Major| Resolution:
 Keywords:  tor crash inet_pton c99 openbsd  |  Actual Points:
  024-backport 025-backport 026-backport |
  027-backport 028-backport 029-backport |
  030-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:18 fredzupy]:
 > Replying to [comment:17 catalyst]:
 > > My reading of C99 is that `strtol("0xquux", , 16)` must return
 zero and `next` must point to the `x`.  The optionality in paragraph 3 is
 for the input data, not the implementation.
 >
 > Under Linux produce:
 > l:0 rest:xquux
 >
 > Under OpenBSD produce:
 > l:0 rest:0xquux
 >
 > The question is to know if the Tor code is good enough and OpenBSD need
 to fix something or OpenBSD is sufficiently conformant and the Tor code
 need to adapt.
 >
 I believe the OpenBSD result is correct according to the C99 text and
 contradicts catalyst's statement. Because paragraph 7.20.1.4.7 states
 > If the subject sequence is empty or does not have the expected form, no
 conversion is performed; the value of nptr is stored in the object pointed
 to by endptr, provided that endptr is not a null pointer.
 With the example code, `nptr` does not have the expected form, so no
 conversion is performed therefore `nptr == *endptr`. Furthermore,
 paragraph 7.20.1.4.8 states
 > The strtol, strtoll, strtoul, and strtoull functions return the
 converted value, if any. If no conversion could be performed, zero is
 returned. If the correct value is outside the range of representable
 values, LONG_MIN, LONG_MAX, LLONG_MIN, LLONG_MAX, ULONG_MAX, or ULLONG_MAX
 is returned (according to the return type and sign of the value, if any),
 and the value of the macro ERANGE is stored in errno.
 With the example code, `nptr` does not have the expected form, so no
 conversion is performed therefore the return value is zero.

 Combining these two together means that when the subject sequence is empty
 or does not have the expected form, no conversion is performed and the
 return value is zero and `nptr == *endptr`.

--
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] #22808 [Applications/Tor Browser]: Always apply Do Not Track, and disable checkbox to prevent changing it.

[Tor Bug Tracker & Wiki]

#22808: Always apply Do Not Track, and disable checkbox to prevent changing it.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In current TBB, user can disable DNT by uncheck it. This will distinguish
 user.

 TBB should prevent this by removing this checkbox and forcefully set DNT
 to enabled state.

--
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] #22652 [Metrics/CollecTor]: Adapt CollecTor to metrics-lib 1.9.0

[Tor Bug Tracker & Wiki]

#22652: Adapt CollecTor to metrics-lib 1.9.0
---+-
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  merge_ready => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-22652-3 my task-22652-3 branch] which contains squashed
 commits from my task-22652 branch plus updates to metrics-lib 2.0.0 and to
 libraries in Debian stretch.

--
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] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
-+-
 Reporter:  fredzupy |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.4-alpha
 Severity:  Major| Resolution:
 Keywords:  tor crash inet_pton c99 openbsd  |  Actual Points:
  024-backport 025-backport 026-backport |
  027-backport 028-backport 029-backport |
  030-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by fredzupy):

 Replying to [comment:17 catalyst]:
 > My reading of C99 is that `strtol("0xquux", , 16)` must return zero
 and `next` must point to the `x`.  The optionality in paragraph 3 is for
 the input data, not the implementation.

 In order to clarify a little bit, because it was not obvious for me to
 understand, the following code have different behaviour under different
 system:
 {{{
 #include 
 #include 
 #include 

 int
 main()
 {
 long l;
 char *rest;

 l = strtol("0xquux", , 16);
 printf("l:%ld rest:%s\n", l, rest);

 return 0;
 }
 }}}

 Under Linux produce:
 l:0 rest:xquux

 Under OpenBSD produce:
 l:0 rest:0xquux

 The question is to know if the Tor code is good enough and OpenBSD need to
 fix something or OpenBSD is sufficiently conformant and the Tor code need
 to adapt.

--
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] #22807 [Webpages/Blog]: Content Security Policy (CSP) header not implemented

[Tor Bug Tracker & Wiki]

#22807: Content Security Policy (CSP) header not implemented
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Mozilla Observatory reports that blog.torproject.org does not have a CSP
 header:
 https://observatory.mozilla.org/analyze.html?host=blog.torproject.org

--
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] #22391 [Internal Services/Service - deb.tpo]: Add torrc.d configuration directory on deb packages

[Tor Bug Tracker & Wiki]

#22391: Add torrc.d configuration directory on deb packages
-+-
 Reporter:  Jigsaw52 |  Owner:  weasel
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:  invalid
 Keywords:  deb torrc|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


--
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] #22391 [Internal Services/Service - deb.tpo]: Add torrc.d configuration directory on deb packages

[Tor Bug Tracker & Wiki]

#22391: Add torrc.d configuration directory on deb packages
-+-
 Reporter:  Jigsaw52 |  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  deb torrc|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 This is not the place to discuss bugs/improvements to the debian packaging
 of Tor.  Please file them against the Debian package on the Debian BTS.

 https://bugs.debian.org/
 https://bugs.debian.org/tor
 https://bugs.debian.org/866187

--
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] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security, tbb-sandboxing  |  Actual Points:
Parent ID:  #20775| Points:
 Reviewer:|Sponsor:
--+--
Changes (by intrigeri):

 * cc: intrigeri (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