Re: [tor-bugs] #23013 [Core Tor/Tor]: Tor 0.3.0.9 tarball was missing ReleaseNotes entry

[Tor Bug Tracker & Wiki]

#23013: Tor 0.3.0.9 tarball was missing ReleaseNotes entry
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 (Reported by Udo van den Heuvel via a tor-talk mail.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23013 [Core Tor/Tor]: Tor 0.3.0.9 tarball was missing ReleaseNotes entry

[Tor Bug Tracker & Wiki]

#23013: Tor 0.3.0.9 tarball was missing ReleaseNotes entry
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 https://dist.torproject.org/tor-0.3.0.9.tar.gz
 has an 0.3.0.9 stanza in the ChangeLog file but not in the ReleaseNotes
 file.

 There's a release checklist:
 https://gitweb.torproject.org/tor.git/tree/doc/HACKING/ReleasingTor.md
 but it looks like this step got missed this time.

 Are there technical steps we can take to make sure things are synced in
 future releases, so we don't have to rely only on the checklist?

 Like, 'make dist' could check and complain?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23012 [- Select a component]: ebay password issues

[Tor Bug Tracker & Wiki]

#23012: ebay password issues
--+-
 Reporter:  hoosierbros   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 no geek here..but does not stay signed in on ebay...or juno...or anything
 else for that matter

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23011 [Obfuscation/BridgeDB]: Update leekspin's requirements.txt

[Tor Bug Tracker & Wiki]

#23011: Update leekspin's requirements.txt
--+--
 Reporter:  Samdney   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Trivial   |   Keywords:  leekspin
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In a fresh python2 virtualenv enviroment, I cloned and installed leekspin
 and the requirements with  "pip install -r requirements.txt". After
 running "leekspin -n 20" I received the following error:

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 Traceback (most recent call last):
   File "/mypath/python2env/bin/leekspin", line 37, in 
 from leekspin import generator
   File "/mypath/python2env/lib/python2.7/site-
 packages/leekspin/generator.py", line 27, in 
 import OpenSSL
   File "/mypath/python2env/lib/python2.7/site-
 packages/OpenSSL/__init__.py", line 8, in 
 from OpenSSL import rand, crypto, SSL
   File "/mypath/python2env/lib/python2.7/site-packages/OpenSSL/SSL.py",
 line 105, in 
 SSL_ST_INIT = _lib.SSL_ST_INIT
 AttributeError: 'module' object has no attribute 'SSL_ST_INIT'
   }}}
 }}}

 I changed in "requirements.txt" the entry
 PyOpenSSL==0.14
 to
 PyOpenSSL==16.2.0

 Now it works fine :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23010 [Core Tor/Tor]: prop224: make sure the protocol handshakes are extensible

[Tor Bug Tracker & Wiki]

#23010: prop224: make sure the protocol handshakes are extensible
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop224
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 How and when do we plan to move away from using SHA1 in Tor circuits?

 For non-onion service circuits, this would mean:
 * implementing support for circuit digests using a secure hash [0]
 * adding a Relay protocol version 3
 * teaching clients to use a secure hash [0] digest with relays with Relay
 protocol >= 3

 For onion service circuits, it's more complicated, because the
 following circuit types can't use relay versions from the consensus:
 * client to intro
 * service to rend
 * client to service
 (Using relay versions from the consensus leaks which consensus clients
 and services have, which reduces the anonymity set.)

 Here are the upgrade mechanisms in prop224 at the moment, for both
 circuit protocol versions and any necessary handshake material:

 client to intro:
 * the protocol version could be in a proto line to each intro point,
  but this isn't implemented yet
 * the handshake data can be in the link-specifiers (I think?)

 service to rend
 * the protocol version could be in the EXT_FIELD in the INTRODUCE
  cell, but this isn't implemented yet
 * the handshake data can be in the link-specifiers (I think?)

 client to service:
 * the protocol version is in the create2-formats in the descriptor
 * the handshake data is in HANDSHAKE_INFO in the RENDEZVOUS cells
 * SHA3-256 digests are implemented, but not documented in prop224 (#22995)

 I suggest we make the following changes to prop224 to make this happen:

 Protocol version information:
 * add the relevant relay protocol versions to the intro point section
  of the descriptor
 * put the relevant relay protocol versions in an EXT_FIELD in the
  INTRODUCE cell
 * check create2-formats contains all the version info we will need to
  change the client to service circuit protocol version

 Downgrade resistance:
 * teach clients and services to use the highest common protocol between
  client/service and relay, excluding protocols that are below the
  minimum required protocol versions
 * work out how we will tell clients to no longer accept an old
  create2-formats line from a service

 [0]: probably SHA3-256, but let's make sure it can be upgraded, because it
 will be broken some day, too

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

Re: [tor-bugs] #22948 [Core Tor/Tor]: Padding, Keepalive and Drop cells should have random payloads

[Tor Bug Tracker & Wiki]

#22948: Padding, Keepalive and Drop cells should have random payloads
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:  #18856| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:8 isis]:
 > ...
 >
 > So the defense-in-depth in this case has a lot of assumptions like: if
 we believe that AES-128 is not breakable in close-to-real-time (we do),
 and we believe that neither endpoint is victim to any kleptographic attack
 (we can't defend against that), and we don't believe that an adversary is
 capable of a SHA-256 second-preimage in any reasonable amount of time (we
 don't), then the fact that some subset of cells on a circuit have known
 plaintexts probably doesn't really give you that much of an advantage in
 terms of forging a MAC that is cumulative over all data seen so far (i.e.
 `H(a || b || c || …)` ''not'' "chained" like `H(… || H(c || H(b ||
 H(a`). You'd need a second-preimage on SHA-256, so finding `x'` where
 `H(x) == H(x')`.

 Unfortunately, Tor still uses SHA1 for its relay cell digests, except for
 onion service v3 client to service cells, which use SHA3-256.

 But I think your reasoning still applies, at least for the next few years.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23009 [Core Tor/Tor]: Make it clear that RELAY_SENDME cells don't have a payload

[Tor Bug Tracker & Wiki]

#23009: Make it clear that RELAY_SENDME cells don't have a payload
--+
 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, doc
Actual Points:|  Parent ID:  #18856
   Points:|   Reviewer:
  Sponsor:|
--+
 tor-spec taslks about SENDME cells, but doesn't say if they have a payload
 or not. We should probably make this explicit:
 https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1560

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

Re: [tor-bugs] #23005 [Webpages/Blog]: 'no space left on device' Drupal warning messages

[Tor Bug Tracker & Wiki]

#23005: 'no space left on device' Drupal warning messages
---+---
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by snoek):

 duplicate of 23008

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

Re: [tor-bugs] #23005 [Webpages/Blog]: 'no space left on device' Drupal warning messages

[Tor Bug Tracker & Wiki]

#23005: 'no space left on device' Drupal warning messages
---+---
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by snoek):

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


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

Re: [tor-bugs] #22995 [Core Tor/Tor]: prop224 should say we use SHA3-256 for rend circuit digests (was: prop224 should say we use SHA256 for rend circuit digests)

[Tor Bug Tracker & Wiki]

#22995: prop224 should say we use SHA3-256 for rend circuit digests
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tor-spec, doc  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Description changed by teor:

Old description:

> In prop224, the rend section says:
> {{{
>A successfully completed handshake, as embedded in the
>INTRODUCE/RENDEZVOUS cells, gives the client and hidden service host
>a shared set of keys Kf, Kb, Df, Db, which they use for sending
>end-to-end traffic encryption and authentication as in the regular
>Tor relay encryption protocol, applying encryption with these keys
>before other encryption, and decrypting with these keys before other
>decryption. The client encrypts with Kf and decrypts with Kb; the
>service host does the opposite.
> }}}
> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-
> ng.txt#n1890
>
> But that's not what the code does: circuit_init_cpath_crypto() uses
> SHA256 rather than SHA1 when `is_hs_v3` is true.

New description:

 In prop224, the rend section says:
 {{{
A successfully completed handshake, as embedded in the
INTRODUCE/RENDEZVOUS cells, gives the client and hidden service host
a shared set of keys Kf, Kb, Df, Db, which they use for sending
end-to-end traffic encryption and authentication as in the regular
Tor relay encryption protocol, applying encryption with these keys
before other encryption, and decrypting with these keys before other
decryption. The client encrypts with Kf and decrypts with Kb; the
service host does the opposite.
 }}}
 https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-
 ng.txt#n1890

 But that's not what the code does: circuit_init_cpath_crypto() uses
 SHA3-256 rather than SHA1 when `is_hs_v3` is true.

--

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

Re: [tor-bugs] #23008 [Webpages/Blog]: Possible low disk space on tor blog server

[Tor Bug Tracker & Wiki]

#23008: Possible low disk space on tor blog server
---+--
 Reporter:  snoek  |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by snoek):

 * 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] #23008 [Webpages/Blog]: Possible low disk space on tor blog server

[Tor Bug Tracker & Wiki]

#23008: Possible low disk space on tor blog server
---+---
 Reporter:  snoek  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Minor  | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by snoek):

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


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

Re: [tor-bugs] #23005 [Webpages/Blog]: 'no space left on device' Drupal warning messages

[Tor Bug Tracker & Wiki]

#23005: 'no space left on device' Drupal warning messages
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by snoek):

 A tiny bit more info: When clicking through the calendar on the Tor blog
 (​https://blog.torproject.org/events/month/201712), I got an error message
 about space being low. Couldn't reproduce, but it still seems like a
 pretty symptomatic event.

 {{{
 Warning: mkdir(): No space left on device in
 Drupal\Component\PhpStorage\FileStorage->createDirectory() (line 157 of
 core/lib/Drupal/Component/PhpStorage/FileStorage.php).
 Warning:
 
rename(/srv/bindings/f9f2c526d24b44d7ba7aa6dbd99e29d2/tmp/rolling/live_27/twig/.F38PtAmo52rpiQgOPThx3rCjQRg,/srv/bindings/f9f2c526d24b44d7ba7aa6dbd99e29d2/tmp/rolling/live_27/twig
 /597322173a1f3_views-
 
view.html.twig_SBN7Lltt1eiGczqO_RklqsLYR/eZcB9mV7uCho4pn6tePHDY0N4l6teDPtUnThCnq6_Vg.php):
 No such file or directory in
 Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage->save() (line 88
 of
 core/lib/Drupal/Component/PhpStorage/MTimeProtectedFastFileStorage.php).
 Can supply screenshot upon request.
 }}}

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

Re: [tor-bugs] #23007 [Webpages/Blog]: Get a second blog maintainer

[Tor Bug Tracker & Wiki]

#23007: Get a second blog maintainer
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by isabela):

 I will try emailing the hosting people, I think I have access to the
 hosting page. Mike could help too, I think.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23008 [Webpages/Blog]: Possible low disk space on tor blog server

[Tor Bug Tracker & Wiki]

#23008: Possible low disk space on tor blog server
---+--
 Reporter:  snoek  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Minor  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 When clicking through the calendar on the Tor blog
 (https://blog.torproject.org/events/month/201712), I got an error message
 about space being low. Couldn't reproduce, but it still seems like a
 pretty symptomatic event.

 {{{
 Warning: mkdir(): No space left on device in
 Drupal\Component\PhpStorage\FileStorage->createDirectory() (line 157 of
 core/lib/Drupal/Component/PhpStorage/FileStorage.php).
 Warning:
 
rename(/srv/bindings/f9f2c526d24b44d7ba7aa6dbd99e29d2/tmp/rolling/live_27/twig/.F38PtAmo52rpiQgOPThx3rCjQRg,/srv/bindings/f9f2c526d24b44d7ba7aa6dbd99e29d2/tmp/rolling/live_27/twig
 /597322173a1f3_views-
 
view.html.twig_SBN7Lltt1eiGczqO_RklqsLYR/eZcB9mV7uCho4pn6tePHDY0N4l6teDPtUnThCnq6_Vg.php):
 No such file or directory in
 Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage->save() (line 88
 of
 core/lib/Drupal/Component/PhpStorage/MTimeProtectedFastFileStorage.php).
 }}}

 Can supply screenshot upon request.

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

Re: [tor-bugs] #23005 [Webpages/Blog]: 'no space left on device' Drupal warning messages

[Tor Bug Tracker & Wiki]

#23005: 'no space left on device' Drupal warning messages
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * cc: snoek (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] #23006 [Core Tor]: Test connection speed

[Tor Bug Tracker & Wiki]

#23006: Test connection speed
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 What is your goal?

 That is, there are all sorts of things that we might measure, and all
 sorts of things users might be curious about, and trying to display each
 of them has a cost in terms of e.g. user confusion.

 The bandwidth you'll get from Tor varies over time, depending mostly on
 congestion inside the Tor network, which impacts round-trip times, which
 impacts flow control, and things are interrelated in complex ways.

 Telling users the bandwidth between them and their first hop is not going
 to mean what some of them think it means.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23007 [Webpages/Blog]: Get a second blog maintainer

[Tor Bug Tracker & Wiki]

#23007: Get a second blog maintainer
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 We try to have two maintainers for every service:
 https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure

 I think only hiro knows how to log in to the blog and fix stuff? Or worse,
 there is no such thing as logging into the blog (i.e. there is only the
 web interface), and fixing things requires filing tickets with the current
 hosting provider? And in that case the right answer is to document how to
 file those tickets, who our contacts are, etc, so somebody else can do
 this process if needed?

 Is Mike this person?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23006 [Core Tor]: Test connection speed

[Tor Bug Tracker & Wiki]

#23006: Test connection speed
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Please figure out a way to show what is my internet connection speed
 between the tor client and the first hop (Guard or bridge).
 Suggestion, maybe deduce the speed of downloading the consensus files and
 display it in the log files.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23005 [Webpages/Blog]: 'no space left on device' Drupal warning messages

[Tor Bug Tracker & Wiki]

#23005: 'no space left on device' Drupal warning messages
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 From irc:
 {{{
  Not sure where to put this info, as there's no #tor-it channel,
 but
 when I was browsing the events calendar on the tor blog, the site is
 displaying 'no space left on device' Drupal warning messages: "Warning:
 mkdir(): No space left on device in Drupal\Component\..."
 }}}

 I'm not able to reproduce immediately, but that doesn't mean there isn't
 some thing somewhere that's full and needs attention.

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

Re: [tor-bugs] #23002 [Applications/Tor Browser Sandbox]: Determine if Tor browser bundle sandbox has been compromised

[Tor Bug Tracker & Wiki]

#23002: Determine if Tor browser bundle sandbox has been compromised
--+
 Reporter:  Dbryrtfbcbhgf |  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

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


Comment:

 This is pointless because all of the firefox components that would be
 protected are exposed within the container as read-only files.

 The only time that anything in a container has write access to it's own
 components is when applying updates, which is done in a different
 container with no network access.  At this time, malicious MAR files with
 valid signatures are entirely beyond the threat model (Though see #22946).

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

Re: [tor-bugs] #23004 [- Select a component]: ccc

[Tor Bug Tracker & Wiki]

#23004: ccc
--+-
 Reporter:  adminco   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by nickm):

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


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

Re: [tor-bugs] #12412 [Applications/Orbot]: Orbot broke using TransPort

[Tor Bug Tracker & Wiki]

#12412: Orbot broke using TransPort
-+-
 Reporter:  isis |  Owner:  n8fr8
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Applications/Orbot   |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  orbot-14.0.3.1, orbot-14.0.4, wtf,   |  Actual Points:
  software-engineering   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by adminco):

 [wiki:dasda]

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

Re: [tor-bugs] #12412 [Applications/Orbot]: Orbot broke using TransPort

[Tor Bug Tracker & Wiki]

#12412: Orbot broke using TransPort
-+-
 Reporter:  isis |  Owner:  n8fr8
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Applications/Orbot   |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  orbot-14.0.3.1, orbot-14.0.4, wtf,   |  Actual Points:
  software-engineering   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by adminco):

 * severity:   => Blocker


Comment:

 ]

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

[tor-bugs] #23004 [- Select a component]: ccc

[Tor Bug Tracker & Wiki]

#23004: ccc
--+-
 Reporter:  adminco   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

Re: [tor-bugs] #23003 [- Select a component]: fff

[Tor Bug Tracker & Wiki]

#23003: fff
-+-
 Reporter:  adminco  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  - Select a component |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  > |
-+-
Changes (by adminco):

 * reviewer:  "> => >


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

[tor-bugs] #23003 [- Select a component]: fff

[Tor Bug Tracker & Wiki]

#23003: fff
--+-
 Reporter:  adminco   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

Re: [tor-bugs] #23003 [- Select a component]: fff

[Tor Bug Tracker & Wiki]

#23003: fff
-+-
 Reporter:  adminco  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  - Select a component |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  "> |
-+-
Changes (by adminco):

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


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

[tor-bugs] #23002 [Applications/Tor Browser Sandbox]: Determine if Tor browser bundle sandbox has been compromised

[Tor Bug Tracker & Wiki]

#23002: Determine if Tor browser bundle sandbox has been compromised
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  yawning
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Applications/Tor Browser |  0.3.2.x-final
  Sandbox|Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Every time tor browser bundle sandbox launcher opens Tor browser bundle,
 it should take a Sha2 hash of Firefox ESR and other internal files and
 compere it to a predetermined hash, taken during the initial launch to
 tell whether it's been compromise, the hash should be saved somewhere
 where a compromise Firefox cannot edit it. If the hash does not match the
 initial hash then it should give a warning to users that it needs to
 delete tor browser bundle and re-download/reinstall tor browser bundle.
 The hash should only be taken of Firefox ESR and other components that the
 user would not be able to change under normal operations.

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

Re: [tor-bugs] #22610 [Applications/Tor Browser]: Tor Browser 7 crashes when cancelling downloads on the external helper app warning

[Tor Bug Tracker & Wiki]

#22610: Tor Browser 7 crashes when cancelling downloads on the external helper 
app
warning
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, tbb-7.0-issues, tbb-  |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 I resolved #22999 as a 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] #22999 [Applications/Tor Browser]: SIGSEGV when cancelling out of a download popup

[Tor Bug Tracker & Wiki]

#22999: SIGSEGV when cancelling out of a download popup
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

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


Comment:

 Replying to [comment:1 cypherpunks]:
 > Seems like a duplicate: #22610

 I agree, at least enough to say "close enough." The website in this ticket
 appears to use a blob URL, which is another type of URL that our current
 patch for #21766 does not handle well.

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

Re: [tor-bugs] #23001 [Webpages/Website]: On the website, in the 'bridges' section, update references from 'obfs3' to 'obfs4'

[Tor Bug Tracker & Wiki]

#23001: On the website, in the 'bridges' section, update references from 
'obfs3' to
'obfs4'
--+-
 Reporter:  snoek |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by snoek):

 Ah, sorry.

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

Re: [tor-bugs] #23001 [Webpages/Website]: On the website, in the 'bridges' section, update references from 'obfs3' to 'obfs4'

[Tor Bug Tracker & Wiki]

#23001: On the website, in the 'bridges' section, update references from 
'obfs3' to
'obfs4'
--+-
 Reporter:  snoek |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 > Also, I noticed that the 'pluggable transport page' on trac suffered
 from the same affliction. I updated it slightly where it matters.

 The paragraph you edited, which I since reverted, is supposed to mention
 obfs2 and obfs3 because it's discussing features/capabilities.

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

Re: [tor-bugs] #20848 [Applications/Tor Browser]: Integrate selfrando into 32bit Linux alpha bundles

[Tor Bug Tracker & Wiki]

#20848: Integrate selfrando into 32bit Linux alpha bundles
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security,|  Actual Points:
  TorBrowserTeam201707R, GeorgKoppen201707   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-security, TorBrowserTeam201707, GeorgKoppen201707 => tbb-
 security, TorBrowserTeam201707R, GeorgKoppen201707
 * status:  new => needs_review


Comment:

 The patch is up for review in our oniongit instance:
 https://oniongit.eu/gk/tor-browser-bundle/merge_requests/2.

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

Re: [tor-bugs] #23001 [Webpages/Website]: On the website, in the 'bridges' section, update references from 'obfs3' to 'obfs4' (was: On the website, in the 'bridges' section, update references to obfs3

[Tor Bug Tracker & Wiki]

#23001: On the website, in the 'bridges' section, update references from 
'obfs3' to
'obfs4'
--+-
 Reporter:  snoek |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

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

[tor-bugs] #23001 [Webpages/Website]: On the website, in the 'bridges' section, update references to obfs3 to obfs4

[Tor Bug Tracker & Wiki]

#23001: On the website, in the 'bridges' section, update references to obfs3 to
obfs4
--+-
 Reporter:  snoek |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I noticed that in the 'bridges' section on the website, the recommended
 default pluggable transport still was obfs3. While elsewhere obfs4 is the
 recommended PT. I guess it's quite minor, but I'd think people get a bit
 jittery when they are presented with slightly off information about what
 obfuscation technique they should actually be using to protect against
 inspection of their anonymous connection.

 So I made a commit (and branch) to remedy this:
 https://github.com/stuij/tor-
 site/commit/ad38186eceabd733efd67d60485aed9da22e3f99

 Pull if you think it's worth the trouble (and I didn't mildly or wholly
 misunderstood something).

 Also, I noticed that the 'pluggable transport page' on trac suffered from
 the same affliction. I updated it slightly where it matters. There's also
 a section on composing pluggable transports where obfs3 is used, but I
 didn't dare touch that bit, as the whole section looks a bit outdated:
 
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Combiningpluggabletransports

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

Re: [tor-bugs] #22999 [Applications/Tor Browser]: SIGSEGV when cancelling out of a download popup

[Tor Bug Tracker & Wiki]

#22999: SIGSEGV when cancelling out of a download popup
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => tbb-crash


Comment:

 Seems like a duplicate: #22610

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

Re: [tor-bugs] #22610 [Applications/Tor Browser]: Tor Browser 7 crashes when cancelling downloads on the external helper app warning (was: Tor Browser 7 crashes when opening a PDF file on my desktop a

[Tor Bug Tracker & Wiki]

#22610: Tor Browser 7 crashes when cancelling downloads on the external helper 
app
warning
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, tbb-7.0-issues, tbb-  |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #22827 [Core Tor/Tor]: Formalise CollecTor spec for sanitised bridge descriptors and put in torspec

[Tor Bug Tracker & Wiki]

#22827: Formalise CollecTor spec for sanitised bridge descriptors and put in
torspec
-+-
 Reporter:  isis |  Owner:  karsten
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-docs, tor-bridges  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 I started a new metrics-web branch for tracking changes to this
 specification document. I can't finish this right now, but I'm planning to
 include more changes and post a link here. If you were planning to work on
 this, better wait another 12 hours. Thanks.

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

Re: [tor-bugs] #22952 [Applications/Tor Browser]: Tor Browser Arabic Fonts Issue !

[Tor Bug Tracker & Wiki]

#22952: Tor Browser Arabic Fonts Issue !
--+---
 Reporter:  sigma4111 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting-fonts  |  Actual Points:
Parent ID:  #18097| Points:
 Reviewer:|Sponsor:
--+---

Comment (by dcf):

 Replying to [comment:11 sigma4111]:
 > 2) thank you Tails OS team 4 times (not single time), because indeed Tor
 browser alone is useless in dealing with such e-library site that all it's
 books are posted as PDF files that are impossible to be downloaded over
 Tor network by using Tor browser outside Tails OS...

 The PDF download issue sounds like a known bug: #22471

 You can work around the bug by right-clicking and "Save As..." instead of
 using the download button.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  needs_revision
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * status:  needs_review => needs_revision


Comment:

 Review of the patches from comment:2:

 It's better if the WebSocket struct exposes the entire client http.Request
 structure, not just Request.URL. That way, consumers can also inspect the
 headers etc. Compare with
 [https://godoc.org/golang.org/x/net/websocket#Conn.Request Conn.Request()]
 in the x/net websocket package. (You can make it a simple member access,
 doesn't have to be a function call.)

 Completely delete the path check in websocket, don't just comment it out.

 Run `go fmt`.

 About the client address:
  * There should be some validation of `client_ip`, such as parsing with
 [https://golang.org/pkg/net/#ParseIP net.ParseIP], before passing the
 string into tor.
  * The ExtORPort USERADDR command
 [https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-
 control-ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n72 is
 documented] to take an addr:port string, not just an IP address. So
 snowflake-server needs to add a dummy port number (using
 [https://golang.org/pkg/net/#JoinHostPort net.JoinHostPort]) before giving
 the string to tor. Alternately, rename `client_ip` to `client_addr` and
 have it contain the entire addr:port string.
* If tor is accepting a plain IP address for USERADDR, it's a bug in
 tor or in the documentation, and we need to file a separate bug.
  * How does client_ip handle IPv6 addresses? We need to decide whether
 IPv6 addresses will have square brackets (if the port is included, then
 yes; if the port is not included, then probably no) and document it at
 least in a comment.

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

Re: [tor-bugs] #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:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Hooman is working on patches to address this.

 websocket patch to retain the request URL and remove the restriction on
 paths:
   https://gitweb.torproject.org/pluggable-
 
transports/websocket.git/commit/?h=bug18628=0446621630483a656f179963ca77451f04aeaf01
 snowflake patch to pass the `client_ip` from the websocket request URL
 query into pt.DialOr:
 
https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=0c958d8ffba0c117fb4768133afcbd4d56f61d1f

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

Re: [tor-bugs] #21936 [Internal Services/Tor Sysadmin Team]: turn off onionperf.torproject.org

[Tor Bug Tracker & Wiki]

#21936: turn off onionperf.torproject.org
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Done now, both papillar and ferrinii (onionperf and torperf)

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

Re: [tor-bugs] #21936 [Internal Services/Tor Sysadmin Team]: turn off onionperf.torproject.org

[Tor Bug Tracker & Wiki]

#21936: turn off onionperf.torproject.org
-+
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

[tor-bugs] #23000 [HTTPS Everywhere]: HTTPS Everywhere does not work in current versions of SlimJet

[Tor Bug Tracker & Wiki]

#23000: HTTPS Everywhere does not work in current versions of SlimJet
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Last several versions over many weeks of SlimJet Chrominum loads OK from
 webstore and puts icon on toolbar but attempting to reach any site only
 hangs until you disable extension

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