Re: [tor-bugs] #32580 [Core Tor/Tor]: Use clang's enum_extensibility attribute to check enum values

[Tor Bug Tracker & Wiki]

#32580: Use clang's enum_extensibility attribute to check enum values
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Here's how we can check for that feature in clang:
 https://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-
 macros

 I think the sa,e syntax works on gcc, but we should check.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32579 [Core Tor/Tor]: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements

[Tor Bug Tracker & Wiki]

#32579: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case
statements
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Here's how we can check for that feature in clang:
 https://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-
 macros

 I think the sa,e syntax works on gcc, but we should check.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32581 [Core Tor/Tor]: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors

[Tor Bug Tracker & Wiki]

#32581: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  code-correctness
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 See:
 https://clang.llvm.org/docs/AttributeReference.html#type-safety-checking

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32580 [Core Tor/Tor]: Use clang's enum_extensibility attribute to check enum values

[Tor Bug Tracker & Wiki]

#32580: Use clang's enum_extensibility attribute to check enum values
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  code-correctness
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 We could avoid constructing bad enum values using enum_extensibility:
 https://clang.llvm.org/docs/AttributeReference.html#enum-extensibility

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32579 [Core Tor/Tor]: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements

[Tor Bug Tracker & Wiki]

#32579: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case
statements
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  code-correctness
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 We can avoid accidental fallthroughs using clang's -Wimplicit-fallthrough.

 https://clang.llvm.org/docs/AttributeReference.html#fallthrough

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32578 [Webpages]: Onion v.3 links doesnt work

[Tor Bug Tracker & Wiki]

#32578: Onion v.3 links doesnt work
--+--
 Reporter:  Imprettynew   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Component:  Webpages
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Today when I tried to connect to a website, it wouldn't work. I first
 thought that the site was down, but then I tried more links. No one the
 v.3 links works. Clearnet and v.2 links works without any issues.

 I even tried to host a site using a clearnet site to see if it worked.
 All it says is "connection timed out".

 I downloaded Tor browser v.9.0.0 and same issue.
 The problem wasn't here 24 hours ago.

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

Re: [tor-bugs] #32394 [Applications/Tor Browser]: Update Progress Bar doesn't use translations

[Tor Bug Tracker & Wiki]

#32394: Update Progress Bar doesn't use translations
--+--
 Reporter:  Zarko_Gjurov  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update, TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Zarko_Gjurov):

 Probably should be taken over and directly integrated to Tor Project and
 to be put on Transifex for translating same as was with the case of
 "onboarding.properties".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32576 [Circumvention/Snowflake]: Fix race condition in snowflake broker

[Tor Bug Tracker & Wiki]

#32576: Fix race condition in snowflake broker
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--

Comment (by cohosh):

 Replying to [comment:7 dcf]:
 > Perhaps because the old broker had 1 CPU core and the new one has 2 CPU
 cores? I can imagine that might affect goroutine scheduling which might
 affect the visibility of race conditions.
 Ah that would do it :) The reason we didn't notice then was because
 clients and proxies weren't around to trigger the race until we switched
 over the DNS records for the bamsoftware.com domains.
 >
 > You might try setting `GOMAXPROCS=1` in /etc/service/snowflake-
 broker/run as a temporary workaround, if indeed it helps.
 Okay I did this and restarted the broker as of `2019/11/22 22:50:27` that
 should work until we get this patch reviewed. 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] #32576 [Circumvention/Snowflake]: Fix race condition in snowflake broker

[Tor Bug Tracker & Wiki]

#32576: Fix race condition in snowflake broker
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 This race condition occurs because both the proxy process and the client
 process try to `Pop`/`Remove` the same snowflake from the heap.

 When a proxy polls the broker, it starts a go routine that waits for an
 offer through the snowflake's offer channel, or waits for a timeout:
 {{{
 go func(request *ProxyPoll) {
 select {
 case offer := <-snowflake.offerChannel:
 request.offerChannel <- offer
 case <-time.After(time.Second * ProxyTimeout):
 // This snowflake is no longer available to serve clients.
 // TODO: Fix race using a delete channel
 heap.Remove(ctx.snowflakes, snowflake.index)
 delete(ctx.idToSnowflake, snowflake.id)
 request.offerChannel <- nil
 }
 }(request)
 }}}

 Snowflakes are removed from the heap when they time out or if they are
 popped off the heap by a client:
 {{{
 func clientOffers(ctx *BrokerContext, w http.ResponseWriter, r
 *http.Request) {

 ...

 // Delete must be deferred in order to correctly process answer
 request later.
 snowflake := heap.Pop(ctx.snowflakes).(*Snowflake)
 defer delete(ctx.idToSnowflake, snowflake.id)
 snowflake.offerChannel <- offer
 }}}

 A race can always occur where the timeout happens after the `Pop` removes
 the snowflake but before the offer is sent through `offerChannel`. This
 can be fixed through the use of locks and a check to see if
 `snowflake.index` has been set to `-1` (which happens after it has been
 popped off the heap). Here's a patch that adds synchronization to the
 broker to prevent simultaneous access to the heap as well as the
 `idToSnowflake` map: https://github.com/cohosh/snowflake/pull/14

 I'd like to do some tests before merging this to make sure that the
 synchronization doesn't slow things down too much, but a code review would
 be good at this point.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32499 [Circumvention/Snowflake]: Add a build step / documentation for code reuse in Cupcake

[Tor Bug Tracker & Wiki]

#32499: Add a build step / documentation for code reuse in Cupcake
-+--
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by arlolra):

 * status:  assigned => needs_review


Comment:

 Here's a branch for this,
 https://github.com/keroserene/snowflake/commits/trac32499

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32550 [Circumvention/Obfs4]: Static tor in docker container

[Tor Bug Tracker & Wiki]

#32550: Static tor in docker container
-+--
 Reporter:  thymbahutymba|  Owner:  phw
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  docker   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by thymbahutymba):

 I was building again all and I saw that I've made two mistake in the
 Makefile. In order to fix it so that you are able to build by yourself
 without any trouble here the fixing.
 * In {{{tor}}} target remove libseccomp (that is not present at all);
 * In {{{tor-${TOR_VER i forgot one slash into the url. The correct url
 is: {{{${TOR}/$@.tar.gz}}}.
 Forgive me about those mistake, I'm really sorry.

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

Re: [tor-bugs] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

[Tor Bug Tracker & Wiki]

#31823: HSv3 descriptor support in stem [encoding]
-+-
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:  2
  network-team-roadmap-september tor-spec|
Parent ID:  #26768   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 Thanks asn! Quick update...

 *
 
[https://gitweb.torproject.org/stem.git/commit/?id=a1d5d9726e3653f58035c76420582059b0c86d13
 Ed25519 key blinding is now 100x faster]
 *
 
[https://gitweb.torproject.org/stem.git/commit/?id=2526db23a86022796d7d635e1081f2bcd976376b
 desc-auth-ephemeral-key are now generated from keys]
 *
 
[https://gitweb.torproject.org/stem.git/commit/?id=f5c8c96cdd2cdc967d44ff017b68ea58ce77ca36
 sixteen auth-client are now included by default]
 *
 
[https://gitweb.torproject.org/stem.git/commit/?id=eea41c17ed53ab44552f6b2c3fc574bc3710fb82
 more flexible IntroductionPointV3 construction]

 If ya spot anything else please let me know.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32576 [Circumvention/Snowflake]: Fix race condition in snowflake broker

[Tor Bug Tracker & Wiki]

#32576: Fix race condition in snowflake broker
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by dcf):

 Replying to [comment:4 cohosh]:
 > The weird thing is that the #29207 update was deployed on the old broker
 at the same time but hasn't caused any problems. It's possible this was
 due to the DNS update to point to the new broker, but as seen from the
 metrics data, the old broker was still getting a lot of proxy polls for
 several days after.

 Perhaps because the old broker had 1 CPU core and the new one has 2 CPU
 cores? I can imagine that might affect goroutine scheduling which might
 affect the visibility of race conditions.

 You might try setting `GOMAXPROCS=1` in /etc/service/snowflake-broker/run
 as a temporary workaround, if indeed it helps.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29249 [Circumvention/BridgeDB]: Assessment of moat for bridges

[Tor Bug Tracker & Wiki]

#29249: Assessment of moat for bridges
+---
 Reporter:  gaba|  Owner:  (none)
 Type:  task| Status:  closed
 Priority:  High|  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:  invalid
 Keywords:  moat, ex-sponsor-19 |  Actual Points:
Parent ID:  #31280  | Points:  5
 Reviewer:  |Sponsor:  Sponsor30-can
+---
Changes (by gaba):

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


Comment:

 This was one of the tickets created during the roadmap in Brussels in
 February 2019. I'm going to close it 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] #32576 [Circumvention/Snowflake]: Fix race condition in snowflake broker (was: Snowflake broker not serving metrics correctly)

[Tor Bug Tracker & Wiki]

#32576: Fix race condition in snowflake broker
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Old description:

> Looks like the snowflake broker isn't serving metrics since 2019-11-14
> (which happens to coincide with the host migration.
>
> At first I thought this was a DNS issue and filed #32570, but even when I
> manually fetch https://snowflake-broker.torproject.net/metrics I'm
> getting outdated metrics.
>
> I've attached the result of the above fetch as well as the metrics file
> located on the snowflake broker host that the broker *should* be reading
> from.

New description:

 There is a race condition with the snowflake heap that has been causing
 the broker to crash several times a day. This race condition has existed
 in the broker for several years, but some recent updates as well as the
 host migration managed to shake it loose.

 

 This race condition is causing the snowflake broker to crash repeatedly
 and often since the migration. We noticed because CollecTor stopped
 collecting metrics since the restart on 14 November 2019.

--

Comment (by cohosh):

 Just updating the summary of this ticket to reflect the actual problem.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32380 [Applications/Tor Browser]: Get current Tor Browser code ready for RLBox

[Tor Bug Tracker & Wiki]

#32380: Get current Tor Browser code ready for RLBox
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, GeorgKoppen201911  |  Actual Points:
Parent ID:  #32379   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by gk):

 Okay, with `bug_30380_v3` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_32380_v3) I get the following build issue:
 {{{
  1:06.10 /var/tmp/build/firefox-
 301a46905ed1/gfx/thebes/gfxFcPlatformFontList.cpp:495:18: error: value of
 type 'tainted_opaque' (aka
 'tainted_opaque') is not
 contextually convertible to 'bool'
  1:06.10   if (mHBFace || mGrFace) {
  1:06.10  ^~~
  1:06.10 /var/tmp/build/firefox-
 301a46905ed1/gfx/thebes/gfxFcPlatformFontList.cpp:495:15: error: invalid
 operands to binary expression ('hb_face_t *' and 'tainted_opaque' (aka 'tainted_opaque'))
  1:06.10   if (mHBFace || mGrFace) {
  1:06.10   ~~~ ^  ~~~
  1:06.10 /var/tmp/build/firefox-301a46905ed1/obj-x86_64-pc-linux-
 gnu/dist/include/mozilla/rlbox/rlbox.hpp:793:1: note: candidate template
 ignored: could not match 'tainted_base_impl' against 'tainted_opaque'
  1:06.11 BooleanBinaryOpWrappedRhs(||);
  1:06.11 ^
  1:06.11 /var/tmp/build/firefox-301a46905ed1/obj-x86_64-pc-linux-
 gnu/dist/include/mozilla/rlbox/rlbox.hpp:747:25: note: expanded from macro
 'BooleanBinaryOpWrappedRhs'
  1:06.11   inline constexpr auto operator opSymbol(
 \
  1:06.11 ^
  1:06.11 /var/tmp/build/firefox-301a46905ed1/obj-x86_64-pc-linux-
 gnu/dist/include/mozilla/rlbox/rlbox.hpp:793:1: note: candidate template
 ignored: could not match 'tainted_base_impl' against 'tainted_opaque'
  1:06.11 /var/tmp/build/firefox-301a46905ed1/obj-x86_64-pc-linux-
 gnu/dist/include/mozilla/rlbox/rlbox.hpp:765:25: note: expanded from macro
 'BooleanBinaryOpWrappedRhs'
  1:06.11   inline constexpr auto operator opSymbol(
 \
  1:06.11 ^
  1:06.86 2 errors generated.
  1:06.88 make[1]: *** [gfxFcPlatformFontList.o] Error 1
 }}}
 Our toolchain is fine in that it can compile the respective code from the
 canonical
 
[https://treeherder.mozilla.org/#/jobs?repo=try=f315fe26d1731d325eb8981a5bfe7e7c819842fd
 try push]. It seems we have the problem that the patch for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1547063 did not land on ESR
 68.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32570 [Metrics/CollecTor]: CollecTor stopped collecting snowflake stats

[Tor Bug Tracker & Wiki]

#32570: CollecTor stopped collecting snowflake stats
---+--
 Reporter:  cohosh |  Owner:  metrics-team
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cohosh):

 * status:  new => needs_review


Comment:

 Found the problem, there's a bug in the broker that's causing it to crash.
 We don't collect metrics if it crashes so that explains why the new broker
 wasn't updating the metrics log file.

 Anyway, CollecTor should atleast be able to get data for the last week now
 since I moved the log from the old host to the new one.

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

Re: [tor-bugs] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:  1.1
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---

Comment (by thymbahutymba):

 Replying to [comment:15 phw]:
 > Here's a patch that derives docker's volume name from the two given
 ports, making it possible to deploy more than one container on a machine:
 > https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/compare/master...fix%2F31834
 >
 > I know that thymbahutymba is no fan of this but I find it intuitive that
 each call to `make deploy` results in a new container being deployed. As
 for the volume names: I believe that thymbahutymba prefers the volume name
 to contain the bridge name instead of the ports. I'm fine with this too
 but I find it a little awkward because we'd be introducing a new
 constraint (unique bridge names) which don't exist in Tor.

 Actually my point is not about bridge name but how to identify in a smart
 way the name of the container and the volume connected with. I thought
 that having external config file can solve this (and others) problem. In
 this case the user can keep the configuration file separated by the
 Makefile, moreover if the user need to re-deploy the container, due to
 image update or whatever else, this make the process quite easy and faster
 than run deploy multiple time, which requires to have in mind which are
 the ports associated to that. After saying that just consider something
 like what follows.
 {{{
 # env
 BRIDGE_NAME=DockerObfs4
 BRIDGE_LIST=${BRIDGE_NAME}-{1..2}

 ${BRIDGE_NAME}-1-OR_PORT=993
 ${BRIDGE_NAME}-1-PT_PORT=143

 ${BRIDGE_NAME}-2-OR_PORT=443
 ${BRIDGE_NAME}-2-PT_PORT=25

 # Makefile
 include env

 deploy: $(shell echo ${BRIDGE_LIST})

 ${BRIDGE_NAME}-%:
 @echo ${BRIDGE_LIST}
 @[ ${$@-OR_PORT} ] || ( echo "Env var OR_PORT for $@ is not set.";
 exit 1 )
 @[ ${$@-PT_PORT} ] || ( echo "Env var PT_PORT for $@ is not set.";
 exit 1 )
 @docker run \
 \
 --volume $@:/var/lib/tor \
 
 }}}
 Just to summarize what I think are the advantages of that:
 * Is not required to remember the configuration each time;
 * Easy to identify at which container is associate one volume;
 * No need to run multiple times {{{make deploy }}} for each
 instance that we would run that's means speedup on deployment phase.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 In any case, this is almost certainly due to this
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/broker/broker.go#n128 documented race
 condition], so we should fix that.

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

Re: [tor-bugs] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 The weird thing is that the #29207 update was deployed on the old broker
 at the same time but hasn't caused any problems. It's possible this was
 due to the DNS update to point to the new broker, but as seen from the
 metrics data, the old broker was still getting a lot of proxy polls for
 several days after.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29207 [Circumvention/Snowflake]: New design for broker -- proxy protocol for snowflakes

[Tor Bug Tracker & Wiki]

#29207: New design for broker -- proxy protocol for snowflakes
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake, design, ex-sponsor-19,|  Actual Points:  2
  anti-censorship-roadmap|
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by cohosh):

 The weird thing is that the #29207 update was deployed on the old broker
 at the same time but hasn't caused any problems. It's possible this was
 due to the DNS update to point to the new broker, but as seen from the
 metrics data, the old broker was still getting a lot of proxy polls for
 several days after.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 Okay so the crashes have been happening every since this restart:
 https://trac.torproject.org/projects/tor/ticket/29207#comment:35

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 Alright I found what look like a few crashes:
 {{{
 >[scrubbed]: read: connection reset by peer
 panic: runtime error: index out of range

 goroutine 360108 [running]:
 main.SnowflakeHeap.Swap(0xc001440200, 0x10, 0x40, 0x, 0xf)
 /home/david/branches/snowflake/broker/snowflake-heap.go:30 +0x8a
 container/heap.Remove(0x7bc1c0, 0xc7abe0, 0x, 0x1,
 0xc7c601)
 /usr/lib/go-1.11/src/container/heap/heap.go:75 +0x9c
 main.(*BrokerContext).Broker.func1(0xc000ef4240, 0xc7ac00,
 0xc00111e5e0)
 /home/david/branches/snowflake/broker/broker.go:129 +0x128
 created by main.(*BrokerContext).Broker
 /home/david/branches/snowflake/broker/broker.go:122 +0xa2
 }}}

 {{{
 2019/11/15 12:25:29 http2: received GOAWAY [FrameHeader GOAWAY len=8],
 starting graceful shutdown
 fatal error: concurrent map writes
 }}}

 {{{
 2019/11/15 17:23:46 http: TLS handshake error from [scrubbed]: EOF
 panic: runtime error: index out of range

 goroutine 1949618 [running]:
 main.SnowflakeHeap.Swap(0xc003e08400, 0x20, 0x40, 0x,
 0x1f)
 /home/david/branches/snowflake/broker/snowflake-heap.go:30 +0x8a
 container/heap.Remove(0x7bc1c0, 0xc0cc00, 0x, 0x1,
 0xc001de4f01)
 /usr/lib/go-1.11/src/container/heap/heap.go:75 +0x9c
 main.(*BrokerContext).Broker.func1(0xc004d065a0, 0xc0cc20,
 0xc004b03300)
 /home/david/branches/snowflake/broker/broker.go:129 +0x128
 created by main.(*BrokerContext).Broker
 /home/david/branches/snowflake/broker/broker.go:122 +0xa2
 }}}
 {{{
 2019/11/15 18:03:08 http: TLS handshake error from [scrubbed]: read tcp
 [scrubbed]->[scrubbed]: read:
  connection reset by peer
 fatal error: concurrent map writes
 }}}

 ... and so on, pretty much continuously through to today:
 {{{
 2019/11/22 10:15:44 http: TLS handshake error from [scrubbed]: EOF
 fatal error: concurrent map writes
 }}}

 The weird thing is, these errors don't occur on the old broker host:
 /var/log/snowflake-broker# grep "fatal error" ./*
 /var/log/snowflake-broker# grep "panic" ./*
 both yield no results.

 The frequency with which the panics on the new host occur explain the lack
 of metrics, we only log metrics once the broker has been running for 24
 hours straight and that hasn't happened since 14-11-2019.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32577 [Core Tor/Torsocks]: torsocks is not fully capable of performing required downloads

[Tor Bug Tracker & Wiki]

#32577: torsocks is not fully capable of performing required downloads
---+---
 Reporter:  estellnb   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:  sbws: unspecified
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by estellnb):

 It hangs for an infinite amount of time while the files can quickly be
 downloaded without tor.

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

Re: [tor-bugs] #32577 [Core Tor/Torsocks]: torsocks is not fully capable of performing required downloads

[Tor Bug Tracker & Wiki]

#32577: torsocks is not fully capable of performing required downloads
---+---
 Reporter:  estellnb   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:  sbws: unspecified
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by estellnb):

 * Attachment "download-trial.png" added.

 screenshot

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29258 [Circumvention/Snowflake]: Provide an IPv6 address for the Snowflake broker

[Tor Bug Tracker & Wiki]

#29258: Provide an IPv6 address for the Snowflake broker
+--
 Reporter:  ahf |  Owner:  dcf
 Type:  task| Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--
Changes (by cohosh):

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


Comment:

 Reopening because I think we still need to think about logs?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32570 [Metrics/CollecTor]: CollecTor stopped collecting snowflake stats

[Tor Bug Tracker & Wiki]

#32570: CollecTor stopped collecting snowflake stats
---+--
 Reporter:  cohosh |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cohosh):

 Okay I copied the old snowflake broker logs to the new host just so we
 have data for the last week.

 I'm still not sure why the new broker host hasn't been logging metrics
 data, I fear we have lost data for the new host since the 14th, but
 CollecTor should be able to get more data 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] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 Okay it turns out I was still ssh-ing into the old broker. I copied over
 the metrics log from the old broker so that CollecTor at least has *some*
 data from the last week, but note that this will be metrics from the old
 broker host so most proxies will have migrated to the new host.

 Interestingly, it looks like there is still one proxy in Japan that's
 polling the old broker still.

 I'm still not sure why the new broker wasn't saving metrics since
 migrating the other domains on November 14th. Looking at the log files, it
 looks like the broker might have crashed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32577 [Core Tor/Torsocks]: torsocks is not fully capable of performing required downloads

[Tor Bug Tracker & Wiki]

#32577: torsocks is not fully capable of performing required downloads
---+---
 Reporter:  estellnb   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor/Torsocks
  Version:  sbws: unspecified  |   Severity:  Major
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
 ii  torsocks   2.3.0-2  amd64use SOCKS-friendly
 applications with Tor
 using Debian 10.1.0 live

   When I try to shield the necessary downloads of my coreboot firmware
 source compilation I get the following three types of errors:
 1574449473 WARNING torsocks[13517]: [syscall] Unsupported syscall number
 332. Denying the call (in tsocks_syscall() at syscall.c:605)
 1574449473 WARNING torsocks[13517]: [syscall] Unsupported syscall number
 293. Denying the call (in tsocks_syscall() at syscall.c:605)
 1574449410 WARNING torsocks[13244]: [syscall] Unsupported syscall number
 326. Denying the call (in tsocks_syscall() at syscall.c:605)

   The download always hangs in some other position and I have given up to
 do a secure download for the darp5 firmware. This means that I will have
 no coreboot firmware since the main installation on my darp5 (downloads
 and compilation work well there) is bugged with a rootkit as detectable by
 https://www.elstel.org/debcheckroot/. I can not use the compilation
 results of a bugged machine.

 model: System76 Darter Pro 5
 git repository: https://github.com/system76/firmware-open

 commands to execute:

 torsocks git clone https://github.com/system76/firmware-open
 cd firmware-open
 git checkout whl-u
 torsocks git submodule update --init --recursive --checkout
 vim scripts/build.sh  # remove +nightly from installer
 torsocks scripts/deps.sh
 source ?.rustup/env? - look for this command in build.sh
 torsocks scripts/build.sh darp5

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:6 eighthave]:
 > I guess we should also have an automatic naming convention for
 translating ControlPort command names to Java method names.  The existing
 standard is to use camelCase for ControlPort commands with an `_` in them,
 and when there are clear words.  Then camelCase for methods that are not
 just direct calls for ControlPort commands.  For example:
 >
 > * `takeOwnership()` -> `TAKEOWNERSHIP`
 > * `setEvents()` -> `SETEVENTS`
 > * `addOnion()` -> `ADD_ONION`
 > * `dropGuards()` -> `DROPGUARDS`
 > * `resetConf()` -> `RESETCONF`
 > * `hsFetch()` -> `HSFETCH`
 > * `hsForget()` -> `HSFORGET`
 > * `sendAndWaitForResponse()`
 >
 > So @sisbell's proposal looks good to me, except `takeownership()` should
 be `takeOwnership()`.
 >
 > I can put together this update for the things that I'm proposing, as
 long as Tor Project is willing to use it and make the releases to Maven
 Central.

 This makes sense on the naming conventions. There are a lot of possible
 commands. We can probably just start with those we need for Orbot/tor-
 android-service. Any additional ones from the community can be opened as
 tickets. If we have the ability to control the code. I'd suggest a base
 classes which just the connection stuff and then drop all the tor specific
 commands to a subclass, just to make the code a little more readable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * cc: sisbell (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] #32573 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Https on openculture.com

[Tor Bug Tracker & Wiki]

#32573: Https on openculture.com
-+-
 Reporter:  cypherpunks  |  Owner:  legind
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere | Resolution:  not a
 Severity:  Normal   |  bug
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by legind):

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


Comment:

 The ruleset is disabled by default.  If you have EASE mode turned on in
 your settings, it may redirect you anyway, regardless of a rule for this
 site being present or not.  EASE mode tries to opportunistically upgrade
 your connection to HTTPS and present a warning page if it fails, but in
 this rare case the HTTPS version of the site gives a valid certificate but
 an error when accessed.  I suggest  using the HTTPS Everywhere menu to
 "Disable HTTPS Everywhere on this site" - that button is for just such
 rare instances.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:81 acat]:
 > Thanks for the review.
 >
 > > 3. Can we use the circular onion icon? I aim to have updated all the
 onions at the URL bar and the circuit display too.
 >
 > Is there a svg for that one? I could not find one with just a single
 color like the ones in your design.
 >

 Yes, here browser/components/tornetworksettings/content/torNetworkIcon.svg

 >
 > > 4. I don't think we need a menu under the [...] It adds noise and I
 don't see a real use case for it. Do you think I'm missing something? Let
 me know.
 >
 > I think it makes sense. This came for free by using the internal Firefox
 page action API, but we can just make it not be a page action, and be at
 the left of those, like the reader mode button for example.
 >
 >

 I prefer that. We can discuss it with the team during the meeting on
 Monday.

 > > 5. Can we prompt the discover-like doorhanger just for first-time
 users? I don't want to suggest users change the general settings every
 time they have an onion available. It will add extra friction in the
 entire experience which I don't think is needed.
 > > 6. If users have selected [ask me every time] then we show the onion-
 label suggestion pill. If users have selected [always use .onion when
 available] then we redirect to the onion using the proposed animation. So,
 the onion-label pill doesn't need a menu. Again, am i missing something?
 >
 > Ok, so clicking on the pill should directly go to the .onion, and the
 doorhanger should appear only once, for the opt-in. I think that makes
 sense, and then there's no need for contextual menu, indeed.
 >

 Exactly. Awesome!

 > > 9. As part of #30024, I made this micro animation for when the onion
 gets updated. Do you think it is something doable? The persistent pill
 seems too much for it.
 > > https://trac.torproject.org/projects/tor/attachment/ticket/30024
 /prompt-onion-2.gif
 >
 > Not completely sure how easy that will be, but I will try. The animation
 only affects the "lock"/onion icon and the pill, right? That's for "ask me
 everytime", for "always use .onion" the animation would be only on the
 "lock"/onion (as there would be no pill), if I am correct.
 >

 We can discuss it during the next meeting. I'm not sure what is going to
 be the case of CV/EV and onions and maybe the lock is needed in the
 future.

 > > 10. The panel at `about:preferences` looks great. Should we move it
 under the Tor section? I suggested to have it on Privacy & Security and
 maybe it is the right place to have it. What do others think?
 >
 > I'm not sure. Is the Tor section supposed to mean "settings for Tor
 client", or just any setting related to Tor? I don't know if it should be
 in `Privacy/Security` either, as I'm not sure it has much privacy/security
 benefits actually (as noted in
 https://gitweb.torproject.org/user/asn/torspec.git/tree/proposals/ideas
 /onion-location.txt?h=onion-
 location=14fc750e3afcd759f4235ab955535a07eed24286).
 >
 Let's talk about it during the next meeting. I'm fine keeping it as the
 first option in privacy/security.


 Thanks for your quick reply!!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32465 [Circumvention/Snowflake]: Use gorilla websocket instead of x/net websocket in proxy-go

[Tor Bug Tracker & Wiki]

#32465: Use gorilla websocket instead of x/net websocket in proxy-go
-+--
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by arlolra):

 * 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] #31244 [Internal Services/Tor Sysadmin Team]: long term prometheus metrics

[Tor Bug Tracker & Wiki]

#31244: long term prometheus metrics
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 doubling the disk space (from 40GB to 80GB) would double the price, but it
 can easily be done in the
 [https://console.hetzner.cloud/projects/56864/servers/2087572/rescale
 rescale menu]. all that's needed is a reboot.. i guess i'll add that to
 the agenda for monday.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32568 [Internal Services/Service - nextcloud]: nextcloud collaborative "pad" synchronization breaks down with multiple users

[Tor Bug Tracker & Wiki]

#32568: nextcloud collaborative "pad" synchronization breaks down with multiple
users
-+-
 Reporter:  anarcat  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gaba):

 Yes. I see the problem with using owncloud and may not be clear for people
 and we lose data that we do not want to lose.

 I agree about moving any agenda/notes for meetings to pad.riseup.net and
 periodically archive them in nc.torproject.net if we want to save old
 notes. Once they fix the text app then we can consider if we move there or
 not. For now we can continue using pad.riseup.net as we use for network
 and anti-censorship team meetings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * status:  assigned => needs_revision


Comment:

 Thanks for the review.

 > 3. Can we use the circular onion icon? I aim to have updated all the
 onions at the URL bar and the circuit display too.

 Is there a svg for that one? I could not find one with just a single color
 like the ones in your design.

 > 4. I don't think we need a menu under the [...] It adds noise and I
 don't see a real use case for it. Do you think I'm missing something? Let
 me know.

 I think it makes sense. This came for free by using the internal Firefox
 page action API, but we can just make it not be a page action, and be at
 the left of those, like the reader mode button for example.

 > 5. Can we prompt the discover-like doorhanger just for first-time users?
 I don't want to suggest users change the general settings every time they
 have an onion available. It will add extra friction in the entire
 experience which I don't think is needed.
 > 6. If users have selected [ask me every time] then we show the onion-
 label suggestion pill. If users have selected [always use .onion when
 available] then we redirect to the onion using the proposed animation. So,
 the onion-label pill doesn't need a menu. Again, am i missing something?

 Ok, so clicking on the pill should directly go to the .onion, and the
 doorhanger should appear only once, for the opt-in. I think that makes
 sense, and then there's no need for contextual menu, indeed.

 > 9. As part of #30024, I made this micro animation for when the onion
 gets updated. Do you think it is something doable? The persistent pill
 seems too much for it.
 > https://trac.torproject.org/projects/tor/attachment/ticket/30024/prompt-
 onion-2.gif

 Not completely sure how easy that will be, but I will try. The animation
 only affects the "lock"/onion icon and the pill, right? That's for "ask me
 everytime", for "always use .onion" the animation would be only on the
 "lock"/onion (as there would be no pill), if I am correct.

 > 10. The panel at `about:preferences` looks great. Should we move it
 under the Tor section? I suggested to have it on Privacy & Security and
 maybe it is the right place to have it. What do others think?

 I'm not sure. Is the Tor section supposed to mean "settings for Tor
 client", or just any setting related to Tor? I don't know if it should be
 in `Privacy/Security` either, as I'm not sure it has much privacy/security
 benefits actually (as noted in
 https://gitweb.torproject.org/user/asn/torspec.git/tree/proposals/ideas
 /onion-location.txt?h=onion-
 location=14fc750e3afcd759f4235ab955535a07eed24286).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31244 [Internal Services/Tor Sysadmin Team]: long term prometheus metrics

[Tor Bug Tracker & Wiki]

#31244: long term prometheus metrics
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 nbg1 has hit 90% disk usage recently (hit 80% on nov. 6th):

 {{{
 /dev/sda1   38G 33G  3,8G  90% /
 }}}

 I've tweaked the reserved space down to 1% to give us some extra room:

 {{{
 root@hetzner-nbg1-01:~# df -h /
 Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
 /dev/sda1   38G 33G  4,9G  87% /
 }}}

 but this is definitely not going to work in the long term. we'll need to
 give more space to this or something. we'd need to basically double the
 disk space for this server to keep the year of samples we want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31051 [Internal Services/Tor Sysadmin Team]: bungei running out of space

[Tor Bug Tracker & Wiki]

#31051: bungei running out of space
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 all good now:

 {{{
 root@bungei:~# lvextend vg_bulk/backups-pg -L +2T
   Size of logical volume vg_bulk/backups-pg changed from 1,00 TiB (262144
 extents) to 3,00 TiB (786432 extents).
   Logical volume vg_bulk/backups-pg successfully resized.
 root@bungei:~# resize2fs /dev/mapper/vg_bulk-backups--pg
 resize2fs 1.44.5 (15-Dec-2018)
 Filesystem at /dev/mapper/vg_bulk-backups--pg is mounted on
 /srv/backups/pg; on-line resizing required
 old_desc_blocks = 128, new_desc_blocks = 384
 The filesystem on /dev/mapper/vg_bulk-backups--pg is now 805306368 (4k)
 blocks long.

 root@bungei:~# df -h
 Sys. de fichiersTaille Utilisé Dispo Uti% Monté sur
 udev   63G   0   63G   0% /dev
 tmpfs  13G1,3G   12G  11% /run
 /dev/mapper/croot  20G2,6G   17G  14% /
 tmpfs  63G 72K   63G   1% /dev/shm
 tmpfs 5,0M   0  5,0M   0% /run/lock
 tmpfs  63G   0   63G   0%
 /sys/fs/cgroup
 tmpfs 4,0G   0  4,0G   0% /tmp
 /dev/md127488M140M  319M  31% /boot
 /dev/mapper/vg_bulk-backups--pg   3,0T854G  2,0T  30%
 /srv/backups/pg
 /dev/mapper/vg_bulk-backups--bacula30T 13T   17T  43%
 /srv/backups/bacula
 tmpfs  13G   0   13G   0% /run/user/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

Re: [tor-bugs] #31051 [Internal Services/Tor Sysadmin Team]: bungei running out of space

[Tor Bug Tracker & Wiki]

#31051: bungei running out of space
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i actually grew the *wrong* filesystem (`/srv/backups/bacula` instead of
 `.../pg`), so i'll have to go at it again.

 {{{
 root@bungei:~# df -h
 Sys. de fichiersTaille Utilisé Dispo Uti% Monté sur
 udev   63G   0   63G   0% /dev
 tmpfs  13G1,3G   12G  11% /run
 /dev/mapper/croot  20G2,9G   16G  16% /
 tmpfs  63G 72K   63G   1% /dev/shm
 tmpfs 5,0M   0  5,0M   0% /run/lock
 tmpfs  63G   0   63G   0%
 /sys/fs/cgroup
 tmpfs 4,0G   0  4,0G   0% /tmp
 /dev/md127488M140M  319M  31% /boot
 /dev/mapper/vg_bulk-backups--pg  1007G854G  103G  90%
 /srv/backups/pg
 /dev/mapper/vg_bulk-backups--bacula30T 13T   17T  43%
 /srv/backups/bacula
 tmpfs  13G   0   13G   0% /run/user/0
 tmpfs  13G   0   13G   0%
 /run/user/1529
 }}}

 i don't think it's a problem that bacula is bigger, that said... shrinking
 it seems unnecessary. i'll just give a few more TBs to pg already (say
 2TB).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31051 [Internal Services/Tor Sysadmin Team]: bungei running out of space

[Tor Bug Tracker & Wiki]

#31051: bungei running out of space
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  reopened => accepted
 * owner:  tpa => anarcat


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31051 [Internal Services/Tor Sysadmin Team]: bungei running out of space

[Tor Bug Tracker & Wiki]

#31051: bungei running out of space
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 this is a problem again today.

 {{{
 root@bungei:~# df -h
 Sys. de fichiersTaille Utilisé Dispo Uti% Monté sur
 udev   63G   0   63G   0% /dev
 tmpfs  13G1,3G   12G  11% /run
 /dev/mapper/croot  20G2,9G   16G  16% /
 tmpfs  63G 72K   63G   1% /dev/shm
 tmpfs 5,0M   0  5,0M   0% /run/lock
 tmpfs  63G   0   63G   0%
 /sys/fs/cgroup
 tmpfs 4,0G   0  4,0G   0% /tmp
 /dev/md127488M140M  319M  31% /boot
 /dev/mapper/vg_bulk-backups--pg  1007G854G  103G  90%
 /srv/backups/pg
 /dev/mapper/vg_bulk-backups--bacula26T 13T   13T  50%
 /srv/backups/bacula
 tmpfs  13G   0   13G   0% /run/user/0
 }}}

 performing an online resize to add 10TB 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] #32568 [Internal Services/Service - nextcloud]: nextcloud collaborative "pad" synchronization breaks down with multiple users

[Tor Bug Tracker & Wiki]

#32568: nextcloud collaborative "pad" synchronization breaks down with multiple
users
-+-
 Reporter:  anarcat  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 also, thanks gaba and sysrqb for the diagnostics, that's super useful! :)
 in particular, thanks gaba for the detective work in the text app issue
 queue. it sure looks like there's a race condition in the code that can
 get triggered when multiple people edit at the same time. and since they
 found it, there's a good chance *that* specific issue gets fixed...

 so maybe this is just a matter of "wait and see" (ie. use pad.riseup.net
 for a bit longer) while they fix their things...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32570 [Metrics/CollecTor]: CollecTor stopped collecting snowflake stats

[Tor Bug Tracker & Wiki]

#32570: CollecTor stopped collecting snowflake stats
---+--
 Reporter:  cohosh |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cohosh):

 Hmm, I'm also getting outdated stats when I manually fetch the metrics
 log. This appears to be a snowflake issue. It's weird because the updated
 log file is there, the broker just doesn't appear to be serving it. I've
 created #32576.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by cohosh):

 * Attachment "metrics-broker.txt" 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] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by cohosh):

 * Attachment "metrics-fetch.txt" added.


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

[tor-bugs] #32576 [Circumvention/Snowflake]: Snowflake broker not serving metrics correctly

[Tor Bug Tracker & Wiki]

#32576: Snowflake broker not serving metrics correctly
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:  metrics
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:  Sponsor28|
-+--
 Looks like the snowflake broker isn't serving metrics since 2019-11-14
 (which happens to coincide with the host migration.

 At first I thought this was a DNS issue and filed #32570, but even when I
 manually fetch https://snowflake-broker.torproject.net/metrics I'm getting
 outdated metrics.

 I've attached the result of the above fetch as well as the metrics file
 located on the snowflake broker host that the broker *should* be reading
 from.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32568 [Internal Services/Service - nextcloud]: nextcloud collaborative "pad" synchronization breaks down with multiple users

[Tor Bug Tracker & Wiki]

#32568: nextcloud collaborative "pad" synchronization breaks down with multiple
users
-+-
 Reporter:  anarcat  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i just had a quick chat with micah about this, and here's a summary...

 for the sake of clarity, I'll start by naming things, because it's hard
 and i think a source of confusion:

  * '''onlyoffice''': the Nextcloud collaborative editor with support for
 Word and Excel documents, kind of like Google docs ('''installed on
 nc.tpo''')
  * '''etherpad app''', '''ownpad''': the
 [https://apps.nextcloud.com/apps/ownpad Nextcloud Etherpad app] that
 bridges Nextcloud with an existing Etherpad lite instance ('''not
 installed on nc.tpo''')
  * '''markdown app''', '''text app''': the
 [https://apps.nextcloud.com/apps/text Nextcloud Text app] that allows
 collaborative editing of text documents ('''installed on nc.tpo''').

 Let's take those one by one...

 == The text app

 The Text app we are having problems with in the meetings is built on top
 of [https://prosemirror.net/ Prosemirror], one of *many*
 [https://anarc.at/blog/2018-06-26-collaborative-editors-history/
 collaborative editors I have found in a previous research last year], and
 [https://anarc.at/blog/2018-06-26-collaborative-editors-history/ tiptap],
 a rich text editor built on top of Prosemirror. This app is
 [https://nextcloud.com/blog/nextcloud-introduces-collaborative-rich-text-
 editor/ fairly recent] (june 2019) and shipws with NC 17 by default.

 Micah told me the problems we are seeing are known, and others have
 suffered the same problems. He suspects the NC people haven't yet made the
 app scale to tens of users like we've seen in the vegas and metrics
 meetings (or at least, more than 10). This would confirm sysrqb's
 observations that it would fall apart under load. It works fine for a
 couple people, with some quirks, like a small scratch pad, but not so well
 for larger groups.

 There might be performance tweaks we could do in Nginx or elsewhere to fix
 the issue sysrqb observed.

 == The etherpad app

 This app is not yet installed on our instance, but could be. It was (or
 still is?) installed on nc.riseup.net but because Riseup's etherpad
 instance expires documents after a while, this led to data loss as the
 files disappeared from NC as well.

 So while we ''could'' deploy that app in our instance, it might lead to
 the same problem as there's no obvious marker that a pad will be removed
 in the NC UI. There is, of course, a huge warning in the pad itself when
 you first open it, but people forget about this all the time.

 If we use it only for ephemeral stuff like the vegas meeting notes, maybe
 that would be alright, but I would still be worried that people would use
 it for other things and lose data.

 Maybe we could just use Riseup's pad service for our meetings? Do we
 absolutely need this to be integrated in Nextcloud? If so we would have
 '''three''' different collaborative editors in nextcloud, which doesn't
 seem very reasonable to me...

 Alternatively, can't we just use meetbot to take minutes in meetings? :)

 == The onlyoffice app

 We *could* use the OnlyOffice app for meetings. We haven't tried that in a
 large scale yet, as far as I know. It might have exactly the same problems
 as the text app, maybe even worse because onlyoffice is much heavier. It
 would be worth a try, however.

 == TL;DR:

 Known issue. Needs debugging or we could just use pad.riseup.net or
 meetbot or onlyoffice for meetings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32536 [Applications/Tor Browser]: Security level set to "Safest" but JavaScript still Enabled.

[Tor Bug Tracker & Wiki]

#32536: Security level set to "Safest" but JavaScript still Enabled.
--+--
 Reporter:  tor70001  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * cc: ma1 (added)
 * keywords:   => noscript


Comment:

 Cypherpunk, are there steps for reproducing this or does it seem random?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 hey alec! Thanks for this build! It looks awesome. Running UI Review here:

 1. Let's organize the items at the URL bar. Is it possible to have the
 onion-label item first? see
 
[https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952%20-%20UI%20Review.png,
 here]

 2. I know the original design has the purple at the hover, but i think is
 more significant to show the color change when it loads. See
 
[https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952%20-%20UI%20Review.png,
 here]

 3. Colors are from
 [https://design.firefox.com/photon/visuals/color.html#purple, Photon]

 Light theme: Purple 70 #6200A4 / Blue 60 #0060DF
 Dark theme: Purple 50 #9400ff / Blue 60 #0060DF

 3. Can we use the circular onion icon? I aim to have updated all the
 onions at the URL bar and the circuit display too.

 4. I don't think we need a menu under the [...] It adds noise and I don't
 see a real use case for it. Do you think I'm missing something? Let me
 know.

 5. Can we prompt the discover-like doorhanger just for first-time users? I
 don't want to suggest users change the general settings every time they
 have an onion available. It will add extra friction in the entire
 experience which I don't think is needed.

 6. If users have selected [ask me every time] then we show the onion-label
 suggestion pill. If users have selected [always use .onion when available]
 then we redirect to the onion using the proposed animation. So, the onion-
 label pill doesn't need a menu. Again, am i missing something?

 7. I see an onboarding experience when we explain to users how to opt-in
 via `about:preferences`. I will file that ticket.

 8. I like how users don't need to restart the browser to op-out the
 automatic redirect.

 9. As part of #30024, I made this micro animation for when the onion gets
 updated. Do you think it is something doable? The persistent pill seems
 too much for it.
 https://trac.torproject.org/projects/tor/attachment/ticket/30024/prompt-
 onion-2.gif

 10. The panel at `about:preferences` looks great. Should we move it under
 the Tor section? I suggested to have it on Privacy & Security and maybe it
 is the right place to have it. What do others think?

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

Re: [tor-bugs] #23719 [Applications/Tor Browser]: Make sure WebExtensions are spared from JIT disabling in higher security settings (Medium-High)

[Tor Bug Tracker & Wiki]

#23719: Make sure WebExtensions are spared from JIT disabling in higher security
settings (Medium-High)
-+-
 Reporter:  cypherpunks  |  Owner:  acat
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-performance, GeorgKoppen201911,  |  Actual Points:  0.5
  TorBrowserTeam201911   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Yeah. Let's talk next Monday about it, I am not sure yet.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by antonela):

 * Attachment "21952 - UI Review.png" added.


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

Re: [tor-bugs] #23719 [Applications/Tor Browser]: Make sure WebExtensions are spared from JIT disabling in higher security settings (Medium-High)

[Tor Bug Tracker & Wiki]

#23719: Make sure WebExtensions are spared from JIT disabling in higher security
settings (Medium-High)
-+-
 Reporter:  cypherpunks  |  Owner:  acat
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-performance, GeorgKoppen201911,  |  Actual Points:  0.5
  TorBrowserTeam201911   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 What should we do about this one? It looks like we would need to enable
 JIT in webextensions apart from wasm to avoid this issue in HTTPS
 Everywhere (or try to improve the perf. on the JS side of HTTPS
 Everywhere, which I don't know if it's possible). I guess doing the wasm
 patch took some effort for tom, I'm not sure how feasible would it be to
 do a patch for JIT enabled for webextensions...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32255 [Applications/Tor Browser]: Missing ORIGIN header breaks CORS in Tor Browser 9.0

[Tor Bug Tracker & Wiki]

#32255: Missing ORIGIN header breaks CORS in Tor Browser 9.0
-+-
 Reporter:  complexparadox   |  Owner:  acat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-  |  Actual Points:
  regression, TorBrowserTeam201911R, tbb-|
  backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1598647.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31683 [Core Tor/Tor]: md: Bad family line in cached-microdescs.new

[Tor Bug Tracker & Wiki]

#31683: md: Bad family line in cached-microdescs.new
---+--
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  microdesc, 042-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

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


Comment:

 None of my hypotheses here were supported by the code; I don't see a fix
 happening here in 0.4.2.

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

Re: [tor-bugs] #31078 [Core Tor/Tor]: improve docs for config var abstraction

[Tor Bug Tracker & Wiki]

#31078: improve docs for config var abstraction
--+
 Reporter:  catalyst  |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  042-should|  Actual Points:
Parent ID:  #29211| Points:  2
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * milestone:  Tor: 0.4.2.x-final => Tor: 0.4.3.x-final


Comment:

 If we do this, it will happen in 0.4.3.

 (Should I go ahead and do 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] #31364 [Core Tor/Tor]: tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5 )

[Tor Bug Tracker & Wiki]

#31364: tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494:
warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5
)
-+-
 Reporter:  computer_freak   |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  microdesc assert 042-should  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 I haven't been able to figure this out beyond what's already on #31683.
 None of my hypotheses there turned out to be supported by the code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by eighthave):

 I'm digging into this now, one thing that surprised me is that the
 constants in `TorControlCommands` seem to be entirely unused.  The only
 thing that I could find in that file are the constants added by Briar for
 parsing the onion info, which does not come from Tor:

 {{{
 public static final String HS_ADDRESS = "onionAddress";
 public static final String HS_PRIVKEY = "onionPrivKey";
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19859 [Core Tor/Tor]: Expose stream isolation information to controllers

[Tor Bug Tracker & Wiki]

#19859: Expose stream isolation information to controllers
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs tor-control dns isolation |  Actual Points:
  needs-spec needs-design term-project   |
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * 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] #32575 [Core Tor/Tor]: CID 1455953: Resource leak in options_act_reversible()

[Tor Bug Tracker & Wiki]

#32575: CID 1455953:  Resource leak in options_act_reversible()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  coverity  |  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:  teor  |Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * reviewer:   => teor
 * actualpoints:   => .1


Comment:

 Branch is #32575 with PR at https://github.com/torproject/tor/pull/1557

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32575 [Core Tor/Tor]: CID 1455953: Resource leak in options_act_reversible()

[Tor Bug Tracker & Wiki]

#32575: CID 1455953:  Resource leak in options_act_reversible()
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  coverity
Actual Points: |  Parent ID:
   Points:  .1 |   Reviewer:
  Sponsor:  Sponsor31-can  |
---+
 {{{
  *** CID 1455953:  Resource leaks  (RESOURCE_LEAK)
 /src/app/config/config.c: 1983 in options_act_reversible()
 1977   tor_assert(*msg);
 1978
 1979   options_rollback_log_transaction(log_transaction);
 1980   options_rollback_listener_transaction(listener_transaction);
 1981
 1982  done:
 >>> CID 1455953:  Resource leaks  (RESOURCE_LEAK)
 >>> Variable "listener_transaction" going out of scope leaks the
 storage it points to.
 1983   return r;
 1984 }
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32574 [Applications/Tor Browser]: set up mirror repo on GitHub torproject/jtorctl

[Tor Bug Tracker & Wiki]

#32574: set up mirror repo on GitHub torproject/jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32534   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: hiro (added)


Comment:

 hiro offered to help us here.

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

Re: [tor-bugs] #32574 [Applications/Tor Browser]: set up mirror repo on GitHub torproject/jtorctl (was: set up mirror repo on https://github/torproject/jtorctl)

[Tor Bug Tracker & Wiki]

#32574: set up mirror repo on GitHub torproject/jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32534   | Points:
 Reviewer:   |Sponsor:
-+-

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

[tor-bugs] #32574 [Applications/Tor Browser]: set up mirror repo on https://github/torproject/jtorctl

[Tor Bug Tracker & Wiki]

#32574: set up mirror repo on https://github/torproject/jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor
 |  Browser
  Version:   |   Severity:  Normal
 Keywords:  Android, tbb-mobile, |  Actual Points:
  jtorctl, TorBrowserTeam202001  |
Parent ID:  #32534   | Points:
 Reviewer:   |Sponsor:
-+-
 The majority of the jtorctl work in the past 10 years has happened on
 github, so tor's official repo should have a mirror there to keep it
 visible there.

 It'd be fine to have the current torproject/jtorctl there to start with,
 as ancient as it is.  Then hopefully, I can make the
 guardianproject/jtorctl be a fork of that one.

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

Re: [tor-bugs] #32044 [Webpages/Website]: donation FAQ update on hardware

[Tor Bug Tracker & Wiki]

#32044: donation FAQ update on hardware
--+
 Reporter:  anarcat   |  Owner:  hiro
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

 * status:  assigned => 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] #32297 [Applications/Tor Browser]: Version 9 problem (regular and alpha) when some Exit Nodes are blocked by a website firewall

[Tor Bug Tracker & Wiki]

#32297: Version 9 problem (regular and alpha) when some Exit Nodes are blocked 
by a
website firewall
-+-
 Reporter:  mwolfe   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201911   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:13 mwolfe]:
 > Replying to [comment:12 gk]:
 > > Replying to [comment:11 mwolfe]:
 >
 > > > > Fixed in latest update. Now I see the New Tor Circuit when I click
 the (i) after Tor cannot conect! Thanks.
 > > > Sorry, fixed in OSX Capitan, still not working in Windows 10 ver
 1903
 > >
 > > Just to be on the same page here: with 9.0 this was an issue for both
 macOS and Windows but with 9.0.1 this is no issue any longer for macOS but
 Windows still remains? If so, can you re-test 9.0 now on your macOS so we
 can rule out some macOS related software update that fixed this. (old
 bundles are at: https://archive.torproject.org/tor-package-
 archive/torbrowser/9.0)
 > I am unable to load 9.0 on my Mac. I downloaded it from
 archive.torproject.org, but when I opened it, when it opened, it announced
 that it had upgraded itself to 9.0.1.

 This happens after starting it a second time, yes. But if you just start a
 fresh version and keep using it you should still have 9.0 because *using*
 9.0.1 requires a restart (the update is applied in the background,
 though).

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

Re: [tor-bugs] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 eighthave: nobody responded so far, and I am sorry about that. +1 to what
 you said in comment:5 and comment:6. Please move forward with that. We'll
 meanwhile think about how to integrate the `jtorctl` release builds and
 Maven Central pushed into our build setup.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32297 [Applications/Tor Browser]: Version 9 problem (regular and alpha) when some Exit Nodes are blocked by a website firewall

[Tor Bug Tracker & Wiki]

#32297: Version 9 problem (regular and alpha) when some Exit Nodes are blocked 
by a
website firewall
-+-
 Reporter:  mwolfe   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201911   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 So I assume this is now a Windows-only issue. I thought the issue might be
 reproducible in Windows with safe mode, but unfortunately I could still
 not reproduce it. It's difficult to track down the problem without more
 info. Not sure if you `TorNotice.zip` was intended to be the Browser
 Console logs that I asked in comment:8, but the file is empty. Could you
 please check again if there are any errors in `Browser Console`
 (Ctrl+Shift+J) when you load the pages with errors and try to request new
 circuits?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32549 [Applications/Tor Browser]: NoScript makes requests to sync-messages.invalid

[Tor Bug Tracker & Wiki]

#32549: NoScript makes requests to sync-messages.invalid
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 What is the intended behavior? That every message about blocked by
 NoScript script on the Safest level is complemented with the two mentioned
 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

[tor-bugs] #32573 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Https on openculture.com

[Tor Bug Tracker & Wiki]

#32573: Https on openculture.com
-+-
 Reporter:  cypherpunks  |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  HTTPS Everywhere/EFF-HTTPS
 |  Everywhere
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 The website openculture.com is redirected to https via a ruleset. This
 redirects to 403 error. Should the ruleset be removed? I have contacted
 the website to let them know.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32549 [Applications/Tor Browser]: NoScript makes requests to sync-messages.invalid

[Tor Bug Tracker & Wiki]

#32549: NoScript makes requests to sync-messages.invalid
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by ma1):

 Replying to [comment:8 cypherpunks]:
 > Looks like `noscript-csp.invalid` is still interfering/messing with CSP:
 > {{{
 > [11-22 09:47:42] Torbutton INFO: tor SOCKS: https://noscript-
 csp.invalid/__NoScript_Probe__/ via
 >torproject.org:602f1e2c568ce366b5800e14a4383d41
 > Content Security Policy: The page’s settings blocked the loading of a
 resource at https://blog.torproject.org/sites/default/files/js/js.js
 (“script-src”).
 > }}}
 No interfering/messing here.
 That's the intended behavior. It's used to intercept and take note of any
 CSP violation in order to buy the UI when it's time (and again, these CSP
 reports won't reach the network anyway).
 This is likely going to be replaced with a securitypolicyviolation in the
 content script, now that's available on ESR 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

Re: [tor-bugs] #32554 [Metrics/CollecTor]: Stop checking and reloading configuration file

[Tor Bug Tracker & Wiki]

#32554: Stop checking and reloading configuration file
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Thanks for looking! Merged! 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] #32324 [Applications/Tor Browser]: Introduce Letterboxing to users

[Tor Bug Tracker & Wiki]

#32324: Introduce Letterboxing to users
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam201912   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "32324.png" added.


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

Re: [tor-bugs] #32324 [Applications/Tor Browser]: Introduce Letterboxing to users

[Tor Bug Tracker & Wiki]

#32324: Introduce Letterboxing to users
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam201912   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "32324.png" added.


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

Re: [tor-bugs] #32570 [Metrics/CollecTor]: CollecTor stopped collecting snowflake stats

[Tor Bug Tracker & Wiki]

#32570: CollecTor stopped collecting snowflake stats
---+--
 Reporter:  cohosh |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 I did notice this problem, too, but did not get to letting you know about
 it yet.

 So, when I open https://snowflake-broker.freehaven.net/metrics or https
 ://snowflake-broker.torproject.net/metrics in a browser, I see outdated
 statistics with all zeroes. That's what CollecTor sees, too.

 Could it be that you need to update something on your side?

 Or can you tell me a URL that has recent statistics that I can put into
 CollecTor's config file? 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] #32324 [Applications/Tor Browser]: Introduce Letterboxing to users

[Tor Bug Tracker & Wiki]

#32324: Introduce Letterboxing to users
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam201912   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 thanks y'all for the useful comments!

 Yes, i agree. Having the grey area clickable is confusing, and we want to
 make sure that the grey area is not more annoying than what already it is.

 I think the (?) icon idea is our best option now.
 [https://trac.torproject.org/projects/tor/attachment/ticket/32324/32324.png,
 I've made some mocks.] We can discuss them during our next meeting with
 the entire team.

 I'm using the [https://design.firefox.com/icons/viewer/#help, default Help
 Photon icon]. Our best explainer now lives at
 `https://support.torproject.org/tbb/maximized-torbrowser-window/`. Let's
 link there.

 For the implementation, let's make sure that we are using a context-fill
 icon so we have a proper light filling when dark themes are enabled and
 vice-versa.

 Should we show this icon forever? Perhaps, we can remove it after the
 first click.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32324 [Applications/Tor Browser]: Introduce Letterboxing to users

[Tor Bug Tracker & Wiki]

#32324: Introduce Letterboxing to users
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam201912   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "32324.png" added.


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

Re: [tor-bugs] #32512 [Applications/Tor Browser]: preference "browser.download.dir" is ignored

[Tor Bug Tracker & Wiki]

#32512: preference "browser.download.dir" is ignored
--+---
 Reporter:  Yeti  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Yeti):

 Thank you and sorry for this misplaced 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] #32418 [Applications/Tor Browser]: Torbrowser tells on every start, that it can't update although it is newest

[Tor Bug Tracker & Wiki]

#32418: Torbrowser tells on every start, that it can't update although it is 
newest
--+---
 Reporter:  Yeti  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Yeti):

 Replying to [comment:5 boklm]:
 > In some cases it can be useful to have a way to disable the updater, so
 I think having support for the `app.update.enabled` pref would be nice.
 I support that.
 At least until Mozilla decides to change this doubtful behaviour. Programs
 started with user rights shouldn't be able to write into program
 directories. It's easy to click away the warning at every start but when
 it gets habitual (or someone writes a userscript for that), it's bad.

 Replying to [comment:4 mcs]:
 > Another alternative would be to decide that installing in a read-only
 area of the file system [...] is not something we can support.

 This would be the worst case, especially for security related software.
 (IMHO this even should be default.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25924 [Metrics/Statistics]: Improve execution time of onion service statistics module

[Tor Bug Tracker & Wiki]

#25924: Improve execution time of onion service statistics module
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Alright, I think I know what's going on. The reason why runtime keeps
 getting higher is that we're re-processing an ever increasing number of
 onion service statistics reported by relays for which we computed a
 network fraction of zero for having observed these statistics. Of course,
 it does make sense not to extrapolate these numbers, because we cannot
 divide by zero. But we should remember this fact and not attempt to
 extrapolate statistics in all future executions. That's also what we do
 with statistics reported by relays with non-zero network fractions: we
 notice that we did extrapolate these before and skip them. This is the
 reason why runtime keeps getting higher and higher over time. The fix is
 simply to write extrapolated numbers for all reported statistics.

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 web.git/commit/?h=task-25924=ed4f75df1a246afdc86b2c38f95a31e6a37a5d33
 commit ed4f75d in my task-25924 branch]. I did test this branch locally,
 but before deploying it we should make fresh a backup of
 `work/modules/hidserv/`, just in case.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32549 [Applications/Tor Browser]: NoScript makes requests to sync-messages.invalid

[Tor Bug Tracker & Wiki]

#32549: NoScript makes requests to sync-messages.invalid
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Looks like `noscript-csp.invalid` is still interfering/messing with CSP:
 {{{
 [11-22 09:47:42] Torbutton INFO: tor SOCKS: https://noscript-
 csp.invalid/__NoScript_Probe__/ via
torproject.org:602f1e2c568ce366b5800e14a4383d41
 Content Security Policy: The page’s settings blocked the loading of a
 resource at https://blog.torproject.org/sites/default/files/js/js.js
 (“script-src”).
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32572 [Applications/Tor Browser]: Expose Tor advanced settings in about:preferences#tor

[Tor Bug Tracker & Wiki]

#32572: Expose Tor advanced settings in about:preferences#tor
--+--
 Reporter:  antonela  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by antonela:

Old description:

> Since TB9.0, we have room to expose more Tor settings in Tor Browser UI
> via `about:preferences#tor`.
>
> Let's use this ticket to collect and discuss which kind of Tor settings
> we want to offer to Tor Browser advanced users.

New description:

 Since TB9.0, we have room to expose more Tor settings in Tor Browser UI
 via `about:preferences#tor`.

 Let's use this ticket as a parent ticket to collect and discuss which kind
 of Tor settings we want to offer to Tor Browser advanced users.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32572 [Applications/Tor Browser]: Expose Tor advanced settings in about:preferences#tor

[Tor Bug Tracker & Wiki]

#32572: Expose Tor advanced settings in about:preferences#tor
--+--
 Reporter:  antonela  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 There is a conversation going on in our mailing list about it:

 https://lists.torproject.org/pipermail/tor-dev/2019-November/014077.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

[tor-bugs] #32572 [Applications/Tor Browser]: Expose Tor advanced settings in about:preferences#tor

[Tor Bug Tracker & Wiki]

#32572: Expose Tor advanced settings in about:preferences#tor
--+--
 Reporter:  antonela  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ux-team
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Since TB9.0, we have room to expose more Tor settings in Tor Browser UI
 via `about:preferences#tor`.

 Let's use this ticket to collect and discuss which kind of Tor settings we
 want to offer to Tor Browser advanced users.

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