Re: [tor-bugs] #22910 [Applications/Tor Browser Sandbox]: Deprecate the volatile extension dir options

[Tor Bug Tracker & Wiki]

#22910: Deprecate the volatile extension dir options
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


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

Re: [tor-bugs] #22910 [Applications/Tor Browser Sandbox]: Deprecate the volatile extension dir options (was: Deprecate the extra codecs/volatile extension dir options)

[Tor Bug Tracker & Wiki]

#22910: Deprecate the volatile extension dir options
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Old description:

> Having massive "foot + gun" options in general is bad practice.
>
> The extra codecs will expose ffmpeg to the browser container, which is a
> concrete increase in attack surface for questionable gain (gstreamer is
> never allowed).
>
> The volatile extension dir gives firefox more write access than what
> anyone that's vaguely security conscious should be comfortable with, to
> critical browser components, and there's the ongoing `about:addons`
> fisasco.

New description:

 Having massive "foot + gun" options in general is bad practice.

 ~~~The extra codecs will expose ffmpeg to the browser container, which is
 a concrete increase in attack surface for questionable gain (gstreamer is
 never allowed).~~~

 The volatile extension dir gives firefox more write access than what
 anyone that's vaguely security conscious should be comfortable with, to
 critical browser components, and there's the ongoing `about:addons`
 fisasco.

--

Comment (by yawning):

 The extra codec deprecation is now #22933, and this ticket is fixed in
 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

[tor-bugs] #22933 [Applications/Tor Browser Sandbox]: Deprecate the extra codecs option.

[Tor Bug Tracker & Wiki]

#22933: Deprecate the extra codecs option.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Split the codec option off from #22910 since they technically are two
 separate things.  Relevant details from the original ticket are as
 follows:

 Having massive "foot + gun" options in general is bad practice.

 The extra codecs will expose ffmpeg to the browser container, which is a
 concrete increase in attack surface for questionable gain (gstreamer is
 never allowed).

 It looks like the browser people sort of considered the ffmpeg situation
 at #18946, and I initially added the pref in #20806.  Really what should
 happen is that Tor Browser should bundle their own copy if it's that
 critical to functionality instead of pulling in one of 7 different .so
 files via dlopen (`dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp`).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22932 [Applications/Tor Browser Sandbox]: Support a non-volatile profile directory.

[Tor Bug Tracker & Wiki]

#22932: Support a non-volatile profile directory.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Basic idea is to copy the profile directory into a new tmpfs mount inside
 the container on each launch so that even if firefox writes evil to it,
 said evil will be non-persistent.

 The drawback is that this applies to bookmarks and preferences, so it
 can't be the default behavior, but as an "improve security" option, it's
 easy to do.

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

Re: [tor-bugs] #22874 [Obfuscation/Snowflake]: Standalone broker (independent of App Engine)

[Tor Bug Tracker & Wiki]

#22874: Standalone broker (independent of App Engine)
---+--
 Reporter:  dcf|  Owner:  cmm32
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  arlolra serene cmm32   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * keywords:   => arlolra serene cmm32


Comment:

 I added automatic Let's Encrypt code here:
   https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=standalone-
 broker=afe771690364e14586f24d98b65f0a2172cac1cc

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

Re: [tor-bugs] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by Vort):

 I have made a test with Windows 8.1 (6.3.9600) and WANem 40Mbit/150ms.
 And maximum speeds for `BwTest -s -u` and `BwTest -s -u -t` appeared to be
 the same: 4475 KiB/s.

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

[tor-bugs] #22931 [Core Tor/Tor]: What happens when a VERSIONS cell is sent outside a handshake?

[Tor Bug Tracker & Wiki]

#22931: What happens when a VERSIONS cell is sent outside a handshake?
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  doc tor-spec
Actual Points:|  Parent ID:  #18856
   Points:|   Reviewer:
  Sponsor:|
--+--
 The spec really doesn't say:

 {{{
To determine the version, in any connection where the "renegotiation"
or "in-protocol" handshake was used (that is, where the responder
sent only one certificate at first and where the initiator did not
send any certificates in the first negotiation), both parties MUST
send a VERSIONS cell.  In "renegotiation", they send a VERSIONS cell
right after the renegotiation is finished, before any other cells are
sent.  In "in-protocol", the initiator sends a VERSIONS cell
immediately after the initial TLS handshake, and the responder
replies immediately with a VERSIONS cell.  Parties MUST NOT send any
other cells on a connection until they have received a VERSIONS cell.

The payload in a VERSIONS cell is a series of big-endian two-byte
integers.  Both parties MUST select as the link protocol version the
highest number contained both in the VERSIONS cell they sent and in the
versions cell they received.  If they have no such version in common,
they cannot communicate and MUST close the connection.  Either party
 MUST
close the connection if the versions cell is not well-formed (for
 example,
if it contains an odd number of bytes).
 }}}

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

Re: [tor-bugs] #22110 [Core Tor/Tor]: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec

[Tor Bug Tracker & Wiki]

#22110: Defining TOR_BUILD_TAG and tor_git_revision violates the version spec
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  easy, tor-spec  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * keywords:  easy => easy, tor-spec


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22929, #22918, #22882

[Tor Bug Tracker & Wiki]

Batch modification to #22929, #22918, #22882 by teor:
parent to #18856

Comment:
Re-parent spec issues found during to the stem ORPort task to that task

--
Tickets URL: 

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

Re: [tor-bugs] #22930 [Internal Services/Service - trac]: Give teor batch modify

[Tor Bug Tracker & Wiki]

#22930: Give teor batch modify
--+
 Reporter:  teor  |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
  |  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Turns out what I really needed here was to turn on JavaScript. My existing
 permissions include batch modify.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #5799, #6059, #7257, #8165, ...

[Tor Bug Tracker & Wiki]

Batch modification to #5799, #6059, #7257, #8165, #13042, #14973, #18607, 
#18851, #20014, #20060, #20086, #20094, #20577, #21109, #22742, #18744, #21193, 
#21744, #8537 by teor:
keywords to torspec

Comment:
Consistently use tor-spec across all tickets (remove torspec).

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #5799, #6059, #7257, #8165, ...

[Tor Bug Tracker & Wiki]

Batch modification to #5799, #6059, #7257, #8165, #13042, #14973, #18607, 
#18851, #20014, #20060, #20086, #20094, #20577, #21109, #22742, #18744, #21193, 
#21744, #8537 by teor:
keywords to tor-spec

Comment:
Consistently use tor-spec across all tickets (add tor-spec).

--
Tickets URL: 

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

Re: [tor-bugs] #8537 [Core Tor/Tor]: Fix sentence in gettor-spec.txt

[Tor Bug Tracker & Wiki]

#8537: Fix sentence in gettor-spec.txt
--+---
 Reporter:  rodolfoferraz |  Owner:  rodolfoferraz
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  torspec tor-spec gettor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * component:  - Select a component => Core Tor/Tor
 * severity:   => Normal


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

Re: [tor-bugs] #22930 [Internal Services/Service - trac]: Give teor batch modify

[Tor Bug Tracker & Wiki]

#22930: Give teor batch modify
--+
 Reporter:  teor  |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
  |  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22930 [Internal Services/Service - trac]: Give teor batch modify

[Tor Bug Tracker & Wiki]

#22930: Give teor batch modify
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 For the record, I just gave myself batch modify permission.

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

Re: [tor-bugs] #18856 [Core Tor/Stem]: Talk with tor's ORPort

[Tor Bug Tracker & Wiki]

#18856: Talk with tor's ORPort
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:12 atagar]:
 > Thanks Tim! Sorry, bit naive - are version cells for getting the tor
 version?

 Versions cells contain the link version, which doesn't change very often,
 and is mostly hidden from users:
 https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n503

 > Is there anything end users may want to take advantage of that I should
 start integrating?

 Not at this point, as far as I can tell: the interesting stuff happens
 once I write the circuit encryption code and can exchange data with a
 remote relay. Until then it's just boring byte packing and spec queries.

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

Re: [tor-bugs] #18856 [Core Tor/Stem]: Talk with tor's ORPort

[Tor Bug Tracker & Wiki]

#18856: Talk with tor's ORPort
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Thanks Tim! Sorry, bit naive - are version cells for getting the tor
 version? Is there anything end users may want to take advantage of that I
 should start integrating?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22929 [Core Tor/Tor]: What cells can be sent before a VERSIONS cell, and what is their CIRCID_LEN?

[Tor Bug Tracker & Wiki]

#22929: What cells can be sent before a VERSIONS cell, and what is their
CIRCID_LEN?
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 tor-spec.txt says:
 {{{
CIRCID_LEN is 2 for link protocol versions 1, 2, and 3.  CIRCID_LEN
is 4 for link protocol version 4 or higher.  The VERSIONS cell itself
always has CIRCID_LEN == 2 for backward compatibility.
 }}}

 But what is the CIRCID_LEN for early VPADDING, AUTHORIZE, or PADDING
 cells?

 {{{
When this handshake is in use, the first cell must
be VERSIONS, VPADDING or AUTHORIZE, and no other cell type is allowed
 to
intervene besides those specified, except for PADDING and VPADDING
 cells.
 }}}

 Is it valid to send VPADDING, then PADDING, then VERSIONS?
 If so, what is their CIRCID_LEN?
 Which sentence prevails, the one above, or the one below?

 {{{
Parties MUST NOT send any
other cells on a connection until they have received a VERSIONS cell.
 }}}

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

Re: [tor-bugs] #22874 [Obfuscation/Snowflake]: Standalone broker (independent of App Engine)

[Tor Bug Tracker & Wiki]

#22874: Standalone broker (independent of App Engine)
---+--
 Reporter:  dcf|  Owner:  cmm32
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Hooman has been working on this and I pushed their changes to a
 standalone-broker branch:
   https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=standalone-
 broker=3f4f5d2292416dc7aeb6d091c174e20d779fe947

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

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

[Tor Bug Tracker & Wiki]

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+-
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by dcf):

 * cc: cmm32 (added)
 * priority:  Medium => High


Comment:

 Replying to [ticket:18628 arlolra]:
 > In order to report true client IP addresses, we will need to devise some
 way for the browser proxy to forward that metadata to the bridge before
 the OR data.

 I realized a good way to do this: put the client IP address in the
 WebSocket URL. Currently we have
 {{{
 new WebSocket("wss://snowflake.bamsoftware.com/")
 }}}
 We could just change that to (imagine proper escaping):
 {{{
 new WebSocket("wss://snowflake.bamsoftware.com/?client_ip=" + client_ip)
 }}}
 The WebSocket server can extract the IP address by inspecting the URL it
 gets in the request, and provide that IP address to the pt.DialOr
 function.

 The alternative of sending the client IP address in an HTTP header
 [[#13171|à la meek]] won't work, because the
 [https://developer.mozilla.org/en-US/docs/Web/API/WebSocket WebSocket API]
 doesn't provide a way to set headers. The only information you can provide
 to the constructor is a URL and an optional list of sub-protocol names.

 Unfortunately the WebSocket implementation used by snowflake-server (the
 one inherited from flash proxy) doesn't expose the URL of the client
 request (and in fact [https://gitweb.torproject.org/pluggable-
 
transports/websocket.git/tree/websocket/websocket.go?id=6dc990ad6a898bc507605c51a5aa860fb9f74201#n336
 requires the path to be `/`]). But that shouldn't be hard to change.

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

Re: [tor-bugs] #15967 [Obfuscation/BridgeDB]: Separate BridgeDB's CAPTCHA into another service

[Tor Bug Tracker & Wiki]

#15967: Separate BridgeDB's CAPTCHA into another service
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-https captcha tor-launcher  |  Actual Points:  2
  ooni-probe |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorM
-+-
Changes (by isis):

 * status:  new => needs_review
 * points:   => 2
 * sponsor:   => SponsorM
 * actualpoints:   => 2


Comment:

 I made a CAPTCHA server here: https://github.com/isislovecruft/farfetchd

 It has a JSON API:

 1) `GET /fetch` will return JSON in the form:
{{{
{
  'image': null or base64-encoded jpeg image,
  'challenge': null or url-safe base64-encoded challenge string,
  'error': null or ascii-encoded string describing the error,
}
}}}

 2) `POST /check?data=[…]` where the `data` url parameter is a JSON string
 in the following form:
{{{
{
  'challenge': base64-encoded challenge string (from the above
 response),
  'response': base64-encoded response (i.e. the CAPTCHA solution),
}
}}}
 The farfetched server will attempt to verify the challenge response, and
 replies with JSON in the following form:
{{{
{
  'result': bool,
  'error': null or base64-encoded string describing the error,
}
}}}

 Please let me know if this API seems like it'll work on the Tor Browser
 side, or if there's any way I could make it easier to process the data
 and/or hand it back and forth.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22137, #13398, #15473, #16678, ...

[Tor Bug Tracker & Wiki]

Batch modification to #22137, #13398, #15473, #16678, #19479, #21830 by 
arthuredelstein:
cc to arthuredelstein

--
Tickets URL: 

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+---
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pospeselr):

 * owner:  tbb-team => pospeselr
 * status:  new => accepted


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

Re: [tor-bugs] #22563 [Applications/Tor Browser]: Many memory pages in tor.exe for Windows violate W^X

[Tor Bug Tracker & Wiki]

#22563: Many memory pages in tor.exe for Windows violate W^X
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  windows tor-client win32 tor-relay   |  Actual Points:
  security hardening 031-backport,   |
  TorBrowserTeam201707   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:10 arthuredelstein]:
 > My dear cypherpunk, maybe you would like to start that debate on the
 mingw-w64 discussion page? :)
 That debate has a very long history (see, e.g.
 https://sourceforge.net/p/mingw-w64/discussion/723797/thread/9e2995ab/).
 Don't you want to say some words to push the discussion forward? :)

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

Re: [tor-bugs] #22928 [Applications/Tor Browser]: Problems launching browser

[Tor Bug Tracker & Wiki]

#22928: Problems launching browser
--+---
 Reporter:  darth_erp |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate of #8337

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

Re: [tor-bugs] #22902 [Core Tor/Stem]: run_tests.py hangs in process or control.controller

[Tor Bug Tracker & Wiki]

#22902: run_tests.py hangs in process or control.controller
---+---
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by atagar):

 Interesting. Thanks catalyst, pushed a tweak. Mind giving this a try?

 https://gitweb.torproject.org/stem.git/commit/?id=d378100

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22928 [Applications/Tor Browser]: Problems launching browser

[Tor Bug Tracker & Wiki]

#22928: Problems launching browser
--+--
 Reporter:  darth_erp |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I click on the Start Tor Browser icon, a User Account box appears
 which asks, 'Do I want the following program to make changes to my
 computer?'
 I click Yes and the following comes up,
 'Tor Browser has stopped working'

 Problem Details:

 Problem signature:
   Problem Event Name:   APPCRASH
   Application Name: firefox.exe
   Application Version:  52.2.0.6242
   Application Timestamp:
   Fault Module Name:KERNELBASE.dll
   Fault Module Version: 6.1.7601.23807
   Fault Module Timestamp:   5915f98e
   Exception Code:   c06d007f
   Exception Offset: c54f
   OS Version:   6.1.7601.2.1.0.768.3
   Locale ID:2057
   Additional Information 1: 0a9e
   Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
   Additional Information 3: 0a9e
   Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

 Tor previously ran on my PC but no longer launches. I use the Commodo
 AntiVirus.

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail with libzstd 1.3.0

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail with libzstd 1.3.0
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:  1
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * actualpoints:   => 1


Comment:

 See branch `bug22927_031` in my public repository.  It seems to fix the
 issue for me.

 Ahf, if you have a chance, could you look over this code?

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail with libzstd 1.3.0 (was: zstd tests fail on master)

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail with libzstd 1.3.0
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 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] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I think I have it figured out -- the problem is that we have an
 intervening call to zstd_compressstream.

 I'm attaching a program that succeeds under zstd 1.2.0, but fails under
 zstd 1.3.0.

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 The latest docs have the following extra lines:
 {{{
   @return : 0 if frame fully completed and fully flushed,
  or >0 if some data is still present within internal buffer
   (value is minimum size estimation for remaining data to
 flush, but it could be more)
 or an error code, which can be tested using ZSTD_isError().

 typedef ZSTD_CCtx ZSTD_CStream;  /**< CCtx and CStream are now effectively
 same object (>= v1.3.0) */
 }}}
 https://facebook.github.io/zstd/zstd_manual.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] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 (The documentation implies that this should work, though:
 {{{
 *  ZSTD_endStream() instructs to finish a frame.
 *  It will perform a flush and write frame epilogue.
 *  The epilogue is required for decoders to consider a frame completed.
 *  Similar to ZSTD_flushStream(), it may not be able to flush the full
 content i
 f `output->size` is too small.
 *  In which case, call again ZSTD_endStream() to complete the flush.
 *  @return : nb of bytes still present within internal buffer (0 if it's
 empty,
 hence compression completed)
 *or an error code, which can be tested using ZSTD_isError().
 }}}

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Based on some examination, here is what I think is happening: we are done
 compressing our input, so we call ZSTD_endStream to write the epilogue...
 but the output buffer is full, so we have to grow the output buffer and
 try again... so we try ZSTD_endStream again, but it doesn't work for some
 reason.

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

Re: [tor-bugs] #18856 [Core Tor/Stem]: Talk with tor's ORPort

[Tor Bug Tracker & Wiki]

#18856: Talk with tor's ORPort
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:10 teor]:
 > Here's what I must implement to do this:
 > * implement VERSIONS

 I have implemented SSL and the VERSIONS cell in python.

 You can follow along on github if you'd like:

 https://github.com/teor2345/endosome

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:1 nickm]:
 > Can reproduce.
 >
 > I wonder if this has anything to do with zstd 1.3.0, which just came out
 a few days ago?

 I only saw them after I upgraded.

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: ahf (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] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 When I run those tests with the --info option I see a bunch of "Zstandard
 compression unable to write epilogue: Context should be init 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] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * priority:  Medium => High


Comment:

 Can reproduce.

 I wonder if this has anything to do with zstd 1.3.0, which just came out a
 few days ago?

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

Re: [tor-bugs] #17750 [Core Tor/Tor]: Make bootstrapping clients wait before trying an authority

[Tor Bug Tracker & Wiki]

#17750: Make bootstrapping clients wait before trying an authority
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bootstrap, 031-backport, |  Actual Points:  0.3
  030-backport, 029-backport |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I have added another fix to the `bug17750_029_squashed` branch to fix a
 unit test failure, as #22924.  I've re-merged the branch to master.  This
 branch is still cooking in master, with a possibility of an eventual
 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] #22924 [Core Tor/Tor]: signed integer overflow in unit tests crashes hardened build on 32-bit trusty

[Tor Bug Tracker & Wiki]

#22924: signed integer overflow in unit tests crashes hardened build on 32-bit
trusty
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #22924 [Core Tor/Tor]: signed integer overflow in unit tests crashes hardened build on 32-bit trusty

[Tor Bug Tracker & Wiki]

#22924: signed integer overflow in unit tests crashes hardened build on 32-bit
trusty
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I've added it to bug17750_029_squashed, and re-merged that into master.
 I'll make a note on #17750.  Thanks for the 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] #22924 [Core Tor/Tor]: signed integer overflow in unit tests crashes hardened build on 32-bit trusty

[Tor Bug Tracker & Wiki]

#22924: signed integer overflow in unit tests crashes hardened build on 32-bit
trusty
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Okay.  So it seems to me I should cherry-pick this onto the branch for
 17750, in case we decide to backport that any more.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22927 [Core Tor/Tor]: zstd tests fail on master

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail on master
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal|   Keywords:  tor-dir
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 When I run the unit tests on tor master:
 `
 [notice] Tor 0.3.2.0-alpha-dev (git-9a1338d9df938fba) running on Darwin
 with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3,
 and Libzstd 1.3.0.
 `

 I see the following failures:
 {{{
 buffer/compress/zstd: [forking]
   FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf,
 compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
   FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf,
 compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
   FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf,
 compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
   FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf,
 compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
   [compress/zstd FAILED]
 ...
 util/compress_concat/zstd:
   FAIL src/test/test_util.c:2414: assert(r OP_EQ 0): -1 vs 0
   [compress_concat/zstd FAILED]
 }}}

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

Re: [tor-bugs] #22924 [Core Tor/Tor]: signed integer overflow in unit tests crashes hardened build on 32-bit trusty

[Tor Bug Tracker & Wiki]

#22924: signed integer overflow in unit tests crashes hardened build on 32-bit
trusty
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_revision
 * version:   => Tor: 0.2.9.1-alpha


Comment:

 Replying to [comment:1 nickm]:
 > See my branch `bug22924` against master.  I haven't figured out when
 this bug was first introduced, though.

 It's been there since test_dir_download_status_random_backoff() was
 introduced in commit 1553512 in tor-0.2.9.1-alpha, but we didn't find it
 until #17750, because the pre-#17750 unit tests used limited ranges.

 I tested the patch on i386 and x86_64 macOS, and it passes on both.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 The new Tor compression code in 0.3.1 assumes that all the compression
 functions are bound at runtime.

 For example, tor_lzma_method_supported() returns 1 when HAVE_LZMA is
 defined, but that doesn't mean that lzma_version_string() has actually
 been bound to a non-NULL address in the binary.

 This is more likely to happens when tor is used as a shared library rather
 than linked as an executable (shadow, iOS), and when using weak, lazy
 symbol binding.

 This might not be an issue we can solve unless we check for all the
 symbols being NULL at runtime. Maybe the responsibility for proper linking
 is on people who are compiling tor with weak, lazy symbol binding.

 This bug was discovered by Rob Jansen when running shadow.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Also, if possible the assistance URL should be a direct link (it isn't at
 least on macOS, it's just text).

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

Re: [tor-bugs] #22910 [Applications/Tor Browser Sandbox]: Deprecate the extra codecs/volatile extension dir options

[Tor Bug Tracker & Wiki]

#22910: Deprecate the extra codecs/volatile extension dir options
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 It looks like the browser people sort of considered the ffmpeg situation
 at #18946, and I initially added the pref in #20806.

 The list of shared objects that FF will pull appears to be hardcoded in
 `dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp`.  When I initially
 wrote this, it was also pulling in libgstreamer (which has explicitly
 always been rejected via the fine grained shared object code), but maybe
 that's gone now.

 {{{
 "libavcodec-ffmpeg.so.57",
 "libavcodec-ffmpeg.so.56",
 "libavcodec.so.57",
 "libavcodec.so.56",
 "libavcodec.so.55",
 "libavcodec.so.54",
 "libavcodec.so.53",

 // "libgstreamer-0.10.so.0",
 // "libgstapp-0.10.so.0",
 // "libgstvideo-0.10.so.0",
 }}}

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

[tor-bugs] #22925 [Applications/Tor Browser Sandbox]: Make the extension whitelist public key cryptography based.

[Tor Bug Tracker & Wiki]

#22925: Make the extension whitelist public key cryptography based.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 If/when the Tor Browser people decide to do the sensible thing and start
 signing all of the XPIs bundled with Tor Browser, the extension whitelist
 can be made more resilient to Tor Browser changes by validating XPI
 signatures with it's own copies of the public key.

 Till then it will be somewhat fragile, though new extensions don't get
 added very often, so it's "merely" a matter of keeping in sync with the
 browser.

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

Re: [tor-bugs] #22924 [Core Tor/Tor]: signed integer overflow in unit tests crashes hardened build on 32-bit trusty

[Tor Bug Tracker & Wiki]

#22924: signed integer overflow in unit tests crashes hardened build on 32-bit
trusty
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 See my branch `bug22924` against master.  I haven't figured out when this
 bug was first introduced, 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

[tor-bugs] #22924 [Core Tor/Tor]: signed integer overflow in unit tests crashes hardened build on 32-bit trusty

[Tor Bug Tracker & Wiki]

#22924: signed integer overflow in unit tests crashes hardened build on 32-bit
trusty
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 If I build on gcc with --enable-fragile-hardening on ubuntu trusty, I get
 a crash in dir/download_status_random_backoff :

 {{{
 #0  0xf7fd9d70 in __kernel_vsyscall ()
 #1  0xf6599827 in raise () from /lib/i386-linux-gnu/libc.so.6
 #2  0xf659cc53 in abort () from /lib/i386-linux-gnu/libc.so.6
 #3  0x56e5e16c in __addvsi3 ()
 #4  0x5679e366 in download_status_random_backoff_helper (
 min_delay=min_delay@entry=0, max_delay=max_delay@entry=2147483647)
 at src/test/test_dir.c:4167
 #5  0x5679e699 in test_dir_download_status_random_backoff (arg=0x0)
 at src/test/test_dir.c:4196
 #6  0x56a519dc in testcase_run_bare_ (
 testcase=testcase@entry=0x5724e0c0 )
 at src/ext/tinytest.c:106
 #7  0x56a51de1 in testcase_run_one (group=,
 group@entry=0x572346b0 , testcase=,
 testcase@entry=0x5724e0c0 ) at src/ext/tinytest.c:253
 #8  0x56a532c4 in tinytest_main (c=2, v=0xd764,
 groups=0x572345e0 ) at src/ext/tinytest.c:435
 #9  0x5661eede in main (c=2, v=)
 at src/test/testing_common.c:319

 }}}

 I think this has something to do with our fixes for #17750 or #20534, but
 I'm not certain.

 I have a patch that fixes this issue for me.

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

Re: [tor-bugs] #22910 [Applications/Tor Browser Sandbox]: Deprecate the extra codecs/volatile extension dir options

[Tor Bug Tracker & Wiki]

#22910: Deprecate the extra codecs/volatile extension dir options
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

 * status:  new => accepted


Comment:

 Volatile Extensions Dir: https://gitweb.torproject.org/tor-browser
 /sandboxed-tor-
 browser.git/commit/?id=701c0656be16440203147eb0ea6104486bb77096

 I still need to think about ffmpeg, but really what should happen is that
 Tor Browser should bundle their own copy if it's that critical to
 functionality instead of pulling in one of 7 different `.so` files via
 dlopen.

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

Re: [tor-bugs] #22902 [Core Tor/Stem]: run_tests.py hangs in process or control.controller

[Tor Bug Tracker & Wiki]

#22902: run_tests.py hangs in process or control.controller
---+---
 Reporter:  catalyst   |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by catalyst):

 Thanks.  I think I haven't seen a deadlock since updating to that.

 Here's one failure (after I had been running `run_tests.py` in a loop for
 a while:

 {{{
 ==
 test.integ.process.TestProcess
 ==

 test_can_run_multithreaded 0 ms  [SUCCESS]
 test_dump_config_argument  0 ms  [SUCCESS]
 test_hash_password 0 ms  [SUCCESS]
 test_hash_password_requires_argument   0 ms  [SUCCESS]
 test_help_argument 0 ms  [SUCCESS]
 test_hush_argument 0 ms  [SUCCESS]
 test_launch_tor_with_config_via_file   0 ms  [SUCCESS]
 test_launch_tor_with_config_via_stdin  0 ms  [SUCCESS]
 test_launch_tor_with_timeout   0 ms  [SUCCESS]
 test_list_fingerprint_argument 0 ms  [SUCCESS]
 test_list_torrc_options_argument   0 ms  [SUCCESS]
 test_no_orphaned_process   0 ms  [SUCCESS]
 test_quiet_argument0 ms  [SUCCESS]
 test_take_ownership_via_controller   [FAILURE]
 test_take_ownership_via_pid0 ms  [SUCCESS]
 test_torrc_arguments   0 ms  [SUCCESS]
 test_torrc_arguments_via_stdin 0 ms  [SUCCESS]
 test_unanonymous_hidden_service_config_must_match  0 ms  [SUCCESS]
 test_validate_config_argument  0 ms  [SUCCESS]
 test_version_argument  0 ms  [SUCCESS]
 test_with_invalid_config   0 ms  [SUCCESS]
 test_with_missing_torrc0 ms  [SUCCESS]

 ==
 FAIL: test_take_ownership_via_controller
 --
 Traceback (most recent call last):
   File "/home/tlyu/src/stem/stem/util/test_tools.py", line 150, in
 
 self.method = lambda test: self.result(test)  # method that can be
 mixed into TestCases
   File "/home/tlyu/src/stem/stem/util/test_tools.py", line 214, in result
 test.fail(self._result.msg)
 AssertionError: Traceback (most recent call last):
   File "/home/tlyu/src/stem/stem/util/test_tools.py", line 165, in
 _wrapper
 runner(*args) if args else runner()
   File "/home/tlyu/src/stem/test/integ/process.py", line 625, in
 test_take_ownership_via_controller
 take_ownership = True,
   File "/home/tlyu/src/stem/stem/process.py", line 274, in
 launch_tor_with_config
 return launch_tor(tor_cmd, ['-f', '-'], None, completion_percent,
 init_msg_handler, timeout, take_ownership, stdin = config_str)
   File "/home/tlyu/src/stem/stem/process.py", line 153, in launch_tor
 raise OSError('Process terminated: %s' % last_problem)
 OSError: Process terminated: Failed to bind one of the listener ports.


 --
 Ran 22 tests in 0.001s

 FAILED (failures=1)


 Shutting down tor... done

 Style checks require pycodestyle version 1.4.2 or later. Please install it
 from...
   http://pypi.python.org/pypi/pycodestyle

 TESTING FAILED (35 seconds)
   [RUN_NONE] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL
   [RUN_OPEN] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL
   [RUN_PASSWORD] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL
   [RUN_COOKIE] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL
   [RUN_MULTIPLE] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL
   [RUN_SOCKET] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL
   [RUN_SCOOKIE] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL
   [RUN_PTRACE] test_take_ownership_via_controller
 (test.integ.process.TestProcess) ... FAIL

 You can re-run just these tests with:

   ./run_tests.py --tor ../tor/src/or/tor --all --log notice --target
 RUN_ALL -v --test test.integ.process
 }}}

 and another one:

 {{{

Re: [tor-bugs] #22920 [Webpages/Website]: Change OS names at the TBB donwload page

[Tor Bug Tracker & Wiki]

#22920: Change OS names at the TBB donwload page
--+
 Reporter:  i139  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


Comment:

 Ok. Done and deployed.

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

Re: [tor-bugs] #22921 [Core Tor/Tor]: Tor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 of our path. Discarding this circuit.

[Tor Bug Tracker & Wiki]

#22921: Tor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 
of
our path. Discarding this circuit.
--+--
 Reporter:  neel  |  Owner:
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pastly):

 * component:  Core Tor => Core Tor/Tor


Comment:

 > Jul 13 21:31:40.000 [warn] Received directory with skewed time
 (DIRSERV:171.25.193.9:443): It seems that our clock is ahead by 5 hours, 1
 minutes, or that theirs is behind. Tor requires an accurate clock to work:
 please check your time, timezone, and date settings.

 Did you look into this? What did you learn?

 It looks like you got lucky after starting Tor again and were able to get
 farther into the bootstrap process. Perhaps at this point having a clock
 that is more correct than +5h is very important. Extra logging (for
 example: debug or info level instead of just notice) might have revealed
 the issue better.

 But first: I'm guessing you're in UTC-5 and have set the time to UTC but
 the timezone is still central time.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22923 [Internal Services/Tor Sysadmin Team]: Create a Virtual Machine for Tor Browser Crash Dumps

[Tor Bug Tracker & Wiki]

#22923: Create a Virtual Machine for Tor Browser Crash Dumps
-+-
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 As the initial experiment for the Crash Reporter GSOC, we intend to run
 (at least) two instances of https://github.com/electron/mini-breakpad-
 server

  - One instance will be a modified version that only ACCEPTS submissions.
  - One instance will be a modified version that only lets you VIEW
 submissions.

 We'll run both on .onions, but the latter will be set up with Hidden
 Service authentication.

 We may want to run two more (to segregate Alpha from Release) but I don't
 think we'll need to.


 As far as packages needed on the machine: it's TBD. 'npm' and 'grunt' look
 like certainties though.

 And as far as resources: I don't think we'll need much except a healthy
 amount of disk space. This is an in-progress project so hopefully we can
 grow this space and capacity if needed.

 Submission will be over .onion so direct external internet access it not
 necessary.

 I don't think we need our own VM if it's easy to have us share, but please
 assume that several members of the Tor Browser machine will need access to
 login and fiddle with the server/machine.

 For now, please set it up with me having access, but down the road we'll
 probably revoke my access and move it over to GeKo.

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

Re: [tor-bugs] #22912 [Metrics/metrics-lib]: tpf parsing drops trailing newline

[Tor Bug Tracker & Wiki]

#22912: tpf parsing drops trailing newline
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  accepted
 Priority:  High |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  needs_review => accepted
 * owner:  metrics-team => iwakeh


Comment:

 Replying to [comment:6 karsten]:
 > I think it's okay to assume that all descriptors should end in newline.
 Would you want to add a parameterized test?

 Yup, I can do that.
 Setting to accepted.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22922 [Internal Services/Tor Sysadmin Team]: pipeline.torproject.net subdomain for 199.119.112.90

[Tor Bug Tracker & Wiki]

#22922: pipeline.torproject.net subdomain for 199.119.112.90
-+-
 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:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hi,

 I am setting up a webform for people to submit grant proposals. Could I
 get the subdomain pipeline.torproject.net to point to:

 {{{
 199.119.112.90


 }}}

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

Re: [tor-bugs] #21321 [Applications/Tor Browser]: .onion HTTP is shown as non-secure in Tor Browser

[Tor Bug Tracker & Wiki]

#21321: .onion HTTP is shown as non-secure in Tor Browser
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  ff52-esr, tbb-7.0-issues, tbb-   |  Actual Points:
  usability, ux-team, TorBrowserTeam201707,  |
  GeorgKoppen201707  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff52-esr, tbb-usability, ux-team, TorBrowserTeam201707 =>
 ff52-esr, tbb-7.0-issues, tbb-usability, ux-team,
 TorBrowserTeam201707, GeorgKoppen201707


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

Re: [tor-bugs] #22909 [Core Tor/Tor]: Our Rust code is always built in debug mode

[Tor Bug Tracker & Wiki]

#22909: Our Rust code is always built in debug mode
-+-
 Reporter:  isis |  Owner:
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, tor-build  |  Actual Points:
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:  SponsorZ
-+-

Comment (by chelseakomlo):

 On http://doc.crates.io/guide.html:

 "Compiling in debug mode is the default for development-- compilation time
 is shorter since the compiler doesn't do optimizations, but the code will
 run slower. Release mode takes longer to compile, but the code will run
 faster."

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

Re: [tor-bugs] #22912 [Metrics/metrics-lib]: tpf parsing drops trailing newline

[Tor Bug Tracker & Wiki]

#22912: tpf parsing drops trailing newline
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 I think it's okay to assume that all descriptors should end in newline.
 Would you want to add a parameterized test?

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

Re: [tor-bugs] #22920 [Webpages/Website]: Change OS names at the TBB donwload page

[Tor Bug Tracker & Wiki]

#22920: Change OS names at the TBB donwload page
--+--
 Reporter:  i139  |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:   => hiro
 * status:  new => assigned
 * component:  - Select a component => Webpages/Website


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

Re: [tor-bugs] #22919 [Applications/Tor Browser]: Form tracking and OS fingerprinting (only Windows, but without Javascript)

[Tor Bug Tracker & Wiki]

#22919: Form tracking and OS fingerprinting (only Windows, but without 
Javascript)
--+--
 Reporter:  basvd |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * priority:  Medium => High
 * keywords:   => tbb-fingerprinting


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22921 [Core Tor]: Tor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 of our path. Discarding this circuit.

[Tor Bug Tracker & Wiki]

#22921: Tor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 
of
our path. Discarding this circuit.
---+--
 Reporter:  neel   |  Owner:
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor   |Version:  Tor: 0.3.0.9
 Severity:  Critical   |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 When I run Tor on FreeBSD on a dedicated server, I get errors like this:

 Jul 14 13:38:46.000 [warn] Failed to find node for hop 0 of our path.
 Discarding this circuit.

 The versions of Tor affected are 0.3.0.9 and 0.3.1.4-alpha. The 0.2.9.x
 branches and earlier don't have this issue.

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

Re: [tor-bugs] #22870 [Core Tor/Tor]: consdiff test fails on OS X

[Tor Bug Tracker & Wiki]

#22870: consdiff test fails on OS X
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Closing this now; I've tried hunting for more cases with coccinelle, but I
 didn't find any.

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

Re: [tor-bugs] #22900 [Applications/Tor Browser]: Tor Browser loads a script from Google Analytics on the Addon Management page

[Tor Bug Tracker & Wiki]

#22900: Tor Browser loads a script from Google Analytics on the Addon Management
page
--+---
 Reporter:  justJanne |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


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

Re: [tor-bugs] #22916 [Core Tor/Tor]: Clang warnings when building with openssl and scrypt

[Tor Bug Tracker & Wiki]

#22916: Clang warnings when building with openssl and scrypt
-+-
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  027-backport 028-backport|  Actual Points:  .1
  029-backport 030-backport 031-backport |
Parent ID:   | Points:  .1
 Reviewer:  isis |Sponsor:
 |  Sponsor3-can
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.2.9.x-final


Comment:

 Merged to 0.2.9 and forward.

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

Re: [tor-bugs] #22803 [Core Tor/Tor]: Memory leak in link-handshake/certs_ok_ed25519

[Tor Bug Tracker & Wiki]

#22803: Memory leak in link-handshake/certs_ok_ed25519
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  030-backport 031-backport tor-tests  |  Actual Points:  .1
  memory-leak|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Thanks! Merged to 0.3.0 and forward!

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

[tor-bugs] #22920 [- Select a component]: Change OS names at the TBB donwload page

[Tor Bug Tracker & Wiki]

#22920: Change OS names at the TBB donwload page
--+-
 Reporter:  i139  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 At https://www.torproject.org/projects/torbrowser.html.en
 The OS names must be, Microsoft Windows, Apple MacOS and GNU/Linux

 Apple renomed they OS from OS X to MacOS

 and GNU Project have somer arguments about use GNU/Linux instance of just
 Linux, as the Linux is just a kernel.
 http://www.gnu.org/gnu/gnu.en.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] #22900 [Applications/Tor Browser]: Tor Browser loads a script from Google Analytics on the Addon Management page

[Tor Bug Tracker & Wiki]

#22900: Tor Browser loads a script from Google Analytics on the Addon Management
page
--+--
 Reporter:  justJanne |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by i139):

 * cc: i139 (added)
 * status:  closed => reopened
 * resolution:  duplicate =>


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

Re: [tor-bugs] #22900 [Applications/Tor Browser]: Tor Browser loads a script from Google Analytics on the Addon Management page

[Tor Bug Tracker & Wiki]

#22900: Tor Browser loads a script from Google Analytics on the Addon Management
page
--+---
 Reporter:  justJanne |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by i139):

 there's one alternative solution
 https://github.com/mozilla/addons-
 frontend/issues/2785#issuecomment-315212909

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

Re: [tor-bugs] #22452 [Applications/Tor Browser]: favicons in tab drop down list are not first-party isolated

[Tor Bug Tracker & Wiki]

#22452: favicons in tab drop down list are not first-party isolated
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-7.0-must, tbb-linkability,   |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  tbb-7.0-must tbb-lnkability TorBrowserTeam201705R =>
 tbb-7.0-must, tbb-linkability, TorBrowserTeam201705R


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

Re: [tor-bugs] #22912 [Metrics/metrics-lib]: tpf parsing drops trailing newline

[Tor Bug Tracker & Wiki]

#22912: tpf parsing drops trailing newline
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Looks fine for the TorperfResult case, but shouldn't all descriptors end
 in newline?
 If yes, the test could be run for several input data (parametrized test).
 If no, there should be different tests and data for the various cases.

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

[tor-bugs] #22919 [Applications/Tor Browser]: Form tracking and OS fingerprinting (only Windows, but without Javascript)

[Tor Bug Tracker & Wiki]

#22919: Form tracking and OS fingerprinting (only Windows, but without 
Javascript)
--+--
 Reporter:  basvd |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I found out that TOR (/Firefox) is using a weak implementation of a
 (pseudo)random number generator. On form submission Firefox always sends
 an unique boundary delimiter together with the POST data. But this unique
 boundary string isn't so unique as it looks like.

 For example, when you send a multipart form request the number is always
 the first time: 41184676334, 2nd time: 265001916915724, 3th time:
 114782935826962, etc..

 Try it yourself: build a multipart form and check the POST data:

 {{{
 
  
 
 }}}
 {{{
 Content-Type: multipart/form-data;
 boundary=---41184676334

 Content-Length: 63-41184676334--
 }}}
 '''Threats:'''

 '''1) OS fingerprinting for Windows
 '''It looks like the implementation between Windows and Linux is
 different. Windows isn't seeding srand() calls. In this way we're 99% sure
 that boundary string with 41184676334, 265001916915724, 114782935826962
 came from a Windows OS.

 '''2) "track" form submissions between websites.
 '''On website_A I submit a form mulitple times. Now, the owner of
 website_B is able to read the boundary string and can check how many times
 a user submitted a form on website_A.

 '''3) "track" form interactions on other websites.
 '''For example, I'm the owner of website_A, and website_B is a photo
 upload website. If the user goes from website_A to B and later he came
 back to my website, I'm able to know if the user uploaded a photo on the
 other website:

  * website_A (boundary: 41184676334)
  * website_B (??)
  * website_A (boundary: 114782935826962)

 As you can see only 265001916915724 is missing, so he did one action on
 the other website.

 '''4) Fake boundaries for file uploads
 '''It is possible to inject fake data in a file and let you browser think
 that you've uploaded 2 files. In this way it is possible to upload 2 files
 by uploading only one. Of course it also depends on server side
 validation, but for the browser this seems to be okay. Example on
 [https://bugzilla.mozilla.org/show_bug.cgi?id=461204 Bugzilla]


 '''Conclusion:'''
 Without Javascript we're able to know if an user is running on Windows and
 we're able to know how many times a user submitted a form (... on another
 website)

 '''Technical analysis:'''
 The [https://dxr.mozilla.org/mozilla-
 central/source/dom/html/HTMLFormSubmission.cpp#430 current implementation]
 of the boundary delimiter in Firefox:

 {{{
 mBoundary.AssignLiteral("---");
 mBoundary.AppendInt(rand());
 mBoundary.AppendInt(rand());
 mBoundary.AppendInt(rand());
 }}}
 As you can see RAND() is called without seeding this function. Every time
 you'll (re)start TOR, the browser also resets the seed. Without a good
 seed the output is of rand is
 [http://statweb.stanford.edu/~serban/116/random.txt always predictable].
 At least on Windows, I think Linux has a different implementation of PRNG.

 A solution is to seed RAND() with the PID or something else that's not
 public (like dates or timestamps).

 5 years ago there was also a discussion about this topic on Bugzilla:
 https://bugzilla.mozilla.org/show_bug.cgi?id=461204

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

Re: [tor-bugs] #22803 [Core Tor/Tor]: Memory leak in link-handshake/certs_ok_ed25519

[Tor Bug Tracker & Wiki]

#22803: Memory leak in link-handshake/certs_ok_ed25519
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  030-backport 031-backport tor-tests  |  Actual Points:  .1
  memory-leak|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me and seems to fix the leak!

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

Re: [tor-bugs] #22912 [Metrics/metrics-lib]: tpf parsing drops trailing newline

[Tor Bug Tracker & Wiki]

#22912: tpf parsing drops trailing newline
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Like [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-22912=d00a28fe2d7d451b2c4e3d033e259e5c786294e6
 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] #22255 [Core Tor/Tor]: Frequent OOM kills of tor process

[Tor Bug Tracker & Wiki]

#22255: Frequent OOM kills of tor process
--+
 Reporter:  DeS   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 > Tor daemon DNS queries

 I believe Tor does DNS queries mostly wrong/broken logic because tor's and
 libevent's (evdns) code bugs. Leading to large queues, errors, timeouts.
 Anybody want to discuss/fix 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] #22452 [Applications/Tor Browser]: favicons in tab drop down list are not first-party isolated

[Tor Bug Tracker & Wiki]

#22452: favicons in tab drop down list are not first-party isolated
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-7.0-must tbb-lnkability  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-7.0-must tbb-first-party TorBrowserTeam201705R =>
 tbb-7.0-must tbb-lnkability TorBrowserTeam201705R


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

Re: [tor-bugs] #22327 [Applications/Tor Browser]: First party isolation of Page Info

[Tor Bug Tracker & Wiki]

#22327: First party isolation of Page Info
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-7.0-must tbb-linkability |  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-7.0-must tbb-first-party TorBrowserTeam201705 =>
 tbb-7.0-must tbb-linkability TorBrowserTeam201705


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

Re: [tor-bugs] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 When testing collector I noticed that the op-{hk,nl,us} hosts all provide
 still data since 2017/04/11 , which currently is no problem.  But, at some
 point in future a deletion policy might be needed (CollecTor will supply
 historical data).  Or, is there one in place?

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

Re: [tor-bugs] #22831 [Applications/Tor Browser]: Merge Snowflake for mac

[Tor Bug Tracker & Wiki]

#22831: Merge Snowflake for mac
-+--
 Reporter:  dcf  |  Owner:  tbb-team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake TorBrowserTeam201707R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gk):

 * status:  needs_revision => closed
 * keywords:  snowflake TorBrowserTeam201707 => snowflake
 TorBrowserTeam201707R
 * resolution:   => fixed


Comment:

 Thanks for the explanations. And, yeah, I meant splitting up the one big
 patch file in into 8 smaller ones to make it easier to deal with
 upstreaming etc. But, as I said, I am fine taking that part as-is.

 I went forward and picked the remaining commits to `master`
 (fcdc2be0a2da32a939e172564300d5a09259b75e,
 26e0cd44f2886bfad1c3d30844ff7a21eb9d0478, and
 ce3fbdf44272e3334d935044599a3b42cf7ff87c).

 This will make it into the next alpha.

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

Re: [tor-bugs] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 An operator contacted me with the following changes:
 {{{
 I had to move the current fallback Freebird31 to another ip:
 old:
  178.254.13.126:80 orport=443
  id=F9246DEF2B653807236DA134F2AEAB103D58ABFE
 new:
  ORPort 81.7.11.38:443, DirPort 81.7.11.38:80
  fp F9246DEF2B653807236DA134F2AEAB103D58ABFE

 ...
 I would like to opt-in the following Ichotolot60 as an alternative:
  ORPort 81.7.14.253:443, DirPort 81.7.14.253:9001
  fp 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E

 
 The two current ones will stay:
  178.254.44.135:9030 orport=9001
  id=8FA37B93397015B2BC5A525C908485260BE9F422

  178.254.20.134:80 orport=443
  id=9F5068310818ED7C70B0BC4087AB55CB12CB4377
 }}}

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