date:20170919

Re: [tor-bugs] #22542 [Applications/Tor Browser]: Tor Browser 7.0 Security Settings Window too small on macOS 10.12

2017-09-19 Thread Tor Bug Tracker & Wiki

#22542: Tor Browser 7.0 Security Settings Window too small on macOS 10.12
-+-
 Reporter:  teor |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-security-slider, TorBrowserTeam201707R,|
  tbb-backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-7.0-issues, tbb-regression, tbb-security-slider,
 TorBrowserTeam201707R, tbb-backport
 =>
 tbb-7.0-issues, tbb-regression, tbb-security-slider,
 TorBrowserTeam201707R, tbb-backported


Comment:

 Picking this up for 1.9.7.7 (commit
 9aa6f29c896be65a4f883dd4bd73f48e07d359a7).

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

Re: [tor-bugs] #20375 [Applications/Tor Browser]: warn users when entering fullscreen

2017-09-19 Thread Tor Bug Tracker & Wiki

#20375: warn users when entering fullscreen
-+-
 Reporter:  fem  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability, tbb-fingerprinting,   |  Actual Points:
  tbb-torbutton, TorBrowserTeam201708R, tbb- |
  backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Picking this up for 1.9.7.7 (commit
 d68d2b68366af9456adf8c152e127ec5c10344c5).

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

Re: [tor-bugs] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

2017-09-19 Thread Tor Bug Tracker & Wiki

#21830: Copying large text from web console leaks to /tmp
-+-
 Reporter:  gk   |  Owner:  neillm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-disk-leak,   |  Actual Points:
  TorBrowserTeam201708R, tbb-backported  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-disk-leak, TorBrowserTeam201708R, tbb-backport => tbb-
 disk-leak, TorBrowserTeam201708R, tbb-backported


Comment:

 Taking this for the stable (7.0.6). Cherry-picked to `tor-
 browser-52.3.0esr-7.0-1` (commit
 7a1b25245e73051cb724a7eb6a66de18263f88c2).

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

Re: [tor-bugs] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

2017-09-19 Thread Tor Bug Tracker & Wiki

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Vort):

 * cc: vvort@… (added)


Comment:

 Same thing for 0.3.1.7 (custom build) and Windows 7:
 {{{
 Sep 19 12:33:13.743 [notice] Tor 0.3.1.7 running on Windows 7 with
 Libevent 2.0.22-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and
 Libzstd 1.3.1.
 ...
 Sep 19 23:36:30.000 [warn] tor_bug_occurred_(): Bug: compress.c:576:
 tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) &&
 *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor
 0.3.1.7 )
 Sep 19 23:36:30.000 [warn] Bug: Non-fatal assertion !((rv ==
 TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig)
 failed in tor_compress_process at compress.c:576. (Stack trace not
 available) (on Tor 0.3.1.7 )
 }}}

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

Re: [tor-bugs] #19760 [Core Tor/Tor]: Update longclaw's hard-coded IPv6 address

2017-09-19 Thread Tor Bug Tracker & Wiki

#19760: Update longclaw's hard-coded IPv6 address
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  dir-auth, ipv6, 028-backport,|  Actual Points:  0.2
  029-backport, 030-backport, 031-backport,  |
  032-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-

Comment (by teor):

 I made a ticket for the IPv4 change at #23592.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23592 [Core Tor/Tor]: Update longclaw's IPv4 address (after it moves)

2017-09-19 Thread Tor Bug Tracker & Wiki

#23592: Update longclaw's IPv4 address (after it moves)
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal|   Keywords:  tor-dir-auth
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 Longclaw will soon move IPv4 addresses. Its current address was added in
 0.2.6.2-alpha.

 Will it have multiple IPv4 addresses?
 (One for the hard-coded address, and one for the consensus?)

 How does this impact 0.2.5 clients?
 * Clients with a consensus will use whatever address longclaw signs in its
 relay descriptor
 * Clients without a consensus:
   * 0.2.8 and later try multiple authorities without waiting for failures,
 so they will be fine
   * 0.2.4, 0.2.6, and 0.2.7 are no longer supported:
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

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

Re: [tor-bugs] #19760 [Core Tor/Tor]: Update longclaw's hard-coded IPv6 address

2017-09-19 Thread Tor Bug Tracker & Wiki

#19760: Update longclaw's hard-coded IPv6 address
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  dir-auth, ipv6, 028-backport,|  Actual Points:  0.2
  029-backport, 030-backport, 031-backport,  |
  032-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 Replying to [comment:13 micah]:
 > I think that the IPv6 address for longclaw should be removed in the
 source code. It was only a temporary address that I setup on teor's
 request for testing and never was meant to be something that stuck.
 Additionally, longclaw will be moving to a new location, so its ipv6
 address will go away then (I'm unsure when it will get a new one)

 See my branch longclaw-ipv6-028, which implements this change. The address
 was added in 0.2.8, so it only needs to be backported that far. We don't
 need to worry about clients here: 0.2.8 and later have plenty of fallback
 directory mirrors on IPv6, which isn't on by default anyway.

 > as well as its ipv4 address.

 Now, that will be more interesting. I assume you mean both the hard-coded
 IPv4 address, and the one in the consensus? Have they changed at all since
 longclaw was added in 0.2.6.2-alpha / 0.2.5.11 / 0.2.4.26 ?

 Here's what clients will do:
 * Clients with a consensus will use whatever address longclaw signs in its
 relay descriptor
 * Clients without a consensus:
   * 0.2.8 and later try multiple authorities without waiting for failures,
 so they will be fine
   * 0.2.4, 0.2.6, and 0.2.7 are no longer supported:
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases
   * for 0.2.5, I will pull out the email that arma and I worked on last
 time we changed directory authority details, and re-post it to tor-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] #19760 [Core Tor/Tor]: Update longclaw's hard-coded IPv6 address

2017-09-19 Thread Tor Bug Tracker & Wiki

#19760: Update longclaw's hard-coded IPv6 address
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  dir-auth, ipv6, 028-backport,|  Actual Points:  0.2
  029-backport, 030-backport, 031-backport,  |
  032-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-
Changes (by teor):

 * keywords:  dir-auth, ipv6, 029-proposed =>
 dir-auth, ipv6, 028-backport, 029-backport, 030-backport,
 031-backport, 032-backport
 * owner:  (none) => teor
 * actualpoints:   => 0.2


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

Re: [tor-bugs] #18892 [Core Tor/Tor]: Add IP versions to man page

2017-09-19 Thread Tor Bug Tracker & Wiki

#18892: Add IP versions to man page
-+
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  easy, doc, docs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

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


Comment:

 The child tickets are all merged, closing this ticket.

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

Re: [tor-bugs] #22995 [Core Tor/Tor]: prop224 should say we use SHA3-256 for rend circuit digests

2017-09-19 Thread Tor Bug Tracker & Wiki

#22995: prop224 should say we use SHA3-256 for rend circuit digests
+
 Reporter:  teor|  Owner:  asn
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  prop224, tor-spec, doc  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by teor):

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


Comment:

 That's fine, I was confusing it with the similar section in tor-spec.txt.

 I think we can leave it as-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

[tor-bugs] #23591 [Applications]: Build Tor and Tor Browser with -mmitigate-rop

2017-09-19 Thread Tor Bug Tracker & Wiki

#23591: Build Tor and Tor Browser with -mmitigate-rop
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 GCC 6 has a new option, `-mmitigate-rop`, which modifies the generated
 code to make finding ROP gadgets a bit harder. This is ''not'' CFI and
 does not provide strong protections, but it's better than nothing and is
 easier to use than alternatives, given that it doesn't require modifying
 source code for compatibility or loading a new runtime.

 >-mmitigate-rop
 >Try to avoid generating code sequences that contain unintended
 >return opcodes, to mitigate against certain forms of attack. At the
 >moment, this option is limited in what it can do and should not be
 >relied on to provide serious protection.

 I suppose someone should try compiling Tor with this and scan for ROP
 gadgets using popular ROP compilers on 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] #20955 [Applications/Tor Browser]: Tor Browser memory hardening

2017-09-19 Thread Tor Bug Tracker & Wiki

#20955: Tor Browser memory hardening
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I'm a bit weary about using a memory allocator from a research paper.
 There are alternatives that are actively developed and regularly used in
 production systems, like OpenBSD malloc and Copperhead malloc. They also
 do not come with the risk of the authors not maintaining the source as
 they move on to another research project. Personally, I would very
 strongly recommend the Copperhead malloc, as it's an improvement over even
 the OpenBSD malloc in quite a few ways, and has some very interesting
 hardening techniques planned for the future.

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

Re: [tor-bugs] #12418 [Applications/Tor Browser]: TBBs with UBSan create lots of errors when running

2017-09-19 Thread Tor Bug Tracker & Wiki

#12418: TBBs with UBSan create lots of errors when running
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201709  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:13 tom]:
 > What do you mean by "amount of UBSAN"?  There are some checks that
 should have basically no false-positives (like pointer overflow) - those
 should be feasible for whole-browser I think.

 Amount of UB (undefined behavior), not amount of UBSAN. And yes, some
 checks seem to very compatible with many programs (`-fsanitize=object-
 size` for example). Those should be the first tested, though instrumenting
 the image decoders as thoroughly as possible should be high priority.

 Just a side-note, but `-ftrapv` and friends interfere with `-fsanitize
 =signed-integer-overflow`, such that the former disables the latter, even
 though it is easier to bypass. They should never be combined.

 > Instrumenting components with more verbose tests (like int overflows) is
 definitely valuable though!
 >
 > Mind you, Mozilla's not going to ship Firefox with UBSAN enabled, we'll
 just run tests with it to catch issues. Maybe Tor would ship something
 with UBSAN (??) but maybe not since I don't think you can enable both ASAN
 and UBSAN.

 You can enable both ASAN and UBSAN, but ASAN is not intended for use in
 production systems for security as the complex runtime can introduce
 vulnerabilities, and it's quite easy to bypass anyway considering it's
 looking for unintentional bugs that aren't trying to be stealthy. UBSAN on
 the other hand is fine for production use.

 > Well, It's a big org, we're not all bad ;)  But I hear you loud and
 clear. My main point was not "Try and get Mozilla to take your patches"
 but rather "You can almost certainly make use of Mozilla's infrastructure
 to do experimental runs and examine the output."  For example, you could
 queue up 10 jobs that turn on UBSAN for 10 individual components, and run
 them all at once.

 I have a small cluster of computers which I can use to do the test myself,
 so long as I have the code for the unit tests. Getting trusted by Mozilla
 to the point where I can use their test infrastructure is not something
 I'm eager to commit to.

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

[tor-bugs] #23590 [Applications/Tor Browser]: Tor Browser needs write access to /dev/shm

2017-09-19 Thread Tor Bug Tracker & Wiki

#23590: Tor Browser needs write access to /dev/shm
--+--
 Reporter:  cypherpunks   |  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:|
--+--
 A user on the Tor IRC was having problems running Tor Browser, with the
 browser not starting up and outputting an error:

 `Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed 2 buffer`

 Searching the error gave few results, but eventually I stumbled across a
 blog post suggesting that the problem was related to the filesystem
 permissions of `/dev/shm`: https://gkiseki.wordpress.com/2017/07/25
 /slackware-currentの不具合/

 On my system (Gentoo GNU/Linux), Tor Browser works, and `/dev/shm` is mode
 1777 (readable/writable by all, with sticky bit set). On his system
 (Debian GNU/Linux), it is mode 755 instead (readable/writable by root,
 readable by world). When he switched to mode 1777, the browser finally
 opened, and the error went away.

 Many systems have this directory set to mode 755 or even 700 permissions,
 which would suggest that these systems will not be able to run Tor
 Browser. I didn't look into this in detail, but it appears to be related
 to Glib's graphics handling.

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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

2017-09-19 Thread Tor Bug Tracker & Wiki

#23483: Donation banner on about:tor page for 2017 campaign
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201609  |  Actual Points:
Parent ID:  #23482  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 BTW, I ended up using design 2 among the two alternatives, because the
 text positioning in design 1 required too much finesse. Every time I got
 the text in the right location for one locale, it became badly positioned
 in another locale.

 And I should mention, I wrote positioning code RTL languages. So it should
 work if we get Arabic, Farsi, or Hebrew translations. There aren't any
 translations for those locales yet, however, so I tested with dummy text.

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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

2017-09-19 Thread Tor Bug Tracker & Wiki

#23483: Donation banner on about:tor page for 2017 campaign
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201609  |  Actual Points:
Parent ID:  #23482  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 Here's a patch using the background image and layout concept from Mark
 Hardin and text from the crowfunding team. Please review. :)
 https://github.com/arthuredelstein/torbutton/commit/23483

 To test the banner, it's necessary to pull down the latest translations,
 build the torbutton xpi, install it in Tor Browser (release or alpha) and
 set the pref "extensions.torbutton.testBanner" to true in about:config.

 Currently we have translations for [en, es, fr, it, tr] (plus some
 languages we don't currently release). If more translations have been
 completed at bundle time, then we will need to add those two-letter codes
 to the list located
 [https://github.com/arthuredelstein/torbutton/commit/23483#diff-
 0486c7dd22caf1044540b9765e704ef7R9 here].

 I tested this patch on Mac, Linux, and Windows TBB 7.0. I also tested on
 Mac TBB 7.5. The banner is designed to first appear to users on October
 23, 2017.

 Here are some screen shots. (There's a horizontal scroll bar at the bottom
 of this comment that lets you see the right edge of the images.)
 [[Image(Screen Shot 2017-09-19 at 7.31.01 PM.png)]]
 [[Image(Screen Shot 2017-09-19 at 7.29.41 PM.png)]]
 [[Image(Screen Shot 2017-09-19 at 7.43.40 PM.png)]]

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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

2017-09-19 Thread Tor Bug Tracker & Wiki

#23483: Donation banner on about:tor page for 2017 campaign
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201609  |  Actual Points:
Parent ID:  #23482  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * Attachment "Screen Shot 2017-09-19 at 7.43.40 PM.png" 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] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

2017-09-19 Thread Tor Bug Tracker & Wiki

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
--+---
 Reporter:  arthuredelstein   |  Owner:  sysrqb
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sysrqb):

 Can we map any unrecognized keys to a single keycode? There will certainly
 be a long tail of characters that aren't explicitly included here, we
 should handle them gently.

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

Re: [tor-bugs] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

2017-09-19 Thread Tor Bug Tracker & Wiki

#23483: Donation banner on about:tor page for 2017 campaign
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201609  |  Actual Points:
Parent ID:  #23482  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * Attachment "Screen Shot 2017-09-19 at 7.31.01 PM.png" 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] #23483 [Applications/Tor Browser]: Donation banner on about:tor page for 2017 campaign

2017-09-19 Thread Tor Bug Tracker & Wiki

#23483: Donation banner on about:tor page for 2017 campaign
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  crowdfunding, TorBrowserTeam201609  |  Actual Points:
Parent ID:  #23482  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * Attachment "Screen Shot 2017-09-19 at 7.29.41 PM.png" 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] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

2017-09-19 Thread Tor Bug Tracker & Wiki

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
--+---
 Reporter:  arthuredelstein   |  Owner:  sysrqb
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  assigned => needs_information


Comment:

 Basically we are implementing a virtual customized keyboard layout. This
 layout does not contain Right-keys (location 2, keys on right side). It is
 a QWERTY keyboard based on the "English (US)" layout, therefore any non-
 English characters will be mapped onto US-centric keys when combined with
 a modifier. We'll need both shift and AltGr (as the combination of
 asserting ctrl and alt) for this, else we don't have enough combinations
 available.

 The US-International keyboard layout [0] provides a nice base, so
 beginning with that we gain:

 With AltGr:
 {{{
 ¡ ² ³ ¤ € ¼ ½ ¾ ‘ ’ ¥ ×
  ä å é ® þ ü ú í ó ö « »
   á ß ð   ø ¶ ´ ¬
æ   © ñ µ ç   ¿
 }}}

 With Shift-AltGr:
 {{{
 ¹ £   ÷
  Ä Å É   Þ Ü Ú Í Ó Ö
   Á § Ð   Ø ° ¨ ¦
Æ   ¢ Ñ   Ç
 }}}

 What other keys are missing? Some layouts provide 1/8, 3/8, 5/8, 7/8, ™,
 ˆ. Should these be included?

 What is the expected result if a key is not recognized? Should torbrowser
 drop it? I'm worried about the impact on usability if torbrowser does
 something surprising when a user presses a key that "should work". With
 that said, any keys not included in this custom layout continue to be a
 potential fingerprint.

 [0] https://en.wikipedia.org/wiki/AltGr_key#US-International
 [1] https://en.wikipedia.org/wiki/AZERTY

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

Re: [tor-bugs] #23589 [Core Tor/Tor]: Stop assuming that every extend_info contains an IPv4 address in get_lspecs_from_extend_info()

2017-09-19 Thread Tor Bug Tracker & Wiki

#23589: Stop assuming that every extend_info contains an IPv4 address in
get_lspecs_from_extend_info()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 This is safe, because all client extend infos are IPv4.

 Even if they are not, if addr is an IPv6 address, the IPv4 address ends up
 being 0.0.0.0. And it gets rejected in hs_get_extend_info_from_lspecs() by
 extend_info_addr_is_allowed().

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

Re: [tor-bugs] #23502 [Core Tor/Tor]: prop224: Don't make IPv4 mandatory because one day we'll have IPv6 only relays

2017-09-19 Thread Tor Bug Tracker & Wiki

#23502: prop224: Don't make IPv4 mandatory because one day we'll have IPv6 only
relays
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tor-relay, tor-hs  |  Actual Points:
Parent ID:  #23493  | Points:
 Reviewer:  asn |Sponsor:
+--
Changes (by teor):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.2.x-final


Comment:

 I think this is a good idea, and I'd be happy to include it in 0.3.2 if
 it's rebased on top of my bug23493.

 At the very least, we need to make sure we won't crash if IPv4 is left
 out, and we should just discard the particular link specifier and try
 again.

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

Re: [tor-bugs] #23507 [Core Tor/Tor]: Add single onion unreachable address algorithm to prop224

2017-09-19 Thread Tor Bug Tracker & Wiki

#23507: Add single onion unreachable address algorithm to prop224
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, tor-spec, prop224, tor-hs,  |  Actual Points:
  single-onion, ipv6 |
Parent ID:  #23493   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:1 dgoulet]:
 > I do think we have all this logic in place already *except* for the
 concept of both IPv4 or IPv6 but that is a know limitation for now and
 postponed to 033 (#23502).
 >
 > Can you confirm it?
 > ...
 > Again, you'll notice that the IPv6 problem in #23502 aren't addressed
 but apart from that, is the algorithm you describe followed?

 No, it's broken in several places in 0.3.2.1-alpha (single onion service
 descriptor link specifiers, and fallback 3-hop connections for intro and
 rend). That's why the test doesn't work.

 For fixes for 0.3.2 and a plan for 0.3.3, see
 https://trac.torproject.org/projects/tor/ticket/23493#comment:9

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

Re: [tor-bugs] #23502 [Core Tor/Tor]: prop224: Don't make IPv4 mandatory because one day we'll have IPv6 only relays

2017-09-19 Thread Tor Bug Tracker & Wiki

#23502: prop224: Don't make IPv4 mandatory because one day we'll have IPv6 only
relays
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tor-relay, tor-hs  |  Actual Points:
Parent ID:  #23493  | Points:
 Reviewer:  asn |Sponsor:
+--

Comment (by teor):

 For the bugs in 0.3.2.1-alpha, and the current plan for 0.3.2 and 0.3.3,
 see https://trac.torproject.org/projects/tor/ticket/23493#comment:9

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

Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

2017-09-19 Thread Tor Bug Tracker & Wiki

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

2017-09-19 Thread Tor Bug Tracker & Wiki

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  0.5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * actualpoints:   => 0.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] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

2017-09-19 Thread Tor Bug Tracker & Wiki

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 This comments section got complicated, so I'm going to summarise the
 issues in 0.3.2.1-alpha, my suggested changes in my bug23493 branch, and
 what we should fix in 0.3.3.

 My branch bug23493 completes the implementation of the single onion
 service reachability algorithm in #23507. This is the minimum we need to
 do for functional single onion services with
 ReachableAddresses/ClientUseIPv6 in 0.3.2. (The alternative is to rip out
 some of the existing implementation, which I think is worse.)

 This is how v3 single onion services will work after we merge this branch:
 * services choose intro points they can reach, if possible (0.3.2.1-alpha)
   * if not, they choose any valid intro point (0.3.2.1-alpha)
 * services connect to intro points directly, if possible (0.3.2.1-alpha)
   * if not, they fail to connect (0.3.2.1-alpha)
   * if not, they connect over a 3-hop path (bug23493)
 * services put IPv4 addresses for those intro points in the descriptor
 (bug23493)
 * clients choose rend points (0.3.2.1-alpha)
   * clients know about single onion services from the descriptor, but they
 don't do anything different for them, and they don't need to
 (0.3.2.1-alpha)
 * clients put rend point IPv4 addresses in the INTRODUCE cell
 (0.3.2.1-alpha)
 * services choose a reachable rend address from the INTRODUCE cell, if
 possible (0.3.2.1-alpha)
   * if not, they fail to connect (0.3.2.1-alpha)
   * if not, they connect over a 3-hop path (bug23493)

 This is what we'll change in 0.3.3 for v3 onion services:
 * services put IPv4 and IPv6 addresses for their intro points in the
 descriptor (#23576)
 * clients put rend point IPv4 and IPv6 addresses in the INTRODUCE cell
 (#23577, #23589)
 * single onion services choose rend via direct IPv6, when IPv6 is
 reachable and isn't preferred, but IPv4 is unreachable (#23588)
   * in 0.3.2.1-alpha, they fail in this rare case, which can only be
 triggered by 0.3.3 clients with fixes for #23577 and #23589
   * in bug23493, they use a 3-hop path in this rare case, which can only
 be triggered by 0.3.3 clients with fixes for #23577 and #23589

 I've deferred all the other child tickets to 0.3.3.

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

Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

2017-09-19 Thread Tor Bug Tracker & Wiki

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  dgoulet => teor
 * status:  accepted => assigned


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #23502, #23576, #23577, #23588, ...

2017-09-19 Thread Tor Bug Tracker & Wiki

Batch modification to #23502, #23576, #23577, #23588, #23589 by teor:
milestone to Tor: 0.3.3.x-final

Comment:
These tickets aren't urgent, and they involve major refactoring.
Deferring to 0.3.3

--
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] #23560 [Core Tor/Tor]: Fix typo(s) in comment(s) in the scheduling system.

2017-09-19 Thread Tor Bug Tracker & Wiki

#23560: Fix typo(s) in comment(s) in the scheduling system.
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 lgtm; merged!

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

Re: [tor-bugs] #23560 [Core Tor/Tor]: Fix typo(s) in comment(s) in the scheduling system.

2017-09-19 Thread Tor Bug Tracker & Wiki

#23560: Fix typo(s) in comment(s) in the scheduling system.
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by pastly):

 * status:  assigned => merge_ready


Comment:

 `bug23560_032_01`

 Thanks arma for the contributions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23589 [Core Tor/Tor]: Stop assuming that every extend_info contains an IPv4 address in get_lspecs_from_extend_info()

2017-09-19 Thread Tor Bug Tracker & Wiki

#23589: Stop assuming that every extend_info contains an IPv4 address in
get_lspecs_from_extend_info()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core |Version:
  Tor/Tor|
 Severity:  Normal   |   Keywords:  prop224, tor-hs, single-onion, ipv6
Actual Points:   |  Parent ID:  #23493
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 addr can be an IPv6 address

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

2017-09-19 Thread Tor Bug Tracker & Wiki

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|
 Severity:  Normal   |   Keywords:  prop224, tor-hs, single-onion, ipv6
Actual Points:   |  Parent ID:  #23493
   Points:  1|   Reviewer:
  Sponsor:   |
-+-
 Currently, the address choice logic is:
 * if we have an IPv6 address and can reach the ls IPv6 address, and prefer
 IPv6, use it
 * if we have an IPv4 address and can reach the ls IPv4 address, use it

 But it needs to be:
 * if we have both addresses and can reach both, then use whatever we
 prefer
 * if we have one address and can reach it, use it

 This doesn't matter until clients put IPv6 addresses in the link
 specifier.

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

Re: [tor-bugs] #23566 [Core Tor/Tor]: options/validate__transproxy fails on FreeBSD (thanks to the new scheduler)

2017-09-19 Thread Tor Bug Tracker & Wiki

#23566: options/validate__transproxy fails on FreeBSD (thanks to the new 
scheduler)
---+
 Reporter:  pastly |  Owner:  pastly
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-sched, regression  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Sure, let's give it a try.  Merged.

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

Re: [tor-bugs] #22931 [Core Tor/Tor]: What happens when a VERSIONS cell is sent outside a handshake?

2017-09-19 Thread Tor Bug Tracker & Wiki

#22931: What happens when a VERSIONS cell is sent outside a handshake?
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  doc tor-spec  |  Actual Points:
Parent ID:  #18856| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #22929 [Core Tor/Tor]: What cells can be sent before a VERSIONS cell, and what is their CIRCID_LEN?

2017-09-19 Thread Tor Bug Tracker & Wiki

#22929: What cells can be sent before a VERSIONS cell, and what is their
CIRCID_LEN?
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-spec, spec  |  Actual Points:
Parent ID:  #18856  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #22929 [Core Tor/Tor]: What cells can be sent before a VERSIONS cell, and what is their CIRCID_LEN?

2017-09-19 Thread Tor Bug Tracker & Wiki

#22929: What cells can be sent before a VERSIONS cell, and what is their
CIRCID_LEN?
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, spec  |  Actual Points:
Parent ID:  #18856  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_review


Comment:

 My branch bug22929 fixes #22929 and #22931.

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

Re: [tor-bugs] #22931 [Core Tor/Tor]: What happens when a VERSIONS cell is sent outside a handshake?

2017-09-19 Thread Tor Bug Tracker & Wiki

#22931: What happens when a VERSIONS cell is sent outside a handshake?
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc tor-spec  |  Actual Points:
Parent ID:  #18856| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 My branch bug22929 fixes #22929 and #22931.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23587 [Metrics/Website]: userstats-bridge-transport.html says that bridge users come from counting requests (not responses)

2017-09-19 Thread Tor Bug Tracker & Wiki

#23587: userstats-bridge-transport.html says that bridge users come from 
counting
requests (not responses)
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 https://metrics.torproject.org/userstats-bridge-transport.html
 ([https://web.archive.org/web/20170919232058/https://metrics.torproject.org
 /userstats-bridge-transport.html archive]) says "These numbers are derived
 from directory requests counted on bridges."

 But #18203 says that bridge estimate come from counting ''responses'', not
 ''requests'': "We're using the number of responses to estimate bridge
 users but the number of requests to estimate direct users."

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

Re: [tor-bugs] #23566 [Core Tor/Tor]: options/validate__transproxy fails on FreeBSD (thanks to the new scheduler)

2017-09-19 Thread Tor Bug Tracker & Wiki

#23566: options/validate__transproxy fails on FreeBSD (thanks to the new 
scheduler)
---+
 Reporter:  pastly |  Owner:  pastly
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, regression  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by pastly):

 * status:  assigned => needs_review


Comment:

 `bug23566_032_01`

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

Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

2017-09-19 Thread Tor Bug Tracker & Wiki

#22266: fix the jump-to-80% issue
---+---
 Reporter:  catalyst   |  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by catalyst):

 * keywords:  usability, ux, ux-team => usability, ux, ux-team, bootstrap


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

Re: [tor-bugs] #23537 [Core Tor/Tor]: Allow the new sched to respond to a new conensus, not the old one.

2017-09-19 Thread Tor Bug Tracker & Wiki

#23537: Allow the new sched to respond to a new conensus, not the old one.
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 merged; ty!

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

Re: [tor-bugs] #23537 [Core Tor/Tor]: Allow the new sched to respond to a new conensus, not the old one.

2017-09-19 Thread Tor Bug Tracker & Wiki

#23537: Allow the new sched to respond to a new conensus, not the old one.
-+
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by pastly):

 * status:  assigned => merge_ready


Comment:

 `bug23537_032_01` on muh gitweb

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

Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

2017-09-19 Thread Tor Bug Tracker & Wiki

#22266: fix the jump-to-80% issue
+
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  High|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  usability, ux, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by catalyst):

 The controller-visible bootstrap phase always starts from 0 when tor
 starts up (even if DisableNetwork is 1, I think); phase 0 is always the
 first bootstrap event sent to the control connection.  The trigger for
 reaching phase 80 is having a consensus (though not necessarily an up-to-
 date-one; this is probably a bug!) and enough descriptors to build
 circuits.  This might not happen immediately upon setting
 DisableNetwork=0.  I haven't checked all of the ways this happens -- the
 relevant bootstrap event reporting is in
 `update_router_have_minimum_dir_info()` which is called by
 `router_have_minimum_dir_info()`, and the latter gets called through
 several paths, some of which look like timer-triggered events that occur
 once per second.

 That said, I think there are several reasons to not show a bootstrap phase
 of 80 in circumstances where we currently do so:
 * The consensus might be stale, so we should download a new one.
 * We might not be able to connect to any relays.  This means we might not
 get anywhere near 80 in our current configuration, maybe not even as far
 as 10 or 20.
 * Our clock might be skewed by several hours, so we might be stuck at 80
 forever trying to download an up-to-date consensus (with very large
 exponential timeouts) and never succeeding.  (See #23508.)

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

Re: [tor-bugs] #18203 [Metrics/Statistics]: Base direct user estimates on responses to directory requests, rather than responses

2017-09-19 Thread Tor Bug Tracker & Wiki

#18203: Base direct user estimates on responses to directory requests, rather 
than
responses
+
 Reporter:  karsten |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by dcf):

 * cc: dcf (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] #23586 [Webpages/Website]: fingerprint in documentation is wrong

2017-09-19 Thread Tor Bug Tracker & Wiki

#23586: fingerprint in documentation is wrong
--+-
 Reporter:  kkuehl@…  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  gpg fingerprint
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 From  https://www.torproject.org/docs/verifying-signatures.html.en
 You should see:

 pub   4096R/93298290 2014-12-15
   Key fingerprint = EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329
 8290
 uid  Tor Browser Developers (signing key)
 sub   4096R/F65C2036 2014-12-15
 sub   4096R/D40814E0 2014-12-15
 sub   4096R/C3C07136 2016-08-24

 Which is probably just outdated information

 From the command line:
 gpg --fingerprint 0x4E2C6E8793298290
 pub   rsa4096 2014-12-15 [C] [expires: 2020-08-24]
   EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
 uid   [ unknown] Tor Browser Developers (signing key)
 
 sub   rsa4096 2016-08-24 [S] [expires: 2018-08-24]

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

Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

2017-09-19 Thread Tor Bug Tracker & Wiki

#22266: fix the jump-to-80% issue
+
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  High|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  usability, ux, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by mcs):

 * status:  new => needs_information


Comment:

 Although the Tor Launcher fix in #23240 has been merged and seems to work,
 as Kathy and I are working on the revised Tor Launcher UI we have
 discovered that the approach used in our fix for #23240 no longer works.
 Specifically, after implementing #23262 (integrated progress bar), we see
 that a tor that has cached directory information (80% start) returns
 `PROGRESS=0` in response to the `GETINFO status/bootstrap-phase` command
 that Tor Launcher sends. This is surprising; Kathy and I think the right
 answer is `PROGRESS=80`. The problem with receiving zero is that our
 strategy for #23240 was to keep the progress bar hidden until we queried
 tor to find out the current bootstrap progress value.

 Tor Launcher starts tor with DisableNetwork=1 on the command line, and
 here is the sequence of control port commands that is issued:
 {{{
 SETCONF UseBridges Bridge
 SETCONF Socks4Proxy Socks5Proxy Socks5ProxyUsername Socks5ProxyPassword
 HTTPSProxy HTTPSProxyAuthenticator
 SETCONF ReachableAddresses
 SETCONF DisableNetwork=0
 SAVECONF
 GETINFO status/bootstrap-phase
 }}}

 It is that last command that returns `PROGRESS=0`.

 Can someone on the networking team confirm that this is occurring due to
 the internal architecture of tor? E.g., when `DisableNetwork=0` is
 received when networking is disabled, the process of enabling the
 networking code must be asynchronous (which leads to the confusing
 `GETINFO status/bootstrap-phase` response). That would explain problems
 like #15715 as well (and we do see what to us are spurious "Disable
 Network is set" NOTICE message in our testing because the commands above
 are immediately followed by some `GETCONF` commands).

 With Tor Launcher's current, separate progress window things work okay
 because there is enough delay between the `SETCONF DisableNetwork=0` and
 the `GETINFO status/bootstrap-phase` commands that tor returns
 `PROGRESS=80`.

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

Re: [tor-bugs] #23569 [Internal Services/Tor Sysadmin Team]: Please create email alias for Richard

2017-09-19 Thread Tor Bug Tracker & Wiki

#23569: Please create email alias for Richard
-+
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

 * 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] #21139 [Metrics/CollecTor]: add javadoc overview page to CollecTor

2017-09-19 Thread Tor Bug Tracker & Wiki

#21139: add javadoc overview page to CollecTor
---+---
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 See [https://trac.torproject.org/projects/tor/ticket/21138#comment:8 my
 comment 8 on #21138] for a related question.

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

Re: [tor-bugs] #23569 [Internal Services/Tor Sysadmin Team]: Please create email alias for Richard

2017-09-19 Thread Tor Bug Tracker & Wiki

#23569: Please create email alias for Richard
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ewyatt):

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Please create an email alias and set up LDAP access for Richard, our new
 desktop browser developer.

 First name: Richard
 Last name: Pospesel
 Desired uid/email alias: rich...@torproject.org
 Forwarding address: pospes...@riseup.net
 BE7C 914C C922 CED9 D93D  23B7 DE47 3603 63F3 4B2C

 Thanks!

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIcBAEBCgAGBQJZwX0IAAoJELoMlAD4D5HOGNwP/3u/zMLAoGE8cFW/ir0/Pups
 Q9/3i7DN/5eNzsi11EJhQX0CDL8rn60WL4Tb6h3hB74WR1XXljEg8+Vc77epR2gE
 kbIIcm2NsDMBtIVW1vCemcnIZ7aT7aEVP1g/0ym40jfrju6a4ICDVEKoGN81/S9E
 YhsnJF/8RLFnq/UOc6MXQCrHNJwGnPLIlk1Z6xHRpHv0CutixiOiZ1AeTke+pedN
 Lg2icNAZTExDpcciUEI51xOS7hvQSym66c+CIsH5rXfNh+WUDbII+lrUXXG3Fv3s
 TB+ZswFQ1fS3pfSNWKk2QEXjvmMSILbqBnnTrl9nKzchHuS/zUnCu9KFOp1USFzF
 dH+Jy2CJkcR3sdGLVW5IpDdfTPaXiO8ZXYDlQxA38XQxfo4cU47kC8Tpz7EtLAd3
 2onTHIYWyvmP/ABI/0QdgXeOLqAijAFSRXAexK89DM6CxVTNG0xIJLt6PQJ3IV0E
 vdcB3GgTWoKPagV7w6NbjIEQ+epA5792nGaBm8SiQwfNy+gVJo/Yupjjo3byDuLf
 Uqr6iRygJpf3ZBDj+q/3c+WiSoZRwnq8IFV1HWDVWHQY2NzQVAhosDM03jazW4g7
 UnYfmR0aAbjY6HU4s8LqwJlTmsfzP3zxOfUwC7balHzv5pNaFEjvcVrk5MaQRWlL
 lHTmlmmDrU3xIb7fzfw0
 =ZsWI
 -END PGP SIGNATURE-

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

Re: [tor-bugs] #21138 [Metrics/Onionoo]: add javadoc overview page to Onionoo

2017-09-19 Thread Tor Bug Tracker & Wiki

#21138: add javadoc overview page to Onionoo
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  Onionoo-1.6.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 How much do we care about this overview page? Onionoo's JavaDocs are not
 part of a public API, but just used internally, if at all. I'm not even
 sure whether there's a large enough fraction of public classes/methods in
 Onionoo with JavaDocs to make them useful at all. Are you looking at
 Onionoo's JavaDocs when working on the code? Is this specific issue
 something we should spend much effort on? (Or is it just a 5-minute
 minimal thing you have in mind 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

Re: [tor-bugs] #13709 [Metrics/Website]: Track some Dir Auth network stats

2017-09-19 Thread Tor Bug Tracker & Wiki

#13709: Track some Dir Auth network stats
-+-
 Reporter:  grarpamp |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 I believe that fallback directories introduced a few years ago made the
 bandwidth-for-bootstrapping reason moot.

 And private Tor networks are not something that we care about. It's not
 something we discourage in any way, but it's also not something that we'd
 direct development efforts to specifically.

 Re-closing for various reasons, some stated in this comment and some in
 earlier comments.

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

Re: [tor-bugs] #22265 [Webpages/Website]: write high-level overview of bootstrap process

2017-09-19 Thread Tor Bug Tracker & Wiki

#22265: write high-level overview of bootstrap process
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * status:  new => needs_review


Comment:

 This has been in [[doc/Bootstrap]] for a while but could use some feedback
 on whether it's sufficiently readable by (non-developer?) people not
 familiar with the code.

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

Re: [tor-bugs] #19566 [Core Tor/Tor]: SR: Use BUG() instead of tor_assert() when we can

2017-09-19 Thread Tor Bug Tracker & Wiki

#19566: SR: Use BUG() instead of tor_assert() when we can
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-sr, dirauth, easy, disaster- |  Actual Points:
  waiting-to-happen  |
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by neel):

 I have made an updated patch under the file
 bug_shared_random_patch_r2.patch.

 The changes I have made this file is to use the correct use of the BUG()
 function.

 I switched tor_assert() to BUG() in shared_random.c and
 shared_random_state.c in functions that seem related to SR and who's
 return values are void.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

2017-09-19 Thread Tor Bug Tracker & Wiki

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Just to be sure, this is ready to be merged now, right? (I only looked
 very briefly and would check more thoroughly tomorrow, but maybe there's
 something that happened in the past two weeks that would lead to not
 merging as-is that I might overlook tomorrow?)

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

Re: [tor-bugs] #19566 [Core Tor/Tor]: SR: Use BUG() instead of tor_assert() when we can

2017-09-19 Thread Tor Bug Tracker & Wiki

#19566: SR: Use BUG() instead of tor_assert() when we can
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-sr, dirauth, easy, disaster- |  Actual Points:
  waiting-to-happen  |
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by neel):

 * Attachment "bug_shared_random_patch_r2.patch" added.

 Patch to replace tor_assert() with BUG() in SR code whenever possible
 (Revision 2)

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

2017-09-19 Thread Tor Bug Tracker & Wiki

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 Replying to [comment:53 gk]:
 > What is a violation (or who is violating it)? Do you have a link with
 some more information about that?
 "it doesn't have an underscore" is a violation of
 https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names
 According to unixwiz.net/techtips/win32-callconv.html, it is required for
 direct linking to a third-party dll only. So your way 2) should work, but
 it's better to fix it properly. Given that "Chrome doesn't use the
 SANDBOX_EXPORTS parts of the code, because they use the same EXE for the
 child", we are on terra incognita here for mingw-w64. Please, ask Jacek to
 find out what's going on.

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

Re: [tor-bugs] #23538 [Core Tor/Tor]: Allow KISTSchedRunInterval to be negative

2017-09-19 Thread Tor Bug Tracker & Wiki

#23538: Allow KISTSchedRunInterval to be negative
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by pastly):

 Replying to [comment:5 pastly]:
 > I  think Schedulers should be the way to disable KIST. I don't think we
 should allow KISTSchedRunInterval to be negative anymore. The hard part is
 making consensus params that are strings.
 >

 Actually, let's not open that consensus param can of worms.

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

2017-09-19 Thread Tor Bug Tracker & Wiki

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pastly):

 Tests fine for me on OS X. It does kill the Tor process if I switch to
 `Schedulers KIST` and HUP. Making Schedulers a consensus param would give
 the auths power to kill non-linux relays, so let's not do that. (It would
 require a ton of work anyway, because we can only do int consensus params
 currently).

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

Re: [tor-bugs] #23585 [Applications/Tor Browser]: Build is failing with runc version 1.0.0-rc2

2017-09-19 Thread Tor Bug Tracker & Wiki

#23585: Build is failing with runc version 1.0.0-rc2
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Branch `bug_23585` has a patch that might fix the issue:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23585&id=a48690ea2873d699351929b25c9fd667f31e0890

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

Re: [tor-bugs] #23549 [Metrics/Website]: Move ExoneraTorServlet to metrics-web

2017-09-19 Thread Tor Bug Tracker & Wiki

#23549: Move ExoneraTorServlet to metrics-web
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 With an approach very similar to the one you describe above, do you think
 we could
  1. keep the current front-end functionality in ExoneraTor to enable
 others to run it stand-alone '''and'''
  2. generate a .jar file for metrics-web to use `ExoneraTorServlet` and
 `QueryResponse` there with different header and footer?

 Note that I wouldn't want to keep the existing ExoneraTor front-end
 running on exonerator.tp.o. I'm just thinking whether we need to rip out
 this functionality or could instead leave ExoneraTor intact for those who
 don't happen to run a metrics-web, too. And now that I write this, I
 believe this use case is real, for people who can't use the public
 ExoneraTor, because they can't give out the IP addresses they're looking
 for.

 All the other changes you mention, including using embedded Jetty, sound
 good to me, and I could see us making some of them in the course of making
 this move to metrics-web.

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

Re: [tor-bugs] #23567 [Core Tor/Tor]: prop224 should become an official specification

2017-09-19 Thread Tor Bug Tracker & Wiki

#23567: prop224 should become an official specification
--+
 Reporter:  nickm |  Owner:  dgoulet
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  prop224 tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 Implemented!

 (I re-copied the text of prop224, since it changed a little since
 yesterday. No more changes to prop224 please)

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

Re: [tor-bugs] #22722 [Core Tor/Tor]: tor-spec still says "For a public-key cipher, we use RSA with 1024-bit keys"

2017-09-19 Thread Tor Bug Tracker & Wiki

#22722: tor-spec still says "For a public-key cipher, we use RSA with 1024-bit
keys"
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-spec, spec  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 I took a mostly local approach in 0.3 in
 51f1127c2fea9b34ee32bbf8b56ea2658424b9f2.

 I think we should at some point do a more thorough rewrite of the spec,
 but at least 0.3 is not currently misleading.

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

Re: [tor-bugs] #23538 [Core Tor/Tor]: Allow KISTSchedRunInterval to be negative

2017-09-19 Thread Tor Bug Tracker & Wiki

#23538: Allow KISTSchedRunInterval to be negative
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by pastly):

 I  think Schedulers should be the way to disable KIST. I don't think we
 should allow KISTSchedRunInterval to be negative anymore. The hard part is
 making consensus params that are strings.

 I really dislike more flags like `KISTDisable 0|1`.

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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

2017-09-19 Thread Tor Bug Tracker & Wiki

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:  #23538   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  assigned => needs_information


Comment:

 We'll wait on this decision before we do anything else about this #23538
 but I think we might be leaning towards no negative value at all.

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

2017-09-19 Thread Tor Bug Tracker & Wiki

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 (1) is the one.

 Branch: `bug23581_032_01`

 You'll see the interesting `exit(1)` in there because since the scheduler
 can be changed during runtime at any point, we do have to trigger the
 cleanup ourselves.

 (This will conflicts with #23552 but at least we have a baseline 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] #23583 [Core Tor/Tor]: ext/timeouts/timeout-bitops.c:234: bad shift

2017-09-19 Thread Tor Bug Tracker & Wiki

#23583: ext/timeouts/timeout-bitops.c:234: bad shift
---+---
 Reporter:  dcb314@…   |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  030-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  merge_ready => 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] #23583 [Core Tor/Tor]: ext/timeouts/timeout-bitops.c:234: bad shift

2017-09-19 Thread Tor Bug Tracker & Wiki

#23583: ext/timeouts/timeout-bitops.c:234: bad shift
---+---
 Reporter:  dcb314@…   |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  030-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 > I think I slightly prefer x = (uint64_t)1 << i but not strongly.

 I can never remember whether the order of operations works with that one,
 or whether I need to say `((uint64_t)1)` :)

 Merging.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

2017-09-19 Thread Tor Bug Tracker & Wiki

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

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 We can still take this in 0.3.2, if you turn it into a patch.

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

Re: [tor-bugs] #23583 [Core Tor/Tor]: ext/timeouts/timeout-bitops.c:234: bad shift

2017-09-19 Thread Tor Bug Tracker & Wiki

#23583: ext/timeouts/timeout-bitops.c:234: bad shift
---+---
 Reporter:  dcb314@…   |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  030-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me.  I think I slightly prefer `x = (uint64_t)1 << i` but
 not strongly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23585 [Applications/Tor Browser]: Build is failing with runc version 1.0.0-rc2

2017-09-19 Thread Tor Bug Tracker & Wiki

#23585: Build is failing with runc version 1.0.0-rc2
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201709
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I have been able to do builds with runc 0.1.1 (from Debian jessie
 backports, and from stretch), and runc 1.0.1 from Fedora 25. Matt reported
 on the tbb-dev mailing list that it is not working with version 1.0.0~rc2:
 https://lists.torproject.org/pipermail/tbb-dev/2017-September/000615.html

 It seems version 1.0.0~rc2 is half between version 0.1.1 and 1.0.0.

 It was released after this commit, so it uses the same commands as 1.0.0:
 
https://github.com/opencontainers/runc/commit/c669b8d1568633c68bd915561ceb2e5ecc1bfc6a

 However it seems to expect a config.json file in the same format as 0.1.1.

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

Re: [tor-bugs] #23584 [Core Tor/Tor]: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?

2017-09-19 Thread Tor Bug Tracker & Wiki

#23584: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?
--+
 Reporter:  dcb314@…  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  030-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * 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] #23584 [- Select a component]: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?

2017-09-19 Thread Tor Bug Tracker & Wiki

#23584: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?
--+
 Reporter:  dcb314@…  |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  030-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Actually, looks like this is a duplicate of bug #23055.  Not planning to
 backport this one to 0.3.1 or earlier, since it won't trigger until people
 make certs that expire in Y2106 or later -- at which point probably nobody
 will be running Tor 0.3.1 or earlier.

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

Re: [tor-bugs] #23583 [Core Tor/Tor]: ext/timeouts/timeout-bitops.c:234: bad shift

2017-09-19 Thread Tor Bug Tracker & Wiki

#23583: ext/timeouts/timeout-bitops.c:234: bad shift
---+---
 Reporter:  dcb314@…   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  030-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  accepted => needs_review
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Fix in branch `bug23583_029` in my public repository.  I suggest no
 backport, since this code is not actually compiled into Tor -- it's
 conditional on the timeout.c bitops tests being run.

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

Re: [tor-bugs] #20895 [Core Tor/Tor]: Split node_supports_ed25519_link_authentication into two or three separate functions

2017-09-19 Thread Tor Bug Tracker & Wiki

#20895: Split node_supports_ed25519_link_authentication into two or three 
separate
functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:  #15054| Points:  2
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by nickm):

 So, my rationale is that if we want to know "does this support 3", then
 we'll be looking at `protocol_list_supports_protocol`.  That already
 exists.

 I'm not claiming that if a relay supports 4 it must support 3: I'm
 claiming that if it supports 4, it is okay to include an ed25519 key in
 its link specifiers.

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

Re: [tor-bugs] #22891 [Core Tor/Tor]: Add GitLab CI configs

2017-09-19 Thread Tor Bug Tracker & Wiki

#22891: Add GitLab CI configs
-+-
 Reporter:  catalyst |  Owner:  hiro
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ci, continuous-integration,  |  implemented
  testing, best-practice, unit-testing, new- |  Actual Points:
  developers, review-group-22, review-group-23   |
Parent ID:   | Points:
 Reviewer:  ahf, dgoulet |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 merged to master!

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

Re: [tor-bugs] #23584 [- Select a component]: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?

2017-09-19 Thread Tor Bug Tracker & Wiki

#23584: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?
--+
 Reporter:  dcb314@…  |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:  030-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => accepted
 * owner:  (none) => nickm
 * keywords:   => 030-backport
 * milestone:   => Tor: 0.3.1.x-final


Comment:

 long is not guaranteed to be 64-bit, though.

 What checker are you using 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

Re: [tor-bugs] #23583 [Core Tor/Tor]: ext/timeouts/timeout-bitops.c:234: bad shift

2017-09-19 Thread Tor Bug Tracker & Wiki

#23583: ext/timeouts/timeout-bitops.c:234: bad shift
---+---
 Reporter:  dcb314@…   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  030-backport 029-backport  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted
 * component:  - Select a component => Core Tor/Tor
 * keywords:   => 030-backport 029-backport
 * milestone:   => Tor: 0.3.1.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] #21405 [Core Tor/Tor]: Clarify "address" in man page: IPv4, IPv6, hostname?

2017-09-19 Thread Tor Bug Tracker & Wiki

#21405: Clarify "address" in man page: IPv4, IPv6, hostname?
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Low |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:  implemented
 Keywords:  tor-doc easy intro manpage  |  Actual Points:
Parent ID:  #18892  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

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


Comment:

 ok; merged!

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

Re: [tor-bugs] #21405 [Core Tor/Tor]: Clarify "address" in man page: IPv4, IPv6, hostname?

2017-09-19 Thread Tor Bug Tracker & Wiki

#21405: Clarify "address" in man page: IPv4, IPv6, hostname?
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Low |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  tor-doc easy intro manpage  |  Actual Points:
Parent ID:  #18892  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 Oh yes! Good stuff.

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

Re: [tor-bugs] #21405 [Core Tor/Tor]: Clarify "address" in man page: IPv4, IPv6, hostname?

2017-09-19 Thread Tor Bug Tracker & Wiki

#21405: Clarify "address" in man page: IPv4, IPv6, hostname?
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  needs_revision
 Priority:  Low |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  tor-doc easy intro manpage  |  Actual Points:
Parent ID:  #18892  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 I think they all document that they're in the same format as ExitPolicy?
 Also ReachableDirAddresses is deprecated.

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

Re: [tor-bugs] #21405 [Core Tor/Tor]: Clarify "address" in man page: IPv4, IPv6, hostname?

2017-09-19 Thread Tor Bug Tracker & Wiki

#21405: Clarify "address" in man page: IPv4, IPv6, hostname?
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  needs_revision
 Priority:  Low |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  tor-doc easy intro manpage  |  Actual Points:
Parent ID:  #18892  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by dgoulet):

 Hmmm I don't see anything for `ReachableAddresses`,
 `ReachableDirAddresses` and `ReachableORAddresses`?

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

Re: [tor-bugs] #21405 [Core Tor/Tor]: Clarify "address" in man page: IPv4, IPv6, hostname?

2017-09-19 Thread Tor Bug Tracker & Wiki

#21405: Clarify "address" in man page: IPv4, IPv6, hostname?
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  needs_revision
 Priority:  Low |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  tor-doc easy intro manpage  |  Actual Points:
Parent ID:  #18892  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 I've thrown some boilerplate around whenever we say `__IP__`.  Better 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] #18891 [Core Tor/Tor]: Make it clear that Address only works for IPv4

2017-09-19 Thread Tor Bug Tracker & Wiki

#18891: Make it clear that Address only works for IPv4
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  easy, doc, docs  |  Actual Points:
Parent ID:  #18892   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Thank you! Amended and merged.

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

Re: [tor-bugs] #19566 [Core Tor/Tor]: SR: Use BUG() instead of tor_assert() when we can

2017-09-19 Thread Tor Bug Tracker & Wiki

#19566: SR: Use BUG() instead of tor_assert() when we can
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-sr, dirauth, easy, disaster- |  Actual Points:
  waiting-to-happen  |
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by neel):

 * cc: neel@… (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] #18736 [Core Tor/Tor]: [Manual] Add some information about sub-domain rules

2017-09-19 Thread Tor Bug Tracker & Wiki

#18736: [Manual] Add some information about sub-domain rules
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  easy, docs|  Actual Points:
Parent ID:| Points:  0
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

2017-09-19 Thread Tor Bug Tracker & Wiki

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I think that (1) is fine with me; if the user said "KIST or nothing",
 let's respect their wishes.

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

Re: [tor-bugs] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

2017-09-19 Thread Tor Bug Tracker & Wiki

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pastly):

 If we've made it to runtime, we must have a `the_scheduler`. Tor shouldn't
 just stop.

 I don't like (2) because I don't like fallback strategies that violate the
 Schedulers torrc option. We already do this in one place now[0], and I
 think that one place is a necessary evil.

 What if we implicitly add "Vanilla" to the end of any Schedulers torrc
 option that doesn't already have "Vanilla" in it somewhere? Then we'd
 always have a lowest common denominator and guaranteed-to-run-on-your-
 system option to fallback to if worst comes to worst.

 [0] KIST is working as usual, then boom support in the kernel drops out
 from under us. We log a notice about the sudden issue, but continue to
 call ourselves "KIST" (not "KISTLite"). We can do this fallback even if we
 don't have KISTLite in Schedulers

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

Re: [tor-bugs] #23538 [Core Tor/Tor]: Allow KISTSchedRunInterval to be negative

2017-09-19 Thread Tor Bug Tracker & Wiki

#23538: Allow KISTSchedRunInterval to be negative
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Replying to [comment:2 pastly]:
 > Maybe ... just maybe ... using a negative run interval is obsolete logic
 and the Schedulers option should be the way to disable KIST :) That might
 be simpler.

 Yes... I do think 0 should be "use consensus value" else use torrc. And
 not magically "disable KIST" with -1.

 Then. for the scheduler type, it should be `Schedulers` that is used in
 the consensus but for that we need tor to be able to parse consensus param
 as resulting string values. We will also require some sort of value that
 tells tor to look in the consensus by default and fallback to defaults.
 Like: `Schedulers auto` would be the default value in tor and it basically
 does the above (consensus then default list).

 Or we go with an explicit option that is `KISTDisable 0|1` but then what
 to do with `KISTLite` ... ? I'm not a big fan of 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] #23581 [Core Tor/Tor]: Die more helpfully if Schedulers option isn't compatible with platform

2017-09-19 Thread Tor Bug Tracker & Wiki

#23581: Die more helpfully if Schedulers option isn't compatible with platform
--+
 Reporter:  pastly|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 I see two possible behaviors to solve this:

 1. We exit(1) if `select_scheduler()` can't set a scheduler. So in this
 case, you tried to put KIST only on a platform that doesn't support it, we
 stop and ask you to fix your torrc.

 2. We fallback to some default (`KISTLite` for instance) and warn the
 user.

 The approach in (1) has a bad side effect of if at runtime the new type is
 not usable well tor will just stop... As for (2), it is very possible the
 user just don't notice the fallback and end up with a tor scheduler it
 didn't want (not sure that's really a big issue...)

 For now, I'm for (2) ? Objections?

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

Re: [tor-bugs] #23305 [Core Tor/Tor]: hs: Maybe don't use REND_DESC_ID_V2_LEN_BASE32 as the length for a base32 relay digest id

2017-09-19 Thread Tor Bug Tracker & Wiki

#23305: hs: Maybe don't use REND_DESC_ID_V2_LEN_BASE32 as the length for a 
base32
relay digest id
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, easy, refactor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 Branch `ticket23305_032_01`

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

Re: [tor-bugs] #21405 [Core Tor/Tor]: Clarify "address" in man page: IPv4, IPv6, hostname?

2017-09-19 Thread Tor Bug Tracker & Wiki

#21405: Clarify "address" in man page: IPv4, IPv6, hostname?
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  needs_revision
 Priority:  Low |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  tor-doc easy intro manpage  |  Actual Points:
Parent ID:  #18892  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 In the case of `__IP__`, I don't see any mentions of what is the expected
 format? I'm asking because for v4 it is easy but seems that for v6 we do
 require `[]` from what I can see in the code in terms of parsing.

 It's kind of obvious the brackets are needed for IPv6 because you can put
 a port with `:PORT` but could we make a quick note maybe at the start of
 the man page that every IPv6 address needs the brackets?

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

Re: [tor-bugs] #19760 [Core Tor/Tor]: Update longclaw's hard-coded IPv6 address

2017-09-19 Thread Tor Bug Tracker & Wiki

#19760: Update longclaw's hard-coded IPv6 address
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  dir-auth, ipv6, 029-proposed  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:  SponsorZ
--+
Changes (by micah):

 * owner:  micah => (none)


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

Re: [tor-bugs] #19760 [Core Tor/Tor]: Update longclaw's hard-coded IPv6 address

2017-09-19 Thread Tor Bug Tracker & Wiki

#19760: Update longclaw's hard-coded IPv6 address
--+
 Reporter:  teor  |  Owner:  micah
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  dir-auth, ipv6, 029-proposed  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:  SponsorZ
--+

Comment (by micah):

 I think that the IPv6 address for longclaw should be removed in the source
 code. It was only a temporary address that I setup on teor's request for
 testing and never was meant to be something that stuck. Additionally,
 longclaw will be moving to a new location, so its ipv6 address will go
 away then (I'm unsure when it will get a new one), as well as its ipv4
 address.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23584 [- Select a component]: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?

2017-09-19 Thread Tor Bug Tracker & Wiki

#23584: tor-0.3.1.7/src/or/torcert.c:396: bad expression ?
--+
 Reporter:  dcb314@…  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 tor-0.3.1.7/src/or/torcert.c:396]: (style) int result is assigned to long
 variable.

 Source code is

   const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
   const uint64_t expiration_time = expiration_date * 3600;

 Multiplying something by 3600 doesn't change its type. Suggest new code

   const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
   const uint64_t expiration_time = expiration_date * 3600UL;

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

Re: [tor-bugs] #23569 [Internal Services/Tor Sysadmin Team]: Please create email alias for Richard

2017-09-19 Thread Tor Bug Tracker & Wiki

#23569: Please create email alias for Richard
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ewyatt):

 FWIW, Richard was here in the office yesterday when he made this key. I
 have signed it and uploaded it to the server. Can we get his email
 forwarding set up now and deal with LDAP when we have the answers we need?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23583 [- Select a component]: ext/timeouts/timeout-bitops.c:234: bad shift

2017-09-19 Thread Tor Bug Tracker & Wiki

#23583: ext/timeouts/timeout-bitops.c:234: bad shift
--+
 Reporter:  dcb314@…  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 tor-0.3.1.7/src/ext/timeouts/timeout-bitops.c:234]: (error) Shifting
 31-bit value by 63 bits is undefined behaviour

 Source code is

 for (i = 0; i <= 63; ++i) {
 uint64_t x = 1 << i;

 If you are going to shift something by 60+ bits reliably,
 you need 1UL, not 1.

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

Re: [tor-bugs] #20895 [Core Tor/Tor]: Split node_supports_ed25519_link_authentication into two or three separate functions

2017-09-19 Thread Tor Bug Tracker & Wiki

#20895: Split node_supports_ed25519_link_authentication into two or three 
separate
functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:  #15054| Points:  2
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => dgoulet


Comment:

 I'm not sure I fully understand here the use of
 `protocol_list_supports_protocol_or_later()` which goes like this:

 {{{
 +  if (range->high >= version) {
 +contains = 1;
 +goto found;
 }}}

 So let's say I have a relay with `LinkAuth 2,4` which deliberately not
 list "3", this "or later" function will return true for `return
 protocol_list_supports_protocol_or_later(protos, PRT_LINKAUTH, 3);` but it
 should really not actually say that it supports LinkAuth 3

 Can we really imply that if a relay supports 4 then it has to support 3 ?
 What if we disabled it or made it obsolete or consensus put if off?

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

Re: [tor-bugs] #22690 [Core Tor/Tor]: SR: Authorities can add a reveal to their own vote, but expect a commit in all votes

2017-09-19 Thread Tor Bug Tracker & Wiki

#22690: SR: Authorities can add a reveal to their own vote, but expect a commit 
in
all votes
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-sr|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 No news in a while and nobody hitting this on chutney now, closing. But
 let's re-open if this re-appears.

 The entire SR phases and duration are based on the valid_after consensus
 time so it can happen in theory with a bad block or out of sync consensus
 between 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

1 2 >

1 - 100 of 193 matches

Mail list logo