Re: [tor-bugs] #26124 [Metrics]: Bring​ back Tor​ Weather

[Tor Bug Tracker & Wiki]

#26124: Bring​ back Tor​ Weather
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by phoul):

 * cc: phoul (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] #24943 [Applications/Tor Browser]: Tor Browser is preventing add-on from saving its setting

[Tor Bug Tracker & Wiki]

#24943: Tor Browser is preventing add-on from saving its setting
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+--

Comment (by cypherpunks):

 https://trac.torproject.org/projects/tor/ticket/26125

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

Re: [tor-bugs] #26125 [Applications/Tor Browser]: Javascript's localStorage/sessionStorage is not working.

[Tor Bug Tracker & Wiki]

#26125: Javascript's localStorage/sessionStorage is not working.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|
--+--

Comment (by cypherpunks):

 And we highly value Tor Browser's Anonymity-first development.
 But disabling(removing?) such API will break Javascript applications.

 Instead of removing localStorage/sessionStorage code, why not:
 a) Treat all "localStorage"(long term) as "sessionStorage"(short term).
 b) Enable "sessionStorage" by default, like Mozilla Firefox provides.
 c) When the user close the tab or click "New Identity", clear
 local|sessionStorage.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26125 [Applications/Tor Browser]: Javascript's localStorage/sessionStorage is not working.

[Tor Bug Tracker & Wiki]

#26125: Javascript's localStorage/sessionStorage is not working.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
--+--
 To whom it may concern,

 We're allowing Tor users to read our websites. We are using sessionStorage
 to save temporary information.

 Unfortunatelly some Tor users reported us about Javascript error, and we
 downloaded your software to check their claim.

 Steps to reproduce:
 1. Open Tor Browser.
 2. Open any website, such as this current page
 https://trac.torproject.org/projects/tor/newticket
 3. Press [F12] key to open "Developer Tools" and click "Console".
 4. Type "sessionStorage.length".

 Result:
 SecurityError: The operation is insecure.

 It seems your browser's Storage API is broken.
 We have no problems when we tried latest Mozilla Firefox and Google
 Chrome.

 Result (Firefox 60):
 0

 Please fix your browser to meet Mozilla's default standard.

 --
 Rick W.

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

Re: [tor-bugs] #25545 [Core Tor/Tor]: Figure out default vanguard script parameters

[Tor Bug Tracker & Wiki]

#25545: Figure out default vanguard script parameters
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-guard, guard-discovery, 034  |  Actual Points:
  -roadmap-master, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  SponsorV
-+-

Comment (by mikeperry):

 I have a quick observation here: If I am understanding the source right,
 the pwnage time to compromise L2 is chosen for each relay in L2. These
 times come from the adversary model.

 Since these times come from a probability distribution, the more times we
 sample it (for more L2 guards), the more likely we are to get a lower
 value for time-to-compromise for that layer. I suppose this reflects
 reality somewhat. The more L2 guards there are, the more likely you're
 able to get to one of them faster than the others.

 Anyway I agree with the ultimate conclusion of your doc. I will get
 vanguards into a state that we can run a bunch of onionperf instances with
 it and compare 2-3-8 and 2-4-8 there.

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
-+-
 Reporter:  isabela  |  Owner:
 |  pospeselr
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:38 dmr]:
 > Replying to [comment:36 cypherpunks]:
 > > FWIW it's important to keep this timeline in mind especially the
 coming deprecation of the lock icon (2019) for HTTPS
 https://blog.cloudflare.com/https-or-bust-chromes-plan-to-label-sites-as-
 not-secure/
 > >
 > > > 1. Google will announce the lock icon’s demise in 2018 and remove it
 in January 2019 with the release of Chrome 72
 >
 > Just to place the quote into context:
 > This is a //guess/prediction// by CloudFlare. That Chrome will
 eventually deprecate the lock icon seems to be part of their rough plan
 from 2014, but there is no set timeframe indicated in the article. (Still
 good to keep in mind, however.)

 It's official: in September 2018, Google will stop marking HTTPS sites as
 secure (but there's a non-green doorhanger still).
 https://blog.chromium.org/2018/05/evolving-chromes-security-
 indicators.html

 [[Image(https://ipfs.io/ipfs/QmZP41Gwe33NsgTzPUR1xuKVn8TECQHvMRAoefLzN9Af3D)]]

 Full doorhanger removal will happen "eventually", and CloudFlare's
 prediction is it will happen "in January 2019 with the release of Chrome
 72".

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

Re: [tor-bugs] #10915 [Core Tor/Tor]: Tool to find unused functions in Tor

[Tor Bug Tracker & Wiki]

#10915: Tool to find unused functions in Tor
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay technical-debt tooling |  Actual Points:
  analysis   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rl1987):

 Doesn't Coverity support this?

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

Re: [tor-bugs] #17873 [Core Tor/Tor]: replacing 0.0.0.0 listeners at runtime fails

[Tor Bug Tracker & Wiki]

#17873: replacing 0.0.0.0 listeners at runtime fails
+--
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-client port bind switching  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  ahf |Sponsor:
+--
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 I addressed things you commented in pull request and wrote an integration
 test in Python. One remaining thing to do is to get `make distcheck` to
 pass (did I include my integration test into build incorrectly?; `make
 check` does pass with my new stuff). Once that's done, I will
 rebase/squash the changes into new branch.

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

[tor-bugs] #26124 [Metrics]: Bring​ back Tor​ Weather

[Tor Bug Tracker & Wiki]

#26124: Bring​ back Tor​ Weather
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 TL;DR: I believe Tor Weather is the most efficient way to achieve and
 maintain a healthy Tor network on the long run.

 This is an item on the metrics team road map ("Q4 2018 or later") but
 maybe the new relay advocate (Colin) can help with this?

 Tor Weather has been discontinued on 2016-04-04,
 see Karsten's email for the reasoning behind it:
 https://lists.torproject.org/pipermail/tor-relays/2016-April/009009.html
 but as he says "Tor Weather is still a good idea, it just needs somebody
 to implement it."

 How Tor Weather looked like:
 
https://web.archive.org/web/20141004055709/https://weather.torproject.org/subscribe/


 **Motivation**

 If a relay disappears today, it is unlikely that anyone will notice or
 even send an email to the operator unless it is a big one.

 Relay operators and the entire tor network would benefit from a Tor
 Weather service because it notifies relay operators when the state of
 their relays changed (and more). This will increase the likelihood that
 relay operators notice problems and actually mitigate the problem
 otherwise there is no "user feedback" since tor can cope with disappearing
 relays quite well.
 It also
 * shows the relay operator that someone actually cares if their relays go
 down or become outdated or have another problem
 * gives the operator relay best-practices information.

 **Expected Effects**

 If enough operators subscribe to such a service:
 * relays might become more long lived / the churn rate might decrease
 * the fraction of relays running outdated tor versions might decrease
 * the fraction of exits with broken DNS might decrease

 It also has the benefit of being able to contact relay operators
 * completely automatically
 * even if they choose to not set a public ContactInfo string in their
 torrc files.

 **Ideas for Notification Types**
 (sorted by importance)

 Support subscribing via single relay FP or MyFamily groups (should not
 need any subscription change if a relay gets added to the family).

 [ ] Email me when my node is down
 How long before we send a notification? 
 [ ] email me when my relay is affected by a security vulnerability
 [ ] email me when my relay runs an end-of-life version of tor

 [ ] email me when my relay runs an outdated tor version (note: this should
 depend on the related onionoo bugs to avoid emailing alpha relay people)

 [ ] email me when my exit relay fails to resolve hostnames (DNS failure)

 [ ] email me when my relay looses the [ ] stable, [ ] guard, [ ] exit flag

 [ ] email me when my MyFamily configuration is broken (meaning: non-mutual
 config detected or relay with same contactInfo but no MyFamily)
 [ ] email me when you detect issues with my relay
 [ ] email me with suggestions for configuration improvements for my relay
 (only once per improvement)

 [ ] email me when my relay is on the top [ ] 20 [ ] 50 [ ] 100 relays list

 [ ] email me with monthly/quarterly status information that includes
 information like what my position in the overall relay list is (sorted by
 CW), how much traffic my relay did during the last month and what fraction
 of the months time your relay was included in consensus as running (this
 shows information on how many % of the months' consensuses this relay has
 been included and running)
 [ ] aggregate emails for all my relays into a single digest email
 [ ] email me about new relay requirements
 [ ] email me about tor relay operator events

 * Write a specification describing the meaning of each checkbox

 **Security and Privacy Implications**

 The service stores email addresses of potential tor relay operators, they
 should be kept private and safeguarded, but a passive observer can collect
 them by watching outbound email traffic if no TLS is used. Suggest to use
 a dedicated email address for this service.

 **Additional Ideas**

 * easy: integration into tor: show the URL pointing to the new Tor Weather
 service like the current link to the lifecycle blogpost when tor starts
 and detects to be a new relay
 * Provide an uptimerobot-style status page for relay operators using
 onionoo data

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

Re: [tor-bugs] #26122 [Obfuscation/Obfsproxy]: obfs4: remove byte threshold for disconnection (was: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec)

[Tor Bug Tracker & Wiki]

#26122: obfs4: remove byte threshold for disconnection
---+-
 Reporter:  cypherpunks|  Owner:  dcf
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by dcf):

 * component:  Obfuscation/Censorship analysis => Obfuscation/Obfsproxy
 * type:  defect => enhancement


Old description:

> obfs4-spec.txt:
> > On the event of a failure at this point implementations SHOULD delay
> dropping the TCP connection from the client by a random interval to make
> active probing more difficult.
>
> closeAfterDelay() can to violate spec by closing connection immediately.

New description:

 As currently implemented, an obfs4 server disconnects an unauthenticated
 client after 8192–16383 received bytes or 30–90 seconds. (The exact values
 are chosen randomly from these ranges for each server.) The patch in
 comment:1 proposes to remove the byte threshold and keep the time
 threshold, as a mitigation against active-probing distinguishers such as
 the one in #26083.

 Original description:
 > obfs4-spec.txt:
 > > On the event of a failure at this point implementations SHOULD delay
 dropping the TCP connection from the client by a random interval to make
 active probing more difficult.
 >
 > closeAfterDelay() can to violate spec by closing connection immediately.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26123 [- Select a component]: Repetidores falló

[Tor Bug Tracker & Wiki]

#26123: Repetidores falló
--+
 Reporter:  Conker1190|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 estableciendo una conexion cifrada con el repositorio de repetidores falló
 ( 212.47.244.38:443

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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+-
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:  2
 Reviewer:  isis, catalyst   |Sponsor:
 |  Sponsor3
-+-

Comment (by nickm):

 I didn't run into #26076, so it might still be there.

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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+-
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:  2
 Reviewer:  isis, catalyst   |Sponsor:
 |  Sponsor3
-+-

Comment (by catalyst):

 Replying to [comment:34 nickm]:
 > So, I've rebased the branch onto master, and hacked randomly on it until
 it passed.  It's in my github repository as "appveyor3", and here it is
 passing: https://ci.appveyor.com/project/nmathewson/tor/build/1.0.8
 >
 > Does that seem good? If so, I think the next step is to squash it down
 to a more manageable branch, clean it up a little, and get it reviewed
 again.
 Thanks! It looks good at first glance. I might want to study it a bit
 more. Did you figure out how to fix #26076? Or is it still (possibly)
 intermittently failing?

 I agree that squashing it into more manageable commits might be a good
 idea (and easier to 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] #26122 [Obfuscation/Censorship analysis]: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec

[Tor Bug Tracker & Wiki]

#26122: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec
-+-
 Reporter:  cypherpunks  |  Owner:  dcf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 > As I read it, the patch is about an alternate (spec-compliant) behavior
 that may make active probing somewhat more expensive.

 It doesn't.

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

Re: [tor-bugs] #26122 [Obfuscation/Censorship analysis]: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec

[Tor Bug Tracker & Wiki]

#26122: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec
-+-
 Reporter:  cypherpunks  |  Owner:  dcf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Yawning, I think this ticket was badly phrased wrt spec compliance. Since
 you don't want to maintain obfs4proxy anymore, could we at least leave the
 ticket open for discussion? As I read it, the patch is about an alternate
 (spec-compliant) behavior that may make active probing somewhat more
 expensive.

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

Re: [tor-bugs] #26122 [Obfuscation/Censorship analysis]: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec

[Tor Bug Tracker & Wiki]

#26122: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec
-+-
 Reporter:  cypherpunks  |  Owner:  dcf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

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


Comment:

 It does conform to the spec.

 The interval and threshold is randomized on a per-server instance basis.
 Exactly how this is implemented (and even then there is a difference
 between `SHOULD` and `MUST`) is deliberately left up to the
 implementation, and the altered behavior is also fairly distinctive.

 As a side note: I both recommended starting the development of something
 new, and the migration off obfs4 over a year ago.

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

Re: [tor-bugs] #26122 [Obfuscation/Censorship analysis]: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec

[Tor Bug Tracker & Wiki]

#26122: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec
-+-
 Reporter:  cypherpunks  |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Proposed fix:
 {{{
 -   // Consume and discard data on this connection until either the
 specified
 -   // interval passes or a certain size has been reached.
 -   discarded := 0
 -   var buf [framing.MaximumSegmentLength]byte
 -   for discarded < int(sf.closeDelayBytes) {
 +   // Consume and discard data on this connection until the specified
 +   // interval passes.
 +   var buf [maxHandshakeLength]byte
 +   for {
 n, err := conn.Conn.Read(buf[:])
 if err != nil {
 return
 }
 -   discarded += n
 }
 }}}

 This fix can also to stop some form of active probing attack discovered by
 #26083

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26122 [Obfuscation/Censorship analysis]: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec

[Tor Bug Tracker & Wiki]

#26122: obfs4proxy: closeAfterDelay() should to conform to obfs4 spec
-+-
 Reporter:  cypherpunks  |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 obfs4-spec.txt:
 > On the event of a failure at this point implementations SHOULD delay
 dropping the TCP connection from the client by a random interval to make
 active probing more difficult.

 closeAfterDelay() can to violate spec by closing connection immediately.

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

Re: [tor-bugs] #25895 [Core Tor/Tor]: Cross-compiling tor rust for Windows is broken

[Tor Bug Tracker & Wiki]

#25895: Cross-compiling tor rust for Windows is broken
-+-
 Reporter:  gk   |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, 034-proposed, tbb-wants,   |  Actual Points:
  033-backport, 034-roadmap-proposed |
Parent ID:  #25849   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Hello71):

 Replying to [comment:11 gk]:
 > Replying to [comment:10 gk]:
 > > What you actually want is not the LLVM target triple, but the Rust
 target triple. So, instead of "LLVM target triple (for Rust)" just use
 "Rust target triple".
 >
 > Better even "Rust target" as the target is strictly speaking not a
 triple here.

 strictly strictly speaking, Rust takes a target specifier in LLVM format
 (which is apparently very similar to, but of course incompatible with
 autotools format). I guess it's not wrong to say Rust target though.

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

Re: [tor-bugs] #26121 [Core Tor/Tor]: BUILDTIMEOUT_SET totals are still off

[Tor Bug Tracker & Wiki]

#26121: BUILDTIMEOUT_SET totals are still off
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/tor/pull/115

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26121 [Core Tor/Tor]: BUILDTIMEOUT_SET totals are still off

[Tor Bug Tracker & Wiki]

#26121: BUILDTIMEOUT_SET totals are still off
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 While testing and examining onion service timeout rates and trying to
 verify them from a controller script, I realized that our timeout rates
 are still off in the BUILDTIMEOUT_SET event.

 The reason for the discrepancy is that we're double-counting circuits that
 transition into MEASUREMENT_EXPIRED. Every circuit that transitions into
 MEASUREMENT_EXPIRED is first counted as a timeout in
 circuit_build_times_mark_circ_as_measurement_only(). Of those that do not
 complete within the measurement window, we again count as a "closed"
 circuit in circuit_build_times_count_close(). If a measurement circuit
 succeeds, we do *not* count it as a success (see
 circuit_build_times_handle_completed_hop()).

 This means that the total_circuits value in
 cbt_control_event_buildtimeout_set() should be timeouts+succeeded, and not
 timeouts+succeeded+closed. (Again, counting closed in the total there
 double-counts "closed" MEASUREMENT circuits, which were also counted as
 timeout circuits earlier).

 Since this is just a control port stats change, it would be nice to get it
 into 0.3.4 (and maybe 0.3.3) so it is easier to get more accurate data
 about how the circuit build timeout is interacting with vanguards there.

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

Re: [tor-bugs] #26110 [Core Tor/Tor]: CIRC_BW fields vague

[Tor Bug Tracker & Wiki]

#26110: CIRC_BW fields vague
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+

Comment (by mikeperry):

 Woops - I remembered one more detail. The READ and WRITE fields do not
 include circuit headers, and the Delivered and Overhead fields do not
 include relay cell headers. I pushed another fixup for this to that
 branch.

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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+-
 Reporter:  isis |  Owner:  saper
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing, 034-roadmap-|  Actual Points:
  subtask, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:  #25550   | Points:  2
 Reviewer:  isis, catalyst   |Sponsor:
 |  Sponsor3
-+-

Comment (by nickm):

 So, I've rebased the branch onto master, and hacked randomly on it until
 it passed.  It's in my github repository as "appveyor3", and here it is
 passing: https://ci.appveyor.com/project/nmathewson/tor/build/1.0.8

 Does that seem good? If so, I think the next step is to squash it down to
 a more manageable branch, clean it up a little, and get it reviewed again.

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

Re: [tor-bugs] #26110 [Core Tor/Tor]: CIRC_BW fields vague

[Tor Bug Tracker & Wiki]

#26110: CIRC_BW fields vague
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by atagar):

 * status:  needs_review => merge_ready


Comment:

 Thanks Mike! Looks good to me.

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

Re: [tor-bugs] #25545 [Core Tor/Tor]: Figure out default vanguard script parameters

[Tor Bug Tracker & Wiki]

#25545: Figure out default vanguard script parameters
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-guard, guard-discovery, 034  |  Actual Points:
  -roadmap-master, 034-triage-20180328,  |
  034-included-20180328  |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  SponsorV
-+-
Changes (by asn):

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


Comment:

 Posted my analysis of vanguard topologies here:
 https://github.com/asn-d6/vanguard_simulator/wiki/Optimizing-vanguard-
 topologies

 It's pretty much in-line with the analysis that Mike has done.

 I'm hence closing this deliverable item, and let's discuss more in the
 future as part of the vanguard project.

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

Re: [tor-bugs] #16824 [Core Tor/Tor]: Emit a warning message about side channel leaks when using relays as clients

[Tor Bug Tracker & Wiki]

#16824: Emit a warning message about side channel leaks when using relays as
clients
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  mike-can, tor-client tor-relay   |  Actual Points:
  sidechannel logging easy   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by starlight):

 Replying to [comment:42 starlight]:
 > Seemed to me a warning would arrive once client activity commenced on a
 traffic forwarding relay.  Had not considered how it would be implemented,
 whether SocksPort!=0 and ORPort!=NULL would trigger it.  Perhaps the
 message should emit on the first socks connection when ORPort is
 configured?  Or perhaps SockPort=0 should default when ORPort is set and
 the message arrive when both are asserted?
 >
 > To quote my earlier self:
 >
 > > 2) some consider it a reasonable idea to configure a client
 > > and relay in the same daemon instance with the belief
 > > that this would obfuscate local client traffic to some
 > > degree; but with the implementation as it presently
 > > stands such an idea is false and should be denigrated
 >
 > The idea of the warning is to alert users to potential risk, in
 consideration of the time and effort that will likely pass before the risk
 is alleviated.  Already quite some time has passed.
 >
 > Mike Perry suggested a warning as an alternative to my original idea
 that such configurations be discouraged via a new parameter, his reasoning
 in comment:16 above.

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

Re: [tor-bugs] #26022 [Metrics/Statistics]: Fix a flaw in the noise-removing code in our onion service statistics

[Tor Bug Tracker & Wiki]

#26022: Fix a flaw in the noise-removing code in our onion service statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Replying to [comment:15 amj703]:
 > > > Why not throw out the outliers, then add the remaining, then do the
 adjustment?
 > >
 > > The way we're determining whether a reported value was an outlier or
 not is by extrapolating all reported values to network totals and
 discarding the lowest 25% and highest 25% of ''extrapolated'' values. But
 extrapolating values requires us to make these adjustment first, or we'd
 extrapolate to the wrong network totals.
 >
 > It sounds to me like it doesn't make a difference if throw out the
 outliers before adjustment or after adjustment. The adjustment preserves
 the relative ordering of the values, and so the bottom (and top) 25% of
 data points will remain the same.

 You're right. Agreed, this would work.

 > So here's a suggestion: (1) extrapolate by dividing the raw measurement
 by the relay's weight; (2) remove the top and bottom 25% of extrapolated
 values; (3) add the remaining raw values; (4) adjust that result by
 rounding towards the closest bin edge, subtracting num_relay*bin_size/2,
 and replacing a negative value with 0; and then (5) extrapolate the result
 by dividing by the total weight of the included relays.

 I see how that approach would work and produce similar results to our
 current approach. In particular, I think it does the following things
 differently:

  - We're currently rounding each reported statistic towards the closest
 bin edge, whereas your suggested approach would only do that once in step
 (4). You approach is less likely to introduce errors and relies more on
 noise to cancel out itself. This seems good.

  - Your approach replaces a negative end value with 0 in step (4) which
 our current approach doesn't. We could easily adopt this part, if we
 wanted. So far, it hasn't happened that we got a negative end result,
 though.

 > > Here's another idea, though: what if we change the way how we're
 removing noise by ''only'' subtracting `bin_size / 2` to undo the binning
 step as good as we can and leave the Laplace noise alone. Basically, we'd
 only account for the fact that relays always round up to the next multiple
 of `bin_size`, but we wouldn't do anything about the positive or negative
 noise.
 >
 > This isn't really the best guess about the value at the relays before
 noise is added. While not performing the noise-removal step makes it
 easier to explain how the metrics numbers are produced (and to implement
 them), I think it makes it harder to understand what they mean. This is a
 judgement call that I can see both sides of, though!

 Wait, my suggestion was to subtract `bin_size / 2` but not round to the
 closest bin edge. I think it produces the same result as your suggestion
 above, except that it does not round the end result to the closest bin
 edge in your step (4).

 However, and here comes the catch: I'm running out of time for
 experimenting with different approaches. My goal here was to fix a bug,
 not to try improved estimation algorithms. I can see how your suggestion
 might improve our results, but it's a bigger code change than a single
 method. I'm afraid I'll have to leave that as future work. :(

 I'll wait for the simplified `removeNoise()` method run to finish and will
 post a new graph that compares flawed, fixed, and simplied methods.

 > > Wait, we're talking about two different things:
 > >
 > >  1. Relays internally round ''up'' to the next multiple of `bin_size`.
 > >  2. metrics-web contains that `removeNoise()` method that this ticket
 is all about.
 >
 > Ah, right, thanks for clarifying that.

 Great! Sorry for confusing you earlier.

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

Re: [tor-bugs] #8915 [Applications/Tor Browser]: Cannot spoof useragent and vendor

[Tor Bug Tracker & Wiki]

#8915: Cannot spoof useragent and vendor
-+-
 Reporter:  nhk91|  Owner:  danieleweber7624
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.3.x-stable
  Browser|Version:  Tor: unspecified
 Severity:  Normal   | Resolution:  worksforme
 Keywords:  tbb-firefox-patch|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Changing `general.useragent.override` yields immediate results, thus that
 part is fixed. Closing this as WORKSFORME.

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

Re: [tor-bugs] #1623 [Applications/Tor Browser]: Block protocol handler enumeration

[Tor Bug Tracker & Wiki]

#1623: Block protocol handler enumeration
---+--
 Reporter:  mikeperry  |  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting, tbb-torbutton  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * milestone:  TorBrowserBundle 2.3.x-stable =>


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

Re: [tor-bugs] #8904 [Applications/Tor Browser]: Linux - App/Firefox/chrome/icons/default Missing

[Tor Bug Tracker & Wiki]

#8904: Linux - App/Firefox/chrome/icons/default Missing
-+-
 Reporter:  DasFox   |  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.3.x-stable
  Browser|Version:
 Severity:  Normal   | Resolution:  worksforme
 Keywords:  needs-triage |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 I don't think that's an issue anymore.

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

Re: [tor-bugs] #3929 [Applications/Tor Browser]: Remove CNNIC

[Tor Bug Tracker & Wiki]

#3929: Remove CNNIC
-+-
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.3.x-stable
  Browser|Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tbb-firefox-patch|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 We don't plan to start in the CA policing business.

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

Re: [tor-bugs] #9674 [Applications/Tor Browser]: /Applications/TorBrowser-2.3.25-12-osx-i386-en-US.zip usability woes

[Tor Bug Tracker & Wiki]

#9674: /Applications/TorBrowser-2.3.25-12-osx-i386-en-US.zip usability woes
-+-
 Reporter:  RomanCzyborra|  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.3.x-stable
  Browser|Version:  Tor: 0.2.2.21-alpha
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  data, loss, data,|  Actual Points:
  protection, user, stress, mental,  |
  health, sanity, tbb-firefox-patch  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 There is no 32bit macOS we support anymore.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #3938, #10114

[Tor Bug Tracker & Wiki]

Batch modification to #3938, #10114 by gk:


Action: resolve

--
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] #25926 [Metrics/Website]: "The anonymous Internet" page on metrics has malicious looking links

[Tor Bug Tracker & Wiki]

#25926: "The anonymous Internet" page on metrics has malicious looking links
-+---
 Reporter:  pastly   |  Owner:  metrics-team
 Type:  defect   | Status:  needs_information
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by pastly):

 Replying to [comment:5 cypherpunks]:
 > Replying to [comment:4 pastly]:
 > > Providing an archived link right next to it would be a nice and easy
 plus.
 > Why not to provide only an archived link with a specific date in which
 the URL is known to not be malicious
 `https://web.archive.org/web/2018/...`?

 I think places generally deserve to receive traffic directly so that
 visitors can continue on exploring their website if desired. Linking to
 them **only** via an archived link raises the bar too much IMHO.


 -

 karsten,  it helps, I archived the page today. https://archive.fo/LfJ7D

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

Re: [tor-bugs] #15262 [Community/Translations]: Translatable URL in TORbutton

[Tor Bug Tracker & Wiki]

#15262: Translatable URL in TORbutton
+
 Reporter:  kingu   |  Owner:  phoul
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Torbutton: 1.4
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  URL |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by gk):

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


Comment:

 There is not disconnect anymore we use.

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

Re: [tor-bugs] #10397 [Applications/Tor Browser]: Torbrowser's updater integrates additional protections from Thandy's threat model

[Tor Bug Tracker & Wiki]

#10397: Torbrowser's updater integrates additional protections from Thandy's 
threat
model
--+--
 Reporter:  StrangeCharm  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  pantheon, chronos, tbb-torbutton => tbb-security


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

Re: [tor-bugs] #10393 [Applications/Tor Browser]: Torbrowser updates are verified through the Tor consensus

[Tor Bug Tracker & Wiki]

#10393: Torbrowser updates are verified through the Tor consensus
--+--
 Reporter:  StrangeCharm  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  pantheon, chronos, tbb-torbutton => tbb-security


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

Re: [tor-bugs] #7858 [Applications/Tor Browser]: I am using window 7 when i open any flash content site in tor browser(2.2.39) then tor jam for 20 seconds and at the spot of video show black screen no

[Tor Bug Tracker & Wiki]

#7858: I am using window 7 when i open any flash content site in tor
browser(2.2.39) then tor jam for 20  seconds and at the spot of video show
black screen not run video
-+-
 Reporter:  rao49|  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.2.x-stable
  Browser|Version:  Tor: 0.2.2.39
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  needs-triage, flash  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 We won't fix any flash related bugs.

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

Re: [tor-bugs] #7535 [Archived/Vidalia]: unable to delete line in torrc using advanced settings edit torrc

[Tor Bug Tracker & Wiki]

#7535: unable to delete line in torrc using advanced settings edit torrc
---+---
 Reporter:  mwolfe |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  TorBrowserBundle 2.2.x-stable
Component: |Version:  Vidalia: 0.2.20
  Archived/Vidalia |
 Severity:  Normal | Resolution:  wontfix
 Keywords:  edit torrc |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

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


Comment:

 We don't have Vidalia anymore, so closing.

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

Re: [tor-bugs] #26120 [Internal Services/Service - deb.tpo]: add tor-experimental-0.3.4.x deb repos

[Tor Bug Tracker & Wiki]

#26120: add tor-experimental-0.3.4.x deb repos
-+-
 Reporter:  cypherpunks  |  Owner:  weasel
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 don't file tickets for new releases immediately.  if there still are no
 debs after a week, then it's reasonable.

 right now it's anything but and really really annoying

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26120 [Internal Services/Service - deb.tpo]: add tor-experimental-0.3.4.x deb repos

[Tor Bug Tracker & Wiki]

#26120: add tor-experimental-0.3.4.x deb repos
-+
 Reporter:  cypherpunks  |  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 the first 0.3.4.x has been released
 https://lists.torproject.org/pipermail/tor-talk/2018-May/044211.html
 lets add builds to the torproject debian repo
 https://deb.torproject.org/torproject.org/dists/

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

Re: [tor-bugs] #10397 [Applications/Tor Browser]: Torbrowser's updater integrates additional protections from Thandy's threat model

[Tor Bug Tracker & Wiki]

#10397: Torbrowser's updater integrates additional protections from Thandy's 
threat
model
--+--
 Reporter:  StrangeCharm  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  pantheon, chronos, tbb-torbutton  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * milestone:  Chronos: phase two =>


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

Re: [tor-bugs] #10393 [Applications/Tor Browser]: Torbrowser updates are verified through the Tor consensus

[Tor Bug Tracker & Wiki]

#10393: Torbrowser updates are verified through the Tor consensus
--+--
 Reporter:  StrangeCharm  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  pantheon, chronos, tbb-torbutton  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * milestone:  Chronos: phase two =>


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

Re: [tor-bugs] #25926 [Metrics/Website]: "The anonymous Internet" page on metrics has malicious looking links

[Tor Bug Tracker & Wiki]

#25926: "The anonymous Internet" page on metrics has malicious looking links
-+---
 Reporter:  pastly   |  Owner:  metrics-team
 Type:  defect   | Status:  needs_information
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 Replying to [comment:4 pastly]:
 > Providing an archived link right next to it would be a nice and easy
 plus.
 Why not to provide only an archived link with a specific date in which the
 URL is known to not be malicious
 `https://web.archive.org/web/2018/...`?

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * priority:  Medium => High


Comment:

 Setting priority to high, because it would be neat to finalize the
 specification for this graph.

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 I'm changing my mind! After waiting for over 5 (!) days for the re-import
 of just the 2018 descriptors to succeed, I'm giving up on this plan. I
 don't know how far that import got when I aborted it, but even if it had
 succeeded 1 second after, the whole import would take many weeks if not
 months. It's not a good enough use of my time to babysit this import. Nor
 is it good timing to re-implement this code now. After all, this graph if
 by far not our most important one. Let's do something else to simplify
 this code and make it easier to specify.

 Suggestion !#2: We simplify this graph by a) updating the graph
 description to say that the graph only includes directory traffic from
 directory mirrors and b) taking out the extrapolation step.

 The difference to suggestion !#1 is that all data is already in the
 database. Here's a graph that compares the current approach with
 suggestion !#2:

 [[Image(dirbytes.3.png, 700px)]]

 This graph shows that the extrapolation step may have been useful in 2010
 and 2011. It also shows that it started producing weird results in late
 2016 when the extrapolated number got smaller than the reported number.
 I'm not even sure what happened there. Yet one more reason to get rid of
 it, in addition to the main goal of simplifying our statistics and making
 them easier to reproduce.

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-26002=a0cd20e13945ad7712f8cdb5f98e615fe41f81e6
 commit a0cd20e in my task-26002 branch].

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

Re: [tor-bugs] #26002 [Metrics/Statistics]: Simplify graph with number of bytes spent on answering directory requests

[Tor Bug Tracker & Wiki]

#26002: Simplify graph with number of bytes spent on answering directory 
requests
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * Attachment "dirbytes.3.png" 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] #26022 [Metrics/Statistics]: Fix a flaw in the noise-removing code in our onion service statistics

[Tor Bug Tracker & Wiki]

#26022: Fix a flaw in the noise-removing code in our onion service statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by amj703):

 > > Why not throw out the outliers, then add the remaining, then do the
 adjustment?
 >
 > The way we're determining whether a reported value was an outlier or not
 is by extrapolating all reported values to network totals and discarding
 the lowest 25% and highest 25% of ''extrapolated'' values. But
 extrapolating values requires us to make these adjustment first, or we'd
 extrapolate to the wrong network totals.

 It sounds to me like it doesn't make a difference if throw out the
 outliers before adjustment or after adjustment. The adjustment preserves
 the relative ordering of the values, and so the bottom (and top) 25% of
 data points will remain the same. So here's a suggestion: (1) extrapolate
 by dividing the raw measurement by the relay's weight; (2) remove the top
 and bottom 25% of extrapolated values; (3) add the remaining raw values;
 (4) adjust that result by rounding towards the closest bin edge,
 subtracting num_relay*bin_size/2, and replacing a negative value with 0;
 and then (5) extrapolate the result by dividing by the total weight of the
 included relays.

 > Here's another idea, though: what if we change the way how we're
 removing noise by ''only'' subtracting `bin_size / 2` to undo the binning
 step as good as we can and leave the Laplace noise alone. Basically, we'd
 only account for the fact that relays always round up to the next multiple
 of `bin_size`, but we wouldn't do anything about the positive or negative
 noise.

 This isn't really the best guess about the value at the relays before
 noise is added. While not performing the noise-removal step makes it
 easier to explain how the metrics numbers are produced (and to implement
 them), I think it makes it harder to understand what they mean. This is a
 judgement call that I can see both sides of, though!

 > Wait, we're talking about two different things:
 >
 >  1. Relays internally round ''up'' to the next multiple of `bin_size`.
 >  2. metrics-web contains that `removeNoise()` method that this ticket is
 all about.

 Ah, right, thanks for clarifying that.

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

Re: [tor-bugs] #25543 [Applications/Tor Browser]: Rebase Tor Browser patches for ESR60

[Tor Bug Tracker & Wiki]

#25543: Rebase Tor Browser patches for ESR60
+--
 Reporter:  gk  |  Owner:
|  arthuredelstein
 Type:  task| Status:
|  needs_revision
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201805, ff60-esr  |  Actual Points:
Parent ID:  #25741  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Replying to [comment:20 mcs]:
 > I just attached a fixup patch `0001-fixup-Bug-4234-Use-the-Firefox-
 Update-Process-for-To.patch` that removes some code that hunts around in
 the Windows registry to decide whether to append `=1` to the update
 check URL. Arthur, please include this fixup when you create a new branch.
 >
 > For Firefox, the registry keys that are checked are set by Mozilla's
 installer. This means that they will never be set for Tor Browser, which
 also means it is a waste of time to look for them.

 Looks good to me (I checked commit
 d2fd026be23ba97ba4826dedb2197c778d0315b1 on Arthur's 25543+10).

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

Re: [tor-bugs] #25543 [Applications/Tor Browser]: Rebase Tor Browser patches for ESR60

[Tor Bug Tracker & Wiki]

#25543: Rebase Tor Browser patches for ESR60
+--
 Reporter:  gk  |  Owner:
|  arthuredelstein
 Type:  task| Status:
|  needs_revision
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201805, ff60-esr  |  Actual Points:
Parent ID:  #25741  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Replying to [comment:31 gk]:
 > 31530f47b84a0df2c1b9371089f7f8211cccd8a9 -- not okay
 >
 > It seems to me with the telemetry pref flip in
 34407382d48ebbbc6deb74dcf5f67e95a74d8346 we don't need the `_enabled`
 check. (see my comment in #25909 as well)

 Actually, I think that's the better fix, see: comment:7:ticket:25909. So,
 we are good with that 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] #25909 [Applications/Tor Browser]: disable updater telemetry

[Tor Bug Tracker & Wiki]

#25909: disable updater telemetry
+--
 Reporter:  mcs |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Okay, makes sense.

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

Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:
|  needs_revision
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  ff60-esr, TorBrowserTeam201805R => ff60-esr,
 TorBrowserTeam201805


Comment:

 Some comments (just nits):

 commit 785568d05b12f819a29b90c2dcd4e55b821a2047:
 Any reason why the `minVersion` for Fennec is 45 and not 52? (I am fine
 with leaving the patch you have given that we are not really enforcing 52
 for desktop either, just curious)

 commit 2e1e760a8393de281318e97ef44b2e89ba67879c
 "Gecko now requires "0o"-prefixed octal literals" <- Are you sure about
 that? Yes, the warning shows up in the browser console but the bug you are
 citing is already fixed in Firefox 48, yet Tor Browser 7 does not show the
 warning. Fixing the octals is good, though. I hunted a bit but finding the
 actual bug behind this change seems a bit tricky. I think we could just
 say "Fix deprecated octal literals" in the commit message and move on.

 You are using "Bug XXX" and "bug XXX" for referencing Mozilla bugs
 within a sentence. I think you should stick to one format and the latter
 is the better one.

 commit 039bd44ce1a65bbc7bcacfa7a6b114b744a84b8f

 s/var loader/let loader/
 {{{
 +  TorLauncherLogger.log(5,"Ignoring invalid pref ending with a
 period: '" +
 }}}
 Whitspace between "," and "\"".

 You want to have pairwise "'" but are forgetting sometimes the closing
 one.

 commit 3f2936d1323c36d1882b81ab155bf9fd48e27a37

 The indentation of the new code block is off by 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] #25895 [Core Tor/Tor]: Cross-compiling tor rust for Windows is broken

[Tor Bug Tracker & Wiki]

#25895: Cross-compiling tor rust for Windows is broken
-+-
 Reporter:  gk   |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, 034-proposed, tbb-wants,   |  Actual Points:
  033-backport, 034-roadmap-proposed |
Parent ID:  #25849   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Targets, triples, heh...
 https://bugzilla.mozilla.org/show_bug.cgi?id=475488

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

Re: [tor-bugs] #25895 [Core Tor/Tor]: Cross-compiling tor rust for Windows is broken

[Tor Bug Tracker & Wiki]

#25895: Cross-compiling tor rust for Windows is broken
-+-
 Reporter:  gk   |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, 034-proposed, tbb-wants,   |  Actual Points:
  033-backport, 034-roadmap-proposed |
Parent ID:  #25849   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:10 gk]:
 > What you actually want is not the LLVM target triple, but the Rust
 target triple. So, instead of "LLVM target triple (for Rust)" just use
 "Rust target triple".

 Better even "Rust target" as the target is strictly speaking not a triple
 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] #25926 [Metrics/Website]: "The anonymous Internet" page on metrics has malicious looking links

[Tor Bug Tracker & Wiki]

#25926: "The anonymous Internet" page on metrics has malicious looking links
-+---
 Reporter:  pastly   |  Owner:  metrics-team
 Type:  defect   | Status:  needs_information
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by pastly):

 I think it would be fine to add the link back to the metrics page.

 It seems they have changed the URL for "The Anonymous Internet" to
 http://geography.oii.ox.ac.uk/the-anonymous-internet/, so I'd probably
 link to that instead.

 I think just linking to the OII page again is reasonable. Providing an
 archived link right next to it would be a nice and easy plus.

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

Re: [tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-25383=2dbfc52541c07c3e4a72ee120cf793b87cb47b0a
 commit 2dbfc52 in my task-25383 branch].

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

Re: [tor-bugs] #25895 [Core Tor/Tor]: Cross-compiling tor rust for Windows is broken

[Tor Bug Tracker & Wiki]

#25895: Cross-compiling tor rust for Windows is broken
-+-
 Reporter:  gk   |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, 034-proposed, tbb-wants,   |  Actual Points:
  033-backport, 034-roadmap-proposed |
Parent ID:  #25849   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 What you actually want is not the LLVM target triple, but the Rust target
 triple. So, instead of "LLVM target triple (for Rust)" just use "Rust
 target triple".

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

Re: [tor-bugs] #26119 [Webpages/Website]: Add job posting to website - Localization Project Manager (part-time)

[Tor Bug Tracker & Wiki]

#26119: Add job posting to website - Localization Project Manager (part-time)
--+-
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  closed
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by hiro):

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


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

Re: [tor-bugs] #26022 [Metrics/Statistics]: Fix a flaw in the noise-removing code in our onion service statistics

[Tor Bug Tracker & Wiki]

#26022: Fix a flaw in the noise-removing code in our onion service statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Here's an updated version of the graph from comment 5 that also goes back
 to late 2014 when we started gathering onion service statistics:

 [[Image(hidserv-change-full-task-26022.png​, 700px)]]

 Some thoughts:
  - Some of the numbers for 2015 produced by the fixed `removeNoise()`
 method are up to 15% smaller than those from the flawed method. During
 2015, very few relays were reporting onion service statistics, with the
 [https://metrics.torproject.org/hidserv-frac-
 reporting.html?start=2014-10-01=2018-05-17 fraction not going up
 before late 2015]. The reason for new values being smaller than old values
 is that we're not erroneously adding `bin_size` to negative reported
 statistics anymore.
  - There are very few cases in the first half of 2015 where new values are
 much larger than old values. I believe this is related to another bug in
 our code that made us terminate the module immediately if a consensus did
 not contain a `bandwidth-weights` line. I'm going to fix that, too, but
 it's unrelated to the flawed `removeNoise()` method.
  - The numbers starting in 2016 are almost the same in the new and old
 approach. That's what the previous graph in comment 5 showed, too.

 All in all, I'd say the fixed `removeNoise()` method works just fine.

 I'm starting another run now that uses the simplified `removeNoise()`
 method that only subtracts `bin_size` and does no
 rounding/truncating/flooring at all (as suggested earlier). That will take
 12+ hours.

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

Re: [tor-bugs] #26015 [Metrics/Statistics]: Remove inconsistency between bandwidth history graphs

[Tor Bug Tracker & Wiki]

#26015: Remove inconsistency between bandwidth history graphs
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by iwakeh):

 * reviewer:   => iwakeh


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

Re: [tor-bugs] #26022 [Metrics/Statistics]: Fix a flaw in the noise-removing code in our onion service statistics

[Tor Bug Tracker & Wiki]

#26022: Fix a flaw in the noise-removing code in our onion service statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * Attachment "hidserv-change-full-task-26022.png" 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] #20890 [Applications/Tor Launcher]: Increase connection timeout to avoid "Could not connect to Tor control port" errors

[Tor Bug Tracker & Wiki]

#20890: Increase connection timeout to avoid "Could not connect to Tor control
port" errors
-+
 Reporter:  torrc591 |  Owner:  brade
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201805R, tbb-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by gk):

 * keywords:  TorBrowserTeam201805R => TorBrowserTeam201805R, tbb-backport
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Looks good and applied to `master` (commit
 9aa5fd46cb33528150400a9b94c14ad5e9b7d4ee). Marking for possible backport
 for next stable release.

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

Re: [tor-bugs] #26071 [Internal Services/Tor Sysadmin Team]: Please give Tommy LDAP access

[Tor Bug Tracker & Wiki]

#26071: Please give Tommy LDAP access
-+-
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 Ah, the X was not the username, but the supposed forwarding address.

 Why do we want as username a different one than the current local part,
 which appears to be tommyc. That seems not so smart and potentially
 confusing.

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

Re: [tor-bugs] #26071 [Internal Services/Tor Sysadmin Team]: Please give Tommy LDAP access

[Tor Bug Tracker & Wiki]

#26071: Please give Tommy LDAP access
-+-
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by phoul):

 Replying to [comment:2 weasel]:
 > X seems like a local username that we don't want.  (capitals,
 unreasonably short).

 Hi weasel,

 Sorry about this, I forgot this would create a new email address and
 assumed his old one would be used. Will update this ticket with a new
 signed statement when I speak with Tommy.

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