Re: [tor-bugs] #25448 [Metrics/Onionoo]: allow for URLs that specify list of fingerprints

[Tor Bug Tracker & Wiki]

#25448: allow for URLs that specify list of fingerprints
-+--
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-25448=c9218fbd3b8f029857cca1cde4c16dc5099f129d
 commit c9218fb in my task-25448 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] #26868 [Metrics/Statistics]: How does metrics get bridge statistics at a granularity of 1 user?

[Tor Bug Tracker & Wiki]

#26868: How does metrics get bridge statistics at a granularity of 1 user?
+--
 Reporter:  teor|  Owner:  metrics-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:  not a bug
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

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


Comment:

 Replying to [comment:8 karsten]:
 > Replying to [comment:7 teor]:
 > > ...
 > > * You say that you "Skip dates where frac is smaller than 10% and
 hence too low for a robust estimate"
 > >   * are the snowflake bridges less than 10% of total bridge usage?
 That could be why their numbers vary so much.
 > >   * how do you calculate 10% of bridge usage? (Bridges don't have
 bandwidth, so do you use unique IP addresses?)
 >
 > Wait, no, ''frac'' is the "estimated fraction of reported directory-
 request statistics". It is unrelated to snowflake in particular and refers
 to all bridge usage. The formula for computing ''frac'' is specified in
 Step 3 of the [https://metrics.torproject.org/reproducible-metrics.html
 #relay-users Relay users] section.
 >
 > Please let me know if this makes more sense now, and if not, how we can
 improve it. Thanks!

 Ok, that makes sense. Thank you for explaining!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26641 [Applications/Tor Browser]: problema con l'apertura di siti onion

[Tor Bug Tracker & Wiki]

#26641: problema con l'apertura di siti onion
--+--
 Reporter:  rossicè46 |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by rossicè46):

 ciao hiro,
 si il motore di ricerca duckduckgo si apre, ma altri siti ad eccezione di
 questi non si aprono. io utilizzo un macBook pro con sistema operativo
 high sierra e non trovo la cartella TorBrowser-Data l'ho cercata ovunque
 ma non la trovo.
 help me please.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26802 [Internal Services/Tor Sysadmin Team]: teor LDAP name change

[Tor Bug Tracker & Wiki]

#26802: teor LDAP name change
-+
 Reporter:  teor |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #23914 [Metrics/Onionoo]: Extend flag parameter to support comma-separated list of flags

[Tor Bug Tracker & Wiki]

#23914: Extend flag parameter to support comma-separated list of flags
-+--
 Reporter:  nusenu   |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_review => accepted


Comment:

 Hmm, maybe we can't make this change after all. With the currently planned
 `flag=exit,guard` parameter, we'd return relays that have ''both'' flags
 ('''AND'''). But if we also add a parameter like
 `lookup=fingerprint1,fingerprint2`, we'd return relays with ''either'' of
 the two fingerprints ('''OR'''). This might be too confusing, especially
 if we add more parameters that treat comma-separated values as '''OR''',
 not '''AND'''. Maybe we'll have to fall back to #23913 with two parameters
 `flag=exit` and `flag=guard` to support searches for relays having all
 required flags ('''AND'''). Moving out of review for now.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26848 [Core Tor/sbws]: Create Debian package for sbws

[Tor Bug Tracker & Wiki]

#26848: Create Debian package for sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by irl):

 Replying to [comment:18 teor]:
 > > This is not a real requirement. This is an artificial restriction to
 ensure that deb.tpo packages are well maintained. In the case of sbws I
 think there is a strong argument for an exception.
 >
 > Is there a wiki documenting this requirement?

 I do not know of any such wiki page. There probably should be one.

 > Who can decide to make an exception?

 {{{
 irl@perdulce:~$ getent group tordeb
 tordeb:x:1540:irl,lunar,weasel
 }}}

 > > > Replying to [comment:15 juga]:
 > > > > So you suggest to call sbws "tor-sbws" both for the upstream and
 the Debian package?. Pastly, would you agree with that name change?
 > > >
 > > > It's fine with me if the package is called tor-sbws instead of sbws.
 > >
 > > The upstream name doesn't need to be changed to change the name of the
 Debian package. There are plenty of examples in the python section where
 pysomething is packaged as python-something to have consistent namespace.
 >
 > Please email tor-proj...@lists.torproject.org about the proposed use of
 the trademark, and CC frontd...@rt.torproject.org.

 I would still suggest it's a good idea to rename the package even if it's
 only hosted on deb.tpo.

 When I followed up on the ITP with an extended description for the binary
 package, I realised that this is not only useful to directory authorities
 but may also be useful to those running test networks for research. I
 think on that basis this package would be suitable for inclusion in Debian
 as it's not limited to only the dirauths in its usefulness.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23914 [Metrics/Onionoo]: Extend flag parameter to support comma-separated list of flags

[Tor Bug Tracker & Wiki]

#23914: Extend flag parameter to support comma-separated list of flags
-+--
 Reporter:  nusenu   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |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/user/karsten/onionoo.git/commit/?h=task-23914=49cdff77c4ca95b8a8f4d48b0d8374f4c7b4ad33
 commit 49cdff7 in my task-23914 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] #26868 [Metrics/Statistics]: How does metrics get bridge statistics at a granularity of 1 user?

[Tor Bug Tracker & Wiki]

#26868: How does metrics get bridge statistics at a granularity of 1 user?
+--
 Reporter:  teor|  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Replying to [comment:7 teor]:
 > So, I believe he answer to my question is:
 >
 > "We approximate directory request numbers by multiplying the fraction of
 unique IP addresses from a given country, transport, or IP version with
 the total number of successful requests."

 That would produce smaller numbers than 8, too.

 Another answer is this part: "Split observations to the covered UTC dates
 by assuming a linear distribution of observations."

 We'd have to look at the raw data to say which one is the better answer.
 But I assume your question is mostly answered by knowing that it's not a
 too small number in the original data.

 > But I think there are two missing steps:
 > * Metrics appears to round/truncate/ceiling client numbers to the
 nearest integer

 Right, we're using integer truncation here. We should probably document
 that under Step 4 of the  [https://metrics.torproject.org/reproducible-
 metrics.html#relay-users Relay users] section.

 > * You say that you "Skip dates where frac is smaller than 10% and hence
 too low for a robust estimate"
 >   * are the snowflake bridges less than 10% of total bridge usage? That
 could be why their numbers vary so much.
 >   * how do you calculate 10% of bridge usage? (Bridges don't have
 bandwidth, so do you use unique IP addresses?)

 Wait, no, ''frac'' is the "estimated fraction of reported directory-
 request statistics". It is unrelated to snowflake in particular and refers
 to all bridge usage. The formula for computing ''frac'' is specified in
 Step 3 of the [https://metrics.torproject.org/reproducible-metrics.html
 #relay-users Relay users] section.

 Please let me know if this makes more sense now, and if not, how we can
 improve it. 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] #25459 [Metrics/Statistics]: Add graph that compares total consensus weights across bandwidth authorities (was: Compare total consensus weights across bandwidth authorities)

[Tor Bug Tracker & Wiki]

#25459: Add graph that compares total consensus weights across bandwidth
authorities
+--
 Reporter:  teor|  Owner:  metrics-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * owner:  karsten => metrics-team
 * status:  new => assigned


Comment:

 Sounds good. Blocking on #21378, but once the data is available in
 CollecTor, let's make a new 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] #26916 [Core Tor/Stem]: Make tox config more useful/friendly for running multiple interpreters/versions

[Tor Bug Tracker & Wiki]

#26916: Make tox config more useful/friendly for running multiple
interpreters/versions
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  dev testing|  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Dave, pushed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26922 [Webpages]: Gay hardcore porn

[Tor Bug Tracker & Wiki]

#26922: Gay hardcore porn
---+
 Reporter:  Jamming72  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal | Resolution:
 Keywords:  Gay nasty  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by Dbryrtfbcbhgf):

 This is spam, please close as invalid.

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

Re: [tor-bugs] #23713 [Metrics/Onionoo]: Expand parameters and fields around AS number and names

[Tor Bug Tracker & Wiki]

#23713: Expand parameters and fields around AS number and names
-+--
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please carefully (it was really hot here today) review the last three
 commits
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-23713=225b8753ff50fcd3939b2d933e1f5665d979fa4c
 225b875],
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-23713=4e281b2f88f7c4068ca3f4a9db0f746e303d3998
 4e281b2], and
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-23713=c5eb9d05cb25974d44df5131549f4793a784b23c
 c5eb9d0] in
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-23713
 my task-23713 branch]. 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

[tor-bugs] #26922 [Webpages]: Gay hardcore porn

[Tor Bug Tracker & Wiki]

#26922: Gay hardcore porn
---+---
 Reporter:  Jamming72  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal |   Keywords:  Gay nasty
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 Anal felching raw nasty

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducibly with Stylo enabled using rustc > 1.25.0

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducibly with Stylo enabled 
using
rustc > 1.25.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807,   |  Actual Points:
  GeorgKoppen201807  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:23 gk]:
 > Replying to [comment:22 alexcrichton]:
 > > Hm interesting! I wonder if this is perhaps related to
 https://github.com/rust-lang/rust/issues/52044? That claims it was fixed
 with the most recent LLVM upgrade. Are you able to reproduce the non-
 determinism on the most recent nightly?
 >
 > Aha! That sounds promising and I certainly feel glandium's "This is
 driving me crazy", so this should be the issue then, right? ;)
 >
 > That said, I compiled the nightly from 2018-07-13 which should contain
 the LLVM upgrade and I can't reproduce the problem anymore. However, I
 can't either when compiling the one from from 2018-07-11 which should
 *not* contain the LLVM upgrade (it's based on commit
 e5f6498d3d5c9dac841009d7b49738923826af75). So, it seem the LLVM uprade
 (alone) is not enough to explain this bug, or am I missing something?

 On the other hand testing your script from https://github.com/rust-
 lang/rust/issues/52044#issuecomment-402349038 shows easily that the one
 from 2018-07-13 is good while the one from 2018-07-11 is not. I guess I
 tried the Firefox build just not often enough with 2018-07-11...

 So, what's the suggested way to fix that? What until a new stable compiler
 with a fix for it is out (I guess that's 1.28.0) and use that one?

 Althought, tbh, it's scary to hope this is finally fixed without exactly
 knowing what the issue was. I might try to look closer at it.

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

Re: [tor-bugs] #25695 [Applications/Tor Browser]: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an user onboard

[Tor Bug Tracker & Wiki]

#25695: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an 
user
onboard
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201807  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by mcs):

 Kathy and I are working on implementation of the startup page portion of
 this ticket (that is, about:tor without new user or feature onboarding).
 We have a few questions:
 * Within this new design, how do we let users know that Tor is not working
 correctly? In the old about:tor, the text near the top of the page is
 changed to "Something Went Wrong! Tor is not working in this browser."
 (with a red background).
 * Should about:tor include a link to the Tor Browser manual? I think we
 talked about this during one of our meetings, but I cannot remember our
 conclusion.
 * Will there be a way for users to navigate to
 https://check.torproject.org/ (the old "Test Tor Network Settings" link)?
 * Is it OK to completely remove everything related to update notifications
 from about:tor? I think we decided to use something based on Firefox 60's
 doorhanger-based update notifications, which means we no longer need
 anything related to updates inside the about:tor page.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26807 [Obfuscation/Censorship analysis]: Venezuela blocks access to the Tor network

[Tor Bug Tracker & Wiki]

#26807: Venezuela blocks access to the Tor network
-+-
 Reporter:  ptdetector   |  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 madurosbus):

 cantv (some networks) does redirection of all tcp ports to transparent
 proxy, most of proxies behaves like TPROXY but some reveals non client IP
 address.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducibly with Stylo enabled using rustc > 1.25.0

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducibly with Stylo enabled 
using
rustc > 1.25.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807,   |  Actual Points:
  GeorgKoppen201807  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alexcrichton):

 Ah yeah for the LLVM 7 change we're gonna let that ride the trains (aka
 not backport). If you can temporarily use a nightly that'd work but
 otherwise this may have to wait until that's released.

 Knowing for sure though what was causing the nondeterminism in LLVM would
 be great!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26923 [Obfuscation/Pluggable transport]: Intent to create Pluggable Transport: HTTPS proxy

[Tor Bug Tracker & Wiki]

#26923: Intent to create Pluggable Transport: HTTPS proxy
-+-
 Reporter:  sf   |  Owner:  asn
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 = httpsproxy =
 HTTP CONNECT method is one of the standard ways to proxy internet traffic,
 which is used both in [https://tools.ietf.org/html/rfc2616#section-9.9
 HTTP/1.1] and [https://http2.github.io/http2-spec/#CONNECT HTTP/2]. HTTPS
 traffic is very popular on the web, and pluggable transports could benefit
 from this fact. There's very high collateral damage that would result from
 full HTTPS blocking, and it adds diversity to PTs’ shapes because most
 current PTs do not resemble HTTPS.

 Usage of HTTPS proxies also helps with active probing: a proxy can be an
 actual web server that serves content, as opposed to circumvention
 technologies, that don't show any apparent collateral damage nor respond
 in any way, when probed. To a prober that doesn't have correct
 credentials, httpsproxy server can look like a real web server, if it is a
 real web server.

 == Way to use it HTTPS proxies with Tor ==
 === Naive proxy ===
 Given correct credentials, user can request any standard forwardproxy on
 the web to connect to Tor. Client establishes TLS connection to the web
 proxy, and sends request in a form of

 {{{
 CONNECT 0.1.2.3:9001 HTTP/1.1
 Host: 0.1.2.3
 Proxy-Authorization: Basic dXNlcjpwYXNz
 }}}
 where 0.1.2.3:9001 is address of arbitrary vanilla Tor entry node. Web
 Server would establish tcp connection to this address and relay subsequent
 traffic to it.

 Such an approach allows us to use a diverse set of standard proxies: a
 webproxy is easy to set up and does not need to speak Tor. However, the
 web proxy operator will likely want to whitelist Tor entrance nodes in
 order to prevent abuse. As such, they would benefit from talking to some
 sort of https-proxy-authority, which would provide an entrance node(s) to
 whitelist, and allow proxies to let Tor Project know that their servers
 could be used as a proxy.

 While lack of server-side PT makes it easier to deploy, it also means we
 cannot collect metrics.

 === Full Bridge ===
 A full bridge runs a Tor entry node, a pluggable transport and an
 upstreaming frontend webserver. The upstreaming webserver would check
 credentials, and, instead of consuming CONNECT requests, it would upstream
 them into the pluggable transport ExtORPort, while also stapling client’s
 IP to it in a header. The PT would parse the IP from the HTTP request
 header, and pass it to ExtORPort, thus enabling metrics collection.

 == Registering with BridgeDB ==
 As it currently stands, bridges have to have an ORPort open to be
 registered with BridgeDB #7349
 This leads to easy identification and blocking of bridges. However, we can
 still register bridge lines with BridgeDB, if we add an additional hop to
 an intermediate proxy before entering a bridge. A censor would only be
 able to observe the address of the intermediate proxy.

 Having such a 2-hop setup is a natural property of Naive Proxy, as
 described above. Bridge line example:

 {{{
 httpsproxy [vanilla entry addr] [entry fingerprint]
 url=https://username:passw...@naiveproxy.org
 }}}
 We can use 2-hop approach with full bridges as well: the intermediate
 proxy would forward HTTP request (preferably with client IP in “Forwarded:
 for=IP:port” header). In this case, intermediate proxy just redirects all
 requests (as long as credentials are correct) to the chosen full
 bridge(s), which is essentially a reverse proxy -- a widely supported
 technology.

 While the second hop adds overhead, there's a benefit in not requiring
 would-be proxy operators to run a full bridge, since configuration of a
 proxy now becomes substantially easier, and, ideally, would amount to
 adding a few lines to a web server config file and registering themselves
 w/ bridgeDB via some script. Not requiring them to install, configure and
 run both PT and Tor daemons may allow us to attract a bigger amount of
 volunteers for the entrance servers.

 However it’s unclear which party and how would actually register the
 bridge line. Perhaps, a separate https-proxy-authority could do that (and
 provide web proxies with entries to use)

 == Current prototype ==
 Works with standard HTTP/1.1 and HTTP/2.0 proxies with both naive proxies
 and full bridges. If there's an interest in seeing current prototype, I
 would gladly share it, @dcf already created ticket for 

Re: [tor-bugs] #25695 [Applications/Tor Browser]: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an user onboard

[Tor Bug Tracker & Wiki]

#25695: Activity 5.1: Redesign Tor Browser homepage ("about:tor") - create an 
user
onboard
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201807  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 hey! happy to have you working on it :)

 Replying to [comment:19 mcs]:
 >Within this new design, how do we let users know that Tor is not working
 correctly? In the old about:tor, the text near the top of the page is
 changed to "Something Went Wrong! Tor is not working in this browser."
 (with a red background).

 I think someone mentioned it before on another ticket; does exist a
 situation where Tor Browser is not connected to Tor Network?

 >Should about:tor include a link to the Tor Browser manual? I think we
 talked about this during one of our meetings, but I cannot remember our
 conclusion.

 We are linking to the manual in a lot of cards at the onboarding. We can
 have a link at `about:tor` too for sure.


 >Will there be a way for users to navigate to
 https://check.torproject.org/ (the old "Test Tor Network Settings" link)?

 The first time I thought about `about:tor` came to my mind the idea to
 have check.torproject.org status just there. But then, the same question:
 Which is the situation where Tor Browser loads and not connect to Tor?
 Anyways, "You're connected to the Tor Network" string was inspired
 directly by check.tpo. What would be wrong if we take it from there?


 >Is it OK to completely remove everything related to update notifications
 from about:tor? I think we decided to use something based on Firefox 60's
 doorhanger-based update notifications, which means we no longer need
 anything related to updates inside the about:tor page.

 Yes, exactly. I'm going to back to Update Tor ticket I hope this week. So
 far, we discussed to have everything running at the doorhanger. I
 suggested having the red `about:tor`  for old Tor Browser versions ->
 https://trac.torproject.org/projects/tor/attachment/ticket/25694/1.0.2.png.
 Both cases can work together and that `about:tor` status is an ongoing
 discussion at #25694.


 Question for you now :)

 * Could we load our brand typography? or do you prefer to stick with
 system fonts? https://styleguide.torproject.org/visuals/#typography
 * is okay an SVG for the circle's pattern at the background? or do you
 prefer a png/jpg?

 Can't wait to see it live!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24217 [Metrics/Statistics]: Specify data format and aggregation process of statistics offered by metrics.tp.o

[Tor Bug Tracker & Wiki]

#24217: Specify data format and aggregation process of statistics offered by
metrics.tp.o
+---
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by karsten):

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


Comment:

 Looks like I opened #26857 when I could as well have revived the
 discussion on this ticket. Anyway, I looked through the comments above and
 did not find anything that's left unaddressed. Closing as near duplicate.

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

Re: [tor-bugs] #26922 [Webpages]: Gay hardcore porn

[Tor Bug Tracker & Wiki]

#26922: Gay hardcore porn
---+-
 Reporter:  Jamming72  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal | Resolution:  invalid
 Keywords:  Gay nasty  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by sukhbir):

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


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

Re: [tor-bugs] #25448 [Metrics/Onionoo]: allow for URLs that specify list of fingerprints

[Tor Bug Tracker & Wiki]

#25448: allow for URLs that specify list of fingerprints
-+--
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by irl):

 * reviewer:   => irl


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23713 [Metrics/Onionoo]: Expand parameters and fields around AS number and names

[Tor Bug Tracker & Wiki]

#23713: Expand parameters and fields around AS number and names
-+--
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I assume here that the comma-seperated list is to match any (union)? It is
 possible for a prefix to be announced by multiple AS in BGP and a future
 data source might provide all the ASs an IP address may be found in, not
 just one, so a match on all (intersection) is also a legitimate use case.

 The first two bullet points look good.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6947 [Metrics/Onionoo]: Allow filtering relays by version ranges

[Tor Bug Tracker & Wiki]

#6947: Allow filtering relays by version ranges
-+--
 Reporter:  rransom  |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 Replying to [comment:9 karsten]:
 > However, I'm not sure what the most intuitive interface is. Maybe it's
 something else, like a different character for ranges, such as
 `/details?version=0.3.2.1:0.3.2.5`. (If so, we should consider changing
 `first_seen_days` and `last_seen_days`, too, for consistency.)

 I think using `:` for ranges is better, as long as we can be certain that
 we'll never see a `:` in a released Tor version. We should probably
 require this in torspec somewhere. If we do a major version change, which
 I think we should for this, then we would also change
 `{first,last}_seen_days`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26918 [Internal Services/Wiki]: Restructure our Tor Browser HACKING document

[Tor Bug Tracker & Wiki]

#26918: Restructure our Tor Browser HACKING document
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * owner:  (none) => tbb-team
 * 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

[tor-bugs] #26918 [Internal Services/Wiki]: Restructure our Tor Browser HACKING document

[Tor Bug Tracker & Wiki]

#26918: Restructure our Tor Browser HACKING document
+
 Reporter:  gk  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 Our Tor Browser HACKING document has grown over the years in a way that it
 might be smarter to restructure it, so that its usefulness is not
 impacted.

 Ideas would be moving Orbot/Orfox to different (sub)-pages. Moving the
 debugging guides to an own page as well etc.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26641 [Applications/Tor Browser]: problema con l'apertura di siti onion

[Tor Bug Tracker & Wiki]

#26641: problema con l'apertura di siti onion
--+--
 Reporter:  rossicè46 |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hiro):

 Ciao,
 La cartella che cerchi e' questa qui:
 ~/Library/Application Support/TorBrowser-Data/
 Se apri la tua home nel mac, trovi la cartella "Library", dentro c'e'
 un'altra cartella, chiamata "Application Support". Dentro "Application
 Support" trovi la cartella "TorBrowser-Data".

 Inoltre ti chiedo di provare alcuni dei siti onion della nostra lista:
 https://onion.torproject.org/
 Se questi funzionano, probabilmente c'e' un problema con gli altri siti
 che stai cercando di accedere.
 Fammi sapere.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26903 [Core Tor/Tor]: Document what 'GETINFO net/listeners/*' do

[Tor Bug Tracker & Wiki]

#26903: Document what 'GETINFO net/listeners/*' do
--+--
 Reporter:  atagar|  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

 * status:  new => needs_review


Comment:

 https://github.com/torproject/torspec/pull/30

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducibly with Stylo enabled using rustc > 1.25.0

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducibly with Stylo enabled 
using
rustc > 1.25.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807,   |  Actual Points:
  GeorgKoppen201807  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:23 gk]:
 > Replying to [comment:22 alexcrichton]:
 > > Hm interesting! I wonder if this is perhaps related to
 https://github.com/rust-lang/rust/issues/52044? That claims it was fixed
 with the most recent LLVM upgrade. Are you able to reproduce the non-
 determinism on the most recent nightly?

 [snip]

 > Trying to figure out where all this started, I am pretty sure that
 2018-02-15 is good and 2018-03-07 is bad.

 So, here is another interesting bit: While running the script
 (https://github.com/rust-lang/rust/issues/52044#issuecomment-402349038) on
 a Linux box does replicate the issue for a Linux build using the nightly
 from 2018-07-11, it does not replicate it using the nightly from
 2018-03-07 (I ran the script a couple of times). On the other hand, using
 the nightly from 2018-03-07 to generate a Firefox build for macOS does
 show differences (while, as mentioned above, I seemingly can't reproduce
 the problem with the nightly from 2018-07-11 anymore when cross-compiling
 for macOS).

 To test better I adapted your repro script and added a respective
 `--target x86_64-apple-darwin` and with that setup it's easy to see the
 bug with the nightly from 2018-03-07.

 So, to sum up, the problem is not just bumping the LLVM version but it
 seems to be somewhat target dependent, too.

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

Re: [tor-bugs] #26793 [Internal Services/Service - git]: Create /pluggable-transports/httpsproxy repo

[Tor Bug Tracker & Wiki]

#26793: Create /pluggable-transports/httpsproxy repo
-+
 Reporter:  dcf  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  httpsproxy pt|  Actual Points:
Parent ID:  #26923   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

 * keywords:   => httpsproxy pt
 * cc: fs (removed)
 * cc: sf (added)
 * parent:   => #26923


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26228 [Core Tor/Tor]: Clarify/determine specification for padding bytes, (formerly also PADDING cell)

[Tor Bug Tracker & Wiki]

#26228: Clarify/determine specification for padding bytes, (formerly also 
PADDING
cell)
--+
 Reporter:  dmr   |  Owner:  dmr
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:  #26869| Points:
 Reviewer:|Sponsor:
--+

Comment (by dmr):

 Replying to [comment:15 teor]:
 > Please see my branch 26228-padding-bytes on
 ​https://github.com/teor2345/torspec.git , which also fixes #26870 and
 contains the spec for #26871.

 Now tracking all of #26228, #26870, #26871 in this pull request:
 https://github.com/torproject/torspec/pull/28

 (teor, I pushed your branch's changes into that PR)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26870 [Core Tor/Tor]: Spec: clarify inconsistency for [V]PADDING/DROP cell content vs. padding bytes

[Tor Bug Tracker & Wiki]

#26870: Spec: clarify inconsistency for [V]PADDING/DROP cell content vs. padding
bytes
--+
 Reporter:  dmr   |  Owner:  dmr
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:  #26228| Points:
 Reviewer:|Sponsor:
--+

Comment (by dmr):

 Replying to [comment:3 teor]:
 > I fixed this in #26228.

 Now tracking all of #26228, #26870, #26871 in this pull request:
 https://github.com/torproject/torspec/pull/28

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26848 [Core Tor/sbws]: Create Debian package for sbws

[Tor Bug Tracker & Wiki]

#26848: Create Debian package for sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Replying to [comment:18 teor]:
 [...]
 > Please email tor-proj...@lists.torproject.org about the proposed use of
 the trademark, and CC frontd...@rt.torproject.org.

 Done: https://lists.torproject.org/pipermail/tor-
 project/2018-July/001912.html

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

Re: [tor-bugs] #26923 [Obfuscation/Pluggable transport]: Intent to create Pluggable Transport: HTTPS proxy

[Tor Bug Tracker & Wiki]

#26923: Intent to create Pluggable Transport: HTTPS proxy
-+-
 Reporter:  sf   |  Owner:  asn
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  pt httpsproxy|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * keywords:   => pt httpsproxy


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26871 [Core Tor/Tor]: prop289: randomize the unused part of relay payloads

[Tor Bug Tracker & Wiki]

#26871: prop289: randomize the unused part of relay payloads
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711   |
Parent ID:  #26288   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dmr):

 Replying to [comment:7 teor]:
 > I patched tor-spec to randomise relay cell padding, see:
 >
 > https://trac.torproject.org/projects/tor/ticket/26228#comment:15

 Now tracking all of #26228, #26870, #26871 in this pull request:
 https://github.com/torproject/torspec/pull/28

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, certs, handshake, |  Actual Points:
  ed25519, 035-roadmap-proposed, 035-must,   |
  fast-fix, 035-triaged-in-20180711  |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Travis CI passed all three branches:
 * bug26627_032: https://travis-ci.org/teor2345/tor/builds/407846838
 * bug26627_033: https://travis-ci.org/teor2345/tor/builds/407847054
 * bug26627_033_merged_master: https://travis-
 ci.org/teor2345/tor/builds/407847143

 Appveyor CI passed, it's only active for 0.3.5:
 * bug26627_033_merged_master:
 https://ci.appveyor.com/project/teor2345/tor/build/1.0.8

 Please see the bug26627_032 pull request for review:
 https://github.com/torproject/tor/pull/248

 (bug26627_033 is a non-trivial merge due to changed context.
 bug26627_033_merged_master is a trivial merge of bug26627_033.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, certs, handshake, |  Actual Points:
  ed25519, 035-roadmap-proposed, 035-must,   |
  fast-fix, 035-triaged-in-20180711  |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * 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] #21952 [Webpages]: .Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: .Onion everywhere?: increasing the use of onion services through 
automatic
redirects and aliasing
-+--
 Reporter:  linda|  Owner:  linda
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Webpages |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Perhaps you saw already: Cloudflare's DNS HTTPS server sends an `Alt-Svc`
 that points to an onion.
 https://blog.cloudflare.com/welcome-hidden-resolver/
 > How can the users remember this address?
 >
 > We don’t think you should need to remember this address. Ideally, all
 you would need to do is go to [https://tor.cloudflare-dns.com/ https://tor
 .cloudflare-dns.com] and have the browser route your request to the .onion
 address. This is possible using the "[https://tools.ietf.org/html/rfc7838
 Alt-Svc]" HTTP header which is an optional header notifying the browser
 that the resources can be accessed from an alternative network location,
 possibly using a different protocol. Thanks to
 [https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/
 Mozilla], using .onion addresses as alternative services is now possible
 in [https://nightly.mozilla.org/ Firefox Nightly].

 When I go to https://tor.cloudflare-dns.com/, I see
 {{{
 Alt-Svc:
 h2="dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443";
 ma=31536; persist=1
 }}}

 As far as I can tell, the `Alt-Svc` header doesn't actually ''do''
 anything yet in Tor Browser (maybe it does in Firefox), but there is
 #26365.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26926 [Core Tor/sbws]: Binaries should have manual pages (man)

[Tor Bug Tracker & Wiki]

#26926: Binaries should have manual pages (man)
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #26848 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 https://github.com/pastly/simple-bw-scanner/pull/240

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26924 [Core Tor/Tor]: Make single onion service to rend and Tor2web to intro link authentication into a protocol warning

[Tor Bug Tracker & Wiki]

#26924: Make single onion service to rend and Tor2web to intro link 
authentication
into a protocol warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:  Tor: 0.3.2.4-alpha
  Tor/Tor|   Keywords:  tor-relay, certs, handshake,
 Severity:  Normal   |  ed25519, 035-roadmap-proposed, 035-must, fast-
 |  fix, 035-triaged-in-20180711
Actual Points:   |  Parent ID:  #26627
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Single onion services and Tor2web connect directly to relays using
 untrusted link authentication keys.

 These connections can cause a lot of warnings, particularly due to the
 link auth bugs in #26627.

 We can either:
 * downgrade all link auth warnings to protocol warnings on single onion
 services and Tor2web (this is the fast fix)
 * taint untrusted link auth keys, and then downgrade connections using
 tainted keys to protocol warnings (this is very intrusive)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, certs, handshake, |  Actual Points:
  ed25519, 035-roadmap-proposed, 035-must,   |
  fast-fix, 035-triaged-in-20180711  |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Please see my branches bug26627_032 and bug26627_033 on
 https://github.com/teor2345/tor.git
 * I did a forced update on bug26627_032 to rebase to get CI working
 * bug26627_033 merges cleanly to master (see bug26627_033_merged_master)

 Here's what I fixed:
 * backport #20895 and #23577 from 0.3.3 to 0.3.2
   * without the backport, clients can't check if the node supports ed25519
 link auth
   * these backports also make v3 client intro behaviour consistent between
 0.3.3+ and 0.3.2
 * only send ed25519 link specifiers in client intros if the rend point
 supports ed25519 link auth
 * only send ed25519 link specifiers in service descriptors if the intro
 point supports ed25519 link auth

 Relays already behave correctly:
 * all relays log a protocol warning when a client asks them to extend to
 an ed25519 id, but the relay they're extending to doesn't support ed25519
 link authentication

 I'm going to split off into #26924:
 * make v3 single onion service to rend link authentication into a protocol
 warning

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26409 [Applications/Tor Browser]: Language prompt is shown twice at first start in Tor Browser based on ESR60

[Tor Bug Tracker & Wiki]

#26409: Language prompt is shown twice at first start in Tor Browser based on 
ESR60
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  AffectsTails, TorBrowserTeam201807 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by intrigeri):

 Is there a chance this will be fixed by August 7? If not, I'll try to
 schedule time on August 8-9 to work on this myself.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26925 [Core Tor/Tor]: Make link specifier handling in rend-spec-v3 more precise

[Tor Bug Tracker & Wiki]

#26925: Make link specifier handling in rend-spec-v3 more precise
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-spec, doc, tor-relay, certs,
 Severity:  Normal   |  handshake, ed25519, 035-roadmap-proposed,
 |  035-must, fast-fix, 035-triaged-in-20180711
Actual Points:   |  Parent ID:  #26627
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Split off #26627.

 We should specify that clients and services must not check untrusted link
 specifiers against the consensus:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705

 Services should also copy unrecognized rend point link specifiers from the
 introduce cell to the rendezvous join cell.
 We can copy the text from the client intro spec:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
 To the service rend spec:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705

 Thanks to catalyst for picking up on these missing parts of the 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] #24868 [Core Tor/Tor]: Check a consensus parameter before activating onion service IPv6 features

[Tor Bug Tracker & Wiki]

#24868: Check a consensus parameter before activating onion service IPv6 
features
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, must-do-before-033-stable,   |
  033-triage-20180320, 033-removed-20180320  |
Parent ID:  #26627   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => closed
 * resolution:   => wontfix
 * parent:  #23493 => #26627


Comment:

 We didn't get this feature in 0.3.3, so introducing it now would make
 clients more fingerprintable.

 Instead, we make 0.3.2 clients behave the same as 0.3.3 clients as a side
 effect of #26627.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26926 [Core Tor/sbws]: Binaries should have manual pages (man)

[Tor Bug Tracker & Wiki]

#26926: Binaries should have manual pages (man)
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #26848
   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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, certs,|  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-relay, certs, handshake, ed25519, 035-roadmap-proposed, 035-must,
 fast-fix, 035-triaged-in-20180711
 =>
 tor-hs, tor-relay, certs, handshake, ed25519, 035-roadmap-proposed,
 035-must, fast-fix, 035-triaged-in-20180711


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26927 [Core Tor/Tor]: Improve the log message when peer id authentication fails

[Tor Bug Tracker & Wiki]

#26927: Improve the log message when peer id authentication fails
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:  Tor: 0.3.0.1-alpha
  Tor/Tor|   Keywords:  tor-relay, certs, handshake,
 Severity:  Normal   |  ed25519, 035-roadmap-proposed, 035-must, fast-
 |  fix, 035-triaged-in-20180711
Actual Points:   |  Parent ID:  #26924
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Split off #26924.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, certs,|  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711,   |
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-hs, tor-relay, certs, handshake, ed25519, 035-roadmap-proposed,
 035-must, fast-fix, 035-triaged-in-20180711
 =>
 tor-hs, tor-relay, certs, handshake, ed25519, 035-roadmap-proposed,
 035-must, fast-fix, 035-triaged-in-20180711, 032-backport,
 033-backport, 034-backport


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

[tor-bugs] #26928 [Core Tor/Tor]: Taint untrusted link authentication keys

[Tor Bug Tracker & Wiki]

#26928: Taint untrusted link authentication keys
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should taint untrusted link auth keys, and then downgrade connections
 using tainted keys to protocol warnings.

 Link auth keys from the following sources are trusted:
 * hard-coded authorities
 * the consensus signed by hard-coded authorities

 Link auth keys from the following sources are untrusted:
 * hardcoded fallback dirs, because relay keys change over time
 * our state file (if not confirmed in the consensus), because relay keys
 change over time
 * onion service descriptors, because they come from untrusted services
 * onion service introduce cells, because they come from untrusted clients

 Split off #26924.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26709 [Core Tor/Tor]: Onion V3 addresses not always working

[Tor Bug Tracker & Wiki]

#26709: Onion V3 addresses not always working
-+-
 Reporter:  time_attacker|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  onion, tor-hs, 034-backport, |  Actual Points:
  033-backport, 032-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dmr):

 * cc: dmr (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] #26924 [Core Tor/Tor]: Make single onion service to rend and Tor2web to intro link authentication into a protocol warning

[Tor Bug Tracker & Wiki]

#26924: Make single onion service to rend and Tor2web to intro link 
authentication
into a protocol warning
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-log, tor-relay, certs,   |  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711,   |
  029-backport, 032-backport, 033-backport,  |
  034-backport   |
Parent ID:  #26627   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-relay, certs, handshake, ed25519, 035-roadmap-proposed, 035-must,
 fast-fix, 035-triaged-in-20180711
 =>
 tor-hs, tor-log, tor-relay, certs, handshake, ed25519, 035-roadmap-
 proposed, 035-must, fast-fix, 035-triaged-in-20180711, 029-backport,
 032-backport, 033-backport, 034-backport
 * status:  assigned => needs_review
 * version:  Tor: 0.3.2.4-alpha => Tor: 0.2.9.1-alpha


Comment:

 I chose the easy option, and opened #26928 for follow-up in some future
 release.

 Please see my branches at https://github.com/teor2345/tor.git :
 * bug26924_029 - downgrades Tor2web and single onion service link auth
 failures to a protocol warning
 * bug26924_032 - also improves the actual log message so it says "RSA +
 ed25519" (see #26927)
 * bug26924 - fixes an include path for the mass refactor in master

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

Re: [tor-bugs] #26927 [Core Tor/Tor]: Improve the log message when peer id authentication fails

[Tor Bug Tracker & Wiki]

#26927: Improve the log message when peer id authentication fails
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, certs, handshake, |  Actual Points:
  ed25519, 035-roadmap-proposed, 035-must,   |
  fast-fix, 035-triaged-in-20180711, |
  029-backport, 032-backport, 033-backport,  |
  034-backport   |
Parent ID:  #26924   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * keywords:
 tor-relay, certs, handshake, ed25519, 035-roadmap-proposed, 035-must,
 fast-fix, 035-triaged-in-20180711
 =>
 tor-relay, certs, handshake, ed25519, 035-roadmap-proposed, 035-must,
 fast-fix, 035-triaged-in-20180711, 029-backport, 032-backport,
 033-backport, 034-backport


Comment:

 This bug is fixed in my #26924 branches, it can close when #26924 closes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26852 [Core Tor/Tor]: doc: document Appveyor CI setup

[Tor Bug Tracker & Wiki]

#26852: doc: document Appveyor CI setup
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  doc, fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dmr):

 * cc: dmr (added)
 * status:  needs_review => closed
 * resolution:   => implemented


Comment:

 Replying to [comment:2 nickm]:
 > lgtm; merged.

 Looks like the ticket wasn't closed.

 I //do// see this merged in, in
 
[[https://gitweb.torproject.org/tor.git/commit/?id=88bb80d5fc83e97cb099cb4887d83a2400fd9830|88bb80d5fc83e97cb099cb4887d83a2400fd9830]].
 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] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  not-just-linux, tor-ci, teor-was-|  Actual Points:
  assigned, 034-triage-20180328, |
  034-removed-20180328, 034-backport,|
  035-removed-20180711   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by dmr):

 * cc: dmr (added)
 * status:  assigned => new


Comment:

 `assigned` without an owner seems like an invalid (or at least misleading)
 state.
 Bumping to `new` again.

 (Feel free to correct me if this is wrong.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26409 [Applications/Tor Browser]: Language prompt is shown twice at first start in Tor Browser based on ESR60

[Tor Bug Tracker & Wiki]

#26409: Language prompt is shown twice at first start in Tor Browser based on 
ESR60
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  AffectsTails, TorBrowserTeam201807 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 There is!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26925 [Core Tor/Tor]: Make link specifier handling in rend-spec-v3 more precise

[Tor Bug Tracker & Wiki]

#26925: Make link specifier handling in rend-spec-v3 more precise
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, doc, tor-relay, certs, |  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711|
Parent ID:  #26627   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review


Old description:

> Split off #26627.
>
> We should specify that clients and services must not check untrusted link
> specifiers against the consensus:
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
>
> Services should also copy unrecognized rend point link specifiers from
> the introduce cell to the rendezvous join cell.
> We can copy the text from the client intro spec:
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
> To the service rend spec:
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
>
> Thanks to catalyst for picking up on these missing parts of the spec.

New description:

 Split off #26627.

 We should specify that clients and services must not check untrusted link
 specifiers against the consensus:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705

 Services should also copy unrecognized rend point link specifiers from the
 introduce cell to the rendezvous join cell.
 We can copy the text from the client intro spec:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
 To the service rend spec:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705

 Thanks to catalyst for picking up on these missing parts of the spec.

 Edit: fix line numbers

--

Comment:

 See my branch bug26925 on https://github.com/teor2345/torspec.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] #26925 [Core Tor/Tor]: Make link specifier handling in rend-spec-v3 more precise

[Tor Bug Tracker & Wiki]

#26925: Make link specifier handling in rend-spec-v3 more precise
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, doc, tor-relay, certs, |  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711|
Parent ID:  #26627   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> Split off #26627.
>
> We should specify that clients and services must not check untrusted link
> specifiers against the consensus:
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
>
> Services should also copy unrecognized rend point link specifiers from
> the introduce cell to the rendezvous join cell.
> We can copy the text from the client intro spec:
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
> To the service rend spec:
> https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
>
> Thanks to catalyst for picking up on these missing parts of the spec.
>
> Edit: fix line numbers

New description:

 Split off #26627.

 We should specify that clients and services must not check untrusted link
 specifiers against the consensus:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705

 Services should also copy unrecognized rend point link specifiers from the
 introduce cell to the rendezvous join cell.
 We can copy the text from the service intro->rend spec:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1705
 To the the client desc->intro spec:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1338

 Thanks to catalyst for picking up on these missing parts of the spec.

 Edit: fix line numbers

--

Comment (by teor):

 Now I have the right line numbers in the description.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #7349, #17159, #18644, #19552, ...

[Tor Bug Tracker & Wiki]

Batch modification to #7349, #17159, #18644, #19552, #20068, #20142, #21600, 
#21621, #22815, #24805, #24838, #25208, #25324, #25786, #25796, #25963 by teor:


Action: new

Comment:
Make everything that is assigned to no-one new again.

--
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] #26910 [Core Tor/Tor]: Could tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)

[Tor Bug Tracker & Wiki]

#26910: Could tor drop privileges even earlier? (before trying to access 
anything
on the filesystem beyond its torrc files)
--+--
 Reporter:  nusenu|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by weasel):

 * cc: weasel (added)


Comment:

 Yes, please.

 The Debian service file still needs to give tor the CAP_DAC_READ_SEARCH
 capability (which lets uid 0 override DAC file permissions for read/search
 purposes) or else it falls flat on its face with hidden services (cf.
 [https://bugs.debian.org/847598 Debian#847598]).  We'd appreciate if Tor
 did not need this elevated capability.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #9145 [Applications/Tor Browser]: Tor Browser for Windows is borked with hardware acceleration enabled (because of gcc?)

[Tor Bug Tracker & Wiki]

#9145: Tor Browser for Windows is borked with hardware acceleration enabled
(because of gcc?)
-+-
 Reporter:  dope457  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, fuck-mingw, ff60-esr, |  Actual Points:
  TorBrowserTeam201807   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-crash, fuck-mingw, ff60-esr, TorBrowserTeam201807R => tbb-
 crash, fuck-mingw, ff60-esr, TorBrowserTeam201807


Comment:

 Replying to [comment:44 sukhbir]:
 > Tor Browser (should this have been a `fixup` commit perhaps?):

 Yes, please. You could add some more info doing a `git commit --amend`, so
 that everyone can later on look at `tor-browser-60.1.0esr-8.0-1` to find
 out why the prefs are gone now (i.e. before the rebase happens and the
 fixup commits vanishes).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #9145 [Applications/Tor Browser]: Tor Browser for Windows is borked with hardware acceleration enabled (because of gcc?)

[Tor Bug Tracker & Wiki]

#9145: Tor Browser for Windows is borked with hardware acceleration enabled
(because of gcc?)
-+-
 Reporter:  dope457  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, fuck-mingw, ff60-esr, |  Actual Points:
  TorBrowserTeam201807   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sukhbir):

 * status:  needs_revision => needs_review


Comment:

 https://github.com/azadi/tor-browser-build-1/tree/bug-9145-rev1

 https://github.com/azadi/gecko-dev/tree/bug-9145-rev2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26920 [Applications/Tor Browser]: Deploy Marionette as a Pluggable Transport

[Tor Bug Tracker & Wiki]

#26920: Deploy Marionette as a Pluggable Transport
--+--
 Reporter:  Marionette|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Marionette|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * owner:  asn => tbb-team
 * priority:  Very High => Medium
 * component:  Obfuscation/Pluggable transport => Applications/Tor Browser
 * cc: dcf (added)


Comment:

 [https://lists.torproject.org/pipermail/tor-dev/2018-July/01.html tor-
 dev thread]
 > We are now ready to integrate Marionette, or at least have it evaluated,
 as a bridge for the Tor browser in its Pythonless form.
 >
 > At the Tor meeting in March, we successfully operated Marionette as a
 bridge by implementing the PT v2.0 specification (Thanks ahf!).
 >
 > Now we have a new version of Marionette which operates as a stand-alone
 binary (NO PYTHON!).  I checked that it still forms a bridge, like at the
 Tor meeting.  We also have a wider variety of transports enabled.
 >
 > We are in the process of writing the documentation for Marionette, but
 the documentation on the web page should be sufficient for at least
 getting a full evaluation started.  We'd like to have the evaluation
 complete by the end of next month, hopefully the middle of next month, and
 stand ready to make any and all changes necessary.
 >
 > A full set of documentation will also be written for designing your own
 protocols.  This is in process.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25448 [Metrics/Onionoo]: allow for URLs that specify list of fingerprints

[Tor Bug Tracker & Wiki]

#25448: allow for URLs that specify list of fingerprints
-+-
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 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] #26910 [Core Tor/Tor]: Could tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)

[Tor Bug Tracker & Wiki]

#26910: Could tor drop privileges even earlier? (before trying to access 
anything
on the filesystem beyond its torrc files)
--+--
 Reporter:  nusenu|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 I'm not sure I understand: How would Tor know which user to switch to (or
 which other privileges to drop) if it has not first read the torrc file?
 And would reading the torrc file not count as using the filesystem?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26903 [Core Tor/Tor]: Document what 'GETINFO net/listeners/*' do

[Tor Bug Tracker & Wiki]

#26903: Document what 'GETINFO net/listeners/*' do
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26919 [Metrics/Onionoo]: Remove fingerprint parameter

[Tor Bug Tracker & Wiki]

#26919: Remove fingerprint parameter
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 Can you pull the stats on how many requests were made with the parameters?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23713 [Metrics/Onionoo]: Expand parameters and fields around AS number and names

[Tor Bug Tracker & Wiki]

#23713: Expand parameters and fields around AS number and names
-+--
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:5 irl]:
 > I assume here that the comma-seperated list is to match any (union)? It
 is possible for a prefix to be announced by multiple AS in BGP and a
 future data source might provide all the ASs an IP address may be found
 in, not just one, so a match on all (intersection) is also a legitimate
 use case.

 Well, my (possibly flawed) plan was to use comma-separated lists for
 unions (`as=1,2,3` for relays in any of those three ASes) and repeatedly
 stated parameters for intersections (`as=1=2=3` for relays announced
 by all three ASes).

 > The first two bullet points look good.

 Okay, great, I already started writing some code for them that I'll bring
 here for review as soon as it's ready.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6947 [Metrics/Onionoo]: Allow filtering relays by version ranges

[Tor Bug Tracker & Wiki]

#6947: Allow filtering relays by version ranges
-+--
 Reporter:  rransom  |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:10 irl]:
 > Replying to [comment:9 karsten]:
 > > However, I'm not sure what the most intuitive interface is. Maybe it's
 something else, like a different character for ranges, such as
 `/details?version=0.3.2.1:0.3.2.5`. (If so, we should consider changing
 `first_seen_days` and `last_seen_days`, too, for consistency.)
 >
 > I think using `:` for ranges is better, as long as we can be certain
 that we'll never see a `:` in a released Tor version. We should probably
 require this in torspec somewhere. If we do a major version change, which
 I think we should for this, then we would also change
 `{first,last}_seen_days`.

 Hmm, on second thought, `:` wouldn't work so well with qualified search
 terms. Imagine a search for `version:0.3.2.1:0.3.2.5` (for versions
 0.3.2.1, 0.3.2.2, 0.3.2.3, 0.3.2.4, and 0.3.2.5) or even
 `version::0.3.2.5` (for everything ''until'' 0.3.2.5) or
 `version:0.3.2.1:` for 0.3.2.1 or newer).

 New idea (sorry for the brainstorming, I'm just trying to find the best
 solution): `..`, as in `version:0.3.2.1..0.3.2.5` or `version:..0.3.2.5`
 or `version:0.3.2.1..` for the examples given above. Yet unimplemented, so
 no guarantee that it will work well in all cases. We'd only have to
 require that versions don't contain two consecutive `.`, but that should
 be a safe assumption. What do you think? Are there better alternatives?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23713 [Metrics/Onionoo]: Expand parameters and fields around AS number and names

[Tor Bug Tracker & Wiki]

#23713: Expand parameters and fields around AS number and names
-+--
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 Replying to [comment:6 karsten]:
 > Replying to [comment:5 irl]:
 > > I assume here that the comma-seperated list is to match any (union)?
 It is possible for a prefix to be announced by multiple AS in BGP and a
 future data source might provide all the ASs an IP address may be found
 in, not just one, so a match on all (intersection) is also a legitimate
 use case.
 >
 > Well, my (possibly flawed) plan was to use comma-separated lists for
 unions (`as=1,2,3` for relays in any of those three ASes) and repeatedly
 stated parameters for intersections (`as=1=2=3` for relays announced
 by all three ASes).

 This seems OK. I think Relay Search would have to explain this in the
 documentation as well as explaining it in Onionoo, but it's not
 ridiculously complicated to understand.

 > > The first two bullet points look good.
 >
 > Okay, great, I already started writing some code for them that I'll
 bring here for review as soon as it's ready.

 Cool.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26917 [Applications/Quality Assurance and Testing]: Update QA and Testing content on our HACKING document

[Tor Bug Tracker & Wiki]

#26917: Update QA and Testing content on our HACKING document
-+-
 Reporter:  gk   |  Owner:  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance   |Version:
  and Testing|
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Our QA and Testing content on our HACKING page needs some update.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26892 [Core Tor/Tor]: log_addr_has_changed() does not heed SafeLogging

[Tor Bug Tracker & Wiki]

#26892: log_addr_has_changed() does not heed SafeLogging
--+
 Reporter:  rl1987|  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-log   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #6947 [Metrics/Onionoo]: Allow filtering relays by version ranges

[Tor Bug Tracker & Wiki]

#6947: Allow filtering relays by version ranges
-+--
 Reporter:  rransom  |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 Replying to [comment:11 karsten]:
 > Hmm, on second thought, `:` wouldn't work so well with qualified search
 terms. Imagine a search for `version:0.3.2.1:0.3.2.5` (for versions
 0.3.2.1, 0.3.2.2, 0.3.2.3, 0.3.2.4, and 0.3.2.5) or even
 `version::0.3.2.5` (for everything ''until'' 0.3.2.5) or
 `version:0.3.2.1:` for 0.3.2.1 or newer).

 Good point.

 > New idea (sorry for the brainstorming, I'm just trying to find the best
 solution): `..`, as in `version:0.3.2.1..0.3.2.5` or `version:..0.3.2.5`
 or `version:0.3.2.1..` for the examples given above. Yet unimplemented, so
 no guarantee that it will work well in all cases. We'd only have to
 require that versions don't contain two consecutive `.`, but that should
 be a safe assumption. What do you think? Are there better alternatives?

 Yes, I think a double `.` is safer than a `:`. I know that `:` is
 perfectly valid in Debian package version numbers and perhaps there would
 be other clients that use it in the future.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25448 [Metrics/Onionoo]: allow for URLs that specify list of fingerprints

[Tor Bug Tracker & Wiki]

#25448: allow for URLs that specify list of fingerprints
-+
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_revision
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+

Comment (by karsten):

 Oh, yes, the yet unspoken reason that we shouldn't keep both parameters. I
 meant to create a ticket for that, but forgot. Let me do that now, so that
 we can discuss the future of the fingerprint parameter, and then we can
 get back to this ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25448 [Metrics/Onionoo]: allow for URLs that specify list of fingerprints

[Tor Bug Tracker & Wiki]

#25448: allow for URLs that specify list of fingerprints
-+
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_revision
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+

Comment (by karsten):

 Replying to [comment:7 karsten]:
 > Oh, yes, the yet unspoken reason that we shouldn't keep both parameters.
 I meant to create a ticket for that, but forgot. Let me do that now, so
 that we can discuss the future of the fingerprint parameter, and then we
 can get back to this ticket.

 Created #26919.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25448 [Metrics/Onionoo]: allow for URLs that specify list of fingerprints

[Tor Bug Tracker & Wiki]

#25448: allow for URLs that specify list of fingerprints
-+
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_revision
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+
Changes (by irl):

 * status:  needs_review => needs_revision


Comment:

 Is there a reason that we can't have the fingerprint parameter accept a
 list just as lookup does is in this patch?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26919 [Metrics/Onionoo]: Remove fingerprint parameter

[Tor Bug Tracker & Wiki]

#26919: Remove fingerprint parameter
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We have two quite similar parameters: lookup and fingerprint. Both expect
 a full hex fingerprint and return a single relay or bridge (or more than
 just one when we implement #25448).

 The main difference between these two parameters is that fingerprint
 returns relays or bridges regardless of whether they have been running in
 the past week. There is no other way to access these documents other than
 by knowing the exact fingerprint of a relay or hashed fingerprint of a
 bridge. Unlike other parameters, the fingerprint does not even work with
 hashed relay fingerprints or hashed hashed bridge fingerprints.

 Do we need to keep the fingerprint parameter with this somewhat special
 behavior?

 We added the parameter four years ago for one of the EFF relay challenges.
 But is it still in use? And is that because clients really need to access
 older relays and bridges, or because their developers did not know about
 the lookup parameter?

 Setting type to enhancement, because removing the fingerprint parameter
 would let us remove some special code from the code base.

 However, if there are valid use cases to keep the fingerprint parameter,
 let's just collect them here and let the parameter in.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25448 [Metrics/Onionoo]: allow for URLs that specify list of fingerprints

[Tor Bug Tracker & Wiki]

#25448: allow for URLs that specify list of fingerprints
-+--
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by irl):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:7 karsten]:
 > Oh, yes, the yet unspoken reason that we shouldn't keep both parameters.
 I meant to create a ticket for that, but forgot. Let me do that now, so
 that we can discuss the future of the fingerprint parameter, and then we
 can get back to this ticket.

 Ah ok. I didn't even realise we had that field until I saw it in the
 commit.

 In which case, I shall finish the review.

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

[tor-bugs] #26920 [Obfuscation/Pluggable transport]: Deploy Marionette as a Pluggable Transport

[Tor Bug Tracker & Wiki]

#26920: Deploy Marionette as a Pluggable Transport
-+
 Reporter:  Marionette   |  Owner:  asn
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   |   Keywords:  Marionette
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 This is a ticket to organize the deployment of Marionette as a new
 pluggable transport integrated into Tor.  The original code is currently
 located at https://github.com/redjack/marionette.  It has already been
 shown to be compatible with Tor in March in its Python encumbered form.
 Currently, it can be compiled as a completely standalone binary, and
 therefore should be easy to integrate.  We would like it to be integrated
 before the end of September.

 To run it as a bridge, currently, use the torcc files in the etc/tor
 directory in the github repository 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] #6947 [Metrics/Onionoo]: Allow filtering relays by version ranges

[Tor Bug Tracker & Wiki]

#6947: Allow filtering relays by version ranges
-+--
 Reporter:  rransom  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * owner:  metrics-team => karsten
 * status:  assigned => accepted


Comment:

 Okay, great, I think that's enough to start writing some code. Grabbing
 the ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26919 [Metrics/Onionoo]: Remove fingerprint parameter

[Tor Bug Tracker & Wiki]

#26919: Remove fingerprint parameter
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Not easily. We only keep aggregate statistics of most frequent parameter
 combinations:

 {{{
 2018-07-24 13:46:11,543 Request statistics (2018-07-24 13:46:11, 3600 s):
 2018-07-24 13:46:11,544   Total processed requests: 40467
 [...]
 2018-07-24 13:46:11,544   Most frequently requested parameter
 combinations: [search, limit, type, fields] (21944), [lookup, fields]
 (18106), [lookup] (236)
 }}}

 So, at least we can say that at most 181 (= 40467 - 21944 - 18106 - 236)
 out of 40467 requests (0.58%) included the fingerprint parameter. Could
 also be 0, but we don't know for sure.

 What we could do is extend the statistics to include less frequent
 parameter combinations beyond the top 3 without giving a request count for
 privacy reasons. Then we'd at least find out whether the fingerprint
 parameter is used at all, over a day or 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] #26910 [Core Tor/Tor]: Could tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)

[Tor Bug Tracker & Wiki]

#26910: Could tor drop privileges even earlier? (before trying to access 
anything
on the filesystem beyond its torrc files)
--+--
 Reporter:  nusenu|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nusenu):

 Replying to [comment:1 nickm]:
 > I'm not sure I understand: How would Tor know which user to switch to
 (or which other privileges to drop) if it has not first read the torrc
 file?

 sorry if I was not clear about that: I was suggesting to drop privileges
 *after* reading the torrc file

 > And would reading the torrc file not count as using the filesystem?

 reading the torrc file as the user that is used to start tor (root in this
 case is fine)

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

Re: [tor-bugs] #9145 [Applications/Tor Browser]: Tor Browser for Windows is borked with hardware acceleration enabled (because of gcc?)

[Tor Bug Tracker & Wiki]

#9145: Tor Browser for Windows is borked with hardware acceleration enabled
(because of gcc?)
-+-
 Reporter:  dope457  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, fuck-mingw, ff60-esr, |  Actual Points:
  TorBrowserTeam201807R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-crash, fuck-mingw, ff60-esr, TorBrowserTeam201807 => tbb-
 crash, fuck-mingw, ff60-esr, TorBrowserTeam201807R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducibly with Stylo enabled using rustc > 1.25.0

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducibly with Stylo enabled 
using
rustc > 1.25.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807,   |  Actual Points:
  GeorgKoppen201807  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:22 alexcrichton]:
 > Hm interesting! I wonder if this is perhaps related to
 https://github.com/rust-lang/rust/issues/52044? That claims it was fixed
 with the most recent LLVM upgrade. Are you able to reproduce the non-
 determinism on the most recent nightly?

 Aha! That sounds promising and I certainly feel glandium's "This is
 driving me crazy", so this should be the issue then, right? ;)

 That said, I compiled the nightly from 2018-07-13 which should contain the
 LLVM upgrade and I can't reproduce the problem anymore. However, I can't
 either when compiling the one from from 2018-07-11 which should *not*
 contain the LLVM upgrade (it's based on commit
 e5f6498d3d5c9dac841009d7b49738923826af75). So, it seem the LLVM uprade
 (alone) is not enough to explain this bug, or am I missing something?

 Trying to figure out where all this started, I am pretty sure that
 2018-02-15 is good and 2018-03-07 is bad.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26807 [Obfuscation/Censorship analysis]: Venezuela blocks access to the Tor network

[Tor Bug Tracker & Wiki]

#26807: Venezuela blocks access to the Tor network
-+-
 Reporter:  ptdetector   |  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 madurosbus):

 if traffic ~~torturer~~ shaper malfunctions (overload) connection closed
 just after successful TCP handshake. any ports.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducibly with Stylo enabled using rustc > 1.25.0

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducibly with Stylo enabled 
using
rustc > 1.25.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807,   |  Actual Points:
  GeorgKoppen201807  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I wonder if building from scratch is important here (which I do and
 glandium did as well).

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

[tor-bugs] #26921 [Applications/Orbot]: Sometimes randomly start

[Tor Bug Tracker & Wiki]

#26921: Sometimes randomly start
+--
 Reporter:  ciano84 |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Applications/Orbot  |Version:  Tor: unspecified
 Severity:  Minor   |   Keywords:  randomly start
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 sometimes randomly Orbot starts without a reason ... the boot check box is
 removed. I have a ZenFone asus 3 max, Android 7.0

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