Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:   => teor
 * 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] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_revision


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

Re: [tor-bugs] #21310 [Core Tor/Tor]: Exits should tell clients when they are connecting to an IPv6-only hostname

[Tor Bug Tracker & Wiki]

#21310: Exits should tell clients when they are connecting to an IPv6-only 
hostname
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.7-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  0.1
Parent ID:  #21311| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * owner:   => teor
 * status:  needs_revision => 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] #21310 [Core Tor/Tor]: Exits should tell clients when they are connecting to an IPv6-only hostname

[Tor Bug Tracker & Wiki]

#21310: Exits should tell clients when they are connecting to an IPv6-only 
hostname
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.7-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  0.1
Parent ID:  #21311| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  accepted => needs_revision


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

Re: [tor-bugs] #22760 [Core Tor/Tor]: Parse or ignore falback extra-info markers

[Tor Bug Tracker & Wiki]

#22760: Parse or ignore falback extra-info markers
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22759| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


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

Re: [tor-bugs] #22689 [Core Tor/Tor]: prop224: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: prop224: Stop rend and intro points being used as single hop proxies
---+
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop224, relay-safety  |  Actual Points:
Parent ID:  #17945 | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * owner:   => teor
 * 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] #22689 [Core Tor/Tor]: prop224: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: prop224: Stop rend and intro points being used as single hop proxies
---+
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop224, relay-safety  |  Actual Points:
Parent ID:  #17945 | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  assigned => needs_revision


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

Re: [tor-bugs] #13912 [Core Tor/Tor]: Key Security: Zeroing Buffers Is Insufficient (AES-NI leaves keys in SSE registers)

[Tor Bug Tracker & Wiki]

#13912: Key Security: Zeroing Buffers Is Insufficient (AES-NI leaves keys in SSE
registers)
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  security registers aesni memwipe |  Actual Points:
  tor-relay  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 Replying to [comment:11 cypherpunks]:
 > What about ROP gadgets that do not provide turing complete behavior (so
 no "arbitrary" code execution), but still expose the sensitive registers?

 I think you've likewise effective lost at that point.  Patch OpenSSL's
 assembly in strategic locations if you actually care about this, though
 there's a a lot of other places in the code that don't scrub "sensitive"
 keying information so IMO this is a lost cause.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22861 [Core Tor/Tor]: Update tor-spec for ed25519 link authentication keys

[Tor Bug Tracker & Wiki]

#22861: Update tor-spec for ed25519 link authentication keys
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 tor-spec.txt says that the ed25519 link authentication key isn't used:
 {{{
These are Ed25519 keys:

 - A long-term "master identity" key.  This key never
   changes; it is used only to sign the "signing" key below.  It may be
   kept offline.
 - A medium-term "signing" key.  This key is signed by the master
 identity
   key, and must be kept online.  A new one should be generated
   periodically.
 - A short-term "link authentication" key.  Not yet used.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22862 [Core Tor/Tor]: tor-spec doesn't say how clients authenticate authorities or fallback directories

[Tor Bug Tracker & Wiki]

#22862: tor-spec doesn't say how clients authenticate authorities or fallback
directories
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 {{{
 In all handshake variants, once all certificates are exchanged, all
 parties receiving certificates must confirm that the identity key is
 as
 expected.  (When initiating a connection, the expected identity key is
 -the one given in the directory; when creating a connection because of
 an
 +during bootstrap: the one given in the hard-coded authority or
 fallback list,
 +after bootstrap: the one in the directory; when creating a connection
 because of an
 EXTEND cell, the expected identity key is the one given in the cell.)
 If
 the key is not as expected, the party must close the connection.
 }}}

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

Re: [tor-bugs] #22862 [Core Tor/Tor]: tor-spec doesn't say how clients authenticate authorities or fallback directories

[Tor Bug Tracker & Wiki]

#22862: tor-spec doesn't say how clients authenticate authorities or fallback
directories
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Description changed by teor:

Old description:

> {{{
> In all handshake variants, once all certificates are exchanged, all
> parties receiving certificates must confirm that the identity key is
> as
> expected.  (When initiating a connection, the expected identity key
> is
> -the one given in the directory; when creating a connection because
> of an
> +during bootstrap: the one given in the hard-coded authority or
> fallback list,
> +after bootstrap: the one in the directory; when creating a
> connection because of an
> EXTEND cell, the expected identity key is the one given in the cell.)
> If
> the key is not as expected, the party must close the connection.
> }}}

New description:

 {{{
  In all handshake variants, once all certificates are exchanged, all
  parties receiving certificates must confirm that the identity key is
 as
  expected.  (When initiating a connection, the expected identity key
 is
 -the one given in the directory; when creating a connection because of
 an
 +during bootstrap: the one given in the hard-coded authority or
 fallback list,
 +after bootstrap: the one in the directory; when creating a connection
 because of an
  EXTEND cell, the expected identity key is the one given in the cell.)
 If
  the key is not as expected, the party must close the connection.
 }}}

--

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

Re: [tor-bugs] #22862 [Core Tor/Tor]: tor-spec doesn't say how clients authenticate authorities or fallback directories

[Tor Bug Tracker & Wiki]

#22862: tor-spec doesn't say how clients authenticate authorities or fallback
directories
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review


Comment:

 Someone probably needs to fix the line wrapping when this is applied.

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

Re: [tor-bugs] #22862 [Core Tor/Tor]: tor-spec doesn't say how clients authenticate authorities or fallback directories

[Tor Bug Tracker & Wiki]

#22862: tor-spec doesn't say how clients authenticate authorities or fallback
directories
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Old description:

> {{{
>  In all handshake variants, once all certificates are exchanged, all
>  parties receiving certificates must confirm that the identity key is
> as
>  expected.  (When initiating a connection, the expected identity key
> is
> -the one given in the directory; when creating a connection because
> of an
> +during bootstrap: the one given in the hard-coded authority or
> fallback list,
> +after bootstrap: the one in the directory; when creating a
> connection because of an
>  EXTEND cell, the expected identity key is the one given in the
> cell.)  If
>  the key is not as expected, the party must close the connection.
> }}}

New description:

 {{{
  In all handshake variants, once all certificates are exchanged, all
  parties receiving certificates must confirm that the identity key is
 as
  expected.  (When initiating a connection, the expected identity key
 is
 -the one given in the directory; when creating a connection because of
 an
 +when no reasonably live consensus is available: the one given in the
 hard-coded authority or fallback list;
 +or otherwise, the one in the directory; when creating a connection
 because of an
  EXTEND cell, the expected identity key is the one given in the cell.)
 If
  the key is not as expected, the party must close the connection.
 }}}

--

Comment (by teor):

 Let's be more precise

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

Re: [tor-bugs] #22862 [Core Tor/Tor]: tor-spec doesn't say how clients authenticate authorities or fallback directories

[Tor Bug Tracker & Wiki]

#22862: tor-spec doesn't say how clients authenticate authorities or fallback
directories
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Old description:

> {{{
>  In all handshake variants, once all certificates are exchanged, all
>  parties receiving certificates must confirm that the identity key is
> as
>  expected.  (When initiating a connection, the expected identity key
> is
> -the one given in the directory; when creating a connection because
> of an
> +when no reasonably live consensus is available: the one given in the
> hard-coded authority or fallback list;
> +or otherwise, the one in the directory; when creating a connection
> because of an
>  EXTEND cell, the expected identity key is the one given in the
> cell.)  If
>  the key is not as expected, the party must close the connection.
> }}}

New description:

 {{{
  In all handshake variants, once all certificates are exchanged, all
  parties receiving certificates must confirm that the identity key is
 as
  expected.  (When initiating a connection, the expected identity key
 is
 -the one given in the directory; when creating a connection because of
 an
 +when no reasonably live consensus is available: the one given in the
 hard-coded authority or fallback list;
 +when there is a reasonably live consensus: the one in the directory;
 when creating a connection because of an
  EXTEND cell, the expected identity key is the one given in the cell.)
 If
  the key is not as expected, the party must close the connection.
 }}}

--

Comment (by teor):

 Ok, I think I could do with some help re-phrasing this.
 The description has my best attempt at 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] #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 cypherpunks):

 > Maybe I am doing something wrong.
 > So please try to reproduce this thing.

 I don't trust windows to get internet connection. My virtual env isolated.
 Maybe it is reason for non reproducible result with outbound connections.
 btw, your win7 via wanem isolated from internet?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Core Tor/Tor]: 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:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  windows tor-client win32 tor-relay   |  Actual Points:
  security hardening 031-backport,   |
  TorBrowserTeam201707   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  windows tor-client win32 tor-relay security hardening
 031-backport =>
 windows tor-client win32 tor-relay security hardening 031-backport,
 TorBrowserTeam201707


Comment:

 Not sure how long this takes but we might want to try it in the next alpha
 anyway. Thus, putting it on our radar.

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

 > btw, your win7 via wanem isolated from internet?

 Yes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 don't trust windows to get internet connection.

 Is it hard to make isolated Tor network?

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

 > Is it hard to make isolated Tor network?

 [/wiki/doc/TorChutneyGuide Chutney], except windows case probably.

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

 > 4) How do we explain the tor process just uses 400 Meg of memory each
 (see arma comment above)
 > How can a rising number of connections (to tor - nothing else running)
 drain the 4G memory out of the machine when the tor processes itself only
 use about 1G.
 > Where does the memory go and why ?

 Sockets' buffers!

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

Re: [tor-bugs] #22861 [Core Tor/Tor]: Update tor-spec for ed25519 link authentication keys

[Tor Bug Tracker & Wiki]

#22861: Update tor-spec for ed25519 link authentication keys
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * 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] #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):

 Can't reproduce inbound/outbound difference with VM and isolated Tor
 network.
 Probably that is because host and guest have different sets of OS updates.

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

 > Probably that is because host and guest have different sets of OS
 updates.

 Microsoft probably fixed silently and partially somedays before. My VM
 with "outdated" win7 too. Tried almost everything, redirected for internet
 detection, assigned public ip addr, connected to 443 port. nada, 53KiB/s
 per 150ms as hard coded.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22863 [- Select a component]: Bridge relay don't work on IPv6

[Tor Bug Tracker & Wiki]

#22863: Bridge relay don't work on IPv6
--+--
 Reporter:  mr-burns  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.0.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 tor will listen on the port, but no self test will happens.
 The self test will only done for the IPv4 port.

 Here the log:
 Jul 09 10:56:54 foo.foo.foo systemd[1]: Starting Anonymizing overlay
 network for TCP...
 Jul 09 10:56:54 foo.foo.foo tor[23178]: Jul 09 10:56:54.893 [notice] Tor
 0.3.0.9 (git-22b3bf094e327093) running on Linux with Libevent
 2.0.21-stable, OpenSS
 Jul 09 10:56:54 foo.foo.foo tor[23178]: Jul 09 10:56:54.893 [notice] Tor
 can't help you if you use it wrong! Learn how to be safe at
 https://www.torproject.
 Jul 09 10:56:54 foo.foo.foo tor[23178]: Jul 09 10:56:54.945 [notice] Read
 configuration file "/usr/share/tor/defaults-torrc".
 Jul 09 10:56:54 foo.foo.foo tor[23178]: Jul 09 10:56:54.946 [notice] Read
 configuration file "/etc/tor/torrc".
 Jul 09 10:56:54 foo.foo.foo tor[23178]: Jul 09 10:56:54.951 [notice] Based
 on detected system memory, MaxMemInQueues is set to 2964 MB. You can
 override thi
 Jul 09 10:56:54 foo.foo.foo tor[23178]: Configuration was valid
 Jul 09 10:56:54 foo.foo.foo systemd[1]: Started Anonymizing overlay
 network for TCP.
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: OpenSSL version from headers does
 not match the version we're running with. If you get weird crashes, that
 might be
 Jul 09 10:56:55 foo.foo.foo tor[23179]: Jul 09 10:56:55.111 [notice] Tor
 0.3.0.9 (git-22b3bf094e327093) running on Linux with Libevent
 2.0.21-stable, OpenSS
 Jul 09 10:56:55 foo.foo.foo tor[23179]: Jul 09 10:56:55.112 [notice] Tor
 can't help you if you use it wrong! Learn how to be safe at
 https://www.torproject.
 Jul 09 10:56:55 foo.foo.foo tor[23179]: Jul 09 10:56:55.112 [notice] Read
 configuration file "/usr/share/tor/defaults-torrc".
 Jul 09 10:56:55 foo.foo.foo tor[23179]: Jul 09 10:56:55.112 [notice] Read
 configuration file "/etc/tor/torrc".
 Jul 09 10:56:55 foo.foo.foo tor[23179]: Jul 09 10:56:55.117 [notice] Based
 on detected system memory, MaxMemInQueues is set to 2964 MB. You can
 override thi
 Jul 09 10:56:55 foo.foo.foo tor[23179]: Jul 09 10:56:55.118 [notice]
 Opening OR listener on [IPv6Address]:Port
 Jul 09 10:56:55 foo.foo.foo tor[23179]: Jul 09 10:56:55.118 [notice]
 Opening OR listener on IPv4Address:Port
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Tor 0.3.0.9 (git-22b3bf094e327093)
 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1e-fips and Zlib
 1.2.7.
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Tor can't help you if you use it
 wrong! Learn how to be safe at
 https://www.torproject.org/download/download#warning
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Read configuration file
 "/usr/share/tor/defaults-torrc".
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Read configuration file
 "/etc/tor/torrc".
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Based on detected system memory,
 MaxMemInQueues is set to 2964 MB. You can override this by setting
 MaxMemInQueues b
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Opening OR listener on
 [IPv6Address]:Port
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Opening OR listener on
 IPv4Address:Port
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Parsing GEOIP IPv4 file
 /usr/share/tor/geoip.
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Parsing GEOIP IPv6 file
 /usr/share/tor/geoip6.
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: Configured to measure statistics.
 Look for the *-stats files that will first be written to the data
 directory in 24
 Jul 09 10:56:55 foo.foo.foo Tor[23179]: We were built to run on a 64-bit
 CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that
 apparently lac
 Jul 09 10:56:56 foo.foo.foo Tor[23179]: Your Tor server's identity key
 fingerprint is 'XX'
 Jul 09 10:56:56 foo.foo.foo Tor[23179]: Your Tor bridge's hashed identity
 key fingerprint is ''
 Jul 09 10:56:56 foo.foo.foo Tor[23179]: Bootstrapped 0%: Starting
 Jul 09 10:57:10 foo.foo.foo Tor[23179]: Starting with guard context
 "default"
 Jul 09 10:57:10 foo.foo.foo Tor[23179]: Bootstrapped 80%: Connecting to
 the Tor network
 Jul 09 10:57:10 foo.foo.foo Tor[23179]: Opening Control listener on
 /run/tor/control
 Jul 09 10:57:10 foo.foo.foo Tor[23179]: Bootstrapped 85%: Finishing
 handshake with first hop
 Jul 09 10:57:11 foo.foo.foo Tor[23179]: Bootstrapped 90%: Establishing a
 Tor circuit
 Jul 09 10:57:11 foo.foo.foo Tor[23179]: Tor has successfully opened a
 circuit. Looks like client functionality is working.
 Jul 09 10:57:11 foo.foo.foo Tor[23179]: Bootstrappe

Re: [tor-bugs] #12418 [Applications/Tor Browser]: TBBs with UBSan create lots of errors when running

[Tor Bug Tracker & Wiki]

#12418: TBBs with UBSan create lots of errors when running
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, tbb-hardened  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by tom):

 Replying to [comment:10 cypherpunks]:
 > Has anyone started working on at least instrumenting individual FF
 components, as suggested above?

 Kind of. Mozilla spend a considerable amount of person-time playing with
 UBSAN.

 The conclusion was that some tests are valuable and should be used
 (bounds, pointer-overflow, vptr although this requires RTTI).

 But that others (signed and unsigned overflow) caused a gratuitous amount
 of false positives (largely in the graphics and layout areas but in
 general all over the place) and it's infeasible to whitelist them all. We
 had someone spend a month on this and using his whitelist we brought the
 number of reports down from the hundred of thousands down to the mere
 thousands - but even then it was with a ton of effort and had a ton of
 effort to go.

 So I think the path forward is to turn on UBSAN on the whole browser, run
 it through something like the web platform tests or Mozilla's usual unit
 tests, and slowly increase the number of UBSAN tests one by one. When we
 hit one that causes too many false positives, we turn it back off and
 investigate turning it on for an individual component (like image
 decoders.)

 Also I would suggest the path forward for this is in Mozilla's court,
 rather than Tor's. Not that Tor has to wait for Mozilla, only that making
 use of Mozilla's infrastructure will make it considerably easier. Tor devs
 have access to that, and if any cypherpunks want access, I think the only
 thing needed is a few contributions* that I can point to and say "This
 person is doing good work, let's give them access to run their tests on
 our task runner".

 \* Contributions such as looking at and improving UBSAN? :)

 Here's where our stuff is:

 - http://searchfox.org/mozilla-central/source/build/autoconf/sanitize.m4 -
 Here's where we have the mozconfig options for the sanitizers. We have the
 UBSAN integer one here. You can swap out integer for one of the other
 tests.
 - http://searchfox.org/mozilla-central/search?q=ubsan&path= - at the top
 you can find our blacklist

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

 Sadly, updates did not helped me to reproduce inbound/outgoing difference.
 But now I know that outgoing upload for relay and for client not differs.
 Both of them shows ~50 KiB/s in isolated VM.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22864 [- Select a component]: Problems created by new version - Loggins in to Secure Sites

[Tor Bug Tracker & Wiki]

#22864: Problems created by new version - Loggins in to Secure Sites
--+-
 Reporter:  spirit1812s   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Since the changeover to the new version I can no longer log in to a site I
 go to often.  The site seems to log me in, but then the login is cancelled
 and I can't do things a logged in person could do.  There is an icon in
 the menu bar that allows me to turn off security for the site, but it
 resets every time I submit my user name and password.

 This just happened.  I have an older version on another computer that
 works fine.  I transferred it to my desktop computer and Tor automatically
 applied an update without my consent.  Now it no longer works.

 Whatever you did, please reverse 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] #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 cypherpunks):

 Win7 detects we tries to fool it with VM and disables super exclusive
 feature :)

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

 Or triggered by some peer's params like tcp window.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

[Tor Bug Tracker & Wiki]

#22865: Explicitly set Content-Length to zero when there is no data to send
--+-
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Since Go 1.8 http.Transport does not set Content-Length header if body
 contains no bytes.
 https://golang.org/doc/go1.8#net_http
 https://go-review.googlesource.com/c/31445/

 However some of domain fronts do inspect Content-Length header and return
 411 error when it is not set. This breaks connection entierly since these
 packets do not travel beyond a frontend to a meek server.

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

Re: [tor-bugs] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

[Tor Bug Tracker & Wiki]

#22865: Explicitly set Content-Length to zero when there is no data to send
--+--
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by twim):

 * 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] #22864 [Applications/Tor Browser]: Problems created by new version - Loggins in to Secure Sites

[Tor Bug Tracker & Wiki]

#22864: Problems created by new version - Loggins in to Secure Sites
--+--
 Reporter:  spirit1812s   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 > The site seems to log me in, but then the login is cancelled

 You get logged out immediately or after a short period of time?

 > There is an icon in the menu bar that allows me to turn off security for
 the site

 By that you mean the padlock in the URL bar (where you type websites)?

 Also giving steps to reproduce your issue would be pretty helpful.

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

Re: [tor-bugs] #22863 [Core Tor]: Bridge relay don't work on IPv6

[Tor Bug Tracker & Wiki]

#22863: Bridge relay don't work on IPv6
--+--
 Reporter:  mr-burns  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * component:  - Select a component => Core Tor


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

Re: [tor-bugs] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

[Tor Bug Tracker & Wiki]

#22865: Explicitly set Content-Length to zero when there is no data to send
--+--
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Thanks for the clear explanation. I plan to merge this patch.

 Can you give an example of a service that this was causing problems with?
 If it was Amazon or Azure, then we need to change something about our test
 procedure because we didn't detect 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] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

[Tor Bug Tracker & Wiki]

#22865: Explicitly set Content-Length to zero when there is no data to send
--+--
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by twim):

 Unfortunately I can't give you an example right now because it looks like
 something that should not happen. Maybe it's even a bug.

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

Re: [tor-bugs] #22762 [Core Tor/Tor]: Revise coding standards expectation for tests to be run before review

[Tor Bug Tracker & Wiki]

#22762: Revise coding standards expectation for tests to be run before review
---+
 Reporter:  chelseakomlo   |  Owner:  chelseakomlo
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  documentation  |  Actual Points:
Parent ID: | Points:
 Reviewer:  catalyst   |Sponsor:
---+

Comment (by chelseakomlo):

 I pushed the commit for when to run `make distcheck` to:

 `g...@github.com:chelseakomlo/tor_patches.git`, branch `coding-
 standards-22762`, commit 934f85f87aa17bf6e1ffad37df8d8d4fb7bf404e

 Let me know if there is any changes or additions I can make.

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

Re: [tor-bugs] #22762 [Core Tor/Tor]: Revise coding standards expectation for tests to be run before review

[Tor Bug Tracker & Wiki]

#22762: Revise coding standards expectation for tests to be run before review
---+
 Reporter:  chelseakomlo   |  Owner:  chelseakomlo
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  documentation  |  Actual Points:
Parent ID: | Points:
 Reviewer:  catalyst   |Sponsor:
---+
Changes (by chelseakomlo):

 * 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] #22832 [Applications/Tor Browser]: libwebrtc and snowflake are not being built reproducibly (unless you build in the same month)

[Tor Bug Tracker & Wiki]

#22832: libwebrtc and snowflake are not being built reproducibly (unless you 
build
in the same month)
--+
 Reporter:  gk|  Owner:  dcf
 Type:  defect| Status:
  |  needs_review
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-gitian TorBrowserTeam201707R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * status:  assigned => needs_review
 * keywords:  tbb-gitian => tbb-gitian TorBrowserTeam201707R


Comment:

 I made a new [https://gitweb.torproject.org/user/dcf/tor-browser-
 bundle.git/log/?h=snowflake-mac-5 snowflake-mac-5] branch and
 [https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commit/?h
 =snowflake-mac-5&id=669ca72e0824c9eb7f4fb882849ce322c583d4ef this commit]
 is the one you want.

 Including those extra .o files was always a bug. We just didn't notice
 until now, because they happened to be of a compatible architecture to the
 actual webrtc .o files. Not including the inappropriate .o files is also
 the reason why it's no longer necessary to have `-not -name '*.main.o'
 -not -name 'dump_syms_regtest.o'` in the `find` command.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake TorBrowserTeam201707R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 I made a new branch [https://gitweb.torproject.org/user/dcf/tor-browser-
 bundle.git/log/?h=snowflake-
 mac-5&id=f662c9cb1caea6348fe2dcb001d6600f2c813ae0 snowflake-mac-5] in
 response to a request at comment:5:ticket:22832. It's the same as
 snowflake-mac-4 except for comments.

 Overall diff: https://gitweb.torproject.org/user/dcf/tor-browser-
 bundle.git/diff/?h=snowflake-
 
mac-5&id=f662c9cb1caea6348fe2dcb001d6600f2c813ae0&id2=f47d812d86c40f349ce113eee5783522a1d9cc13

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

Re: [tor-bugs] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

[Tor Bug Tracker & Wiki]

#22865: Explicitly set Content-Length to zero when there is no data to send
--+--
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Replying to [comment:3 twim]:
 > Unfortunately I can't give you an example right now because it looks
 like something that should not happen. Maybe it's even a bug.

 Do you mean a bug in the fronting service, or a bug somewhere else in
 meek-client?

 I would guess, that with a POST, the http client would omit `Content-
 Length`, and send `Transfer-Encoding: chunked`, then send a zero-length
 chunk if there were nothing to send. But I haven't checked.

 I'm still planning to merge your patch, because it looks like the right
 thing 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

[tor-bugs] #22866 [- Select a component]: Default language

[Tor Bug Tracker & Wiki]

#22866: Default language
--+-
 Reporter:  masser|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Why does Thor not remember my chosen language and when opening (by
 default) determines English?

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

Re: [tor-bugs] #12418 [Applications/Tor Browser]: TBBs with UBSan create lots of errors when running

[Tor Bug Tracker & Wiki]

#12418: TBBs with UBSan create lots of errors when running
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, tbb-hardened  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:11 tom]:
 > Replying to [comment:10 cypherpunks]:
 > > Has anyone started working on at least instrumenting individual FF
 components, as suggested above?
 >
 > Kind of. Mozilla spend a considerable amount of person-time playing with
 UBSAN.

 Wow! I had no idea so much work has already been put into this task! This
 will be very helpful.

 > The conclusion was that some tests are valuable and should be used
 (bounds, pointer-overflow, vptr although this requires RTTI).
 >
 > But that others (signed and unsigned overflow) caused a gratuitous
 amount of false positives (largely in the graphics and layout areas but in
 general all over the place) and it's infeasible to whitelist them all. We
 had someone spend a month on this and using his whitelist we brought the
 number of reports down from the hundred of thousands down to the mere
 thousands - but even then it was with a ton of effort and had a ton of
 effort to go.

 Unfortunately, those are some of the most important types of UB that must
 be prevented. An alternative (mutually exclusive due to incompatibilities
 with internal symbol names, or something of that sort), if suitable
 manpower is present, is to instrument important parts of FF with the PaX
 Size Overflow plugin (see
 https://forums.grsecurity.net/viewtopic.php?f=7&t=3043). It provides
 better protection than UBSAN for this specific issue.

 > So I think the path forward is to turn on UBSAN on the whole browser,
 run it through something like the web platform tests or Mozilla's usual
 unit tests, and slowly increase the number of UBSAN tests one by one. When
 we hit one that causes too many false positives, we turn it back off and
 investigate turning it on for an individual component (like image
 decoders.)

 I had assumed that the amount of UB would be so great that it would be
 infeasible to do this in any reasonable amount of time. I still feel like
 instrumenting individual components of the browser would be easier.

 > Also I would suggest the path forward for this is in Mozilla's court,
 rather than Tor's. Not that Tor has to wait for Mozilla, only that making
 use of Mozilla's infrastructure will make it considerably easier. Tor devs
 have access to that, and if any cypherpunks want access, I think the only
 thing needed is a few contributions* that I can point to and say "This
 person is doing good work, let's give them access to run their tests on
 our task runner".

 I tend to avoid Mozilla's ticket system due to their excessively
 bureaucratic nature, and their tendency to put security as a low priority.
 All my Firefox-related contributions have been made here (though
 admittedly I have made more contributions for Tor itself, and relatively
 few for Firefox).

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

Re: [tor-bugs] #22866 [Applications/Tor Browser]: Default language

[Tor Bug Tracker & Wiki]

#22866: Default language
--+---
 Reporter:  masser|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => not a bug
 * component:  - Select a component => Applications/Tor Browser


Comment:

 Because people can use it to track you around the Internet.

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

Re: [tor-bugs] #22858 [Applications/Tor Browser]: The size of my working window

[Tor Bug Tracker & Wiki]

#22858: The size of my working window
--+---
 Reporter:  masser|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * priority:  High => Medium
 * resolution:   => not a bug
 * status:  needs_information => closed
 * component:  - Select a component => Applications/Tor Browser


Comment:

 Because people can use it to track you around the Internet.

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

 Or VM simulation is inaccurate somewhere.
 Here is upload test with NAT-ed VM and guard
 
[[https://atlas.torproject.org/#details/E555B09C77036733E00A7D61CD534BA9AF4AA232|E555B09C]]
 (ping = 124 ms from my location):
 attachment:tor_vm_fast_upload.png

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

Re: [tor-bugs] #22863 [Core Tor]: Bridge relay don't work on IPv6

[Tor Bug Tracker & Wiki]

#22863: Bridge relay don't work on IPv6
--+--
 Reporter:  mr-burns  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 This is either a duplicate of #4847, or a duplicate of #6939.

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

Re: [tor-bugs] #21999 [Applications/Tor Browser]: The "request English language web pages"-prompt is not working in 7.0a3

[Tor Bug Tracker & Wiki]

#21999: The "request English language web pages"-prompt is not working in 7.0a3
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-e10s, tbb-7.0-must,|  Actual Points:
  tbb-7.0-issues, tbb-regression,|
  TorBrowserTeam201707R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:
 ff52-esr, tbb-e10s, tbb-7.0-must, tbb-7.0-issues, tbb-regression,
 TorBrowserTeam201707
 =>
 ff52-esr, tbb-e10s, tbb-7.0-must, tbb-7.0-issues, tbb-regression,
 TorBrowserTeam201707R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:13 gk]:

 Thanks for the review and testing. Here is a revised branch, with the same
 patch revised to trigger the prompt only when a request is launched from a
 content "load context". I tested this new version with update requests and
 various about: pages and the prompt was not triggered.

 I also noticed that some homepage URLs were not being properly detected by
 function `torbutton_is_homepage_url(aURI)`. So I added a second patch to
 this new branch to try to take care of that problem.

 https://github.com/arthuredelstein/torbutton/commits/21999+3

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