Re: [tor-bugs] #34013 [Applications/Tor Browser]: Bump node version to v10.19

[Tor Bug Tracker & Wiki]

#34013: Bump node version to v10.19
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam202004   |
Parent ID:  #33626   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 End-of-life: April 2021
 Critical bug fixes and security updates:
 https://nodejs.org/download/release/latest-dubnium/

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

Re: [tor-bugs] #34011 [Applications/Tor Browser]: Bump clang version to 9.0.1

[Tor Bug Tracker & Wiki]

#34011: Bump clang version to 9.0.1
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam202004   |
Parent ID:  #33626   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Some reproducibility issues were fixed only in clang 10.0.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] #34043 [Circumvention/Snowflake]: Update snowflake to persist sessions across proxies

[Tor Bug Tracker & Wiki]

#34043: Update snowflake to persist sessions across proxies
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 I'm now testing a build with a branch (an updated version of the one from
 comment:6:ticket:33745) and will update if it builds successfully.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34043 [Circumvention/Snowflake]: Update snowflake to persist sessions across proxies

[Tor Bug Tracker & Wiki]

#34043: Update snowflake to persist sessions across proxies
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This updates snowflake for #33745 and #33897, which add Turbo Tunnel
 features to snowflake.

 There are two new dependencies, kcp-go and smux, which together make up
 the inner reliability layer. There's a patch to kcp-go to eliminate
 dependencies of features we don't use.

 This is a Tor Browser ticket but I'm putting it in Circumvention/Snowflake
 to start to see if there's anything else we want to merge at the same
 time. Maybe #34042?

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

Re: [tor-bugs] #34042 [Circumvention/Snowflake]: Reduce DataChannelTimeout

[Tor Bug Tracker & Wiki]

#34042: Reduce DataChannelTimeout
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 In comment:2:ticket:33897 I started testing with 5 s, however I backed it
 off to 10 s after I saw that for me, 3 s is a typical delay.

 {{{
 2020/04/27 01:17:42 WebRTC: DataChannel created.
 2020/04/27 01:17:45 WebRTC: DataChannel.OnOpen
 }}}

 {{{
 2020/04/27 21:09:50 WebRTC: DataChannel created.
 2020/04/27 21:09:53 WebRTC: DataChannel.OnOpen
 }}}

 {{{
 2020/04/28 02:39:24 WebRTC: DataChannel created.
 2020/04/28 02:39:27 WebRTC: DataChannel.OnOpen
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34042 [Circumvention/Snowflake]: Reduce DataChannelTimeout

[Tor Bug Tracker & Wiki]

#34042: Reduce DataChannelTimeout
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Since #33897 we have separate timeout controls for first establishing the
 data channel (`DataChannelTimeout`) and deciding a once-working data
 channel has died (`SnowflakeTimeout`). They are both currently set to 30
 s. We can lower `DataChannelTimeout` to discard non-working proxies more
 quickly.

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

Re: [tor-bugs] #33235 [Core Tor/Tor]: Proposal 312: 3.2.1. Test Address torrc Option Configurations

[Tor Bug Tracker & Wiki]

#33235: Proposal 312: 3.2.1. Test Address torrc Option Configurations
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop312, ipv6  |  Actual Points:
Parent ID:  #33049 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-must
---+

Old description:

> Once we have implemented IPv6 Addresses in #33233, and automatic IPv6
> ORPorts in #33246, tor should support the following Address
> configurations:
>   A. IPv4 Address / hostname (for IPv6 only),
>   B. IPv6 Address / hostname (for IPv4 only),
>   C. IPv4 Address only / try to guess IPv6, then check its reachability
>  (see section 4.3.1 in [Proposal 311: Relay IPv6 Reachability]), and
>   D. IPv6 Address only / guess IPv4, then its reachability must succeed.
> There are also similar configurations where a hostname is configured, but
> it only provides IPv4 or IPv6 addresses.
>
> Combination C is the most common legacy configuration. We want to
> support the following outcomes for legacy configurations:
>   * automatic upgrades to guessed and reachable IPv6 addresses,
>   * continuing to operate on IPv4 when the IPv6 address can't be guessed,
> and
>   * continuing to operate on IPv4 when the IPv6 address has been guessed,
> but it is unreachable.
>
> See proposal 312, section 3.2.1, testing notes:
> ​https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-
> ipv6-addr.txt#n270

New description:

 This ticket depends on IPv6 Addresses in #33233, and automatic IPv6
 ORPorts in #33246.

 We should support the following combinations of address literals and
 hostnames:

 Legacy configurations:
   A. No configured Address option
   B. Address IPv4 literal
   C. Address hostname (use IPv4 and IPv6 DNS addresses)

 New configurations:
   D. Address IPv6 literal
   E. Address IPv4 literal / Address IPv6 literal
   F. Address hostname / Address hostname (use IPv4 and IPv6 DNS addresses)
   G. Address IPv4 literal / Address hostname (only use IPv6 DNS addresses)
   H. Address hostname (only use IPv4 DNS addresses) / Address IPv6 literal

 If we can't find an IPv4 or IPv6 address using the configured Address
 options:
   * No IPv4: guess IPv4, and its reachability must succeed.
   * No IPv6: guess IPv6, publish if reachability succeeds.

 Combinations A and B are the most common legacy configurations. We want to
 support the following outcomes for all legacy configurations:
   * automatic upgrades to guessed and reachable IPv6 addresses,
   * continuing to operate on IPv4 when the IPv6 address can't be guessed,
 and
   * continuing to operate on IPv4 when the IPv6 address has been guessed,
 but it is unreachable.

 See proposal 312, section 3.2.1, testing notes:
 ​https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-
 ipv6-addr.txt#n270

--

Comment (by teor):

 Update proposal and 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] #33897 [Circumvention/Snowflake]: Remove buffering from WebRTCPeer

[Tor Bug Tracker & Wiki]

#33897: Remove buffering from WebRTCPeer
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 Merged in [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/log/?id=047d3214bfb46de07e5d9f223e4fb1ba24584c8a
 047d3214bfb46de07e5d9f223e4fb1ba24584c8a].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34041 [Circumvention]: Discord sent me an email listing my real ip as login location

[Tor Bug Tracker & Wiki]

#34041: Discord sent me an email listing my real ip as login location
-+-
 Reporter:  Camillia124  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Component:
 |  Circumvention
  Version:  Tor: unspecified |   Severity:
 Keywords:  discord, ip address, real location,  |  Critical
  bug, critical  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 I logged in to discord using tor and then got an email from discord saying
 someone had logged in to discord and giving my REAL IP address.

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

Re: [tor-bugs] #33897 [Circumvention/Snowflake]: Remove buffering from WebRTCPeer

[Tor Bug Tracker & Wiki]

#33897: Remove buffering from WebRTCPeer
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+-
Changes (by cohosh):

 * status:  needs_review => merge_ready


Comment:

 Awesome, looks good.

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

Re: [tor-bugs] #33224 [Core Tor/Tor]: Prop 311: 4.3.2. Add AssumeIPv6Reachable Option and Consensus Parameter (was: Prop 311: 4.3.2. Add AssumeIPv6Reachable Option)

[Tor Bug Tracker & Wiki]

#33224: Prop 311: 4.3.2. Add AssumeIPv6Reachable Option and Consensus Parameter
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33221 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-must
---+

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

Re: [tor-bugs] #33224 [Core Tor/Tor]: Prop 311: 4.3.2. Add AssumeIPv6Reachable Option

[Tor Bug Tracker & Wiki]

#33224: Prop 311: 4.3.2. Add AssumeIPv6Reachable Option
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33221 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-must
---+

Comment (by teor):

 This ticket is optional, but there are some risks if we don't implement
 it.

 Here are the risks and mitigations:

 Don't implement the AssumeIPv6Reachable torrc option:
 * Low Risk
 * Issue:
   * Operators can't disable IPv6 self-tests, but continue using IPv4
 self-tests.
 * Workaround:
   * Operators use AssumeReachable to disable IPv4 and IPv6 self-tests.

 Don't implement the AssumeIPv6Reachable consensus parameter:
 * Medium Risk
 * Issue:
   * If there is a network-wide issue with IPv6 self-tests, all IPv6
 relays (30%) and bridges (unknown percentage) will go down.
 * Workaround:
   * There is no workaround.
 * Mitigation:
   * Make sure chutney fails when relay and bridge reachability
 self-tests fail. Chutney ensures relay self-tests work, but
 doesn't check bridges. There are two alternative ways to do
 bridge checks:
 * Fix tor bridge descriptor uploads (#33582) and check them in
   chutney (#33407), or
 * Make chutney check tor's logs for reachability self-tests
   (#34037).

 If we implement the consensus parameter, we should also implement the
 torrc option, so operators can configure the option independently.

 Since this option stops relays publishing their descriptors, we should
 probably test it in chutney, or on the public tor network. (See #33229 and
 #33230.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34040 [Core Tor]: Video but no sound in TOR, Knoppix OS

[Tor Bug Tracker & Wiki]

#34040: Video but no sound in TOR, Knoppix OS
--+--
 Reporter:  AntiDiluv |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: 0.4.2.7  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I'm running an unaltered Knoppix OS from a USB, on a Dell Latitude E6500
 laptop: 2 core, Intel 45 chipset, 64bit capable but only running 32 bit;
 512 & 8 GB memory capable but 2 GB memory installed.
"About" in the browser says this is Tor 9.0.9, up to date,Firefox
 68.7.0esr) (32-bit) up to date.
While in Windows 7 Ultimate (32 bit), sound & video work fine locally &
 on web in both Firefox and TOR. In Knoppix, both work locally & in
 Firefox. But in Knoppix in TOR, I can play video but THERE's NO SOUND.
 I'm illiterate in unix/debian commands. This is all new to me. Can
 someone guide me in plainspeak through trying some fixes in Knoppix?
 I'm coming up empty on the internet. I would very much appreciate any
 help. Thank you.

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

[tor-bugs] #34039 [Core Tor]: Video but no sound in TOR, Knoppix OS

[Tor Bug Tracker & Wiki]

#34039: Video but no sound in TOR, Knoppix OS
--+--
 Reporter:  AntiDiluv |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: 0.4.2.7  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I'm running an unaltered Knoppix OS from a USB, on a Dell Latitude E6500
 laptop: 2 core, Intel 45 chipset, 64bit capable but only running 32 bit;
 512 & 8 GB memory capable but 2 GB memory installed.
"About" in the browser says this is Tor 9.0.9, up to date,
 Firefox  68.7.0esr) (32-bit) up to date.
While in Windows 7 Ultimate (32 bit), sound & video work fine locally &
 on web in both Firefox and TOR. In Knoppix, both work locally & in
 Firefox. But in Knoppix in TOR, I can play video but THERE's NO SOUND.
 I'm illiterate in unix/debian commands. This is all new to me. Can
 someone guide me in plainspeak through trying some fixes in Knoppix?
 I'm coming up empty on the internet. I would very much appreciate any
 help. Thank you.

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

[tor-bugs] #34038 [Community]: Video but no sound in TOR, Knoppix OS

[Tor Bug Tracker & Wiki]

#34038: Video but no sound in TOR, Knoppix OS
---+---
 Reporter:  AntiDiluv  |  Owner:  ggus
 Type:  task   | Status:  new
 Priority:  Very High  |  Component:  Community
  Version:  Tor: 0.4.2.7   |   Severity:  Major
 Keywords:  Knoppix, Linux, Tor, audio, sound  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
 I'm running an unaltered Knoppix OS from a USB, on a Dell Latitude E6500
 laptop: 2 core, Intel 45 chipset, 64bit capable but only running 32 bit;
 512 & 8 GB memory capable but 2 GB memory installed.
"About" in the browser says this is Tor 9.0.9, up to date,Firefox
 68.7.0esr) (32-bit) up to date.
While in Windows 7 Ultimate (32 bit), sound & video work fine locally &
 on web in both Firefox and TOR. In Knoppix, both work locally & in
 Firefox. But in Knoppix in TOR, I can play video but THERE's NO SOUND.
 I'm illiterate in unix/debian commands. This is all new to me. Can
 someone guide me in plainspeak through trying some fixes in Knoppix?
 I'm coming up empty on the internet. I would very much appreciate any
 help. Thank you - AntiDiluv

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

Re: [tor-bugs] #33582 [Core Tor/Tor]: Make bridges wait until they have bootstrapped, before publishing their descriptor

[Tor Bug Tracker & Wiki]

#33582: Make bridges wait until they have bootstrapped, before publishing their
descriptor
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-relay, prop311,  |  Actual Points:
  outreachy-ipv6, easy   |
Parent ID:  #33050   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-

Old description:

> On bridges, there's a race condition when bridges try to publish their
> descriptor to the bridge authority:
> * bridges try to publish their descriptors before bootstrapping
> * but bridges can't publish their descriptors, because they don't have
> enough directory info to build a circuit to the bridge authority
>
> Bridges will eventually try to publish their descriptors again, when they
> become dirty.
>
> We should make bridges wait until they have bootstrapped, before they try
> to publish their descriptors. (This might be a good change for relays as
> well: there isn't much point in publishing a relay that can't bootstrap.)
>
> This issue happens regardless of `AssumeReachable`. It is most obvious in
> chutney networks.

New description:

 Instead of this fix, we can make chutney check tor's logs for reachability
 self-test successes. See #34037.

 On bridges, there's a race condition when bridges try to publish their
 descriptor to the bridge authority:
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Bridges will eventually try to publish their descriptors again, when they
 become dirty.

 We should make bridges wait until they have bootstrapped, before they try
 to publish their descriptors. (This might be a good change for relays as
 well: there isn't much point in publishing a relay that can't bootstrap.)

 This issue happens regardless of `AssumeReachable`. It is most obvious in
 chutney networks.

--

Comment (by teor):

 Instead of this fix, we can make chutney check tor's logs for reachability
 self-test successes. See #34037.

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

Re: [tor-bugs] #33407 [Core Tor/Tor]: Make chutney bridge authorities publish bridges in their networkstatus-bridges

[Tor Bug Tracker & Wiki]

#33407: Make chutney bridge authorities publish bridges in their networkstatus-
bridges
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, tor-bridge, chutney,  |  Actual Points:
  outreachy-ipv6 |
Parent ID:  #33050   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-

Old description:

> This chutney fix is blocked by a tor bridge bootstrap / descriptor upload
> race condition, see #33582.
>
> (Chutney may need to check for this tor bug fix. One way to do that is to
> modify the tor version EXTRA_INFO so it is sortable, see #33408.)
>
> Chutney bridge authorities don't have any bridges in their networkstatus-
> bridges. That's a problem, because we want to check networkstatus-bridges
> for the reachability checks in #33232.
>
> There are two different ways to fix this issue:
> 1. Implement the robust ORPort reachability self-tests in #33222. Bridges
> bootstrap, self-test reachability, and then publish their descriptors.
>
> 2. Make bridge descriptor upload wait until the bridge has bootstrapped
> in #33582. Bridges bootstrap, then publish their descriptors.
>
> Once bridges upload their descriptors, we can make chutney check the
> bridge authority's networkstatus-bridges for bridge nicknames (this
> ticket).
>
> We can only do the networkstatus-bridges check on tor versions with the
> #33222 or #33582 fixes. If we want to do these tests before an
> 0.4.4-alpha release, we can:
> * implement ordered version EXTRA_INFO in #33408,
> * check for a log message that we add to tor during the fix, or
> * set an environmental variable.
>
> Whatever we do, we should also check for the next 0.4.4-alpha release, so
> we don't depend on these implementation details.
>
> We don't have to do these fixes, because it should be enough to test
> relay reachability. But we would risk breaking bridge reachability tests,
> and not knowing about it until after a release.

New description:

 Instead of this fix, we can make chutney check tor's logs for reachability
 self-test successes. See #34037.

 This chutney fix also needs fixes to a tor bridge descriptor upload race
 condition, see #33582.

 (Chutney may need to check for this tor bug fix. One way to do that is to
 modify the tor version EXTRA_INFO so it is sortable, see #33408.)

 Chutney bridge authorities don't have any bridges in their networkstatus-
 bridges. That's a problem, because we want to check networkstatus-bridges
 for the reachability checks in #33232.

 There are two different ways to fix this issue:
 1. Implement the robust ORPort reachability self-tests in #33222. Bridges
 bootstrap, self-test reachability, and then publish their descriptors.

 2. Make bridge descriptor upload wait until the bridge has bootstrapped in
 #33582. Bridges bootstrap, then publish their descriptors.

 Once bridges upload their descriptors, we can make chutney check the
 bridge authority's networkstatus-bridges for bridge nicknames (this
 ticket).

 We can only do the networkstatus-bridges check on tor versions with the
 #33222 or #33582 fixes. If we want to do these tests before an 0.4.4-alpha
 release, we can:
 * implement ordered version EXTRA_INFO in #33408,
 * check for a log message that we add to tor during the fix, or
 * set an environmental variable.

 Whatever we do, we should also check for the next 0.4.4-alpha release, so
 we don't depend on these implementation details.

 We don't have to do these fixes, because it should be enough to test relay
 reachability. But we would risk breaking bridge reachability tests, and
 not knowing about it until after a release.

--

Comment (by teor):

 Instead of this fix, we can make chutney check tor's logs for reachability
 self-test successes. See #34037.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34037 [Core Tor/Chutney]: Make chutney check tor's logs for reachability self-test success

[Tor Bug Tracker & Wiki]

#34037: Make chutney check tor's logs for reachability self-test success
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  ipv6, prop311
Actual Points:|  Parent ID:  #33050
   Points:  2 |   Reviewer:
  Sponsor:  Sponsor55-can |
--+---
 This ticket is an alternative to #33407.

 Instead of fixing bridge descriptor uploads, we can check bridge logs to
 make sure that reachability self-tests have succeeded.

 For consistency, we should also do the same checks for relays.

 We can only do these tests on authorities, relays, and bridges that are
 configured with `AssumeReachable 0`. Chutney's current defaults are:
 * directory authorities: 1
 * bridge authorities: 1
 * relays: 0
 * bridges: 0
 * clients: clients never perform reachability self-tests

 Some custom chutney networks may set `AssumeReachable 1` for relays and
 bridges. So we should make it easy for them to disable these checks.

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

Re: [tor-bugs] #33223 [Core Tor/Tor]: Prop 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is Unreachable (was: Prop 311: 4.3.1. Refusing to Publish Descriptor if IPv6 ORPort is Unreachable)

[Tor Bug Tracker & Wiki]

#33223: Prop 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is Unreachable
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33221 | Points:  3
 Reviewer: |Sponsor:  Sponsor55-must
---+

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

Re: [tor-bugs] #33222 [Core Tor/Tor]: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests (was: Prop 311: 4.2. Checking IPv6 ORPort Reachability)

[Tor Bug Tracker & Wiki]

#33222: Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33221 | Points:  6
 Reviewer: |Sponsor:  Sponsor55-must
---+

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

Re: [tor-bugs] #33221 [Core Tor/Tor]: Prop 311: 4. Ensure Relay and Bridge IPv6 ORPorts are Reachable (was: Prop 311: 4. Check Relay and Bridge IPv6 ORPort Reachability)

[Tor Bug Tracker & Wiki]

#33221: Prop 311: 4. Ensure Relay and Bridge IPv6 ORPorts are Reachable
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, network-team- |  Actual Points:
  roadmap-2020Q2 |
Parent ID:  #33048   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor55-must
-+-

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

Re: [tor-bugs] #33897 [Circumvention/Snowflake]: Remove buffering from WebRTCPeer

[Tor Bug Tracker & Wiki]

#33897: Remove buffering from WebRTCPeer
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:4 cohosh]:
 > `broker.Negotiate()` can still return a `nil` answer and we're no longer
 checking for that [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/client/lib/webrtc.go#n268 like we used to].
 At first glance, it looks like it '''shouldn't''' return a nil answer and
 a non-nil error, but `util.DeserializeSessionDescription`
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/common/util/util.go#n21 can return a nil
 value] without an error attached to it which would cause problems.

 That's a great catch. Indeed I looked at `broker.Negotiate` quickly and
 wrongly decided that it wouldn't return `(nil, nil)`. Here's a new branch
 to review. The only difference is
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug33897_2&id=b48fb781ee15cf033efc61496746a295dc0d63c7
 this patch] to make `util.DeserializeSessionDescription` and
 `util.SerializeSessionDescription` return an error.

 
https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=bug33897_2&id=047d3214bfb46de07e5d9f223e4fb1ba24584c8a
 
https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=bug33897_2&id=047d3214bfb46de07e5d9f223e4fb1ba24584c8a&id2=76732155e7d730573b3ced62209e4e1e4ead511c

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

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by anarcat:

Old description:

> while working on the nextcloud project, we realized it wasn't exactly
> trivial to setup the LDAP bridge because of our specific requirements (no
> direct connexion, offline support). so we just didn't implement it yet
> (#32332). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
> procedure, but then i realized there are probably many other such
> services that do *not* connect with LDAP.
>
> On the top of my head, there's at least Trac and mailing lists, for
> example, which are managed completely separarely. Audit
> [[org/operations/services]] and see which services are manager manually
> and which aren't. Those services have been identified as particularly out
> of sync:
>
>  * rt.torproject.org, see #34036 for an example audit
>  * blog.torproject.org
>  * email, see also #32558
>  * IRC, the @tor-tpomember group
>  * Nagios contacts (almost cleaned up, but will still need checking for
> sysadmins arriving/departing)
>
> That list is not exhaustive.
>
> Then make sure there's an automated way to add/remove users to services,
> either by hooking up the service with LDAP, or by creating a wrapper
> script that will manage those accesses.
>
> So the following needs to be done here:
>
>  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
> new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
> retire-a-user], the various services to add/remove people to
>  * [ ] automate the above with a script or LDAP
>
> Note that the two pages have different scope: `new-person` is about TSA
> while `retire-a-user` is broader. This should also be converged, probably
> in the broader sense.
>
> Also note that a particularly tricky situation is when we want to do a
> *partial* removal. For example, maybe the person needs to be removed from
> tor-internal, but keep access to some servers. Or removed from server,
> but keep an email alias.
>
> The latter case is especially sensitive: some people feel keeping their
> email alias around forever is an inalienable right and that we should
> keep forwarding their email even after they are fully retired from Tor.
> This policy needs to be clarified, see #32558 for that particularly
> tricky problem.

New description:

 while working on the nextcloud project, we realized it wasn't exactly
 trivial to setup the LDAP bridge because of our specific requirements (no
 direct connexion, offline support). so we just didn't implement it yet
 (#32332). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
 procedure, but then i realized there are probably many other such services
 that do *not* connect with LDAP.

 On the top of my head, there's at least Trac and mailing lists, for
 example, which are managed completely separarely. Audit
 [[org/operations/services]] and see which services are manager manually
 and which aren't. Those services have been identified as particularly out
 of sync:

  * blog.torproject.org
  * email, see also #32558
  * IRC, the @tor-tpomember group
  * Nagios contacts (almost cleaned up, but will still need checking for
 sysadmins arriving/departing)
  * Nextcloud (#32332)
  * rt.torproject.org, see #34036 for an example audit

 That list is not exhaustive.

 Then make sure there's an automated way to add/remove users to services,
 either by hooking up the service with LDAP, or by creating a wrapper
 script that will manage those accesses.

 So the following needs to be done here:

  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
 new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
 retire-a-user], the various services to add/remove people to
  * [ ] automate the above with a script or LDAP

 Note that the two pages have different scope: `new-person` is about TSA
 while `retire-a-user` is broader. This should also be converged, probably
 in the broader sense.

 Also note that a particularly tricky situation is when we want to do a
 *partial* removal. For example, maybe the person needs to be removed from
 tor-internal, but keep access to some servers. Or removed from server, but
 keep an email alias.

 The 

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by anarcat:

Old description:

> while working on the nextcloud project, we realized it wasn't exactly
> trivial to setup the LDAP bridge because of our specific requirements (no
> direct connexion, offline support). so we just didn't implement it yet
> (#32332). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
> procedure, but then i realized there are probably many other such
> services that do *not* connect with LDAP.
>
> On the top of my head, there's at least Trac and mailing lists, for
> example, which are managed completely separarely. Audit
> [[org/operations/services]] and see which services are manager manually
> and which aren't. Those services have been identified as particularly out
> of sync:
>
>  * rt.torproject.org
>  * blog.torproject.org
>  * email, see also #32558
>  * IRC, the @tor-tpomember group
>  * Nagios contacts (almost cleaned up, but will still need checking for
> sysadmins arriving/departing)
>
> That list is not exhaustive.
>
> Then make sure there's an automated way to add/remove users to services,
> either by hooking up the service with LDAP, or by creating a wrapper
> script that will manage those accesses.
>
> So the following needs to be done here:
>
>  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
> new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
> retire-a-user], the various services to add/remove people to
>  * [ ] automate the above with a script or LDAP
>
> Note that the two pages have different scope: `new-person` is about TSA
> while `retire-a-user` is broader. This should also be converged, probably
> in the broader sense.
>
> Also note that a particularly tricky situation is when we want to do a
> *partial* removal. For example, maybe the person needs to be removed from
> tor-internal, but keep access to some servers. Or removed from server,
> but keep an email alias.
>
> The latter case is especially sensitive: some people feel keeping their
> email alias around forever is an inalienable right and that we should
> keep forwarding their email even after they are fully retired from Tor.
> This policy needs to be clarified, see #32558 for that particularly
> tricky problem.

New description:

 while working on the nextcloud project, we realized it wasn't exactly
 trivial to setup the LDAP bridge because of our specific requirements (no
 direct connexion, offline support). so we just didn't implement it yet
 (#32332). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
 procedure, but then i realized there are probably many other such services
 that do *not* connect with LDAP.

 On the top of my head, there's at least Trac and mailing lists, for
 example, which are managed completely separarely. Audit
 [[org/operations/services]] and see which services are manager manually
 and which aren't. Those services have been identified as particularly out
 of sync:

  * rt.torproject.org, see #34036 for an example audit
  * blog.torproject.org
  * email, see also #32558
  * IRC, the @tor-tpomember group
  * Nagios contacts (almost cleaned up, but will still need checking for
 sysadmins arriving/departing)

 That list is not exhaustive.

 Then make sure there's an automated way to add/remove users to services,
 either by hooking up the service with LDAP, or by creating a wrapper
 script that will manage those accesses.

 So the following needs to be done here:

  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
 new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
 retire-a-user], the various services to add/remove people to
  * [ ] automate the above with a script or LDAP

 Note that the two pages have different scope: `new-person` is about TSA
 while `retire-a-user` is broader. This should also be converged, probably
 in the broader sense.

 Also note that a particularly tricky situation is when we want to do a
 *partial* removal. For example, maybe the person needs to be removed from
 tor-internal, but keep access to some servers. Or removed from server, but
 keep an email alias.

 The latter case is especially sensitive: some people feel ke

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> while working on the nextcloud project, we realized it wasn't exactly
> trivial to setup the LDAP bridge because of our specific requirements (no
> direct connexion, offline support). so we just didn't implement it yet
> (#32332). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
> procedure, but then i realized there are probably many other such
> services that do *not* connect with LDAP.
>
> On the top of my head, there's at least Trac and mailing lists, for
> example, which are managed completely separarely. Audit
> [[org/operations/services]] and see which services are manager manually
> and which aren't.
>
> Then make sure there's an automated way to add/remove users to services,
> either by hooking up the service with LDAP, or by creating a wrapper
> script that will manage those accesses.
>
> So the following needs to be done here:
>
>  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
> new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
> retire-a-user], the various services to add/remove people to
>  * [ ] automate the above with a script or LDAP
>
> Note that the two pages have different scope: `new-person` is about TSA
> while `retire-a-user` is broader. This should also be converged, probably
> in the broader sense.
>
> Also note that a particularly tricky situation is when we want to do a
> *partial* removal. For example, maybe the person needs to be removed from
> tor-internal, but keep access to some servers. Or removed from server,
> but keep an email alias.
>
> The latter case is especially sensitive: some people feel keeping their
> email alias around forever is an inalienable right and that we should
> keep forwarding their email even after they are fully retired from Tor.
> This policy needs to be clarified, see #32558 for that particularly
> tricky problem.

New description:

 while working on the nextcloud project, we realized it wasn't exactly
 trivial to setup the LDAP bridge because of our specific requirements (no
 direct connexion, offline support). so we just didn't implement it yet
 (#32332). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
 procedure, but then i realized there are probably many other such services
 that do *not* connect with LDAP.

 On the top of my head, there's at least Trac and mailing lists, for
 example, which are managed completely separarely. Audit
 [[org/operations/services]] and see which services are manager manually
 and which aren't. Those services have been identified as particularly out
 of sync:

  * rt.torproject.org
  * blog.torproject.org
  * email, see also #32558
  * IRC, the @tor-tpomember group
  * Nagios contacts (almost cleaned up, but will still need checking for
 sysadmins arriving/departing)

 That list is not exhaustive.

 Then make sure there's an automated way to add/remove users to services,
 either by hooking up the service with LDAP, or by creating a wrapper
 script that will manage those accesses.

 So the following needs to be done here:

  * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
 new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
 retire-a-user], the various services to add/remove people to
  * [ ] automate the above with a script or LDAP

 Note that the two pages have different scope: `new-person` is about TSA
 while `retire-a-user` is broader. This should also be converged, probably
 in the broader sense.

 Also note that a particularly tricky situation is when we want to do a
 *partial* removal. For example, maybe the person needs to be removed from
 tor-internal, but keep access to some servers. Or removed from server, but
 keep an email alias.

 The latter case is especially sensitive: some people feel keeping their
 email alias around forever is an inalienable right and that we should keep
 forwarding their email even after they are fully retired from Tor. This
 policy needs to be clarified, see #32558 for that particularly tricky
 problem.

--

Comment (by anarcat):

 regroup the list of services in the description explicitely.

--
Ticket URL: 

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 rt.torproject.org is one of those services that has been suffering from
 neglect in this process as well.

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

[tor-bugs] #34036 [Internal Services/Services Admin Team]: audit access permissions in rt.torproject.org

[Tor Bug Tracker & Wiki]

#34036: audit access permissions in rt.torproject.org
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Services   |Version:
  Admin Team |
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 there are a lot of users in rt, some of which probably do not belong
 there:

 https://rt.torproject.org/Admin/Users/

 we need to perform an audit of who has access to RT, to which queue and
 clean all that up.

 ideally, users shouldn't be granted individual access to stuff and only be
 part of groups which, in turn, have the required accesses.

 users should also be added/removed properly as part of the
 onboarding/offboarding procedures, but that's a question for #32519. for
 now, this ticket is just about playing catchup.

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

Re: [tor-bugs] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  extra-review, prop313, ipv6, |  Actual Points:
  outreachy-ipv6, network-team-roadmap-2020Q1|
Parent ID:  #33052   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-
Changes (by teor):

 * keywords:  prop313, ipv6, outreachy-ipv6, network-team-roadmap-2020Q1 =>
 extra-review, prop313, ipv6, outreachy-ipv6, network-team-roadmap-
 2020Q1


Comment:

 Replying to [comment:33 MrSquanchee]:
 > Replying to [comment:32 teor]:
 > > We've been a bit busy for the past few weeks. I was also waiting for
 you to write more tests.
 >
 > I thought we were done with the tests. Can you please tell me what
 functions do you want to have
 > tests for ??

 We should test all the functions that have been modified. Sometimes we
 decide to do unit tests later, and open another ticket. Other times we ask
 for them as part of the PR, so we are sure that the new code works.

 We don't have good integration tests for this code, so unit tests are
 important.

 I'll leave it to the next reviewer to decide if we need more tests.

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

Re: [tor-bugs] #7193 [Core Tor/Tor]: Tor's sybil protection doesn't consider IPv6

[Tor Bug Tracker & Wiki]

#7193: Tor's sybil protection doesn't consider IPv6
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, intro, tor-dirauth, security,  |  Actual Points:
  sybil, network-health, outreachy-ipv6, |
  network-team-roadmap-2020Q1|
Parent ID:  #24403   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-can
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 I think this ticket needs review, I see a new PR here:
 https://github.com/torproject/tor/pull/1871

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

Re: [tor-bugs] #34002 [Circumvention/Snowflake]: Remove Snowflake interface, use *WebRTCPeer directly

[Tor Bug Tracker & Wiki]

#34002: Remove Snowflake interface, use *WebRTCPeer directly
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 Merged in [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=76732155e7d730573b3ced62209e4e1e4ead511c
 76732155e7d730573b3ced62209e4e1e4ead511c].

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

Re: [tor-bugs] #33997 [Circumvention/Snowflake]: Don't do a separate check for a short write

[Tor Bug Tracker & Wiki]

#33997: Don't do a separate check for a short write
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 Merged in [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=d9b076c32eed106a382a19bda973a9616cc44501
 d9b076c32eed106a382a19bda973a9616cc44501].

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

Re: [tor-bugs] #33995 [Circumvention/Snowflake]: Move pc.CreateOffer and pc.SetLocalDescription out of a goroutine

[Tor Bug Tracker & Wiki]

#33995: Move pc.CreateOffer and pc.SetLocalDescription out of a goroutine
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 Merged in [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=51bb49fa6f4ac7e01b19fd3136411a54a67a4ff6
 51bb49fa6f4ac7e01b19fd3136411a54a67a4ff6].

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

Re: [tor-bugs] #33835 [Circumvention/BridgeDB]: Gmail's quoted response confuses BridgeDB's email autoresponder

[Tor Bug Tracker & Wiki]

#33835: Gmail's quoted response confuses BridgeDB's email autoresponder
+---
 Reporter:  phw |  Owner:  agix
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o22a2   |  Actual Points:
Parent ID:  #31279  | Points:  1
 Reviewer:  |Sponsor:  Sponsor30-can
+---

Comment (by phw):

 For some reason I'm unable to comment on GitHub's "Files changed" view. Do
 you mind squashing your branch to a single commit? It will make it easier
 for me to comment on specific code lines.

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

Re: [tor-bugs] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop313, ipv6, outreachy-ipv6,   |  Actual Points:
  network-team-roadmap-2020Q1|
Parent ID:  #33052   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-

Comment (by MrSquanchee):

 PR https://github.com/torproject/tor/pull/1872
 Rebased with a cleaner git history.

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

Re: [tor-bugs] #34027 [Applications/GetTor]: GetTor not responding to emails

[Tor Bug Tracker & Wiki]

#34027: GetTor not responding to emails
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Never mind. I think this is fixed. I got confused because I saw the same
 few requests coming up every cycle. But I think someone has actually
 automated sending requests to GetTor for links for "windows is".

 Not sure if this is spam or intentional. In any case, it's just 3 requests
 every 5 seconds so maybe it's okay for now.

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

Re: [tor-bugs] #34027 [Applications/GetTor]: GetTor not responding to emails

[Tor Bug Tracker & Wiki]

#34027: GetTor not responding to emails
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * status:  needs_revision => 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] #34027 [Applications/GetTor]: GetTor not responding to emails

[Tor Bug Tracker & Wiki]

#34027: GetTor not responding to emails
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * status:  merge_ready => needs_revision


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

Re: [tor-bugs] #34027 [Applications/GetTor]: GetTor not responding to emails

[Tor Bug Tracker & Wiki]

#34027: GetTor not responding to emails
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cohosh):

 Merged and deployed. I've just noticed that it looks like we're still
 stuck. There's some links request that keep repeating without getting
 deleted from the database.

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

Re: [tor-bugs] #34035 [Applications/GetTor]: Dry out GetTor's sendmail function

[Tor Bug Tracker & Wiki]

#34035: Dry out GetTor's sendmail function
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  assigned => needs_review


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

[tor-bugs] #34035 [Applications/GetTor]: Dry out GetTor's sendmail function

[Tor Bug Tracker & Wiki]

#34035: Dry out GetTor's sendmail function
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This patch refactors the sendmail function in GetTor to avoid code
 duplication.

 https://gitlab.torproject.org/torproject/anti-censorship/gettor-
 project/gettor/-/merge_requests/6

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34034 [Internal Services/Service - lists]: Create anti-censorship-alerts list for service outage alerts

[Tor Bug Tracker & Wiki]

#34034: Create anti-censorship-alerts list for service outage alerts
---+-
 Reporter:  phw|  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Can you please create a new list, anti-censorship-alerts dot lists dot
 tpo, for the anti-censorship team? We will use this list for service
 alerts, i.e., Nagios, Prometheus, and other monitoring tools will send
 service outage alerts to the list.

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

Re: [tor-bugs] #32027 [Applications/Tor Browser]: Bump version of Go to 1.13+

[Tor Bug Tracker & Wiki]

#32027: Bump version of Go to 1.13+
-+-
 Reporter:  cohosh   |  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake, tbb-rbm,  |  Actual Points:
  ReleaseTrainMigration, GeorgKoppen202004,  |
  TorBrowserTeam202004R, tbb-9.5a12  |
Parent ID:  #31688   | Points:  2
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58
-+-
Changes (by sysrqb):

 * keywords:
 snowflake, tbb-rbm, ReleaseTrainMigration, GeorgKoppen202004,
 TorBrowserTeam202004R
 =>
 snowflake, tbb-rbm, ReleaseTrainMigration, GeorgKoppen202004,
 TorBrowserTeam202004R, tbb-9.5a12


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

Re: [tor-bugs] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---

Comment (by phw):

 Replying to [comment:7 anarcat]:
 > > Yes, let's do that!
 >
 > Sorry, could you clarify what you mean by that? list or alias? :) if
 it's a list, you need to create another ticket to get this going with the
 listmasters and loop back around here... which is why i'm asking.
 [[br]]
 I meant a list. I created #34034 for 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] #32027 [Applications/Tor Browser]: Bump version of Go to 1.13+

[Tor Bug Tracker & Wiki]

#32027: Bump version of Go to 1.13+
-+-
 Reporter:  cohosh   |  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake, tbb-rbm,  |  Actual Points:
  ReleaseTrainMigration, GeorgKoppen202004,  |
  TorBrowserTeam202004R  |
Parent ID:  #31688   | Points:  2
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58
-+-
Changes (by sysrqb):

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


Comment:

 Patch looks good to me. Merged to master with commit
 `30bdc472d4d2b222b9435c4a1c728ab74ff96365`.

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

Re: [tor-bugs] #32027 [Applications/Tor Browser]: Bump version of Go to 1.13+

[Tor Bug Tracker & Wiki]

#32027: Bump version of Go to 1.13+
-+-
 Reporter:  cohosh   |  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake, tbb-rbm,  |  Actual Points:
  ReleaseTrainMigration, GeorgKoppen202004,  |
  TorBrowserTeam202004R  |
Parent ID:  #31688   | Points:  2
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58
-+-

Comment (by sysrqb):

 And 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] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---

Comment (by anarcat):

 > Yes, let's do that!

 Sorry, could you clarify what you mean by that? list or alias? :) if it's
 a list, you need to create another ticket to get this going with the
 listmasters and loop back around here... which is why i'm asking.

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

Re: [tor-bugs] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---

Comment (by phw):

 Replying to [comment:5 anarcat]:
 > > There isn't but it may be a good opportunity to create one, if that's
 something that you can do easily. How about ​anti-censorship-service-
 alerts@tp.o?
 > the other contact we have like this right now is metrics-
 ale...@lists.torproject.org (notice the `lists.tpo` part), maybe we could
 do that just to have some coherence there? or is there already a mailing
 list we can use for this?
 [[br]]
 Yes, let's do that! We don't have an existing mailing list that would make
 for a good candidate. The closest is anti-censorship-team at lists dot tpo
 but I don't want to spam it with service alerts.

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

Re: [tor-bugs] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---

Comment (by anarcat):

 > There isn't but it may be a good opportunity to create one, if that's
 something that you can do easily. How about ​anti-censorship-service-
 alerts@tp.o?

 the other contact we have like this right now is metrics-
 ale...@lists.torproject.org (notice the `lists.tpo` part), maybe we could
 do that just to have some coherence there? or is there already a mailing
 list we can use for this?

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

Re: [tor-bugs] #33576 [Applications/Tor Browser]: Update pion-webrtc version to 2.2.3

[Tor Bug Tracker & Wiki]

#33576: Update pion-webrtc version to 2.2.3
--+
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake, TorBrowserTeam202004R  |  Actual Points:
Parent ID:| Points:
 Reviewer:  boklm |Sponsor:
--+
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 I rebased the branch. It's actually just one commit now:
 https://gitweb.torproject.org/user/cohosh/tor-browser-
 build.git/commit/?h=bug/0&id=8d7c51141c71923e0b62043a62f977c0254e679a

 I started a build to test it, I'll update here when it's done

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

Re: [tor-bugs] #33972 [Internal Services/Tor Sysadmin Team]: Add Nagios check for CollecTor

[Tor Bug Tracker & Wiki]

#33972: Add Nagios check for CollecTor
-+
 Reporter:  karsten  |  Owner:  phw
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by anarcat):

 >  Thanks for deploying the check! Can you change ​this line to contacts:
 +metrics, so that alerts don't go out just to me but to the metrics-
 alerts@ mailing list?

 Note that I set it up this way because you were marked as a contact for
 the hosts (corsicum and colchicifolium), should those be changed to
 metrics-alerts@ 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] #33948 [Applications/Tor Browser]: Setup a new nightly build machine

[Tor Bug Tracker & Wiki]

#33948: Setup a new nightly build machine
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 #33803 is related.

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

Re: [tor-bugs] #33803 [Applications/Tor Browser]: Generate a second mar signing key for nightly

[Tor Bug Tracker & Wiki]

#33803: Generate a second mar signing key for nightly
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Someone else from the team should be creating this second mar signing key,
 to migrate to it after #33948 is done.

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

Re: [tor-bugs] #33576 [Applications/Tor Browser]: Update pion-webrtc version to 2.2.3

[Tor Bug Tracker & Wiki]

#33576: Update pion-webrtc version to 2.2.3
--+
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake, TorBrowserTeam202004R  |  Actual Points:
Parent ID:| Points:
 Reviewer:  boklm |Sponsor:
--+
Changes (by cohosh):

 * status:  needs_review => needs_revision


Comment:

 Rebasing because of #33761

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

Re: [tor-bugs] #33952 [Applications/Tor Browser]: Document the process to update ssh keys and add/remove users from build-sunet-a.torproject.net

[Tor Bug Tracker & Wiki]

#33952: Document the process to update ssh keys and add/remove users from build-
sunet-a.torproject.net
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * status:  new => 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] #33952 [Applications/Tor Browser]: Document the process to update ssh keys and add/remove users from build-sunet-a.torproject.net

[Tor Bug Tracker & Wiki]

#33952: Document the process to update ssh keys and add/remove users from build-
sunet-a.torproject.net
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004R


Comment:

 There is a patch for review in branch `bug_33952`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_33952&id=409a0e2a9a27a79ae6b74f8b1816df2fe6bc8d8e

 I did not check that the instructions for removing users actually work.

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

Re: [tor-bugs] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---

Comment (by phw):

 Replying to [comment:3 anarcat]:
 > > Can Cecylia and I please get an email notification when the service
 goes offline?
 >
 > is there an alias that already exists which I should use instead? i
 don't think i have cecylia as a contact in nagios yet.
 [[br]]
 There isn't but it may be a good opportunity to create one, if that's
 something that you can do easily.  How about anti-censorship-service-
 alerts@tp.o?

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

Re: [tor-bugs] #30134 [Applications/Orbot]: reEnable IPv6 routing by Orbot add back Route to handle IPv6

[Tor Bug Tracker & Wiki]

#30134: reEnable IPv6 routing by Orbot add back Route to handle IPv6
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  Orbot IPv6  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by cypherpunks):

 both android vpnmode and bundled badvpn-tun2socks supports IPv6 just fine

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

[tor-bugs] #34033 [Applications/Orbot]: KBytes/s units labeled wrong as kpbs

[Tor Bug Tracker & Wiki]

#34033: KBytes/s units labeled wrong as kpbs
-+
 Reporter:  cypherpunks  |  Owner:  n8fr8
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Orbot
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
 In notification, it shows Bandwidth as kpbs in app itself it says
 Kbit/s but in reality it is traffic of unit KByte/s

 i confirmed with ntop that gives orbot bandwidth * 8
 (factor 8) difference

 ''may this is another reason why some people say tor is slow.''

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

Re: [tor-bugs] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---

Comment (by anarcat):

 > Can Cecylia and I please get an email notification when the service goes
 offline?

 is there an alias that already exists which I should use instead? i don't
 think i have cecylia as a contact in nagios 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] #8706 [Applications/Tor Browser]: .recently-used.xbel contains filenames if browser stored them to disk

[Tor Bug Tracker & Wiki]

#8706: .recently-used.xbel contains filenames if browser stored them to disk
-+-
 Reporter:  runa |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  backport-to-mozilla, tbb-disk-leak,  |  Actual Points:
  tbb-firefox-patch  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 >Storing file names in recently-used.xbel
 And here:
 {{{
 $ strings tor-browser_en-US/Browser/.local/share/gvfs-metadata/*
 }}}

 fix (use '''srm''' for secure wipe):
 {{{
 $ rm -r tor-browser_en-US/Browser/.local/share/
 $ ln -s /dev/null tor-browser_en-US/Browser/.local/share/
 }}}

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

Re: [tor-bugs] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---

Comment (by phw):

 Replying to [comment:1 anarcat]:
 > maybe i'm confused, but isn't this what we already have?
 [[br]]
 Oh, apparently.
 [[br]]
 > i did notice the service was down this weekend, but figured it was
 someone else's problem, to be honest. :)
 [[br]]
 Yes, it's the problem of the service operators. Can Cecylia and I please
 get an email notification when the service goes offline?

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

Re: [tor-bugs] #34032 [Applications/Tor Browser]: Use Securedrop's Official https-everywhere ruleset

[Tor Bug Tracker & Wiki]

#34032: Use Securedrop's Official https-everywhere ruleset
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-9.5a12|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * keywords:   => tbb-9.5a12


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34032 [Applications/Tor Browser]: Use Securedrop's Official https-everywhere ruleset

[Tor Bug Tracker & Wiki]

#34032: Use Securedrop's Official https-everywhere ruleset
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Let's create a fixup for #28005.

 Official ruleset is now: https://securedrop.org/https-everywhere/

 New signing key: https://github.com/freedomofpress/securedrop-https-
 everywhere-ruleset/blob/master/release-pubkey.jwk
 (also in footer of securedrop.org)

 The repository for storing the official HTTPS Everywhere ruleset channel
 is here:
 https://github.com/freedomofpress/securedrop-https-everywhere-ruleset

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

Re: [tor-bugs] #33698 [Applications/Tor Browser]: Update "About Tor Browser" links in Tor Browser

[Tor Bug Tracker & Wiki]

#33698: Update "About Tor Browser" links in Tor Browser
---+
 Reporter:  ggus   |  Owner:  mcs
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam202004R, tbb-9.5a12  |  Actual Points:
Parent ID: | Points:
 Reviewer:  acat   |Sponsor:
---+
Changes (by sysrqb):

 * status:  merge_ready => closed
 * keywords:  TorBrowserTeam202004R => TorBrowserTeam202004R, tbb-9.5a12
 * resolution:   => fixed
 * actualpoints:  0.15 =>


Comment:

 Merged commit `5a8128b566fab32fa2d97fe7a1a99e761afe77b0` onto `tor-
 browser-68.7.0esr-9.5-1`. 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] #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:  mcs
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update,TorBrowserTeam202004R  |  Actual Points:  1.7
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sysrqb):

 (It looks like tom had a similar idea in
 https://trac.torproject.org/projects/tor/ticket/29916#comment:1, too)

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

Re: [tor-bugs] #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:  mcs
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update,TorBrowserTeam202004R  |  Actual Points:  1.7
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sysrqb):

 Replying to [comment:13 mcs]:
 > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug32418-01&id=71c414d5edc5562a176e98fe3d037f0da6e51afc
 >
 > (both patches are on brade's bug32418-01 branch).

 Thanks! The patches look good to me, overall, and I'm fine with taking
 these patches as-is.

 Is there a reason for not using `MOZ_PROXY_BYPASS_PROTECTION` instead of
 defining a new `JSON_POLICIES_ONLY`? The latter is definitely more
 explicit about why it is defined, so I see some benefit for us in using
 `JSON_POLICIES_ONLY`, but I wonder if there is another reason as well.

 I agree Mozilla likely won't directly accept this patch, but that's okay.

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

Re: [tor-bugs] #12802 [Circumvention/BridgeDB]: BridgeDB needs Nagios checks for the Email Distributor

[Tor Bug Tracker & Wiki]

#12802: BridgeDB needs Nagios checks for the Email Distributor
-+-
 Reporter:  isis |  Owner:  phw
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-email, nagios, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #30152   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by phw):

 Replying to [comment:25 hiro]:
 > So when I made the check for bridgedb I was under the impression that it
 was managed via our infra to at least some extent. We don't have nagios in
 bridgedb as the machine is managed by you guys. So I guess we can either
 add nagios to bridgedb or add an email check to prometheus.
 > What would you prefer in this case?
 [[br]]
 I'm not sure what "managed by you guys" means. Cecylia and I administer
 the BridgeDB service but not the machine as a whole. We don't have root on
 polyanthum. Isn't this the same situation as with gettor-01? If so, I
 suggest installing nagios on polyanthum.

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

Re: [tor-bugs] #34031 [Metrics/Onionperf]: Figure out warning about unknown error type when exporting .tpf file

[Tor Bug Tracker & Wiki]

#34031: Figure out warning about unknown error type when exporting .tpf file
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.3
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Reproducing the warning with OnionPerf master should be as simple as:

 {{{
 onionperf analyze -t --tgen onionperf_2020-04-27_12\:59\:59.tgen.log.gz
 --torctl onionperf_2020-04-27_12\:59\:59.torctl.log.gz
 }}}

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

Re: [tor-bugs] #34031 [Metrics/Onionperf]: Figure out warning about unknown error type when exporting .tpf file

[Tor Bug Tracker & Wiki]

#34031: Figure out warning about unknown error type when exporting .tpf file
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.3
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * Attachment "onionperf_2020-04-27_12:59:59.torctl.log.gz" 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] #33082 [Internal Services/Tor Sysadmin Team]: decomission kvm3 AKA macrum, 7 VMs to migrate

[Tor Bug Tracker & Wiki]

#33082: decomission kvm3 AKA macrum, 7 VMs to migrate
-+-
 Reporter:  anarcat  |  Owner:  hiro
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-april|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Next step is wiping the disks.

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

Re: [tor-bugs] #34031 [Metrics/Onionperf]: Figure out warning about unknown error type when exporting .tpf file

[Tor Bug Tracker & Wiki]

#34031: Figure out warning about unknown error type when exporting .tpf file
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.3
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * Attachment "onionperf_2020-04-27_12:59:59.tgen.log.gz" 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] #34031 [Metrics/Onionperf]: Figure out warning about unknown error type when exporting .tpf file

[Tor Bug Tracker & Wiki]

#34031: Figure out warning about unknown error type when exporting .tpf file
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points:  0.3|   Reviewer:
  Sponsor: |
---+--
 I found this warning on an OnionPerf test instance:

 {{{
 2020-04-27 13:00:01 1587992401.168824 [onionperf] [INFO] saving analysis
 results to /home/cloud/onionperf-data/htdocs/op-nl2-51200-2020-04-27.tpf
 2020-04-27 13:00:01 1587992401.169561 [onionperf] [WARNING] KeyError while
 exporting torperf file, missing key ''PROXY_END_MISC'', skipping transfer
 'transfer50k:2'
 2020-04-27 13:00:01 1587992401.170384 [onionperf] [INFO] done!
 }}}

 I don't have time to look into this yet, but I'll attach log files to find
 out later.

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

Re: [tor-bugs] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  hiro
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february tpa-roadmap-|  Actual Points:
  march  |
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by phw):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:16 hiro]:
 > I am ok with this if people are happy with the result. I will add it to
 puppet.
 [[br]]
 The blackbox-target-availability plugin looks great and solves this
 problem. However, our default bridges aren't all down (only 146.57.248.225
 is, as of 2020-04-27), so there seems to be an error with the blackbox
 exporter?

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

Re: [tor-bugs] #34027 [Applications/GetTor]: GetTor not responding to emails

[Tor Bug Tracker & Wiki]

#34027: GetTor not responding to emails
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by phw):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me! I only had a nit that I left as comment in the MR.

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

Re: [tor-bugs] #34024 [Metrics/Onionperf]: Reduce timeout and stallout values

[Tor Bug Tracker & Wiki]

#34024: Reduce timeout and stallout values
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Ah, that makes sense. Thanks for the explanation!

 However, I'm going to deploy the three new OnionPerf instances without
 changing weights or timeouts and leave them running for a while to see
 whether results are different from currently running instances. If they
 are not, we'll learn that something in the setup was different, and it
 would be good to keep the number of changes as small as possible. Coming
 back to this in May. Thanks for all the great input so far!

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

Re: [tor-bugs] #34023 [Metrics/Onionperf]: Reduce the number of 50 KiB downloads

[Tor Bug Tracker & Wiki]

#34023: Reduce the number of 50 KiB downloads
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Even better plan: I'm going to deploy the three new OnionPerf instances
 without changing weights or timeouts and leave them running for a while to
 see whether results are different from currently running instances. If
 they are not, we'll learn that something in the setup was different, and
 it would be good to keep the number of changes as small as possible.
 Coming back to this in May. Thanks for all the great input so far!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34030 [Metrics/CollecTor]: Indexer ignores a file after moving it away and back shortly after

[Tor Bug Tracker & Wiki]

#34030: Indexer ignores a file after moving it away and back shortly after
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points:  0.5|   Reviewer:
  Sponsor: |
---+--
 Today I tried to trigger the new Nagios CollecTor check by moving away a
 recent Snowflake file and moving it back a few minutes later.

 The first part of moving the file away worked fine to the effect that it
 was not included in the `index.json` file anymore.

 However, the second part of moving the file back did not cause the indexer
 to include the file in the `index.json` file again.

 What I had to do was touch the file and setting a slightly different last-
 modified timestamp. More precisely, changing the second was not
 sufficient, but changing the minute was.

 I haven't looked at the code yet, but I could imagine that it's related to
 some optimization we did about not indexing files that we had already
 indexed before. Maybe it's also related to the way how we keep files
 available for a certain time after they dropped out of the `index.json`
 file. Or maybe it's caused by both.

 This is not a critical bug, but it's also likely not a complex fix. It
 would be good to fix this, because it would probably confuse another
 CollecTor operator who didn't happen to write the indexer 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] #33539 [Internal Services/Service - git]: retire gitlab-01

[Tor Bug Tracker & Wiki]

#33539: retire gitlab-01
-+--
 Reporter:  anarcat  |  Owner:  hiro
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gitlab,tpa-roadmap-april |  Actual Points:
Parent ID:  #32730   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 I have followed the procedure outlined on
 https://help.torproject.org/tsa/howto/retire-a-host/
 This host is now retired.
 Might just have to check the wiki and see if gitlab-01 is some where there
 still.

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

Re: [tor-bugs] #33539 [Internal Services/Service - git]: retire gitlab-01

[Tor Bug Tracker & Wiki]

#33539: retire gitlab-01
-+
 Reporter:  anarcat  |  Owner:  hiro
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  gitlab,tpa-roadmap-april |  Actual Points:
Parent ID:  #32730   | 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] #33082 [Internal Services/Tor Sysadmin Team]: decomission kvm3 AKA macrum, 7 VMs to migrate

[Tor Bug Tracker & Wiki]

#33082: decomission kvm3 AKA macrum, 7 VMs to migrate
-+-
 Reporter:  anarcat  |  Owner:  hiro
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-april|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 I have followed the retire-a-host procedure
 https://help.torproject.org/tsa/howto/retire-a-host/ up to point 13 in the
 list.
 We just need to remove it from the wiki and physically from hetzner.

 -hiro

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

Re: [tor-bugs] #12802 [Circumvention/BridgeDB]: BridgeDB needs Nagios checks for the Email Distributor

[Tor Bug Tracker & Wiki]

#12802: BridgeDB needs Nagios checks for the Email Distributor
-+-
 Reporter:  isis |  Owner:  phw
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-email, nagios, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #30152   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by hiro):

 Hi phw,
 So when I made the check for bridgedb I was under the impression that it
 was managed via our infra to at least some extent. We don't have nagios in
 bridgedb as the machine is managed by you guys. So I guess we can either
 add nagios to bridgedb or add an email check to prometheus.
 What would you prefer in this case?
 Apologies for this.

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

Re: [tor-bugs] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  hiro
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february tpa-roadmap-|  Actual Points:
  march  |
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 I am ok with this if people are happy with the result. I will add it to
 puppet.

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

Re: [tor-bugs] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Here's a comment from anarcat on #33972 to consider when working on this
 patch:

 > That's fine: the point is to make sure we check on a specific host
 instead of delegating this to DNS or whatever. Keep in mind this means you
 need to bypass DNS while still making HTTPS verification work! It's tricky
 stuff... But since you're already using `urlopen()`, it's possible you can
 implement such a hack.

 Also, once the script actually allows checking different CollecTor hosts,
 we can update the label from "global/collector" to "$hostname/collector"
 or similar.

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

Re: [tor-bugs] #33972 [Internal Services/Tor Sysadmin Team]: Add Nagios check for CollecTor

[Tor Bug Tracker & Wiki]

#33972: Add Nagios check for CollecTor
-+
 Reporter:  karsten  |  Owner:  phw
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Replying to [comment:11 anarcat]:
 > Replying to [comment:9 karsten]:
 > >  Yup, this worked. One thing I noticed is that the alert says
 "global/collector" whereas the Onionoo checks say things like
 "omeiense/network service - onionoo varnish". Is it possible to rename the
 CollecTor check to something like "colchicifolium/collector"?
 >
 > That would be confusing, at this stage: because we do not actually
 control which host we're probing, I prefer to keep the check "global"
 because that's effectively what it is. When we *can* specify the host,
 I'll update the label, if you don't mind.

 Okay, works for me.

 > Not sure which status to set here. I'll just reassign it to you, feel
 free to resolve. :)

 I had already opened #34029 for the remaining changes. I'll resolve this
 ticket and will open a new one once there's an updated script to deploy.

 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] #33907 [Internal Services/Tor Sysadmin Team]: new gnt-fsn node (fsn-node-06)

[Tor Bug Tracker & Wiki]

#33907: new gnt-fsn node (fsn-node-06)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-april|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 still no news from h. opened a ticket with them to see what's up.

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

Re: [tor-bugs] #33972 [Internal Services/Tor Sysadmin Team]: Add Nagios check for CollecTor

[Tor Bug Tracker & Wiki]

#33972: Add Nagios check for CollecTor
-+-
 Reporter:  karsten  |  Owner:  phw
 Type:  task | Status:
 |  assigned
 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 => assigned
 * owner:  anarcat => phw


Comment:

 Replying to [comment:9 karsten]:
 > Thanks for deploying the check! Can you change
 [https://gitweb.torproject.org/admin/tor-nagios.git/tree/config/nagios-
 master.cfg?id=9d70ee6ded7d0048a25242684b41541e010c424e#n1451 this line] to
 `contacts: +metrics`, so that alerts don't go out just to me but to the
 metrics-alerts@ mailing list?

 Of course, consider it done.

 > I'll move away a file on colchicifolium now to trigger the alert and
 back afterwards. Just to see if it's working.

 Definitely got that ring here. :)

 > I'll also look into the parameters and using argparse next week.

 Good.

 > Unfortunately, the check wouldn't work for corsicum right now anyway,
 because that CollecTor instance does not archive all descriptor types. It
 would just keep shouting about timestamps being missing.

 That's fine: the point is to make sure we check on a specific host instead
 of delegating this to DNS or whatever. Keep in mind this means you need to
 bypass DNS while still making HTTPS verification work! It's tricky
 stuff... But since you're already using `urlopen()`, it's possible you can
 implement such a hack.

 > Maybe we'll need to add another option to only complain about outdated
 timestamp, not about missing timestamps. Added to my list.

 No idea about that. ;)

 >  Yup, this worked. One thing I noticed is that the alert says
 "global/collector" whereas the Onionoo checks say things like
 "omeiense/network service - onionoo varnish". Is it possible to rename the
 CollecTor check to something like "colchicifolium/collector"?

 That would be confusing, at this stage: because we do not actually control
 which host we're probing, I prefer to keep the check "global" because
 that's effectively what it is. When we *can* specify the host, I'll update
 the label, if you don't mind.

 Not sure which status to set here. I'll just reassign it to you, feel free
 to resolve. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34029 [Metrics/CollecTor]: Add more command-line arguments to the Nagios CollecTor check script

[Tor Bug Tracker & Wiki]

#34029: Add more command-line arguments to the Nagios CollecTor check script
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Moved here from #33972:

 ''I'll also look into the parameters and using argparse next week.
 Unfortunately, the check wouldn't work for corsicum right now anyway,
 because that CollecTor instance does not archive all descriptor types. It
 would just keep shouting about timestamps being missing. Maybe we'll need
 to add another option to only complain about outdated timestamp, not about
 missing timestamps. Added to my list.''

 These are two changes:
  - add two separate host and IP parameters as suggested on the other
 ticket and
  - add another parameter for ignoring missing timestamps.

 None of these changes are critical, but making them sooner rather than
 later reduces the overhead for context switching.

 The check script is [https://gitweb.torproject.org/admin/tor-
 nagios.git/tree/tor-nagios-checks/checks/tor-check-collector 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] #33972 [Internal Services/Tor Sysadmin Team]: Add Nagios check for CollecTor

[Tor Bug Tracker & Wiki]

#33972: Add Nagios check for CollecTor
-+-
 Reporter:  karsten  |  Owner:  anarcat
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Replying to [comment:9 karsten]:
 > I'll move away a file on colchicifolium now to trigger the alert and
 back afterwards. Just to see if it's working.

 Yup, this worked. One thing I noticed is that the alert says
 "global/collector" whereas the Onionoo checks say things like
 "omeiense/network service - onionoo varnish". Is it possible to rename the
 CollecTor check to something like "colchicifolium/collector"?

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

Re: [tor-bugs] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+---
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+---
Changes (by anarcat):

 * status:  new => needs_information


Comment:

 maybe i'm confused, but isn't this what we already have?

 i did notice the service was down this weekend, but figured it was someone
 else's problem, to be honest. :)

 the check is here:

 https://nagios.torproject.org/cgi-
 
bin/icinga/extinfo.cgi?type=2&host=gettor-01&service=application+service+-+gettor+status

 it runs this command on the nagios server:

 {{{
 tor_check_nrpe!tor_application_service
 }}}

 That connects to gettor-01 (over "NRPE") and runs
 `tor_application_service`, which is opaque to me, but i think it's
 something hiro wrote to do exactly what you are proposing here.

 is it possible this was done on gettor and not on bridgedb?

 for what it's worth, here are the alerts i have in my backlog:

 {{{
 2020-04-22 03:51:14  tor-nagios: [gettor-01] application service -
 gettor status is WARNING: 1: No emails from gettor found
 2020-04-27 15:17:59  tor-nagios: [gettor-01] application service -
 gettor status is OK: 0: GetTor is good and sending emails with working
 links
 }}}

 maybe we should change the notified parties to make sure this falls on the
 right lap? :)

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

Re: [tor-bugs] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  hiro
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february tpa-roadmap-|  Actual Points:
  march  |
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  needs_information => needs_review


Comment:

 this is indeed a complex panel to create! i managed to make one using
 "singlestat" - I couldn't figure how to make the "alert list" thing work -
 but it's kind of clunky:

 https://grafana2.torproject.org/d/fC77Nk6Wz/blackbox-probe-state

 now after asking on #prometheus (freenode), i was told there's a Granafa
 plugin specifically for that purpose. it's really heavy on the Javascript,
 but it seems to actually work and provide a much better visualization.
 here's the dashboard I created with the plugin:

 https://grafana2.torproject.org/d/6shXNz6Wz/blackbox-target-availability

 the plugin is:

 https://grafana.com/grafana/plugins/flant-statusmap-panel/installation

 i installed it with:

 {{{
 sudo -u grafana grafana-cli plugins install flant-statusmap-panel
 service grafana-server stop
 service grafana-server start
 }}}

 ... which needs to be added into Puppet if we're happy with the results.

 let me know how that looks for you.

 (and yes, it does seem like all blackbox targets except bridges.tpo are
 down.)

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

Re: [tor-bugs] #33953 [Applications/Tor Browser]: Provide a way for easily updating Go dependencies of projects

[Tor Bug Tracker & Wiki]

#33953: Provide a way for easily updating Go dependencies of projects
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:4 gk]:
 > Replying to [comment:3 boklm]:
 > > Replying to [comment:2 cohosh]:
 > > > > 1) Use go mod vendor to vendor in the dependencies and then build
 with -mod=vendor to use the vendor folder with the dependencies.
 > > >
 > > > How would this work? Would we have to pull from a separate snowflake
 branch that has this vendor folder checked in? If we're going to pull all
 the dependencies at once, I'd rather do something like option (3), since
 it sounds like there's already a workflow present for something similar.
 Maintaining the vendor directory sounds tricky.
 > >
 > > I think this can be done by adding a `go_mod_vendor` step, which will
 use a container with network enabled and a snowflake source tarball (from
 the same git clone) to run `go mod vendor` and generate a tarball which
 will be used as `input_files` for the snowflake build.
 >
 > That's one approach, yes. I had more the option in mind to do it like we
 handle our Rust crates. One would update all the modules and then put them
 into a .tar.bz2 file somewhere which then gets used during the build. I
 don't like the idea of using just what `go mod vendor` gives us
 automatically for building for each build but it seems you have addressed
 that with your PoC. We'd have right now duplicated repos, though, due to
 #33988, right?

 That would be separate steps from the same project, so they would use the
 same git clone. #33988 is when different projects use the same repo.

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

Re: [tor-bugs] #34027 [Applications/GetTor]: GetTor not responding to emails

[Tor Bug Tracker & Wiki]

#34027: GetTor not responding to emails
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 Here's a merge request: https://gitlab.torproject.org/torproject/anti-
 censorship/gettor-project/gettor/-/merge_requests/5

 I already deployed this patch just to get the emails going through again
 and it looks like it's back to working as usual.

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

Re: [tor-bugs] #34026 [Applications]: Cannot change Background Color in Preferences

[Tor Bug Tracker & Wiki]

#34026: Cannot change Background Color in Preferences
---+
 Reporter:  Tinker |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications   |Version:
 Severity:  Normal | Resolution:
 Keywords:  firefox, background color  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by Tinker):

 I should add that the Color Override selection is set to Always.

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

Re: [tor-bugs] #33953 [Applications/Tor Browser]: Provide a way for easily updating Go dependencies of projects

[Tor Bug Tracker & Wiki]

#33953: Provide a way for easily updating Go dependencies of projects
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:3 boklm]:
 > Replying to [comment:2 cohosh]:
 > > > 1) Use go mod vendor to vendor in the dependencies and then build
 with -mod=vendor to use the vendor folder with the dependencies.
 > >
 > > How would this work? Would we have to pull from a separate snowflake
 branch that has this vendor folder checked in? If we're going to pull all
 the dependencies at once, I'd rather do something like option (3), since
 it sounds like there's already a workflow present for something similar.
 Maintaining the vendor directory sounds tricky.
 >
 > I think this can be done by adding a `go_mod_vendor` step, which will
 use a container with network enabled and a snowflake source tarball (from
 the same git clone) to run `go mod vendor` and generate a tarball which
 will be used as `input_files` for the snowflake build.

 That's one approach, yes. I had more the option in mind to do it like we
 handle our Rust crates. One would update all the modules and then put them
 into a .tar.bz2 file somewhere which then gets used during the build. I
 don't like the idea of using just what `go mod vendor` gives us
 automatically for building for each build but it seems you have addressed
 that with your PoC. We'd have right now duplicated repos, though, due to
 #33988, right?

 > I have not tested it, and it probably does not work yet, but I think
 this could look like this:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 
build.git/commit/?h=bug_33953_go_mod_vendor&id=5e7c5b88bc22548262744f7ec435210ebfaed221

 Okay, there is safeguarded with a sha256sum we calculate before using the
 whole input, that's good. I still feel a bit uneasy with doing build X
 while network access is allowed for building X. Because you should not
 need to have network access when building. :) But one maybe could see it
 more like fetching resources which we'd need to do anyway for building.

 Another thing that I feel the `go mod vendor` version does not give us is
 easy transparency regarding dependencies and what is used. You have,
 however we construct the fetching of dependencies, usually a .tar.xz blob
 and that's it while with the current setup (and boklm's improved one) it
 makes it easier to see the updated repo changes and spotcheck 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] #34025 [Applications/Orbot]: Orbot connects directly to raw.githubusercontent.com on startup

[Tor Bug Tracker & Wiki]

#34025: Orbot connects directly to raw.githubusercontent.com on startup
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by n8fr8):

 https://github.com/guardianproject/orbot/issues/323

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

Re: [tor-bugs] #34025 [Applications/Orbot]: Orbot connects directly to raw.githubusercontent.com on startup

[Tor Bug Tracker & Wiki]

#34025: Orbot connects directly to raw.githubusercontent.com on startup
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by n8fr8):

 It was only meant to run on devices without Google Play or F-Droid, i.e.
 users in China.

 Github was chosen for its accessibility in China.

 Will consider again how we implement this, and ensure it doesn't check in
 those cases. It should also have an option to disable.

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

Re: [tor-bugs] #33906 [Applications/Tor Launcher]: Fix Tor-Launcher issues for Firefox 75

[Tor Bug Tracker & Wiki]

#33906: Fix Tor-Launcher issues for Firefox 75
-+-
 Reporter:  acat |  Owner:  brade
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  0.95
  ReleaseTrainMigration,TorBrowserTeam202004R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-
Changes (by mcs):

 * actualpoints:   => 0.95


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

Re: [tor-bugs] #33698 [Applications/Tor Browser]: Update "About Tor Browser" links in Tor Browser

[Tor Bug Tracker & Wiki]

#33698: Update "About Tor Browser" links in Tor Browser
--+-
 Reporter:  ggus  |  Owner:  mcs
 Type:  task  | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:  0.15
Parent ID:| Points:
 Reviewer:  acat  |Sponsor:
--+-
Changes (by mcs):

 * actualpoints:   => 0.15


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  mcs
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update,TorBrowserTeam202004R  |  Actual Points:  1.7
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * actualpoints:  0.7 => 1.7


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34028 [Applications/GetTor]: Monitor GetTor's email autoresponder

[Tor Bug Tracker & Wiki]

#34028: Monitor GetTor's email autoresponder
-+
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:   |
-+
 The GetTor process occasionally dies without anyone noticing. See #34027
 for the latest incident. We should set up a script that periodically
 emails the autoresponder and raises an alert if it doesn't get a response.

 We already created
 [https://github.com/NullHypothesis/bridgedb/blob/enhancement/12802/scripts
 /nagios-email-check such a script] for BridgeDB as part of #12802. Here's
 how it works:
 0. We created a new Gmail address that's used by this script to email the
 autoresponder.
 1. Polyanthum (the host BridgeDB runs on) runs the script in a cron job
 every three hours.
 2. The script sends an email to brid...@torproject.org and, after waiting
 for a minute, checks for a response.
 3. Depending on if there's a response, the script writes a status code to
 disk, which is read by Nagios.
 4. Nagios should then alert us if the script's output says that BridgeDB's
 autoresponder is offline.

 It shouldn't be too hard to adapt BridgeDB's monitoring script for GetTor.
 In fact, to avoid code duplication, we should move this script into a
 separate repository and parameterise it, so it can work for both GetTor
 and BridgeDB.

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