Re: [tor-bugs] #18608 [Core Tor/Tor]: Limiting ADD_ONION TARGET access.

[Tor Bug Tracker & Wiki]

#18608: Limiting ADD_ONION TARGET access.
-+--
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, control  |  Actual Points:
Parent ID:   | Points:  smally
 Reviewer:   |Sponsor:  SponsorR-can
-+--

Comment (by cypherpunks):

 We don't want these deanonymization scenarios happening, do we?

 add_onion new:best port=80,fbi.gov
 add_onion new:best port=80,cmu.edu

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_information


Comment:

 I have lost track of this one. I made some changes. Shari maybe asked for
 some more changes. I am a bad person to lead this web page thing.

 If anybody still wants changes, please find somebody to do them. :)

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

Re: [tor-bugs] #18982 [Core Tor/Tor]: Tor should log 1-based hop numbers

[Tor Bug Tracker & Wiki]

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

 * keywords:  easy, logging, 029-nickm-says-yes, review-group-2 => easy,
 logging, 029-nickm-says-yes, review-group-2, CoreTorTeam201606


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

Re: [tor-bugs] #19152 [Core Tor/Tor]: use-after-free on failing RSA_generate_key_ex()

[Tor Bug Tracker & Wiki]

#19152: use-after-free on failing RSA_generate_key_ex()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  027-backport must-fix-   |Version:
  before-028-alpha CoreTorTeam201606 | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:  arma | Points:
 |Sponsor:
-+-

Comment (by arma):

 Ok: the bug reporter wants to be credited as "Yuan Jochen Kang, Suman
 Jana, and Baishakhi Ray".

 The bug reporter also confirms that the patch looks good.

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

Re: [tor-bugs] #19166 [Core Tor/Tor]: HS connections randomly fail

[Tor Bug Tracker & Wiki]

#19166: HS connections randomly fail
--+--
 Reporter:  TvdW  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorR-can
--+--
Changes (by arma):

 * sponsor:   => SponsorR-can
 * milestone:   => Tor: 0.2.???


Comment:

 Ok. The summary of the client-side log appears to be that it receives the
 socks request, finds an already-established rendezvous circuit, sends the
 begin cell, and I didn't see for sure if it got any answer because right
 about then it decided to fetch a new consensus and once it got the
 consensus it decided to fetch the new microdescriptors it learned about.

 If you would set up boring clients and onion services that don't do
 anything else, and set {{{safelogging 0}}} and {{{LogTimeGranularity 1}}}
 on both sides, we'll be in a better position to debug next time.

 Thanks!

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

Re: [tor-bugs] #19152 [Core Tor/Tor]: use-after-free on failing RSA_generate_key_ex()

[Tor Bug Tracker & Wiki]

#19152: use-after-free on failing RSA_generate_key_ex()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  027-backport must-fix-   |Version:
  before-028-alpha CoreTorTeam201606 | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:  arma | Points:
 |Sponsor:
-+-
Changes (by arma):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #19152 [Core Tor/Tor]: use-after-free on failing RSA_generate_key_ex()

[Tor Bug Tracker & Wiki]

#19152: use-after-free on failing RSA_generate_key_ex()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  027-backport must-fix-   |Version:
  before-028-alpha CoreTorTeam201606 | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:  arma | Points:
 |Sponsor:
-+-
Changes (by arma):

 * keywords:  027-backport must-fix-before-028-alpha => 027-backport must-
 fix-before-028-alpha CoreTorTeam201606
 * reviewer:   => arma


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

Re: [tor-bugs] #19152 [Core Tor/Tor]: use-after-free on failing RSA_generate_key_ex()

[Tor Bug Tracker & Wiki]

#19152: use-after-free on failing RSA_generate_key_ex()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  027-backport must-fix-   |Version:
  before-028-alpha   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by arma):

 s/failes/fails/

 "exactly when to"...?

 The commit log starts with "let me walk through my analysis" rather than
 explaining what the issue is or what the fix is. Re-using some of the text
 from the changes file would be helpful, to give context to the person who
 is reading (since you clearly are intending for people to read this commit
 log). Like, you start talking about a non-engine case before I knew
 engines were involved.

 The patch itself looks good to me.

 I've mailed the original bug reporter so he can look it over too if he
 wants.

 Thanks!

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

Re: [tor-bugs] #19166 [Core Tor/Tor]: HS connections randomly fail

[Tor Bug Tracker & Wiki]

#19166: HS connections randomly fail
--+--
 Reporter:  TvdW  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Can you reproduce this bug on quiet hidden services and quiet clients?

 Or do they need to be active?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19167 [Core Tor/Tor]: torrc parsing b0rks on carriage-return

[Tor Bug Tracker & Wiki]

#19167: torrc parsing b0rks on carriage-return
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Windows still terminates text files with '\r\n' by default, this seems to
 break the handling of quoted values in torrc.

 https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n2899

 It consumes the quoted string, then consumes any trailing whitespace (tabs
 or spaces), then it expects either a comment '#' or an '\n'. However if a
 file edited through notepad.exe for example, the first character it
 encounters would be '\r', preceding the '\n'.

 This results in tor throwing: "[warn] Error while parsing configuration:
 Excess data after quoted string" then erroring out.

 Testing on 0.2.7.6.

 Steps to reproduce:

 `$ printf "SocksPort 54321\nDataDirectory \"/tmp/datadir\"\r\n" >
 /tmp/conf`
 `$ tor -f /tmp/conf`
 `...[notice] Tor v0.2.7.6 (git-605ae665009853bd) running on Linux with
 Libevent 2.0.21-stable, OpenSSL 1.0.2h and Zlib 1.2.8`
 `...[notice] Tor can't help you if you use it wrong! Learn how to be safe
 at https://www.torproject.org/download/download#warning`
 `...[notice] Read configuration file "/tmp/conf".`
 `...[warn] Error while parsing configuration: Excess data after quoted
 string`
 `...[err] Reading config failed--see warnings above.`
 `$`

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

Re: [tor-bugs] #19166 [Core Tor/Tor]: HS connections randomly fail

[Tor Bug Tracker & Wiki]

#19166: HS connections randomly fail
--+--
 Reporter:  TvdW  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 btw, when i make debug logs, I set
 {{{
 LogTimeGranularity 1
 }}}
 so it's easier to tell which debug statements are grouped with each other.

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

Re: [tor-bugs] #19166 [Core Tor/Tor]: HS connections randomly fail

[Tor Bug Tracker & Wiki]

#19166: HS connections randomly fail
--+--
 Reporter:  TvdW  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by TvdW):

 Potentially relevant:

 * restarting the tor daemon on the client consistently fixes this issue
 * it takes a few minutes after restarting for the issue to appear again,
 not hours
 * occasionally these connections will fail many (10+) times in a row
 * some 60 hosts are monitored, which results in a nice 720 checks per
 hour. Every hour several of these fail, sometimes up to 40

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19166 [Core Tor/Tor]: HS connections randomly fail

[Tor Bug Tracker & Wiki]

#19166: HS connections randomly fail
--+--
 Reporter:  TvdW  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 For the sake of checking whether my bridges are running properly, a
 regular nagios job tries to establish a tcp connection to a HS running on
 each bridge, every 5 minutes. This is done through 'torsocks check_ssh -H
 abcdef.onion -p 22' but the issue in this ticket is reproducible with
 'torsocks nc abcdef.onion 22' as well.

 Connections randomly fail, causing a lot of monitoring noise, though I bet
 that for other users this manifests as hosts being unavailable completely.

 As a test, I restarted tor and waited for a nagios check to fail. I then
 stopped nagios completely, causing tor to be idle, and manually ran a
 single check. The tor debug log, trimmed to the rough timeframe in which I
 ran the check, can be found at https://tvdw.eu/tor-
 debug-2016052422.log

 torsocks says: [May 24 22:00:33] ERROR torsocks[28974]: General SOCKS
 server failure (in socks5_recv_connect_reply() at socks5.c:516)
 (note the timestamp, this failure is visible in tor's logs)

 In my test the client ran Tor 0.2.7.6, and the HS ran 0.2.8.2, though I
 have been able to reproduce this with various tor versions on the HS side.

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

Re: [tor-bugs] #18884 [Applications/Tor Browser]: Rip Firefox Hello Beta / Loop extension in ESR45 based Tor Browser

[Tor Bug Tracker & Wiki]

#18884: Rip Firefox Hello Beta / Loop extension in ESR45 based Tor Browser
-+-
 Reporter:  gk   |  Owner:
 Type:  task |  arthuredelstein
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_revision
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605R, |Version:
  tbb-6.0-must   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by gk):

 Okay, I am waiting with the 6.0 build for this one. I guess we can get it
 going tomorrow then.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ff45-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


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

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

Comment (by mcs):

 Replying to [comment:5 arthuredelstein]:
 > Good question. I added a `dump` statement to the part of the code where
 the "X-ChromeLogger-Data" header value is parsed. I was able to manually
 confirm that this code is not called except when "Server" logging is
 enabled (through the button in the devtools UI, or in the prefs).

 Thanks for investigating. I think this ticket can be closed, assuming gk
 agrees.

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

Re: [tor-bugs] #15994 [Applications/Quality Assurance and Testing]: Running Tor Browser unit tests as part of our gitian-based build process

[Tor Bug Tracker & Wiki]

#15994: Running Tor Browser unit tests as part of our gitian-based build process
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing| Resolution:
 Severity:  Normal   |  Actual Points:
 Keywords:   | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by mcs):

 * cc: brade (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] #18914 [Applications/Tor Browser]: Consider removing

[Tor Bug Tracker & Wiki]

#18914: Consider removing 
-+-
 Reporter:  mcs  |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 This looks good.

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

Re: [tor-bugs] #18718 [Metrics/metrics-lib]: remove last impl. dependency from api

[Tor Bug Tracker & Wiki]

#18718: remove last impl. dependency from api
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * parent:  #18746 =>


Comment:

 Removing parent ID, because this won't go into 1.2.0 but into the next
 major release to be released in the possibly distant future.

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

Re: [tor-bugs] #18746 [Metrics/metrics-lib]: release descriptor 1.2.0 (was: release descriptor 2.0.0)

[Tor Bug Tracker & Wiki]

#18746: release descriptor 1.2.0
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Changing summary to reflect that we're now aiming for releasing version
 1.2.0 rather than 2.0.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] #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 karsten):

 Here are some random ideas why there might be missing referenced
 descriptors on your CollecTor instance:

  1. My CollecTor instance does not download descriptors from
 194.109.206.212, because in May 2014 that directory authority left
 connections open without writing any bytes, and we're not handling
 timeouts very well yet.  I don't expect that to still be the case, but if
 you're seeing log lines with that authority indicating problems, maybe
 take that address out of `DownloadFromDirectoryAuthorities`.
  1. I'm not setting `DownloadAllServerDescriptors` and
 `DownloadAllExtraInfoDescriptors` in my CollecTor instance.  It might be
 that these settings are the cause for your missing numbers going down once
 per day.  Maybe the logs tell you more, or maybe you'll need to add logs
 for whenever your instance downloads all descriptors.  By the way, here's
 what I noted down when I disabled those settings: "By downloading "all"
 descriptors, we only learn the most recent descriptors for all known
 servers, not all known descriptors.  That’s not exactly what we’d expect.
 There’s also a potential problem with the result: the authority’s own
 descriptor ends with a double newline which might confuse metrics-lib;
 unless we split up concatenated descriptors differently in metrics-db.
 Found out both things on May 8, 2014 when looking more into #11648."
  1. I'm also not setting `CompressRelayDescriptorDownloads`.  Here's where
 I noted down why: "2014-04-29: changed to 0, because of
 "java.io.EOFException: Unexpected end of ZLIB input stream"".  I also
 noted down this: "The reason for broken compressed downloads might have
 been #11648, which should be fixed by August/September.  The current
 default in metrics-db for compressing downloads is 0.  That's bad.
 Consider fixing this once all directory authorities have upgraded.  Have
 they?"

 And here are some suggestions for finding out more about the missing
 descriptors:
  - For serverdesc missing (referenced by votes), can you plot how many of
 those are missing by how many votes?  I wouldn't worry so much about
 missing descriptors being referenced from a single vote but more about
 missing descriptors being referenced from (almost) all votes.
  - Regarding the extrainfo missing, have these been published by relays
 that only published a single server descriptor or relays that have been
 around for a longer time?  Again, more worried in the latter case.

 You'll notice that I'm mostly guessing here, because I don't know what
 could be going wrong.  But I think you're in a good position to spot a bug
 or three here.  Thanks for looking into this!

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

Re: [tor-bugs] #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:  nickm
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.2-alpha
 Severity:  Blocker| Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by toralf):

 The issue appeared again after about 20h (expected due to the lower
 bandwidth now).
 Unfortunately I missed to add the "-ex bt" to the gdb command line,
 therefore I just got a
 {{{
 Program received signal SIGFPE, Arithmetic exception.
 0x0313c6d855e1 in tls1_enc (s=0x79e1d5f710, send=1) at t1_enc.c:849
 849 t1_enc.c: No such file or directory.
 }}}
 related to this of debug.log
 {{{
 May 24 19:06:35.000 [debug] conn_write_callback(): socket 622 wants to
 write.

  T= 1464109596
 Tor 0.2.8.2-alpha-dev (git-684babee8491c3e9) died: Caught signal 8
 /usr/bin/tor(+0x1435c9)[0x79dd1c35c9]
 /usr/lib64/libssl.so.1.0.0(tls1_enc+0x1c1)[0x313c6d855e1]
 /usr/lib64/libssl.so.1.0.0(tls1_enc+0x1c1)[0x313c6d855e1]
 /usr/lib64/libssl.so.1.0.0(+0x320fa)[0x313c6d760fa]
 /usr/lib64/libssl.so.1.0.0(ssl3_write_bytes+0xe5)[0x313c6d76555]
 /usr/bin/tor(tor_tls_write+0xa3)[0x79dd1ef7e3]
 /usr/bin/tor(flush_buf_tls+0xbb)[0x79dd128d3b]
 /usr/bin/tor(+0xf2e52)[0x79dd172e52]
 /usr/bin/tor(connection_handle_write+0x43)[0x79dd173813]
 /usr/bin/tor(+0x3fe41)[0x79dd0bfe41]
 /usr/lib64/libevent-2.0.so.5(event_base_loop+0x799)[0x313c6fd4319]
 /usr/bin/tor(do_main_loop+0x235)[0x79dd0c10c5]
 /usr/bin/tor(tor_main+0x1b35)[0x79dd0c4745]
 /usr/bin/tor(main+0x2b)[0x79dd0bc6ab]
 /lib64/libc.so.6(__libc_start_main+0x114)[0x313c5cce734]
 /usr/bin/tor(_start+0x29)[0x79dd0bc6f9]
 }}}
 I do have the debug.log here and can send it via email if needed.
 Currently I do have the following gdb running :
 {{{
 rm nohup.out; nohup gdb -q -p `pgrep tor` -ex "handle SIGPIPE nostop
 ignore noprint" -ex "handle SIGHUP nostop" -ex cont -ex bt &
 }}}
 Hope to get a better result within the enxt day or so.

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

Re: [tor-bugs] #18950 [Applications/Tor Browser]: Disable or audit Reader View in ESR 45

[Tor Bug Tracker & Wiki]

#18950: Disable or audit Reader View in ESR 45
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff45-esr, TorBrowserTeam201605R, |  Actual Points:
  GeorgKoppen201605, tbb-6.0-must| Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

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


Comment:

 Okay, thanks. Taking this for now, though. I revised the commit message a
 bit and fixed a typo in it. commit
 1344de9d3c90e3eac02dd13433ef8412a450df5a on tor-browser-45.1.0esr-6.0-1
 has the fixup.

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

Re: [tor-bugs] #18912 [Applications/Tor Browser]: add automated tests for updater cert pinning

[Tor Bug Tracker & Wiki]

#18912: add automated tests for updater cert pinning
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff45-esr, TorBrowserTeam201605R, |  Actual Points:
  tbb-6.0-must   | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:3 mcs]:
 > Kathy and I created a test:
 > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug18912-01&id=c84f29c2f1cf26cd676d786d6f5e65ee67095170

 Looks good to me. Applied to tor-browser-45.1.0esr-6.0-1 (commit
 351b3c16c1581771e724156f43c5bee32ec42f51).

 > Please review. There are a couple of caveats though:
 > 1. This test is affected by #18087.
 > 2. We do not have a way to run tests like this automatically against our
 nightly builds. We should fix that (as well as #18087) so we can be sure
 to catch regressions. At the very least, we should find a way to run the
 tests that we have created such as this one, Arthur's isolation tests, and
 so on.

 Yes, I think we have #15994 for that one.

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

Re: [tor-bugs] #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| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #16943| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Sounds like a good idea!

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

Re: [tor-bugs] #18914 [Applications/Tor Browser]: Consider removing

[Tor Bug Tracker & Wiki]

#18914: Consider removing 
-+-
 Reporter:  mcs  |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:5 mcs]:
 > Replying to [comment:3 arthuredelstein]:
 > > Here's a patch that uses an English-only label on `` tags.
 The localized tag is removed. This provides an easy fix while we wait for
 Mozilla to remove the  support altogether.
 > >
 > > https://github.com/arthuredelstein/tor-browser/commit/18914+1
 > > Hash 018cc9788c202df10a9f6aceaac12af12bd672b6
 >
 > This is a good solution.
 > Is it safe to use u"..." string literals for all compilers?
 > Mozilla code usually uses NS_LITERAL_STRING.
 > Otherwise, the changes look good.

 Good point. Here's a revised version using NS_LITERAL_STRING.

 https://github.com/arthuredelstein/tor-browser/commit/18914+2
 Hash 3c2c77205ee2bf92abd975fbed310cfcd57e74dc

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

Re: [tor-bugs] #15994 [Applications/Quality Assurance and Testing]: Running Tor Browser unit tests as part of our gitian-based build process

[Tor Bug Tracker & Wiki]

#15994: Running Tor Browser unit tests as part of our gitian-based build process
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing| Resolution:
 Severity:  Normal   |  Actual Points:
 Keywords:   | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

 * severity:   => Normal


Comment:

 I think this is the ideal thing for our nightly builds. At least we should
 try to get that deployed there first.

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

 Applied your patch and modified the docs target.  Thanks!

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

Re: [tor-bugs] #19021 [Metrics/CollecTor]: improve configuration process

[Tor Bug Tracker & Wiki]

#19021: improve configuration process
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip operation |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Replying to [comment:3 iwakeh]:
 > Does the following topic from the RoadMap mean that Torperf data
 fetching will be obsolete in CollecTor then?
 > {{{Take Torperf offline; karsten; 2016-09-30 }}}

 Possibly, yes.  The plan is to switch from Torperf to OnionPerf, and
 OnionPerf might come with its own code to fetch data from other OnionPerf
 instances and make that available to the world.  But I'm not entirely
 certain which role CollecTor will play once OnionPerf is in place.  We
 might be able to remove the code that merges .data and .extradata files,
 but we might need to keep the Torperf results archiving code.  I'd say
 don't give up on the Torperf module in CollecTor just yet.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R, | Resolution:  fixed
  tbb-6.0-must   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Jonas' mail seems to indicate we are not in a bad shape with this patch.
 We should try to figure this out, though, with his help if possible.
 Taking this patch for 6.0 and we'll back it out and rebuild if we indeed
 overlooked things. This is fixed on tor-browser-45.1.0esr-6.0-1 (commit
 464f9221b09b70e05950a44ebb4f3c1f0bfde179).

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

Re: [tor-bugs] #19154 [Metrics/Onionoo]: Onionoo stopped to resolve ASN and country code for new relays

[Tor Bug Tracker & Wiki]

#19154: Onionoo stopped to resolve ASN and country code for new relays
-+--
 Reporter:  twim |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * cc: iwakeh (added)
 * status:  accepted => needs_review
 * severity:  Normal => Major


Comment:

 iwakeh, if you can, please review
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-19154
 my branch task-19154].  Thanks!

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

Re: [tor-bugs] #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.9.x-final
 Keywords:  029-nickm-unsure, 029-teor-yes,  |Version:
  tor-hs | Resolution:
Parent ID:  #16943   |  Actual Points:
 Reviewer:   | Points:  small
 |Sponsor:
-+-

Comment (by arma):

 I haven't reviewed the code, but the description in this ticket matches
 what I think teor and asn and dgoulet and I discussed right before I ran
 out of the Montreal meeting. So, yay.

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

Re: [tor-bugs] #19150 [Core Tor/Tor]: Pointer overflow in memarea_alloc()

[Tor Bug Tracker & Wiki]

#19150: Pointer overflow in memarea_alloc()
+--
 Reporter:  asn |  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
Component:  Core Tor/Tor|  0.2.8.x-final
 Severity:  Normal  |Version:  Tor:
 Keywords:  TorCoreTeam201605 027-backport  |  0.2.1.10-alpha
Parent ID:  | Resolution:
 Reviewer:  |  Actual Points:
| Points:
|Sponsor:
+--

Comment (by asn):

 Did an initial review of Nick's branch. Found some issues which have been
 addressed. I like the current version.

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

Re: [tor-bugs] #19163 [Core Tor/Tor]: Maybe RSOS single-hop circuits should always have ntor

[Tor Bug Tracker & Wiki]

#19163: Maybe RSOS single-hop circuits should always have ntor
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rsos  |  Actual Points:
Parent ID:  #17178| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by isis):

 If we're worried that one-hop paths could be used, e.g. by the RSOS to
 upload its descriptor to the HSDir, then using the TAP handshake for said
 upload would reduce the guarantees of authenticity of the HSDir to
 RSA-1024. So yes, since it's trivial to do, there's no performance
 decrease, and nearly non-existent anonymity decrease to exclude TAP, we
 should exclude TAP for RSOSes.

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

Re: [tor-bugs] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0.1
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+

Comment (by isis):

 Replying to [comment:11 isis]:
 > Replying to [comment:10 nickm]:
 > > uggg. starting around line 7617 is where we see the
 problem: linking doesn't work because we try to include '-libscrypt' but
 not '-lm'.
 > >
 > > `bug19161_028` now has an extra fix to search for libm even harder.
 >
 > All the `AC_CHECK_SIZEOF` checks are still failing due to not adding
 `-lm`, see attached
 
[https://trac.torproject.org/projects/tor/attachment/ticket/19161/config.log.2.tar.xz
 config.log.2.tar.xz].

 And fourteen pages of GNU Autoconf documentation later… I think I have a
 patch which fixes this so that libscript is linked in when available, and
 when it is linked in, if we do need `-lm`, then `-lm` is also added where
 needed. It's available in my `bug19161_028`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug19161_028
 branch], which is based on nickm's branch of the same name.

 My patch works for me, but it'd be nice to know that it doesn't break
 things for anyone else.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  task |  arthuredelstein
 Priority:  Very High| Status:
Component:  Applications/Tor Browser |  assigned
 Severity:  Critical |  Milestone:
 Keywords:  tbb-fingerprinting-os, tbb-easy, |Version:
  TorBrowserTeam201605   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by cypherpunks):

 Okay I've rechecked and compared the individual test results for each
 machine.
 Which I refer to as `Linux A`, `Linux B`, and `Windows`

 For the **AudioContext properties** `Windows` and `Linux B` had the exact
 same values namely:
 {{{
 {
 "ac-sampleRate": 48000,
 "ac-maxChannelCount": 2,
 "ac-numberOfInputs": 1,
 
"ac-numberOfOutputs": 0,
 "ac-channelCount": 2,
 "ac-channelCountMode": "explicit",
 "ac-channelInterpretation": "speakers",
 
"an-fftSize": 2048,
 "an-frequencyBinCount": 1024,
 "an-minDecibels": -100,
 "an-maxDecibels": -30,
 "an-smoothingTimeConstant": 0.8,
 "an-numberOfInputs": 1,
 "an-numberOfOutputs": 1,
 "an-channelCount": 1,
 "an-channelCountMode": "max",
 "an-channelInterpretation": "speakers"
 }
 }}}

 But `Linux A` only had different values, listed here:
 {{{
   "ac-sampleRate": 44100,
   "ac-maxChannelCount": 1,
 }}}

 For the **Fingerprint using DynamicsCompressor (sum of buffer values)**
 * `Linux A` and `Linux B` both had `35.14587543532252`
 * `Windows` had `35.145139578345606`

 For the **Fingerprint using DynamicsCompressor (hash of full buffer)**
 * `Linux A` and `Linux B` both had
 `12a8c630cab33ce196f223822f4d23c59717abeb`
 * `Windows` had `14b5e50593a946dbf54923aeefec7682156ea46c`

 For **Fingerprint using OscillatorNode**
 * `Linux A`, `Linux B` and `Windows` **all had a unique fingerprint.**

 For **Fingerprint using hybrid of OscillatorNode/DynamicsCompressor
 method**
 * `Linux A`, `Linux B` and `Windows` **all had a unique fingerprint as
 well.**

 Hope this helps.

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

Re: [tor-bugs] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0.1
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+
Changes (by nickm):

 * status:  needs_revision => needs_review
 * actualpoints:  0 => 0.1


Comment:

 Okay. Let's get it reviewed then.

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

Re: [tor-bugs] #19154 [Metrics/Onionoo]: Onionoo stopped to resolve ASN and country code for new relays

[Tor Bug Tracker & Wiki]

#19154: Onionoo stopped to resolve ASN and country code for new relays
-+--
 Reporter:  twim |  Owner:  karsten
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * owner:   => karsten
 * status:  new => accepted


Comment:

 Huh, there's indeed something wrong.  I found this in the log:

 {{{
 2016-05-24 14:17:18,656 ERROR o.t.o.u.LookupService:169 Number format
 exception while parsing line
 '1.34.160.0/22,1668284,1668284,,0,0,,23.5000,121.,51' in
 /srv/onionoo.torproject.org/onionoo/geoip/GeoLite2-City-Blocks-IPv4.csv.
 }}}

 I'll need to dig deeper, I just wanted to confirm this is a 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] #18884 [Applications/Tor Browser]: Rip Firefox Hello Beta / Loop extension in ESR45 based Tor Browser

[Tor Bug Tracker & Wiki]

#18884: Rip Firefox Hello Beta / Loop extension in ESR45 based Tor Browser
-+-
 Reporter:  gk   |  Owner:
 Type:  task |  arthuredelstein
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_revision
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605R, |Version:
  tbb-6.0-must   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_review => needs_revision


Comment:

 When testing with a standalone (non-gitian) build on MacOS, we had to add
 this to the patch:
 {{{
 diff --git a/browser/locales/Makefile.in b/browser/locales/Makefile.in
 index be9454e..ec54b63 100644
 --- a/browser/locales/Makefile.in
 +++ b/browser/locales/Makefile.in
 @@ -133,7 +133,9 @@ ifdef MOZ_WEBAPP_RUNTIME
 @$(MAKE) -C ../../webapprt/locales AB_CD=$* XPI_NAME=locale-$*
  endif
 @$(MAKE) -C ../../extensions/spellcheck/locales AB_CD=$*
 XPI_NAME=locale-$*
 +ifdef MOZ_LOOP
 @$(MAKE) -C ../extensions/loop/chrome/locale AB_CD=$*
 XPI_NAME=locale-$*
 +endif
 @$(MAKE) -C ../../intl/locales AB_CD=$* XPI_NAME=locale-$*
 @$(MAKE) -C ../../devtools/client/locales AB_CD=$*
 XPI_NAME=locale-$* XPI_ROOT_APPID='$(XPI_ROOT_APPID)'
 @$(MAKE) -B searchplugins AB_CD=$* XPI_NAME=locale-$*
 }}}

 Also, our packaged build still includes the loop extension (but we haven't
 figured out why).
 {{{
 ls -l obj-
 macos/dist/firefox/TorBrowserDebug.app/Contents/Resources/browser/features/
 total 3312
 -rw-r--r--  1 brade  staff  1691779 May 24 11:39 l...@mozilla.org.xpi
 }}}

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

Re: [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| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #16943| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:2 teor]:
 > If we don't bother, any build on those clang/llvm versions with
 `./configure --enable-gcc-warnings` will fail.
 >
 > So we need to silence this warning, otherwise no-one can use `--enable-
 gcc-warnings` with clang/llvm.

 You are right. I'm surprised this is the only place in the codebase where
 this pattern bothers clang/llvm.

 If this is the only instance of this issue, maybe we can just remove the
 `= {0}` part, and rely on the compiler zeroing it because it's a global
 static struct.

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

Re: [tor-bugs] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+

Comment (by isis):

 Replying to [comment:12 nickm]:
 > bug19161_028_v2 is far simpler.

 Okay, that works fine for me (although obviously doesn't link in libscrypt
 or try to use it).

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

Re: [tor-bugs] #18950 [Applications/Tor Browser]: Disable or audit Reader View in ESR 45

[Tor Bug Tracker & Wiki]

#18950: Disable or audit Reader View in ESR 45
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R, | Resolution:
  GeorgKoppen201605, tbb-6.0-must|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 This looks good. It would not hurt for Arthur to take a look as well.

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

Re: [tor-bugs] #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 karsten):

 For the record, here are the two details documents which might not be
 available anymore in a week from now:

 {{{
 {"version":"3.1",
 "relays_published":"2016-05-24 12:00:00",
 "relays":[
 
{"nickname":"oleedrom","fingerprint":"041DDC5D9760D2EFF0450B46FF030C3986D54493","or_addresses":["176.99.183.29:443"],"dir_address":"176.99.183.29:80","last_seen":"2016-05-21
 09:00:00","last_changed_address_or_port":"2016-05-18
 14:00:00","first_seen":"2016-05-18
 
14:00:00","running":false,"flags":["Fast","Running","V2Dir","Valid"],"consensus_weight":260,"host_name":"176.99.183.29","last_restarted":"2016-05-20
 
22:49:25","bandwidth_rate":1073741824,"bandwidth_burst":1073741824,"observed_bandwidth":2202971,"advertised_bandwidth":2202971,"exit_policy":["reject
 *:*"],"exit_policy_summary":{"reject":["1-65535"]},"platform":"Tor 0.2.7.6
 on OpenBSD","recommended_version":true,"measured":true}
 ],
 "bridges_published":"2016-05-24 11:44:30",
 "bridges":[
 ]}


 {"version":"3.1",
 "relays_published":"2016-05-24 12:00:00",
 "relays":[
 
{"nickname":"sayonar","fingerprint":"9634197516DA0EA4ECB83E7DC4960D832039D209","or_addresses":["176.99.177.201:443"],"last_seen":"2016-05-24
 13:00:00","last_changed_address_or_port":"2016-05-20
 00:00:00","first_seen":"2016-05-15
 
01:00:00","running":true,"flags":["Fast","Running","Valid"],"country":"ru","country_name":"Russia","latitude":55.75,"longitude":37.6166,"as_number":"AS35598","as_name":"INETCOM
 
LLC","consensus_weight":390,"host_name":"176.99.177.201","last_restarted":"2016-05-23
 
18:43:52","bandwidth_rate":1073741824,"bandwidth_burst":1073741824,"observed_bandwidth":742679,"advertised_bandwidth":742679,"exit_policy":["reject
 *:*"],"exit_policy_summary":{"reject":["1-65535"]},"platform":"Tor 0.2.7.6
 on
 
Linux","consensus_weight_fraction":9.708045E-6,"guard_probability":0.0,"middle_probability":2.5208281E-5,"exit_probability":0.0,"recommended_version":true,"measured":true}
 ],
 "bridges_published":"2016-05-24 11:44:30",
 "bridges":[
 ]}
 }}}

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

 The first relay you mention above (041DDC5D) does not only lack a
 `"country"` field but also all other GeoIP-related fields.  That looks
 like a bug.  But I don't (yet) see how that's related to the earlier fix
 here, because that only affected the `"country"` field, not the others.  I
 suggest we move the discussion of that new bug to #19154 and leave this
 ticket for the Atlas bug of wanting to display `img/cc/.png`.

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

Re: [tor-bugs] #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 karsten):

 Sure, it's available here:
 https://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum2.zip

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

 Share the MaxMind data with me and I will do the comparison.

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

 Hang on, the MaxMind data that I quoted above does include this row:

 {{{
 1841168384,1841233919,"AS35540 OVH SAS"
 }}}

 So, in this case the CAIDA data looks about as good as MaxMind's.

 Can you give an example, or better a handful of examples, where CAIDA data
 is obviously better than MaxMind's?

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

Re: [tor-bugs] #18914 [Applications/Tor Browser]: Consider removing

[Tor Bug Tracker & Wiki]

#18914: Consider removing 
-+-
 Reporter:  mcs  |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:3 arthuredelstein]:
 > Here's a patch that uses an English-only label on `` tags. The
 localized tag is removed. This provides an easy fix while we wait for
 Mozilla to remove the  support altogether.
 >
 > https://github.com/arthuredelstein/tor-browser/commit/18914+1
 > Hash 018cc9788c202df10a9f6aceaac12af12bd672b6

 This is a good solution.
 Is it safe to use u"..." string literals for all compilers?
 Mozilla code usually uses NS_LITERAL_STRING.
 Otherwise, the changes look good.

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

Re: [tor-bugs] #19148 [Core Tor/Tor]: Make some parts of Tor scriptable

[Tor Bug Tracker & Wiki]

#19148: Make some parts of Tor scriptable
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Yes, but unfortunately the logic is hardcoded in C.

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

Re: [tor-bugs] #16873 [Metrics/metrics-lib]: add javadoc to metrics-lib

[Tor Bug Tracker & Wiki]

#16873: add javadoc to metrics-lib
-+--
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #18746   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:24 iwakeh]:
 > Good documentation! Quite a lot to read!
 >
 > I put myself in the mindset of someone who reads the javadoc for the
 first time and wants to use descriptor quickly for accessing the available
 data.
 >
 > Here some suggestions derived from that way of reading:
 > * the overview page is missing (I added a diff, not a format patch just
 a suggestion, most of the text moved from the package description)

 Looks good, applied with minor edits and pushed to my task-16873 branch.

 > * listing of the property names in the factory class and an example
 (also in the attached diff)

 Also applied.

 > * It might be very useful to add source code examples for using the
 descriptor api to the downloader, collector, parser, and reader classes.
 Maybe, just copied from Onionoo sources.

 Good idea, I included source code examples for collector and reader, as I
 expect those to be used by 90% of users.  Parser is mostly an internal
 thing that happens to be publicly available, and downloader is not really
 used by anything and should be removed sooner than later.

 > * Somewhere there ought to be a link to the Tor spec. Maybe, in the
 overview or/and the classes?

 Sure, added to the overview.

 > * the link in BridgeExtraInfoDescriptor should be turned into a
 clickable one.

 Changed, as well as similar links in the other three Bridge* interfaces.

 Great feedback, let me know if you have more, and I'll incorporate that.
 Thanks!

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

Re: [tor-bugs] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+

Comment (by nickm):

 bug19161_028_v2 is far simpler.

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

Re: [tor-bugs] #19071 [Core Tor/Tor]: Check existing fallback fingerprints, IPs, and ports before 0.2.8-rc

[Tor Bug Tracker & Wiki]

#19071: Check existing fallback fingerprints, IPs, and ports before 0.2.8-rc
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | 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
  TorCoreTeam201606  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  0.5
 |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:3 nickm]:
 > What skills will that developer need to have?  What work will be
 involved for them?
 >
 > (I suspect it might be easier to get a volunteer if they knew better
 what they were getting themselves into.)

 * Run a python script on a reliable, non-tor network connection,
 * contact relay operators in response to failures in the script logs,
 * edit configuration files based on operator responses.

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

Re: [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| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #16943| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 If we don't bother, any build on those clang/llvm versions with
 `./configure --enable-gcc-warnings` will fail.

 So we need to silence this warning, otherwise no-one can use `--enable-
 gcc-warnings` with clang/llvm.

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

Re: [tor-bugs] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+

Comment (by isis):

 Replying to [comment:10 nickm]:
 > uggg. starting around line 7617 is where we see the problem:
 linking doesn't work because we try to include '-libscrypt' but not '-lm'.
 >
 > `bug19161_028` now has an extra fix to search for libm even harder.

 All the `AC_CHECK_SIZEOF` checks are still failing due to not adding
 `-lm`, see attached
 
[https://trac.torproject.org/projects/tor/attachment/ticket/19161/config.log.2.tar.xz
 config.log.2.tar.xz].

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

Re: [tor-bugs] #17599 [Applications/Tor Browser]: Please add keyboard shortcuts for New Identity and New Tor Circuit for this Site

[Tor Bug Tracker & Wiki]

#17599: Please add keyboard shortcuts for New Identity and New Tor Circuit for 
this
Site
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 Type:  enhancement  |  team
 Priority:  Medium   | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-usability, tbb-torbutton,| Resolution:  fixed
  TorBrowserTeam201605R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks, this makes it into 6.0: commit
 e546a3f158b6fc39c66e323eaa7b8463caef599c on master has the patch.

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

Re: [tor-bugs] #17282 [Core Tor/Chutney]: Chutney could use a HOWTO for writing new test cases, network tests, etc

[Tor Bug Tracker & Wiki]

#17282: Chutney could use a HOWTO for writing new test cases, network tests, etc
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, tor-tests-integration, tor- |  Actual Points:
  chutney-usability, TorCoreTeam201606   | Points:  3
Parent ID:   |Sponsor:
 Reviewer:   |  SponsorS-must
-+-
Changes (by nickm):

 * keywords:
 doc, tor-tests-integration, tor-chutney-usability, TorCoreTeam201605,
 TorCoreTeam-postponed-201604
 => doc, tor-tests-integration, tor-chutney-usability,
 TorCoreTeam201606


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

Re: [tor-bugs] #19071 [Core Tor/Tor]: Check existing fallback fingerprints, IPs, and ports before 0.2.8-rc

[Tor Bug Tracker & Wiki]

#19071: Check existing fallback fingerprints, IPs, and ports before 0.2.8-rc
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | 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
  TorCoreTeam201606  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  0.5
 |Sponsor:
-+-

Comment (by nickm):

 What skills will that developer need to have?  What work will be involved
 for them?

 (I suspect it might be easier to get a volunteer if they knew better what
 they were getting themselves into.)

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

Re: [tor-bugs] #19043 [Core Tor/Tor]: Implementation of prop224 ESTABLISH_INTRO cell (was: Implementation of Proposal 224 Section 3.1)

[Tor Bug Tracker & Wiki]

#19043: Implementation of prop224 ESTABLISH_INTRO cell
-+
 Reporter:  alec.heif|  Owner:
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194  |  Actual Points:
Parent ID:  #17241   | Points:
 Reviewer:  asn, dgoulet |Sponsor:  SponsorR-must
-+

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

Re: [tor-bugs] #19150 [Core Tor/Tor]: Pointer overflow in memarea_alloc()

[Tor Bug Tracker & Wiki]

#19150: Pointer overflow in memarea_alloc()
+--
 Reporter:  asn |  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
Component:  Core Tor/Tor|  0.2.8.x-final
 Severity:  Normal  |Version:  Tor:
 Keywords:  TorCoreTeam201605 027-backport  |  0.2.1.10-alpha
Parent ID:  | Resolution:
 Reviewer:  |  Actual Points:
| Points:
|Sponsor:
+--
Changes (by nickm):

 * status:  needs_revision => 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] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+

Comment (by nickm):

 uggg. starting around line 7617 is where we see the problem:
 linking doesn't work because we try to include '-libscrypt' but not '-lm'.

 `bug19161_028` now has an extra fix to search for libm even harder.

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

Re: [tor-bugs] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+

Comment (by isis):

 Replying to [comment:8 nickm]:
 > isis says this fails, with failures to find types for uintfoo_t and
 void*. Usually that means that we've added some compiler flag that stops
 building or linking entirely.  Waiting on a config.log analysis to see
 what the issue was.

 New config.log attached.

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

Re: [tor-bugs] #18930 [Core Tor/Tor]: Segmentation fault: entry->parsed->intro_nodes

[Tor Bug Tracker & Wiki]

#18930: Segmentation fault: entry->parsed->intro_nodes
-+-
 Reporter:  juha |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_information
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor2web, crash, TorCoreTeam201605|Version:  Tor:
  028-backport   |  0.2.7.1-alpha
Parent ID:   | Resolution:
 Reviewer:  dgoulet  |  Actual Points:
 | Points:  1
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor2web, crash, TorCoreTeam201605 => tor2web, crash,
 TorCoreTeam201605 028-backport
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.9.x-final


Comment:

 we can take this in 0.2.9 and maybe even backport, if we get a fix.

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

Re: [tor-bugs] #18100 [Core Tor/Tor]: src/or/connection_edge.c typo

[Tor Bug Tracker & Wiki]

#18100: src/or/connection_edge.c typo
+--
 Reporter:  jirib   |  Owner:
 Type:  defect  | Status:
 Priority:  Medium  |  needs_information
Component:  Core Tor/Tor|  Milestone:  Tor: 0.2.???
 Severity:  Normal  |Version:  Tor:
 Keywords:  029-proposed TorCoreTeam201605  |  0.2.6.3-alpha
Parent ID:  | Resolution:
 Reviewer:  |  Actual Points:
| Points:
|Sponsor:
+--
Changes (by nickm):

 * keywords:  027-backport, 026-backport TorCoreTeam201605 => 029-proposed
 TorCoreTeam201605
 * milestone:  Tor: 0.2.8.x-final => 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] #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:  nickm
 Type:  defect   | Status:
 Priority:  High |  needs_information
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Blocker  |  0.2.8.x-final
 Keywords:  must-fix-before-028-alpha|Version:  Tor:
  TorCoreTeam201605  |  0.2.8.2-alpha
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:
 |Sponsor:
-+-

Comment (by nickm):

 (currently hoping for a gdb backtrace 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] #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:  nickm
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.2-alpha
 Severity:  Blocker| Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * keywords:  must-fix-before-028-alpha TorCoreTeam201605 =>
   TorCoreTeam201605


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

Re: [tor-bugs] #19161 [Core Tor/Tor]: test for libscrypt_scrypt() fails

[Tor Bug Tracker & Wiki]

#19161: test for libscrypt_scrypt() fails
---+
 Reporter:  isis   |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer:  isis   |Sponsor:
---+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 isis says this fails, with failures to find types for uintfoo_t and void*.
 Usually that means that we've added some compiler flag that stops building
 or linking entirely.  Waiting on a config.log analysis to see what the
 issue was.

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

[Tor Bug Tracker & Wiki]

#19125: [prop250] 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 asn):

 * keywords:  tor-hs, TorCoreTeam201605, review-group-2 => tor-hs,
 TorCoreTeam201605


Comment:

 FWIW, this is a patch on top of the prop250 branch.

 I included this fix in my #16943 branch (see comment:72:ticket:16943). We
 can close this ticket once that gets merged.

 For now I remove it from review-group-2, since it's part of the prop250
 giant.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  task |  arthuredelstein
 Priority:  Very High| Status:
Component:  Applications/Tor Browser |  assigned
 Severity:  Critical |  Milestone:
 Keywords:  tbb-fingerprinting-os, tbb-easy, |Version:
  TorBrowserTeam201605   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by isis):

 * cc: isis (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] #18950 [Applications/Tor Browser]: Disable or audit Reader View in ESR 45

[Tor Bug Tracker & Wiki]

#18950: Disable or audit Reader View in ESR 45
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R, | Resolution:
  GeorgKoppen201605, tbb-6.0-must|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 See bug_18950 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_18950) in my tor-browser repo for a patch.

 I did not disable the whole feature but made sure that the fingerprinting
 risks that might be associated with it are neutered. This is mainly done
 by flipping `reader.parse-on-load.enabled` to `false`. Having it set to
 `true` would discriminate between users with low memory computers
 (probably only some mobile ones) and those who have Reader View capable
 ones.

 This has the side-effect that the reader view icon is vanishing from the
 URL bar and the View menu making it harder to click on them by accident
 (at least on the desktop). See: https://mxr.mozilla.org/mozilla-
 esr45/source/browser/base/content/tab-content.js#331

 The other code path that goes to `_readerParse()` (https://mxr.mozilla.org
 /mozilla-esr45/source/toolkit/components/reader/ReaderMode.jsm#351) comes
 from the `about:reader` URL which is called if one already has saved an
 item in one's reader list. This is okay I think. Content seems not be able
 to use `about:reader` URLs to mess with a user's browsing session, a
 security error is thrown.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 uint64_t for integers in shared random structs

[Tor Bug Tracker & Wiki]

#19126: Consistently use uint64_t for integers in shared random structs
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  reopened
 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:
--+

Comment (by asn):

 FWIW, I folded this patch in my latest prop250 branch. See
 comment:72:ticket:16943.

 Maybe we should remove this from review-group-2? Not sure if there is a
 point in someone reviewing this two line change when it's on top of the
 gigantic prop250 branch. In any case, I reviewed the change before merging
 it :)

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

Re: [tor-bugs] #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 asn):

 OK, did another review of `dgoulet/ticket16943_029_02` up to `b9b9022`. I
 like the new changes!

 Please see my branch `ticket16943_029_04`, which addresses some more
 issues. Specifically, it fixes the first two points from comment:65, and
 also it folds in teor's patch from #19126 (which fixes tests in platforms
 where time_t is 32bits).

 What else remains to be done?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  task |  arthuredelstein
 Priority:  Very High| Status:
Component:  Applications/Tor Browser |  assigned
 Severity:  Critical |  Milestone:
 Keywords:  tbb-fingerprinting-os, tbb-easy, |Version:
  TorBrowserTeam201605   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by boklm):

 In my case, I get the same fingerprint on 2 different computers with the
 same OS and same Tor Browser version. But changing Tor Browser version (I
 tried with 5.5.5 and 6.0a5) changed the fingerprint.

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

Comment (by asn):

 Not sure if we should consider this a code bug, or a spec bug. I'm
 personally fine with fitting those fields in a single byte. We are still
 quite far away from anything close to 255 dirauths or 255 SR protocol
 versions.

 I'll let David decide if this is worth the engineering changes. I'm fine
 either 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] #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| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #16943| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Seems to be related to llvm bug 21689. See
 https://webcache.googleusercontent.com/search?q=cache:7Fk9-xz-
 MBYJ:https://llvm.org/bugs/show_bug.cgi%3Fid%3D21689+&cd=1&hl=en&ct=clnk&gl=us

 In theory we could work around this llvm bug by removing the `= {0}` part,
 since the struct is a file-level static variable which should have its
 elements inited to NULs anyway.

 Not sure if we should bother 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] #19142 [Core Tor/Tor]: Remove the environ configure check

[Tor Bug Tracker & Wiki]

#19142: Remove the environ configure check
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 It turns out the `environ` variable cannot be redeclared because of
 `-Wredundant-decls`. Instead i looked into why it was added and if it can
 be removed.

 It was initially added in commit
 
[https://gitweb.torproject.org/tor.git/commit/?id=efb7b9dec135594718b765234bc1f745855f60d2
 efb7b9dec135594718b765234bc1f745855f60d2] because (according to the
 comment) FreeBSD needed it. The
 
[https://www.freebsd.org/cgi/man.cgi?query=environ&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE&arch=default&format=html
 man page] (all the way back to FreeBSD 1.0) tells us otherwise. If someone
 could give the reasoning why FreeBSD requires declaring `environ` that
 would be helpful because i don't have a FreeBSD machine and cannot test it
 myself.

 In commit
 
[https://gitweb.torproject.org/tor.git/commit/?id=bc66878bdea0250991fc99b2d023146f67a6f4bb
 bc66878bdea0250991fc99b2d023146f67a6f4bb] the environ configure check was
 added because it gave redundant declaration warnings on Linux. These were
 the exact same warnings i got when testing redeclaring `environ`
 unconditionally.

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

Re: [tor-bugs] #19151 [Core Tor/Tor]: Looks like a memory leak?

[Tor Bug Tracker & Wiki]

#19151: Looks like a memory leak?
--+
 Reporter:  t-3.net   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Major | Resolution:
 Keywords:  unsolved  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by t-3.net):

 As of now, the memory use is on a slow, steady increase as before (and the
 memory use graph doesn't resemble the traffic graph).

 If we're waiting to see if it hits a 3+ GB threshold and stops, it will
 take a number of days at this rate of growth, maybe 5+ days.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 Type:  task |  arthuredelstein
 Priority:  Very High| Status:
Component:  Applications/Tor Browser |  assigned
 Severity:  Critical |  Milestone:
 Keywords:  tbb-fingerprinting-os, tbb-easy, |Version:
  TorBrowserTeam201605   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by gk):

 * status:  needs_information => assigned
 * keywords:  tbb-fingerprinting-os, tbb-easy => tbb-fingerprinting-os, tbb-
 easy, TorBrowserTeam201605
 * owner:  tbb-team => arthuredelstein


Comment:

 Okay, we take a closer look and get to the bottom of it.

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