Re: [tor-bugs] #24915 [Core Tor/Tor]: I keep getting this error. "OpenSSL version from headers does not match the version we're running with"

[Tor Bug Tracker & Wiki]

#24915: I keep getting this error. "OpenSSL version from headers does not match 
the
version we're running with"
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:2 teor]:
 > Hi,
 >
 > Please don't use priorities to try to get attention for your issues. It
 doesn't work, and it confuses us when we review tickets. If you want us to
 look at a ticket, set the version field correctly, and set the milestone
 field to the next release.
 >
 > The warning is telling you that your packager compiled tor against the
 FIPS-certified version of OpenSSL, but you installed the non-FIPS-
 certified version. This is a slightly weird thing to do, but it is
 unlikely to cause any issues if the versions are similar enough.
 >
 > (In this case, they are the same version, with slightly different
 compilation options.)
 >
 > > If you get weird crashes, that might be why.
 >
 > Unless you get weird crashes, this is not a bug.
 Thank you tor for the explanation. I did not know that I could not use
 priorities, There is no documentation I could find that shows that I'm not
 supposed to use it "priorities setting". I will take your recommendations
 Into consideration in the future when creating tickets.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24972 [Core Tor/Tor]: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.

[Tor Bug Tracker & Wiki]

#24972: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal
assertion !(ret < 0) failed.
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs prop224
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 My HSv3 is unable to encode its own descriptor with the following fail:
 {{{
 Jan 21 08:00:49.000 [info] connection_free_minimal(): Freeing linked Socks
 connection [open] with 0 bytes on inbuf, 0 on outbuf.
 Jan 21 08:00:49.000 [info] handle_response_upload_hsdesc(): Uploaded
 hidden service descriptor (status 200 ("HS descriptor stored
 successfully."))
 Jan 21 08:00:49.000 [info] handle_response_upload_hsdesc(): Uploading
 hidden service descriptor: finished with status 200 ("HS descriptor stored
 successfully.")
 Jan 21 08:00:49.000 [info] connection_free_minimal(): Freeing linked
 Directory connection [client finished] with 0 bytes on inbuf, 0 on outbuf.
 Jan 21 08:00:49.000 [info] circuit_finish_handshake(): Finished building
 circuit hop:
 Jan 21 08:00:49.000 [info] internal (high-uptime) circ (length 4, last hop
 damita): $E2920D7419B7601CF82D43400D042DA70E0675B2(open)
 $CA58EB617C6CA2F351AEFD56C84B8A7AF7704B22(open)
 $0E3D3FCE26F6969B7AE80E4CA6C4CFA97988F31E(open)
 $A9F7185499C5784E35B5C25744ED4AB75437CE5D(open)
 Jan 21 08:00:49.000 [info] entry_guards_note_guard_success(): Recorded
 success for primary confirmed guard papadouka
 ($E2920D7419B7601CF82D43400D042DA70E0675B2)
 Jan 21 08:00:49.000 [info] circuit_build_no_more_hops(): circuit built!
 Jan 21 08:00:49.000 [info] pathbias_count_build_success(): Got success
 count 224.332749/291.637758 for guard papadouka
 ($E2920D7419B7601CF82D43400D042DA70E0675B2)
 Jan 21 08:01:06.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 5296 ms. Delta -4ms
 Jan 21 08:01:12.000 [info] routerlist_remove_old_routers(): We have 0 live
 routers and 0 old router descriptors.
 Jan 21 08:01:19.000 [info] or_state_save(): Saved state to
 "/home/f/.tor/state"
 Jan 21 08:01:25.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 5996 ms. Delta 2ms
 Jan 21 08:01:32.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 6840 ms. Delta -2ms
 Jan 21 08:01:43.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 2096 ms. Delta 0ms
 Jan 21 08:01:51.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 7912 ms. Delta 0ms
 Jan 21 08:01:57.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 6456 ms. Delta 0ms
 Jan 21 08:02:05.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 7952 ms. Delta 3ms
 Jan 21 08:02:07.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 2280 ms. Delta 1ms
 Jan 21 08:02:12.000 [info] routerlist_remove_old_routers(): We have 0 live
 routers and 0 old router descriptors.
 Jan 21 08:02:20.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 3756 ms. Delta 2ms
 Jan 21 08:02:33.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 8344 ms. Delta 0ms
 Jan 21 08:03:00.000 [info]
 channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive
 on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after
 4508 ms. Delta 2ms
 Jan 21 08:03:04.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service
 j2eiu2izwjpazjevu4xs3muaif3jzex3nnvnu677vz2fypmzccvhhiid with 3/3
 introduction points.
 Jan 21 08:03:04.000 [info] close_directory_connections(): Closed 0 active
 service directory connections for descriptor
 9btQxrMpxWDJwnf1TU6U+5vcPmPdD2OPBVAKKmRLr7I of service
 j2eiu2izwjpazjevu4xs3mua

Re: [tor-bugs] #24972 [Core Tor/Tor]: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.

[Tor Bug Tracker & Wiki]

#24972: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal
assertion !(ret < 0) failed.
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+
Description changed by asn:

Old description:

> My HSv3 is unable to encode its own descriptor with the following fail:
> {{{
> Jan 21 08:00:49.000 [info] connection_free_minimal(): Freeing linked
> Socks connection [open] with 0 bytes on inbuf, 0 on outbuf.
> Jan 21 08:00:49.000 [info] handle_response_upload_hsdesc(): Uploaded
> hidden service descriptor (status 200 ("HS descriptor stored
> successfully."))
> Jan 21 08:00:49.000 [info] handle_response_upload_hsdesc(): Uploading
> hidden service descriptor: finished with status 200 ("HS descriptor
> stored successfully.")
> Jan 21 08:00:49.000 [info] connection_free_minimal(): Freeing linked
> Directory connection [client finished] with 0 bytes on inbuf, 0 on
> outbuf.
> Jan 21 08:00:49.000 [info] circuit_finish_handshake(): Finished building
> circuit hop:
> Jan 21 08:00:49.000 [info] internal (high-uptime) circ (length 4, last
> hop damita): $E2920D7419B7601CF82D43400D042DA70E0675B2(open)
> $CA58EB617C6CA2F351AEFD56C84B8A7AF7704B22(open)
> $0E3D3FCE26F6969B7AE80E4CA6C4CFA97988F31E(open)
> $A9F7185499C5784E35B5C25744ED4AB75437CE5D(open)
> Jan 21 08:00:49.000 [info] entry_guards_note_guard_success(): Recorded
> success for primary confirmed guard papadouka
> ($E2920D7419B7601CF82D43400D042DA70E0675B2)
> Jan 21 08:00:49.000 [info] circuit_build_no_more_hops(): circuit built!
> Jan 21 08:00:49.000 [info] pathbias_count_build_success(): Got success
> count 224.332749/291.637758 for guard papadouka
> ($E2920D7419B7601CF82D43400D042DA70E0675B2)
> Jan 21 08:01:06.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 5296 ms. Delta -4ms
> Jan 21 08:01:12.000 [info] routerlist_remove_old_routers(): We have 0
> live routers and 0 old router descriptors.
> Jan 21 08:01:19.000 [info] or_state_save(): Saved state to
> "/home/f/.tor/state"
> Jan 21 08:01:25.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 5996 ms. Delta 2ms
> Jan 21 08:01:32.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 6840 ms. Delta -2ms
> Jan 21 08:01:43.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 2096 ms. Delta 0ms
> Jan 21 08:01:51.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 7912 ms. Delta 0ms
> Jan 21 08:01:57.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 6456 ms. Delta 0ms
> Jan 21 08:02:05.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 7952 ms. Delta 3ms
> Jan 21 08:02:07.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 2280 ms. Delta 1ms
> Jan 21 08:02:12.000 [info] routerlist_remove_old_routers(): We have 0
> live routers and 0 old router descriptors.
> Jan 21 08:02:20.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 3756 ms. Delta 2ms
> Jan 21 08:02:33.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 8344 ms. Delta 0ms
> Jan 21 08:03:00.000 [info]
> channelpadding_send_padding_cell_for_callback(): Sending netflow
> keepalive on 58 to 86.106.137.6:443
> (E2920D7419B7601CF82D43400D042DA70E0675B2) after 4508 ms. Delta 2ms
> Jan 21 08:03:04.000 [info] run_upload_descriptor_event(): Initiating
> upload for hidden service current descriptor for service
> j2eiu2izwjpazjevu4xs3muaif3jzex3nnvnu677vz2fypmzccvhhiid with 3/3
> introduction points.
> Jan 21 08:03:04.000 [info] close_directory_connectio

Re: [tor-bugs] #24971 [- Select a component]: Tor browser not working

[Tor Bug Tracker & Wiki]

#24971: Tor browser not working
--+
 Reporter:  johnsmithjs   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Dude! You should not post your computername and architecture. This pair is
 valuable information that Microsoft and NSA can identify you that you're
 using Tor. Edit it 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] #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:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by weasel):

 I pointed you to https://tb-manual.torproject.org/alpha/ in our last mail.
 Is that not sufficient?

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

Re: [tor-bugs] #24937 [Core Tor/Tor]: tor failing to resolve some dns records

[Tor Bug Tracker & Wiki]

#24937: tor failing to resolve some dns records
---+--
 Reporter:  baageg |  Owner:  dgoulet
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords:  dns resolving records  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * component:  Core Tor/Torsocks => Core Tor/Tor


Comment:

 I can confirm that you can apparently not resolve
 "node.moneroworld.com"
 and
 "node.xmr.be"
 via tor.
 I didn't test across multiple exits because I assume it is not related to
 the exit.

 I tested it against tor's DNSPort, I don't think that has anything todo
 with torsocks.
 (That is why I changed the component for this ticket on trac)


 It is probably worth mentioning that
 node.moneroworld.com resolves to 32 A records,
 node.xmr.be resolve to 55 A records,
 which might be the problem here?

 Has tor a limit on how much it can take?

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 99%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 99%
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Immediate  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Blocker| Resolution:
 Keywords:  noscript   |  Actual Points:
Parent ID:  #18361 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Damn... Happening again. Google ban 100% Tor exits.

 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 99%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 99%
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Immediate  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Blocker| Resolution:
 Keywords:  noscript   |  Actual Points:
Parent ID:  #18361 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Fuck you Google and Cloudflare. I mean 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] #24937 [Core Tor/Tor]: tor failing to resolve some dns records

[Tor Bug Tracker & Wiki]

#24937: tor failing to resolve some dns records
---+--
 Reporter:  baageg |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords:  dns resolving records  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

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


Comment:

 (removing dgoulet as owner since it was only him because the component
 used to be torsocks)

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

Re: [tor-bugs] #24937 [Core Tor/Tor]: tor failing to resolve some dns records

[Tor Bug Tracker & Wiki]

#24937: tor failing to resolve some dns records
---+--
 Reporter:  baageg |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords:  dns resolving records  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
--+
 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|   Keywords:  tor-dos tor-hs performance
Actual Points:|  Parent ID:
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 When starting up Tor as an HS, Tor will create dozens of circs in quick
 succession (preemptive circs, HSDir circs, intro point circs, CBT circs).

 Consider a Tor that starts up with 10 HSes configured(many of those Tors
 exist); it will easily attempt to make hundreds of circuits within
 seconds.

 It might make sense to have some sort of circuit rate limiting during
 startup to avoid flooding our guard with so many circuit creations. I
 notice that Tor will whine about the guard failing circuits during startup
 very often, and perhaps this initial circuit flood is what's causing it?

 We already have `MaxClientCircuitsPending` but not sure if that's enough.
 We also used to delay bootup of multiple onion services, but not sure we
 do this anymore (can't see it in `hs_config_service_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] #22488 [Metrics/Onionoo]: Include relay version listed in consensus in addition to platform line from server descriptor

[Tor Bug Tracker & Wiki]

#22488: Include relay version listed in consensus in addition to platform line 
from
server descriptor
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 I just realized that onionoo provides already both data points (platform
 and version as seen in consensus):


 
https://onionoo.torproject.org/details?fields=version,platform,recommended_version,fingerprint&search=fastor&type=relay
 {{{
 {"version":"5.0",
 "build_revision":"0bce98a",
 "relays_published":"2018-01-23 08:00:00",
 "relays":[
 {"fingerprint":"0EE3D3F6988B868F9018FFEC7567289E791D4785","platform":"Tor
 0.3.2.9 on Linux","version":"0.2.9.11","recommended_version":false}
 ],
 "bridges_published":"2018-01-23 08:04:05",
 "bridges":[
 ]}
 }}}

 Filed a low prio ticket:
 https://trac.torproject.org/projects/tor/ticket/24974

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24974 [Metrics/Relay Search]: add onionoo version field to atlas/relay search

[Tor Bug Tracker & Wiki]

#24974: add onionoo version field to atlas/relay search
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This is related to:
 https://trac.torproject.org/projects/tor/ticket/22488#comment:23

 Goal: reduce the confusion for relay ops caused by false-positives of "you
 are running an outdated tor version" banner.

 Below the platform field add the onionoo version field:
 https://metrics.torproject.org/onionoo.html#details_relay_version

 Description: Version
 Tooltip text: Version of this relay as seen in the tor consensus


 Based on the recent discussion on metrics-team ML I'm adding some ticket
 "metadata":
 - This is a nice-to-have feature
 - Would be nice to have it before 2019

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

Re: [tor-bugs] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
+--
 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-dos tor-hs performance  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [ticket:24973 asn]:
 > We already have `MaxClientCircuitsPending` but not sure if that's
 enough.

 Also, MaxClientCircuitsPending only counts CIRCUIT_PURPOSE_C_GENERAL
 circuits, and Mike's new feature in #23101 has stopped using C_GENERAL
 circuits for posting or fetching hsdescs.

 Also also, my upcoming plans in #24902 will start sending destroys back if
 you send me too many create cells in too short a time period.

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

Re: [tor-bugs] #24937 [Core Tor/Tor]: tor failing to resolve some dns records

[Tor Bug Tracker & Wiki]

#24937: tor failing to resolve some dns records
---+--
 Reporter:  baageg |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords:  dns resolving records  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 When you do a "host node.moneroworld.com", its answer starts with:
 ;; Truncated, retrying in TCP mode.

 I'm guessing that could be a good hint.

 --Roger

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

Re: [tor-bugs] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
+--
 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-dos tor-hs performance  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [ticket:24973 asn]:
 > Consider a Tor that starts up with 10 HSes configured(many of those Tors
 exist); it will easily attempt to make hundreds of circuits within
 seconds.

 You can see one of those Tors in action (probably with more than 10 HSes)
 at #24897:
 {{{
 Jan 20 16:33:30.000 [notice] We'd like to launch a circuit to handle a
 connection, but we already have 128 general-purpose client circuits
 pending. Waiting until some finish. [1808313 similar message(s) suppressed
 in last 600 seconds]
 }}}

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:15 dgoulet]:
 > * This code uses the geoip client cache which seems fine but has an
 interesting quirks. After 24h, an entry is wiped out which means we loose
 all the DoS mitigation statistics for the entry at that point.

 Is this another way that the concurrent conn count could get out of sync?

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:18 teor]:
 > Do we know if the extra load is bringing down HSDirs?
 > (The fetch creates more load, but HS descriptors are cached by clients.)

 I heard from one of the affected onion services that some of their HSDirs
 tend to go offline. So I'm going to say "yes it does happen".

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:24 teor]:
 > Tor2web clients don't use guards for any HS circuits. They're all direct
 connections to a randomly selected rend point. With no bandwidth
 weighting.

 For the historical record, they do use bandwidth weighting, except in the
 case where they additionally set the Tor2webRendezvousPoints config option
 (which I assume few of them do).

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:24 teor]:
 > * ignore ESTABLISH_RENDEZVOUS cells (min 15s)
 >
 > I think we should send back CREATED, and ignore the
 ESTABLISH_RENDEZVOUS, because that gets us a guaranteed minimum 15 second
 timeout.

 Agreed. That's what I've been doing on my hacked-up relay:
 {{{
 @@ -249,6 +251,14 @@ rend_mid_establish_rendezvous(or_circuit_t *circ,
 const uint8_t *request,
  goto err;
}

 +  if (channel_is_client(circ->p_chan)) {
 +log_info(LD_REND,
 +  "DEFENSE: dropped ESTABLISH_RENDEZVOUS on circuit %u, prev IP %s",
 +  (unsigned)circ->p_circ_id,
 +  channel_get_actual_remote_descr(circ->p_chan));
 +return 0; // quietly drop it, and let it time out
 +  }
 +
/* Acknowledge the request. */
if (relay_send_command_from_edge(0,TO_CIRCUIT(circ),
 RELAY_COMMAND_RENDEZVOUS_ESTABLISHED,
 }}}
 and I think it's a good choice here too.

 > We could increase the cbtmintimeout consensus parameter to a really high
 value. (Which seemed to work well on my relays.) But the client's timeout
 would only stay high if almost all relays delayed almost all circuits
 created by these clients.

 No, I think the only way to get a higher timeout for establish-rendezvous
 attempts is if the user manually set their options->CircuitStreamTimeout.
 The code as you say is
 {{{
   /* CIRCUIT_PURPOSE_C_ESTABLISH_REND behaves more like a RELAY cell.
* Use the stream cutoff (more or less). */
   SET_CUTOFF(stream_cutoff, MAX(options->CircuitStreamTimeout,15)*1000 +
 1000);
 }}}
 which does not reference get_circuit_build_timeout_ms(). :(

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

Re: [tor-bugs] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
+--
 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-dos tor-hs performance  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [comment:1 arma]:
 > Also also, my upcoming plans in #24902 will start sending destroys back
 if you send me too many create cells in too short a time period.

 Would it be totally crazy for clients to take a look at the
 dos_cc_circuit_max_count consensus param (or whatever we end up naming it)
 from #24902, and try to hold themselves under it when they have some
 control over their circuit load, like in this case?

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

Re: [tor-bugs] #24883 [Webpages]: Listing OpenBSD Tor Brower on www

[Tor Bug Tracker & Wiki]

#24883: Listing OpenBSD Tor Brower on www
-+
 Reporter:  gman999  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Webpages |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 it has been added to download-easy:
 https://www.torproject.org/download/download-easy.html.en#openbsd

 but not to download:
 https://www.torproject.org/download/download.html.en

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

Re: [tor-bugs] #24896 [Core Tor/Tor]: Onion services should include basic intro/rend stats in their heartbeat logs

[Tor Bug Tracker & Wiki]

#24896: Onion services should include basic intro/rend stats in their heartbeat
logs
--+
 Reporter:  arma  |  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:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * status:  new => needs_review


Comment:

 Pushed branch in my `bug24896` that implements a basic version of this
 feature (does not actually do (c) from arma above).

 This is the basic feature; in the future we can build more stuff and logic
 into it. The current version can still be helpful in giving a rough
 estimate of onion service usage, and also showing signs of abnormal
 activity.

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

Re: [tor-bugs] #24937 [Core Tor/Tor]: tor failing to resolve some dns records

[Tor Bug Tracker & Wiki]

#24937: tor failing to resolve some dns records
---+--
 Reporter:  baageg |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords:  dns resolving records  |  Actual Points:
Parent ID:  #24968 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * parent:   => #24968


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

Re: [tor-bugs] #24937 [Core Tor/Tor]: tor failing to resolve some dns records

[Tor Bug Tracker & Wiki]

#24937: tor failing to resolve some dns records
---+--
 Reporter:  baageg |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.9
 Severity:  Normal | Resolution:
 Keywords:  dns resolving records  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * parent:  #24968 =>


Comment:

 removing parent ID since this has nothing todo with 0.3.2.9 (happens on
 0.3.1.9 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] #19801 [Webpages/Website]: Add sdscoq7snqtznauu.onion to torproject.org/docs/debian.html

[Tor Bug Tracker & Wiki]

#19801: Add sdscoq7snqtznauu.onion to torproject.org/docs/debian.html
--+--
 Reporter:  ilf   |  Owner:  hiro
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-bug   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 A guide for using apt-transport-tor to enable apt (apt-get) to handle
 hidden service onions was written on the Tor Blog in December 2016. The
 blog post and comments could be modified and appended to (or simply linked
 from) the docs page in the ticket description.

 https://blog.torproject.org/tor-heart-apt-transport-tor-and-debian-onions

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

Re: [tor-bugs] #24937 [Core Tor/Tor]: tor failing to resolve some dns records

[Tor Bug Tracker & Wiki]

#24937: tor failing to resolve some dns records
---+
 Reporter:  baageg |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-exit, tor-dns  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:  dns resolving records => tor-exit, tor-dns
 * priority:  High => Medium
 * version:  Tor: 0.3.2.9 => Tor: 0.2.9.11
 * points:   => 1
 * milestone:   => Tor: 0.3.4.x-final


Comment:

 The next step is to test this on an exit, and see what the error is.
 Chutney would be a good tool to run a client and exit, and log at info or
 debug level, without logging any user data.

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

Re: [tor-bugs] #22960 [Applications/Tor Browser]: Tor Browser crashes when IPC connection got lost (was: Tor Browser is leaking IPC messages)

[Tor Bug Tracker & Wiki]

#22960: Tor Browser crashes when IPC connection got lost
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-e10s, tbb-crash, tbb-oom  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:2 cypherpunks]:
 > Unfortunately, this happens pretty often when you switch tabs on the
 latest alpha. If it happens when a child process lost connection to the
 parent, ipc queue is empty on the parent side, but it grows on the child
 side.
 It seems possible to bring the browser back to life by manually resuming
 suspended thread in child process like in #22813. Probably, upgrading
 MinGW-w64 could help.
 (cypherpunks account is now able to Cc `tor-...@lists.torproject.org`,
 please disable 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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:29 arma]:
 > Replying to [comment:24 teor]:
 > > We could increase the cbtmintimeout consensus parameter to a really
 high value. (Which seemed to work well on my relays.) But the client's
 timeout would only stay high if almost all relays delayed almost all
 circuits created by these clients.
 >
 > No, I think the only way to get a higher timeout for establish-
 rendezvous attempts is if the user manually set their
 options->CircuitStreamTimeout. The code as you say is
 > {{{
 >   /* CIRCUIT_PURPOSE_C_ESTABLISH_REND behaves more like a RELAY cell.
 >* Use the stream cutoff (more or less). */
 >   SET_CUTOFF(stream_cutoff, MAX(options->CircuitStreamTimeout,15)*1000 +
 1000);
 > }}}
 > which does not reference get_circuit_build_timeout_ms(). :(

 I was talking about dropping other types of cells earlier in circuit
 construction. Those purposes reference get_circuit_build_timeout_ms().

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

Re: [tor-bugs] #24972 [Core Tor/Tor]: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.

[Tor Bug Tracker & Wiki]

#24972: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal
assertion !(ret < 0) failed.
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+

Comment (by asn):

 Also uploading some info logs.

 It seems like the problem occurs only for the `current` descriptor, wheras
 the `next` one gets uploaded normally. You can also see various info-level
 HSDir descriptor rejection logs even from before the non-fatal assert
 started appearing.

 It's a bit sad we don't have more precise logs from `tor_cert_checksig()`
 so that we know how the signature check failed. It could even be an
 expiration issue, but that wouldn't make much sense since the cert is made
 on demand before the desc encode...

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

Re: [tor-bugs] #24972 [Core Tor/Tor]: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.

[Tor Bug Tracker & Wiki]

#24972: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal
assertion !(ret < 0) failed.
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+
Changes (by asn):

 * Attachment "bug24972.log.gz" 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] #18918 [Core Tor/Tor]: Clarify directory and ORPort checking functions

[Tor Bug Tracker & Wiki]

#18918: Clarify directory and ORPort checking functions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, code, refactor|  Actual Points:
  technical-debt tor-relay   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ffmancera):

 I have been reviewing the code these days. I don't think we should rename
 any function but I want to propose some changes in the code structure. I
 will list all the reviewed functions with my notes about them.

  * `check_whether_orport_reachable()` and
 `check_whether_dirport_reachable()`: I think they are fine, nice
 documentation and names.

  * `router_has_bandwidth_to_dirserver()`: Poor documentation, I already
 improved it a bit. Also I think we don't need to check
 `options->BandwidthRate < MIN_BW_TO_ADVERTISE_DIRSERVER` because we are
 checking the same on RelayBandwidthRate.

  * `router_should_be_directory()`: I don't think we need to check
 `advertising != new_choice` and then `new_choice == 1` because we
 initialize both to `1` and within the function only `new_choice` could
 turn into `0`. I already removed this if statement and it works correctly.

 * `dir_server_mode()` and `decide_to_advertise_dirport()`: I think they
 are fine, nice documentation and names.

 About combine functions, I think we could get
 `router_has_bandwidth_to_be_dirserv` into `router_should_be_directory`.
 Let's decide about do or not these changes and I will work on them :-)

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

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

 * Attachment "seccomp-browser.c" added.

 seccomp based test case.

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

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

Comment (by yawning):

 Apparently someone really wanted to be able to see this with seccomp, so I
 attached a trivial program that uses libseccomp to initialize a filter
 that will reject `socket(AF_INET[6], ..., ...)` by SIGSYSing the thread.

 Usage:

  1. Compile it.
  2. Set the required env vars to get Tor Browser to talk to a external tor
 process over AF_UNIX sockets.
  3. Run it from the root of a tor browser installation (It calls
 `system("Browser/start-tor-browser");` because it's a trivial test case
 and I'm lazy).
  4. Watch in horror as nothing works.
  5. Run it with strace to see the socket thread traces ending abruptly
 with `+++ killed by SIGSYS +++`.

 The control port appears to work, but any attempt to use the socks port
 get stomped on, so I'm basically convinced that the root cause is the
 non-`AF_INET` socket support in `nsSOCKSIOLayer` being a steaming pile of
 shit.

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

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

Comment (by yawning):

 Really though, just look at `nsSOCKSIOLayer`.

  1. All outgoing SOCKS connections made by firefox start out their lives
 as `AF_INET` sockets. (Assumption, firefox code gives me a headache, but
 it matches the trace output).
  2. When firefox actually goes to connect to the proxy (`ConnectToProxy`),
 the `FixupAddressFamily` routine is called.
  3. `FixupAddressFamily` checks to see if the proxy actually is reachable
 via an `AF_INET` socket, and if not, opens a new file descriptor with the
 correct domain.

 What appears to have happened judging for a cursory inspection of the file
 history was:

   1. Back in the day, this was only expected to handle `AF_INET`, because
 "this IPng thing will never happen".
   2. When `AF_INET6` support was required, it was kludged on this way.
   3. When `AF_UNIX` (and Windows pipes or whatever that's also in the
 code) support was required, the kludge was enhanced.

 Which is great if the only reason you want something like `AF_UNIX` is to
 use `AF_UNIX` socket for the hell of it, and not so great if you want use
 something like seccomp to prohibit `AF_INET`.

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

 The definition of the routerstatus_t structure, as in or.h has only
 `time_t published_on`. Is that the required timestamp to check.
 A check like, (a->published_on != b->published_on) would do the task?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24975 [Core Tor/Tor]: sched: scheduler_notify_networkstatus_changed() calls select_scheduler() without the new consensus

[Tor Bug Tracker & Wiki]

#24975: sched: scheduler_notify_networkstatus_changed() calls select_scheduler()
without the new consensus
--+-
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  032-backport, tor-sched
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 `select_scheduler()` is called when a new consensus arrives with
 `scheduler_notify_networkstatus_changed()` but never takes the new
 consensus for which at that point it is not yet set as the global
 consensus.

 It needs to use `new_c`.

 This is not good because of that, we can't change anything with the
 consensus at runtime.

 Thanks to Roger for finding this out here:
 https://oniongit.eu/dgoulet/tor/merge_requests/17#note_2153

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

[tor-bugs] #24977 [- Select a component]: 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:  - Select a component  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal|   Keywords:  tor-hs prop224
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 This one is back, since pre-release days of hsv3. Something makes it such
 that the hsdir index is not well set for some relays.

 I got this to happen on my hsv3 service a few weeks ago. I got it a few
 times on the same second for the same node, and then it got fixed... There
 were no other references to that node (or its fpr) before that.

 {{{
 Jan 04 21:30:54.000 [warn] tor_bug_occurred_(): Bug:
 src/or/hs_common.:1277: node_has_hsdir_index: Non-fatal assertion
 !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))
 failed. (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: Non-fatal assertion
 !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))
 failed in node_has_hsdir_index at src/or/hs_common.c:1277. Stack trace:
 (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(log_backtrace+0x42)
 [0x7f6079a21db2] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug:
 ./tor/src/or/tor(tor_bug_occurred_+0xb7) [0x7f6079a3cc57] (on Tor 0.3.2.6
 -alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug:
 ./tor/src/or/tor(hs_get_responsible_hsdirs+0x4f9) [0x7f6079a046c9] (on Tor
 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug:
 ./tor/src/or/tor(hs_service_run_scheduled_events+0x1a5b) [0x7f6079a11c5b]
 (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(+0x4b9f1)
 [0x7f60798ed9f1] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(+0x6b4f0)
 [0x7f607990d4f0] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f6078f253dc] (on Tor
 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(do_main_loop+0x244)
 [0x7f60798f0eb4] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(tor_main+0x1c25)
 [0x7f60798f46f5] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(main+0x19)
 [0x7f60798ec629] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7f60781182b1] (on Tor 0.3.2.6
 -alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [warn] Bug: ./tor/src/or/tor(_start+0x2a)
 [0x7f60798ec67a] (on Tor 0.3.2.6-alpha-dev b6fd78ea301bd089)
 Jan 04 21:30:55.000 [info] hs_get_responsible_hsdirs(): Node
 $EEC47B34F9403AA7F765D070BB3011E50A373C21~ivanmk2 at 185.22.173.162 was
 found without hsdir index.
 Jan 04 21:30:55.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  029-backport 031-backport
 Severity:  Normal   |  032-backport openssl
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 From https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ :

 >If you explicitly configure your ciphersuites then care should be taken
 to ensure that you are not inadvertently excluding all TLSv1.3 compatible
 ciphersuites. If a client has TLSv1.3 enabled but no TLSv1.3 ciphersuites
 configured then it will immediately fail (even if the server does not
 support TLSv1.3) with an error message

 That's the situation we're in now.  When OpenSSL 1.1.1 releases in April,
 current Tor versions just won't work with it at all, since they have
 neither disabled TLS1.3 nor enabled any TLS1.3 ciphers.

 We have two options for fixing this: I'll implement both and we can see
 what we like.

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

 This was merged, but rpms.wml cannot be removed at the moment.

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

[tor-bugs] #24979 [Core Tor/Torsocks]: torsocks could support ptrace sandboxing

[Tor Bug Tracker & Wiki]

#24979: torsocks could support ptrace sandboxing
---+-
 Reporter:  Hello71|  Owner:  dgoulet
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 pros:

 - 'fixes' SIP, suid, caps
 - fixes static binaries

 cons:

 - kind of a pain to implement
 - DNS would require actual parsing, which is apparently a hard problem
 even for 'minimal' implementations:
 https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-
 dhcp.html. I think an initial hybrid implementation could punt on this,
 and it would still fix the ugly hack of hardcoding SIP paths.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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] #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] #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:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by Hello71):

 * 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] #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 cypherpunks):

 By default, seems really great to protect users (would such a benefit
 apply to GlobaLeaks as well?). What if I want to have EXIF data uploaded?
 There should be some pref for that I can flip in such cases.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24980 [Webpages]: Add QubesOS and Whonix's next-gen onion services

[Tor Bug Tracker & Wiki]

#24980: Add QubesOS and Whonix's next-gen onion services
-+--
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Webpages |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Add

 {{{
 http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/
 http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/
 }}}

 to the NextGenOnions trac wiki page.

 Verification: https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-
 gen-tor-onion-services/

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

Re: [tor-bugs] #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:
-+--
Changes (by mcs):

 * cc: brade, mcs, isabela, antonela (added)


Comment:

 For future reference, here are some of the images that still need to be
 replaced in a Firefox 52 ESR-based Tor Browser:
 * browser/branding/official/default22.png
 * browser/branding/official/content/about-logo.png
 * browser/branding/official/content/about-l...@2x.png
 * browser/branding/official/content/about-wordmark.png
 * browser/branding/official/content/about.png
 * browser/branding/official/content/icon48.png
 * browser/branding/official/content/icon64.png
 * browser/branding/official/content/identity-icons-brand.svg
 * browser/branding/official/content/silhouette-40.svg

 We will probably need to update this list for ESR 60, and there are other
 images under browser/branding/official that may or may not be used in Tor
 Browser (I think some of the files are only be used by Firefox's Windows
 installer).

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

Re: [tor-bugs] #24578 [Applications/Tor Browser]: about:tbupdate popup notification formatting error

[Tor Bug Tracker & Wiki]

#24578: about:tbupdate popup notification formatting error
--+---
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

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


Comment:

 Replying to [comment:3 mcs]:
 > I do not think this is a new problem. We do plan to stop using a query
 parameter with about:tbupdate (#21850 is a related ticket). Then the
 doorhanger would just have `about:tbupdate`.

 The above issue is fixed by the patches in #21850.

 > The wrong icon is shown on all of our about: pages, e.g., about:tor so
 that is general branding problem.

 I am resolving this ticket as a duplicate of #10888 because it covers this
 remaining issue.

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

Re: [tor-bugs] #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] #24981 [Internal Services/Service - trac]: Update trac identity to match styleguide

[Tor Bug Tracker & Wiki]

#24981: Update trac identity to match styleguide
--+-
 Reporter:  steph |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 - change Tor trac logo to:
 https://styleguide.torproject.org/static/images/color.svg

 - change purple links to # 7D4698

 - change green h1 to # 68B030

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

[tor-bugs] #24982 [Applications/rbm]: Update url in README file and add script to help updating the website

[Tor Bug Tracker & Wiki]

#24982: Update url in README file and add script to help updating the website
--+---
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 With #24055 we now have the url https://rbm.torproject.org/, so we can
 update the url from the `README.md` file.

 We can also add a script in the docs directory to help us updating the
 website when there are changes.

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

Re: [tor-bugs] #22842 [Webpages/Website]: Create a knowledge base that's more in-depth than FAQs

[Tor Bug Tracker & Wiki]

#22842: Create a knowledge base that's more in-depth than FAQs
--+---
 Reporter:  catalyst  |  Owner:  hiro
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:  WebsiteV3
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #23266| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Other example designs and content by and for large open-source
 communities:
 - [https://docs.readthedocs.io/en/latest/ Read the Docs]
 - [https://wiki.archlinux.org/ ArchWiki] by Arch Linux
 - [https://wiki.debian.org/ Debian Wiki] by Debian Linux

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

Re: [tor-bugs] #22842 [Webpages/Website]: Create a knowledge base that's more in-depth than FAQs

[Tor Bug Tracker & Wiki]

#22842: Create a knowledge base that's more in-depth than FAQs
--+---
 Reporter:  catalyst  |  Owner:  hiro
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:  WebsiteV3
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #23266| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 - Wikipedia
   - [https://en.wikipedia.org/wiki/Help:Menu Help:Menu]
   - [https://en.wikipedia.org/wiki/Wikipedia:FAQ/Index
 Wikipedia:FAQ/Index]
   - [https://en.wikipedia.org/wiki/Help:Directory Help:Directory]
   - [https://en.wikipedia.org/wiki/Help:Contents Help:Contents]

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

Re: [tor-bugs] #24982 [Applications/rbm]: Update url in README file and add script to help updating the website

[Tor Bug Tracker & Wiki]

#24982: Update url in README file and add script to help updating the website
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201801R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by boklm):

 * keywords:   => TorBrowserTeam201801R
 * status:  new => needs_review


Comment:

 Branch `bug_24982` has two commits doing this:
 
https://gitweb.torproject.org/user/boklm/rbm.git/commit/?h=bug_24982&id=0eb1f12241ed067ef9c013ef0f72e9cca89ee5e6
 
https://gitweb.torproject.org/user/boklm/rbm.git/commit/?h=bug_24982&id=213fad5a8fe04272359c33778626a2802efc4ebc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24983 [Metrics/CollecTor]: Inaccessible semi-recent consensus files

[Tor Bug Tracker & Wiki]

#24983: Inaccessible semi-recent consensus files
---+--
 Reporter:  robgjansen |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I noticed there is a gap between the consensus files that are available in
 the latest snapshot, e.g.:
 https://collector.torproject.org/archive/relay-
 descriptors/consensuses/consensuses-2018-01.tar.xz

 and those available in the list of recent consensus files:
 https://collector.torproject.org/recent/relay-descriptors/consensuses/

 As of right now, many consensus files from January 19th, 2018 are
 inaccessible (they are too old to be in the recent list and too new to
 exist in the latest archived snapshot).

 I realize that those files will get added to the January 2018 archive
 snapshot soon, but it seems to me like a problem in general that at any
 time some consensus files may be inaccessible.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by robgjansen):

 Is it a reasonable change to just expand the number of files available in
 [https://collector.torproject.org/recent/relay-descriptors/consensuses/
 the recent directory of the web server]?

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

Comment (by nickm):

 The history here looks clean to me; I'll merge 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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 LOTS of fixes went in.

 See _01 branch for all the fixups and new commits.

 The _02 branch is squashed with all the things.

 Now an _03 exists for which we can have a new nice merge requests without
 breaking the _02 one on Oniongit:
 https://oniongit.eu/dgoulet/tor/merge_requests/18

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

Re: [tor-bugs] #22402 [Webpages/Website]: Usablity and accessiblity improvement on the Tor assistant page

[Tor Bug Tracker & Wiki]

#22402: Usablity and accessiblity improvement on the Tor assistant page
--+---
 Reporter:  iry   |  Owner:  linda
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #23266| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 ticket:22402#comment:8
 > Clicking on the link and open it in a default browser may be dangerous
 for some users It will let an adversary know that the user is trying
 to access torproject.org through their internet traffic, or leave a
 browser history

 This should be written above or below the text-link itself to warn users
 before they copy it. Or hide the link behind an "I'll be careful" or "I
 accept the risk" button like how Firefox does it on its about:config page.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
---+--
Changes (by karsten):

 * status:  new => accepted
 * owner:  metrics-team => karsten


Comment:

 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.

 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.

 Accepting 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] #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:  new
 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 nickm):

 * status:  needs_review => new


Comment:

 merged.  Back into "new" for other refactoring.

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

Re: [tor-bugs] #24896 [Core Tor/Tor]: Onion services should include basic intro/rend stats in their heartbeat logs

[Tor Bug Tracker & Wiki]

#24896: Onion services should include basic intro/rend stats in their heartbeat
logs
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 lgtm; 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] #24952 [Core Tor/Tor]: channel: channel_tls_get_remote_addr_method() should return the "real_addr" of the connection

[Tor Bug Tracker & Wiki]

#24952: channel: channel_tls_get_remote_addr_method() should return the 
"real_addr"
of the connection
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-channel   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 But, who calls channel_get_addr_if_possible()?  Will they still work if
 they get real_addr  instead of addr?

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

 merged, but not closing. Mike, can you answer asn's questions above and
 could one of you open tickets as appropriate?

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

 This bugged me now because I actually need the files from the 19th :)

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

 I think that would work, yes. I can't think of any problems with that
 approach other than slightly higher CPU usage for a brief period.

 Thanks!

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

Re: [tor-bugs] #22402 [Webpages/Website]: Usablity and accessiblity improvement on the Tor assistant page

[Tor Bug Tracker & Wiki]

#22402: Usablity and accessiblity improvement on the Tor assistant page
--+---
 Reporter:  iry   |  Owner:  linda
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #23266| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 > we may host a mirror assistant page on website like Github which is "too
 expensive to block" by a censor.
 > open it in a default browser may be dangerous
 Should Tor launcher display all mirrors then or only one?  If one,
 torproject.org cannot be it because it isn't always safe, so then either
 it always has to be a collateral freedom mirror or Tor Launcher has to
 determine which link to display... which is probably impossible to do
 safely in this case when Tor isn't able to connect, so we're back to a
 collateral freedom mirror.

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

 Also see ticket:16886#comment:8 (short summary: icon48.png is used in the
 branded wizards, e.g., the add-on compatibility check dialog).

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

Re: [tor-bugs] #22402 [Webpages/Website]: Usablity and accessiblity improvement on the Tor assistant page

[Tor Bug Tracker & Wiki]

#22402: Usablity and accessiblity improvement on the Tor assistant page
--+---
 Reporter:  iry   |  Owner:  linda
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #23266| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 The link could instead open a minimal static local copy of the online
 documentation which could be bundled with Tor Browser explicitly for help
 configuring Tor Launcher and listing the same contact information for out-
 of-band support.

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

Re: [tor-bugs] #9186 [Webpages/Website]: Document how to report security vulnerabilities

[Tor Bug Tracker & Wiki]

#9186: Document how to report security vulnerabilities
--+
 Reporter:  lunar |  Owner:  kat5
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Blocker   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by kat5):

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


Comment:

 hiro merged 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] #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 kat5):

 * cc: kat@… (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] #18918 [Core Tor/Tor]: Clarify directory and ORPort checking functions

[Tor Bug Tracker & Wiki]

#18918: Clarify directory and ORPort checking functions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, code, refactor|  Actual Points:
  technical-debt tor-relay   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * points:   => 1
 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


Comment:

 Replying to [comment:9 ffmancera]:
 > I have been reviewing the code these days. I don't think we should
 rename any function but I want to propose some changes in the code
 structure. I will list all the reviewed functions with my notes about
 them.
 >
 >  * `check_whether_orport_reachable()` and
 `check_whether_dirport_reachable()`: I think they are fine, nice
 documentation and names.
 >
 >  * `router_has_bandwidth_to_dirserver()`: Poor documentation, I already
 improved it a bit. Also I think we don't need to check
 `options->BandwidthRate < MIN_BW_TO_ADVERTISE_DIRSERVER` because we are
 checking the same on RelayBandwidthRate.

 Let's rename this to router_has_bandwidth_to_be_dirserver(). "to
 dirserver" is confusing, it could refer to another dirserver.

 See my note below about removing conditions that depend on external code.

 >  * `router_should_be_directory()`: I don't think we need to check
 `advertising != new_choice` and then `new_choice == 1` because we
 initialize both to `1` and within the function only `new_choice` could
 turn into `0`. I already removed this if statement and it works correctly.

 When we remove statements because they are obviously correct, we usually
 insert a tor_assert_nonfatal_once() or if(BUG()) to make sure the
 condition holds. If the condition depends on code outside the function,
 please check it inside the function.

 For consistency, let's rename this to router_should_be_dirserver().

 > * `dir_server_mode()` and `decide_to_advertise_dirport()`: I think they
 are fine, nice documentation and names.

 Let's rename decide_to_advertise_dirport() to
 router_should_advertise_dirport() for consistency.

 > About combine functions, I think we could get
 `router_has_bandwidth_to_be_dirserv` into `router_should_be_directory`.

 If both functions are short, this is ok.
 But if the combined function is longer than a standard terminal window (24
 lines), let's not combine them.

 > Let's decide about do or not these changes and I will work on them :-)

 They sound fine to me. Thanks for working on 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] #18918 [Core Tor/Tor]: Clarify directory and ORPort checking functions

[Tor Bug Tracker & Wiki]

#18918: Clarify directory and ORPort checking functions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, code, refactor|  Actual Points:
  technical-debt tor-relay   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Oh, you left out a few:

 decide_to_advertise_begindir() -> router_should_advertise_begindir()

 consider_testing_reachability():

 Maybe we could split this into a boolean function that doesn't change
 state: router_should_check_reachability().
 And a function that calls that function and changes state:
 router_do_reachability_checks().

 You might also want to check the code and documentation in these
 functions.

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

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 phoul):

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


Comment:

 I somehow missed this part of your email, my apologies.

 Closing.

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

Re: [tor-bugs] #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:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by phoul):

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


Comment:

 After looking at things closer, there appears to be an error in the tb-
 manual-install-alpha job:

 {{{
 20:37:40 Copied 1 artifact from "tb-manual" build number 733
 }}}

 This should be copying from tb-manual-alpha, currently build 4.

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

Re: [tor-bugs] #24975 [Core Tor/Tor]: sched: scheduler_notify_networkstatus_changed() calls select_scheduler() without the new consensus

[Tor Bug Tracker & Wiki]

#24975: sched: scheduler_notify_networkstatus_changed() calls select_scheduler()
without the new consensus
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 I recommend if you want a function that gets called after the new
 consensus is in place (i.e. you don't care about what the old consensus
 used to say), move your call to the bottom of
 {{{networkstatus_set_current_consensus}}}.

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

Re: [tor-bugs] #24981 [Internal Services/Service - trac]: Update trac identity to match styleguide

[Tor Bug Tracker & Wiki]

#24981: Update trac identity to match styleguide
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by hiro):

 * owner:  qbi => hiro
 * status:  new => 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] #24984 [Applications/TorBirdy]: Torbirdy changes SMTP security setting from STARTTLS to SSL/TLS

[Tor Bug Tracker & Wiki]

#24984: Torbirdy changes SMTP security setting from STARTTLS to SSL/TLS
---+-
 Reporter:  markr  |  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 If I set up an SMTP server in thunderbird to use STARTTLS, it works fine
 until I install torbirdy (0.2.3) at which point the setting is changed to
 SSL/TLS. If I manually change it back to STARTTLS it works fine, until I
 disable and re-enable torbirdy, which causes the server security setting
 to switch back to SSL/TLS 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] #24975 [Core Tor/Tor]: sched: scheduler_notify_networkstatus_changed() calls select_scheduler() without the new consensus

[Tor Bug Tracker & Wiki]

#24975: sched: scheduler_notify_networkstatus_changed() calls select_scheduler()
without the new consensus
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Quoting the oniongit comment here for ease of history:
 """
 When this function is called, the consensus ***has not yet changed***. It
 is still old_c. It will be new_c soon. This is your chance to take new
 actions.

 So if you ignore new_c and just call stuff that looks at "the consensus",
 you're going to be looking at the current consensus, i.e. old_c.

 I think this is a bug in 0.3.2 with
 scheduler_notify_networkstatus_changed() too, in that set_scheduler() can
 call select_scheduler() which calls scheduler_can_use_kist() which calls
 kist_scheduler_run_interval(NULL) -- so even though
 kist_scheduler_run_interval knows how to receive an ns as an argument, it
 doesn't get new_c 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] #24159 [Applications/Tor Browser]: The Torbutton version check does not deal properly with platform specific checks

[Tor Bug Tracker & Wiki]

#24159: The Torbutton version check does not deal properly with platform 
specific
checks
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-torbutton,   |  Actual Points:
  TorBrowserTeam201801R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  new => needs_review
 * keywords:  tbb-torbutton, TorBrowserTeam201801 => tbb-torbutton,
 TorBrowserTeam201801R
 * cc: brade, mcs (added)


Comment:

 Here is a fix:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug24159-01&id=f8604998e58fdece9c191661121ada6a3b911499

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

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] #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
 
+G7TRdM/sr48/C/wALt8HfFfi/wn4hsNSOqJ431HwNqWjafaeLNT1C+87w9pc8

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

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

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

[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