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.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, security  |  Actual Points:
Parent ID:  #18856  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * keywords:  tor-spec, security-maybe => tor-spec, security
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 I don't know how to classify this security issue.
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy

 Is it low severity: "A defense-in-depth mechanism provides less defense-
 in-depth than it should"?
 Or is it high severity: A potential denial of service attack that affects
 clients and hidden services?
 (I split the security policy clarification off into #22962.)

 Should we fix it in 0.3.1?
 Should we fill all cells with random bytes? (Split off into #22963.)

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

Re: [tor-bugs] #22963 [Core Tor/Tor]: Make relay integrity digests harder to guess by padding cells with random bytes

[Tor Bug Tracker & Wiki]

#22963: Make relay integrity digests harder to guess by padding cells with 
random
bytes
--+
 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:  security  |  Actual Points:
Parent ID:  #22948| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #22948


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22963 [Core Tor/Tor]: Make relay integrity digests harder to guess by padding cells with random bytes

[Tor Bug Tracker & Wiki]

#22963: Make relay integrity digests harder to guess by padding cells with 
random
bytes
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  security
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The tor spec says we should put random bytes in padding cells:
 https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1534

 But we don't currently do this (see #22948).
 And we don't put random bytes in other cells.

 This makes it easier to guess the circuit integrity digest, which makes
 some DoS and malleability attacks easier.

 Should we pad all cells with random bytes?

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

[tor-bugs] #22962 [Core Tor/Tor]: Clarify the security severity of issues that make denial of service easier

[Tor Bug Tracker & Wiki]

#22962: Clarify the security severity of issues that make denial of service 
easier
--+
 Reporter:  teor  |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #22948
   Points:|   Reviewer:
  Sponsor:|
--+
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy

 In #22948, we discovered that the relay integrity digest was easier to
 guess than it should be. This makes the following classes of attacks
 easier:
 * sending bandwidth and guessing the integrity digest, and
 * modifying cells and manipulating the integrity digest.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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, security-maybe  |  Actual Points:
Parent ID:  #18856| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:4 teor]:
 > Is there any reason for padding cells to have random payloads?

 Yes, the end-to-end circuit digest includes the payloads of all the cells
 received, and random payloads are not easy to predict. For example, it
 would reduce vulnerability to attacks where one side produces a valid
 digest without actually receiving the cells that it is acknowledging.

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

Re: [tor-bugs] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

[Tor Bug Tracker & Wiki]

#21830: Copying large text from web console leaks to /tmp
--+--
 Reporter:  gk|  Owner:  neillm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neillm):

 * owner:  tbb-team => neillm


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

Re: [tor-bugs] #18891 [Core Tor/Tor]: Make it clear that Address only works for IPv4

[Tor Bug Tracker & Wiki]

#18891: Make it clear that Address only works for IPv4
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy, doc |  Actual Points:
Parent ID:  #18892| Points:
 Reviewer:|Sponsor:
--+

Comment (by chelsieanayas):

 Just a smile and the rain is gone Can hardly believe it, yeah. There's an
 angel standing next to me. Reaching for my heart Just a smile and there's
 no way back .Can hardly believe it, yeah But there's an angel calling me.
 Reaching for my heart I know that I'll be okay now. This time, it's real I
 lay my love on you It's all I wanna do Every time I breathe I feel brand
 new You open up my heart Show me all your love and walk right through As I
 lay my love on you. [http://dumbways-todie.com dumb ways to die] } [http
 ://fireboy-andwatergirl.com fireboy and watergirl 4]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:4 sigma4111]:
 > I can supply you by files for Arabic fonts (like Arial), if you like ...
 >
 > Currently, display of this site is really uggly.

 We wouldn't be able to use Arial exactly, because it is not available
 under a free license. For the same reason, Arial will never be a part of
 Tails or Debian.

 You can see what fonts are being used this way:
  1. Right-click on the text.
  2. Choose "Inspect Element" from the menu that appears.
  3. A new panel will open on the browser and there will be a tab labeled
 "Fonts". (For me it is on the right side.)
 We might be able to make some progress if you can do that on a browser
 where the text looks good, and tell us what font is being 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

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, security-maybe  |  Actual Points:
Parent ID:  #18856| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:4 teor]:
 > Then this is probably ok in 0.3.1.
 >
 > Is there any reason for padding cells to have random payloads?
 > Does it make it harder for adversaries to decrypt them?
 > (If so, should we fill every cell with random data rather than zeroes?
 > Or does that make it harder to add extra fields to cells?)
 >
 > On the other hand, are we worried that implementations with low quality
 PRNGs will leak state by doing this?
 >
 > I suggest we update the spec to say that padding cells should be filled
 with zero bytes, just like other cells, unless there is some compelling
 reason to use random bytes.
 This is not something to decide, permanently, in a rush.

 Intuitively, thinking about what (very far future attacks) could happen,
 rather than what is known to already be possible, random or at least
 pseudo-random data seems better. And there are simple ways of generating
 pseudorandom data that is at least better against imaginable future
 cryptanalysis than all zeroes, which consume very little entropy, like
 repeated hashing, or (perhaps potentially less good) a stream cipher with
 a random key, etc.

 (Why potentially less good? Arguably it is consistent with $agency's
 agenda to allow 'hash functions' to be developed and adopted that have the
 best security properties possible, but the same may not be true of
 'ciphers'.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22961 [Core Tor/Tor]: Should tor-spec say that nodes MUST NOT use TLS compression?

[Tor Bug Tracker & Wiki]

#22961: Should tor-spec say that nodes MUST NOT use TLS compression?
--+
 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 security
Actual Points:|  Parent ID:  #18856
   Points:|   Reviewer:
  Sponsor:|
--+
 In general, it's unsafe to compress attacker-controlled data and secret
 data together in the same blocks, because attackers can use compressed
 data size to discover the secret (as in the CRIME attack).

 Discovered as part of #22948.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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, security-maybe  |  Actual Points:
Parent ID:  #18856| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:  Tor: 0.3.1.1-alpha =>
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Then this is probably ok in 0.3.1.

 Is there any reason for padding cells to have random payloads?
 Does it make it harder for adversaries to decrypt them?
 (If so, should we fill every cell with random data rather than zeroes?
 Or does that make it harder to add extra fields to cells?)

 On the other hand, are we worried that implementations with low quality
 PRNGs will leak state by doing this?

 I suggest we update the spec to say that padding cells should be filled
 with zero bytes, just like other cells, unless there is some compelling
 reason to use random bytes.

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

Re: [tor-bugs] #22791 [Core Tor/Tor]: Prop 224 encrypted public key

[Tor Bug Tracker & Wiki]

#22791: Prop 224 encrypted public key
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:
 Type:  defect | Status:  reopened
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by Dbryrtfbcbhgf):

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


Comment:

 Thanks for the information.

  If you discover what "ciphertext  = .onion" can a  Rondevoo points block
 access to ciphertext  that they have discovered.
 Example.  ciphertext{ YTitcitfyitcyyitvygiviguuivg} =
 securitysitegvj.onion} can the Rondevoo node Block all connections trying
 to go to [YTitcitfyitcyyitvygiviguuivg]



  You can close the ticket after this it's answered thank you.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by isis):

 Couple things I realised I should do:

  * There should be a 'version' field in every JSON thing so that we can
 add things later if we need to.
  * There should probably be a 'type' field in every JSON thing so that we
 know which part of the protocol it is.
  * The JSON in the `data` URL parameter should be en-/de- coded as URL-
 safe base64. (And it should probably just be in the body of the POST
 request?)

 Also, in order to conform to [http://jsonapi.org/format/ the JSON API
 standard], I need to change the following things:

  * The content-type apparently needs to be `application/vnd.api+json` (not
 `application/json`).
  * "Servers MUST respond with a 415 Unsupported Media Type status code if
 a request specifies the header Content-Type: application/vnd.api+json with
 any media type parameters."
  * "Servers MUST respond with a 406 Not Acceptable status code if a
 request’s Accept header contains the JSON API media type and all instances
 of that media type are modified with media type parameters."
  * "A document MUST contain at least one of the following top-level
 members:
   - `data`: the document’s “primary data”
   - `errors`: an array of error objects
   - `meta`: a meta object that contains non-standard meta-
 information."
  * "The members `data` and `errors` MUST NOT coexist in the same
 document."
  * "Primary data MUST be […] a single resource object […]
  * "A resource object MUST contain at least the following top-level
 members:
   - `id`
   - `type`
Exception: The `id` member is not required when the resource object
 originates at the client and represents a new resource to be created on
 the server."
  * "In addition, a resource object MAY contain any of these top-level
 members:
   - `attributes`: an attributes object representing some of the
 resource’s data."
  * "The value of the attributes key MUST be an object (an “attributes
 object”). Members of the attributes object (“attributes”) represent
 information about the resource object in which it’s defined. Attributes
 may contain any valid JSON value."
  * "A JSON API document MAY include information about its implementation
 under a top level `jsonapi` member. If present, the value of the jsonapi
 member MUST be an object (a “jsonapi object”). The jsonapi object MAY
 contain a version member whose value is a string indicating the highest
 JSON API version supported."
  * "A server MUST return 403 Forbidden in response to an unsupported
 request to create a resource with a client-generated ID." (for the POST
 part)
  * "Error objects provide additional information about problems
 encountered while performing an operation. Error objects MUST be returned
 as an array keyed by errors in the top level of a JSON API document.
An error object MAY have the following members:
   - `id`: a unique identifier for this particular occurrence of the
 problem.
   - `links`: a links object containing the following members:
- `about`: a link that leads to further details about this
 particular occurrence of the problem.
   - `status`: the HTTP status code applicable to this problem,
 expressed as a string value.
   - `code`: an application-specific error code, expressed as a string
 value.
   - `title`: a short, human-readable summary of the problem that
 SHOULD NOT change from occurrence to occurrence of the problem, except for
 purposes of localization.
   - `detail`: a human-readable explanation specific to this occurrence
 of the problem. Like title, this field’s value can be localized.
   - `source`: an object containing references to the source of the
 error, optionally including any of the following members:
 - `pointer`: a JSON Pointer [RFC6901] to the associated entity
 in the request document [e.g. "/data" for a primary data object, or
 "/data/attributes/title" for a specific attribute].
 - `parameter`: a string indicating which URI query parameter
 caused the error.
   - `meta`: a meta object 

Re: [tor-bugs] #22939 [Applications/Tor Messenger]: Can't configure my OTR key

[Tor Bug Tracker & Wiki]

#22939: Can't configure my OTR key
+-
 Reporter:  cypherpunks |  Owner:
 Type:  task| Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Can you first confirm this works for you w/o disabling Tor Launcher?
 That bit seems independent of the problem you're reporting.

 Can you provide some system information?  OS/platform

 Are there any logs in the error console?

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

Re: [tor-bugs] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-+-
 Reporter:  catalyst |  Owner:
 |  patrickod
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci testing|  Actual Points:  .5
  best-practice unit-testing new-developers  |
  travis review-group-21 |
Parent ID:   | Points:  .5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by isis):

 * keywords:
 continuous-integration ci testing best-practice unit-testing new-
 developers travis
 =>
 continuous-integration ci testing best-practice unit-testing new-
 developers travis review-group-21


Comment:

 Selfishly putting tickets I care about in review-group-21. :)

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

Re: [tor-bugs] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-+-
 Reporter:  catalyst |  Owner:
 |  patrickod
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci testing|  Actual Points:  .5
  best-practice unit-testing new-developers  |
  travis |
Parent ID:   | Points:  .5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by isis):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #22229 [Applications/Tor Messenger]: Compile Linux 64bits versions of Tor Messenger with Selfrando?

[Tor Bug Tracker & Wiki]

#9: Compile Linux 64bits versions of Tor Messenger with Selfrando?
+-
 Reporter:  blockflare  |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Building Tor Messenger with tor-browser-build.git is happening in #22005

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

Re: [tor-bugs] #22005 [Applications/Tor Messenger]: Move to ESR 52

[Tor Bug Tracker & Wiki]

#22005: Move to ESR 52
+--
 Reporter:  arlolra |  Owner:  sukhbir
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

 * owner:   => sukhbir
 * 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] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-+-
 Reporter:  catalyst |  Owner:
 |  patrickod
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci testing|  Actual Points:  .5
  best-practice unit-testing new-developers  |
  travis |
Parent ID:   | Points:  .5
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by isis):

 Replying to [comment:15 isis]:
 > Replying to [comment:14 catalyst]:
 > > Thanks!  This is very useful to have.  Technically this looks mostly
 good to me, with a few minor (mostly documentation) nits.
 > >
 > > I have a GitHub account with Travis CI enabled.  I confirm that tests
 on `bug22636_0.3.1` [https://travis-ci.org/tlyu/tor/builds/254404828 pass]
 and tests on `bug22636_0.2.4` [https://travis-
 ci.org/tlyu/tor/builds/254484617 pass].
 > >
 > > I'm trying to understand the differences between this and our Jenkins
 configurations.  It looks like our Jenkins config turns on `--disable-
 silent-rules` to get a bit more verbosity on the compile lines; should we
 do likewise?
 >
 > Yes, this is a good idea.

 Okay, this is done in
 
[https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug22636=63928a0b1294324249c69c8165e13c808e11a335
 commit] `63928a0b1294324249c69c8165e13c808e11a335`.

 > > Jenkins also does `make check` instead of `make check-spaces` and
 `make test`.  Is there some reason to not do `make check`?  I think that
 doesn't significantly increase the run time, but I haven't measured the
 difference yet.
 >
 > This is probably a good idea, as it tests more. The output might be a
 bit tricky to get, because the way it is configured right now, if some
 step fails, the whole CI build will fail fast.  So e.g. if compilation
 failed, don't waste more time testing.  Also if `make check-spaces` fails,
 your commit needs to be fixed up anyway, so again don't bother wasting
 time testing.  Whereas if we run `make check` it does all this in one go,
 and if it fails some step, it only reports that at the end of everything.
 Also, all the output that we'd need in order to see what failed gets
 shoved into a file (but possibly I can get that output with a `after-
 script` stanza?).

 This is also done in
 
[https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug22636=63928a0b1294324249c69c8165e13c808e11a335
 commit] `63928a0b1294324249c69c8165e13c808e11a335`.

 > > Commenting the `.travis.yml` with brief explanations of these choices
 might be a good idea.  Also, squashing the commits somewhat would be good.
 Some of the commit messages, like the ones involving Rust config choices,
 might work better as comments in `.travis.yml`.
 >
 > Yes, this is a great idea.

 Done in
 
[https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug22636=ca4168ea98818b1f291449596a7885671aefeded
 commit] `ca4168ea98818b1f291449596a7885671aefeded`.

 I'll squash all the branches once these new changes are approved.

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

Re: [tor-bugs] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-+-
 Reporter:  catalyst |  Owner:
 |  patrickod
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci testing|  Actual Points:  .5
  best-practice unit-testing new-developers  |
  travis |
Parent ID:   | Points:  .5
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by isis):

 Replying to [comment:14 catalyst]:
 > Thanks!  This is very useful to have.  Technically this looks mostly
 good to me, with a few minor (mostly documentation) nits.
 >
 > I have a GitHub account with Travis CI enabled.  I confirm that tests on
 `bug22636_0.3.1` [https://travis-ci.org/tlyu/tor/builds/254404828 pass]
 and tests on `bug22636_0.2.4` [https://travis-
 ci.org/tlyu/tor/builds/254484617 pass].
 >
 > I'm trying to understand the differences between this and our Jenkins
 configurations.  It looks like our Jenkins config turns on `--disable-
 silent-rules` to get a bit more verbosity on the compile lines; should we
 do likewise?

 Yes, this is a good idea.

 > Jenkins also does `make check` instead of `make check-spaces` and `make
 test`.  Is there some reason to not do `make check`?  I think that doesn't
 significantly increase the run time, but I haven't measured the difference
 yet.

 This is probably a good idea, as it tests more. The output might be a bit
 tricky to get, because the way it is configured right now, if some step
 fails, the whole CI build will fail fast.  So e.g. if compilation failed,
 don't waste more time testing.  Also if `make check-spaces` fails, your
 commit needs to be fixed up anyway, so again don't bother wasting time
 testing.  Whereas if we run `make check` it does all this in one go, and
 if it fails some step, it only reports that at the end of everything.
 Also, all the output that we'd need in order to see what failed gets
 shoved into a file (but possibly I can get that output with a `after-
 script` stanza?).

 > Commenting the `.travis.yml` with brief explanations of these choices
 might be a good idea.  Also, squashing the commits somewhat would be good.
 Some of the commit messages, like the ones involving Rust config choices,
 might work better as comments in `.travis.yml`.

 Yes, this is a great idea.

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

Re: [tor-bugs] #22769 [Core Tor/Tor]: Investigate the reproducibility of Rust binaries

[Tor Bug Tracker & Wiki]

#22769: Investigate the reproducibility of Rust binaries
+
 Reporter:  isis|  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, SponsorZ  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:  SponsorZ
+

Comment (by infinity0):

 Sure that's OK. I'll just note though that the ticket linked ''is'' about
 reproducibility of rustc itself (the "extremely deep rabbit hole"), which
 ''probably'' is a super-set of the original goal.

 For example, cargo is [[https://tests.reproducible-builds.org/debian/rb-
 pkg/buster/amd64/cargo.html|already reproducible (when not varying build-
 paths)]]. However, it's possible that compilation of cargo and rustc only
 exercise "some parts" of rustc, whereas more complex programs ''might''
 exercise rustc in different ways that reveal other unreproducible
 behaviour. You'll have to run tests and see.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22960 [Applications/Tor Browser]: Tor Browser is leaking IPC messages

[Tor Bug Tracker & Wiki]

#22960: Tor Browser is leaking IPC messages
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-e10s, tbb-crash,
 Severity:  Normal   |  tbb-oom
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Sometimes something happens during load of a new page in a tab, and then
 other tabs show loading circles instead of pages, and nothing happens,
 except increase of
 {{{
 1,696 (100.0%) -- queued-ipc-messages
 └──1,696 (100.0%) ── content-parent(???, pid=3796, open channel,
 0x133abab8, refcnt=46)
 }}}
 which leads to OOM of the main process. (Killing child process brings TBB
 back to mind.)

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

Re: [tor-bugs] #22769 [Core Tor/Tor]: Investigate the reproducibility of Rust binaries

[Tor Bug Tracker & Wiki]

#22769: Investigate the reproducibility of Rust binaries
+
 Reporter:  isis|  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, SponsorZ  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:  SponsorZ
+
Changes (by isis):

 * cc: infinity0 (added)


Comment:

 The upstream issue that Alex mentioned is being worked on quite a lot by
 Ximin, so I'm adding him to the CC. (Hope that's okay, and feel free to
 unsubscribe, Ximin!)

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

Re: [tor-bugs] #7743 [Core Tor/Tor]: Avoid needless wasted space in cells

[Tor Bug Tracker & Wiki]

#7743: Avoid needless wasted space in cells
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, bwbug, nagle, |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * keywords:  tor-relay, bwbug, nagle, sponsor8-maybe, review-group-21 =>
 tor-relay, bwbug, nagle, sponsor8-maybe


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

Re: [tor-bugs] #7743 [Core Tor/Tor]: Avoid needless wasted space in cells

[Tor Bug Tracker & Wiki]

#7743: Avoid needless wasted space in cells
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, bwbug, nagle, |  Actual Points:
  sponsor8-maybe, review-group-21|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #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:  teor
 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:  review-group-21  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #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:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  review-group-21  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 setting owner

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

Re: [tor-bugs] #22915 [Core Tor/Tor]: clang 4.0 double promotion warnings in clamp_double_to_int64()

[Tor Bug Tracker & Wiki]

#22915: clang 4.0 double promotion warnings in clamp_double_to_int64()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-21  |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => 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] #22915 [Core Tor/Tor]: clang 4.0 double promotion warnings in clamp_double_to_int64()

[Tor Bug Tracker & Wiki]

#22915: clang 4.0 double promotion warnings in clamp_double_to_int64()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-21  |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * owner:   => nickm
 * status:  needs_review => accepted


Comment:

 setting owner

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22810, #17639, #7743, #20247, ...

[Tor Bug Tracker & Wiki]

Batch modification to #22810, #17639, #7743, #20247, #22862, #22885, #22895, 
#22915 by nickm:
keywords to review-group-21

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22883, #22927

[Tor Bug Tracker & Wiki]

Batch modification to #22883, #22927 by nickm:
keywords to review-group-21

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

Re: [tor-bugs] #22499 [Applications/Tor Browser]: Decide what we want to do with python obfsproxy and fteproxy pluggable transports

[Tor Bug Tracker & Wiki]

#22499: Decide what we want to do with python obfsproxy and fteproxy pluggable
transports
--+---
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201707  |  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 I am not sure how much time this conversion would take, but maybe it is
 not that much. Being able to compare builds from rbm and Gitian sounds
 like a good idea, to make sure nothing was forgotten.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  tbb-gitian TorBrowserTeam201707R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 In `tor-browser-build.git`, this is done in commit
 dac7649db2b8567c8ace185dcdac56edd098d55b.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by boklm):

 I opened #22959 for applying the same changes to tor-browser-build.git.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22959 [Applications/Tor Browser]: Merge Snowflake for mac, in rbm tor-browser

[Tor Bug Tracker & Wiki]

#22959: Merge Snowflake for mac, in rbm tor-browser
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201707,
 Severity:  Normal   |  snowflake
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We need to apply the changes from #22831 to tor-browser-build.git.

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

Re: [tor-bugs] #22884 [Applications/Tor Browser]: about:tor page is not showing up in non-e10s mode after fix for #18913 landed

[Tor Bug Tracker & Wiki]

#22884: about:tor page is not showing up in non-e10s mode after fix for #18913
landed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201707, tbb-torbutton  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  assigned => needs_information


Comment:

 gk: what do you think of the idea of whitelisting all about: pages?
 (assuming that is possible) Too risky, or a good idea?

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

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

 Hi again.

 1) I'm not the owner of this site. I'm just visitor & downloader from it.

 2) The issue is related to Tor browser itself. You may had idea that it is
 not related to Tor itself may be due to screenshot which show that I view
 it by Tails, isn't it the case ? No, I contact Tails 1st & they inform me
 that it is not related to Tails but to Tor itself & recommend me to
 contact you & open a bug about it.

 3) I invistigated issue: it is existing on Tor browser on Debian, Tails,
 CentOS, openSUSE, Ubuntu, Windows 8, Windows 8.1, Windows 10. So, it is
 not related to OS. It is specific to Tails.

 4) During my contact with Tails support, I contact owners of this site on
 their e-mail that posted on their page. I asked them specifically about
 default fonts used by them & their replay was: [most contents of this
 site in "Arial" & fiew "Time new Romman"... Google sites editor has option
 to select default fonts for contents ... we using "Arial" as default fonts
 ...]

 ---

 Now you like me to supply you by fonts 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

Re: [tor-bugs] #22940 [Core Tor/Tor]: prop224: HS revision counter should persist after service reboot

[Tor Bug Tracker & Wiki]

#22940: prop224: HS revision counter should persist after service reboot
+
 Reporter:  asn |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  #20657  | Points:  1
 Reviewer:  |Sponsor:  SponsorR-can
+

Comment (by nickm):

 {{{
 19:47 <+nickm> asn: Anti-tamper database research: Inference control
 techniques.
  Technical Report EECS 433 Final Report, Case Western Reserve University,
 Novemb
 er 2002
 19:47 <+nickm> I yoinked the scheme from
 http://cryptowiki.net/index.php?title=O
 rder-preserving_encryption
 }}}

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

Re: [tor-bugs] #22940 [Core Tor/Tor]: prop224: HS revision counter should persist after service reboot

[Tor Bug Tracker & Wiki]

#22940: prop224: HS revision counter should persist after service reboot
+
 Reporter:  asn |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  #20657  | Points:  1
 Reviewer:  |Sponsor:  SponsorR-can
+

Comment (by asn):

 Replying to [comment:3 nickm]:
 > Attached is a very silly order-preserving encryption example based on
 the scheme I've seen attributed to Bebek 02.

 What's the bebek 02 paper btw? Is it `Anti-Tamper Databases: Inference
 control techniques` or another one?

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

Re: [tor-bugs] #22897 [Core Tor/Tor]: Revise privcount patch series to use trace modules (was: Revise privcount patch series to use trace/lttng modules)

[Tor Bug Tracker & Wiki]

#22897: Revise privcount patch series to use trace modules
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  privcount |  Actual Points:
Parent ID:  #22955| Points:
 Reviewer:|Sponsor:  SponsorQ-can
--+

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

 Replying to [comment:4 sigma4111]:
 > I not sure how you like me to help ? I understood - please correct to me
 - Tor not allowed to use system fonts so as to protect from fingerprint.
 This mean - please correct to me - it "Arial" is used from within Tor (by
 being one of Tor owen built-in set of fonts) then no risk, but if used
 from outside Tor (from system fonts) it will be risky. For that, we need
 to add "Arial" to Tor owen built-in set of fonts to be one of them by
 default ? Is this what you plan to do, or something else ?
 >
 > I can supply you by files for Arabic fonts (like Arial), if you like ...

 The right way to do this is to provide your own fonts on that website (if
 you're the website owner) that get loaded.

 In any case, this does not look like an issue with the Tor Browser.

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by nickm):

 Here's the report:
 {{{
 Unable to unlink ".\\Data\\Tor\\LocalState\\diff-cache/1001" while
 removing file: Permission denied
 tor_bug_occurred_(): Bug: consdiffmgr.c:1289: store_multiple: Non-fatal
 assertion !(ent == NULL) failed. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
 Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at
 consdiffmgr.c:1289. (Stack trace not available) (on Tor 0.3.1.4-alpha
 fab91a290ded3e74)
 tor_bug_occurred_(): Bug: consdiffmgr.c:328: cdm_diff_ht_purge: Non-fatal
 assertion !((*diff)->entry == NULL) failed. (on Tor 0.3.1.4-alpha
 fab91a290ded3e74)
 Bug: Non-fatal assertion !((*diff)->entry == NULL) failed in
 cdm_diff_ht_purge at consdiffmgr.c:328. (Stack trace not available) (on
 Tor 0.3.1.4-alpha fab91a290ded3e74)
 eventdns: All nameservers have failed
 }}}

 So this issues is still present in 0.3.1.4-alpha

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

Re: [tor-bugs] #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.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, security-maybe  |  Actual Points:
Parent ID:  #18856| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 FWIW, we always disable TLS compression, since CRIME was discovered.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

[Tor Bug Tracker & Wiki]

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 It took a bit longer to respond to your comment 5, but here it comes:
  - The following is entirely unrelated to the given patch, but can you try
 to change your Git commit messages to follow the 50/72 rule? That is, the
 first line has no more than 50 characters (unless that's just too hard, in
 which case 60 are still okay), the next line is blank, and all remaining
 lines are wrapped at 72 characters with newlines added between paragraphs.
 And can you write the first line using the imperative, as in "Add sync
 functionality for tpf files." rather than "Implements XY"? Again, this is
 unrelated to this specific commit, but just like we're trying to use a
 common code style we should aim for using a common commit message style.
 Sorry for the nitpick. :)
  - Can you add a change log entry for this change?
  - Should we put out a metrics-lib 2.1.0 first towards the end of the
 month, so that we don't have to require a -dev version in the next
 released CollecTor?
  - Can we keep the old capitalization of OnionPerf in the configs? It
 seems that's what Rob used. It also means fewer changes to the code.
  - Typo: "Instantiate", not "Instanciate".
  - The line `byte[] db = desc.getRawDescriptorBytes();` in
 `SyncPersistence` is probably still left over from testing. This method
 has become really expensive, so we should be careful not to call it more
 often than necessary.
  - I'd like to avoid that we handle descriptors differently depending on
 whether we download them from an OnionPerf host vs. synchronize them from
 a CollecTor host. And I believe that the approach taken in this
 synchronization patch makes more sense than the strict validation approach
 taken in the download part. But maybe we can first take a step back and
 look at all the other modules and find a common approach for all or at
 least most of them. Let's have this discussion first and then merge this
 patch if it still does what we think should be done. Does that make sense?

 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] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-+-
 Reporter:  catalyst |  Owner:
 |  patrickod
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci testing|  Actual Points:  .5
  best-practice unit-testing new-developers  |
  travis |
Parent ID:   | Points:  .5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Thanks!  This is very useful to have.  Technically this looks mostly good
 to me, with a few minor (mostly documentation) nits.

 I have a GitHub account with Travis CI enabled.  I confirm that tests on
 `bug22636_0.3.1` [https://travis-ci.org/tlyu/tor/builds/254404828 pass]
 and tests on `bug22636_0.2.4` [https://travis-
 ci.org/tlyu/tor/builds/254484617 pass].

 I'm trying to understand the differences between this and our Jenkins
 configurations.  It looks like our Jenkins config turns on `--disable-
 silent-rules` to get a bit more verbosity on the compile lines; should we
 do likewise?  Jenkins also does `make check` instead of `make check-
 spaces` and `make test`.  Is there some reason to not do `make check`?  I
 think that doesn't significantly increase the run time, but I haven't
 measured the difference yet.

 Commenting the `.travis.yml` with brief explanations of these choices
 might be a good idea.  Also, squashing the commits somewhat would be good.
 Some of the commit messages, like the ones involving Rust config choices,
 might work better as comments in `.travis.yml`.

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

Re: [tor-bugs] #22947 [Webpages/Blog]: Possible Security Issue (Information Disclosure) with Drupal on blog.torproject.org

[Tor Bug Tracker & Wiki]

#22947: Possible Security Issue (Information Disclosure) with Drupal on
blog.torproject.org
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  security   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hiro):

 I have been hunting down this but for a while, since it has been reported
 a few times. It is difficult to understand what's happening since it
 doesn't show up in the logs. I have a ticket open with pantheon to check
 if they could see something in the logs I wasn't able to spot. For the
 moment nothing is showing :(. Will see if I can get more info. My guess is
 that when I update the blog this error comes along and some of the modules
 is responsible for it (or maybe is some session issue).

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

Re: [tor-bugs] #22820 [Core Tor/Tor]: Give the Exit flag to Exits that use the secure IRC port 6697

[Tor Bug Tracker & Wiki]

#22820: Give the Exit flag to Exits that use the secure IRC port 6697
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  needs-proposal tor-dirauth intro  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Hi Igor,

 Please re-send your email to tor-...@lists.torproject.org.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22137, #16678, #19479, #21830

[Tor Bug Tracker & Wiki]

Batch modification to #22137, #16678, #19479, #21830 by mcs:
cc to brade,mcs

--
Tickets URL: 

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

Re: [tor-bugs] #22907 [Core Tor/Tor]: Investigate using cargo-vendor for offline dependencies

[Tor Bug Tracker & Wiki]

#22907: Investigate using cargo-vendor for offline dependencies
-+-
 Reporter:  isis |  Owner:
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, tor-build  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  SponsorZ
-+-
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #22906 [Core Tor/Tor]: We might not want to commit Cargo.lock files

[Tor Bug Tracker & Wiki]

#22906: We might not want to commit Cargo.lock files
-+--
 Reporter:  isis |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-build  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  SponsorZ
-+--
Changes (by chelseakomlo):

 * cc: chelseakomlo (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

[tor-bugs] #22958 [Webpages/Website]: Update website FAQ about padding defenses

[Tor Bug Tracker & Wiki]

#22958: Update website FAQ about padding defenses
--+-
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  website
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Someone in the blog pointed out that our FAQ is quite negative towards
 padding, even tho the latest tor actually does send netflow padding:
 https://blog.torproject.org/comment/269842#comment-269842

 We should probs update the FAQ to avoid spreading confusion:
 https://www.torproject.org/docs/faq.html.en#SendPadding

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

 Hi. Thank you for your kind replay & attantion !

 I do not know name of font currently used by Tor to display contents of
 this site. I attached screenshot. See it to verify it's type.

 I not sure how you like me to help ? I understood - please correct to me -
 Tor not allowed to use system fonts so as to protect from fingerprint.
 This mean - please correct to me - it "Arial" is used from within Tor (by
 being one of Tor owen built-in set of fonts) then no risk, but if used
 from outside Tor (from system fonts) it will be risky. For that, we need
 to add "Arial" to Tor owen built-in set of fonts to be one of them by
 default ? Is this what you plan to do, or something else ?

 I can supply you by files for Arabic fonts (like Arial), if you like ...

 Currently, display of this site is really uggly.

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

Re: [tor-bugs] #22735 [Core Tor/Tor]: prop224: HS desc overlap period func uses absolute times instead of slots

[Tor Bug Tracker & Wiki]

#22735: prop224: HS desc overlap period func uses absolute times instead of 
slots
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  task | Status:  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-hs spec-conformance  |  Actual Points:
Parent ID:  #20657   | Points:  1
 Reviewer:   |Sponsor:  SponsorR-
 |  can
-+-

Comment (by asn):

 Another problem here is that our current time period function
 `hs_get_time_period_num()` also uses absolute numbers instead of a slot
 system, which means it does not work exactly as intended in chutney (time
 periods rotate too slow).

 Will probably have to fix this first before fixing the root issue here.

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

Re: [tor-bugs] #22947 [Webpages/Blog]: Possible Security Issue (Information Disclosure) with Drupal on blog.torproject.org

[Tor Bug Tracker & Wiki]

#22947: Possible Security Issue (Information Disclosure) with Drupal on
blog.torproject.org
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  security   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * 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] #22956 [Internal Services/Service - lists]: Please allow IgorMitrofanov to post to tor-dev@lists

[Tor Bug Tracker & Wiki]

#22956: Please allow IgorMitrofanov to post to tor-dev@lists
---+---
 Reporter:  teor   |  Owner:  qbi
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID:  #22820 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by qbi):

 * status:  needs_information => closed
 * resolution:   => not a bug


Comment:

 Please tell Igor that the correct address for tor-dev@ is tor-
 d...@lists.torproject.org. See https://lists.torproject.org/cgi-
 bin/mailman/listinfo/tor-dev .
 He wrote to …@torproject.org.

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

Re: [tor-bugs] #22956 [Internal Services/Service - lists]: Please allow IgorMitrofanov to post to tor-dev@lists

[Tor Bug Tracker & Wiki]

#22956: Please allow IgorMitrofanov to post to tor-dev@lists
---+---
 Reporter:  teor   |  Owner:  qbi
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22820 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi Tim, tor-dev@ is an open list. Anyone can subscribe or post to it.
 Leading causes of bounces are due to either not subscribing or subscribing
 with a different address than they post with.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22957 [Internal Services/Tor Sysadmin Team]: Please update my key on db.tpo

[Tor Bug Tracker & Wiki]

#22957: Please update my key on db.tpo
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hi,

 I would like to have my PGP key updated on db.tpo. The one that is
 currently stored there is expired/revoked.

 This is my new key:
 {{{
 % gpg --fingerprint 67EF3966509986E96ACEE84E5D67CD18702287F4
 pub   dsa3072/5D67CD18702287F4 2015-10-19 [SC] [expires: 2018-05-06]
   Key fingerprint = 67EF 3966 5099 86E9 6ACE  E84E 5D67 CD18 7022 87F4
 uid [ultimate] Arturo Filastò 
 uid [ultimate] Arturo Filastò 
 uid [ultimate] Arturo Filastò 
 uid [ultimate] Arturo Filastò 
 sub   elg2752/5D8D319EC58FC4EE 2015-10-19 [E] [expires: 2018-05-06]
 }}}

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by gk):

 Reported on our blog as well:
 https://blog.torproject.org/comment/269841#comment-269841.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22956 [Internal Services/Service - lists]: Please allow IgorMitrofanov to post to tor-dev@lists

[Tor Bug Tracker & Wiki]

#22956: Please allow IgorMitrofanov to post to tor-dev@lists
---+
 Reporter:  teor   |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #22820
   Points: |   Reviewer:
  Sponsor: |
---+
 IgorMitrofanov wants to post a proposal to tor-dev@lists, but the message
 bounced.

 Is it an issue on our end?
 Can we whitelist IgorMitrofanov's email?

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

Re: [tor-bugs] #22942 [Applications/Tor Browser]: Empty menuitem below "About Tor Browser" (was: minor tbb ui nit)

[Tor Bug Tracker & Wiki]

#22942: Empty menuitem below "About Tor Browser"
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

Re: [tor-bugs] #22935 [Applications/Orbot]: Disable SSL alert when visiting .onion HTTPS.

[Tor Bug Tracker & Wiki]

#22935: Disable SSL alert when visiting .onion HTTPS.
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  needs_information
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by gk):

 * status:  reopened => needs_information


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

Re: [tor-bugs] #22935 [Applications/Orbot]: Disable SSL alert when visiting .onion HTTPS.

[Tor Bug Tracker & Wiki]

#22935: Disable SSL alert when visiting .onion HTTPS.
+--
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Wait, are you sure this bug report is for Orbot?

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

Re: [tor-bugs] #22700 [Core Tor/Tor]: Stop relays using the Client*IPv6* options

[Tor Bug Tracker & Wiki]

#22700: Stop relays using the Client*IPv6* options
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-options, tor-relay, torrc  |  Actual Points:
  configuration warning  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 We might want to be careful how we do this, because bridge relays might
 want to use these options to be IPv6-only. See #4847.

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

Re: [tor-bugs] #22935 [Applications/Orbot]: Disable SSL alert when visiting .onion HTTPS.

[Tor Bug Tracker & Wiki]

#22935: Disable SSL alert when visiting .onion HTTPS.
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  closed
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by gk):

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


Comment:

 Duplicate of #13410.

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

Re: [tor-bugs] #22897 [Core Tor/Tor]: Revise privcount patch series to use trace/lttng modules

[Tor Bug Tracker & Wiki]

#22897: Revise privcount patch series to use trace/lttng modules
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  privcount |  Actual Points:
Parent ID:  #22955| Points:
 Reviewer:|Sponsor:  SponsorQ-can
--+
Changes (by teor):

 * keywords:   => privcount
 * parent:   => #22955


Comment:

 Once we've specified how PrivCount works with Tor (#22955), we can tear
 apart the existing experimental PrivCount code, and re-use any pieces that
 fit the new spec.

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

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:
--+---
Changes (by gk):

 * status:  new => needs_information
 * parent:   => #18097


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22955 [Core Tor/Tor]: Specify how PrivCount will work with Tor

[Tor Bug Tracker & Wiki]

#22955: Specify how PrivCount will work with Tor
--+
 Reporter:  teor  |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  privcount
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorQ-can  |
--+
 PrivCount is an experimental statistics collection protocol, which
 provides secure aggregation of a differentially private set of statistics.

 We need to work out which parts of the experimental protocol are useful,
 and how they could work on tor relays, and provide results to Tor metrics.

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

Re: [tor-bugs] #22954 [Applications/Tor Browser]: lxc-based tor-browser-bundle builds failing

[Tor Bug Tracker & Wiki]

#22954: lxc-based tor-browser-bundle builds failing
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201707R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Thanks. Applied to `tor-browser-builder-4` with commit
 5fbfab171782985bc3ae8ab4464b326aa34054b7.

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

Re: [tor-bugs] #22542 [Applications/Tor Browser]: Tor Browser 7.0 Security Settings Window too small on macOS 10.12

[Tor Bug Tracker & Wiki]

#22542: Tor Browser 7.0 Security Settings Window too small on macOS 10.12
-+-
 Reporter:  teor |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-security-slider, TorBrowserTeam201707R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:10 mcs]:
 > ...
 > We tested this on a couple of OSX systems, on a Linux system, and on
 Windows 10. Here is a pre-built xpi for testing:
 >
 
https://people.torproject.org/~brade/builds/bug22542/torbut...@torproject.org.xpi
 > teor: if you have time please test this on your OSX systems.

 I'm sorry, I am not sure I will have time to do this, I have some tight
 deadlines at the moment.

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

Re: [tor-bugs] #22934 [Core Tor/Tor]: PADDING cells can't be sent immediately after a VERSIONS cell

[Tor Bug Tracker & Wiki]

#22934: PADDING cells can't be sent immediately after a VERSIONS cell
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-relay  |  Actual Points:
Parent ID:  #18856   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Also, if a PADDING cell is sent *before* the VERSIONS cell, the connection
 will fail (#22929). Does the link padding code wait for the VERSIONS cell?

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

Re: [tor-bugs] #22934 [Core Tor/Tor]: PADDING cells can't be sent immediately after a VERSIONS cell

[Tor Bug Tracker & Wiki]

#22934: PADDING cells can't be sent immediately after a VERSIONS cell
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-relay  |  Actual Points:
Parent ID:  #18856   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * cc: mikeperry (added)
 * version:   => Tor: 0.3.1.1-alpha
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 I am not sure if this bug can be triggered by the link padding code on
 clients, so I'm moving it into 0.3.1 until we find out.

 I'm also not sure if this bug can be triggered by a client sending
 VERSIONS, NETINFO, then PADDING.

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