Re: [tor-bugs] #28325 [Applications/Tor Browser]: Use go 1.11 module versioning support

[Tor Bug Tracker & Wiki]

#28325: Use go 1.11 module versioning support
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ReleaseTrainMigration,  |  Actual Points:
  TorBrowserTeam202004   |
Parent ID:  #33659   | Points:  3
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58
-+-

Comment (by cypherpunks):

 After upgrading to Go 1.14 only:
 "Module support in the go command is now ready for production use"

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

Re: [tor-bugs] #32804 [Core Tor/Tor]: Travis CI hangs during compile or test

[Tor Bug Tracker & Wiki]

#32804: Travis CI hangs during compile or test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-ci-fail-rarely, tor-test, hang,  |  Actual Points:
  tor-ci |
Parent ID:  #29645   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 Travis replied, they believe the issue is resolved on their end:
 > Hello Teor,
 >
 > Thanks for your patience on this issue and sorry for the delayed
 response.
 >
 > The errors were due to a temporary glitch in our Mac infrastructure that
 let errors go undetected. We have identified areas of our systems that
 require additional monitoring to assist us be more proactive in
 identifying and resolving these kind of errors. Sorry about this please.
 >
 > We observed your builds are fine now. Please let us know if you run into
 any more issues.
 >
 > Thanks and happy building!

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

Re: [tor-bugs] #22668 [Core Tor/Tor]: Add ed25519 public key to format_node_description and callers

[Tor Bug Tracker & Wiki]

#22668: Add ed25519 public key to format_node_description and callers
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-log, tor-ed25519,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:6 wulder]:
 > I will begin work on this. Seems like a nice ticket to get me started.

 Thanks! We normally print ed25519 keys in base64.

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

Re: [tor-bugs] #33898 [Core Tor/Tor]: Stop modifying addr on connections, and delete real_addr

[Tor Bug Tracker & Wiki]

#33898: Stop modifying addr on connections, and delete real_addr
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, technical-debt, prop311  |  Actual Points:
Parent ID:  #33048 | Points:  1
 Reviewer: |Sponsor:  Sponsor55-can
---+---

Comment (by teor):

 In #33899, nickm says:
 > I'm inclined to rename node_ap in connection_or_check_canonicity to
 something like canonical_ap, but that can wait till #33898.

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

Re: [tor-bugs] #33920 [Core Tor/Chutney]: Remove errors or typos from TorNet.py and Templating.py

[Tor Bug Tracker & Wiki]

#33920: Remove errors or typos from TorNet.py and Templating.py
--+-
 Reporter:  MrSquanchee   |  Owner:  MrSquanchee
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:  easy, outreachy-ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+-

Comment (by teor):

 I opened #33957 to follow up the bufsize error.

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

Re: [tor-bugs] #33957 [Core Tor/Chutney]: Unexpected keyword argument 'bufsize' in subprocess.check_output()

[Tor Bug Tracker & Wiki]

#33957: Unexpected keyword argument 'bufsize' in subprocess.check_output()
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop311, prop312  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-can
--+---
Changes (by teor):

 * keywords:   => prop311, prop312
 * sponsor:   => Sponsor55-can


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

[tor-bugs] #33957 [Core Tor/Chutney]: Unexpected keyword argument 'bufsize' in subprocess.check_output()

[Tor Bug Tracker & Wiki]

#33957: Unexpected keyword argument 'bufsize' in subprocess.check_output()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 On some python versions, chutney's call to subprocess.check_output()
 results in the following error:
 {{{
 Unexpected keyword argument 'bufsize'…
 }}}
 https://github.com/torproject/chutney/pull/68#issuecomment-614596946

 The check_output() documentation is unclear about which arguments are
 supported: it simply says that most arguments to Popen() are supported.
 (And bufsize is an argument to Popen().):
 https://docs.python.org/3.5/library/subprocess.html#subprocess.check_output
 https://docs.python.org/3.5/library/subprocess.html#subprocess.Popen

 I think our best option here is to remove the bufsize argument, and accept
 the default buffered behaviour.

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

Re: [tor-bugs] #33918 [Core Tor/Tor]: Stop truncating IPv6 addresses in channel logs

[Tor Bug Tracker & Wiki]

#33918: Stop truncating IPv6 addresses in channel logs
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.4-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, prop311, prop312,  |  Actual Points:  0.1
  043-backport   |
Parent ID:  #33050   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
 |  Sponsor55-must
-+-

Comment (by teor):

 Replying to [comment:3 teor]:
 > Replying to [comment:2 nickm]:
 >
 > > Also do you think it's worth defining a new TOR_ADDRPORT_BUF_LEN?
 >
 > In new code, yes. Let's do that in master in a separate ticket.

 I opened #33956 for this follow-up refactor.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33956 [Core Tor/Tor]: Define and use TOR_ADDRPORT_BUF_LEN

[Tor Bug Tracker & Wiki]

#33956: Define and use TOR_ADDRPORT_BUF_LEN
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  refactor, technical-debt, prop311,
 Severity:  Normal   |  prop312, prop313
Actual Points:   |  Parent ID:
   Points:  0.5  |   Reviewer:
  Sponsor:   |
  Sponsor55-can  |
-+-
 In #33918, we discovered a bug where IPv6 addresses were being truncated
 in logs.

 During the fix, we noticed that we had a TOR_ADDR_BUF_LEN, but no
 equivalent constant for addresses and ports. The new TOR_ADDRPORT_BUF_LEN
 should allow space for:
 * TOR_ADDR_BUF_LEN
 * IPv6 brackets (2, if not included in TOR_ADDR_BUF_LEN already)
 * the port separator (1)
 * the port (5)

 We should check for other truncation errors while making this change.

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

Re: [tor-bugs] #24839 [Core Tor/Tor]: Add a torrc option and descriptor line to opt-in as a FallbackDir

[Tor Bug Tracker & Wiki]

#24839: Add a torrc option and descriptor line to opt-in as a FallbackDir
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, fallback, tor-spec,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328, |
  teor-backlog, network-team-roadmap-2020Q1  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Old description:

> This needs:
> * a proposal and a design
> * a patch to dir-spec.txt
> * a patch to the tor man page
> * a tor code patch
> * an updateFallbackDirs.py code patch
> * a wiki update to [[doc/UpdatingFallbackDirectoryMirrors]]
>
> Here's a quick sketch of a design:
>
> 1. Relay operators set `OfferFallbackDirServer 1` to offer their relay as
> a potential FallbackDir.
> 2. Relays with this option set put `offer-fallback-dir-server` in their
> descriptors
> 3. updateFallbackDirs.py loads relay fingerprints with `offer-fallback-
> dir-server`, and from the legacy whitelist (#24838 will make this easier)
> 4. updateFallbackDirs.py applies the blacklist, does stability checks,
> and generates the fallback list

New description:

 This needs:
 * a proposal and a design
 * a patch to dir-spec.txt
 * a patch to the tor man page
 * a tor code patch
 * an updateFallbackDirs.py code patch
 * a wiki update to [[doc/UpdatingFallbackDirectoryMirrors]]

 Here's a quick sketch of a design:

 1. Relay operators set `OfferFallbackDir 1` to offer their relay as a
 potential FallbackDir.
 2. Relays with this option set put `offer-fallback-dir` in their
 descriptors
 3. updateFallbackDirs.py loads relay fingerprints with `offer-fallback-
 dir`, and from the legacy offer list
 4. updateFallbackDirs.py does stability checks, and generates the fallback
 list

--

Comment (by teor):

 Update description, make option shorter.

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

Re: [tor-bugs] #30972 [Core Tor/Fallback Scripts]: 0-1. Run an opt-in process for relay operators to become fallbacks in 2019-2020

[Tor Bug Tracker & Wiki]

#30972: 0-1. Run an opt-in process for relay operators to become fallbacks in
2019-2020
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #30971 | Points:  1
 Reviewer: |Sponsor:
---+

Comment (by teor):

 An operator asked us to remove their relay "parasol":
 37.252.185.182
 
​https://metrics.torproject.org/rs.html#details/113143469021882C3A4B82F084F8125B08EE471E

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

Re: [tor-bugs] #32882 [Core Tor/Fallback Scripts]: remove parasol from fallbackdir list

[Tor Bug Tracker & Wiki]

#32882: remove parasol from fallbackdir list
---+
 Reporter:  a_p|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #30972 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * parent:   => #30972


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

Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 also, on linux jitsi eats CPU like crazy, apparently because it doesn't do
 hardware acceleration. this reddit thread has some more information:

 
https://old.reddit.com/r/linux/comments/fxcyyw/jitsi_meet_features_update_april_2020/

 important quotes:

 > I've noticed high cpu usage on Linux side due to no hardware
 acceleration. Haven't noticed it in the windows side
 >
 > Chrome and Firefox don't have hardware acceleration in Linux unless you
 are running a patched version of chromium with va-api added.
 >
 > It was supposed to be enabled in Firefox 75 when using Wayland.
 >
 > To see if things would be hardware accelerated you could play a YouTube
 video 4k and see how the CPU is spking vs gpu

 > that's correct but slightly misleading. In order to get WebRTC VAAPI
 decoding support on Linux the upstream WebRTC project code would need to
 support it.
 >
 > The VAAPI work on Chromium and Firefox regarding videos is separate.
 AFAIK, no upstream support looks like it will be added soon.

 Firefox particularly has problems working with Jitsi and WebRTC because of
 missing features.

 They (Jitsi) did improve their support for non-chrome browser, apparently:

 https://github.com/jitsi/jitsi-meet/issues/4758#issuecomment-614063335

 Jitsi are also working on E2E encryption but that requires "insertable
 streams":

 https://bugzilla.mozilla.org/show_bug.cgi?id=1631263

 In general, here are the issues tagged with jitsi in the firefox
 bugtracker:

 
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring_whiteboard
 =jitsi-meet

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

Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

[Tor Bug Tracker & Wiki]

#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 another interesting review

 https://tech.firstlook.media/how-to-pick-a-video-conferencing-platform

 of the free platforms we considered, they only reviewed jitsi, the others
 are Duo, Facetime, Hangouts, Jami, Keybase, Signal, Vidyo, Webex, and
 Zoom.

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

Re: [tor-bugs] #33955 [Applications/Tor Browser]: Selecting "Copy image" from menu leaks the source URL to the clipboard. This data is often dereferenced by other applications.

[Tor Bug Tracker & Wiki]

#33955: Selecting "Copy image" from menu leaks the source URL to the clipboard.
This data is often dereferenced by other applications.
-+-
 Reporter:  peskydan |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  information leak, unexpected,|  Actual Points:
  Firefox|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by peskydan):

 On reflection, including the alt text in the tag generated by "Copy image
 as HTML" is probably a bad idea, since it might not be expected or noticed
 by the user, and could potentially expose harmful information.

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

Re: [tor-bugs] #33955 [Applications/Tor Browser]: Selecting "Copy image" from menu leaks the source URL to the clipboard. This data is often dereferenced by other applications.

[Tor Bug Tracker & Wiki]

#33955: Selecting "Copy image" from menu leaks the source URL to the clipboard.
This data is often dereferenced by other applications.
-+-
 Reporter:  peskydan |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  information leak, unexpected,|  Actual Points:
  Firefox|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by peskydan):

 For reference, this bug has seen some discussion on the following Reddit
 thread:
 
https://www.reddit.com/r/TOR/comments/g4lhrj/serious_privacy_issue_with_image_context_menu/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33955 [Applications/Tor Browser]: Selecting "Copy image" from menu leaks the source URL to the clipboard. This data is often dereferenced by other applications.

[Tor Bug Tracker & Wiki]

#33955: Selecting "Copy image" from menu leaks the source URL to the clipboard.
This data is often dereferenced by other applications.
-+-
 Reporter:  peskydan |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Component:  Applications/Tor
 |  Browser
  Version:   |   Severity:  Major
 Keywords:  information leak,|  Actual Points:
  unexpected, Firefox|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Right-clicking an image and selecting "Copy image" from the context-menu
 leaks the source URL to the clipboard. In many applications, pasting the
 image leads to the URL being dereferenced, and a clearnet web request can
 result, instead of the bitmap simply being pasted. This is dangerous and
 unexpected behaviour that stems from Firefox.

 11 formats are placed on the clipboard during an image copy. 3 of these
 contain the URL, 2 of which contain further tag metadata:

 49318 'HTML Format' - this contains the entire source HTML of the
  element, inside a comment, wrapped in a minimal HTML document, and a
 header containing the offsets

 49419 'text/html' - this also contains the source HTML of the 
 element

 49426 'application/x-moz-file-promise-url' - this contains the plain
 source URL.

 While some might argue that this is appropriate in Firefox, it's an
 unexpected information leak in the Tor Browser.

 My suggestion would be to change the menu items to:

 - Copy image
 - Copy image location
 - Copy image as HTML

 **Copy image** would copy only raw image pixels as an uncompressed bitmap.
 This ensures there is no metadata in the image, and also ensures that
 increasingly common things like WebP don't break everything. It also fixes
 unexpected behaviour with respect to dynamically generated or uncached
 images, ensuring that what the user sees is exactly what ends up in the
 clipboard, without any extra web requests in the target application.

 **Copy image location** would copy, in plaintext, the source URL of the
 image.

 **Copy image as HTML** would copy or create a sanitised version of the
  tag (i.e. onclick handlers etc would be stripped, leaving only alt
 text, width and height and perhaps eventually a filtered version of any
 embedded CSS).

 I believe each of those menu options would behave as everyone would
 expect, without any unexpected information leakage issues.

 (I have set severity as major and priority high, since this has the
 potential to deanonymise a user before they realise what's happened, but
 is probably a relatively easy fix. Presumably this would be regarded as
 the most important kind of bug, but I don't know the convention 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] #33951 [Internal Services/Service - cache]: mtail floods its logs with garbage

[Tor Bug Tracker & Wiki]

#33951: mtail floods its logs with garbage
---+--
 Reporter:  anarcat|  Owner:  anarcat
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - cache  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by anarcat):

 i managed to update the debian package to latest, fix the FTBFS and
 uploaded to unstable. we'll see how this goes with the buildds.

 the package also compiles fine on buster so it should be easy to backport.
 i built one on my office machine and i'll see if i can test it tomorrow.

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

Re: [tor-bugs] #31528 [Circumvention/BridgeDB]: Get rid of BridgeDB's "chatspeak"

[Tor Bug Tracker & Wiki]

#31528: Get rid of BridgeDB's "chatspeak"
+
 Reporter:  phw |  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by phw):

 * status:  needs_review => needs_revision


Comment:

 Can you please make available a branch (based off of BridgeDB's develop
 branch) which contains your code?

 You can discard 0004-Removed-or-replaced-all-chatspeak-like-strings-in-
 st.patch because we took care of these issues over at #30941.

 Regarding 0003-Changed-redirection-to-a-classic.patch: Instead of
 redirecting to a video, I prefer to return an HTTP error code. Code 400 or
 406 seem reasonable.

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

Re: [tor-bugs] #33951 [Internal Services/Service - cache]: mtail floods its logs with garbage

[Tor Bug Tracker & Wiki]

#33951: mtail floods its logs with garbage
---+--
 Reporter:  anarcat|  Owner:  anarcat
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - cache  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by anarcat):

 for now i have removed the mtail.log logfile on both caching servers, as a
 stopgap  measure, which should silence nagios for a while.

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

Comment (by maurice_pibouin):

 Thank you for the review !

  * I'm not sure what you mean by new patch : a different PR, branch,
 issue, or just new commits ?

  * I didn't do a PR because I thought it was reserved to "finished"
 patches (ie that include tests), I will use a PR next time
  * Comment removal was a mistake
  * I didn't see anything in `CodingStandards.md` about the if-else
 newline, is it just common good practice ?

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

Re: [tor-bugs] #33951 [Internal Services/Service - cache]: mtail floods its logs with garbage

[Tor Bug Tracker & Wiki]

#33951: mtail floods its logs with garbage
---+--
 Reporter:  anarcat|  Owner:  anarcat
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - cache  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by anarcat):

 there's no backport of the newer version because it FTBFS in sid:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952333
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918526

 i wonder if those could be fixed by upgrading the package to latest
 upstream. so i filed a bug against debian for the old version to propose
 to update it:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958417

 i have started work on updating the package in sid to see if that still
 works at least, and will see about doing a backport if it passes testing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_revision
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o22a2   |  Actual Points:
Parent ID:  #31279  | Points:  1
 Reviewer:  |Sponsor:  Sponsor30-can
+
Changes (by phw):

 * status:  needs_review => needs_revision


Comment:

 With "push your patch to GitHub," I meant pushing the commits that your
 patch is based on.

 That said, here's some feedback:

 * Overall, the `get_payload()` approach seems reasonable. Nicely done!

 * Make sure that your code is based on the develop and not on the master
 branch. For BridgeDB, we're using [https://nvie.com/posts/a-successful-
 git-branching-model/ a development model] in which patches branch off of
 develop rather than master.

 * I'm not sure why the patch deletes `TRANSPORT_PATTERN` and
 `UNBLOCKED_PATTERN`, and replaces them with a TODO item?

 * The patch's commit message should provide a short summary of how the
 patch accomplishes its goal. [https://git-scm.com/book/en/v2/Distributed-
 Git-Contributing-to-a-Project#Commit-Guidelines Here's a summary] of how
 to write good commit messages.

 * We should add unit tests to make sure that the patch correctly deals
 with emails of different content types.

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

Re: [tor-bugs] #28325 [Applications/Tor Browser]: Use go 1.11 module versioning support

[Tor Bug Tracker & Wiki]

#28325: Use go 1.11 module versioning support
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ReleaseTrainMigration,  |  Actual Points:
  TorBrowserTeam202004   |
Parent ID:  #33659   | Points:  3
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58
-+-

Comment (by gk):

 Okay, just for the dependency update I created #33953 to disentangle some
 pieces that got move into this ticket, 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

[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|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #28325 we are working on enabling `go.mod` support for our Go based
 projects. While that will be an improvement in that we don't need to work
 around a new default anymore, it does not solve the question how we can
 easily update all the dependencies of a project and the dependencies of
 those dependencies. That's the scope for this ticket. Besides #28325 we
 should keep in mind that we might want to think about how we want to
 handle go modules in the future. Right now, we have a project per module
 in `tor-browser-build`. Maybe that's not a smart thing with the growing
 amount of projects we have. Either way, the solution for this ticket will
 have an impact on that, so we should take the question about how to handle
 the module-project relationship into account.

 For the dependency update path forward we a bunch of possible options,
 some already mentioned in #28325 (in no particular order):

 1) Use `go mod vendor` to vendor in the dependencies and then build with
 `-mod=vendor` to use the `vendor` folder with the dependencies.

 2) Refine the `gomodtorbm` script written by dcf/cohosh (see: #28942 and
 #33576)

 3) Use `go mod download` to fetch dependencies into the cache and then
 point, during the build, with `GOPROXY` to the cached files (that's
 feeling similar to what we use for our Gradle dependencies right now).

 There might be more than those three.

 boklm had a nice idea of restructuring our go projects in a way that we'd
 only have one `go-module` project and we could list all needed
 dependencies directly in the respective project under `input_files` (see:
 comment:42:ticket:28942). That might be orthogonal to 1) and 3) but might
 actually help with 2). not sure.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33954 [Applications/Tor Browser]: Consider different approach for "2176: Rebrand Firefox to TorBrowser "

[Tor Bug Tracker & Wiki]

#33954: Consider different approach for "2176: Rebrand Firefox to TorBrowser "
-+-
 Reporter:  acat |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ReleaseTrainMigration,
 Severity:  Normal   |  TorBrowserTeam202004
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:  Sponsor58|
-+-
 The current patch replaces all occurrences of `branding/brand.ftl` with
 `branding/tor-browser-brand.ftl`. This means that many files are touched
 by the patch (increasing chances of rebase conflict), and whenever Firefox
 adds new instances of `branding/brand.ftl` we need to modify the patch to
 also cover those.

 I think we should try a different approach to keep all instances of
 `branding/brand.ftl` untouched, and do the `branding/brand.ftl` ->
 `branding/tor-browser-brand.ftl` remapping somewhere else, and just in a
 single place.

 One way would be to force the Fluent `FileSource` that we register in
 torbutton to take precedence over any other source and rename `tor-
 browser-brand.ftl` to `brand.ftl`, to override Firefox one (including
 langpacks).

 We probably would need to do this in [https://searchfox.org/mozilla-
 
central/rev/3446310d6cc5c85cde16a82eccf560e9b71a3d44/intl/l10n/L10nRegistry.jsm#141
 L10nRegistry.js], but I would need to investigate a bit more.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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|   Keywords:
  |  TorBrowserTeam202004
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should document the process to update ssh keys and add/remove users
 from build-sunet-a.torproject.net. Probably in `tools/ansible/README` in
 `tor-browser-build`.

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

 * status:  assigned => needs_review
 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004R


Comment:

 Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug33698-01=5a8128b566fab32fa2d97fe7a1a99e761afe77b0

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33951 [Internal Services/Service - cache]: mtail floods its logs with garbage

[Tor Bug Tracker & Wiki]

#33951: mtail floods its logs with garbage
---+--
 Reporter:  anarcat|  Owner:  anarcat
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - cache  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 we seen ton of this garbage in the mtail logs:

 {{{
 I0421 18:43:02.307808   21142 file.go:168] file type does not support
 deadline
 }}}

 there's a lot to unpack here:

  * weird log format: the first word is `IMMDD`, that is the above message
 is from April 21st (the I is for "Irrelevant character", i guess?)
  * 21142 is the pid
  * `file type does not support deadline` is an error from the golang
 standard library and occurs when someone calls `SetReadDeadline` on a file
 that doesn't support it

 This happens every minute or so. It gathers about a gigabyte of logs a
 month or two.

 In later versions of mtail, this is fixed by making turning the "warning"
 (technically, it's an "Info" message, but those are displayed
 unconditionnally) into a "verbose" (technically `V(2)`) message that
 doesn't get shown by default.

 The package from buster doesn't have that fix, but the current version in
 unstable (rc24) does have it.

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

Re: [tor-bugs] #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:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:  acat  |Sponsor:
--+--
Changes (by mcs):

 * cc: tbb-team (added)
 * reviewer:   => acat
 * status:  new => assigned
 * owner:  tbb-team => mcs
 * keywords:   => TorBrowserTeam202004


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

Re: [tor-bugs] #32674 [Applications/Tor Browser]: Change link on 'Get involved' in about:tor to new community portal

[Tor Bug Tracker & Wiki]

#32674: Change link on 'Get involved' in about:tor to new community portal
--+--
 Reporter:  emmapeel  |  Owner:  mcs
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  community, TorBrowserTeam201912R  |  Actual Points:  0.15
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

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


Comment:

 #33671 is a duplicate. I am reopening this ticket so we remember to merge
 this change into Tor Browser stable. Alternatively, we could wait for Tor
 Browser 9.5, although this change is fairly low risk and we have had it on
 alpha for a while.

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

Re: [tor-bugs] #33671 [Applications/Tor Browser]: Update "Get Involved" url in about:tor

[Tor Bug Tracker & Wiki]

#33671: Update "Get Involved" url in about:tor
--+---
 Reporter:  ggus  |  Owner:  mcs
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  acat  |Sponsor:
--+---
Changes (by mcs):

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


Comment:

 This is a duplicate of #32674. I think the problem is that the changes
 made there made it to Tor Browser alpha but not to release.

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

Re: [tor-bugs] #33890 [Applications/Tor Browser]: Rename .xul to .xhtml

[Tor Bug Tracker & Wiki]

#33890: Rename .xul to .xhtml
--+-
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:  0.1
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:
--+-
Changes (by mcs):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:3 acat]:
 > Thanks, revised in
 >
 >
 
https://github.com/acatarineu/torbutton/commit/3541943d842162641100741cb6b08cb45058038f
 >
 > and
 >
 > https://github.com/acatarineu/tor-
 launcher/commit/de405aee1a4e5c848905b9f52bccc2764cdbb8c7

 r=brade,r=mcs
 Looks good. Thanks for making the changes we requested.

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

Re: [tor-bugs] #33892 [Applications/Tor Browser]: Add brandProductName to torbutton brand localization files

[Tor Bug Tracker & Wiki]

#33892: Add brandProductName to torbutton brand localization files
--+-
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:  0.75
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:
--+-
Changes (by mcs):

 * status:  needs_review => merge_ready


Comment:

 r=brade,r=mcs
 These changes look good to Kathy and me, including the additions to
 `import-translations.sh` to generate the `tor-browser-brand.ftl` file. We
 will leave it to sysrqb or gk to decide if they want a separate ticket for
 that part.

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

Re: [tor-bugs] #31918 [Applications/Tor Browser]: Rebase and squash mobile and desktop patches (was: Rebase and squash mobile/android patches into desktop)

[Tor Bug Tracker & Wiki]

#31918: Rebase and squash mobile and desktop patches
-+-
 Reporter:  sysrqb   |  Owner:  acat
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.5, ReleaseTrainMigration,  |  Actual Points:
  TorBrowserTeam202004R  |
Parent ID:  #33656   | Points:  1
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58
-+-

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

Re: [tor-bugs] #33131 [Core Tor/Tor]: Bug: buf->datalen >= 0x7fffffff

[Tor Bug Tracker & Wiki]

#33131: Bug: buf->datalen >= 0x7fff
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => merge_ready
 * cc: 043-backport (added)


Comment:

 Looks good.  I think we should take this in master.  We should consider a
 backport, though I'm on the fence about 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] #31918 [Applications/Tor Browser]: Rebase and squash mobile/android patches into desktop

[Tor Bug Tracker & Wiki]

#31918: Rebase and squash mobile/android patches into desktop
-+-
 Reporter:  sysrqb   |  Owner:  acat
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.5, ReleaseTrainMigration,  |  Actual Points:
  TorBrowserTeam202004R  |
Parent ID:  #33656   | Points:  1
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58
-+-
Changes (by acat):

 * keywords:  tbb-9.5, ReleaseTrainMigration, TorBrowserTeam202004 =>
 tbb-9.5, ReleaseTrainMigration, TorBrowserTeam202004R
 * status:  assigned => needs_review


Comment:

 I'm using this one to also squash some of the desktop patches, not only
 mobile -> desktop. I used the 33533+4 branch, and the resulting rebased
 patches are in ​https://github.com/acatarineu/tor-browser/commits/31918.

 I squashed some commits with the mozconfigs one which are not strictly
 mozconfigs, but I think they could all belong to the same category,
 something like "build-time options that we set or unset". And if we do
 #23656 then all the changes in this patch would be effective for tor-
 browser-builds.

 Here is the list of changes from 33533+4 to 31918:

 {{{
 Bug 25741 - TBA: Add mobile-override of 000-tor-browser prefs
   squash! TB4: Tor Browser's Firefox preference overrides.

 Bug 25741 - TBA: Add an AppConstant for TOR_BROWSER_VERSION
   fixup! Bug 4234: Use the Firefox Update Process for Tor Browser.

 Bug 25741 - TBA: Add default configure options in dedicated file
   squash! TB3: Tor Browser's official .mozconfigs.

 Bug 25741 - TBA: Disable features at compile-time
   squash! TB3: Tor Browser's official .mozconfigs.

 Bug 32493: Disable MOZ_SERVICES_HEALTHREPORT
   squash! TB3: Tor Browser's official .mozconfigs.

 Bug 31658: Changed the 'SECURITY LEVEL' text color to builtin --panel-
 disabled-color
   fixup! Bug 25658: Replace security slider with security level UI

 Bug 32188: Change useLocalProxy string to tor-launcher's torsettings
 useProxy.checkbox in TorStrings.jsm
   fixup! Bug 31286: Implementation of bridge, proxy, and firewall settings
 in about:preferences#tor

 Bug 31803: Replaced about:debugging logo with flat version
   squash! Bug 2176: Rebrand Firefox to TorBrowser

 Bug 32111: Fixed issue parsing user-provided brige strings
   fixup! Bug 31286: Implementation of bridge, proxy, and firewall settings
 in about:preferences#tor

 Bug 31749: Fix security level panel spawning events
   fixup! Bug 25658: Replace security slider with security level UI

 Bug 31920: Fix Security Level panel when its toolbar button moves to
 overflow
   fixup! Bug 25658: Replace security slider with security level UI

 Bug 31748: Fixed 'Learn More' links in Security Level preferences and
 panel
   fixup! Bug 25658: Replace security slider with security level UI

 Bug 31935: Disable profile downgrade protection.
   squash! TB3: Tor Browser's official .mozconfigs.

 Bug 28196: preparations for using torbutton tor-browser-brand.ftl
   squash! Bug 2176: Rebrand Firefox to TorBrowser

 Bug 24653: merge securityLevel.properties into torbutton.dtd
   fixup! Bug 25658: Replace security slider with security level UI

 Bug 31457: disable per-installation profiles
   squash! TB3: Tor Browser's official .mozconfigs.

 Bug 31251: Security Level button UI polish
   fixup! Bug 25658: Replace security slider with security level UI

 Bug 30631: Blurry Tor Browser icon on macOS app switcher
   squash! Bug 2176: Rebrand Firefox to TorBrowser

 Bug 25702: Update Tor Browser icon to follow design guidelines
   took the aboutTBUpdateLogo.png changes (aboutTBUpdateLogo.png,
   browser/base/jar.mn) and added commit as fixup for
   `Bug 16940: After update, load local change notes.`

   the rest, squash! Bug 2176: Rebrand Firefox to TorBrowser

 Bug 22548: Firefox downgrades VP9 videos to VP8.
   squash! TB4: Tor Browser's Firefox preference overrides.

 Bug 14392: Make about:tor behave like other initial pages.
   squash! Bug 10760: Integrate TorButton to TorBrowser core
 }}}

 Some notes/questions:

 I did not  touch the onboarding patches, as I'm not sure what we are going
 to do with #31660. If we keep the current onboarding, I think it might be
 worth to squash them. I was thinking to keep two patches:

 - "Resurrect Firefox old onboarding"
   - Revert "Bug 1462415 - Delete onboarding system add-on
 r=Standard8,k88hudson
   - squash! Revert "Bug 1498378 - Actually remove the old onboarding add-
 

Re: [tor-bugs] #26149 [Applications/Quality Assurance and Testing]: Add some ansible roles for tor browser testsuite setup

[Tor Bug Tracker & Wiki]

#26149: Add some ansible roles for tor browser testsuite setup
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201811, boklm201811,   |  Actual Points:
  ReleaseTrainMigration  |
Parent ID:  #21404   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor58
-+-

Comment (by boklm):

 The latest branch is:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/log/?h=bug_26149_v14

 Some patches need to be squashed/rebased, which I'm planning to do this
 week.

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

Re: [tor-bugs] #33533 [Applications/Tor Browser]: Rebase Tor Browser esr68 patches on top of mozilla-central

[Tor Bug Tracker & Wiki]

#33533: Rebase Tor Browser esr68 patches on top of mozilla-central
--+
 Reporter:  acat  |  Owner:  acat
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:  14
Parent ID:  #33661| Points:
 Reviewer:  sysrqb, pospeselr |Sponsor:  Sponsor58-must
--+

Comment (by acat):

 Working on #31918, I looked a bit more at some patches (especially Android
 ones), and saw that several could (I think) be dropped. So to make #31918
 easier, I made a new branch for this ticket with changes that probably
 belong here and not in #31918.

 The new branch is https://github.com/acatarineu/tor-
 browser/commits/33533+4. I dropped the temp. fixups at the end of the
 previous branch, as those should be handled in child tickets and were only
 added to make a tor-browser-build easier.

 The rest of changes from 33533+3 to 33533+4 are:

 {{{
 Bug 28051 - Integrate Orbot and add dependencies
   drop, assuming we do not need anymore.

 Bug 25906 - Imply false both Adjust and Leanplum configure options
   drop, don't see this beeing used anymore.

 Bug 26528 - Don't allow Fennec to use UpdateService when installed through
 the app store
   drop, it does not even apply anymore to mozilla-beta, and the
   function was not really used anymore when this was rebased.

 Bug 25741 - TBA: Add mobile-override of 000-tor-browser prefs
   Moved `000-tor-browser*` changes from
   `Bug 25741 - TBA: Add mozconfig for Android and pertinent branding
 files.`
   to this one, since I think it belongs here.

   Removed change in browser/app/profile/000-tor-browser.js,
   `forward_oma_android_download_manager` is already false by
   default, and I do not see it being used anymore (this avoids
   a conflict in #31918 when rebasing the branch with autosquash).

   Also, moved `@BINPATH@/@PREF_DIR@/000-tor-browser-android.js`
   line in mobile/android/installer/package-manifest.in to make
   sure it's used in geckoview.

 Bug 25741 - TBA: Add mozconfig for Android and pertinent branding files.
   drop, part of it went to the pref overrides above, and the
   rest (mobile branding) I think it's not needed anymore.

 Bug 26045: Add new MAR signing keys
   drop, assuming that it's enough to have `Bug 32658: Create a new MAR
 signing key.`

 Bug 22548: Firefox downgrades VP9 videos to VP8.
   Removed default pref change in StaticPrefList.yaml, which I
   don't think is needed. I think this makes it better for this
   to be squashed with pref overrides.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33950 [Applications/Tor Browser]: Add instructions for rolling back already rolled out update in tor-browser-spec.git/processes/ReleaseProcess

[Tor Bug Tracker & Wiki]

#33950: Add instructions for rolling back already rolled out update in 
tor-browser-
spec.git/processes/ReleaseProcess
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In some cases we might want to disable an update after releasing it, for
 example after discovering an important issue. We should have instructions
 in `processes/ReleaseProcess` explaining how to do 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] #22668 [Core Tor/Tor]: Add ed25519 public key to format_node_description and callers

[Tor Bug Tracker & Wiki]

#22668: Add ed25519 public key to format_node_description and callers
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-log, tor-ed25519,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by wulder):

 I will begin work on this. Seems like a nice ticket to get me started.

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

Re: [tor-bugs] #32934 [Community/Relays]: EFF Legal FAQ review - 2020 edition

[Tor Bug Tracker & Wiki]

#32934: EFF Legal FAQ review - 2020 edition
--+
 Reporter:  ggus  |  Owner:  ggus
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ggus):

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


Comment:

 Merged EFF modifications.

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

 * status:  needs_review => needs_revision


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

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

Comment (by nickm):

 Hi again, and sorry about the delay!  The last week has been very intense.

 This new version of the code looks more workable than the last. I'd
 suggest these changes:
   * I'd suggest making a new patch that takes the new parts of
 `dirserv_generate_networkstatus_vote_obj` and turns it into a new
 function, for testing purposes.
   * Also, it seems like the code in
 `dirserv_generate_networkstatus_vote_obj` won't compare routers by IPv6
 addresses if they have any IPv4 address.  That seems wrong.
   * I don't think that removing the comment in that function about not
 using rl->routers is an improvement.
   * Our code style is not to write "if (a) b;" or "else c;" all on one
 line.  We should always have a new line for the code in the if and else
 blocks.
   * I think we could have a single "omit_as_sybil" digestmap, and add both
 sets of routers that we want to remove to it.  That would remove the need
 for duplication in other parts of the code.  (Also, it is not correct to
 call `dirserv_compute_performance_thresholds` twice in this way: it needs
 to be called exactly once per vote, with the complete list of sybils to
 omit.)
   * You don't need to malloc last_ipv6_addr in get_possible_sybil_list;
 you can just put it on the stack with `tor_addr_t last_ipv6_addr;`.
   * To copy `tor_addr_t`, use `tor_addr_copy`.
   * For the next version of this patch, could you please make a pull
 request?  That way, travis and appveyor will both run tests on the code to
 see if it's passing.

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

Re: [tor-bugs] #32088 [Core Tor/Tor]: Proposal 310 - choose guards in sampled order

[Tor Bug Tracker & Wiki]

#32088: Proposal 310 - choose guards in sampled order
--+
 Reporter:  Jaym  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec prop271 prop310  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Sorry for the delay: the last week or so has been hugely busy.

 The changes look good, but CI still isn't passing.  It looks like these
 tests are failing on appveyor:
 {{{
 entrynodes/confirming_guards: [forking] Skipping 1 testcases.
   FAIL ../src/test/test_entrynodes.c:1513: assert(g1->confirmed_idx OP_EQ
 0): 2 vs 0
   [confirming_guards FAILED]
 entrynodes/confirming_guards_reasonably_future: [forking] Skipping 1
 testcases.
   FAIL ../src/test/test_entrynodes.c:1513: assert(g1->confirmed_idx OP_EQ
 0): 2 vs 0
   [confirming_guards_reasonably_future FAILED]
 entrynodes/confirming_guards_reasonably_past: [forking] Skipping 1
 testcases.
   FAIL ../src/test/test_entrynodes.c:1513: assert(g1->confirmed_idx OP_EQ
 0): 2 vs 0
   [confirming_guards_reasonably_past FAILED]
 }}}

 I'm also seeing more practracker issues on Travis:
 {{{
 problem function-size
 /src/feature/client/entrynodes.c:entry_guard_parse_from_state() 272
 }}}

 For this one we should probably look for some code we can extract into a
 new function, to simplify this function.

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

Re: [tor-bugs] #33899 [Core Tor/Tor]: Allow IPv6 addresses to be canonical

[Tor Bug Tracker & Wiki]

#33899: Allow IPv6 addresses to be canonical
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, network-team- |  Actual Points:  0.3
  roadmap-2020Q2 |
Parent ID:  #33220   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


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

Re: [tor-bugs] #33899 [Core Tor/Tor]: Allow IPv6 addresses to be canonical

[Tor Bug Tracker & Wiki]

#33899: Allow IPv6 addresses to be canonical
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, network-team- |  Actual Points:  0.3
  roadmap-2020Q2 |
Parent ID:  #33220   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-

Comment (by nickm):

 This LGTM.  I'm inclined to rename `node_ap` in
 `connection_or_check_canonicity` to something like `canonical_ap`, but
 that can wait till #33898.

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

Re: [tor-bugs] #33920 [Core Tor/Chutney]: Remove errors or typos from TorNet.py and Templating.py

[Tor Bug Tracker & Wiki]

#33920: Remove errors or typos from TorNet.py and Templating.py
--+-
 Reporter:  MrSquanchee   |  Owner:  MrSquanchee
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:  easy, outreachy-ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+-
Changes (by nickm):

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


Comment:

 This LGTM; merging it to chutney master.

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

Re: [tor-bugs] #33918 [Core Tor/Tor]: Stop truncating IPv6 addresses in channel logs

[Tor Bug Tracker & Wiki]

#33918: Stop truncating IPv6 addresses in channel logs
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.4-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, prop311, prop312,  |  Actual Points:  0.1
  043-backport   |
Parent ID:  #33050   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
 |  Sponsor55-must
-+-
Changes (by nickm):

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


Comment:

 > I'll cherry-pick to 0.4.3 then merge.

 I just did this. (Cherry picked to 0.4.3 and then merged forward.)

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

Re: [tor-bugs] #32850 [Core Tor/Tor]: Channel padding timeout scheduled xxx ms in the past.

[Tor Bug Tracker & Wiki]

#32850: Channel padding timeout scheduled xxx ms in the past.
-+-
 Reporter:  computer_freak   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-backport, 042-backport,  |  Actual Points:
  043-deferred   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by computer_freak):

 Happened on Windows Server 2019 right now 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] #33940 [Internal Services/Tor Sysadmin Team]: Please remove irl from tordeb LDAP group (and any other deb.tpo related group)

[Tor Bug Tracker & Wiki]

#33940: Please remove irl from tordeb LDAP group (and any other deb.tpo related
group)
-+-
 Reporter:  irl  |  Owner:  anarcat
 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 anarcat):

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


Comment:

 done, thanks for the ticket.

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

Re: [tor-bugs] #33940 [Internal Services/Tor Sysadmin Team]: Please remove irl from tordeb LDAP group (and any other deb.tpo related group)

[Tor Bug Tracker & Wiki]

#33940: Please remove irl from tordeb LDAP group (and any other deb.tpo related
group)
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


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

Re: [tor-bugs] #33941 [Internal Services/Tor Sysadmin Team]: Nagios checks for op-??.onionperf.torproject.net

[Tor Bug Tracker & Wiki]

#33941: Nagios checks for op-??.onionperf.torproject.net
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | 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):

 >  Can we somehow include the op-??.onionperf.torproject.net hosts in
 Tor's Nagios -- for checks like running out of disk space -- even if those
 hosts are not managed by the Tor sysadmin team?

 Traditionnally, no: we have all sorts of automation to make checks
 *exactly* like running out of disk space on TPA hosts. It would be
 difficult to make those work on external hosts in our current
 infrastructure.

 One thing we could do would be to try Prometheus and Grafana for this. We
 have started working with the anti-censorship team to do this in #31159
 and while progress *has* been slow, I still believe it's our best shot at
 centralizing our monitoring infrastructure with this heterogeneous
 environment...

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

Re: [tor-bugs] #30735 [Core Tor/sbws]: Work out which relays are ignored by all sbws instances

[Tor Bug Tracker & Wiki]

#30735: Work out which relays are ignored by all sbws instances
-+-
 Reporter:  teor |  Owner:  juga
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:  8
  majority-blocker, sbws-roadmap |
Parent ID:  #33121   | Points:  6
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * actualpoints:   => 8


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

Re: [tor-bugs] #33350 [Core Tor/sbws]: Is sbws weighting some relays too high?

[Tor Bug Tracker & Wiki]

#33350: Is sbws weighting some relays too high?
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws:
  |  1.1.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  sbws-roadmap, network-health  |  Actual Points:
Parent ID:  #33947| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by juga):

 * parent:  #33121 => #33947


Comment:

 Let's also check this as part of #33947

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

Re: [tor-bugs] #33871 [Core Tor/sbws]: Scale exactly as torflow does?

[Tor Bug Tracker & Wiki]

#33871: Scale exactly as torflow does?
-+-
 Reporter:  juga |  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33775   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * owner:  (none) => juga
 * status:  new => assigned


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

[tor-bugs] #33949 [Internal Services/Tor Sysadmin Team]: python 2 end of life coordination

[Tor Bug Tracker & Wiki]

#33949: python 2 end of life coordination
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Python 2.7.18 has just been released. It is the last Python 2 release that
 will ever happen, and Python 2 is now unsupported, end of life,
 [https://www.enricozini.org/blog/2020/python/python-2-is-dead/ dead].

 It is likely that the next Debian release (bullseye) will not support
 Python 2 at all. It's also possible the current release (buster) does not
 support Python 2 for security issues forever. So we have *some* time, in
 practice, to handle this problem. But we definitely will need to finish
 this migration before some time around 2022, and the sooner the better.

 Until then, we need to figure out a strategy on how to handle that
 transition. Some of our code has been written for Python 3, but we have a
 large amount of Python-2-only code that is running, in multiple places.
 Some of it is TPA's responsibility, but other code is ran by teams or
 service admins.

 Since we run stretch or buster everywhere, we're in a good position to
 *not* have to support both Python 2 and Python 3 at once: we can just
 *migrate* to python 3. Stretch has Python 3.5 so we could target that as a
 minimum version. But we could also assume we will have completed the
 Buster upgrade by then and just target the more featureful Python 3.7.

 In any case, we need a plan for this and it would be wise to do it before
 we're backed into a corner.

 Some resources:

  * http://python3porting.com/ - python 3 porting book, freely available
  * https://python3statement.org/practicalities/ - some more advice on
 porting
  * https://docs.python.org/3/howto/pyporting.html - upstream guide, which
 still recommends supporting python 2.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

Re: [tor-bugs] #33871 [Core Tor/sbws]: Scale exactly as torflow does?

[Tor Bug Tracker & Wiki]

#33871: Scale exactly as torflow does?
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:5 starlight]:
 > Replying to [ticket:33871 juga]:
 >
 > > I think this is because while torflow multiplies the calculated ratio
 by the descriptor observed bandwidth [0], while sbws multiplies the ratio
 by the minimum of all descriptor bandwidth values *and* the consensus,
 which was added in #28598.
 >
 > flat wrong, see ticket:28588#comment:4

 i don't know what you mean about "flat wrong". That comment was about to
 include the "observed bandwidth" from the relay descriptors.
 >
 > > So maybe the new consensus bandwidth should not depend on the previous
 one, or not as the minimum.
 >
 > The problems with SBWS are due to poor quality absolute bandwidth
 measurement.

 i don't know what you mean about "poor quality" and "absolute bandwidth".

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

Re: [tor-bugs] #33871 [Core Tor/sbws]: Scale exactly as torflow does?

[Tor Bug Tracker & Wiki]

#33871: Scale exactly as torflow does?
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 gk and i thought that as a first step, we'll implement this patch and
 deploy it in maatuska.
 We'll then think more on how to check this before the majority of bwauths
 switch to sbws.

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

Re: [tor-bugs] #30735 [Core Tor/sbws]: Work out which relays are ignored by all sbws instances

[Tor Bug Tracker & Wiki]

#30735: Work out which relays are ignored by all sbws instances
-+-
 Reporter:  teor |  Owner:  juga
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:
  majority-blocker, sbws-roadmap |
Parent ID:  #33121   | Points:  6
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

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


Comment:

 gk and i had a converstation about this ticket.

 I think the goal of this ticket was that relay operators can see whether
 their relay is reported or not in the bandwidth file and i think it'd be
 even better if sbws would report about the aproximately the same number of
 relays as torflow, in which case it's not so important to show which are
 the relays not reported, since they'll be very few.

 gk pointed out interesting questions in this ticket:

 1. how do we compare with torflow?

 I think that with the lines included in the report, we can compare the
 number of relays in the consensus not reported by torflow and the ones not
 reported by sbws.

 For example, on 2020-04-18 06:00:
 The consensus has 6767 relays.
 longclaw is reporting on 8121 relays, from which 6609 are relays to vote.
 longclaw is not reporting about 10 relays in the consensus and it's not
 voting on 593 relays in it. It's not shown there, but in my experience
 many of the relays reported are not the ones in the consensus.
 760 of the relays reported had descriptors updated and 887 had router
 statuses updated.

 Compared with a Torflow instance:
 Torflow is reporting (and voting) about 8310 and 57 relays in the
 consensus are not in Torflow.
 We can't know whether the reported relays have their descriptors and
 router statuses updated.

 After longclaw is using sbws from maint-1.1 branch, on 2020-04-21 12:00:
 The consensus has 6790 relays.
 longclaw is reporting on 8084 relays, from which 6548 are relays to vote.
 longclaw is not reporting about 62 relays in the consensus and it's not
 voting on 626 of them.
 4651 of the relays reported had descriptors updated and 1130 had router
 statuses updated.

 Compared with a Torflow instance, torflow is reporting (and voting) on
 8481 relays, from which 129 are not in the consensus.

 2. how to check which are the relays "excluded by all sbws" instances?

 This will vary in each consensus since i think the main reason why sbws is
 not voting on some relays is due their relay descriptors/statuses not
 being updated.
 We could still report the common relays not being voted by sbws instances
 in each consensus.
 However i think that as, mentioned above, it'd be more useful to have sbws
 voting on aproximaely the same relays as torflow.

 gk and i thought that probably we don't have to do more in this ticket,
 but rather have another ticket were we check whether the bugfixes we have
 been working on are making sbws behave as torflow.
 I've created #33947 for this and i'm going to close this ticket for now,
 we can reopen it if we think we should focus on showing which are the
 relays excluded.

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

Re: [tor-bugs] #30735 [Core Tor/sbws]: Work out which relays are ignored by all sbws instances

[Tor Bug Tracker & Wiki]

#30735: Work out which relays are ignored by all sbws instances
-+-
 Reporter:  teor |  Owner:  juga
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Critical | Resolution:
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:
  majority-blocker, sbws-roadmap |
Parent ID:  #33121   | Points:  6
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:10 gk]:

 (given that the ticket is in `needs_review` but the request does not seem
 to be code related)

 Well, it's "related" code, it's just not sbws 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] #33295 [Internal Services/Tor Sysadmin Team]: Install Python 3-related packages on polyanthum

[Tor Bug Tracker & Wiki]

#33295: Install Python 3-related packages on polyanthum
-+
 Reporter:  phw  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by anarcat):

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


Comment:

 i'll assume this 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

[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|   Keywords:
  |  TorBrowserTeam202004
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I am currently running nightly builds at http://f4amtbsowhix7rrf.onion/. I
 think someone else from Tor Browser team should setup a new nightly build
 machine.

 To do that the ansible scripts in directory `tools/ansible` can be used:
 https://gitweb.torproject.org/builders/tor-browser-
 build.git/tree/tools/ansible

 You will need to:
  - if the host does not have a public IP address, you can install tor and
 setup an onion service on the http port (this part is not done in ansible)
  - add a new host in the `inventory` file
  - configure this host in your `~/.ssh/config` file if necessary (if the
 hostname added to the `inventory` file is not a real hostname), and make
 sure that you can connect to the host with `ssh root@$hostname`
  - copy the file `boklm-tbb-nightly-build.yml` to an other name
  - copy the directory `group_vars/boklm-tbb-nightly` to another group
 name, and update the configuration in `tbb-nightly-build.yml`
  - configure email on the host. This can be done in ansible with the file
 `dma.yml`. The email password (if needed) is stored encrypted in `dma-
 auth.yml` in the directory `vaulted_vars` (see
 https://docs.ansible.com/ansible/latest/cli/ansible-vault.html), and the
 password to decrypt the vault is passed with the `--vault-password-file`
 argument in the Makefile (maybe it's also possible to store `dma-auth.yml`
 outside tor-browser-build.git without using vault). Alternatively you can
 configure email on the host without using ansible, by removing the `mta`
 role from the `*-tbb-nightly-build.yml` file.
  - in the `Makefile` add a new *-tbb-nightly-build rule
  - run "make *-tbb-nightly-build"
  - if you enabled `nightly_build_sign_build` in `tbb-nightly-build.yml`,
 connect to the host and become the `tbb-nightly` user and generate a new
 gpg key (the key is not created automatically by ansible)

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

Re: [tor-bugs] #33198 [Core Tor/sbws]: Check changes related to descriptors in a bandwidth file created by a bwauth before next release

[Tor Bug Tracker & Wiki]

#33198: Check changes related to descriptors in a bandwidth file created by a
bwauth before next release
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal | Resolution:
 Keywords:  sbws-roadmap   |  Actual Points:
Parent ID:  #33947 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * parent:  #33121 => #33947


Comment:

 Now this is one of the things to check part of #33947

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33947 [Core Tor/sbws]: Compare sbws and Torflow

[Tor Bug Tracker & Wiki]

#33947: Compare sbws and Torflow
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal |   Keywords:  sbws-roadmap
Actual Points: |  Parent ID:  #33121
   Points: |   Reviewer:
  Sponsor: |
---+---
 gk and i were talking about what to review in #30375 and we thought it'd
 be useful to create a ticket to check whether the bugfixes we have been
 working on (https://trac.torproject.org/projects/tor/query?keywords=~sbws-
 roadmap=closed) to deploy sbws in all bwauths are working, ie.
 making sbws to behave very close to Torflow.

 I think we should document what to check, where/how to check it and which
 ticket(s) intended to fix it.

 I also think we should add this as documentation in sbws itself because
 they're important questions that have been blockers to deploy sbws in all
 bwauths and to avoid regressions in the future.

 Some of the main things to check that should be further explained are:
 - whether sbws "failures" "low" (#30719)
 - whether the number of relays to vote on reported by sbws "similar" to
 the number of relays reported by torflow (#30727, #30735)
 - whether sbws relay descriptors are updated (#30733)
 - whether sbws router statuses (relay info. from consensus) are updated
 (#30733)
 - whether sbws consensus bandwidth total sum is similar to torflow
 (#33871, #33009, #33350)?
 - whether changes in a relay consensus bandwidth affect in a similar way
 as torflow (#33871)

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

Re: [tor-bugs] #32422 [Internal Services/Service - git]: Add boklm as a gitolite admin

[Tor Bug Tracker & Wiki]

#32422: Add boklm as a gitolite admin
-+
 Reporter:  sysrqb   |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

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


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

Re: [tor-bugs] #33861 [Core Tor/Tor]: vanguards: circ_max_megabytes applied to all connection

[Tor Bug Tracker & Wiki]

#33861: vanguards: circ_max_megabytes applied to all connection
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:6 cypherpunks]:
 > I didn't attack you. I'm just telling the fact that Github is
 automatically blocking accounts if you create one over Tor.
 >

 Hey, i created over a year ago and used my github only with tor enabled
 torsocks git and this didn't happen to me yet. Is there more information?

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

Re: [tor-bugs] #33924 [Core Tor/Tor]: Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS

[Tor Bug Tracker & Wiki]

#33924: Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS
--+
 Reporter:  tla   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Major | Resolution:
 Keywords:  backport? |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by tla):

 With Tor 0.4.0.6:

 {{{
 Apr 21 15:59:50.160 [notice] Tor 0.4.0.6 (git-39344e410dca1dd4) running on
 Darwin with Libevent 2.1.11-stable, OpenSSL 1.1.1f, Zlib 1.2.11, Liblzma
 5.2.5, and Libzstd N/A.

 ...

 [OnionManager] #stopTor
 [Tor debug] conn_read_callback: socket 22 wants to read.
 [Tor debug] read_to_chunk: Read 19 bytes. 19 on inbuf.
 [Tor info] Interrupt: exiting cleanly.
 Apr 21 16:00:02.000 [notice] Interrupt: exiting cleanly.
 [Tor debug] pathbias_count_circs_in_states: Found opened circuit 2 in
 path_state build succeeded
 [Tor debug] pathbias_count_circs_in_states: Found opened circuit 3 in
 path_state build succeeded
 [Tor debug] pathbias_count_circs_in_states: Found opened circuit 4 in
 path_state build succeeded
 [Tor debug] pathbias_count_circs_in_states: Found opened circuit 5 in
 path_state build succeeded
 [Tor debug] pathbias_count_circs_in_states: Found opened circuit 6 in
 path_state build succeeded
 [Tor debug] tor_rename: Renaming
 /Users/berhart/Library/Developer/CoreSimulator/Devices/9A372026-08DE-
 
4A3A-B991-C22918F0CAA5/data/Containers/Data/Application/0A10C106-1A8A-4674-BB70-6487F63D37EB/Library/Caches/tor/state.tmp
 to /Users/berhart/Library/Developer/CoreSimulator/Devices/9A372026-08DE-
 
4A3A-B991-C22918F0CAA5/data/Containers/Data/Application/0A10C106-1A8A-4674-BB70-6487F63D37EB/Library/Caches/tor/state
 [Tor info] or_state_save: Saved state to
 "/Users/berhart/Library/Developer/CoreSimulator/Devices/9A372026-08DE-
 
4A3A-B991-C22918F0CAA5/data/Containers/Data/Application/0A10C106-1A8A-4674-BB70-6487F63D37EB/Library/Caches/tor/state"
 [Tor info] circuit_free_: Circuit 0 (id: 2) has been freed.
 [Tor info] circuit_free_: Circuit 0 (id: 6) has been freed.
 [Tor info] circuit_free_: Circuit 0 (id: 5) has been freed.
 [Tor info] circuit_free_: Circuit 0 (id: 4) has been freed.
 [Tor info] circuit_free_: Circuit 0 (id: 3) has been freed.
 [Tor debug] channel_tls_free_all: Shutting down TLS channels...
 [Tor debug] channel_tls_free_all: Done shutting down TLS channels
 [Tor debug] channel_free_all: Shutting down channels...
 [Tor debug] channel_free_list: Cleaning up channel 0x7fd7e3a2e740 (global
 ID 1) in state open (2)
 [Tor debug] channel_remove_from_digest_map: Removed channel 0x7fd7e3a2e740
 (global ID 1) from identity map in state open (2) with digest
 92173C9F108197460307969D35DACE9B9F09
 [Tor debug] channel_mark_for_close: Closing channel 0x7fd7e3a2e740 (global
 ID 1) by request
 [Tor debug] channel_change_state_: Changing state of channel
 0x7fd7e3a2e740 (global ID 1) from "open" to "closing"
 [Tor debug] free_socket_info_by_chan: scheduler free socket info for
 chan=1
 [Tor debug] free_socket_info_by_ent: Freeing socket table entry from
 chan=1
 [Tor debug] scheduler_set_channel_state: chan 1 changed from scheduler
 state WAITING_FOR_CELLS to IDLE
 [Tor debug] connection_mark_for_close_internal_: Calling
 connection_mark_for_close_internal_() on an OR conn at
 src/core/or/connection_or.c:1623
 [Tor debug] channel_force_xfree: Force-freeing channel 1 at 0x7fd7e3a2e740
 [Tor debug] scheduler_set_channel_state: chan 1 changed from scheduler
 state IDLE to IDLE
 [Tor debug] channel_clear_remote_end: Clearing remote endpoint identity on
 channel 0x7fd7e3a2e740 with global ID 1
 [Tor debug] circuitmux_free_: Freeing cmux at 0x63ffc050 with no
 queued destroys, the cmux destroy balance was 0, global is 0
 [Tor debug] channel_free_all: Freeing channel_identity_map
 [Tor debug] channel_free_all: Freeing channel_gid_map
 [Tor debug] channel_free_all: Done cleaning up after channels
 [Tor debug] connection_free_minimal: closing fd 15.
 [Tor debug] connection_free_minimal: closing fd 16.
 [Tor debug] connection_free_minimal: closing fd 22.
 [Tor debug] scheduler_free_all: Shutting down scheduler
 [Tor info] tor_lockfile_unlock: Unlocking
 "/Users/berhart/Library/Developer/CoreSimulator/Devices/9A372026-08DE-
 
4A3A-B991-C22918F0CAA5/data/Containers/Data/Application/0A10C106-1A8A-4674-BB70-6487F63D37EB/Library/Caches/tor/lock"
 [Tor debug] subsystems_shutdown_downto: Shutting down btrack
 [Tor debug] subsystems_shutdown_downto: Shutting down ocirc_event
 [Tor debug] subsystems_shutdown_downto: Shutting down orconn_event
 [Tor debug] subsystems_shutdown_downto: Shutting down process
 [Tor debug] subsystems_shutdown_downto: Shutting down crypto
 [Tor debug] 

Re: [tor-bugs] #33924 [Core Tor/Tor]: Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS

[Tor Bug Tracker & Wiki]

#33924: Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS
--+
 Reporter:  tla   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Major | Resolution:
 Keywords:  backport? |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by tla):

 n8fr8, this is what we do on iOS to shut down Tor:

 
https://github.com/iCepa/Tor.framework/blob/master/Tor/TORController.m#L234-L245

 Spot any important differences? I already played around with
 capitalization and removing the NEWNYM call. No difference.

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

Re: [tor-bugs] #33924 [Core Tor/Tor]: Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS

[Tor Bug Tracker & Wiki]

#33924: Tor beginning with 0.4.1 seems to ignore SIGNAL SHUTDOWN on iOS
--+
 Reporter:  tla   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Major | Resolution:
 Keywords:  backport? |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by n8fr8):

 I will test today nickm

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

Re: [tor-bugs] #33919 [Core Tor/Tor]: Write unit tests for channel_matches_target_addr_for_extend()

[Tor Bug Tracker & Wiki]

#33919: Write unit tests for channel_matches_target_addr_for_extend()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop311, ipv6, technical-debt,   |  Actual Points:
  outreachy-ipv6, tests  |
Parent ID:  #33048   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-
Changes (by MrSquanchee):

 * status:  new => needs_review


Comment:

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

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

Re: [tor-bugs] #33437 [Core Tor/Tor]: Unsuccessful compilation of tor on FreeBSD system with libssl.so.11

[Tor Bug Tracker & Wiki]

#33437: Unsuccessful compilation of tor on FreeBSD system with libssl.so.11
-+-
 Reporter:  stillicide   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  0.4.2.6
 Severity:  Normal   | Resolution:
 Keywords:  FreeBSD, openssl, 043-backport   |  Actual Points:
  042-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Yikes, sorry for the delay. This one fell off my radar. Can you also
 include the error message from the unsuccessful compilatino?

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

Re: [tor-bugs] #33861 [Core Tor/Tor]: vanguards: circ_max_megabytes applied to all connection

[Tor Bug Tracker & Wiki]

#33861: vanguards: circ_max_megabytes applied to all connection
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #33875 [Community/Tor Support]: versão do windows

[Tor Bug Tracker & Wiki]

#33875: versão do windows
---+--
 Reporter:  luciano|  Owner:  ggus
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * owner:  (none) => ggus
 * component:  - Select a component => Community/Tor Support


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

Re: [tor-bugs] #22034 [Core Tor/Tor]: GETINFO extra-info/digest/

[Tor Bug Tracker & Wiki]

#22034: GETINFO extra-info/digest/
-+-
 Reporter:  olaf.selke@… |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression, control, 029-backport,   |  Actual Points:
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 (Going to need more information there, cypherpunks: -- does that extrainfo
 actually exist? Does the same happen with every extrainfo, or just some?
 What version of Tor, etc?)

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

Re: [tor-bugs] #33929 [Core Tor/Tor]: Tor relay appears offline in Metrics after some times

[Tor Bug Tracker & Wiki]

#33929: Tor relay appears offline in Metrics after some times
--+--
 Reporter:  clement   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 That's strange! Is there anything in your logs to suggest what might be
 happening here?  What platform/OS are you running on?  Did you upgrade or
 change anything about your relay around that time?

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

Re: [tor-bugs] #33618 [Core Tor/Tor]: Add IPv6 Support to is_local_addr()

[Tor Bug Tracker & Wiki]

#33618: Add IPv6 Support to is_local_addr()
--+
 Reporter:  kimimaro  |  Owner:  kimimaro
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  outreachy-ipv6 ipv6  prop312  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:  teor  |Sponsor:  Sponsor55-can
--+

Comment (by nickm):

 Hm, that looks like it could be a start, but there's going to be a problem
 to the extent that `router_get_my_routerinfo()` might not actually work
 from  the unit tests: it requires that there actually exists a routerinfo,
 which clients don't have.  Maybe there is a better way to get one or more
 ipv6 addresses to test with -- how about `tor_addr_parse()`?

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

Re: [tor-bugs] #33411 [Core Tor/Tor]: Make DirCache default to 0 on Windows relays

[Tor Bug Tracker & Wiki]

#33411: Make DirCache default to 0 on Windows relays
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:
 Keywords:  044-should, cpu, windows, linux, |  Actual Points:
  performance, regression, 033-triage-20180326,  |
  033-removed-20180326, 034-deferred-20180602,   |
  035-removed-20180711, 032-unreached-backport,  |
  040-roadmap-proposed, 033-unreached-backport-  |
  maybe, network-health  |
Parent ID:  #24857   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Replying to [comment:3 gvanem]:
 > If this bug-tracker had been on Github, I would have seen your reply
 sooner.
 > But you insist on using this German Trac crap?

 We're hoping to migrate to a gitlab installation some time this year.
 Sorry that trac isn't working out for you.  Do you think you might be able
 to answer any of the questions on this or the other 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] #33920 [Core Tor/Chutney]: Remove errors or typos from TorNet.py and Templating.py

[Tor Bug Tracker & Wiki]

#33920: Remove errors or typos from TorNet.py and Templating.py
--+--
 Reporter:  MrSquanchee   |  Owner:  MrSquanchee
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy, outreachy-ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+--
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #33750 [Internal Services/Services Admin Team]: Hosting BTCPayserver

[Tor Bug Tracker & Wiki]

#33750: Hosting BTCPayserver
-+-
 Reporter:  hiro |  Owner:  hiro
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pavlenex):

 Hello,

 BTCPay Server core contributor here. sstevenson directed me to this
 ticket. Happy to help with whatever is needed to make the transition
 smooth.

 BTCPay Server can be very easily run and deployed with and VPS that meets
 minimum requirements.

 The server hiro suggested sounds good as well.

 Let me know if I can help somehow.

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

Re: [tor-bugs] #33721 [Applications/Tor Browser]: pdf viewer is not working in the safest security level

[Tor Bug Tracker & Wiki]

#33721: pdf viewer is not working in the safest security level
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam202004, ff78-esr-  |  Actual Points:
  will-have, tbb-usability   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => new


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

Re: [tor-bugs] #33721 [Applications/Tor Browser]: pdf viewer is not working in the safest security level

[Tor Bug Tracker & Wiki]

#33721: pdf viewer is not working in the safest security level
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam202004, ff78-esr-  |  Actual Points:
  will-have, tbb-usability   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 TorBrowserTeam202004, ff78-esr-will-have, GeorgKoppen202004, tbb-
 usability
 => TorBrowserTeam202004, ff78-esr-will-have, tbb-usability
 * owner:  gk => tbb-team


Comment:

 Replying to [comment:4 gk]:
 > This applies cleanly to our esr 68 code and is small. I think that's
 worth testing in the next alpha and shipping in 9.5.

 The small part is not enough, though, we need changes done in

 https://bugzilla.mozilla.org/show_bug.cgi?id=911444 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=1622042

 as well, which makes this endeavor considerably more complex. Given our
 other prios it might not be worth it, alas. :(

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

Re: [tor-bugs] #33930 [Applications/Tor Browser]: Tor binary we build seems to not getting picked up in nightly builds

[Tor Bug Tracker & Wiki]

#33930: Tor binary we build seems to not getting picked up in nightly builds
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202004, GeorgKoppen202004|
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I wonder why we can't just let `tor` speak directly as on the other
 platforms. I think that's the ideal solution here. I'll dig a bit...

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

Re: [tor-bugs] #29636 [Metrics/Website]: Document how we estimate users by transport by country

[Tor Bug Tracker & Wiki]

#29636: Document how we estimate users by transport by country
-+
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24422   | Points:
 Reviewer:  irl  |Sponsor:
-+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 irl and I discussed this ticket. We agreed that the Q link could go away
 if we're being a bit more explicit in the graph description that the
 displayed numbers do not count exactly the number of users. Changing to
 needs_revision for that minor textual change which then doesn't need
 another review to be merged.

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

Re: [tor-bugs] #32065 [Metrics/Onionoo]: Cache-Control header on 404 does not permit caching

[Tor Bug Tracker & Wiki]

#32065: Cache-Control header on 404 does not permit caching
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_review => new


Comment:

 irl and I just talked about this change and found it a good way forward.
 There's still code to write which I'll do, so changing status back to new.

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

Re: [tor-bugs] #17939 [Metrics/Onionoo]: Optimize the construction of details documents with field constraints

[Tor Bug Tracker & Wiki]

#17939: Optimize the construction of details documents with field constraints
-+--
 Reporter:  fmap |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_review => merge_ready


Comment:

 irl and I just discussed this patch conceptually and agree that this is a
 good change. The code changes are not that complex, so I'm going to merge
 the patch as time permits in the next weeks.

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

Re: [tor-bugs] #33502 [Metrics/CollecTor]: Do not let appended descriptor files grow too large

[Tor Bug Tracker & Wiki]

#33502: Do not let appended descriptor files grow too large
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  needs_review => new


Comment:

 irl and I just talked this over and concluded that producing tarballs is
 the better design here. It solves the large files issue, and it might even
 fix data integrity/consistency issues that just haven't surfaced yet. I'm
 going to write a patch for the tarball idea some time in the next weeks.
 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] #33930 [Applications/Tor Browser]: Tor binary we build seems to not getting picked up in nightly builds

[Tor Bug Tracker & Wiki]

#33930: Tor binary we build seems to not getting picked up in nightly builds
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202004, GeorgKoppen202004|
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Hm, there seems to be no easy way to get the version information at that
 point. :( So, maybe we should just not omit it then or move it to a later
 point in the start-up process when we do have it available. It would be
 good to know the respective Tor version used for debugging help, in
 particular now that we are starting to use different Tor versions.

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

Re: [tor-bugs] #33930 [Applications/Tor Browser]: Tor binary we build seems to not getting picked up in nightly builds

[Tor Bug Tracker & Wiki]

#33930: Tor binary we build seems to not getting picked up in nightly builds
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202004, GeorgKoppen202004|
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * priority:  High => Medium


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

Re: [tor-bugs] #33930 [Applications/Tor Browser]: Tor binary we build seems to not getting picked up in nightly builds (was: Tor binary we build is not picked up in nightly builds)

[Tor Bug Tracker & Wiki]

#33930: Tor binary we build seems to not getting picked up in nightly builds
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202004, GeorgKoppen202004|
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> We build Tor for Android now ourselves thanks to the fix for #28766. But
> unfortunately it is not picked up yet, despite #32993 claiming so. I
> stumbled across this when testing a fix for #32027. The branch has all
> patches for #28704 and children but it's still shown that we use the Tor
> we've been bundling so far but not the one we compile.

New description:

 We build Tor for Android now ourselves thanks to the fix for #28766. But
 unfortunately it seems at least as it is not picked up yet, despite #32993
 claiming so. I stumbled across this when testing a fix for #32027. The
 branch has all patches for #28704 and children but it's still shown that
 we use the Tor we've been bundling so far but not the one we compile.

--

Comment (by gk):

 Okay, I have been looking closer. Looking at the `libTor.so` we actually
 ship in nightlies *does* imply that it contains the `tor` and `OpenSSL`
 version we compile (I ran `strings` over the `.so` file), so that's good.
 What is happening is that the binary version check done in `tor-android-
 service` is just returning a hard-coded string `TOR_VERSION`, which is
 currently set to `0.4.1.5-rc-openssl1.0.2p`.

 So, we might actually be good here at least with respect to the actually
 used Tor/OpenSSL version, but that's hard to say. Either way, we need to
 come up with a better solution than hard-coding given that we support
 different Tor versions in parallel 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] #33946 [Internal Services/Service - git]: Please add karsten to onionperf repository

[Tor Bug Tracker & Wiki]

#33946: Please add karsten to onionperf repository
-+
 Reporter:  irl  |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

 * cc: karsten (added)
 * status:  new => closed
 * resolution:   => fixed


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

[tor-bugs] #33946 [Internal Services/Service - git]: Please add karsten to onionperf repository

[Tor Bug Tracker & Wiki]

#33946: Please add karsten to onionperf repository
-+
 Reporter:  irl  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 For trac.tpo on 2020-04-21:

 Please add karsten to onionperf repository, he will become the new product
 owner effective immediately.


 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEE/ps4MHN0fw3t6AudF4mIfdjVvF0FAl6erFkACgkQF4mIfdjV
 vF3BhQ//VhhceDMWR0myy/fGAqJ3hrHsI8WZYVY3m0NhB5SByjPPKeX93PzRUGDv
 FGtlq4JgKp5Ns84/G2G0LEosfjwBAN9dFyBH8ufI/Kn6CiYvzO+aO3YveJ6FK8FW
 4REjqwNHUSQHJh7Mie1Vkka29mQ+S3aBmQnj4Xq+2KXNWMHe/1o4NvPM7/H4kW89
 lk62Gb5BMKaMUYXVjytAxK0x5sbcgv3eKv9MGif3nMLCxfUXMlWS072Jdl79DgqE
 MHI7bgAExi6AxnKfFYwXbEdU9srd6mIECAEjN2H/fJ9yZrrDFsUQL0lkMjhrJF21
 6wqdEivEoTI3Gj4KSooL1rK2Vz61/0Moa+dFt2QCu1bXnZlKSqBXJBfcEVasBkTc
 8h07vLyulYa6JLL4IoYY2xZmyLzx/u2+k5FV0teLsIGzjPZURcL7wvtZP16AhfBb
 k8X9rhmAcOvAVrohX70IN9uYebtX6+fHBsH7eqQEFDIsezmLseN0sYoPItAT+dI+
 tY++cyygiCFTuI9U7kKaLVQLhfYckLIOp+MJvlqza8xPAglJZSy5Jr1F3vFjy5l1
 klhREXHV/VKEnx9xUOKNZiR3GLvc08crsjQVHoss16vUl4e3NXrEQeHNwG9m6Ljr
 /n29ZxkUW5Mf3HGY7E+XSntx4cVYkQZHdvNqejBTMPNcjVBJuFM=
 =IGBz
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #33930 [Applications/Tor Browser]: Tor binary we build is not picked up in nightly builds

[Tor Bug Tracker & Wiki]

#33930: Tor binary we build is not picked up in nightly builds
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202004, GeorgKoppen202004|
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: gk (removed)
 * owner:  tbb-team => gk
 * status:  new => assigned
 * keywords:  tbb-mobile, tbb-rbm, tbb-parity, TorBrowserTeam202004 =>
 tbb-mobile, tbb-rbm, tbb-parity, TorBrowserTeam202004,
 GeorgKoppen202004


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

Re: [tor-bugs] #33721 [Applications/Tor Browser]: pdf viewer is not working in the safest security level

[Tor Bug Tracker & Wiki]

#33721: pdf viewer is not working in the safest security level
-+-
 Reporter:  boklm|  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam202004, ff78-esr-  |  Actual Points:
  will-have, GeorgKoppen202004, tbb-usability|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam202006, ff78-esr-will-have =>
 TorBrowserTeam202004, ff78-esr-will-have, GeorgKoppen202004, tbb-
 usability
 * status:  new => assigned
 * owner:  tbb-team => gk


Comment:

 This applies cleanly to our esr 68 code and is small. I think that's worth
 testing in the next alpha and shipping in 9.5.

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

Re: [tor-bugs] #29614 [Applications/Tor Browser]: Use SHA-256 algorithm for Windows timestamping (was: Use SHA-256 algorithm for Windows authenticode timestamping)

[Tor Bug Tracker & Wiki]

#29614: Use SHA-256 algorithm for Windows timestamping
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sign, tbb-security, tbb-8.5, |  Actual Points:
  GeorgKoppen202004, TorBrowserTeam202004R   |
Parent ID:  #33168   | Points:
 Reviewer:   |Sponsor:
-+-

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