Re: [tor-bugs] #24978 [Core Tor/Tor]: Tor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with enable-tls1_3

[Tor Bug Tracker & Wiki]

#24978: Tor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with
enable-tls1_3
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 031-backport|  Actual Points:
  032-backport openssl   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 See `bug24978_029_enable` and `bug24978_029_disable` for our options.  We
 should merge only one IMO.

 I'd argue against a backport to 0.2.5, since 0.2.5 is EOL in May, and
 since it won't build with OpenSSL 1.1.1 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] #10888 [Applications/Tor Browser]: Mozilla trademarks still remain in some about: urls

[Tor Bug Tracker & Wiki]

#10888: Mozilla trademarks still remain in some about: urls
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-branding, tbb-firefox-patch  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by mcs):

 I closed #24578 as a duplicate.

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

[tor-bugs] #24976 [- Select a component]: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion !(cache_entry->desc->plaintext_data.revision_counter > client_desc->desc->plaintext_dat

[Tor Bug Tracker & Wiki]

#24976: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion
!(cache_entry->desc->plaintext_data.revision_counter >
client_desc->desc->plaintext_data.revision_counter) failed
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  tor-hs prop224
Actual Points:|  Parent ID:
   Points:  0.4   |   Reviewer:
  Sponsor:|
--+
 Got the following non-fatal assert in my hsv3 IRC client some weeks ago.
 The tor version is pretty old, but I don't think we changed anything in
 the between to fix this issue.

 {{{
 Dec 13 16:58:04.000 [warn] tor_bug_occurred_(): Bug:
 src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion
 !(cache_entry->desc->plaintext_data.revision_counter >
 client_desc->desc->plaintext_data.revision_counter) failed. (on Tor
 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: Non-fatal assertion
 !(cache_entry->desc->plaintext_data.revision_counter >
 client_desc->desc->plaintext_data.revision_counter) failed in
 cache_store_as_client at src/or/hs_cache.c:628. Stack trace: (on Tor
 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: ./tor/src/or/tor(log_backtrace+0x42)
 [0x7fe385e0b442] (on Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug:
 ./tor/src/or/tor(tor_bug_occurred_+0xb7) [0x7fe385e262c7] (on Tor 0.3.2.1
 -alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug:
 ./tor/src/or/tor(hs_cache_store_as_client+0x1c2) [0x7fe385de4fc2] (on Tor
 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug:
 ./tor/src/or/tor(connection_dir_reached_eof+0x1a67) [0x7fe385dbb757] (on
 Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: ./tor/src/or/tor(+0x1067cf)
 [0x7fe385d927cf] (on Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: ./tor/src/or/tor(+0x4dcf1)
 [0x7fe385cd9cf1] (on Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7fe38530f3dc] (on Tor
 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: ./tor/src/or/tor(do_main_loop+0x244)
 [0x7fe385cdad84] (on Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: ./tor/src/or/tor(tor_main+0x1c25)
 [0x7fe385cde5c5] (on Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: ./tor/src/or/tor(main+0x19)
 [0x7fe385cd64d9] (on Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7fe3845022b1] (on Tor 0.3.2.1
 -alpha-dev f71ff0cabc36b5ae)
 Dec 13 16:58:04.000 [warn] Bug: ./tor/src/or/tor(_start+0x2a)
 [0x7fe385cd652a] (on Tor 0.3.2.1-alpha-dev f71ff0cabc36b5ae)
 }}}

 Looking at the code, it seems to me that this BUG() could also be caused
 by some sort of HSDir-desynch, where some HSDirs have a newer desc than
 others? Perhaps we could look into this (altho it might be caused
 naturally with network issues), or just remove the BUG from that if
 statement, since it's handled pretty well?

 Not a serious bug all in 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] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  1
 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] #24976 [Core Tor/Tor]: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion !(cache_entry->desc->plaintext_data.revision_counter > client_desc->desc->plaintext_data.re

[Tor Bug Tracker & Wiki]

#24976: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion
!(cache_entry->desc->plaintext_data.revision_counter >
client_desc->desc->plaintext_data.revision_counter) failed
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  0.4
 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] #24275 [Webpages/Website]: Testing Lecktor as a possible framework to be used for all portals related to website redesign project

[Tor Bug Tracker & Wiki]

#24275: Testing Lecktor as a possible framework to be used for all portals 
related
to website redesign project
--+--
 Reporter:  isabela   |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #21222| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > to be used for all portals
 > - easy for folks to update content

 Specifically concerning the FAQ, Trac wiki, proposed knowledge base, or a
 merger of them, the documentation websites for other software projects
 that I consider the easiest to update are '''wikis'''. Wikis are
 particularly easy for communities of projects with extensive websites and
 sub-projects to contribute quickly and broadly toward updating their
 documentation content even if the administration teams are small in
 comparison or preoccupied.

 A framework like Lecktor will aid in redesigning the theme, style, and
 underlying construction of the website which appears to be the goal of the
 website redesign project, but I don't think it would aid lesser-skilled
 folks who might wish to contribute by keeping the textual documentation
 updated. Git, local servers, and workspace interfaces pile steep learning
 curves onto simply updating a sentence or two.

 > Here is the git repository: ​https://oniongit.eu/infra/portal
 Why not on https://gitweb.torproject.org/? It's also accessible on hidden
 services administrated by TorProject ( https://onion.torproject.org/ )
 which means that Tor users skeptical of exit nodes, third-party hosts, or
 certificate authorities would have a pathway to contribute with less
 reluctance. An alternate but less reassuring (and harder for you) option
 could be maintaining a hidden service on oniongit.eu.

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

Re: [tor-bugs] #16886 [Applications/Tor Browser]: "Add-on compatibility check dialog" contains Firefox logo

[Tor Bug Tracker & Wiki]

#16886: "Add-on compatibility check dialog" contains Firefox logo
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-branding  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 In Firefox <= 57, there is still a branded dialog that is shown after the
 post-update restart (which is why we still see it in Tor Browser after
 each update). But in Firefox 57 and newer that old XUL-based dialog has
 been replaced with a simpler HTML-based window, as shown here:
 https://bug1353194.bmoattachments.org/attachment.cgi?id=8905214

 Here is the bug where the work was done:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1353194

 We should take another look at this in the ESR 60 timeframe to see if
 there are any branding issues with the new window (text or images).

 In the meantime, we can fix this problem by putting a Tor Browser icon in
 browser/branding/official/content/icon48.png (see ticket:10888#comment:8).

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

Re: [tor-bugs] #24965 [Applications/Tor Browser]: Automatically remove metadata from images (EXIF) before upload

[Tor Bug Tracker & Wiki]

#24965: Automatically remove metadata from images (EXIF) before upload
---+--
 Reporter:  arthuredelstein|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting, gsoc-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 This seems like a good idea and something Firefox and other browsers
 should have as well. I did find this:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1067211

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

Re: [tor-bugs] #24881 [Webpages/Website]: consolidate relay setup instruction pages and link to new guide

[Tor Bug Tracker & Wiki]

#24881: consolidate relay setup instruction pages and link to new guide
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Silvia [Hiro]:
 > Yes,
 > It is checked for compiling some parts of the docs. That's why the
 > building was failing.

 Oh sorry, I did test my changes by building locally and it did build just
 fine.

 That was probably caused by "Fix merge conflicts in sidenav"
 
https://gitweb.torproject.org/project/web/webwml.git/commit/?id=c257c6ccac167d74206771f13d63e04335272661

 since it added back the sidenav entry for docs/rpm.

 I removed docs/rpm and the sidenav entry in this branch:
 https://github.com/nusenu/torproject-webwml/tree/remove_rpms_from_sidenav

 would be great if you could merge it since that content is obsolete.

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

Re: [tor-bugs] #24978 [Core Tor/Tor]: Tor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with enable-tls1_3

[Tor Bug Tracker & Wiki]

#24978: Tor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with
enable-tls1_3
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 031-backport|  Actual Points:
  032-backport openssl   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 (If you go to test these out with openssl git master, expect a bunch of
 warnings. I have a PR for that in openssl:
 https://github.com/openssl/openssl/pull/5150 .)

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

Re: [tor-bugs] #24965 [Applications/Tor Browser]: Automatically remove metadata from images (EXIF) before upload

[Tor Bug Tracker & Wiki]

#24965: Automatically remove metadata from images (EXIF) before upload
---+--
 Reporter:  arthuredelstein|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting, gsoc-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by sysrqb):

 Replying to [comment:2 mcs]:
 > This seems like a good idea and something Firefox and other browsers
 should have as well. I did find this:
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1067211

 Oh, nice. That's surprisingly appropriate. We can also look at MAT as an
 example, as well as the alternatives.

 https://mat.boum.org/

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

Re: [tor-bugs] #24967 [Core Tor/Torsocks]: torsocks fails to check SIP if the path itself is a symlink

[Tor Bug Tracker & Wiki]

#24967: torsocks fails to check SIP if the path itself is a symlink
---+--
 Reporter:  Hello71|  Owner:  Hello71
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by Hello71):

 * status:  new => assigned
 * owner:  dgoulet => Hello71


Comment:

 
https://cgit.alxu.ca/torsocks.git/commit/?id=db954ddbce29b12baeb1197fbb4ff09471d91133

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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-29   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * status:  new => needs_review
 * cc: catalyst (added)


Comment:

 clang complained about some missing `static` keywords: https://travis-
 ci.org/tlyu/tor/jobs/332496284
 Patch in the static-version-str branch in my GitHub repository.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24985 [Core Tor/Tor]: Preserve circuit-layer confidentiality against a quantum-capable adversary

[Tor Bug Tracker & Wiki]

#24985: Preserve circuit-layer confidentiality against a quantum-capable 
adversary
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  post-quantum, cryptography, tor-
 Severity:  Normal   |  circuit
Actual Points:   |  Parent ID:
   Points:  9001 |   Reviewer:
  Sponsor:   |
  Sponsor3   |
-+-
 [https://eprint.iacr.org/2015/008 Many] [https://eprint.iacr.org/2015/287
 researchers], ourselves included, have been aiming
 [https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-
 create-cells.txt for]
 [https://gitweb.torproject.org/torspec.git/tree/proposals/263-ntru-for-pq-
 handshake.txt quite]
 [https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-
 handshake.txt some]
 [https://gitweb.torproject.org/torspec.git/tree/proposals/270-newhope-
 hybrid-handshake.txt time] to protect Tor traffic against a hypothetical
 future adversary who has access to a quantum computer capable of breaking
 ECDH key exchanges which have occurred in the past and been recorded.

 This is the parent ticket for organising the work into smaller, byte-sized
 chunks and tracking overall progress.

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

[tor-bugs] #24990 [Core Tor/Tor]: Write a proposal for a post-quantum lattice KEX

[Tor Bug Tracker & Wiki]

#24990: Write a proposal for a post-quantum lattice KEX
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core  |Version:
  Tor/Tor |
 Severity:  Normal|   Keywords:  proposal cryptography post-quantum
Actual Points:|  Parent ID:  #24985
   Points:|   Reviewer:
  Sponsor:  Sponsor3  |
--+
 As part of #24985, we'll need a solid, reviewed proposal for which post-
 quantum key exchange we intend concretely to use.

 My current idea for the key exchange is to use q=12289 and n=1024 (the
 lattice parameters from [https://eprint.iacr.org/2015/1092 NewHope] and
 other designs), along with the constant-time sampling protections I
 devised while working on
 [https://gitweb.torproject.org/torspec.git/tree/proposals/270-newhope-
 hybrid-handshake.txt prop#270], ripping out the Voronoi-cell based
 reconciliation mechanism and instead using a variant of the XE5
 reconciliation from the NIST [https://mjos.fi/hila5/ HILA5] submission
 (possibly tuning down the failure probability by increasing the noise,
 which raises the security level, since our key exchange is interactive and
 thus we don't care about having the 2^-128^ failure probability which
 allows HILA5 to be used for public key encryption schemes).

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

Re: [tor-bugs] #24148 [Community/Outreach]: Start a program where developers can call out volunteers for swag and glory

[Tor Bug Tracker & Wiki]

#24148: Start a program where developers can call out volunteers for swag and 
glory
+
 Reporter:  arma|  Owner:  alison
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by mcs):

 * cc: mcs (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] #24986 [Core Tor/Tor]: Implement prop#249 "Large Create Cells"

[Tor Bug Tracker & Wiki]

#24986: Implement prop#249 "Large Create Cells"
--+--
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-cell tor-circuit trunnel
Actual Points:|  Parent ID:  #24985
   Points:  8 |   Reviewer:
  Sponsor:  Sponsor3  |
--+--
 As part of #24985, we'll need to implement
 [https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-
 create-cells.txt prop#249]'s design for large create cells.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24987 [Core Tor/Tor]: Implement prop#269 "Hybrid Handshakes" (composition module)

[Tor Bug Tracker & Wiki]

#24987: Implement prop#269 "Hybrid Handshakes" (composition module)
-+-
 Reporter:  isis |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  post-quantum, cryptography, tor-
 Severity:  Normal   |  circuit, handshakes
Actual Points:   |  Parent ID:  #24985
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor3   |
-+-
 As part of #24985, we'll need to implement
 [https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-
 handshake.txt prop#269]. This should probably be in two parts:

  1) Implement a new module which, given function pointers to two
 handshakes (one classic and the other post-quantum secure) which follow
 some prescribed API, compose the handshakes together to produce a final
 shared secret
  2) Implement "hybrid null" (as it's called in the proposal), which here
 I'm calling "ntor2"

 This ticket is about part 1.  It depends upon #24986 as well.

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

Re: [tor-bugs] #24946 [Core Tor/Tor]: connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed

[Tor Bug Tracker & Wiki]

#24946: connection_ap_expire_beginning(): Bug: circuit->purpose ==
CIRCUIT_PURPOSE_C_GENERAL failed
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 Replying to [comment:5 asn]:
 > Mike's fix LGTM too.
 >
 > Mike any chance we should also be checking for `HS_VANGUARD`
 `circ->purpose` in `connection_ap_expire_beginning()` too?

 No, this check is only for circuits that can have attempted streams
 attached. HS_VANGAURD should never have any streams.

 > WRT mike's question on comment:2: I don't think we have inherent rate-
 limiting for hsdir queries on hsv2 or hsv3, but I don't expect Tor clients
 to make many such circuits. Perhaps we should merge the bug fix patch we
 already have, and maybe open a separate ticket about investigating the
 potential issue of `count_pending_general_client_circuits()`?

 Ok. #24989.

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

Re: [tor-bugs] #24989 [Core Tor/Tor]: Count hsdir requests against maxcircuitspending

[Tor Bug Tracker & Wiki]

#24989: Count hsdir requests against maxcircuitspending
--+--
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mikeperry):

 * status:  assigned => needs_review


Comment:

 https://oniongit.eu/mikeperry/tor/commits/bug24989. Note that I only added
 the client-side hsdir fetch purpose to this check. I figure dealing with
 the service side holistically in #24973 is the right way to deal with the
 service rate limiting.

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
-+--
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  singleonion, guards  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by alecmuffett):

 Followup is #24992

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

Re: [tor-bugs] #20218 [Core Tor/Tor]: Fix and refactor and redocument routerstatus_has_changed

[Tor Bug Tracker & Wiki]

#20218: Fix and refactor and redocument routerstatus_has_changed
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, tor-control, easy, |  Actual Points:
  spec-conformance   |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Yes, this field is the right field.

 Here's how to do this patch:
 1. Create a new function that just checks this field
 2. Find all calls to router_has_changed() in control.c and from controller
 helper functions
 3. Replace them with a call to this new function

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

Re: [tor-bugs] #20218 [Core Tor/Tor]: Fix and refactor and redocument routerstatus_has_changed

[Tor Bug Tracker & Wiki]

#20218: Fix and refactor and redocument routerstatus_has_changed
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, tor-control, easy, |  Actual Points:
  spec-conformance   |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 But that check isn't the right check: you only want newer descriptors.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24988 [Core Tor/Tor]: Implement prop#269 "Hybrid Handshakes" (ntor2 module)

[Tor Bug Tracker & Wiki]

#24988: Implement prop#269 "Hybrid Handshakes" (ntor2 module)
-+-
 Reporter:  isis |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  ntor handshakes tor-circuit
 Severity:  Normal   |  cryptography
Actual Points:   |  Parent ID:  #24985
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor3   |
-+-
 As part of #24985, we'll need to implement ​prop#269. This should probably
 be in two parts:

 1) Implement a new module which, given function pointers to two
 handshakes (one classic and the other post-quantum secure) which follow
 some prescribed API, compose the handshakes together to produce a final
 shared secret
 2) Implement "hybrid null" (as it's called in the proposal), which
 here I'm calling "ntor2"

 This ticket is about part 2. It ultimately depends upon #24986 and #24987
 as well, although it can be done (and even rolled out into production, if
 we chose to do so) before either are finished.

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
-+--
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  singleonion, guards  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by alecmuffett):

 * Attachment "tor.conf" added.

 config

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
-+--
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  singleonion, guards  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by alecmuffett):

 * Attachment "tor.log" added.

 log

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

Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by isis):

 This is issue is fixed in my `fix/24432` branch. The final remaining thing
 causing the "501 missing resources" error was just a bug in the where the
 resources were registered on the Python server versus where the Apache
 server was redirecting to.

 Running the steps above in comment:4 to run the `./scripts/externalize-pt-
 client` script along with `TEST_PRODUCTION_MOAT=1 ./scripts/test-moat`
 script, produces this request:

 {{{
 curl --proxy socks4a://127.0.0.1:1/ -H 'Content-Type:
 application/vnd.api+json' -H 'Accept: application/vnd.api+json' -H 'X
 -Forwarded-For: 1.2.3.4' --data '{"data": [{"supported": ["obfs4"],
 "version": "0.1.0", "type": "client-transports"}]}'
 https://bridges.torproject.org:443/moat/fetch
 }}}

 And the current production server returns the following response:

 {{{
 {"data": [{"challenge":
 "xNAyrt4W7BufeLIWYoRqc4NY1j5Y7XcSPur3nZjjExySWarl0kp3Q-
 
LoFXnCD6net56nvT1FrvyHAGb6ST1-f6KycgMJ4y01nGOKfkCJBqh_PJXajrSh8ruAaXBGwOXOEXnIm3CGLGZXm3pJlaYmynqvo6UVkkRXAi_15AZXQVmll7TMJ_UCpUJmh8QEkVVEjqYRbCJ83V5LRXblQEHR0otDw2FJDjgGHE3
 -0XXl1Gsv5vGq_IJ8LpIrJSQEEGljRWj_dZlHbwdWcQFrFcAD-
 
XMKBh8uHLpPB4ki0eEj9723I1UOFg2TOXxjXiG2kmb6EnsimPDYZMgI2AgSfYTuBUunJOjI4Q8PFEEUHYZ-
 BG2ECCda", "id": 1, "version": "0.1.0", "type": "moat-challenge", "image":
 
"/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAB9AZADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+mzV/Hknw4+Id7dfELw9LP4I+EzaPJ4y8T+OoY9L1PxTrWoX2sJ/a/guy1SO7fUPCNlJplre2mi2Gq3+ua1rv2G62PeW11daj2Hgi9+IV74hPi3wn8HfBmofCvxTcvrt94O1jUXv76y0LU4F0+y1G017Vnm8P20l3oPhq
 
G+Xw34auLiy06NtHs5bEWuoSa1bYenw6P4lj1WXQLTxj491nwpr+j2vhDwz411rX9UtNOvi9lrmrfETw/wDEu0tdX16bwhNockWk+HxrB0DSddg07Ura7ab+17meT6D8P6j4H8Xav/wkngu+0241fTPE/h1tdl0O7U6rq32bwjdPa+ILnTbvw4dOs9W1/wAPsmjW2oadb6aNQ08pa2+vSRQ2yqAcPr+sDSfiz8UPD3gd9E8EWfwx+FmgWdlJpj+L7q38HnWGvLvSLC08G20mmeHZje3MGm34m0MXn2y30m90i8QLKsi+E/DnQtA/aB8CWer6r4bji13SviLZaPf3EPiO9sPEfhzwzL8RdP8Aib4G8RaJ4fI1DxPaXHiO/ufCcnjyDWL/AMLanqkNkL+SWWO206eTQ+I3xD8Q+MPFfj74Zw+H9X0z4ieLtc0Ow0y28W2F9rXgS18PX2uNZ+IZfEur6GvhzR7fxDH4Ok0uKTw7ea39o0/Rb7TtQ0W81PVdQuYp+yXxr8M/hr8O/iv8S/DPiDwBqXjT4beN1vfjPN4PtfF3ijw78O9W8N+DNMeXS/GulxX8+o395YaRDo82p6mkOmLbCK18QapZINGuWQA2/F99pfw7m8PeK9QtfDMGqa54g1D4a6JNY+HX8U6z4i8Vatpfh2800+Ira6v9N1OybSrTwbImoWMuqyXphstFM+r3gtZHaTQ9f+ImpeCL7Q9H0i+X4caFH4TuU8eLqNjpN8EuvDeqahe+EvAMlh4huLBrnRr+38P+H7HUotZuNDuDrdzYXQ1G5s9QmuPwe8Vf8HGnwm+OXxYg8AfBXwrc+A/hOfFGkW6/tDfEnQLbSPAVxNqt/ZaZqFn4CmubHUg3xG8eJr2pN4di1Cz1DULrQ9Mm1LTtDvrTU45pP2E/ZF/aJ8DftHfAz4e+M/h1qfhnw98F75fEj6fpvh/U/Fuj2er6PoGg6r4e8TeGNQTxRovhafwj438FytZy3
 
+k3sUds9/p+p3oVLmGSW0APEvgh4+1vxV4o8a+O9MC+IfBfiaS613wH4F17RvDXj/X/AIff8LN025t/7P8ACtx4dNysuoa7r/hqXVrzRbrV/DWm+H9Fku9T16SaaQvae7+G/j/o2jeD/BHhDVPDvxW+H/hnWr+58JR6/o3w91nw3odvZ6xZ6tocGt6lqmn339s6HqHjHxfexahaajHBMt9qD2EWmG/MP9sSewQt4I/ZL+G3gKDQLnSH+Hnhy08X2McegzeHLrUdcvLfwte+JvCWq+Kbux07S5XS00C2unm/sy0vLvzr6yvbm5ktEuryTF+GF78Of2oPhR4C+MXgX4mfFPSND020t/EF1a+L9KsbTQ9dfw3PZazFba5aeLNG1PRrC50/XW00abrilr9IdMebRL94S9ywB5Ro2r6ddeJPCOoxfFTxlqfh/ULLxl4MvvDkiJ4ZbSrHxFsh8H+ITqeiQXGs+I7jV4vF2kTtBqPjm21DUX1mw1+9jgvNLma2+odG+EtxZfDLwpoOn+JtMh0R7i+1zV9Vj8Hadr1p448Iy2lzZ6BoWn6DDNDq+n+JdI0rTvD2oPdaVp6QS3ulNPLb3LyzAcNY+F/A3j7XvilpOrX2keH/ABndeMrL/hK76x07TbHX7Twl4R0G0l0PXNMXVdR1iynabUbCPU9P13Q7bUUYWdvpN/DZ3thLFZdn4NuvFt74317xct1pOufDPS4NT8T+DIL7wRcaT4vtLCbQptKufBmi67cX1le2evXOs2tz4gv3vNMs5rW01JLOyiuLd2ktADw+78VWngrQPD5034u+ArHw1Z+NfHfwuv8ASZb9vB+nxeBpPEGp6Jp/g7wz4d8VvD4WPijwg+iaRp94Fs3NxpD6qlrZrNLaTXVb4GXGs+Dn8CeE9K0D4o6T4t+Lvw5tvE9nZ3mseH9T0LS9C0m1+HvhG6sodMt9T0Xwml9BpljDrGpWMWlR3cmlahql5olzY3ch0ytn4h
 

Re: [tor-bugs] #24970 [Internal Services/Service - jenkins]: Create alpha Tor Browser Manual Jenkins job

[Tor Bug Tracker & Wiki]

#24970: Create alpha Tor Browser Manual Jenkins job
-+
 Reporter:  phoul|  Owner:  weasel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 Good catch and thanks for the specific pointer.

 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

[tor-bugs] #24989 [Core Tor/Tor]: Count hsdir requests against maxcircuitspending

[Tor Bug Tracker & Wiki]

#24989: Count hsdir requests against maxcircuitspending
--+---
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 In #13837, we split off hsdir purposes from general. In the process, it
 means that we stopped counting hsdir circuits towards the global pending
 rate limit in count_pending_general_client_circuits(). That function was
 already trying to avoid counting hs circuits, but since nothing else
 globally limits the number of pending hs circuits, we probably should keep
 rate limiting hsdirs there, too.

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

Re: [tor-bugs] #24989 [Core Tor/Tor]: Count hsdir requests against maxcircuitspending

[Tor Bug Tracker & Wiki]

#24989: Count hsdir requests against maxcircuitspending
--+---
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 See also the discussion in #24973

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

Re: [tor-bugs] #24988 [Core Tor/Tor]: Implement prop#269 "Hybrid Handshakes" (ntor2 module)

[Tor Bug Tracker & Wiki]

#24988: Implement prop#269 "Hybrid Handshakes" (ntor2 module)
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ntor handshakes tor-circuit  |  Actual Points:
  cryptography   |
Parent ID:  #24985   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor3
-+-

Comment (by isis):

 I had a discussion with Ian at RWC2018 about the changes, and we have a
 meeting scheduled for later this week to discuss (and hopefully come to
 some agreement on) them. Notes and takeaways from the meeting will be
 forthcoming.

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

Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--
Changes (by isis):

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


Comment:

 Tentatively closing as fixed, but please reopen if the issue isn't fixed
 in some way!

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

Re: [tor-bugs] #24983 [Metrics/CollecTor]: Inaccessible semi-recent consensus files

[Tor Bug Tracker & Wiki]

#24983: Inaccessible semi-recent consensus files
---+--
 Reporter:  robgjansen |  Owner:  karsten
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Replying to [comment:2 karsten]:
 > Yes, this is a known (to me), but probably yet undocumented issue.
 Thanks for creating this issue! It bothered me from time to time, but not
 enough to open a ticket. ;)
 >
 > So, making more files available in the `recent/` directory would be one
 option. But all tools downloading from that directory would then have to
 fetch even more data. I'm thinking of newly bootstrapped Onionoo instances
 for development purposes, for one example.

 Valid point.

 >
 > Another option would be to create tarballs for the `archive/` directory
 more often. Maybe every 2 days instead of every 3 days. That would solve
 this issue, too, right? If so, and if there are no concerns, I'll change
 the cronjob to try this out for a week or so.

 That should be fine.
 (We should keep this in mind when we get around to 'java-ize' the
 archiving process.)

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

Re: [tor-bugs] #24992 [Core Tor/Tor]: SingleOnion (and Tor2web?) connections may need better expiry, lots left open

[Tor Bug Tracker & Wiki]

#24992: SingleOnion (and Tor2web?) connections may need better expiry, lots left
open
---+--
 Reporter:  alecmuffett|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords:  singleonion, circuits  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by alecmuffett):

 * Attachment "time-wait.txt" added.

 time-wait connection dump; all these relay connections were open.

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

Re: [tor-bugs] #24956 [Community/Outreach]: put labs.tp.o on hiatus?

[Tor Bug Tracker & Wiki]

#24956: put labs.tp.o on hiatus?
+---
 Reporter:  arma|  Owner:  mikeperry
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by mikeperry):

 Ok. In order to use the auto-renewed Let's Encrypt cert, we need to point
 the labs.torproject.org DNS to be a CNAME for live-
 torlabs.pantheonsite.io.

 (Separately, we should also decide if we want Tor Labs to be a thing -- it
 needs a community manager to interface with volunteer projects to showcase
 them on there. I don't really have the cycles for that).

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

[tor-bugs] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
--+-
 Reporter:  alecmuffett   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal|   Keywords:  singleonion, guards
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This is the first of a pair of bugs with the same logfiles, so unless
 requested I'll only attach the logs once, here, unless there's a real need
 to duplicate them.

 I have an EOTK SingleOnion, config attached.

 Per the logfile, it is both HiddenServiceSingleHopMode and
 HiddenServiceNonAnonymousMode.

 It's from "dropsafezeahmyho" which is the onion for my personal blog
 (dropsafe.crypticide.com) which is very low traffic as an Onion, in fact
 it exists mostly as a test onion.

 Issue #1 - after an extended period of uptime, tor claims:

 {{{
 Jan 21 08:45:04.000 [notice] Our directory information is no longer up-to-
 date enough to build circuits: We're missing descriptors for 1/2 of our
 primary entry guards (total microdescriptors: 5975/6006).
 Jan 21 08:45:04.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We're missing descriptors for 1/2 of
 our primary entry guards (total microdescriptors: 5975/6006).
 }}}

 ...which should not be happening, because (as a single onion) there are no
 Guards.

 Issue 2 will be described in the next ticket, and linked back to this one.

 Attachments: logfile and configfile.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24992 [Core Tor/Tor]: SingleOnion (and Tor2web?) connections may need better expiry, lots left open

[Tor Bug Tracker & Wiki]

#24992: SingleOnion (and Tor2web?) connections may need better expiry, lots left
open
--+---
 Reporter:  alecmuffett   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal|   Keywords:  singleonion, circuits
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 This is a followup to #24991, which has two of the config files (tor
 config, and tor log)

 Expanding on the description in #24991, my blog has a low traffic single
 onion - barely gets hit over Tor at all - yet when I investigated it
 recently I found it claiming to have 6 circuits open for an extended
 period (~days) and also ~50 simultaneous TCP connections.

 I confirmed this with netstat, and then by killing the Tor daemon which
 threw all the connections into simultaneous TIME_WAIT.

 I mentioned this to Teor on IRC, who suggested that I log " a ticket about
 expiring single onion and tor2web connections, please" - because this
 seems really strange, and suggests that SingleOnions are not garbage-
 collecting properly.

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