Re: [tor-bugs] #10683 [Applications/TorBirdy]: Disabling TorBirdy but not restarting is already disabling the extension

[Tor Bug Tracker & Wiki]

#10683: Disabling TorBirdy but not restarting is already disabling the extension
---+-
 Reporter:  gk |  Owner:  sukhbir
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Blocker| Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by sukhbir):

 * status:  assigned => closed
 * resolution:   => fixed
 * severity:   => Blocker


Comment:

 The UI now reflects the current state and the status bar text changes as
 it should on uninstall/disable/enable. This will be a part of the next
 release. Thanks.

 
[https://gitweb.torproject.org/torbirdy.git/commit/?id=26a0def110411e65f0abad893533a705d30a4424
 26a0def1]

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

Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-+-
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-|Version:  Tor:
  group-1|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  asn, special |  Actual Points:
 | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-
Changes (by special):

 * status:  needs_review => needs_revision


Comment:

 I agree with arma. Any client application that needs this function is
 actually working around a bug in tor. We should make tor smarter to solve
 whatever issues this avoids.

 That said, I'm not opposed to having this function if people have other
 uses for it. I could imagine this being useful for testing and scripts.

 I have some control-spec comments:

 We encourage applications to use this by mentioning unstable internet
 connections as a use case. I would rather not.

 I don't think the `DescCookie` parameter is useful. There is no case as a
 client where we can use a descriptor that requires authorization without
 the cookie being configured (such as via `HidServAuth`). Instead of having
 a cookie parameter, you could look up the cookie using
 `rend_client_lookup_service_authorization`.

 There are also a few code issues, some of which are obsolete after my
 suggestion above, but I'll mention them anyway:

 {{{
  +  char descriptor_cookie_base64ext[REND_DESC_COOKIE_LEN_BASE64 + 2 + 1];
 ...
  +descriptor_cookie_decoded = tor_malloc(REND_DESC_COOKIE_LEN + 2);
 ...
  +/* Add trailing zero bytes (AA) to make base64-decoding happy. */
 }}}

 You could replace all of this logic with the recently-created
 `rend_auth_decode_cookie` function.

 {{{
  +if (base64_decode(descriptor_cookie_decoded,
  +  sizeof(descriptor_cookie_decoded),
 }}}

 `descriptor_cookie_decoded` is `char *`, not a char array, so sizeof is
 incorrect. This can never succeed.

 Also, you don't check the decoded length returned by `base64_decode` and
 `descriptor_cookie_decoded` was allocated with `tor_malloc` instead of
 `tor_malloc_zero`, so you could have ended up reading uninitialized memory
 later.

 {{{
  +  tor_free(onion_address);
  +  if (descriptor_cookie_base64) {
  +tor_free(descriptor_cookie_base64);
  +tor_free(descriptor_cookie_decoded);
  +  }
 }}}

 This block of code is repeated for the success and err cases. You could
 avoid that by having an `int result` to return and falling through the
 `err:` case after calling `send_control_done`.

 {{{
  +/** Remove any cached descriptors for service_id. */
 +void
 +rend_cache_remove_entry(const char *service_id)
 }}}

 This name (and documentation) is misleading. This function only removes
 from the client cache, not the service or directory caches. I would rename
 it to mention clients.

 `make check-spaces` has a few other comments for you.

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

Re: [tor-bugs] #19045 [Core Tor/Tor]: Keep trying to form a new shared random value during the next commit phase

[Tor Bug Tracker & Wiki]

#19045: Keep trying to form a new shared random value during the next commit 
phase
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  029-proposed, 029-nickm-unsure, 029  |Version:
  -teor-yes  | Resolution:
Parent ID:  #16943   |  Actual Points:
 Reviewer:   | Points:  small
 |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_review


Comment:

 Please see my branch srv-try-again on https://github.com/teor2345/tor.git

 If the majority voted for a current SRV, we put that in our state. If
 there is no majority SRV, we keep our idea of the SRV for future votes. If
 we reach the reveal phase without agreeing on a SRV, we give up and stop
 voting for our idea of what the SRV could have been.

 We might decide to stop retrying votes for an SRV part-way through the
 commit phase.
 For example, if clients take up to 3 hours to get a consensus, we should
 stop retrying 3 hours before the start of the overlap period.

 We'll need to be careful to do the right thing on
 `sr_act_post_consensus(NULL)`, but it can't happen 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #17291, #15055, #16943

[Tor Bug Tracker & Wiki]

Batch modification to #17291, #15055, #16943 by isabela:
points to 6

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #18639, #12595, #18363, #16794, #18365, #18616, #16645, #7144, #17262, #14881, #17101, #18809, #17282

[Tor Bug Tracker & Wiki]

Batch modification to #18639, #12595, #18363, #16794, #18365, #18616, #16645, 
#7144, #17262, #14881, #17101, #18809, #17282 by isabela:
points to 3

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #17284, #17280

[Tor Bug Tracker & Wiki]

Batch modification to #17284, #17280 by isabela:
points to 4.5

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #18812, #18930, #8051, #15588, #17983, #13239, #18483, #18749, #18761, #18851, #18920, #18921, #18929, #18962, #7478, #18895, #11966, #18668, #18933

[Tor Bug Tracker & Wiki]

Batch modification to #18812, #18930, #8051, #15588, #17983, #13239, #18483, 
#18749, #18761, #18851, #18920, #18921, #18929, #18962, #7478, #18895, #11966, 
#18668, #18933 by isabela:
points to 1

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #16698, #17799

[Tor Bug Tracker & Wiki]

Batch modification to #16698, #17799 by isabela:
points to 2

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

Re: [tor-bugs] #16943 [Core Tor/Tor]: Implement prop250 (Random Number Generation During Tor Voting)

[Tor Bug Tracker & Wiki]

#16943: Implement prop250 (Random Number Generation During Tor Voting)
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201605  | Resolution:
Parent ID:  #8244  |  Actual Points:
 Reviewer:  nickm  | Points:  large
   |Sponsor:  SponsorR-must
---+---

Comment (by teor):

 Please see my branch sr-commit-fixes on
 https://github.com/teor2345/tor.git

 37655c1 Improve log messages for SR commit lines (T5)
 520e14f Fix a bug in shared random version parsing on 32-bit platforms
 (T6)
 2fd8a21 Consistently use uint32_t for integers in shared random structs
 (T7)
 d6487a3 Silence a clang warning about shared random buffer sizes (T1)
 2fd8a21 Make a shared random log message easier to understand (T3)
 add23bd Move the SR flag to the same place as the other SR ns string
 constants
 3731984 Don't crash authorities when they have 254 or more shared random
 reveals (T8, T7)
 8a84070 Sort commits in lexicographical order in votes (T4)

 T2 was fixed by dgoulet.

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

Re: [tor-bugs] #16943 [Core Tor/Tor]: Implement prop250 (Random Number Generation During Tor Voting)

[Tor Bug Tracker & Wiki]

#16943: Implement prop250 (Random Number Generation During Tor Voting)
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201605  | Resolution:
Parent ID:  #8244  |  Actual Points:
 Reviewer:  nickm  | Points:  large
   |Sponsor:  SponsorR-must
---+---

Comment (by asn):

 Here is some TODO from my meeting notes:

 - Commit `prop250: Only trust known authority when computing SRV` seems to
 reject votes that contain commits by unknown dirauths. This can happen
 naturally in the network. Instead of handling unknonw commits during
 parsing in `extract_shared_random_commits()` maybe we should handle them
 in `should_keep_commit()`.

 - I got this message on my notice level logs:
   {{{[notice] SR: State loaded successfully from file
 /home/user/data_directory/sr-state}}}.
   I think this  message should be demoted to a lesser severity.

 - It would be nice for debugging, to order commits in votes based on
 authority fpr, so that they are all in the same order in different votes.
 If it's too hard, let's not do that.

 - We discussed treating SRVs in votes the same way we treat consensus
 parameters. That is, not needing a real majority, and if at least 3
 dirauths agree on the same SRV on their votes, it is copied on the
 consensus. This is controversial security-wise, so it needs some thinking.

 - Make a state diagram of the SRV protocol for greater understanding. We
 already have one in the bottom of the
 [https://trac.torproject.org/projects/tor/wiki/doc/TorNotes notes page],
 but we might be able to make a better one.

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

Re: [tor-bugs] #18809 [Core Tor/Tor]: Handle linked connections better during bootstrap

[Tor Bug Tracker & Wiki]

#18809: Handle linked connections better during bootstrap
-+-
 Reporter:  teor |  Owner:  arma
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  andrea   |  Actual Points:  medium
 | Points:  medium
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by teor):

 Replying to [comment:24 arma]:
 > Replying to [comment:23 teor]:
 > > Code review:
 >
 > Thanks for the review!
 >
 > > 91c5801 avoid following through on a consensus fetch if we have one
 already arriving
 > > Suffers from a race condition where two connections could attach at
 the same time. But this is unlikely and relatively benign: we'll just
 fetch the consensus twice.
 >
 > Can you elaborate on this one? This part of Tor is single-threaded, so
 they can't attach at the same time. One of them attaches before the other,
 and the first one to win gets immediately moved to state
 AP_CONN_STATE_CONNECT_WAIT as soon as it's chosen, so the second one will
 know that there's already a winner.

 Oops, I always imagine more threads in Tor than what we actually have.

 > > a7665df close other consensus fetches when we get a consensus
 > > There were two race conditions avoided by the previous code:
 > > * the old function closed the connection immediately to avoid wasting
 data. But this meant that if a connection was receiving data or undergoing
 other operations, there could be errors. I think calling
 connection_mark_for_close is better, even if it's less efficient.
 >
 > The trouble is that connection_mark_for_close() just closes the dir conn
 -- not the underlying tls connection, and so it doesn't undo any begin
 cell already sent onto the network. So we can close the consensus request,
 but if it already sent its begin cell, we will still get a consensus
 coming back at us -- we'll just drop all the data cells because we won't
 be expecting it anymore. This behavior is similar to the problem in bug
 #16844.
 >
 > But to be clear, this new function
 connection_dir_close_consensus_fetches() is aiming to find and kill
 directory requests that haven't attached to a circuit yet. There should
 not be any directory requests that are attached to a circuit (i.e.
 fetching a consensus) at this point -- they would have been noticed inside
 91c5801 and stopped there.

 Ok, sounds sensible.

 > > * connections can be initiated after
 connection_dir_list_by_purpose_and_resource() is called. These connections
 are never cleaned up. I think this is fixed by checking when we attach a
 stream in 91c5801.
 >
 > You mean the connection_dir_list_by_purpose_and_resource() call inside
 connection_dir_close_consensus_fetches()? That function is only called
 after we've called networkstatus_set_current_consensus(), so we should
 have a consensus in place. But! What about the case where we got a
 consensus, but we don't have the certs yet for verifying it? Then
 networkstatus_consensus_is_bootstrapping() will return 1, yes? Crappo.
 Does this mean we want to modify
 networkstatus_consensus_is_bootstrapping() so it says no if there is a
 consensus but it's in waiting-for-certs limbo? After all, we don't want to
 start launching more consensus fetches in that situation.

 Yes, I think we'll have to modify this part.

 > > d5a9628 simplify more -- we only call these funcs when bootstrapping
 > > makes sense, but you'd better document that those functions should
 only ever be called when bootstrapping
 >
 > The functions are named update_consensus_bootstrap_multiple_downloads
 and update_consensus_bootstrap_attempt_downloads(), and also their
 function comments start with "When we're bootstrapping, ". Should we do
 more?

 Nope.

 > > 1f72653 fix a bug where relays would use the aggressive client
 bootstrapping retry number
 > > I think the correct fix for this is to check `server_mode(options)` in
 `consensus_max_download_tries()`, and `return
 options->TestingConsensusMaxDownloadTries` if it's true.
 > >
 > > Otherwise, this bug is just waiting to happen again.
 >
 > Hm? I was actually thinking of just removing
 consensus_max_download_tries() entirely, since it is only called from two
 places, and one of the places wants the first clause of the function, and
 the other place wants the 

Re: [tor-bugs] #18809 [Core Tor/Tor]: Handle linked connections better during bootstrap

[Tor Bug Tracker & Wiki]

#18809: Handle linked connections better during bootstrap
-+-
 Reporter:  teor |  Owner:  arma
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  andrea   |  Actual Points:  medium
 | Points:  medium
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by arma):

 Replying to [comment:23 teor]:
 > Code review:

 Thanks for the review!

 > 91c5801 avoid following through on a consensus fetch if we have one
 already arriving
 > Suffers from a race condition where two connections could attach at the
 same time. But this is unlikely and relatively benign: we'll just fetch
 the consensus twice.

 Can you elaborate on this one? This part of Tor is single-threaded, so
 they can't attach at the same time. One of them attaches before the other,
 and the first one to win gets immediately moved to state
 AP_CONN_STATE_CONNECT_WAIT as soon as it's chosen, so the second one will
 know that there's already a winner.

 > a7665df close other consensus fetches when we get a consensus
 > There were two race conditions avoided by the previous code:
 > * the old function closed the connection immediately to avoid wasting
 data. But this meant that if a connection was receiving data or undergoing
 other operations, there could be errors. I think calling
 connection_mark_for_close is better, even if it's less efficient.

 The trouble is that connection_mark_for_close() just closes the dir conn
 -- not the underlying tls connection, and so it doesn't undo any begin
 cell already sent onto the network. So we can close the consensus request,
 but if it already sent its begin cell, we will still get a consensus
 coming back at us -- we'll just drop all the data cells because we won't
 be expecting it anymore. This behavior is similar to the problem in bug
 #16844.

 But to be clear, this new function
 connection_dir_close_consensus_fetches() is aiming to find and kill
 directory requests that haven't attached to a circuit yet. There should
 not be any directory requests that are attached to a circuit (i.e.
 fetching a consensus) at this point -- they would have been noticed inside
 91c5801 and stopped there.

 > * connections can be initiated after
 connection_dir_list_by_purpose_and_resource() is called. These connections
 are never cleaned up. I think this is fixed by checking when we attach a
 stream in 91c5801.

 You mean the connection_dir_list_by_purpose_and_resource() call inside
 connection_dir_close_consensus_fetches()? That function is only called
 after we've called networkstatus_set_current_consensus(), so we should
 have a consensus in place. But! What about the case where we got a
 consensus, but we don't have the certs yet for verifying it? Then
 networkstatus_consensus_is_bootstrapping() will return 1, yes? Crappo.
 Does this mean we want to modify
 networkstatus_consensus_is_bootstrapping() so it says no if there is a
 consensus but it's in waiting-for-certs limbo? After all, we don't want to
 start launching more consensus fetches in that situation.

 > bcae392 avoid another redundant check
 > good, but I wonder if we'll want
 networkstatus_consensus_is_downloading_usable_flavor in future. probably
 not worth keeping it around

 Right, we can bring it back if we want it one day.

 > d5a9628 simplify more -- we only call these funcs when bootstrapping
 > makes sense, but you'd better document that those functions should only
 ever be called when bootstrapping

 The functions are named update_consensus_bootstrap_multiple_downloads and
 update_consensus_bootstrap_attempt_downloads(), and also their function
 comments start with "When we're bootstrapping, ". Should we do more?

 > 1f72653 fix a bug where relays would use the aggressive client
 bootstrapping retry number
 > I think the correct fix for this is to check `server_mode(options)` in
 `consensus_max_download_tries()`, and `return
 options->TestingConsensusMaxDownloadTries` if it's true.
 >
 > Otherwise, this bug is just waiting to happen again.

 Hm? I was actually thinking of just removing
 consensus_max_download_tries() entirely, since it is only called from two
 places, and one of the places wants the first clause of the function, and
 the other place wants the last 

[tor-bugs] #19069 [Core Tor/Tor]: When DisableNetwork is 1 but !circuit_enough_testing_circs(), we can still launch circuits

[Tor Bug Tracker & Wiki]

#19069: When DisableNetwork is 1 but !circuit_enough_testing_circs(), we can 
still
launch circuits
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In consider_testing_reachability(), we check
 {{{
   if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) {
 }}}

 Once #18616 is merged, the first function will return 1 for
 orport_reachable when DisableNetwork is 1, so that bug will go away.

 But it will remain the case that if !circuit_enough_testing_circs(), we
 will proceed to call circuit_launch_by_extend_info(), even when
 DisableNetwork is 1.

 There are four places that call consider_testing_reachability():
 * circuitbuild.c:circuit_send_next_onion_skin()
 * circuituse.c:circuit_testing_opened()
 * main.c:directory_info_has_arrived()
 * main.c:check_for_reachability_bw_callback()

 I think the middle two are safe, since they shouldn't happen while
 DisableNetwork is set.

 I think the first one is iffy, since it's called from a bunch of places so
 I'm not sure, but given the name I hope it doesn't get called during
 DisableNetwork.

 And I think the fourth one is bad news, since it gets called periodically
 and doesn't check DisableNetwork.

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  25
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by arma):

 * status:  needs_review => merge_ready


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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  25
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by arma):

 * 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] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  25
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by arma):

 * owner:  andrea => teor
 * status:  merge_ready => assigned


Comment:

 making the owner (writer of patch) accurate

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  25
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready
 * actualpoints:  20 hours => 25 hours


Comment:

 Replying to [comment:38 arma]:
 > My {{{bug18616-v4}}} branch has some fixes on the changes file, as well
 as some comment fixes, as well as a bit of refactoring to pass
 {{{options}}} around a bit more.
 >
 > If you like these changes, I think we're all set here.

 Looks good, let's get arma's `bug18616-v4` merged to 0.2.8 to fix #12538,
 which is already in 0.2.8.

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by arma):

 My {{{bug18616-v4}}} branch has some fixes on the changes file, as well as
 some comment fixes, as well as a bit of refactoring to pass {{{options}}}
 around a bit more.

 If you like these changes, I think we're all set 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] #19026 [Obfuscation/Snowflake]: Remove local LAN address ICE candidates

[Tor Bug Tracker & Wiki]

#19026: Remove local LAN address ICE candidates
---+-
 Reporter:  dcf|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by dcf):

 The WebRTC working draft touches on this issue:
 https://www.w3.org/TR/2016/WD-webrtc-20160128/#revealing-ip-addresses
   Even without WebRTC, the Web server providing a Web application will
 know the public IP address to which the application is delivered. Setting
 up communications exposes additional information about the browser’s
 network context to the web application, and may include the set of
 (possibly private) IP addresses available to the browser for WebRTC use.
 Some of this information has to be passed to the corresponding party to
 enable the establishment of a communication session.

   Revealing IP addresses can leak location and means of connection; this
 can be sensitive. Depending on the network environment, it can also
 increase the fingerprinting surface and create persistent cross-origin
 state that cannot easily be cleared by the user.

   A connection will always reveal the IP addresses proposed for
 communication to the corresponding party. The application can limit this
 exposure by choosing not to use certain addresses using the settings
 exposed by the [https://www.w3.org/TR/2016/WD-webrtc-20160128/#idl-def-
 RTCIceTransportPolicy RTCIceTransportPolicy] dictionary, and by using
 relays (for instance TURN servers) rather than direct connections between
 participants. One will normally assume that the IP address of TURN servers
 is not sensitive information. These choices can for instance be made by
 the application based on whether the user has indicated consent to start a
 media connection with the other party.

   Mitigating the exposure of IP addresses to the application itself
 requires limiting the IP addresses that can be used, which will impact the
 ability to communicate on the most direct path between endpoints. Browsers
 are encouraged to provide appropriate controls for deciding which IP
 addresses are made available to applications, based on the security
 posture desired by the user. The choice of which addresses to expose is
 controlled by local policy (see [https://datatracker.ietf.org/doc/draft-
 ietf-rtcweb-ip-handling/ RTCWEB-IP-HANDLING] for details).

 The latter link is all about handling IP addresses with respect to
 privacy:
 https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-
 handling/?include_text=1

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

Re: [tor-bugs] #18809 [Core Tor/Tor]: Handle linked connections better during bootstrap

[Tor Bug Tracker & Wiki]

#18809: Handle linked connections better during bootstrap
-+-
 Reporter:  teor |  Owner:  arma
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  andrea   |  Actual Points:  medium
 | Points:  medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Code review:

 ce8266d fix typos/etc before i go nuts on #18809
 function rename only

 91c5801 avoid following through on a consensus fetch if we have one
 already arriving
 Suffers from a race condition where two connections could attach at the
 same time. But this is unlikely and relatively benign: we'll just fetch
 the consensus twice.

 59da060 use the new function here too
 this is refactoring I should have done

 a7665df close other consensus fetches when we get a consensus
 There were two race conditions avoided by the previous code:
 * the old function closed the connection immediately to avoid wasting
 data. But this meant that if a connection was receiving data or undergoing
 other operations, there could be errors. I think calling
 connection_mark_for_close is better, even if it's less efficient.
 * connections can be initiated after
 connection_dir_list_by_purpose_and_resource() is called. These connections
 are never cleaned up. I think this is fixed by checking when we attach a
 stream in 91c5801.

 e230e80 get rid of the scattered checks to cancel a consensus fetch
 these look good, because we catch it in attach now

 bcae392 avoid another redundant check
 good, but I wonder if we'll want
 networkstatus_consensus_is_downloading_usable_flavor in future. probably
 not worth keeping it around

 c98fbd4 remove some more unused code
 probably not worth keeping it around, but I do wonder if we'll want these
 functions

 d5a9628 simplify more -- we only call these funcs when bootstrapping
 makes sense, but you'd better document that those functions should only
 ever be called when bootstrapping

 1f72653 fix a bug where relays would use the aggressive client
 bootstrapping retry number

 I think the correct fix for this is to check `server_mode(options)` in
 `consensus_max_download_tries()`, and `return
 options->TestingConsensusMaxDownloadTries` if it's true.

 Otherwise, this bug is just waiting to happen again.

 aa6341d stop looping once we know what the answer will be
 early exit FTW

 53aaed8 get rid of another no-longer-used function
 looks ok

 507883e rip out the unit tests for the functions i removed
 Please leave the parts of the unit tests that test existing functions, or
 remove those functions if they are unused:
 * connection_dir_list_by_purpose_and_resource
 * connection_dir_count_by_purpose_and_resource

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

Re: [tor-bugs] #18619 [Applications/Tor Browser]: TBB/ESR45 reports "InvalidStateError" in browser console

[Tor Bug Tracker & Wiki]

#18619: TBB/ESR45 reports "InvalidStateError" in browser console
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Normal   |  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605R, |Version:
  tbb-6.0-must   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 Kathy and I think your code is fine and this solution is good as well. It
 does mean that some developer tools state will not be persistent, but at
 least this way it is stored while the devtools are open (and we avoid
 strange errors on the console).

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

Re: [tor-bugs] #18945 [Applications/Tor Browser]: Disable monitoring the connected state of Tor Browser users

[Tor Bug Tracker & Wiki]

#18945: Disable monitoring the connected state of Tor Browser users
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R, | Resolution:
  tbb-6.0-must   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  ff45-esr, TorBrowserTeam201605, tbb-6.0-must => ff45-esr,
 TorBrowserTeam201605R, tbb-6.0-must
 * status:  assigned => needs_review


Comment:

 Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug18945-01=d0dfca5436e051fb897f32db298093533dfe73db

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

Re: [tor-bugs] #18676 [Internal Services/Tor Sysadmin Team]: relocate media.tp.o

[Tor Bug Tracker & Wiki]

#18676: relocate media.tp.o
-+
 Reporter:  arma |  Owner:  tpa
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 moved to listera.

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

Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-+-
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-|Version:  Tor:
  group-1|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  asn, special |  Actual Points:
 | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-

Comment (by arma):

 Taking a step back: is this design the right one to encourage client
 applications to use? Basically you are wanting to disable much of the
 client-side onion caching logic.

 Is there a better design, like noticing when your network connection has
 been broken, and flushing all the client-side state right then, and
 otherwise letting Tor do its thing?

 Or better, we could improve the client-side caching logic to be more
 robust to whatever network behavior you're seeing? It is silly for each
 client application to have to do this logic itself.

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

Re: [tor-bugs] #18855 [Applications/Tor Browser]: Add-on directory clean-up error after update check

[Tor Bug Tracker & Wiki]

#18855: Add-on directory clean-up error after update check
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R, | Resolution:
  tbb-6.0-must   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  ff45-esr, TorBrowserTeam201605, tbb-6.0-must => ff45-esr,
 TorBrowserTeam201605R, tbb-6.0-must
 * status:  assigned => needs_review


Comment:

 A backported patch is available here:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug18855-01=ecf19e655e6f6b94c311f3c69e56fea31bdb4185

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by teor):

 "0.2.8.1-alpha bridges were not advertising begindir support", but:
 * entry_guard_set_status() has a specific bridge check
 * bridge check in add_an_entry_guard
 * no bridge check in router_pick_directory_server_impl, but it's made up
 for by a second check in add_an_entry_guard

 To summarise #18616, the missing bridge begindir support was a bug waiting
 to happen, compensated for by conditionals scattered through the code

 And the other missing checks could have caused subtle bugs too

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

Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-+-
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-|Version:  Tor:
  group-1|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  asn, special |  Actual Points:
 | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-
Changes (by special):

 * cc: special (added)
 * reviewer:  asn => asn, special


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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by arma):

 Here are further hints from teor about what's going on in this patch:
 {{{
  no, I mean we have the wrong checks
  the check used to be ri->supports_tunnelled_dir_requests =
 dir_server_mode(options) && router_should_be_directory_server(options,
 ri->dir_port);
  now it's directory_permits_begindir_requests(), which is
 options->BridgeRelay != 0 || dir_server_mode(options)
  that fixes a bridge issue with advertising begindir support
  then we also replace router->supports_tunnelled_dir_requests with
 decide_to_advertise_begindir(options,
 router->supports_tunnelled_dir_requests)
  which fixes a whole heap of checks that were being done for
 DirPorts,
 but not for begindir
 }}}

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Old description:

> This ticket makes sure the checks that Tor does when advertising begindir
> support are similar to the checks it does when advertising the DirPort.
>
> In particular:
> * bridges should advertise begindir support
> * authorities should always advertise begindir
> * we should never advertise begindir if the network is disabled
> * we should never advertise begindir if we don't have an ORPort
> (redundant, as we don't post descriptors without an ORPort)
> * relays should handle AccountingMax like they do for DirPort
>
> These log messages are likely unrelated to this issue:
>
> ~~This pre-0.2.8.2-alpha spews every 5-6 sec a warning (never observed
> before). Furthermore the Bug: poped up (64 bit hardened Gentoo Linux)
> {{{
> Mar 23 18:21:51.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:21:59.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:22:03.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:22:09.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:22:14.000 [warn] router_picked_poor_directory_log(): Bug:
> Firewall denied all OR and Dir addresses for all relays when searching
> for a directory. (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: Node search initiated by. Stack trace:
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x11e255)
> [0x55ee9e0255] (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x624c0) [0x55ee9244c0]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x62843) [0x55ee924843]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0xebb2a) [0x55ee9adb2a]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x61f75) [0x55ee923f75]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x6a0dc) [0x55ee92c0dc]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x1720d) [0x55ee8d920d]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x3208c) [0x55ee8f408c]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug:
> /usr/lib64/libevent-2.0.so.5(event_base_loop+0x7f0) [0x3728572d830] (on
> Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x1b585) [0x55ee8dd585]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x1ec05) [0x55ee8e0c05]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x16b6b) [0x55ee8d8b6b]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug:
> /lib64/libc.so.6(__libc_start_main+0x114) [0x3728443c9e4] (on Tor 0.2.8.1
> -alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x16bb9) [0x55ee8d8bb9]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] router info incompatible with extra info (ri
> id: 06E729BFD466279D4FCA6884DFCD9ACD64F0689A, ei id
> 06E729BFD466279D4FCA6884DFCD9ACD64F0689A, reason: Extrainfo digest did
> not match digest256 from routerdesc)
> Mar 23 18:22:14.000 [warn] router info incompatible with extra info (ri
> id: 3A1BA3B0813E1FD11833C9F430F3507662A58F43, ei id
> 3A1BA3B0813E1FD11833C9F430F3507662A58F43, reason: Extrainfo digest did
> not match digest256 from routerdesc)
> Mar 23 18:22:14.000 [warn] router info incompatible with extra info (ri
> id: D7563D50A4302B7DB3D6038637AD574E2A398D7E, ei id
> D7563D50A4302B7DB3D6038637AD574E2A398D7E, reason: Extrainfo digest
> }}}

New description:

 This 

Re: [tor-bugs] #18619 [Applications/Tor Browser]: TBB/ESR45 reports "InvalidStateError" in browser console

[Tor Bug Tracker & Wiki]

#18619: TBB/ESR45 reports "InvalidStateError" in browser console
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Normal   |  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605R, |Version:
  tbb-6.0-must   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:6 arthuredelstein]:

 > This seems to correctly the browser console input history during a
 browser session. It also appears to eliminate the InvalidStateErrors both
 as a result of browser startup, entering things in the browser console, or
 using Inspect Element.

 Also, I ran the test
 `./mach mochitest devtools/shared/tests/browser/browser_async_storage.js`
 with "dom.indexedDB.enabled" set to false, and all the tests pass.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #18546, #18884, #16285, #18597, #18619, #18811, #18855, #18885, #18886, #18904, #18912, #18944, #18945, #18950, #19047, #19065

[Tor Bug Tracker & Wiki]

Batch modification to #18546, #18884, #16285, #18597, #18619, #18811, #18855, 
#18885, #18886, #18904, #18912, #18944, #18945, #18950, #19047, #19065 by gk:
keywords to tbb-6.0-must

--
Tickets URL: 

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Make begindir advertise checks consistent with DirPort checks (was: Relay fails to self-test its DirPort with AccountingMax enabled)

[Tor Bug Tracker & Wiki]

#18616: Make begindir advertise checks consistent with DirPort checks
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Old description:

> This pre-0.2.8.2-alpha spews every 5-6 sec a warning (never observed
> before). Furthermore the Bug: poped up (64 bit hardened Gentoo Linux)
> {{{
> Mar 23 18:21:51.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:21:59.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:22:03.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:22:09.000 [warn] We just marked ourself as down. Are your
> external addresses reachable?
> Mar 23 18:22:14.000 [warn] router_picked_poor_directory_log(): Bug:
> Firewall denied all OR and Dir addresses for all relays when searching
> for a directory. (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: Node search initiated by. Stack trace:
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x11e255)
> [0x55ee9e0255] (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x624c0) [0x55ee9244c0]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x62843) [0x55ee924843]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0xebb2a) [0x55ee9adb2a]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x61f75) [0x55ee923f75]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x6a0dc) [0x55ee92c0dc]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x1720d) [0x55ee8d920d]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x3208c) [0x55ee8f408c]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug:
> /usr/lib64/libevent-2.0.so.5(event_base_loop+0x7f0) [0x3728572d830] (on
> Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x1b585) [0x55ee8dd585]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x1ec05) [0x55ee8e0c05]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x16b6b) [0x55ee8d8b6b]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug:
> /lib64/libc.so.6(__libc_start_main+0x114) [0x3728443c9e4] (on Tor 0.2.8.1
> -alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] Bug: /usr/bin/tor(+0x16bb9) [0x55ee8d8bb9]
> (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)
> Mar 23 18:22:14.000 [warn] router info incompatible with extra info (ri
> id: 06E729BFD466279D4FCA6884DFCD9ACD64F0689A, ei id
> 06E729BFD466279D4FCA6884DFCD9ACD64F0689A, reason: Extrainfo digest did
> not match digest256 from routerdesc)
> Mar 23 18:22:14.000 [warn] router info incompatible with extra info (ri
> id: 3A1BA3B0813E1FD11833C9F430F3507662A58F43, ei id
> 3A1BA3B0813E1FD11833C9F430F3507662A58F43, reason: Extrainfo digest did
> not match digest256 from routerdesc)
> Mar 23 18:22:14.000 [warn] router info incompatible with extra info (ri
> id: D7563D50A4302B7DB3D6038637AD574E2A398D7E, ei id
> D7563D50A4302B7DB3D6038637AD574E2A398D7E, reason: Extrainfo digest
> }}}

New description:

 This ticket makes sure the checks that Tor does when advertising begindir
 support are similar to the checks it does when advertising the DirPort.

 In particular:
 * bridges should advertise begindir support
 * authorities should always advertise begindir
 * we should never advertise begindir if the network is disabled
 * we should never advertise begindir if we don't have an ORPort
 (redundant, as we don't post descriptors without an ORPort)
 * relays should handle AccountingMax like they do for DirPort

 These log messages are likely unrelated to this issue:

 ~~This 

Re: [tor-bugs] #18619 [Applications/Tor Browser]: TBB/ESR45 reports "InvalidStateError" in browser console

[Tor Bug Tracker & Wiki]

#18619: TBB/ESR45 reports "InvalidStateError" in browser console
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:5 mcs]:
 > Replying to [comment:4 arthuredelstein]:
 > > Here's a patch that attempts to fix the problem.
 > >
 > > https://github.com/arthuredelstein/tor-browser/commit/18619+1
 > > Hash 96e76624a5e354bb059782dbe1fdeb5f8345af4e
 >
 > With this patch, an InvalidState error is no longer logged during
 browser startup. We still see one when we open the developer tools
 (Inspect Element). I don't know how difficult it would be to patch the
 underlying devtools/shared/async-storage.js code to avoid using IndexedDB
 when it has been disabled.

 Thanks for the review. That's a good suggestion. I wrote an in-memory
 implementation that is supposed to match the indexeedDB-based version:

 https://github.com/arthuredelstein/tor-browser/commit/18619+2
 Hash b875e25aade0323c85915e0c09eadaf44151524f

 This seems to correctly the browser console input history during a browser
 session. It also appears to eliminate the InvalidStateErrors both as a
 result of browser startup, entering things in the browser console, or
 using Inspect Element.

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

Re: [tor-bugs] #18945 [Applications/Tor Browser]: Disable monitoring the connected state of Tor Browser users

[Tor Bug Tracker & Wiki]

#18945: Disable monitoring the connected state of Tor Browser users
+--
 Reporter:  gk  |  Owner:  mcs
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201605  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * owner:  tbb-team => mcs
 * 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

Re: [tor-bugs] #18855 [Applications/Tor Browser]: Add-on directory clean-up error after update check

[Tor Bug Tracker & Wiki]

#18855: Add-on directory clean-up error after update check
+--
 Reporter:  gk  |  Owner:  mcs
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201605  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * status:  new => assigned
 * owner:  tbb-team => mcs


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19068 [Core Tor]: Write and run a clique reachability test.

[Tor Bug Tracker & Wiki]

#19068: Write and run a clique reachability test.
--+--
 Reporter:  yawning   |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  stem, tooling
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 It would be useful to know what the full inter-relay connectivity graph
 looks like, and how far it differs from the "every relay can always reach
 every other relay" ideal.

 https://www.sba-research.org/wp-
 content/uploads/publications/NavigaTor_preprint.pdf

 This should be something doable with stem, and ideally we can run it
 periodically/automatically, and use it to do things like reject relays
 that have extremely poor connectivity.

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

Re: [tor-bugs] #18668 [Core Tor/Tor]: Numerous WSAStartup warnings in unit tests on windows

[Tor Bug Tracker & Wiki]

#18668: Numerous WSAStartup warnings in unit tests on windows
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Minor|  0.2.9.x-final
 Keywords:  tor-tests-coverage, tor-tests-unit,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:   |  Actual Points:  0.1
 Reviewer:   | Points:  small
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * actualpoints:   => 0.1


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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

[Tor Bug Tracker & Wiki]

#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by teor):

 Yes, if a relay operator sets DisableNetwork while the user updates the
 config, we shouldn't be testing ORPort reachability. I think it was still
 possible to do 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] #18668 [Core Tor/Tor]: Numerous WSAStartup warnings in unit tests on windows

[Tor Bug Tracker & Wiki]

#18668: Numerous WSAStartup warnings in unit tests on windows
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Minor|  0.2.9.x-final
 Keywords:  tor-tests-coverage, tor-tests-unit,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  small
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Oh wait, that's pretty easy.

 bug18668_028 has the fix here.  I vote "no backport" but I guess we could.

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

Re: [tor-bugs] #18972 [Internal Services/Tor Sysadmin Team]: Refresh Colin's OpenPGP subkeys

[Tor Bug Tracker & Wiki]

#18972: Refresh Colin's OpenPGP subkeys
-+
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #19002 [Internal Services/Tor Sysadmin Team]: IRC bouncer on iranicum

[Tor Bug Tracker & Wiki]

#19002: IRC bouncer on iranicum
-+-
 Reporter:  mrphs|  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 I don't want to run a bouncer service with the tor-admin hat on.  If you
 (or somebody else) wants to, we can probably make something happen
 however.

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

Re: [tor-bugs] #19065 [Applications/Tor Browser]: Tor Browser icon not visible anymore in upper left corner on Linux since 05/13

[Tor Bug Tracker & Wiki]

#19065: Tor Browser icon not visible anymore in upper left corner on Linux since
05/13
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605,  | Resolution:
  tbb-regression |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201605, tbb-regression => ff45-esr,
 TorBrowserTeam201605, tbb-regression
 * owner:  tbb-team => gk
 * 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

Re: [tor-bugs] #19065 [Applications/Tor Browser]: Tor Browser icon not visible anymore in upper left corner on Linux since 05/13

[Tor Bug Tracker & Wiki]

#19065: Tor Browser icon not visible anymore in upper left corner on Linux since
05/13
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 Priority:  Medium   |  assigned
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605,  | Resolution:
  tbb-regression, GeorgKoppen201605  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff45-esr, TorBrowserTeam201605, tbb-regression => ff45-esr,
 TorBrowserTeam201605, tbb-regression, GeorgKoppen201605


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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

[Tor Bug Tracker & Wiki]

#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:31 arma]:
 > Ok, I looked at {{{bug18616-v3-squashed}}}. Looks good to me.
 >
 > I have a further cleanup patch on my side that I'm still working on. But
 I realized I'm confused about what's actually being fixed here.
 >
 > Here's my in-progress new changes file:
 > {{{
 >   o Major bugfixes (directory mirrors):
 > - Fix broken DirPort self-checks. Decide to advertise begindir
 >   support the same way we decide to advertise DirPorts.
 >   Resolves bug 18616; bugfix on 0.2.8.1-alpha. Patch by teor.
 >
 >   o Minor bugfixes:
 > - Add additional config options that might change the content of
 >   a relay's descriptor. Fixes more of bug 12538; bugfix on
 0.2.8.1-alpha.
 > - Avoid checking ORPort reachability when the network is disabled.
 > }}}
 >
 > For the first entry, what exactly was broken about them? I think that's
 this ticket. What was the actual bug?

 DirPort self-checks were failing with error messages. They also weren't
 being scheduled and checked correctly. We fixed some of it in #18632, this
 is the cleanup / remainder.

 >
 > And then for the last entry, was that something that could happen to
 users in practice?

 Yes, if they did a HUP after changing any of those options, it would be 18
 hours before they were reflected in the descriptor. This would be a
 problem if they added a quota and wanted the DirPort to stop working soon.

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

Re: [tor-bugs] #18811 [Applications/Tor Browser]: Our first-party isolation patch incorrectly rejects blobs retrieved in workers

[Tor Bug Tracker & Wiki]

#18811: Our first-party isolation patch incorrectly rejects blobs retrieved in
workers
+--
 Reporter:  arthuredelstein |  Owner:
 Type:  defect  |  arthuredelstein
 Priority:  Medium  | Status:  assigned
Component:  Applications/Tor Browser|  Milestone:
 Severity:  Normal  |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--
Changes (by gk):

 * status:  new => assigned
 * owner:  tbb-team => arthuredelstein


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

Re: [tor-bugs] #19012 [Core Tor/Tor]: Refactor code that looks at voted-on parameters during voting

[Tor Bug Tracker & Wiki]

#19012: Refactor code that looks at voted-on parameters during voting
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:
 Priority:  Medium|  needs_review
Component:  Core Tor/Tor  |  Milestone:
 Severity:  Normal|Version:
 Keywords:  029-proposed, 029-nickm-says-yes  | Resolution:
Parent ID:  #16943|  Actual Points:  0
 Reviewer:| Points:  0.1
  |Sponsor:
--+
Changes (by teor):

 * parent:   => #16943


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

Re: [tor-bugs] #19047 [Applications/Tor Browser]: Disable Heartbeat prompts in Tor Browser

[Tor Bug Tracker & Wiki]

#19047: Disable Heartbeat prompts in Tor Browser
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201605  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (added)


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

[tor-bugs] #19067 [Applications/Quality Assurance and Testing]: Create a testsuite bundle to provide an easy way for users to run the test suite

[Tor Bug Tracker & Wiki]

#19067: Create a testsuite bundle to provide an easy way for users to run the 
test
suite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance   |Version:
  and Testing|   Keywords:
 Severity:  Normal   |  TorBrowserTeam201605
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should create a bundle containing the Tor Browser testsuite and all its
 dependencies, to allow users to easily run it to test Tor Browser, on all
 supported platforms.

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

Re: [tor-bugs] #19067 [Applications/Quality Assurance and Testing]: Create a testsuite bundle to provide an easy way for users to run the test suite

[Tor Bug Tracker & Wiki]

#19067: Create a testsuite bundle to provide an easy way for users to run the 
test
suite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing| Resolution:
 Severity:  Normal   |  Actual Points:
 Keywords:  TorBrowserTeam201605 | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by boklm):

 * type:  defect => 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

Re: [tor-bugs] #18855 [Applications/Tor Browser]: Add-on directory clean-up error after update check

[Tor Bug Tracker & Wiki]

#18855: Add-on directory clean-up error after update check
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201605  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Yes, that would lead to less confusion and should not cause any new
 issues.

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

Re: [tor-bugs] #17325 [Applications/Quality Assurance and Testing]: In Tor Browser test suite, use strace to monitor files and network activity during tests

[Tor Bug Tracker & Wiki]

#17325: In Tor Browser test suite, use strace to monitor files and network 
activity
during tests
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing| Resolution:  fixed
 Severity:  Normal   |  Actual Points:
 Keywords:  TorBrowserTeam201601 | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by boklm):

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


Comment:

 This is fixed in commit c420eade8b0b2713530b55c6b38b2e5fb63a9783.

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

Re: [tor-bugs] #19012 [Core Tor/Tor]: Refactor code that looks at voted-on parameters during voting

[Tor Bug Tracker & Wiki]

#19012: Refactor code that looks at voted-on parameters during voting
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:
 Priority:  Medium|  needs_review
Component:  Core Tor/Tor  |  Milestone:
 Severity:  Normal|Version:
 Keywords:  029-proposed, 029-nickm-says-yes  | Resolution:
Parent ID:|  Actual Points:  0
 Reviewer:| Points:  0.1
  |Sponsor:
--+
Changes (by nickm):

 * points:  0 => 0.1


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

Re: [tor-bugs] #18961 [Core Tor/Tor]: tor_bug_occurred_(): Bug: ../src/or/dnsserv.c:298

[Tor Bug Tracker & Wiki]

#18961: tor_bug_occurred_(): Bug: ../src/or/dnsserv.c:298
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  029-proposed, dnsserv, 029-nickm-|  Actual Points:
  says-yes   | Points:  1
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by nickm):

 * points:   => 1


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

Re: [tor-bugs] #19044 [Core Tor/Tor]: Turn on --enable-gcc-warnings-advisory by default

[Tor Bug Tracker & Wiki]

#19044: Turn on --enable-gcc-warnings-advisory by default
-+-
 Reporter:  special  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.9.x-final
 Severity:  Minor|Version:
 Keywords:  029-proposed, TorCoreTeam201605, | Resolution:
  029-nickm-says-yes |  Actual Points:
Parent ID:   | Points:  0.05
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * points:   => 0.05


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

Re: [tor-bugs] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:
 Priority:  Medium|  needs_review
Component:  Core Tor/Tor  |  Milestone:  Tor:
 Severity:  Normal|  0.2.???
 Keywords:  029-proposed, 029-nickm-says-yes  |Version:
Parent ID:| Resolution:
 Reviewer:  dgoulet   |  Actual Points:
  | Points:  0.1
  |  remaining
  |Sponsor:
--+
Changes (by nickm):

 * points:   => 0.1 remaining


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

Re: [tor-bugs] #19036 [Core Tor/Tor]: Write v3-status-votes file even when we fail to make a consensus

[Tor Bug Tracker & Wiki]

#19036: Write v3-status-votes file even when we fail to make a consensus
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:
 Priority:  Medium|  merge_ready
Component:  Core Tor/Tor  |  Milestone:  Tor:
 Severity:  Normal|  0.2.???
 Keywords:  029-proposed, 029-nickm-says-yes  |Version:
Parent ID:| Resolution:
 Reviewer:  sysrqb dgoulet|  Actual Points:
  | Points:  0.1
  |  remaining
  |Sponsor:
--+
Changes (by nickm):

 * points:   => 0.1 remaining


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

Re: [tor-bugs] #19028 [Core Tor/Tor]: Merge the header checks in configure.ac

[Tor Bug Tracker & Wiki]

#19028: Merge the header checks in configure.ac
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:
 Priority:  Medium|  needs_review
Component:  Core Tor/Tor  |  Milestone:  Tor:
 Severity:  Normal|  0.2.???
 Keywords:  029-proposed, 029-nickm-says-yes  |Version:  Tor:
Parent ID:|  0.2.8.1-alpha
 Reviewer:| Resolution:
  |  Actual Points:
  | Points:  0.2
  |  remaining
  |Sponsor:
--+
Changes (by nickm):

 * points:   => 0.2 remaining


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

Re: [tor-bugs] #11966 [Core Tor/Tor]: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users

[Tor Bug Tracker & Wiki]

#11966: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for 
bridge
users
---+---
 Reporter:  arma   |  Owner:  isis
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.8.x-final
 Severity:  Normal |Version:
 Keywords:  tor-bridge, TorCoreTeam201605  | Resolution:
Parent ID: |  Actual Points:
 Reviewer:  arma   | Points:  small
   |Sponsor:
---+---
Changes (by arma):

 * reviewer:   => arma


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

Re: [tor-bugs] #19020 [Core Tor/Tor]: RSA cross-certification of ed25519 keys differs from spec

[Tor Bug Tracker & Wiki]

#19020: RSA cross-certification of ed25519 keys differs from spec
-+-
 Reporter:  special  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.9.x-final
 Severity:  Normal   |Version:
 Keywords:  prop-220, tor-ed25519-proto  | Resolution:
Parent ID:  #15055   |  Actual Points:
 Reviewer:   | Points:  0.5
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:  prop-220, tor-ed25519-proto, 029-proposed, 029-nickm-says-yes
 => prop-220, tor-ed25519-proto
 * points:   => 0.5
 * parent:   => #15055


Comment:

 Calling this "in" for 029 since it's part of #15055, which is in.

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

Re: [tor-bugs] #18667 [Core Tor/Tor]: Manual on website doesn't render ipv6 addresses right

[Tor Bug Tracker & Wiki]

#18667: Manual on website doesn't render ipv6 addresses right
+--
 Reporter:  Sebastian   |  Owner:  Sebastian
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  029-proposed, 029-nickm-unsure  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * points:   => 0.5


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

Re: [tor-bugs] #18855 [Applications/Tor Browser]: Add-on directory clean-up error after update check

[Tor Bug Tracker & Wiki]

#18855: Add-on directory clean-up error after update check
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201605  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 After some debugging, Kathy and I found that this occurs because the code
 tries to iterate over the contents of a directory that does not exist. An
 existence check was added for Firefox 47. See:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1246614

 Should we backport the fix? It is trivial:
 https://hg.mozilla.org/mozilla-central/rev/49cd9160c34b

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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

[Tor Bug Tracker & Wiki]

#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-

Comment (by arma):

 Ok, I looked at {{{bug18616-v3-squashed}}}. Looks good to me.

 I have a further cleanup patch on my side that I'm still working on. But I
 realized I'm confused about what's actually being fixed here.

 Here's my in-progress new changes file:
 {{{
   o Major bugfixes (directory mirrors):
 - Fix broken DirPort self-checks. Decide to advertise begindir
   support the same way we decide to advertise DirPorts.
   Resolves bug 18616; bugfix on 0.2.8.1-alpha. Patch by teor.

   o Minor bugfixes:
 - Add additional config options that might change the content of
   a relay's descriptor. Fixes more of bug 12538; bugfix on
 0.2.8.1-alpha.
 - Avoid checking ORPort reachability when the network is disabled.
 }}}

 For the first entry, what exactly was broken about them? I think that's
 this ticket. What was the actual bug?

 And then for the last entry, was that something that could happen to users
 in practice?

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

Re: [tor-bugs] #18656 [Core Tor/Tor]: Relay publishing malformed 'dirreq-v3-reqs' line

[Tor Bug Tracker & Wiki]

#18656: Relay publishing malformed 'dirreq-v3-reqs' line
-+-
 Reporter:  atagar   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_information
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  memory-corruption,   |Version:  Tor:
  TorCoreTeam201605, 029-nickm-unsure|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:
 |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_information
 * keywords:  029-proposed, memory-corruption, TorCoreTeam201605, 029-nickm-
 unsure => memory-corruption, TorCoreTeam201605, 029-nickm-unsure


Comment:

 Yanking this out of 029-proposed.  I think #18938 is worth thinking about,
 but tracking down the corruption here will be needs_information for 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] #18982 [Core Tor/Tor]: Tor should log 1-based hop numbers

[Tor Bug Tracker & Wiki]

#18982: Tor should log 1-based hop numbers
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Low  |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Minor|  0.2.???
 Keywords:  easy, logging, 029-proposed, 029 |Version:  Tor:
  -nickm-says-yes|  0.2.4.5-alpha
Parent ID:   | Resolution:
 Reviewer:  arma |  Actual Points:  1 hour
 | Points:  small
 |Sponsor:
-+-
Changes (by arma):

 * reviewer:   => arma


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

Re: [tor-bugs] #18845 [Applications/Tor Browser]: Make zip and tar helpers generate reproducible archives without relying on libfaketime

[Tor Bug Tracker & Wiki]

#18845: Make zip and tar helpers generate reproducible archives without relying 
on
libfaketime
---+---
 Reporter:  boklm  |  Owner:  boklm
 Type:  enhancement| Status:
 Priority:  Medium |  needs_review
Component:  Applications/Tor Browser   |  Milestone:
 Severity:  Normal |Version:
 Keywords:  tbb-gitian, TorBrowserTeam201605R  | Resolution:
Parent ID: |  Actual Points:
 Reviewer: | Points:
   |Sponsor:
---+---
Changes (by boklm):

 * status:  new => needs_review
 * keywords:  tbb-gitian, TorBrowserTeam201605 => tbb-gitian,
 TorBrowserTeam201605R


Comment:

 I attached a patch to do that. I tried a build of tbb-6.0a5-build4 with
 this patch, and it did not modify the result of the build.

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

Re: [tor-bugs] #18668 [Core Tor/Tor]: Numerous WSAStartup warnings in unit tests on windows

[Tor Bug Tracker & Wiki]

#18668: Numerous WSAStartup warnings in unit tests on windows
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  accepted
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Minor|  0.2.9.x-final
 Keywords:  tor-tests-coverage, tor-tests-unit,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  small
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 Semi-canonical example:

 https://jenkins.torproject.org/job/tor-ci-mingwcross-0.2.8-test-
 native/15/console
 https://jenkins.torproject.org/job/tor-ci-mingwcross-master-test-
 native/27/console

 Specifically:

 {{{
 13:00:48 + RESULT/bin/test
 13:00:50 onion_handshake: OK
 13:00:50 bad_onion_handshake: OK
 13:00:50 onion_queues: OK
 13:00:50 ntor_handshake: OK
 13:00:50 circuit_timeout: [forking] [warn] evsig_init: socketpair:
 Successful WSAStartup not yet performed [WSANOTINITIALISED ]
 13:00:51 OK
 13:00:51 rend_fns: [forking] [warn] evsig_init: socketpair: Successful
 WSAStartup not yet performed [WSANOTINITIALISED ]
 13:00:51 OK
  ...
 }}}

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

Re: [tor-bugs] #18886 [Applications/Tor Browser]: consider removing Pocket

[Tor Bug Tracker & Wiki]

#18886: consider removing Pocket
+--
 Reporter:  mcs |  Owner:
 Type:  defect  |  arthuredelstein
 Priority:  Medium  | Status:  needs_review
Component:  Applications/Tor Browser|  Milestone:
 Severity:  Normal  |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--
Changes (by arthuredelstein):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:15 gk]:
 > Neat idea and I guess Mozilla would even be amenable to take that patch.
 However, that still does not seem enough. I stumbled over another Pocket
 button while looking at the Reader functionality (see:
 https://mxr.mozilla.org/mozilla-
 esr45/source/browser/modules/ReaderParent.jsm#81). There are even more
 instances of `CustomizableUI.getPlacementOfWidget("pocket-button")` we
 might want to take care of when upstreaming (even though I did not figure
 out how to get a related Pocket button shown in Tor Browser for these
 cases).

 Thanks for pointing these out. Here is a new version that takes care of
 the pocket button in Reader Mode and also the unlikely event of Pocket
 items in the context menu.

 https://github.com/arthuredelstein/tor-browser/commit/18886+4
 Hash c3fc62020f4b12aaa633d5760ea77999a97c5f11

 I haven't modified the UITour code as we are already suppressing the
 UITour itself.

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

Re: [tor-bugs] #19007 [User Experience/Website]: Create job posting for core OONI developer

[Tor Bug Tracker & Wiki]

#19007: Create job posting for core OONI developer
-+
 Reporter:  hellais  |  Owner:  Sebastian
 Type:  task | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 I just updated the post with a new last paragraph, and also a contact
 address that's specific to this job opening.

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

Re: [tor-bugs] #19039 [Applications/Quality Assurance and Testing]: Test User Timing API in a worker context

[Tor Bug Tracker & Wiki]

#19039: Test User Timing API in a worker context
-+-
 Reporter:  gk   |  Owner:
 Type:  enhancement  |  cypherpunks
 Priority:  Medium   | Status:  closed
Component:  Applications/Quality Assurance and   |  Milestone:
  Testing|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #18597   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 This is fixed in commit 91f5e2b86900eb4d0a8b11aa2f0c14bc7bb45a3e, adding a
 user-timing-worker test.

 The test fails if we enable `dom.enable_user_timing` (as expected).

 The following page is used in the test:
 https://test-data.tbb.torproject.org/user-timing-worker.html

 It will display `OK` if both `performance.measure()` and
 `performance.mark()` called in worker context caused an exception, or `NOT
 OK` otherwise.

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

Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-+-
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-|Version:  Tor:
  group-1|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  asn  |  Actual Points:
 | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 Putting this back in `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] #18904 [Obfuscation/meek]: Mac OS: meek-http-helper profile not updated

[Tor Bug Tracker & Wiki]

#18904: Mac OS: meek-http-helper profile not updated
+--
 Reporter:  mcs |  Owner:  mcs
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Obfuscation/meek|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201605  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by dcf):

 Replying to [comment:9 gk]:
 > The tor-browser-bundle one looks good to me and is applied to master
 (495885feb51d7f1faf6d4c0dc3dd8f47e9f1caa7). dcf could you review the meek
 part and create a new tag we can use?

 Yes but probably not until tomorrow.

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

Re: [tor-bugs] #18823 [Core Tor/Tor]: Sanity check on the fallback dir torrc values

[Tor Bug Tracker & Wiki]

#18823: Sanity check on the fallback dir torrc values
-+-
 Reporter:  dgoulet  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor:
 Severity:  Normal   |  0.2.8.2-alpha
 Keywords:  029-proposed, 029-nickm-says-no, | Resolution:
  029-teor-unsure, easy  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  029-proposed, 029-nickm-unsure, 029-teor-unsure, easy =>
 029-proposed, 029-nickm-says-no, 029-teor-unsure, easy


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

Re: [tor-bugs] #14013 [Core Tor/Tor]: base16_decode() API is inconsistent and error-prone

[Tor Bug Tracker & Wiki]

#14013: base16_decode() API is inconsistent and error-prone
---+
 Reporter:  nickm  |  Owner:  nikkolasg
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  lorax, review-group-1  |  Actual Points:
Parent ID: | Points:  small
 Reviewer:  dgoulet|Sponsor:  SponsorS-can
---+

Comment (by nikkolasg):

 I get it, no worry, I'm just not used yet to your formatting :)
 I'll fix those and submit a new patch, maybe not *quickly* because I've
 just found some unchanged calls to base16_decode that I need to fix also
 (still some `base16_decode(..) == 0`).
 Thanks for the review anyway. I'll get back to you soon.

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

Re: [tor-bugs] #19066 [Core Tor/Tor]: Wrong length used in networkstatus_parse_detached_signatures

[Tor Bug Tracker & Wiki]

#19066: Wrong length used in networkstatus_parse_detached_signatures
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 See branch for a potential fix. Test passes.

 `bug19066_029_01`

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

Re: [tor-bugs] #18823 [Core Tor/Tor]: Sanity check on the fallback dir torrc values

[Tor Bug Tracker & Wiki]

#18823: Sanity check on the fallback dir torrc values
-+-
 Reporter:  dgoulet  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor:
 Severity:  Normal   |  0.2.8.2-alpha
 Keywords:  029-proposed, 029-nickm-unsure, 029  | Resolution:
  -teor-unsure, easy |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  029-proposed, 029-nickm-unsure => 029-proposed, 029-nickm-
 unsure, 029-teor-unsure, easy


Comment:

 Replying to [comment:1 nickm]:
 > What's the impact of doing/not-doing this?

 In rare cases, users can accidentally enter download schedule values that
 make their tor make rapid connections to fallbacks or authorities.
 (That said, this may already be true of the existing config options.)

 It's far more likely that users will break their tor if they modify these
 options.
 We have lots of these kind of config options already, and our standard
 response is "then don't do 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] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed, review-group-1, 029-nickm-   |  0.2.8.1-alpha
  unsure, 029-teor-yes, 028-teor-unsure  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:  arma | Points:  small
 |Sponsor:
-+-
Changes (by teor):

 * keywords:  must-fix-before-028-rc, 029-proposed, review-group-1, 029
 -nickm-unsure =>
 must-fix-before-028-rc, 029-proposed, review-group-1, 029-nickm-
 unsure, 029-teor-yes, 028-teor-unsure


Comment:

 This would be great in 0.2.9, nice to have in 0.2.8, but not essential
 (the 0.2.8 behaviour without this is no worse than 0.2.7).

 It's worth noting that if we don't merge this in 0.2.8, users with
 blackholed fallbacks will end up downloading a consensus, but failing (or
 experiencing delay) when downloading certificates. I think this is not
 ideal, but it is tolerable if we don't want to add more code to 0.2.8.

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

Re: [tor-bugs] #18987 [Core Tor/Tor]: Ship a cached-certs file with Tor, to speed first bootstrap

[Tor Bug Tracker & Wiki]

#18987: Ship a cached-certs file with Tor, to speed first bootstrap
-+-
 Reporter:  arma |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.???
 Severity:  Normal   |Version:
 Keywords:  029-proposed, 029-nickm-unsure, 029  | Resolution:
  -teor-no   |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  029-proposed, 029-nickm-unsure => 029-proposed, 029-nickm-
 unsure, 029-teor-no


Comment:

 This seems like a nice feature for 0.2.10 or later, but it creates some
 release overhead, and may be unnecessary if we do #18963.

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

Re: [tor-bugs] #19045 [Core Tor/Tor]: Keep trying to form a new shared random value during the next commit phase

[Tor Bug Tracker & Wiki]

#19045: Keep trying to form a new shared random value during the next commit 
phase
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.???
 Severity:  Normal   |Version:
 Keywords:  029-proposed, 029-nickm-unsure, 029  | Resolution:
  -teor-yes  |  Actual Points:
Parent ID:  #16943   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  029-proposed, 029-nickm-unsure => 029-proposed, 029-nickm-
 unsure, 029-teor-yes
 * points:   => small


Comment:

 I think this is a very small change:
 * keep the shared random value calculated from the state file
 * replace it with the consensus shared random value, when a consensus
 forms
 * expire non-consensus shared random values at the end of the commit phas

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

Re: [tor-bugs] #19060 [Core Tor/Tor]: Should SafeLogging hide bridge IP addresses in logs?

[Tor Bug Tracker & Wiki]

#19060: Should SafeLogging hide bridge IP addresses in logs?
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.???
 Severity:  Normal   |Version:
 Keywords:  029-proposed, easy, 029-nickm-   | Resolution:
  unsure, 029-teor-no|  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  029-proposed, easy, 029-nickm-unsure => 029-proposed, easy,
 029-nickm-unsure, 029-teor-no


Comment:

 As arma points out, the drawbacks of bridge operators not seeing IP
 addresses by default outweigh the leaking of the occasional bridge
 address.

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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 Priority:  Medium   |  assigned
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.???
 Keywords:  rsos, sos, tor2web, tor-hs,  |Version:
  029-proposed, 029-nickm-unsure, 029-teor-yes   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |  small/medium
 |Sponsor:
-+-
Changes (by teor):

 * keywords:  rsos, sos, tor2web, tor-hs, 029-proposed, 029-nickm-unsure =>
 rsos, sos, tor2web, tor-hs, 029-proposed, 029-nickm-unsure, 029-teor-
 yes
 * owner:   => teor
 * 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

Re: [tor-bugs] #18947 [Applications/Tor Browser]: 6.0a5 is not starting on OS X if put into /Applications

[Tor Bug Tracker & Wiki]

#18947: 6.0a5 is not starting on OS X if put into /Applications
--+--
 Reporter:  gk|  Owner:  mcs
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201605R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * status:  needs_information => needs_review
 * keywords:  TorBrowserTeam201605 => TorBrowserTeam201605R


Comment:

 We can detect that the new string is not available for a given language
 and fall back to the older error message. Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug18947-01=7ee11f5d012773445cc21a86bb1e8d423b15093d

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

Re: [tor-bugs] #19007 [User Experience/Website]: Create job posting for core OONI developer

[Tor Bug Tracker & Wiki]

#19007: Create job posting for core OONI developer
-+
 Reporter:  hellais  |  Owner:  Sebastian
 Type:  task | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by isabela):

 Yes, please just update the company part with the other description:

 About the company:
 The Tor Project is a US 501(c)(3) non-profit dedicated to research,
 development, and education about online anonymity and privacy. The Tor
 network's 6000 volunteer relays carry 48 Gbps for several million daily
 users, including ordinary citizens who want protection from identity theft
 and prying corporations, corporations who want to look at a competitor's
 website in private, people around the world whose Internet connections are
 censored, and even governments and law enforcement. Tor has a staff of 30
 paid developers, researchers, and advocates, plus many dozen volunteers
 who help out on a daily basis. Tor is funded in part by government
 research and development grants, and in part by individual and corporate
 donations.

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

Re: [tor-bugs] #19055 [Applications/Tor Browser]: TBB Upstreaming of Yawning's Firejail Script

[Tor Bug Tracker & Wiki]

#19055: TBB Upstreaming of Yawning's Firejail Script
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by adrelanos):

 Current:
 https://gitweb.torproject.org/builders/tor-browser-
 bundle.git/tree/RelativeLink/start-tor-browser

 Proposed:
 https://git.schwanenlied.me/yawning/tor-firejail/src/master/start-tor-
 browser

 The diff looks reasonable. Should be safe for with non-firejail users.

 {{{
 > #
 > # Automagic sandboxing based on firejail if it's available.
 > #
 > BROWSER_CMD=./firefox
 > if [ -x /usr/bin/firejail ]; then
 >   BROWSER_CMD="/usr/bin/firejail --profile=${HOME}/tor-browser.profile \
 > --env=LD_LIBRARY_PATH=${LD_LIBRARY_PATH} \
 > --env=FONTCONFIG_PATH=${FONTCONFIG_PATH} \
 > --env=FONTCONFIG_FILE=${FONTCONFIG_FILE} \
 > --env=ASAN_OPTIONS=${ASAN_OPTIONS} \
 > --whitelist=${HOME} \
 > ./firefox"
 > fi
 >
 359c373
 < TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor
 Browser" \
 ---
 > TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ${BROWSER_CMD} --class "Tor
 Browser" \
 363c377
 < TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor
 Browser" \
 ---
 > TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ${BROWSER_CMD} --class "Tor
 Browser" \
 367c381
 < TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor
 Browser" \
 ---
 > TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ${BROWSER_CMD} --class "Tor
 Browser" \
 371c385
 < TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor
 Browser" \
 ---
 > TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ${BROWSER_CMD} --class "Tor
 Browser" \
 374c388
 < TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor
 Browser" \
 ---
 > TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ${BROWSER_CMD} --class "Tor
 Browser" \
 }}}

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

Re: [tor-bugs] #18619 [Applications/Tor Browser]: TBB/ESR45 reports "InvalidStateError" in browser console

[Tor Bug Tracker & Wiki]

#18619: TBB/ESR45 reports "InvalidStateError" in browser console
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:4 arthuredelstein]:
 > Here's a patch that attempts to fix the problem.
 >
 > https://github.com/arthuredelstein/tor-browser/commit/18619+1
 > Hash 96e76624a5e354bb059782dbe1fdeb5f8345af4e

 With this patch, an InvalidState error is no longer logged during browser
 startup. We still see one when we open the developer tools (Inspect
 Element). I don't know how difficult it would be to patch the underlying
 devtools/shared/async-storage.js code to avoid using IndexedDB when it has
 been disabled.

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

Re: [tor-bugs] #14013 [Core Tor/Tor]: base16_decode() API is inconsistent and error-prone

[Tor Bug Tracker & Wiki]

#14013: base16_decode() API is inconsistent and error-prone
---+
 Reporter:  nickm  |  Owner:  nikkolasg
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  lorax, review-group-1  |  Actual Points:
Parent ID: | Points:  small
 Reviewer:  dgoulet|Sponsor:  SponsorS-can
---+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 First this is a good find. I've opened #19066 about it:

 {{{
 +// XXX Should it not be always DIGEST256_LEN ? Running the tests with
 +// the condition ` != DIGEST256_LEN` fails.
 }}}

 The patch looks good. There are some minor syntax issues that can easily
 be fixed such as:

 {{{
 if (base16_decode(digest, DIGEST_LEN, hexbuf, HEX_DIGEST_LEN)
 != DIGEST_LEN) {
 }}}

 It should be aligned like this to follow the code base:

 {{{
 if (base16_decode(digest, DIGEST_LEN,
   hexbuf, HEX_DIGEST_LEN) != DIGEST_LEN) {
 }}}

 This one has an extra white space:

 {{{
base16_decode(voter->identity_digest,
 sizeof(voter->identity_digest),
 -tok->args[1], HEX_DIGEST_LEN) < 0) {
 +tok->args[1], HEX_DIGEST_LEN)  != DIGEST_LEN) {
 }}}

 Align:

 {{{
 +tt_int_op(sizeof(blinding_param), OP_EQ, DECODE(blinding_param,
 +ED25519_BLINDING_PARAMS[i]));

 +tt_int_op(sizeof(buf),OP_EQ,base16_decode(buf,sizeof(buf),\
 +hex,strlen(hex)));\
 }}}

 Sorry about this, very wow such nitpicking but it makes the difference in
 the end for a more clean and maintainable code. Let me know if you can
 quickly fix those else I can go over them and credit you as the author.
 Thanks!

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

[tor-bugs] #19066 [Core Tor/Tor]: Wrong length used in networkstatus_parse_detached_signatures

[Tor Bug Tracker & Wiki]

#19066: Wrong length used in networkstatus_parse_detached_signatures
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 While fixing #14013, nikkolasg realized thatif we did in fact use `!=
 DIGEST256_LEN` it caused a failure in the test:

 {{{
 // XXX Should it not be always DIGEST256_LEN ? Running the tests with
 // the condition ` != DIGEST256_LEN` fails.
 if (base16_decode(digests->d[alg], DIGEST256_LEN,
   hexdigest, strlen(hexdigest)) < 0) {
 }}}

 Turns out that `alg` here is actually `sha1` thus of size `DIGEST_LEN`.
 The base16 decode is safe with a larger length but this check (just above
 in the code) could resolved in unwanted behavior:

 {{{
 if (!tor_mem_is_zero(digests->d[alg], DIGEST256_LEN)) {
 }}}

 `tor_mem_is_zero` does make sure that the full length is zeroes thus here
 looking for 12 extra bytes out of bound to be 0... (DIGEST_LEN vs
 DIGEST256_LEN). The length we used should be set according to the
 algorithm in `alg`

 Patch coming soon.

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

Re: [tor-bugs] #18895 [Core Tor/Tor]: --enable-expensive-hardening has hard-to-debug failures when run-time libraries aren't installed

[Tor Bug Tracker & Wiki]

#18895: --enable-expensive-hardening has hard-to-debug failures when run-time
libraries aren't installed
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0.1
Parent ID: | Points:  small
 Reviewer: |Sponsor:  SponsorS-can
---+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => 0.1


Comment:

 Please see branch `hardening_flags_must_link`.

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

Re: [tor-bugs] #18895 [Core Tor/Tor]: --enable-expensive-hardening has hard-to-debug failures when run-time libraries aren't installed

[Tor Bug Tracker & Wiki]

#18895: --enable-expensive-hardening has hard-to-debug failures when run-time
libraries aren't installed
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:  SponsorS-can
---+
Changes (by nickm):

 * keywords:   => TorCoreTeam201605
 * owner:   => nickm
 * status:  new => accepted


Comment:

 Bumping up priority a little since this seems to be breaking some jenkins
 targets.

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

Re: [tor-bugs] #19065 [Applications/Tor Browser]: Tor Browser icon not visible anymore in upper left corner on Linux since 05/13

[Tor Bug Tracker & Wiki]

#19065: Tor Browser icon not visible anymore in upper left corner on Linux since
05/13
-+-
 Reporter:  gk   |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:  new
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  TorBrowserTeam201605, tbb-   | Resolution:
  regression |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201605 => TorBrowserTeam201605, tbb-regression


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19065 [Applications/Tor Browser]: Tor Browser icon not visible anymore in upper left corner on Linux since 05/13

[Tor Bug Tracker & Wiki]

#19065: Tor Browser icon not visible anymore in upper left corner on Linux since
05/13
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  TorBrowserTeam201605
   Points:|  Parent ID:
  Sponsor:|   Reviewer:
--+
 The nightly build from May 09 is the last one still showing the Tor
 Browser icon in the upper left corner of browser windows/dialogs. The
 nightly from May 13 is the first one that just shows a placeholder icon on
 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #18823, #18963, #18987, #19045

[Tor Bug Tracker & Wiki]

Batch modification to #18823, #18963, #18987, #19045 by nickm:
keywords to 029-nickm-unsure

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #17945, #18896, #19060

[Tor Bug Tracker & Wiki]

Batch modification to #17945, #18896, #19060 by nickm:
keywords to 029-nickm-unsure

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #19011, #19020, #19044

[Tor Bug Tracker & Wiki]

Batch modification to #19011, #19020, #19044 by nickm:
keywords to 029-nickm-says-yes

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #18529, #18840, #18933, #18961, #18982, #19012, #19028, #19035, #19036

[Tor Bug Tracker & Wiki]

Batch modification to #18529, #18840, #18933, #18961, #18982, #19012, #19028, 
#19035, #19036 by nickm:
keywords to 029-nickm-says-yes

--
Tickets URL: 

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

Re: [tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Normal   |Version:  Tor:
 Keywords:  must-fix-before-028-rc,  |  0.2.8.1-alpha
  CoreTorTeam201605, review-group-1  | Resolution:  fixed
Parent ID:   |  Actual Points:
 Reviewer:  nickm| Points:  small
 |Sponsor:
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by nickm):

 This ticket keeps confusing me by being open.  I'm unparenting the child
 ticket as it waits for review, then closing this ticket.

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

Re: [tor-bugs] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed, review-group-1   |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  arma |  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by nickm):

 * parent:  #18816 =>


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

Re: [tor-bugs] #17158 [Core Tor/Tor]: Run an opt-in process for fallback directories

[Tor Bug Tracker & Wiki]

#17158: Run an opt-in process for fallback directories
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Normal   |Version:
 Keywords:  028-triaged, must-fix-   | Resolution:
  before-028-rc, TorCoreTeam201605,  |  implemented
  TorCoreTeam-postponed-201604, review-group-1   |  Actual Points:  3 weeks
Parent ID:   | Points:  small-
 Reviewer:  isis |  remaining
 |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

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


Comment:

 merged to maint-0.2.8 and forward. Thanks, 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] #16794 [Core Tor/Tor]: All cryptography unit test coverage should be over 95%; all should have test vectors

[Tor Bug Tracker & Wiki]

#16794: All cryptography unit test coverage should be over 95%; all should have
test vectors
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.9.x-final
 Severity:  Normal   |Version:
 Keywords:  testing, 028-triage, tor-tests-  | Resolution:
  coverage, tor-tests-unit, TorCoreTeam201605,   |  implemented
  review-group-1 |  Actual Points:
Parent ID:  #16791   | Points:  medium
 Reviewer:  isis |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

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


Comment:

 Thanks again for the review; merged into master.

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

Re: [tor-bugs] #18956 [Core Tor/Tor]: Trivial memory leak when reading truncated ed25519 key files

[Tor Bug Tracker & Wiki]

#18956: Trivial memory leak when reading truncated ed25519 key files
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  review-group-1  |  Actual Points:  very small
Parent ID:  #16794  | Points:  very small
 Reviewer:  special, isis   |Sponsor:
+
Changes (by nickm):

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


Comment:

 Thanks again for the review; merged into master with #16794.

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