Re: [tor-bugs] #19118 [Metrics/Onionoo]: Add organization name to each relay

[Tor Bug Tracker & Wiki]

#19118: Add organization name to each relay
-+---
 Reporter:  virgil   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  hardening|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 I'm yet unclear what we'd gain by adding CAIDA.org data.  We're using
 MaxMind's GeoLite ASN file which contains the following entry for 1984
 Hosting:

 {{{
 1566564352,1566566399,"AS44925 1984 ehf AS number"
 }}}

 Onionoo would include that as follows in a relay details document:

 {{{
 "as_number":"AS44925","as_name":"1984 ehf AS number"
 }}}

 (Admittedly, the "AS number" part in that string doesn't make much sense
 and looks like a data import problem on MaxMind's side.  But we can
 probably expect similar problems with CAIDA.org's data, just not with this
 particular entry.)

 But let's also look at a bigger AS/organization that hosts a lot of
 relays: OVH.  Here's what CAIDA.org says about OVH:

 {{{
 ORG-OS3-RIPE||OVH SAS|FR|RIPE
 16276||OVH|ORG-OS3-RIPE|RIPE
 35540||OVH-TELECOM|ORG-OS3-RIPE|RIPE
 }}}

 And here's what MaxMind's ASN file says about OVH:

 {{{
 86441984,86474751,"AS16276 OVH SAS"
 92733440,92798975,"AS16276 OVH SAS"
 96731136,96796671,"AS16276 OVH SAS"
 134738944,134739199,"AS16276 OVH SAS"
 135430144,135430399,"AS16276 OVH SAS"
 135432192,135434239,"AS16276 OVH SAS"
 135441408,135441663,"AS16276 OVH SAS"
 135556608,135556863,"AS16276 OVH SAS"
 135604480,135604735,"AS16276 OVH SAS"
 135792640,135794687,"AS16276 OVH SAS"
 135945728,135945983,"AS16276 OVH SAS"
 136175616,136175871,"AS16276 OVH SAS"
 136237056,136239103,"AS16276 OVH SAS"
 136404992,136407039,"AS16276 OVH SAS"
 136413184,136415743,"AS16276 OVH SAS"
 624623616,624689151,"AS16276 OVH SAS"
 624701440,624705535,"AS16276 OVH SAS"
 633012224,633077759,"AS16276 OVH SAS"
 635305984,635338751,"AS16276 OVH SAS"
 635371520,635437055,"AS16276 OVH SAS"
 778633216,778698751,"AS16276 OVH SAS"
 1056243712,1056251903,"AS16276 OVH SAS"
 1466073088,1466105855,"AS16276 OVH SAS"
 1532647424,1532649471,"AS16276 OVH SAS"
 1534656512,1534722047,"AS16276 OVH SAS"
 1558052864,1558118399,"AS16276 OVH SAS"
 1578565632,1578631167,"AS16276 OVH SAS"
 1728384000,1728385023,"AS16276 OVH SAS"
 1841168384,1841233919,"AS35540 OVH SAS"
 2382675968,2382684159,"AS16276 OVH SAS"
 2809266176,2809331711,"AS16276 OVH SAS"
 2954821632,2954887167,"AS16276 OVH SAS"
 2988441600,2988572671,"AS16276 OVH SAS"
 3001868288,3001872383,"AS16276 OVH SAS"
 310672,310927,"AS16276 OVH SAS"
 3104579584,3104580095,"AS16276 OVH SAS"
 3164930048,3164985007,"AS16276 OVH SAS"
 3164985009,3164995583,"AS16276 OVH SAS"
 3227451392,3227467775,"AS16276 OVH SAS"
 3227713536,3227779071,"AS16276 OVH SAS"
 3244823296,3244823551,"AS16276 OVH SAS"
 3245162240,3245162495,"AS16276 OVH SAS"
 3278773760,3278774271,"AS16276 OVH SAS"
 3287738368,3287738879,"AS16276 OVH SAS"
 3323674624,3323691007,"AS16276 OVH SAS"
 3325198336,3325231103,"AS16276 OVH SAS"
 3328479232,3328483327,"AS16276 OVH SAS"
 3337957376,3337961471,"AS16276 OVH SAS"
 3585744896,3585753087,"AS16276 OVH SAS"
 3590029312,3590045695,"AS16276 OVH SAS"
 }}}

 Wouldn't we include the exact same output after switching to CAIDA.org
 data?

 I'm hesitant to add another data source, because I expect inconsistencies
 between the two data sources where we don't have the exact same AS numbers
 in the two files and similar issues.

 Another (minor) issue is the additional overhead for Onionoo server
 operators.

 Stated differently, I'd want us to have a good reason for adding another
 data source.  Can you maybe give a counterexample where using CAIDA.org
 data in addition to MaxMind data would enhance Onionoo data notably?

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

Re: [tor-bugs] #18967 [Metrics/Onionoo]: Add UUID to families in Onionoo

[Tor Bug Tracker & Wiki]

#18967: Add UUID to families in Onionoo
-+-
 Reporter:  seansaito|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  persistence, |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Replying to [comment:4 virgil]:
 > If an Onionoo is allowed to skip some consensuses, doesn't that mean the
 family UUIDs must be a function of *solely* the most recent consensus?
 >
 > Not to say that's impossible, but that's a huge constraint.

 Not skip but reorder, but you're right, it's a constraint, maybe a too big
 one.

 > Even if you require a complete record going back `k` steps, you're going
 to lose any persistence going back `>k` steps.  Instead of accepting that
 the Onionoo server will have gaps in its consensus history, wouldn't it be
 better simply to put them on a blockchain of some sort?

 Let's not over-engineer this, but I could imagine us designing something
 based on your suggestion before editing your comment:

 > Another solution would be that the UUID is a function of the last $k$
 consensuses.  And for an Onionoo server to update the family, it must have
 the a k-length sequence of consecutive consensuses.

 Consensuses are the wrong descriptor type, because we're only interested
 in mutual agreements that two relays A and B are in the same family,
 regardless of what the directory authorities think.  And consensuses don't
 contain family information, so we'd have to follow references to server
 descriptors, which makes this harder to implement.  We could simply look
 at server descriptors published in the past `k` hours or days.  And it's
 probably okay if an Onionoo server misses a single server descriptor,
 because that kind of inconsistency will heal by itself once that server
 descriptor is older than `k` hours.

 Would you two want to suggest a UUID algorithm based only on server
 descriptors published in the past `k` hours?

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

Re: [tor-bugs] #18733 [Metrics/CollecTor]: contributor's guide incl. coding guidelines for java projects

[Tor Bug Tracker & Wiki]

#18733: contributor's guide incl. coding guidelines for java projects
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID:  #18730 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Hmm, I just pushed your branch because it looked good and didn't have
 issues with the cobertura task.  (I had to run `ant clean` and then `ant
 coverage`.)

 If you think the issue still persists, please send another patch on top of
 current master.

 In the future, please don't edit comments for important changes but only
 for typos or minor things.  I only receive an email for the original
 comment text and usually don't look for updates on Trac before working on
 the ticket.  Just add a new comment and I'll have the latest state in my
 inbox.  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] #19119 [Applications/Tor Browser]: Repurpose block-malicious-sites-checkbox on TLS error page in Tor Browser

[Tor Bug Tracker & Wiki]

#19119: Repurpose block-malicious-sites-checkbox on TLS error page in Tor 
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Right now the checkbox on the neterror page sends a report about an TLS
 error to Mozilla (containing host, port, timestamp, useragent, update
 channel, buildid, certificate chain and version of that feature). We might
 want to repurpose that checkbox as, first, I see no reason why Mozilla
 should gather data related to a Tor Browser user. Second, this message is
 highly confusing in our context. Say, an exit node is MITMing a user. Why
 should the user report that to Mozilla in order to identify and block
 malicious sites? What is Mozilla supposed to do with that information?

 We could think about having an own infrastructure for this that might help
 detecting bad relays

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

Re: [tor-bugs] #18944 [Applications/Tor Browser]: Remove block-malicious-sites-checkbox on TLS error page

[Tor Bug Tracker & Wiki]

#18944: Remove block-malicious-sites-checkbox on TLS error page
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  ff45-esr, TorBrowserTeam201605,  |  Actual Points:
  GeorgKoppen201605, tbb-6.0-must| Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:3 gk]:
 > The first thing is We are not in the business of identifying and
 blocking malicious sites. We actually disabled that feature.

 Looking closer that is not related to the Safebrowsing malware protection
 (which I assumed and which was the reason for filing this ticket). In
 ESR38 this checkbox is already existing although deeper buried and the
 whole thing is working slightly differently. I guess we leave it as-is for
 now then but file a ticket to get Mozilla out of the loop. That might even
 help detecting bad relays.

 > Second, I see no reason why Mozilla should gather data related to a Tor
 Browser user. Third, this message is highly confusing in our context. Say,
 an exit node is MITMing a user. Why should the user report that to Mozilla
 in order to identify and block malicious sites? What is Mozilla supposed
 to do with that information?
 >
 > We can think about ways to deal with MITM attacks in Tor Browser but
 that would be another ticket and would need at least a repurposed
 checkbox.

 This is #19119.

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

Re: [tor-bugs] #16285 [Applications/Tor Browser]: Make sure EME is no tracking risk in Tor Browser

[Tor Bug Tracker & Wiki]

#16285: Make sure EME is no tracking risk in Tor Browser
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  Medium   |  assigned
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, tbb-linkability,   | Resolution:
  GeorgKoppen201605, TorBrowserTeam201605,   |  Actual Points:
  tbb-6.0-must   | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

 * keywords:
 ff45-esr, tbb-linkability, GeorgKoppen201506, TorBrowserTeam201605,
 tbb-6.0-must
 =>
 ff45-esr, tbb-linkability, GeorgKoppen201605, TorBrowserTeam201605,
 tbb-6.0-must
 * severity:   => Normal


Old description:

> The EME architecture got uplifted to Firefox 37
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1137045) in is included in
> ESR 38 as well. We should make sure there are no accompanying
> tracking/fingerprinting risks. The best plan is probably to disable EME
> as Mozilla is doing in its ESR 38 release. We may need a custom patch as
> Mozilla is basically enabling it
> {{{
> #if !defined(MOZ_UPDATE_CHANNEL) || MOZ_UPDATE_CHANNEL != esr
> }}}
> While we may want to take a deeper look at it when we switch to ESR 45 we
> should make sure that everything related to EME is really disabled if the
> respective prefs are set to `false`.

New description:

 The EME architecture got uplifted to Firefox 37
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1137045) and is included in
 ESR 38 as well. We should make sure there are no accompanying
 tracking/fingerprinting risks. The best plan is probably to disable EME as
 Mozilla is doing in its ESR 38 release. We may need a custom patch as
 Mozilla is basically enabling it
 {{{
 #if !defined(MOZ_UPDATE_CHANNEL) || MOZ_UPDATE_CHANNEL != esr
 }}}
 While we may want to take a deeper look at it when we switch to ESR 45 we
 should make sure that everything related to EME is really disabled if the
 respective prefs are set to `false`.

--

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

Re: [tor-bugs] #5102 [Core Tor/Tor]: segfault in entry_guard_register_connect_status on tor bridge running obfsproxy on openbsd

[Tor Bug Tracker & Wiki]

#5102: segfault in entry_guard_register_connect_status on tor bridge running
obfsproxy on openbsd
-+-
 Reporter:  therealditzydoo  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.2.3.11-alpha
 Severity:  Normal   | Resolution:  user disappeared
 Keywords:  tor-bridge   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_information => closed
 * resolution:   => user disappeared


Comment:

 ack

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  teor
 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:
  TorCoreTeam201605, review-group-1,   must- |  0.2.8.1-alpha
  fix-before-0283| Resolution:
Parent ID:   |  Actual Points:  4
 Reviewer:  andrea   | Points:  3
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 Wow that's big.

 For review purposes, I did the squash and revert-pair-removal you describe
 in bug18809_028_squashed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  teor
 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:
  TorCoreTeam201605, review-group-1,   must- |  0.2.8.1-alpha
  fix-before-0283| Resolution:
Parent ID:   |  Actual Points:  4
 Reviewer:  andrea   | Points:  3
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 In connection_ap_handshake_attach_circuit():
* I hate making this function more complex.  It is already far too
 complex.  But I won't hold off the patch for that.

 Here's a case I needed to think about:
 {{{
 + * As soon as we have received a consensus, return 0, even if we don't
 have
 + * enough certificates to validate it. */
 }}}

 Suppose that a fallback gives us a bogus consensus whose certificates are
 all bad.  When will we notice, throw the consensus away, and try to fetch
 another one?  Having a comment that explains the process here would ease
 my mind, and the mind of the next person who tries to read the code. :)

 Merging and applying roger's spelling fixes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  teor
 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:
  TorCoreTeam201605, review-group-1,   must- |  0.2.8.1-alpha
  fix-before-0283| Resolution:
Parent ID:   |  Actual Points:  4
 Reviewer:  andrea   | Points:  3
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 Ug, there is a huge bunch of conflicts when I try to merge this to master.
 They _seem_ to be caused by the fact that we already fixed the
 "boostrapping" spelling mistake on master.  Please have a look at the big
 merge commit (d718c717a67051cb1da2a1f80c70401d0d10b374) before I close
 this ticket and make sure I got it right?

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

Re: [tor-bugs] #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:  1
   |Sponsor:
---+---

Comment (by nickm):

 I'm concerned about all the things that look at this number.  Can we defer
 merging this to 0.2.9?

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

Re: [tor-bugs] #16285 [Applications/Tor Browser]: Make sure EME is no tracking risk in Tor Browser

[Tor Bug Tracker & Wiki]

#16285: Make sure EME is no tracking risk in Tor Browser
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  Medium   |  assigned
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff52-esr, tbb-linkability,   | Resolution:
  GeorgKoppen201605, TorBrowserTeam201605|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 ff45-esr, tbb-linkability, GeorgKoppen201605, TorBrowserTeam201605,
 tbb-6.0-must
 => ff52-esr, tbb-linkability, GeorgKoppen201605, TorBrowserTeam201605


Comment:

 Replying to [comment:6 gk]:
 > https://support.mozilla.org/en-US/kb/enable-drm has some decent info.
 The bottom line is there is only EME on Windows Vista+ and as we don't
 build any sandbox on Windows and the sandbox is needed for EME we won't
 get it to run on Vista+ either. Thus, I'll go with the idea in comment:4
 and audit the result. As mentioned in the description we want to revisit
 this during the preparation for ESR 45 when we have fixed #16010 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=1136707 got solved by
 Mozilla.

 Neither #16010 nor the Mozilla bug are fixed yet. Thus, I postpone
 revisiting our current decision. So far, for ESR45, we are still good with
 the things we currently have in place.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19120 [Core Tor/Tor]: Integrate and remove Clang hardening instructions

[Tor Bug Tracker & Wiki]

#19120: Integrate and remove Clang hardening instructions
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The file `contrib/clang/sanitize_blacklist.txt` contains instructions on
 how to build Tor with AddressSanitizer using Clang. Recent changes to the
 build system made most of these instructions obsolete (see #13538, #18934,
 #18841).

 FWICT the only thing that is not implemented are some CFLAGS and LDFLAGS
 options.

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

Re: [tor-bugs] #18934 [Core Tor/Tor]: test suite failures with expensive hardening.

[Tor Bug Tracker & Wiki]

#18934: test suite failures with expensive hardening.
+
 Reporter:  weasel  |  Owner:  nickm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  review-group-1  |  Actual Points:
Parent ID:  | Points:  very-small
 Reviewer:  |Sponsor:
+
Changes (by cypherpunks):

 * status:  reopened => needs_review


Comment:

 Turns out the solution was archived in
 `contrib/clang/sanitize_blacklist.txt`.
 {{{
 # we need to allow the tor bt handler to catch SIGSEGV
 # otherwise address sanitizer munges the expected output and the test
 fails
 # we can do this by setting an environmental variable
 # See https://code.google.com/p/address-sanitizer/wiki/Flags
 # ASAN_OPTIONS=allow_user_segv_handler=1
 }}}

 Unfortunately the `allow_user_segv_handler` is not supported by older GCC
 versions but they do support `handle_segv=0` which prevents
 AddressSanitizer from installing its own segfault handler. The patch
 attachment:0001-Prevent-ASAN-from-registering-a-SIGSEGV-handler.patch
 fixed the issue for me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19121 [Applications/Tor Browser]: reinstate the update.xml hash check

[Tor Bug Tracker & Wiki]

#19121: reinstate the update.xml hash check
-+-
 Reporter:  mcs  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff45-esr,
 Severity:  Normal   |  TorBrowserTeam201605, tbb-6.0-must
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 While working on #18912, Kathy and I discovered the following Mozilla
 change that causes the update.xml hash check to be skipped when signed MAR
 files are in use (this change shipped in Firefox 43):
 https://bugzilla.mozilla.org/show_bug.cgi?id=862173

 I think the our philosophy is different than Mozilla's and that we
 probably want to reinstate the hash check. Mike and Georg, do you agree?

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

Re: [tor-bugs] #19121 [Applications/Tor Browser]: reinstate the update.xml hash check

[Tor Bug Tracker & Wiki]

#19121: reinstate the update.xml hash check
-+-
 Reporter:  mcs  |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_information
 Severity:  Normal   |  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605,  |Version:
  tbb-6.0-must   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by mcs):

 * status:  new => needs_information


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

Re: [tor-bugs] #18733 [Metrics/CollecTor]: contributor's guide incl. coding guidelines for java projects

[Tor Bug Tracker & Wiki]

#18733: contributor's guide incl. coding guidelines for java projects
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID:  #18730 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Replying to [comment:16 karsten]:
 > Hmm, I just pushed your branch because it looked good and didn't have
 issues with the cobertura task.  (I had to run `ant clean` and then `ant
 coverage`.)
 The task runs fine, the problem only shows when you have tests; then the
 coverage is not calculated correctly.

 > If you think the issue still persists, please send another patch on top
 of current master.
 I'll post the patch; it is very small.
 >
 > In the future, please don't edit comments for important changes but only
 for typos or minor things.  I only receive an email for the original
 comment text and usually don't look for updates on Trac before working on
 the ticket.  Just add a new comment and I'll have the latest state in my
 inbox.  Thanks!
 Good to know! I usually read the trac tickets in trac.

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

Re: [tor-bugs] #18934 [Core Tor/Tor]: test suite failures with expensive hardening.

[Tor Bug Tracker & Wiki]

#18934: test suite failures with expensive hardening.
+
 Reporter:  weasel  |  Owner:  nickm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  review-group-1  |  Actual Points:
Parent ID:  | Points:  very-small
 Reviewer:  nickm   |Sponsor:
+
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #18934 [Core Tor/Tor]: test suite failures with expensive hardening.

[Tor Bug Tracker & Wiki]

#18934: test suite failures with expensive hardening.
+
 Reporter:  weasel  |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  review-group-1  |  Actual Points:
Parent ID:  | Points:  very-small
 Reviewer:  nickm   |Sponsor:
+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Patch looks good; I'll merge it once I can write a changes file.

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

Re: [tor-bugs] #19121 [Applications/Tor Browser]: reinstate the update.xml hash check

[Tor Bug Tracker & Wiki]

#19121: reinstate the update.xml hash check
-+-
 Reporter:  mcs  |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_information
 Severity:  Normal   |  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605,  |Version:
  tbb-6.0-must   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by gk):

 Ugh, good find. Yes, we definitely want the hash check.

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

Re: [tor-bugs] #19121 [Applications/Tor Browser]: reinstate the update.xml hash check

[Tor Bug Tracker & Wiki]

#19121: reinstate the update.xml hash check
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 Priority:  High |  assigned
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  ff45-esr, TorBrowserTeam201605,  | Resolution:
  tbb-6.0-must   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_information => assigned
 * priority:  Medium => High
 * severity:  Normal => Major
 * 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

Re: [tor-bugs] #18733 [Metrics/CollecTor]: contributor's guide incl. coding guidelines for java projects

[Tor Bug Tracker & Wiki]

#18733: contributor's guide incl. coding guidelines for java projects
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID:  #18730 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 the patch
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=make-
 cobertura-work-again branch]

 currently, cobertura.ser needs to be in the base directory.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-bridge, TorCoreTeam201605  | Resolution:
Parent ID: |  Actual Points:
 Reviewer:  arma   | Points:  1
   |Sponsor:
---+---
Changes (by isis):

 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.9.x-final


Comment:

 Replying to [comment:10 nickm]:
 > I'm concerned about all the things that look at this number.  Can we
 defer merging this to 0.2.9?
 >

 That's fine by me. I was wondering why it hadn't been bumped to 0.2.9, and
 why it received the TorCoreTeam201605 tag. (I had assumed you or arma
 wanted it prioritised for some reason.)

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

Re: [tor-bugs] #19079 [Core Tor/Tor]: clang -m32 -ftrapv seems buggy with 64-bit signed integer multiply

[Tor Bug Tracker & Wiki]

#19079: clang -m32 -ftrapv seems buggy with 64-bit signed integer multiply
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  .1
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 code review:

 6d6c828 Include __mulodi4 in libor_ctime when it fixes clang -m32 -ftrapv

 You forgot an atoi on argv[3], and you said on IRC it won't matter.

 3303460 Add __mulodi4 source to src/ext

 Do we need unit tests for this?
 Or should we just assume the llvm source is ok?
 (I wonder about bugs like http://kqueue.org/blog/2013/09/17/cltq/ , the
 specific instance isn't an issue here because the types are all the same,
 but in general, these sort of subtle compiler bugs concern me.)

 Other than that, looks good to merge.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19122 [Core Tor/Tor]: Documentation for "User" option specifies wrong kind of argument

[Tor Bug Tracker & Wiki]

#19122: Documentation for "User" option specifies wrong kind of argument
--+--
 Reporter:  chadmiller|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://www.torproject.org/docs/tor-manual.html.en


 User UID
 On startup, setuid to this user and setgid to their primary group.



 A UID is an integer in unix speak, not a username. The description of
 the value uses "uid" correctly in the function names, but the option
 should say "username" because that is the only value it supports.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19123 [Internal Services/Tor Sysadmin Team]: Plz update my key in the keyring

[Tor Bug Tracker & Wiki]

#19123: Plz update my key in the keyring
-+-
 Reporter:  micah|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin   |Version:
  Team   |   Keywords:  key, update
 Severity:  Normal   |  Parent ID:
Actual Points:   |   Reviewer:
   Points:   |
  Sponsor:   |
-+-
 Hi, my key expired last month, but I've updated it and pushed those
 updates to the keyserver network before it expired... but it seems the
 manual update by tor needs to happen. Would you be a fine person and
 update that, pretty please?

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

Re: [tor-bugs] #19123 [Internal Services/Tor Sysadmin Team]: Plz update my key in the keyring

[Tor Bug Tracker & Wiki]

#19123: Plz update my key in the keyring
-+
 Reporter:  micah|  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  key, update  |  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

[tor-bugs] #19124 [Core Tor/Tor]: Shared Random and Half-Hour Consensuses

[Tor Bug Tracker & Wiki]

#19124: Shared Random and Half-Hour Consensuses
--+
 Reporter:  teor  |  Owner:
 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:  #16943
   Points:|   Reviewer:
  Sponsor:|
--+
 My test authority was asleep for an hour, and so it didn't have a recent
 consensus. It started voting at 10:30 for round commit 3/reveal 3, but the
 rest of the network wasn't voting for commit 3/reveal 3 until 11.

 How does an authority recover from this situation if it has thrown away
 its state at 1030?

 Do we fix this by implemeting #19045 (keep voting for shared random
 values)?
 Or does that make this worse?

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

Re: [tor-bugs] #19117 [Core Tor/DirAuth]: TOR Exit Node Blacklisted

[Tor Bug Tracker & Wiki]

#19117: TOR Exit Node Blacklisted
--+-
 Reporter:  arakiel   |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bad-exit  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

 * keywords:   => bad-exit
 * component:  Core Tor/Tor => Core Tor/DirAuth


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

Re: [tor-bugs] #18084 [Core Tor/Tor]: Use the same fallback directory mirror to bootstrap

[Tor Bug Tracker & Wiki]

#18084: Use the same fallback directory mirror to bootstrap
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  medium/large
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 This might not be a good idea, because it enables attacks where a fallback
 continues to deliver subtly bad (or slow) consensuses to its clients.

 We'd need to implement these checks carefully.

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

Re: [tor-bugs] #19053 [Applications/Tor Messenger]: Raw notifications in OTR mode

[Tor Bug Tracker & Wiki]

#19053: Raw notifications in OTR mode
+--
 Reporter:  ejik|  Owner:  arlolra
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:   => arlolra
 * status:  new => assigned


Comment:

 Thanks for filing.   I thought we had a ticket for this, but I guess not
 :P

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  teor
 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:
  TorCoreTeam201605, review-group-1,   must- |  0.2.8.1-alpha
  fix-before-0283| Resolution:
Parent ID:   |  Actual Points:  4
 Reviewer:  andrea   | Points:  3
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by teor):

 I think everything is ok, because `git show
 d718c717a67051cb1da2a1f80c70401d0d10b374` gives me an empty patch. git
 show on a merge commit uses git diff-tree —cc, which removes hunks which
 match either parent. So I think we're ok here.

 (Is there another git command I should use? I tried `git diff-tree` but
 that gave me the same results.)

 Also, the functions are named correctly and all the unit tests pass, as
 does `make test-network-all`.

 My branch `fix18809-comment` explains that a consensus that's waiting for
 certificates fails after 20 minutes. And then we try again. It's a
 comment-only change.

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

Re: [tor-bugs] #19122 [Core Tor/Tor]: Documentation for "User" option specifies wrong kind of argument

[Tor Bug Tracker & Wiki]

#19122: Documentation for "User" option specifies wrong kind of argument
--+--
 Reporter:  chadmiller|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:   => easy doc
 * points:   => 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] #18809 [Core Tor/Tor]: Handle linked connections better during bootstrap

[Tor Bug Tracker & Wiki]

#18809: Handle linked connections better during bootstrap
-+-
 Reporter:  teor |  Owner:  teor
 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:
  TorCoreTeam201605, review-group-1,   must- |  0.2.8.1-alpha
  fix-before-0283| Resolution:
Parent ID:   |  Actual Points:  4
 Reviewer:  andrea   | Points:  3
 |Sponsor:
 |  SponsorS-can
-+-

Comment (by teor):

 Jenkins mingw fails with `unused-but-set-variable` warnings:
 {{{
 15:34:57 src/test/test_connection.c:660:17: error: variable 'ap_conn4' set
 but not used [-Werror=unused-but-set-variable]
 15:34:57 src/test/test_connection.c:658:17: error: variable 'ap_conn2' set
 but not used [-Werror=unused-but-set-variable]
 15:34:57 src/test/test_connection.c:655:21: error: variable 'conn3' set
 but not used [-Werror=unused-but-set-variable]
 }}}
 https://jenkins.torproject.org/job/tor-ci-
 mingwcross-0.2.8/ARCHITECTURE=amd64,SUITE=jessie/27/console

 Please try my branch `fix18809-warnings`, which includes the warning fix
 and the comment fix.
 (I don't have a compiler that does `-Wunused-but-set-variable`, so we'll
 have to throw this one at jenkins.)

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

Re: [tor-bugs] #19115 [Applications/Tor Browser]: Make sure Tor Browser 6.0 is not falling back to Bing as its search engine

[Tor Bug Tracker & Wiki]

#19115: Make sure Tor Browser 6.0 is not falling back to Bing as its search 
engine
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-6.0-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 The plan as I understood it is that Geko and/or Isabela (somebody pick
 one?) are going to ask disconnect for some statistics on how many searches
 Tor Browser users produce, and that will help Shari figure out how smart
 it would be for us to point at DuckDuckGo directly.

 And in the mean time, the decision for TB 6.0 (between option 2 and option
 3) is not super critical, since we can always change things in a point
 release once we have a clearer answer.

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

Re: [tor-bugs] #18989 [Metrics/Atlas]: No Country image for Lativa

[Tor Bug Tracker & Wiki]

#18989: No Country image for Lativa
---+-
 Reporter:  alenan |  Owner:  phw
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by twim):

 > Okay, the Onionoo bug is now fixed in the sense that there is no
 "country" field for this relay anymore.

 How it had been fixed? There's also a relay without `"country"` somehow
 [1] (and ASN also) while others from the same AS do have this field [2].
 It seems to be the same bug.

 [1]
 
https://onionoo.torproject.org/details?search=041DDC5D9760D2EFF0450B46FF030C3986D54493
 [2]
 
https://onionoo.torproject.org/details?search=9634197516DA0EA4ECB83E7DC4960D832039D209

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19125 [Core Tor/Tor]: Fix a time parsing error on platforms with 32 bit time_t

[Tor Bug Tracker & Wiki]

#19125: Fix a time parsing error on platforms with 32 bit time_t
--+---
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, TorCoreTeam201605
Actual Points:  0.1   |  Parent ID:  #16943
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+---
 On platforms with 32 bit time_t, tor can't parse some dates in 2038, and
 all dates after 2038. So using 2666 in test data doesn't work.

 My branch sr-32bit on https://github.com/teor2345/tor.git fixes this
 issue, which is T9 from #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] #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, tor-hs  | Resolution:
Parent ID:  #16943   |  Actual Points:
 Reviewer:   | Points:  small
 |Sponsor:
-+-
Changes (by teor):

 * keywords:  029-proposed, 029-nickm-unsure, 029-teor-yes => 029-proposed,
 029-nickm-unsure, 029-teor-yes, tor-hs


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19126 [Core Tor/Tor]: Consistently use uint32_t for integers in shared random structs

[Tor Bug Tracker & Wiki]

#19126: Consistently use uint32_t for integers in shared random structs
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:  0.1   |  Parent ID:  #16943
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Rather than using int sometimes and uint32_t other times, we could
 consistently use uint32_t in shared random structs.

 My branch sr-uint32 at https://github.com/teor2345/tor.git has a fix for
 this.

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

[tor-bugs] #19127 [Core Tor/Tor]: Don't crash authorities with more than 254 shared random reveals

[Tor Bug Tracker & Wiki]

#19127: Don't crash authorities with more than 254 shared random reveals
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core  |Version:
  Tor/Tor |   Keywords:  tor-hs, 029-proposed, assert-crash
 Severity:  Normal|  Parent ID:  #16943
Actual Points:  0.5   |   Reviewer:
   Points:  0.5   |
  Sponsor:|
--+
 Rather than asserting that a tor network never has more than 253
 authorities, we could instead log when we truncate the number of reveals
 in the shared random hash.

 As a consequential change, we should do this truncation as late as
 possible, so that the value assigned to `srv->num_reveals` is not
 truncated.

 In any case, `tor_assert(reveal_num < UINT8_MAX);` is unnecessarily
 strict, it can be `tor_assert(reveal_num <= UINT8_MAX);`.

 Please see my branch sr-no-crash on https://github.com/teor2345/tor.git
 for fixes to these 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] #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:  6
   |Sponsor:  SponsorR-must
---+---

Comment (by teor):

 I've split off everything that hasn't been included in
 dgoulet/ticket16943_029_02 into child tickets.

 Here's what has happened to T1-T9 and my branch sr-commit-fixes:

 37655c1 Improve log messages for SR commit lines (T5)
 has been fixup'd into another commit in dgoulet/ticket16943_029_02

 520e14f Fix a bug in shared random version parsing on 32-bit platforms
 (T6)
 has been fixup'd into another commit in dgoulet/ticket16943_029_02

 2fd8a21 Consistently use uint32_t for integers in shared random structs
 (T7)
 Split off into #19126, rebased on the latest dgoulet/ticket16943_029_02

 d6487a3 Silence a clang warning about shared random buffer sizes (T1)
 issue was fixed by b9b9022 prop250: Pass the dst length to sr_srv_encode()

 bc7160c Make a shared random log message easier to understand (T3)
 has been fixup'd into another commit in dgoulet/ticket16943_029_02

 add23bd Move the SR flag to the same place as the other SR ns string
 constants
 has been fixup'd into another commit in dgoulet/ticket16943_029_02

 3731984 Don't crash authorities when they have 254 or more shared random
 reveals
 Split off into #19126

 8a84070 Sort commits in lexicographical order in votes (T4)
 cherry-picked as 4d956a6 prop250: Sort commits in lexicographical order in
 votes

 The unit test fixes in ticket16943_029_02 have a bug on platforms where
 time_t is 32 bit (T9)
 Split off into #19125

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

Re: [tor-bugs] #19124 [Core Tor/Tor]: Shared Random and Half-Hour Consensuses

[Tor Bug Tracker & Wiki]

#19124: Shared Random and Half-Hour Consensuses
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #16943| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 So what happened is:
 `cat debug.log | grep 'Current phase is'`
 {{{
 May 19 00:00:01.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 05:00:00). Current phase is reveal (3 commit & 3
 reveal rounds).
 May 19 01:00:01.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 06:00:00). Current phase is commit (1 commit & 0
 reveal rounds).
 May 19 02:00:01.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 07:00:00). Current phase is commit (2 commit & 0
 reveal rounds).
 May 19 03:00:01.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 08:00:00). Current phase is commit (3 commit & 0
 reveal rounds).
 May 19 04:00:01.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 09:00:00). Current phase is reveal (3 commit & 1
 reveal rounds).
 May 19 10:17:11.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 15:00:00). Current phase is reveal (3 commit & 2
 reveal rounds).
 May 19 11:31:10.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 16:00:00). Current phase is reveal (3 commit & 3
 reveal rounds).
 May 19 12:03:10.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 17:00:00). Current phase is reveal (3 commit & 4
 reveal rounds).
 May 19 13:00:01.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 18:00:00). Current phase is commit (1 commit & 0
 reveal rounds).
 May 19 14:00:01.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 19:00:00). Current phase is commit (2 commit & 0
 reveal rounds).
 }}}

 The "3 commit & 4 reveal rounds" is obviously wrong, but it recovers in
 the next round.

 Also, the "11:31:10.000 [info] sr_state_update: SR: State prepared for new
 voting period (2016-05-19 16:00:00)" is correct. But I wonder what would
 have happened at 11:00 had tje authority been awake at that time. Would it
 have prepared state with the same valid-after time "2016-05-19 16:00:00"?
 Is this a bug?

 How do we get rounds and valid-after times working correctly when one or
 more authorities is voting on the half-hour because they don't have a
 recent consensus?

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

Re: [tor-bugs] #17773 [Core Tor/Tor]: Should clients avoid using guards that lost the Guard flag?

[Tor Bug Tracker & Wiki]

#17773: Should clients avoid using guards that lost the Guard flag?
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  medium?
 Reviewer:|Sponsor:  None
--+--

Comment (by teor):

 What if the guard changes keys?
 Does the client mark it as down, and use another guard?
 (Related to #19074.)

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

Re: [tor-bugs] #17773 [Core Tor/Tor]: Should clients avoid using guards that lost the Guard flag?

[Tor Bug Tracker & Wiki]

#17773: Should clients avoid using guards that lost the Guard flag?
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  medium?
 Reviewer:|Sponsor:  None
--+--

Comment (by arma):

 What's *supposed* to happen is that the client decides that it's guard
 isn't Running anymore, so it moves on to another one, but it keeps the
 first one around for some months in case it comes back.

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

Re: [tor-bugs] #17372 [Core Tor/Tor]: Use Guard as Fallback Directory

[Tor Bug Tracker & Wiki]

#17372: Use Guard as Fallback Directory
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Is this the same ticket as #7798?

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

Re: [tor-bugs] #18084 [Core Tor/Tor]: Use the same fallback directory mirror to bootstrap

[Tor Bug Tracker & Wiki]

#18084: Use the same fallback directory mirror to bootstrap
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #7798 | Points:  medium/large
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * parent:   => #7798


Comment:

 #7798 might achieve this without some of the drawbacks.

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

Re: [tor-bugs] #19128 [Core Tor/Tor]: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING failed; aborting.

[Tor Bug Tracker & Wiki]

#19128: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING
failed; aborting.
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Blocker  |Version:  Tor:
 Keywords:  must-fix-before-028-alpha|  0.2.8.2-alpha
  TorCoreTeam201605  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => must-fix-before-028-alpha TorCoreTeam201605
 * priority:  Medium => High
 * severity:  Normal => Blocker
 * milestone:   => Tor: 0.2.8.x-final


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

[tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 On moria1, git 249f3a16
 {{{
 #0  0x7f8412479625 in raise () from /lib64/libc.so.6
 #1  0x7f841247ae05 in abort () from /lib64/libc.so.6
 #2  0x7f8413caee1d in __subvdi3 ()
 #3  0x7f8413c5ddc0 in round_int64_to_next_multiple_of (number=72742,
 divisor=1024) at src/common/util.c:523
 #4  0x7f8413b7d004 in rep_hist_format_hs_stats (now=1463682482)
 at src/or/rephist.c:3074
 #5  rep_hist_hs_stats_write (now=1463682482) at src/or/rephist.c:3122
 #6  0x7f8413b4b3f8 in write_stats_file_callback (now=1463682482,
 options=0x7f84146c6880) at src/or/main.c:1761
 #7  0x7f8413b60ef0 in periodic_event_dispatch (fd=,
 what=, data=0x7f8413f4b260) at
 src/or/periodic.c:52
 #8  0x7f841323cb44 in event_base_loop () from
 /usr/lib64/libevent-1.4.so.2
 #9  0x7f8413b48e2a in run_main_loop_once () at src/or/main.c:2548
 #10 run_main_loop_until_done () at src/or/main.c:2592
 #11 do_main_loop () at src/or/main.c:2520
 #12 0x7f8413b49ec5 in tor_main (argc=,
 argv=) at src/or/main.c:3647
 #13 0x7f8413b45ec9 in main (argc=,
 argv=) at src/or/tor_main.c:30
 (gdb) up
 #1  0x7f841247ae05 in abort () from /lib64/libc.so.6
 (gdb) up
 #2  0x7f8413caee1d in __subvdi3 ()
 (gdb) up
 #3  0x7f8413c5ddc0 in round_int64_to_next_multiple_of (number=72742,
 divisor=1024) at src/common/util.c:523
 523   if (INT64_MAX - divisor + 1 < number)
 }}}

 Looks like it's in the "add noise when reporting the number of onion
 addresses it's seen" area.

 I do have a couple of local patches applied to moria1, but "surely" they
 aren't interacting with this bug.

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

 * reviewer:   => asn


Comment:

 Useful patch! Assigning myself as the reviewer.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19129 [Core Tor/Tor]: Allow Fallback Directories with no DirPort

[Tor Bug Tracker & Wiki]

#19129: Allow Fallback Directories with no DirPort
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #7798
   Points:  2 |   Reviewer:
  Sponsor:|
--+--
 In #12538, we made almost every relay support begindir-style directory
 fetches. In #18483, we made clients never use DirPorts. Both of these
 features are scheduled for 0.2.8.

 Eventually, we can allow fallback directories with no DirPort.
 (Perhaps this works already with a zero DirPort?)
 If we implement #7798, we might want this feature, but only for directory
 guards in the state file.

 If we want to include fallback directories with no DirPort in the default
 fallback list, we will need to make some some changes to the fallback
 directory checks in scripts/maint/updateFallbackDirs.py. In particular,
 stem can't do begindir, so it will be harder to verify these fallback
 directories have connectivity and support begindir. So maybe we should
 require a DirPort for fallback directories for 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] #19128 [Core Tor/Tor]: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING failed; aborting.

[Tor Bug Tracker & Wiki]

#19128: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING
failed; aborting.
--+
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 git 2b8ba551d3eab2793214ab34a1c9a47a888402cd at a hardened stable Gentoo :

 {{{
 May 19 20:03:46.000 [err] tor_assertion_failed_(): Bug:
 src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING failed;
 aborting. (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: Assertion sz < SIZE_T_CEILING failed in
 memwipe at src/common/crypto.c:3039. Stack trace: (on Tor 0.2.8.2-alpha-
 dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(log_backtrace+0x55)
 [0x64843e1715] (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug:
 /usr/bin/tor(tor_assertion_failed_+0x9c) [0x64843f145c] (on Tor 0.2.8.2
 -alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(memwipe+0xbf)
 [0x648440654f] (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(tor_cert_free+0x43)
 [0x6484341ca3] (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(routerinfo_free+0x102)
 [0x6484329a92] (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(+0x8bbcd) [0x6484329bcd]
 (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug:
 /usr/bin/tor(router_add_to_routerlist+0x75d) [0x648432b3dd] (on Tor
 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug:
 /usr/bin/tor(router_load_routers_from_string+0x183) [0x648432ee53] (on Tor
 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(+0x113d14) [0x64843b1d14]
 (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug:
 /usr/bin/tor(connection_dir_reached_eof+0x3c) [0x64843b27ac] (on Tor
 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(+0xf2779) [0x6484390779]
 (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(+0x40024) [0x64842de024]
 (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug:
 /usr/lib64/libevent-2.0.so.5(event_base_loop+0x6dd) [0x3cd7614671d] (on
 Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(do_main_loop+0x235)
 [0x64842df0c5] (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(tor_main+0x1b35)
 [0x64842e2745] (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(main+0x2b) [0x64842da6ab]
 (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug:
 /lib64/libc.so.6(__libc_start_main+0x114) [0x3cd74e40734] (on Tor 0.2.8.2
 -alpha-dev 684babee8491c3e9)
 May 19 20:03:46.000 [err] Bug: /usr/bin/tor(_start+0x29)
 [0x64842da6f9] (on Tor 0.2.8.2-alpha-dev 684babee8491c3e9)
 }}}

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

Re: [tor-bugs] #7798 [Core Tor/Tor]: Use directory guards even when consensus isn't live

[Tor Bug Tracker & Wiki]

#7798: Use directory guards even when consensus isn't live
--+---
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * status:  new => needs_information


Comment:

 Replying to [comment:1 arma]:
 > Agreed!
 >
 > I wonder how this should relate to the fallbackdir design now that there
 is one.
 >
 > Can we add the directory guards from our state file to the fallbackdir
 list, with higher priority than the other ones on the list?

 There is no priority in the fallback directory design, there is only
 weight.
 But I think this is a nice way of resolving the privacy issues mentioned
 in #18084.

 What we could do is add to the state file one or more `FallbackDir` lines
 describing our directory guards. The format is `address:port orport=port
 id=fingerprint [ipv6=ipv6address:ipv6orport] [weight=num]`. The fallbacks
 will have to have a DirPort, even though clients never use it (see
 #19129). (We're only doing this for clients, right?)

 The current total fallback weight is 1009 (10*100 + 1*9), but it could go
 as high as ~3000 if we ever include 300 fallbacks, as in the original "20%
 of guards" design.

 We might have 3 directory guards, or in future, we might only have 1.
 So let's weight each directory guard at 10,000. Then we will only choose a
 fallback 10% of the time. (Or 3% of the time with 3 directory guards.)

 Then, when we load the state file, we use our standard fallback parsing
 function to add them to the list. And our standard bootstrapping sequence
 will use them like any other fallbacks.

 Should we do this automatically, or should their be an option to turn it
 off?
 The existing `UseDefaultFallbackDirs` doesn't really cover this, so we
 probably need `UseDirGuardsAsFallbackDirs`. (This should control both the
 writing to the state file, and the reading from it.) This way, someone can
 refuse the default fallbacks, but still use their directory guards as
 fallbacks.

 When should these fallback directory guards expire?
 (When do guards in our state file expire?)
 If they're too old, we should ignore them and just try the fallbacks.

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

Re: [tor-bugs] #19129 [Core Tor/Tor]: Allow Fallback Directories with no DirPort

[Tor Bug Tracker & Wiki]

#19129: Allow Fallback Directories with no DirPort
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #7798 | Points:  2
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Yup. If somebody wanted to write a Stem patch so it could retrieve
 directory information from the ORPort I'd love to have that. Haven't a
 clue how difficult it would be though.

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

Re: [tor-bugs] #17372 [Core Tor/Tor]: Use Guard as Fallback Directory

[Tor Bug Tracker & Wiki]

#17372: Use Guard as Fallback Directory
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


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

Re: [tor-bugs] #19078 [Applications/Tor Browser]: Disable RtspMediaResource stuff in OrFox

[Tor Bug Tracker & Wiki]

#19078: Disable RtspMediaResource stuff in OrFox
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:   => tbb-team
 * keywords:  amoghbl1, n8fr8 => tbb-mobile
 * component:  Applications => Applications/Tor Browser
 * cc: amoghbl1, n8fr8 (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] [Tor Bug Tracker & Wiki] Batch modify: #18864, #19076, #19077

[Tor Bug Tracker & Wiki]

Batch modification to #18864, #19076, #19077 by gk:
keywords to tbb-mobile
component to Applications/Tor Browser

--
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] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by asn):

 Yawning suggests this is a signed int overflow that leads to an abort
 because of ftrapv (#17983).

 The overflow happens at:
 {{{
   if (INT64_MAX - divisor + 1 < number)
 return INT64_MAX;
 }}}
 whose left side probably gets applied as `INT64_MAX + 1 - divisor`.

 A potential fix here would be to reorder that if statement to:
 {{{
   if (INT64_MAX - number < divisor - 1)
 return INT64_MAX;
 }}}
 maybe with an additional check that `divisor >= 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] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by asn):

 (It might also be worth considering what happened in the past before
 ftrapv. Did that check actually ever overflow and return `INT64_MAX`?
 Maybe in some platforms? This could in theory influence HS stats.)

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

Re: [tor-bugs] #18798 [Metrics/CollecTor]: analysis of descriptor completeness

[Tor Bug Tracker & Wiki]

#18798: analysis of descriptor completeness
---+---
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by iwakeh):

 a quick overview of 48 hours of missing referenced descs on a new instance
 can be found
 [wiki:doc/CollecTor/AnalysisDescriptorCompletenessFromScratch 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] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Replying to [comment:1 asn]:
 > Yawning suggests this is a signed int overflow that leads to an abort
 because of ftrapv (#17983).
 >
 > The overflow happens at:
 > {{{
 >   if (INT64_MAX - divisor + 1 < number)
 > return INT64_MAX;
 > }}}
 > whose left side probably gets applied as `INT64_MAX + 1 - divisor`.

 Optimising compilers FTW.

 >
 > A potential fix here would be to reorder that if statement to:
 > {{{
 >   if (INT64_MAX - number < divisor - 1)
 > return INT64_MAX;
 > }}}

 That will overflow if number is negative, and I'm pretty sure it's the
 wrong comparison.
 Did you mean:

 {{{
   if (INT64_MAX - divisor < number - 1)
 return INT64_MAX;
 }}}

 > maybe with an additional check that `divisor >= 1`.

 The function already does the equivalent: `tor_assert(divisor > 0);`

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

Re: [tor-bugs] #19073 [Core Tor/Tor]: Remove duplicate signing_cert field from extrainfo and routerinfo.

[Tor Bug Tracker & Wiki]

#19073: Remove duplicate signing_cert field from extrainfo and routerinfo.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+

Comment (by toralf):

 likely that the issue is uncovered by something in ef03dc0..2b8ba55

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

Re: [tor-bugs] #19128 [Core Tor/Tor]: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING failed; aborting.

[Tor Bug Tracker & Wiki]

#19128: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING
failed; aborting.
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Blocker  |Version:  Tor:
 Keywords:  must-fix-before-028-alpha|  0.2.8.2-alpha
  TorCoreTeam201605  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by toralf):

 likely that the issue is uncovered by something in ef03dc0..2b8ba55

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

Re: [tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 We'd also need to `tor_assert(number >= INT64_MIN + 1);`

 But wait, the later statements would still invoke undefined behaviour, so
 the compiler would be free to reach back in time and remove our asserts!

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

Re: [tor-bugs] #19125 [Core Tor/Tor]: Fix a time parsing error on platforms with 32 bit time_t

[Tor Bug Tracker & Wiki]

#19125: Fix a time parsing error on platforms with 32 bit time_t
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201605  | Resolution:
Parent ID:  #16943 |  Actual Points:  0.1
 Reviewer: | Points:  0.1
   |Sponsor:
---+---
Changes (by nickm):

 * 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] #19125 [Core Tor/Tor]: Fix a time parsing error on platforms with 32 bit time_t

[Tor Bug Tracker & Wiki]

#19125: Fix a time parsing error on platforms with 32 bit time_t
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.9.x-final
 Severity:  Normal |Version:
 Keywords:  tor-hs, TorCoreTeam201605  | Resolution:
Parent ID:  #16943 |  Actual Points:  0.1
 Reviewer: | Points:  0.1
   |Sponsor:
---+---
Changes (by nickm):

 * 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] #19073 [Core Tor/Tor]: Remove duplicate signing_cert field from extrainfo and routerinfo.

[Tor Bug Tracker & Wiki]

#19073: Remove duplicate signing_cert field from extrainfo and routerinfo.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 merged to maint-0.2.8 and forward.

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

Re: [tor-bugs] #19073 [Core Tor/Tor]: Remove duplicate signing_cert field from extrainfo and routerinfo.

[Tor Bug Tracker & Wiki]

#19073: Remove duplicate signing_cert field from extrainfo and routerinfo.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:  fixed
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 merged to maint-0.2.8 and forward.

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

Re: [tor-bugs] #19128 [Core Tor/Tor]: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING failed; aborting.

[Tor Bug Tracker & Wiki]

#19128: Bug: src/common/crypto.c:3039: memwipe: Assertion sz < SIZE_T_CEILING
failed; aborting.
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Blocker  |Version:  Tor:
 Keywords:  must-fix-before-028-alpha|  0.2.8.2-alpha
  TorCoreTeam201605  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by nickm):

 I merged #19073, which might fix this, or might not.

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

Re: [tor-bugs] #19079 [Core Tor/Tor]: clang -m32 -ftrapv seems buggy with 64-bit signed integer multiply

[Tor Bug Tracker & Wiki]

#19079: clang -m32 -ftrapv seems buggy with 64-bit signed integer multiply
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorCoreTeam201605  |  Actual Points:  .1
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 I'm assuming that the llvm source is okay. :)  Merging to master.

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

Re: [tor-bugs] #19122 [Core Tor/Tor]: Documentation for "User" option specifies wrong kind of argument

[Tor Bug Tracker & Wiki]

#19122: Documentation for "User" option specifies wrong kind of argument
--+--
 Reporter:  chadmiller|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * milestone:   => Tor: 0.2.???


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

Re: [tor-bugs] #19120 [Core Tor/Tor]: Integrate and remove Clang hardening instructions

[Tor Bug Tracker & Wiki]

#19120: Integrate and remove Clang hardening instructions
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by nickm):

 * keywords:   => 029-proposed


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

Re: [tor-bugs] #19073 [Core Tor/Tor]: Remove duplicate signing_cert field from extrainfo and routerinfo.

[Tor Bug Tracker & Wiki]

#19073: Remove duplicate signing_cert field from extrainfo and routerinfo.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks sensible to me. It's really just a search and replace, apart from
 that one point where you remove whitespace before a comment.

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

Re: [tor-bugs] #19074 [Core Tor/Tor]: Mark fallback directories down when their key is wrong

[Tor Bug Tracker & Wiki]

#19074: Mark fallback directories down when their key is wrong
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Normal   |Version:
 Keywords:  must-fix-before-0283, must-fix-  | Resolution:
  before-028-rc  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * parent:  #18809 =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  teor
 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
  TorCoreTeam201605, review-group-1,   must- | Resolution:  fixed
  fix-before-0283|  Actual Points:  4
Parent ID:   | Points:  3
 Reviewer:  andrea   |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

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


Comment:

 Both fixes merged. 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] #19131 [- Select a component]: Tor Browser Bundle Crash

[Tor Bug Tracker & Wiki]

#19131: Tor Browser Bundle Crash
--+-
 Reporter:  eh|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 "Tor unexpectedly exited. This might be due to a bug in Tor itself,
 another program on your system, or faulty hardware. Until you restart Tor,
 the Tor Browser will not be able to reach any websites. If the problem
 persists, please send a copy of your Tor Log to the support team.

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

Re: [tor-bugs] #18996 [Applications/Tor Browser]: Investigate server logging in ESR45

[Tor Bug Tracker & Wiki]

#18996: Investigate server logging in ESR45
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff45-esr  |  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

Re: [tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by asn):

 * status:  new => needs_review


Comment:

 Let's move this forward. Please see my branch `bug19130` for the fix
 suggested by teor in comment:3 .

 It changes the check to:
 {{{
   if (INT64_MAX - divisor < number - 1)
 return INT64_MAX;
 }}}

 Are there additional check that need to be added?

 Also, should we fix the other `round_*_to_next_multiple_of()` functions
 which have a similar pattern? They deal with unsigned integers where an
 overflow is not UB; but maybe we should not cause overflows on purpose
 anyway.

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

Re: [tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

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


Comment:

 `number - 1` can underflow if `number` is `INT64_MIN`.
 So we need to skip the overflow check in that case.

 How about:
 {{{
 if (number > INT64_MIN)
   if (INT64_MAX - divisor < number - 1)
 return INT64_MAX;
 }}}

 Otherwise this looks good, and yes, it would be sensible to explicitly
 handle overflow and underflow, rather than leaving it to the whims of
 compilers.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19132 [Core Tor/Tor]: shared random: missing field 'fetch_missing_votes' initializer

[Tor Bug Tracker & Wiki]

#19132: shared random: missing field 'fetch_missing_votes' initializer
--+
 Reporter:  teor  |  Owner:
 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:  #16943
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 dgoulet's ticket16943_029_02 fails to compile on OS X with `Apple LLVM
 version 7.3.0 (clang-703.0.31)`:
 {{{
 src/or/dirvote.c:2547:46: error: missing field 'fetch_missing_votes'
 initializer
   [-Werror,-Wmissing-field-initializers]
 }}}

 Even though this is perfectly legal C for "initialise the whole structure
 to zero".

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

Re: [tor-bugs] #19126 [Core Tor/Tor]: Consistently use uint32_t for integers in shared random structs

[Tor Bug Tracker & Wiki]

#19126: Consistently use uint32_t for integers in shared random structs
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #16943| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => 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] #19127 [Core Tor/Tor]: Don't crash authorities with more than 254 shared random reveals

[Tor Bug Tracker & Wiki]

#19127: Don't crash authorities with more than 254 shared random reveals
+--
 Reporter:  teor|  Owner:
 Type:  defect  | Status:
 Priority:  Medium  |  needs_review
Component:  Core Tor/Tor|  Milestone:  Tor:
 Severity:  Normal  |  0.2.9.x-final
 Keywords:  tor-hs, 029-proposed, assert-crash  |Version:
Parent ID:  #16943  | Resolution:
 Reviewer:  |  Actual Points:  0.5
| Points:  0.5
|Sponsor:
+--
Changes (by teor):

 * status:  new => 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] #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:  6
   |Sponsor:  SponsorR-must
---+---

Comment (by teor):

 Logged #19132 for a missing initialiser error in clang.

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

Re: [tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+--
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Let me suggest a simpler fix: Nothing actually uses this function in a
 sane way!  It's only called twice, and when it's called, it's given an
 inputs that can't be negative.

 How do we feel about `bug19130_the_easy_way` ?

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

Re: [tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Well, avoiding using signed integers is one way to avoid signed overflow.
 And we can deal with the unsigned overflow in the other functions in
 another ticket, if asn wants to.

 Let's get the easy way merged.

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

[tor-bugs] #19133 [Core Tor/Tor]: Clarify how INT_N truncates values

[Tor Bug Tracker & Wiki]

#19133: Clarify how INT_N truncates values
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  torspec tor-hs
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 We've assumed that INT_1(x), where x is an integer, means `x % 256`.
 We should make this explicit.

 https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-
 ng.txt#n146

 https://github.com/eewayhsu/tor-
 project/commit/443a3bd64096b36bbfe711ca9b43c52ccb5442dc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19134 [Core Tor/Tor]: Shared Random: INT_8 means 8 bytes, not 8 bits

[Tor Bug Tracker & Wiki]

#19134: Shared Random: INT_8 means 8 bytes, not 8 bits
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:  #16943
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 generate_srv should take 8 bytes of reveal_num and version, not 8 bits.

 This is going to require a synchronous upgrade of our test network, isn't
 it?

 It will also require a htonll() that works on all platforms, which we
 don't currently have. We should move the htonll() code from test_util.c to
 util.c.

 (And arma shouldn't deploy shared random until this is done, right?)

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

Re: [tor-bugs] #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:  6
   |Sponsor:  SponsorR-must
---+---

Comment (by teor):

 I just split off #19134 because we're doing the SRV hash wrong: we're
 meant to use 8 bytes of reveal_num and version in network order, not 8
 bits. This obsoletes #19126.

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

Re: [tor-bugs] #19126 [Core Tor/Tor]: Consistently use uint32_t for integers in shared random structs

[Tor Bug Tracker & Wiki]

#19126: Consistently use uint32_t for integers in shared random structs
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #16943| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 Obsoleted by #19134, because the spec says 8 bytes of reveal_num, not 8
 bits.

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

Re: [tor-bugs] #19134 [Core Tor/Tor]: Shared Random: INT_8 means 8 bytes, not 8 bits

[Tor Bug Tracker & Wiki]

#19134: Shared Random: INT_8 means 8 bytes, not 8 bits
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #16943| Points:  0.5
 Reviewer:|Sponsor:
--+
Description changed by teor:

Old description:

> generate_srv should take 8 bytes of reveal_num and version, not 8 bits.
>
> This is going to require a synchronous upgrade of our test network, isn't
> it?
>
> It will also require a htonll() that works on all platforms, which we
> don't currently have. We should move the htonll() code from test_util.c
> to util.c.
>
> (And arma shouldn't deploy shared random until this is done, right?)

New description:

 generate_srv should take 8 bytes of reveal_num and version, not 8 bits.

 This is going to require a synchronous upgrade of our test network, isn't
 it?

 ~~It will also require a htonll() that works on all platforms, which we
 don't currently have. We should move the htonll() code from test_util.c to
 util.c.~~

 We have tor_htonll() to convert to network/big-endian byte order.

 (And arma shouldn't deploy shared random until this is done, right?)

--

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

Re: [tor-bugs] #18967 [Metrics/Onionoo]: Add UUID to families in Onionoo

[Tor Bug Tracker & Wiki]

#18967: Add UUID to families in Onionoo
-+-
 Reporter:  seansaito|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  persistence, |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by virgil):

 > Would you two want to suggest a UUID algorithm based only on server
 descriptors published in the past `k` hours?

 I looked into candidate designs for this.  In short, the `k` hours model
 entails there will be no persistence beyond `k` hours.  And even for
 values like `k=48`, I presume want UUIDs to last longer than 2 days.  It
 just becomes a 48-hour delay before "use the largest fingerprint".

 We could in fact do this, but whenever a the highest fingerprint of a
 family changes, it's going to have its points reset.

 I thought about this a bit more.  But if we aren't going back to an
 established beginning, everytime a new Onionoo server joins, it will have
 a different perception of what the families are.  I see no way around this
 without a central-server or blockchain-like infrastructure.

 It may be that we simply have to go with the highest fingerprint.  This is
 unfortunate.

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

Re: [tor-bugs] #19118 [Metrics/Onionoo]: Add organization name to each relay

[Tor Bug Tracker & Wiki]

#19118: Add organization name to each relay
-+---
 Reporter:  virgil   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  hardening|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by virgil):

 As far as I can tell, the OVH example you gave is, by happenstance, an
 instance where the CAIDA data is superior.

 Lets look at:

 > `ORG-OS3-RIPE||OVH SAS|FR|RIPE`
 > `16276||OVH|ORG-OS3-RIPE|RIPE`
 > `35540||OVH-TELECOM|ORG-OS3-RIPE|RIPE`

 For these entries, CAIDA says that *the same organization* with id=`ORG-
 OS3-RIPE`, owns both AS16276 and AS35540.

 When you look up OVH on MaxMind, you get only AS16276.  In this case I
 believe the issue is that when you look at the raw records, AS16276 has
 as-name `OVH` while AS35540 has as-name `OVH-TELECOM`.  Ergo on a plain-
 text matching they are not the same.  The CAIDA data squashes these two
 distinct strings into the same organization id, and thus into the same
 organization name.


 Going beyond this specific case, the CAIDA data does some cleverness (see
 http://www.caida.org/research/topology/as2org/ for the methodology) to
 determine who the "real organization" is who owns the AS-number.  This is
 helpful when firm A purchases firm B, and then firm A becomes an upstream
 provider of firm B [making firm B part of firm A's "cone"].  In the CAIDA
 data it would list firm B.  In the CAIDA data it would list firm A.

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

Re: [tor-bugs] #13017 [Applications/Tor Browser]: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

[Tor Bug Tracker & Wiki]

#13017: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting 
vector
-+--
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  tbb-fingerprinting-os, tbb-easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mo):

 * severity:   => Blocker


Comment:

 "This page tests browser-fingerprinting using the AudioContext and Canvas
 API. Using the AudioContext API to fingerprint does not collect sound
 played or recorded by your machine - an AudioContext fingerprint is a
 property of your machine's audio stack itself. "

 https://audiofingerprint.openwpm.com/

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

Re: [tor-bugs] #13017 [Applications/Tor Browser]: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

[Tor Bug Tracker & Wiki]

#13017: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting 
vector
-+--
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os, tbb-easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mo):

 * severity:  Blocker => Normal


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

Re: [tor-bugs] #18967 [Metrics/Onionoo]: Add UUID to families in Onionoo

[Tor Bug Tracker & Wiki]

#18967: Add UUID to families in Onionoo
-+-
 Reporter:  seansaito|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  persistence, |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 What about the fingerprint with the oldest claimed time of appearance
 (first descriptor - uptime)?
 That would likely be more stable than the highest fingerprint.
 It wouldn't be perfect if new onionoo servers joined, but it would be
 close.

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

Re: [tor-bugs] #19013 [Core Tor/Tor]: Authorities shouldn't warn about reachability

[Tor Bug Tracker & Wiki]

#19013: Authorities shouldn't warn about reachability
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  new
 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.2-alpha
  TorCoreTeam201605, logging | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  1
 |Sponsor:
-+-

Comment (by teor):

 They also shouldn't try to test their own reachability, or should they?

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

Re: [tor-bugs] #18195 [Applications/Tor Browser]: Add a flag to identify Tor Browser in JS

[Tor Bug Tracker & Wiki]

#18195: Add a flag to identify Tor Browser in JS
--+--
 Reporter:  pento |  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 pento):

 Hey folks, is there any update on if this would be possible?

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

Re: [tor-bugs] #13017 [Applications/Tor Browser]: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

[Tor Bug Tracker & Wiki]

#13017: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting 
vector
-+--
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os, tbb-easy  |  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

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:
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:
-+-
Changes (by arthuredelstein):

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


Comment:

 Here's a patch to fix the problem.

 https://github.com/arthuredelstein/tor-browser/commit/18811+3
 94fa4b050a1252914c57e59c747d4c9342cdf2cb

 Unfortunately I had to resort to making the blob URL a special case to
 undo the Tor Browser regression caused by the Mozilla patch mentioned in
 the description. I considered various alternatives but didn't find a
 better solution -- at least the change here is localized. Mozilla is
 working on blob isolation using origin attributes, so hopefully a cleaner
 solution will emerge from that approach.

 The problem reported in this ticket was originally revealed by two failing
 tests in
 `./mach mochitest dom/base/test/test_tor_bug15502.html`

 After this patch is applied, the tests all 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

Re: [tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+-

Comment (by cypherpunks):

 `rounded_cells_seen` is now uint64_t but `rounded_onions_seen` is still
 int64_t. Shouldn't the later also be uint64_t?

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

Re: [tor-bugs] #19131 [Applications/Tor Browser]: Tor Browser Bundle Crash

[Tor Bug Tracker & Wiki]

#19131: Tor Browser Bundle Crash
--+--
 Reporter:  eh|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * owner:   => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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