Re: [tor-bugs] #21222 [Webpages/Website]: Redesigning torproject.org: cleanup and update, content organization, and creating themed portals

[Tor Bug Tracker & Wiki]

#21222: Redesigning torproject.org: cleanup and update, content organization, 
and
creating themed portals
--+--
 Reporter:  linda |  Owner:  linda
 Type:  project   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Pari):

 Hey! I am an applicant for outreachy who is a user experience designer. I
 would love to take this up! would it be okay?

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

Re: [tor-bugs] #21926 [Core Tor/Tor]: Still had 1 address policies cached at shutdown

[Tor Bug Tracker & Wiki]

#21926: Still had 1 address policies cached at shutdown
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * Attachment "000a.zip" added.

 zip of authority data dir 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] #21926 [Core Tor/Tor]: Still had 1 address policies cached at shutdown

[Tor Bug Tracker & Wiki]

#21926: Still had 1 address policies cached at shutdown
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  closed => reopened
 * version:  Tor: 0.3.0.6 => Tor: 0.3.0.10
 * resolution:  duplicate =>
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 I have seen this on a modified 0.3.0.10 with the #22370 patch (but also a
 bunch of extra privcount patches, none of which deal with address
 policies).

 Is this still happening on an unmodified 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] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

[Tor Bug Tracker & Wiki]

#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #23262 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by Pari):

 Hey! I am an applicant for outreachy. would it be okay if I take this up?

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

Re: [tor-bugs] #23665 [Applications/Tor Messenger]: Enable content process sandbox on Windows

[Tor Bug Tracker & Wiki]

#23665: Enable content process sandbox on Windows
+
 Reporter:  arlolra |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by sukhbir):

 * cc: sukhbir (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] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

[Tor Bug Tracker & Wiki]

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-+-
 Reporter:  arthuredelstein  |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 After I read Arthur's comment on the github branch[0] I realized there's a
 bug in the patch. I pushed a fixup commit that corrects it[1].

 So it's in this ticket, the relevant part is:
 {{{
 Every call to KEY/SHIFT/ALTGR updates the mapping in all hashmaps,
 therefore
 calling both ALTGR and SHIFT for the same key results in the ALTGR state
 being
 overwritten. I'll leave these comments above and instead I'll create a
 fourth
 macro for ALTGRSHIFT that correctly inserts the key into the hashmaps.
 I'll
 then replace all occurrences of ALTGR()+SHIFT() with ALTGRSHIFT().
 }}}

 Commit 1e094349cd679d8592411d741512d71bc29185fc does this.

 [0] https://github.com/sysrqb/tor-
 browser/commit/bug16678_2#commitcomment-24566167
 [1] https://github.com/sysrqb/tor-
 browser/commit/1e094349cd679d8592411d741512d71bc29185fc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23671 [Core Tor/Tor]: Say how many other nodes we're missing descriptors for

[Tor Bug Tracker & Wiki]

#23671: Say how many other nodes we're missing descriptors for
---+---
 Reporter:  teor   |  Owner:  (none)
 Type: | Status:  new
  enhancement  |
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core   |Version:
  Tor/Tor  |
 Severity:  Normal |   Keywords:  tor-guard, tor-bridge, tor-client
Actual Points: |  Parent ID:  #21969
   Points:  0.5|   Reviewer:
  Sponsor: |
---+---
 Let's log the message that starts:
 {{{
 We need more %sdescriptors: we have %d/%d...
 }}}
 whenever we're missing descriptors for any of our primary entry guards.

 This would be a useful diagnostic for #21969.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23670 [Core Tor/Tor]: Say how many primary entry guards we're missing descriptors for

[Tor Bug Tracker & Wiki]

#23670: Say how many primary entry guards we're missing descriptors for
---+---
 Reporter:  teor   |  Owner:  (none)
 Type: | Status:  new
  enhancement  |
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core   |Version:
  Tor/Tor  |
 Severity:  Normal |   Keywords:  tor-guard, tor-bridge, tor-client
Actual Points: |  Parent ID:  #21969
   Points:  0.5|   Reviewer:
  Sponsor: |
---+---
 Let's say:
 {{{
 We're missing descriptors for %d/%d of our primary entry guards
 }}}

 That would be a more helpful diagnostic for #21969.

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

Re: [tor-bugs] #22501 [Applications/Tor Browser]: Requests via javascript: violate FPI

[Tor Bug Tracker & Wiki]

#22501: Requests via javascript: violate FPI
--+---
 Reporter:  cypherpunks   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pospeselr):

 So the problem here is NoScript with 'noscript.global' preference enabled
 (hence why only happens when in Medium or Higher security setting).

 When an  element is clicked and the href attribute starts with
 'javascript:' NoScript tries to heuristically extract a URI from the
 source by looking for a string between " or ' characters that does not
 contain invalid URI characters (
 
https://github.com/avian2/noscript/blob/8e12f5ce4f2ddf169da3867ca80323cbbd789948/xpi/chrome/content/noscript/Main.js#L4168
 ) and uses that as the href string instead, passing this new href on to an
 XMLHttpRequest at which point everything happens as normal.

 It will interpret the href as relative to the document's URI, unless the
 href is itself an absolute URL (per https://developer.mozilla.org/en-
 US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIIOService#newURI() ).

 This has some really cool consequences such that this  element will go
 to github when clicked with NoScript enabled:

 http://www.github.com' */
 window.alert('Hello!');">Hello!

 proof: https://pste.eu/p/pWdf.html

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

Re: [tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Replying to [comment:5 gk]:
 > Replying to [comment:4 cypherpunks]:
 > > Don't you see that Jacek's patch activated compat shims for mingw?
 They were removed later as useless for UCRT (but needed for <=
 `msvcr120.dll`!).
 >
 > Oh, okay. You are just concerned about https://hg.mozilla.org/mozilla-
 central/rev/5680a55b2ec1?
 Of course, no.
 > I thought about cases in the other patches as well as you posted them in
 the description. But as I said they are guarded by `_MSC_VER` defines
 which are not used by mingw-w64 anyway.
 But they should have been adapted to mingw where it's about CRT bugs.
 > So it seems
 > {{{
 > -if CONFIG['OS_ARCH'] == 'WINNT':
 > -SOURCES += [
 > -'../compat/strtod.c'
 > }}}
 > is the thing that is bothering you. Back then this got introduced to fix
 compilation with mingw-w64. But that's not an issue anymore without this
 particular code.
 They, probably, don't use CRT then.
 > So, what exactly is the problem with that removal for our mingw-w64
 builds as they are building fine now?
 Building fine, but working?
 > And could you point to the security problematic that you think is
 obvious with removing those three code lines? (the one you mentioned in
 comment:2 does not seem to be it)
 No, the security problematic is that ESR52 was never tested with anything
 below UCRT and in general:
 > It makes it very expensive for us to fix bugs in already-released
 versions of the libraries because we are no longer actively working in the
 codebases for those versions, so fixes must be individually backported and
 tested. The result is that we usually fix only serious security
 vulnerabilities in old versions of the libraries. Other bugs are generally
 fixed only for the next major version. (M$)

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

Re: [tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:4 cypherpunks]:
 > Don't you see that Jacek's patch activated compat shims for mingw? They
 were removed later as useless for UCRT (but needed for <=
 `msvcr120.dll`!).

 Oh, okay. You are just concerned about https://hg.mozilla.org/mozilla-
 central/rev/5680a55b2ec1? I thought about cases in the other patches as
 well as you posted them in the description. But as I said they are guarded
 by `_MSC_VER` defines which are not used by mingw-w64 anyway.

 So it seems
 {{{
 -if CONFIG['OS_ARCH'] == 'WINNT':
 -SOURCES += [
 -'../compat/strtod.c'
 }}}
 is the thing that is bothering you. Back then this got introduced to fix
 compilation with mingw-w64. But that's not an issue anymore without this
 particular code. So, what exactly is the problem with that removal for our
 mingw-w64 builds as they are building fine now? And could you point to the
 security problematic that you think is obvious with removing those three
 code lines? (the one you mentioned in comment:2 does not seem to be 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] #23659 [Applications/Tor Browser]: Clean-up content sandboxing code for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#23659: Clean-up content sandboxing code for Tor Browser on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:  #23658| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > > 2. For security/sandbox/chromium/sandbox/win/src/sidestep_resolver.cc:
 do we know what the implications are for the FIXME (making
 `SmartSidestepResolverThunk::SmartStub()` a NOOP)?
 >
 > I trust bobowen when he says this one does not get used right now
 Could you add an assertion to https://dxr.mozilla.org/mozilla-
 
esr52/source/security/sandbox/chromium/sandbox/win/src/interception_agent.cc#226
 to be sure?

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

Re: [tor-bugs] #23598 [Obfuscation/BridgeDB]: Bump pyOpenSSL in BridgeDB to 16.2.0

[Tor Bug Tracker & Wiki]

#23598: Bump pyOpenSSL in BridgeDB to 16.2.0
--+---
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:|Sponsor:  SponsorM
--+---

Comment (by gk):

 I am fine if that's a duplicate (and btw: I really got this traceback by
 just following the README and trying to run the tests/getting the
 requirements installed). What is confusing is that `master` is not the
 branch to write patches against (i.e. not the one containing the latest
 code). Which other canonical branch is the right one to use if one wants
 to do development and write patches for issues popping up?

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

Re: [tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Don't you see that Jacek's patch activated compat shims for mingw? They
 were removed later as useless for UCRT (but needed for <=
 `msvcr120.dll`!).

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

Re: [tor-bugs] #23669 [Internal Services/Tor Sysadmin Team]: Deploy survey microsite to tpo infrastructure

[Tor Bug Tracker & Wiki]

#23669: Deploy survey microsite to tpo infrastructure
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #23376   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by linda):

 I don't have preferences, so I'll wait until others weigh in.

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

Re: [tor-bugs] #23668 [Internal Services/Service - git]: New git repository in Infrastructure and Administration /project for survey microsite

[Tor Bug Tracker & Wiki]

#23668: New git repository in Infrastructure and Administration /project for 
survey
microsite
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #23376   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Sure! What name would you like for the repo? Should anyone else have
 commit access? Should other people be able to read 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] #23598 [Obfuscation/BridgeDB]: Bump pyOpenSSL in BridgeDB to 16.2.0

[Tor Bug Tracker & Wiki]

#23598: Bump pyOpenSSL in BridgeDB to 16.2.0
--+---
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:|Sponsor:  SponsorM
--+---
Changes (by isis):

 * status:  needs_review => closed
 * points:   => .1
 * resolution:   => duplicate
 * sponsor:   => SponsorM
 * actualpoints:   => .1


Comment:

 Replying to [ticket:23598 gk]:
 > When doing e.g. `pip install -r .test.requirements.txt` (with OpenSSL
 1.1.0f) one gets

 Hi! Thanks for reporting this! I'm a little bit confused because
 `.test.requirements.txt` doesn't list `PyOpenSSL` as a dependency (the
 whole point of that file is so that the Travis CI setup can test a matrix
 of different versions of Twisted and PyOpenSSL, see the `install:` stanza
 in `.travis.yml` and the script at `scripts/install-dependencies` that it
 executes).

 > {{{
 > Traceback (most recent call last):
 >   File "/home/thomas/.virtualenvs/bridgedb/bin/pip", line 7, in 
 > from pip import main
 >   File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-
 packages/pip/__init__.py", line 21, in 
 > from pip._vendor.requests.packages.urllib3.exceptions import
 DependencyWarning
 >   File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-
 packages/pip/_vendor/__init__.py", line 64, in 
 > vendored("cachecontrol")
 >   File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-
 packages/pip/_vendor/__init__.py", line 36, in vendored
 > __import__(modulename, globals(), locals(), level=0)
 >   File "/home/thomas/.virtualenvs/bridgedb/share/python-
 wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/__init__.py",
 line 9, in 
 >   File "/home/thomas/.virtualenvs/bridgedb/share/python-
 wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/wrapper.py",
 line 1, in 
 >   File "/home/thomas/.virtualenvs/bridgedb/share/python-
 wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/adapter.py",
 line 4, in 
 >   File "/home/thomas/.virtualenvs/bridgedb/share/python-
 wheels/requests-2.12.4-py2.py3-none-any.whl/requests/__init__.py", line
 52, in 
 >   File "/home/thomas/.virtualenvs/bridgedb/share/python-
 wheels/requests-2.12.4-py2.py3-none-
 any.whl/requests/packages/__init__.py", line 59, in 
 >   File "/home/thomas/.virtualenvs/bridgedb/share/python-
 wheels/requests-2.12.4-py2.py3-none-
 any.whl/requests/packages/__init__.py", line 32, in vendored
 >   File "/home/thomas/.virtualenvs/bridgedb/share/python-
 wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/contrib/pyopenssl.py",
 line 47, in 
 >   File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-
 packages/OpenSSL/__init__.py", line 8, in 
 > from OpenSSL import rand, crypto, SSL
 >   File "/home/thomas/.virtualenvs/bridgedb/lib/python2.7/site-
 packages/OpenSSL/SSL.py", line 105, in 
 > SSL_ST_INIT = _lib.SSL_ST_INIT
 > AttributeError: 'module' object has no attribute 'SSL_ST_INIT'
 > }}}
 > This is essentially https://github.com/pyca/pyopenssl/issues/525.

 The other thing is that the `PyOpenSSL` dependency listed in
 `requirements.txt` was updated as part of #22998 in commit `0ae12639c`.
 Sorry for the trouble! I'm closing as a duplicate, but feel free to reopen
 if I misunderstood.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23669 [Internal Services/Tor Sysadmin Team]: Deploy survey microsite to tpo infrastructure

[Tor Bug Tracker & Wiki]

#23669: Deploy survey microsite to tpo infrastructure
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:  ux-team
Actual Points:   |  Parent ID:  #23376
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I'd like to deploy the survey microsite on tpo infrastructure or
 eventually get a tpo subdomain and deploy it from greenhost.


 If we prefer to deploy it on tpo, we would have to consider that it is a
 rails app. I'd need postgres and like to be able to install gem at user
 level. If possible I'd prefer to instal a local (user) version of ruby  w/
 rbenv.


 Please let me know what we prefer regarding this and how I can help.

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

Re: [tor-bugs] #23437 [Webpages/Webtools]: newsletter archive, subscribe and unsubscribed pages

[Tor Bug Tracker & Wiki]

#23437: newsletter archive, subscribe and unsubscribed pages
---+--
 Reporter:  isabela|  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Webtools  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #23096 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * Attachment "cut off.png" added.

 content cut off

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23668 [Internal Services/Service - git]: New git repository in Infrastructure and Administration /project for survey microsite

[Tor Bug Tracker & Wiki]

#23668: New git repository in Infrastructure and Administration /project for 
survey
microsite
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:  ux-team
Actual Points:   |  Parent ID:  #23376
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Can I get a tor git repository to host the code for the survey microsite?

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

Re: [tor-bugs] #23437 [Webpages/Webtools]: newsletter archive, subscribe and unsubscribed pages

[Tor Bug Tracker & Wiki]

#23437: newsletter archive, subscribe and unsubscribed pages
---+--
 Reporter:  isabela|  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Webtools  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #23096 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by steph):

 cool :)
 - It looks like some content is getting cut off on the front page and
 archive page.
 - will the archive be separate like this or will it be in a side column?
 - the format of the archived newsletter appears to be lost

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

Re: [tor-bugs] #22461 [Core Tor/Tor]: Tor emits inaccurate safesocks warning event whenever you visit a naked IP address

[Tor Bug Tracker & Wiki]

#22461: Tor emits inaccurate safesocks warning event whenever you visit a naked 
IP
address
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Ok so after getting clarifications from arma, the bottom line is that tor
 should NOT warn if we have a SOCKS5 hostname + IP address that is `ATYP
 0x03` with an IPv4/6 address. Application should always use tor that way
 if they did get an IP address from the user in the first place and no DNS
 resolution happened.

 Tor is doing that correctly, only warning for IPv4/v6 atyp + IP string.

 Torsocks is the one not doing that correctly (#23667).

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

Re: [tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:2 cypherpunks]:
 > Are you sure? Did you see what was removed in the last bug? Citing:
 > {{{
 > -/* we use n - 1 here because if the buffer is not big enough, the
 MS
 > - * runtime libraries don't add a terminating zero at the end. MSDN
 > - * recommends to provide _snprintf/_vsnprintf() a buffer size that
 > - * is one less than the actual buffer, and zero it before calling
 > - * _snprintf/_vsnprintf() to workaround this problem.
 > - * See http://msdn.microsoft.com/en-
 us/library/1kt27hek(v=vs.80).aspx */
 > }}}
 > Now you use them without workarounds and who knows what else...

 Well, basically all of that which you are pointing to was behing
 `_MSC_VER` which is not defined in our builds anyway. Thus, we are/were
 not affected by that. Or am I missing something?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23667 [Core Tor/Torsocks]: Always send ATYP 0x03 (domain name) with a plain IP address

[Tor Bug Tracker & Wiki]

#23667: Always send ATYP 0x03 (domain name) with a plain IP address
---+--
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Noticed with #22461, torsocks should always send a DOMAIN NAME type for
 the SOCKS5 request if it gets a plain IP address so tor doesn't warn on
 the control port and SafeSocks to deny the request.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23666 [Internal Services/Tor Sysadmin Team]: Deploy newsletter microsite to tpo infrastructure

[Tor Bug Tracker & Wiki]

#23666: Deploy newsletter microsite to tpo infrastructure
-+
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #23096
   Points:   |   Reviewer:
  Sponsor:   |
-+
 I'd like to deploy the newsletter microsite on tpo infrastructure or get
 newsletter.tpo subdomain for 37.218.240.202.

 If we prefer to deploy it on tpo, we would have to consider that it is a
 rails app. I'd need postgres and like to be able to install gem at user
 level. If possible I'd prefer to instal a local (user) version of ruby w/
 rbenv.

 Please let me know what we prefer regarding this and how I can help.

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

Re: [tor-bugs] #23159 [Core Tor/Tor]: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at src/or/hs_service.c:1784

[Tor Bug Tracker & Wiki]

#23159: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at
src/or/hs_service.c:1784
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Sure; merging. But next time please make sure "make check" passes?

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

Re: [tor-bugs] #23437 [Webpages/Webtools]: newsletter archive, subscribe and unsubscribed pages

[Tor Bug Tracker & Wiki]

#23437: newsletter archive, subscribe and unsubscribed pages
---+--
 Reporter:  isabela|  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Webtools  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #23096 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * parent:   => #23096


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

Re: [tor-bugs] #23096 [Internal Services/Blog]: Request to create solution for permanent link of newsletter letters + archive (was: Request to investigate solution for permanent link of newsletter let

[Tor Bug Tracker & Wiki]

#23096: Request to create solution for permanent link of newsletter letters +
archive
+--
 Reporter:  isabela |  Owner:  hiro
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Blog  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

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

Re: [tor-bugs] #23435 [Internal Services/Service - git]: New git repository in Infrastructure and Administration /project for newsletter microsite

[Tor Bug Tracker & Wiki]

#23435: New git repository in Infrastructure and Administration /project for
newsletter microsite
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #23096   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by hiro):

 * parent:  #23437 => #23096


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

Re: [tor-bugs] #23435 [Internal Services/Service - git]: New git repository in Infrastructure and Administration /project for newsletter microsite

[Tor Bug Tracker & Wiki]

#23435: New git repository in Infrastructure and Administration /project for
newsletter microsite
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #23437   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by hiro):

 * parent:   => #23437


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

Re: [tor-bugs] #23437 [Webpages/Webtools]: newsletter archive, subscribe and unsubscribed pages

[Tor Bug Tracker & Wiki]

#23437: newsletter archive, subscribe and unsubscribed pages
---+--
 Reporter:  isabela|  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Webtools  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * 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] #23437 [Webpages/Webtools]: newsletter archive, subscribe and unsubscribed pages

[Tor Bug Tracker & Wiki]

#23437: newsletter archive, subscribe and unsubscribed pages
---+--
 Reporter:  isabela|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Webtools  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hiro):

 There are a few things to fix in navigation but I have applied the mockup:
 http://37.218.240.202

 Also  the subscribe is working and posting to civi. The confirmation pages
 are still living on civi, but I think we could ask giant rabbit to
 redirect to the newsletter and we could make confirmation pages?

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

Re: [tor-bugs] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  haxxpop
 Type:  task   | Status:  assigned
 Priority:  Very High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by dgoulet):

 * owner:  dgoulet => haxxpop
 * status:  needs_revision => 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] #23100 [Core Tor/Tor]: Circuit Build Timeout needs to count hidden service circuits

[Tor Bug Tracker & Wiki]

#23100: Circuit Build Timeout needs to count hidden service circuits
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery,  |  Actual Points:
  needs-proposal, mike-can, prop247, tor-guard   |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 This should have been in needs_review a while 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] #21446 [Core Tor/Tor]: Number of Introduction Points for a (SingleOnion?) HS seems variable, or degrades with time

[Tor Bug Tracker & Wiki]

#21446: Number of Introduction Points for a (SingleOnion?) HS seems variable, or
degrades with time
---+---
 Reporter:  alecmuffett|  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.3.9-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, 031-deferred-20170425  |  Actual Points:  0.5
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Both remaining child tickets have been postponed to 033.

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

Re: [tor-bugs] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

[Tor Bug Tracker & Wiki]

#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #23262 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: mcs (added)


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

Re: [tor-bugs] #23159 [Core Tor/Tor]: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at src/or/hs_service.c:1784

[Tor Bug Tracker & Wiki]

#23159: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at
src/or/hs_service.c:1784
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 See branch: `bug23159_032_02`.

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

Re: [tor-bugs] #17879 [Applications/Tor Browser]: Activating the Flash Player is not working anymore since Tor Browser 5.0.5

[Tor Bug Tracker & Wiki]

#17879: Activating the Flash Player is not working anymore since Tor Browser 
5.0.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-usability-website,   |  Actual Points:
  TorBrowserTeam201512   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Flash plugin Click-to-Play (aka "Ask to Activate") is finally fixed in
 upstream https://bugzilla.mozilla.org/show_bug.cgi?id=1365714

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23665 [Applications/Tor Messenger]: Enable content process sandbox on Windows

[Tor Bug Tracker & Wiki]

#23665: Enable content process sandbox on Windows
+
 Reporter:  arlolra |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 Port the changes from #16010

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)

[Tor Bug Tracker & Wiki]

#23602: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)
-+-
 Reporter:  hellais  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 032-backport, 031  |  Actual Points:
  -backport-maybe, 030-backport-maybe|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.1.x-final


Comment:

 Hm. I'm okay merging this in 0.3.2 for now.  Let's see if it causes any
 trouble  there before we think about backporting further.

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  asn
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression backport?  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_revision => needs_review
 * reviewer:  dgoulet => asn


Comment:

 Ok some changes happened. I took over the branch as discussed and
 implemented a way to not trigger a new fetch request if we already have
 one pending for a given service.

 So, if we launch 7 SOCKS requests, the first one will fetch then the 6
 others will wait patiently that either the descriptor arrives or the
 fetches fail and they are all closed after.

 See branch: `bug23653_032_01`

 This does NOT implement the above for v2, only v3 for now. If we are
 satisfied with this, we should fix v2 for an improved user experience.

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by nickm):

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


Comment:

 no problem!  I've made the changes you asked for in a typecheck4 branch,
 and am now merging to master. Thanks again for the reviews!

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

Re: [tor-bugs] #17248 [Applications/Tor Browser]: Investigate new WebExtensions API requirements for our extensions

[Tor Bug Tracker & Wiki]

#17248: Investigate new WebExtensions API requirements for our extensions
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201512  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 As stated by the other cypherpunk in #19, Mozilla are removing the stuff
 that is no longer needed when XPCOM extensions are no longer supported
 https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

 Also porting it to WebExtension early may be a great way to catch all the
 bugs before it's production ready.

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me!

 Feel free to merge as is, but here are a few nitpicks that will hopefully
 improve clarity:
 * In the changes file, maybe say "any type mismatches between the C type
 representing a configuration variable and the C type the data-driven
 parser uses to store a value there"? The current wording implies that it
 checks for user errors in a config file.
 * Maybe mention in the comment for `CONF_CHECK_VAR_TYPE()` that the type
 checking technique works because a mismatch violates the type
 compatibility constraint on simple assignment and requires a diagnostic?
 (That way it's more clear that a conforming compiler will produce some
 sort of warning and we're not relying on a specific compiler's
 enthusiastic warning behavior.)
 * Maybe use a macro, possibly named `DUMMY_TYPECHECK_INSTANCE`, to declare
 the dummy structs?
 * The `int *UINT; /* yes, really. */` comment could be more clear,
 possibly `/* yes, config_assign_value() bounds-checks "UINT" values as
 0..INT_MAX */`?
 * The non-unit-test variant of `CONF_TEST_MEMBERS()` should use the same
 parameter names as the other unit-test variant.
 * Removal of the `const` qualifier for `TransProxyType` is not documented
 in the commit message.
 Sorry about the length; this is a tricky technique and I would like us to
 make it as clear as possible what's going on.

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

Re: [tor-bugs] #20963 [Core Tor/Tor]: [notice] The Tor Directory Consensus has changed how many circuits we must track to detect network failures from 0 to 20.

[Tor Bug Tracker & Wiki]

#20963: [notice] The Tor Directory Consensus has changed how many circuits we 
must
track to detect network failures from 0 to 20.
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 031-deferred-20170425  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Any suggestions for what the error message should be?

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

Re: [tor-bugs] #23228 [Applications/Tor Browser]: Build a Windows 64 toolchain based on mingw-w64

[Tor Bug Tracker & Wiki]

#23228: Build a Windows 64 toolchain based on mingw-w64
---+---
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #20636 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 So, if you're ready to get it going till merged upstream, then I can
 provide the required info.

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

Re: [tor-bugs] #22090 [Core Tor/Tor]: Rename channel client functions for clarity

[Tor Bug Tracker & Wiki]

#22090: Rename channel client functions for clarity
---+
 Reporter:  teor   |  Owner:  toby
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy refactor  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.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

Re: [tor-bugs] #23411 [Webpages]: Creating a live style guide

[Tor Bug Tracker & Wiki]

#23411: Creating a live style guide
--+
 Reporter:  hiro  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by hiro):

 Prototype lives on: !https://marvelapp.com/6c5ce44

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

Re: [tor-bugs] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+-
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression, 031-backport|  Actual Points:
  032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  sandbox, regression, review-group-23 => sandbox, regression,
 031-backport 032-backport
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.3.x-final


Comment:

 Yes, I think 0.3.2 or 0.3.3 might be better, with a possible backport if
 it works out.  The fix looks good to me, but it's subtle and we could have
 missed something, so it's best to try it in a pre-alpha 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] #23658 [Applications/Tor Browser]: Improve content sandboxing Tor Browser users on Windows

[Tor Bug Tracker & Wiki]

#23658: Improve content sandboxing Tor Browser users on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 For convenience the old ticket was #16010

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

Re: [tor-bugs] #23664 [Applications/Tor Browser]: Deal with GUID for content sandbox temp folder on Windows

[Tor Bug Tracker & Wiki]

#23664: Deal with GUID for content sandbox temp folder on Windows
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-disk-leak  |  Actual Points:
Parent ID:  #23658   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by tom):

 * cc: tom (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] #23661 [Applications/Tor Browser]: Set content sandbox for Tor Browser on Windows to level 2

[Tor Bug Tracker & Wiki]

#23661: Set content sandbox for Tor Browser on Windows to level 2
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:  #23658| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * cc: tom (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] #23660 [Applications/Tor Browser]: Handle exceptions in content sandboxing code for Tor Browser on Windows properly

[Tor Bug Tracker & Wiki]

#23660: Handle exceptions in content sandboxing code for Tor Browser on Windows
properly
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:  #23658| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * cc: tom (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] #23659 [Applications/Tor Browser]: Clean-up content sandboxing code for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#23659: Clean-up content sandboxing code for Tor Browser on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:  #23658| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * cc: tom (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] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-sr, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * keywords:  tor-hs, tor-sr => tor-hs, tor-sr, prop224


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

Re: [tor-bugs] #23373 [Webpages/Website]: Add new press clips to website

[Tor Bug Tracker & Wiki]

#23373: Add new press clips to website
--+
 Reporter:  steph |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by steph):

 I emailed an updated spreadsheet with additional clips to add.

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

Re: [tor-bugs] #23659 [Applications/Tor Browser]: Clean-up content sandboxing code for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#23659: Clean-up content sandboxing code for Tor Browser on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:  #23658| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 And ticket:16010#comment:62 too.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:11 nickm]:
 > looks okay but needs a changes file.  How tested is this?

 Not fully tested because the race is difficult to get in chutney or the
 network.

 Although, we can probably pull it off in a unit test to at least test that
 it works out.

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

Re: [tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Are you sure? Did you see what was removed in the last bug? Citing:
 {{{
 -/* we use n - 1 here because if the buffer is not big enough, the MS
 - * runtime libraries don't add a terminating zero at the end. MSDN
 - * recommends to provide _snprintf/_vsnprintf() a buffer size that
 - * is one less than the actual buffer, and zero it before calling
 - * _snprintf/_vsnprintf() to workaround this problem.
 - * See http://msdn.microsoft.com/en-us/library/1kt27hek(v=vs.80).aspx
 */
 }}}
 Now you use them without workarounds and who knows what 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] #22581 [Applications/Tor Browser]: Tor browser is crashing on exit on Windows

[Tor Bug Tracker & Wiki]

#22581: Tor browser is crashing on exit on Windows
-+-
 Reporter:  WalrusInAnus |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, tbb-7.0-issues, tbb-  |  Actual Points:
  regression, GeorgKoppen201709, |
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sudha@…):

 I have seen this bug since ages ago, most likely from the first 7a
 version. Certainly it is present on all 7 alphas for windows.

 Steps to reproduce from fresh install are very easy -- I have reproduced
 that on three different systems, Win8.1, Win10 1703 and 1607 builds.

 What's worse, after quite a while of such usage the Tor profile can appear
 very corrupted -- to the point that tor browser starts crashing on start,
 or more specifically -- start browser and then click on a tab get a crash.

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

Re: [tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Could you elaborate what this bug is about? I have a hard time
 understanding the problem given that Tor Browser based on esr52 is working
 fine with the msvcr100.dll we ship.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R,  |
  tbb-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * keywords:
 ff52-esr, tbb-e10s, tbb-security, GeorgKoppen201709,
 TorBrowserTeam201709R
 =>
 ff52-esr, tbb-e10s, tbb-security, GeorgKoppen201709,
 TorBrowserTeam201709R, tbb-backport


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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  asn
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression backport?  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * cc: dgoulet (removed)
 * reviewer:   => dgoulet
 * status:  needs_review => needs_revision


Comment:

 All commits lgtm. Below is for one single commit `e278d84df5294872`:

 * `if (base_conn->marked_for_close` is dead code because
 `connection_list_by_type_state()` does NOT send you back marked for close
 connections.

 * I think this should be done outside of the for each loop:
 `purge_hid_serv_request(identity_pk);`

 * The other thing I'm thinking about is that I've always been annoyed by
 the v2 warning that doesn't tell me _why_ tor had to give up on the
 service. You think we can move the error code we get from
 `fetch_v3_desc()` up to that function?

 * Also, I think we could do this warning only once instead of for each
 SOCKS connection? Else, we should try to put some identifier of the SOCKS
 request in the log if we really want one per-socks. I often get those like
 5 in a row because I had 5 SOCKS request for 5 different email account
 going to the same .onion...

 * `conns` memory leaks, it needs to be `smartlist_free()`.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

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


Comment:

 Okay, I made two fixups:

 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.3.0esr-7.5-2=2354d122644d82df54d655ece5b42bdfa4cf38f8
 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.4.0esr-7.5-1=0a9793458e9ddd5c7742d3ceb250125c52e8bf86

 in addition to the patches that were up for review. (see: comment:54 for
 those). The ones for review got applied to `tor-browser-52.3.0esr-75.-2`
 before rebasing:

 commit 99e8c2c94986940de47d5f50a4b863cb6127df3d
 commit 0b5dfeae5d09168e020acd2f630c5352674075ab
 commit 6cafd21960e74a78317330c8559f643e4beac165.

 The `tor-browser-build` change that landed is commit
 682966b5b0faf438e69f61092487a6ea99534525. We are done here. I created the
 follow-up parent ticket #23658 to improve on the code we have right now
 and four child tickets. #23659, #23660, #23661, and #23664 addressing open
 issues like code clean-up and the GUID of the temp folder. Thanks all!

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:63 arthuredelstein]:
 > Replying to [comment:54 gk]:
 > > `bug_16010_v4` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_16010_v4) has the `tor-browser` patches for review.
 https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_16010_v4=03833cf4c2a833f6e5420e92368ac2dae1b99c70
 has the additional code changes I needed to apply.
 > >
 > > Attached is a fix for the `tor-browser-build` site as well as this is
 still needed due to different `.mozconfig` handlings.
 >
 > I also had a look and didn't find any obvious errors, though I too am
 not familiar with the chromium sandbox code. I think it might be useful to
 briefly document the compile issues fixed in the first patch, either as
 comments or in the commit message.
 >
 > One thing that puzzled me is the section here:
 > https://gitweb.torproject.org/user/gk/tor-
 browser.git/diff/security/sandbox/chromium-
 
shim/base/win/sdkdecls.h?h=bug_16010_v4=4f613829fdcbf6dba4e80e8df1d356cb1c0a7de7
 > You have changed one constant integer to the uLL suffix, but the others
 remain ui64. I'm wondering if there's a reason for that.

 There is no reason for that. It's mainly Jacek PoC he whipped up to get
 the code compiled. It certainly needs some clean-up. We have #23659 for
 that.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:64 cypherpunks]:
 > If you modify the declaration of `flag_aux_` (and others) in `Opcode`
 struct, then why not in `SpecificOpcode` struct too?

 We don't need that at the moment it seems. But having a clean-up would be
 good to have, yes. See: #23659.

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

Re: [tor-bugs] #23659 [Applications/Tor Browser]: Clean-up content sandboxing code for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#23659: Clean-up content sandboxing code for Tor Browser on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:  #23658| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 And see comment:64:ticket:16010, too.

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

Re: [tor-bugs] #16010 [Applications/Tor Browser]: Get a working content process sandbox for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#16010: Get a working content process sandbox for Tor Browser on Windows
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-security,|  Actual Points:
  GeorgKoppen201709, TorBrowserTeam201709R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:65 cypherpunks]:
 > [http://gynvael.coldwind.pl/?id=15 FIXME !!] for ` __declspec(naked)`
 until [https://gcc.gnu.org/gcc-8/changes.html#x86 GCC 8] is released
 (underscore bug is also mentioned). Can pospeselr do that?

 We might not need that:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1230910#c28.

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

Re: [tor-bugs] #23643 [Core Tor/Tor]: Type-check struct members that are passed to confparse

[Tor Bug Tracker & Wiki]

#23643: Type-check struct members that are passed to confparse
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Nice; that ''does'' work, and it's simpler too.

 I have a new branch as `typecheck3`.

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

Re: [tor-bugs] #23659 [Applications/Tor Browser]: Clean-up content sandboxing code for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#23659: Clean-up content sandboxing code for Tor Browser on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:  #23658| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 See: comment:63:ticket:16010 for one of the things we might want to make
 more clear.

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

Re: [tor-bugs] #23159 [Core Tor/Tor]: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at src/or/hs_service.c:1784

[Tor Bug Tracker & Wiki]

#23159: Bug: Non-fatal assertion ei failed in launch_intro_point_circuits at
src/or/hs_service.c:1784
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_information => accepted


Comment:

 All in all, even though we haven't hit it yet, having a NULL extend info
 object from a node_t is possible so we should handle that gracefully.

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

Re: [tor-bugs] #23664 [Applications/Tor Browser]: Deal with GUID for content sandbox temp folder on Windows

[Tor Bug Tracker & Wiki]

#23664: Deal with GUID for content sandbox temp folder on Windows
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-disk-leak  |  Actual Points:
Parent ID:  #23658   | Points:
 Reviewer:   |Sponsor:
-+--
Description changed by gk:

Old description:

> comment:56:ticket:16010 mentioned:
> {{{
> Very important side issue is that the sandboxing feature adds
> `security.sandbox.content.tempDirSuffix` pref which is a 128-bit GUID
> that allows to uniquely identify your copy of Tor Browser. It is
> persistent and leaves unique traces on every machine you use in system
> %TEMP% folder.
> }}}
> We should find a good way dealing with that. Maybe as a first start is to
> set the pref, so that every Windows users has the same sandbox temp dir
> name

New description:

 comment:56:ticket:16010 mentioned:
 {{{
 Very important side issue is that the sandboxing feature adds
 `security.sandbox.content.tempDirSuffix` pref which is a 128-bit GUID that
 allows to uniquely identify your copy of Tor Browser. It is persistent and
 leaves unique traces on every machine you use in system %TEMP% folder.
 }}}
 We should find a good way dealing with that. Maybe a first start is to set
 the pref, so that every Windows user has the same sandbox temp dir name.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23664 [Applications/Tor Browser]: Deal with GUID for content sandbox temp folder on Windows

[Tor Bug Tracker & Wiki]

#23664: Deal with GUID for content sandbox temp folder on Windows
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-security, tbb-disk-
 Severity:  Normal   |  leak
Actual Points:   |  Parent ID:  #23658
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 comment:56:ticket:16010 mentioned:
 {{{
 Very important side issue is that the sandboxing feature adds
 `security.sandbox.content.tempDirSuffix` pref which is a 128-bit GUID that
 allows to uniquely identify your copy of Tor Browser. It is persistent and
 leaves unique traces on every machine you use in system %TEMP% folder.
 }}}
 We should find a good way dealing with that. Maybe as a first start is to
 set the pref, so that every Windows users has the same sandbox temp dir
 name

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

Re: [tor-bugs] #23662 [Core Tor/Tor]: prop224: Service edge-case where it re-uploads descriptor with same rev counter

[Tor Bug Tracker & Wiki]

#23662: prop224: Service edge-case where it re-uploads descriptor with same rev
counter
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by asn:

Old description:

> There is an edge case where if a service's HSDir connection times out
> before getting a 200 back, Tor will open a second connection with the
> same `outbuf` as the previous one and retry the upload. See
> `connection_ap_detach_retriable()` which gets called from
> `connection_ap_expire_beginning()`.
>
> That's a problem for v3 HSes, since that logic bypasses the HS subsystem
> and the rev counter does not get incremented for the second upload.
>
> The problem is that if the first connections ends up succeeding (even tho
> it timed out), the second connection will fail because of rev counter
> issues.
>
> This is not a reachability issue since one of the two conns will
> eventually succeed and the right descriptor will be uploaded. However it
> generates a log_warn on the service-side that might be annoying, and a
> log_info on the HSdir side.

New description:

 There is an edge case where if a service's HSDir connection times out
 before getting a 200 back, Tor will open a second connection with the same
 `outbuf` as the previous one and retry the upload. See
 `connection_ap_detach_retriable()` which gets called from
 `connection_ap_expire_beginning()` which detaches the stream from the
 circuit and marks it as pending again.

 That's a problem for v3 HSes, since that logic bypasses the HS subsystem
 and the rev counter does not get incremented for the second upload.

 The problem is that if the first connections ends up succeeding (even tho
 it timed out), the second connection will fail because of rev counter
 issues.

 This is not a reachability issue since one of the two conns will
 eventually succeed and the right descriptor will be uploaded. However it
 generates a log_warn on the service-side that might be annoying, and a
 log_info on the HSdir side.

 The right fix here might involve intercepting that retry, and piping it
 through the HS subsystem. But this will require refactoring.

--

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

[tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:  tbb-security
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 First, Mozilla fixed VS2015 compilation https://hg.mozilla.org/mozilla-
 central/rev/e597b8795fbe
 Second, Jacek "fixed" ffvpx compilation on mingw. And it became
 incompatible with UCRT on mingw (Jacek, don't do that again!)
 https://hg.mozilla.org/mozilla-central/rev/5680a55b2ec1
 Third, Mozilla dropped support for building with Visual Studio 2013
 https://bugzilla.mozilla.org/show_bug.cgi?id=1186064 in Firefox 50. But
 not only that! They started vigorously removing all their patches for it!
 https://bugzilla.mozilla.org/show_bug.cgi?id=1277155 and almost all other
 compatibility shims/workarounds were removed before ESR52.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23661 [Applications/Tor Browser]: Set content sandbox for Tor Browser on Windows to level 2

[Tor Bug Tracker & Wiki]

#23661: Set content sandbox for Tor Browser on Windows to level 2
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-security
Actual Points:|  Parent ID:  #23658
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #16010 we prepared a patch for enabling content sandboxing for Tor
 Browser on Windows. We started with level 1. We should try if we can
 switch to level 2 without much 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

[tor-bugs] #23662 [Core Tor/Tor]: prop224: Service edge-case where it re-uploads descriptor with same rev counter

[Tor Bug Tracker & Wiki]

#23662: prop224: Service edge-case where it re-uploads descriptor with same rev
counter
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, prop224
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There is an edge case where if a service's HSDir connection times out
 before getting a 200 back, Tor will open a second connection with the same
 `outbuf` as the previous one and retry the upload. See
 `connection_ap_detach_retriable()` which gets called from
 `connection_ap_expire_beginning()`.

 That's a problem for v3 HSes, since that logic bypasses the HS subsystem
 and the rev counter does not get incremented for the second upload.

 The problem is that if the first connections ends up succeeding (even tho
 it timed out), the second connection will fail because of rev counter
 issues.

 This is not a reachability issue since one of the two conns will
 eventually succeed and the right descriptor will be uploaded. However it
 generates a log_warn on the service-side that might be annoying, and a
 log_info on the HSdir 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] #23657 [Applications/Tor Browser]: Decide directories used for signed/unsigned builds in tor-browser-builds

[Tor Bug Tracker & Wiki]

#23657: Decide directories used for signed/unsigned builds in tor-browser-builds
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 >  I think having different directories could also be useful if we want to
 add some scripts helping with the intermediate signing steps.

 I think some of the scripts/makefile targets that could be useful are:
 - uploading the unsigned dmg files to the osx signing machine
 - downloading the code signed osx tar.bz2 files
 - converting the code signed osx tar.bz2 to dmg files
 - uploading the exe files to the linux signing machine
 - downloading the signed exe files (with an rsync over the unsigned files)
 - timestamping the signed exe files
 - uploading the mar files to the linux signing machine for mar signing
 - uploading the signed+timestamped exe files to the linux signing machine
 (with an rsync ovec the previously uploaded ones), for gpg signing
 - uploading the code signed dmg files to the linux signing machine, for
 gpg signing

 > the dmg2mar target is using the signed directory. However at this point,
 only the dmg files are signed, so it is confusing to put all the files in
 the signed directory. Maybe an intermediate directory should be used
 instead?

 One option is to do that in an intermediate directory such as `signed-
 dmg`. An other option is to do it in the `unsigned` directory directly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23660 [Applications/Tor Browser]: Handle exceptions in content sandboxing code for Tor Browser on Windows properly

[Tor Bug Tracker & Wiki]

#23660: Handle exceptions in content sandboxing code for Tor Browser on Windows
properly
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-security
Actual Points:|  Parent ID:  #23658
   Points:|   Reviewer:
  Sponsor:|
--+--
 At the moment we just rip out the SEH parts of the content sandboxing code
 as mingw-w64 has trouble handling it. We should provide a proper fix for
 it, 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] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  asn
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression backport?  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Worth mentioning that my branch will fix this issue but reveal the
 original issue of #15937. Perhaps #15937 is a minor problem tho.

 Also this might be worth backporting back to 0.2.8.

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

[tor-bugs] #23659 [Applications/Tor Browser]: Clean-up content sandboxing code for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#23659: Clean-up content sandboxing code for Tor Browser on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-security
Actual Points:|  Parent ID:  #23658
   Points:|   Reviewer:
  Sponsor:|
--+--
 Jacek wrote back then a PoC to get the Tor Browser content sandbox
 compiled for Windows. We should go thoroughly over the that code and clean
 it up.

 We already shipped two fix up patches to the original patch:

 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.3.0esr-7.5-2=2354d122644d82df54d655ece5b42bdfa4cf38f8
 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.4.0esr-7.5-1=0a9793458e9ddd5c7742d3ceb250125c52e8bf86

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

Re: [tor-bugs] #23658 [Applications/Tor Browser]: Improve content sandboxing Tor Browser users on Windows

[Tor Bug Tracker & Wiki]

#23658: Improve content sandboxing Tor Browser users on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-security


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23658 [Applications/Tor Browser]: Improve content sandboxing Tor Browser users on Windows

[Tor Bug Tracker & Wiki]

#23658: Improve content sandboxing Tor Browser users on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In 7.5a5 a Windows content sandbox ships for the first time. This ticket
 is a parent ticket for documenting and fixing the remaining loose ends
 resulting in an improved Tor Browser content sandbox on Windows

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  asn
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression backport?  |  Actual Points:
Parent ID:| Points:
 Reviewer:|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] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  asn
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression backport?  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => asn
 * status:  needs_review => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #23645 [Core Tor/Tor]: hs: Continue to improve logging in both HS and circuit subsystems

[Tor Bug Tracker & Wiki]

#23645: hs: Continue to improve logging in both HS and circuit subsystems
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, tor-circuit, logging  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 thanks for the fix; I'm adding a changes file and merging.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 looks okay but needs a changes file.  How tested is 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] #23645 [Core Tor/Tor]: hs: Continue to improve logging in both HS and circuit subsystems

[Tor Bug Tracker & Wiki]

#23645: hs: Continue to improve logging in both HS and circuit subsystems
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, tor-circuit, logging  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 This needs a changes file; also, the tests don't pass for me:
 {{{
 hs_service/build_update_descriptors: [forking]
   FAIL src/test/test_hs_service.c:1154: expected log to contain "just
 picked 1 intro points and wanted 3. It " "currently has 0 intro points.
 Launching " "ESTABLISH_INTRO circuit shortly."  Captured logs:
 }}}

 asn, is it possible that you didn't commit some of your changes on your
 branch? I don't see any unit test fixes in this branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23657 [Applications/Tor Browser]: Decide directories used for signed/unsigned builds in tor-browser-builds

[Tor Bug Tracker & Wiki]

#23657: Decide directories used for signed/unsigned builds in tor-browser-builds
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 With gitian builds, all builds (signed and unsigned) were stored in the
 gitian directory directly.

 I remember having issues when generating incremental mars which were done
 with unsigned osx mars instead of the signed ones. To avoid that issue I
 have started with separating signed and unsigned builds in tor-browser-
 build. However it seems the new process is confusing and error-prone
 during the signing process, so we should think more about what directories
 we want to use in the different steps (or if we want to go back to using
 only one).

 I think having different directories could also be useful if we want to
 add some scripts helping with the intermediate signing steps.

 What we currently have is:
 - the build target creates builds in the directory `unsigned`
 - the incrementals target generates incremental mars in the `unsigned`
 directory. However it is using/downloading the mar files from the old
 version in the `unsigned` directory too, while it should be done from a
 signed build (for the osx ones). Maybe we should fix the incrementals step
 to use the old version from the `signed` directory instead.
 - the dmg2mar target is using the `signed` directory. However at this
 point, only the dmg files are signed, so it is confusing to put all the
 files in the `signed` directory. Maybe an intermediate directory should be
 used instead?
 - the update_responses target is using the `signed` directory. I think
 this one is correct as update responses should only be done from a fully
 signed build.

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

Re: [tor-bugs] #23650 [Core Tor/Tor]: Tor source code has many typos

[Tor Bug Tracker & Wiki]

#23650: Tor source code has many typos
--+
 Reporter:  cypherpunks   |  Owner:  arma
 Type:  defect| Status:  assigned
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.3.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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression backport?  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  regression => regression backport?
 * milestone:   => Tor: 0.3.2.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

Re: [tor-bugs] #8557 [Applications/Tor Browser]: Audit and possibly enable safebrowsing

[Tor Bug Tracker & Wiki]

#8557: Audit and possibly enable safebrowsing
-+--
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-pref, tbb-firefox-patch  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by sjmurdoch):

 * cc: sjmurdoch (removed)


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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * status:  new => needs_review


Comment:

 Please see branch `bug23653` in my repo for a fix for the v2 and v3 case.

 A bug was also found during this fix, since we were computing a blinded
 key using time(NULL) instead of consensus time which caused issues when
 purging the HSDir req cache.

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

Re: [tor-bugs] #23651 [Applications/Tor Browser]: ADDONS

[Tor Bug Tracker & Wiki]

#23651: ADDONS
--+---
 Reporter:  dmeek94@… |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Replying to [comment:5 dmeek94@…]:
 > I have been trying to add others though eg self destructing cookies,
 which installs but wont open.

 There's "New Identity" in the Torbutton which removes all cookies and
 stuff and gives you, well, a "New  Identity". You shouldn't thus install
 that addon.

 > Yes sorry, i didnt give much info on issues. It actually did both,
 sometimes it would disappear completely, other times the icon was in the
 addons folder but wouldnt open.

 Then that's not an issue, if you want the icon to be permanently at your
 disposable open the menu then click on "Customize" at the very bottom,
 then find where the HTTPS Everywhere icon is located and then place it
 where you want it to be permanently.

 > Im aldo having a problem with insecure connection on certain sites,
 nothing i do corrects it. It would be greatly appreciated if i could get
 some advice for that.

 What's the exact problem? Also which sites if 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] #23582 [Applications/Tor Browser]: Increased crash rate due to disabled Windows DLL blocklist

[Tor Bug Tracker & Wiki]

#23582: Increased crash rate due to disabled Windows DLL blocklist
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201709,|  Actual Points:
  GeorgKoppen201709, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 What about https://bugzilla.mozilla.org/show_bug.cgi?id=1344921?

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

Re: [tor-bugs] #23651 [Applications/Tor Browser]: ADDONS

[Tor Bug Tracker & Wiki]

#23651: ADDONS
--+---
 Reporter:  dmeek94@… |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by dmeek94@…):

 I did do a reinstall but i didnt remove any data folders. It was the addon
 that come with the browser, https everywhere, i didnt have much of an
 issue with no script. I have been trying to add others though eg self
 destructing cookies, which installs but wont open.

 Yes sorry, i didnt give much info on issues. It actually did both,
 sometimes it would disappear completely, other times the icon was in the
 addons folder but wouldnt open.
 Im aldo having a problem with insecure connection on certain sites,
 nothing i do corrects it. It would be greatly appreciated if i could get
 some advice for that.

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * Attachment "fetching_descs.log.gz" added.


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

Re: [tor-bugs] #23228 [Applications/Tor Browser]: Build a Windows 64 toolchain based on mingw-w64

[Tor Bug Tracker & Wiki]

#23228: Build a Windows 64 toolchain based on mingw-w64
---+---
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #20636 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [comment:20 gk]:
 > Replying to [comment:19 cypherpunks]:
 > > We could fix ld, if you wish.
 >
 > Yes, I wish but aren't we doing that? If not, how would a fix look like?
 That patches are hacks and are not upstreamable. The fix would change the
 behavior of ld back to normal and would fulfill the requirements of
 https://sourceware.org/bugzilla/show_bug.cgi?id=19011.

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:12 dgoulet]:
 > After discussing this with armadev on IRC, a possible avenue to try to
 fix this is investigate why it can take us up to 10 minutes to get up to
 min dirinfo?
 >

 I started this investigation to see how fast we will receive mds when we
 ask for them. The results are very good! When we fetch mds, we always
 receive them super-fast (within seconds). I attach an email from my laptop
 HS client which demonstrates this.

 Snippet:
 {{{
 Sep 26 01:25:56.000 [info] launch_descriptor_downloads(): Launching 3
 requests for 994 microdescs, 332 at a time
 Sep 26 01:25:57.000 [info] handle_response_fetch_microdesc(): Received
 answer to microdescriptor request (status 200, body size 156215) from
 server '137.205.124.35:1720'
 Sep 26 01:25:57.000 [info] handle_response_fetch_microdesc(): Received
 answer to microdescriptor request (status 200, body size 174579) from
 server '213.136.81.89:9001'
 Sep 26 01:25:57.000 [info] handle_response_fetch_microdesc(): Received
 answer to microdescriptor request (status 200, body size 155635) from
 server '213.136.81.89:9001'
 Sep 26 07:17:57.000 [info] launch_descriptor_downloads(): Launching 3
 requests for 179 microdescs, 60 at a time
 Sep 26 07:17:57.000 [info] handle_response_fetch_microdesc(): Received
 answer to microdescriptor request (status 200, body size 25721) from
 server '188.165.220.21:9001'
 Sep 26 07:17:57.000 [info] handle_response_fetch_microdesc(): Received
 answer to microdescriptor request (status 200, body size 25758) from
 server '188.165.220.21:9001'
 Sep 26 07:17:57.000 [info] handle_response_fetch_microdesc(): Received
 answer to microdescriptor request (status 200, body size 29796) from
 server '188.165.220.21:9001'
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23656 [Applications/Tor Browser]: Use .mozconfig files in tor-browser repo for rbm builds

[Tor Bug Tracker & Wiki]

#23656: Use .mozconfig files in tor-browser repo for rbm builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Right now, if we need to change .mozconfig files, we need to change them
 both in the tor-browser repository and in tor-browser-build (see the
 respective note in `README.HACKING`).

 We should find a way to leave the .mozconfig files in the tor-browser
 repository for local builds outside of `rbm` (and only change them there
 when writing tor-browser patches) but use them nevertheless for
 `rbm`-based builds (probably with some modifications if needed).

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