Re: [tor-bugs] #24954 [Metrics/Website]: Metrics performance measurements use v2 onion services

[Tor Bug Tracker & Wiki]

#24954: Metrics performance measurements use v2 onion services
-+-
 Reporter:  teor |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  easy, intro  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 Thanks for taking a look! Merged to master and deployed. Closing.

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

Re: [tor-bugs] #19417 [Applications/Tor Browser]: asm.js files should be no linkability risk

[Tor Bug Tracker & Wiki]

#19417: asm.js files should be no linkability risk
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, GeorgKoppen201609,  |  Actual Points:
  TorBrowserTeam201609, ff52-esr,|
  TorBrowserTeam201802   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-linkability, GeorgKoppen201609, TorBrowserTeam201609,
 ff52-esr =>
 tbb-linkability, GeorgKoppen201609, TorBrowserTeam201609, ff52-esr,
 TorBrowserTeam201802


Comment:

 Replying to [comment:31 gk]:
 > Replying to [comment:30 legind]:
 > > Here's a friendly ping to revisit this issue, now that the transition
 to 52 is complete.
 >
 > So, the disk leak is gone but there is still the problem of asmjs not
 adhering to our URL bar domain isolation. This part still needs to be
 investigated. I am adjusting the title and description of the ticket.

 Actually, asm.js should be governed by the QuotaManager which in turn
 should take care of FPI. We should double-check that and, if it is indeed
 true, put it again into our security slider-treatment.

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

Re: [tor-bugs] #25179 [Applications/Tor Browser]: identity leakage, resolution

[Tor Bug Tracker & Wiki]

#25179: identity leakage, resolution
--+--
 Reporter:  y2875095  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  tbb-team  |Sponsor:
--+--
Changes (by gk):

 * priority:  Very High => Medium
 * keywords:  tbb-security =>
 * status:  new => closed
 * resolution:   => invalid
 * severity:  Critical => Normal


Comment:

 Fake properties are probably not working pretty well. The idea is to make
 all Tor Browser users as uniform as possible. See:
 https://www.torproject.org/projects/torbrowser/design/#fingerprinting-
 linkability.

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

Re: [tor-bugs] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
---+--
 Reporter:  pospeselr  |  Owner:  boklm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201802R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:   => TorBrowserTeam201802R
 * status:  new => needs_review


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

Re: [tor-bugs] #17228 [Applications/Tor Browser]: Consideration for disabling referrers within TBB

[Tor Bug Tracker & Wiki]

#17228: Consideration for disabling referrers within TBB
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #25180 is a duplicate.

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

Re: [tor-bugs] #25180 [Applications/Tor Browser]: Protect against Referer Tracking in Tor Browser

[Tor Bug Tracker & Wiki]

#25180: Protect against Referer Tracking in Tor Browser
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #17228.

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

Re: [tor-bugs] #25189 [Webpages/Website]: Add some clear warning to download page that modifying 3 to 7|8 is a bad idea.

[Tor Bug Tracker & Wiki]

#25189: Add some clear warning to download page that modifying 3 to 7|8 is a bad
idea.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * component:  Applications/Tor Browser => Webpages/Website


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

Re: [tor-bugs] #25190 [- Select a component]: Why "Add to CC" is already set to "tor-dev" email address?

[Tor Bug Tracker & Wiki]

#25190: Why "Add to CC" is already set to "tor-dev" email address?
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * cc: tor-dev@… (added)


Comment:

 Add to Cc:  tor-...@lists.torproject.org  [ ]

 Is it really necessary?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25190 [- Select a component]: Why "Add to CC" is already set to "tor-dev" email address?

[Tor Bug Tracker & Wiki]

#25190: Why "Add to CC" is already set to "tor-dev" email address?
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 To reproduce: just logout and login to cyp account. You'll see tor-dev
 email address to CC field.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25189 [- Select a component]: Add some clear warning to download page that modifying 3 to 7|8 is a bad idea.

[Tor Bug Tracker & Wiki]

#25189: Add some clear warning to download page that modifying 3 to 7|8 is a bad
idea.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 http://endchan5doxvprs5.onion/os/res/2.html#1098

 Wow.

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

Re: [tor-bugs] #25189 [Applications/Tor Browser]: Add some clear warning to download page that modifying 3 to 7|8 is a bad idea.

[Tor Bug Tracker & Wiki]

#25189: Add some clear warning to download page that modifying 3 to 7|8 is a bad
idea.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #25188 [Core Tor/Tor]: Spec bug in formal definition of Document in dir-spec.txt

[Tor Bug Tracker & Wiki]

#25188: Spec bug in formal definition of Document in dir-spec.txt
--+
 Reporter:  witchof0x20   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review
 * points:   => 0.1
 * milestone:   => Tor: 0.3.4.x-final


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

[tor-bugs] #25188 [Core Tor/Tor]: Spec bug in formal definition of Document in dir-spec.txt

[Tor Bug Tracker & Wiki]

#25188: Spec bug in formal definition of Document in dir-spec.txt
--+--
 Reporter:  witchof0x20   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   |   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I was attempting to write a parser that reads vote/consensus documents
 using the the formal definition
 [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210 here].
 However, I noticed an ambiguity.

 Using only the formal definition, the following:

 {{{
 directory-signature 13241234321 12343234
 -BEGIN SIGNATURE-
 00thisisvalidbase64data12345
 -END SIGNATURE-
 }}}
 Could be potentially parsed as

 {{{
 Document(
   Item(
     KeywordLine(
   Keyword(KeywordChar+("directory-signature")),
   WS,
   ArgumentChar+("13241234321 12343234"),
   NL
     )
   ),
   Item(
     KeywordLine(
   Keyword(KeywordChar+("-BEGIN")),
   WS,
   ArgumentChar+("SIGNATURE-"),
   NL
     )
   ),
   Item(
     KeywordLine(
   Keyword(KeywordChar+("00thisisvalidbase64data12345"))
   WS,
   ArgumentChar+("SIGNATURE-"),
   NL
     )
   ),
   Item(
     KeywordLine(
   Keyword(KeywordChar+("-END")),
   WS,
   ArgumentChar+("SIGNATURE-"),
   NL
     )
   ),
 )
 }}}
 When the correct parsing would be

 {{{
 Document(
   Item(
     KeywordLine(
   Keyword(KeywordChar+("directory-signature")),
   WS,
   ArgumentChar+("13241234321 12343234"),
   NL
     ),
     Object(
   BeginLine(
     "-BEGIN ",
     Keyword(KeywordChar+("SIGNATURE")),
     "-",
         NL
       ),
       Base64-encoded-data("00thisisvalidbase64data12345"),
   EndLine(
     "-END ",
     Keyword(KeywordChar+("SIGNATURE")),
     "-",
         NL
       ),
     ),
   ),
 )
 }}}
 A potential change to the spec (assuming that keywords will never start
 with "-") that would prevent would be to replace

 {{{
 Keyword = KeywordChar+
 KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
 }}}
 with

 {{{
 Keyword = KeywordStartChar KeywordChar*
 KeywordStartChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9'
 KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25187 [Applications/Orbot]: [Android] Tor-enable Apps

[Tor Bug Tracker & Wiki]

#25187: [Android] Tor-enable Apps
+--
 Reporter:  dovanvu1792@…   |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:  Tor: unspecified
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 Hello, I am TieuVu, I'm Android developer, I downloaded and ran Tor
 project use android studio. But When i active some app like firefox or
 chorme to use Tor via VPN mode. Only show Sorry You are not using Tor.
 also Orfox normal working (Congratulations. This browser is configred to
 use Tor). I tried build debug and sign new apk, but it not working.
 Anybody can help me to fix it.

 Version name: 16.0.0-RC-2-multi-SDK16
 versionCode 1610

 Have some Logs:
 ===
 Log 1:
 ===
 02-09 11:31:45.934 2450-7273/org.torproject.android1 D/OrbotVpnService:
 tun2Socks has stopped
 java.io.IOException: Error running exec(). Command:
 [/data/data/org.torproject.android1/app_bin/pdnsd, -c,
 /data/data/org.torproject.android1/app_bin/pdnsd.conf] Working Directory:
 null Environment: [ANDROID_ROOT=/system,
 EMULATED_STORAGE_SOURCE=/mnt/shell/emulated, LOOP_MOUNTPOINT=/mnt/obb,
 LD_PRELOAD=libsigchain.so:libNimsWrap.so, ANDROID_BOOTLOGO=1,
 EMULATED_STORAGE_TARGET=/storage/emulated,
 EXTERNAL_STORAGE=/storage/emulated/legacy,
 SYSTEMSERVERCLASSPATH=/system/framework/services.jar:/system/framework
 /ethernet-service.jar:/system/framework/wifi-service.jar,
 ANDROID_SOCKET_zygote=9,
 PATH=/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin,
 ANDROID_DATA=/data, ANDROID_ASSETS=/system/app, ASEC_MOUNTPOINT=/mnt/asec,
 BOOTCLASSPATH=/system/framework/core-
 
libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework
 /core-
 
junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework
 /telephony-common.jar:/system/framework/voip-common.jar:/system/framework
 /ims-common.jar:/system/framework/mms-
 common.jar:/system/framework/android.policy.jar:/system/framework/apache-
 
xml.jar:/system/framework/qcmediaplayer.jar:/system/framework/org.codeaurora.Performance.jar:/system/framework/vcard.jar:/system/framework/tcmiface.jar:/system/framework/qcom.fmradio.jar:/system/framework
 /oem-services.jar, ANDROID_PROPERTY_WORKSPACE=8,0,
 SECONDARY_STORAGE=/storage/sdcard1, ANDROID_STORAGE=/storage]
 at java.lang.ProcessManager.exec(ProcessManager.java:211)
 at java.lang.ProcessBuilder.start(ProcessBuilder.java:195)
 at
 
org.torproject.android.service.vpn.OrbotVpnManager.startDNS(OrbotVpnManager.java:413)
 at
 
org.torproject.android.service.vpn.OrbotVpnManager.access$400(OrbotVpnManager.java:55)
 at
 
org.torproject.android.service.vpn.OrbotVpnManager$2.run(OrbotVpnManager.java:295)
 Caused by: java.io.IOException: No such file or directory
 at java.lang.ProcessManager.exec(Native Method)
 at java.lang.ProcessManager.exec(ProcessManager.java:209)
 at java.lang.ProcessBuilder.start(ProcessBuilder.java:195)
 at
 
org.torproject.android.service.vpn.OrbotVpnManager.startDNS(OrbotVpnManager.java:413)
 at
 
org.torproject.android.service.vpn.OrbotVpnManager.access$400(OrbotVpnManager.java:55)
 at
 
org.torproject.android.service.vpn.OrbotVpnManager$2.run(OrbotVpnManager.java:295)
 ===
 Log 2:
 ===
 02-09 11:34:17.449 8881-8985/org.torproject.android E/Orbot: error onBind
 java.io.FileNotFoundException: armeabi/obfs4proxy.mp3
  at
 android.content.res.AssetManager.openAsset(Native Method)
  at
 android.content.res.AssetManager.open(AssetManager.java:318)
  at
 android.content.res.AssetManager.open(AssetManager.java:292)
  at
 
org.torproject.android.service.util.OtherResourceInstaller.installResources(OtherResourceInstaller.java:77)
  at
 
org.torproject.android.service.TorService.torUpgradeAndConfig(TorService.java:650)
  at
 org.torproject.android.service.TorService.access$800(TorService.java:90)
  at
 org.torproject.android.service.TorService$2.run(TorService.java:599)
  at
 java.lang.Thread.run(Thread.java:818)

--
Ticket URL: 
Tor

[tor-bugs] #25186 [Internal Services/Tor Sysadmin Team]: Please refresh sysrqb's pgp key

[Tor Bug Tracker & Wiki]

#25186: Please refresh sysrqb's pgp key
-+-
 Reporter:  sysrqb   |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I have a new (non-expired) subkey:

 {{{
 $ gpg -k CE1782624600EE98764C6D9CCB8FC772D1AA1D30
 pub   rsa4096 2014-06-26 [SC] [expires: 2018-07-21]
   CE1782624600EE98764C6D9CCB8FC772D1AA1D30
 uid   [ unknown] Matthew Finkel 
 uid   [ unknown] Matthew Finkel 
 sub   rsa4096 2018-01-10 [S] [expires: 2018-07-09]
 sub   rsa4096 2018-01-10 [E] [expires: 2018-07-09]
 sub   rsa4096 2018-01-10 [A] [expires: 2018-07-09]
 }}}

 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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by mwolfe):

 I go by empirical evidence. Official announcements are intended to look
 good. They started blocking Skype, and that may have blocked Tor. I have
 no idea how they are blocking Skype now. Before, they blocked access to
 skype.com, so no one here could download the program without Tor or a VPN.
 Those who could go somewhere that skype.com was not blocked could bring
 back a copy that worked. Now skype.com is not blocked, so anyone can
 download Skype, but it doesn't work.

 Tor was working fine on 31 Dec and needed a bridge on 1 Jan, so one
 deduces that they started blocking it, with or without an announcement.
 It's also hard to know what they would have called the rule. It must not
 be named 'Tor', but some other name. I have no idea what they might call
 it, and I couldn't find it, either.

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by starlight):

 Seems to me `ConnDirectionStatistics` is a problem as well.  Disable it on
 the relay yesterday.

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

Re: [tor-bugs] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
-+-
 Reporter:  alecmuffett  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.9
 Severity:  Minor| Resolution:
 Keywords:  single-onion, guards, logging, easy  |  Actual Points:
Parent ID:  #23863   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  single-onion, guards => single-onion, guards, logging, easy
 * points:   => 0.5
 * severity:  Normal => Minor
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Single onion services use multi-hop paths to upload their descriptors, but
 these paths do not share a guard. (EntryGuards is 0.)

 So I think this is an annoying logging bug, rather than anything serious.
 If they ever stop building circuits, let us know. That is a problem we
 should fix.

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

Re: [tor-bugs] #24992 [Core Tor/Tor]: SingleOnion (and Tor2web?) connections may need better expiry, lots left open

[Tor Bug Tracker & Wiki]

#24992: SingleOnion (and Tor2web?) connections may need better expiry, lots left
open
+
 Reporter:  alecmuffett |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.9
 Severity:  Normal  | Resolution:
 Keywords:  single-onion, circuits  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * keywords:  singleonion, circuits => single-onion, circuits
 * milestone:   => Tor: 0.3.4.x-final


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

Re: [tor-bugs] #24991 [Core Tor/Tor]: SingleOnion claims "missing descriptors for 1/2 of our primary entry guards", has no guards, makes no sense

[Tor Bug Tracker & Wiki]

#24991: SingleOnion claims "missing descriptors for 1/2 of our primary entry
guards", has no guards, makes no sense
--+
 Reporter:  alecmuffett   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal| Resolution:
 Keywords:  single-onion, guards  |  Actual Points:
Parent ID:  #23863| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  singleonion, guards => single-onion, guards
 * parent:   => #23863
 * milestone:   => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #13908 [Core Tor/Tor]: Make it safe to set NumDirectoryGuards=1

[Tor Bug Tracker & Wiki]

#13908: Make it safe to set NumDirectoryGuards=1
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-client, needs-   |  Actual Points:
  design guards client-enumeration research- |
  program|
Parent ID:  #21006   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 In particular, our missing microdesc mitigations only work because there
 are multiple directory guards. We'll need to implement some of the more
 serious fallback strategies under #23863 to move to one directory guard.

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by starlight):

 good to learn the trace is helpful

 relevant configurations in effect during the trace run were

 {{{
 AvoidDiskWrites 1
 RunAsDaemon 1
 NumCPUs 1
 DownloadExtraInfo 1
 DisableAllSwap 1
 MaxMemInQueues 512MB
 CellStatistics 1
 EntryStatistics 1
 ConnDirectionStatistics 1
 HiddenServiceStatistics 1
 ExitPolicy reject *:*
 }}}

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

Re: [tor-bugs] #13908 [Core Tor/Tor]: Make it safe to set NumDirectoryGuards=1

[Tor Bug Tracker & Wiki]

#13908: Make it safe to set NumDirectoryGuards=1
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-client, needs-   |  Actual Points:
  design guards client-enumeration research- |
  program|
Parent ID:  #21006   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Another piece of moving to just one directory guard: right now relays will
 return a 503 if they're running low on bandwidth in their token buckets.
 The idea is it's fine to shed load and push it somewhere else in the
 network that can handle it.

 But if we have guards who have run out of bandwidth and they're serving a
 bunch of 503's, this won't be any fun for the clients who use those
 guards.

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

Re: [tor-bugs] #14045 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Use Firefox SDK

[Tor Bug Tracker & Wiki]

#14045: Use Firefox SDK
-+-
 Reporter:  Marnes   |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:  invalid
 Keywords:  sdk  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by strugee):

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


Comment:

 HTTPS Everywhere is a WebExtension now: https://github.com/EFForg/https-
 everywhere/issues/1123#issuecomment-313064554

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

Re: [tor-bugs] #20611 [Core Tor/Tor]: Relays should log a message when they return a 503 error to a client

[Tor Bug Tracker & Wiki]

#20611: Relays should log a message when they return a 503 error to a client
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:  wontfix
 Keywords:  easy, tor-relay, logging  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


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

Re: [tor-bugs] #20611 [Core Tor/Tor]: Relays should log a message when they return a 503 error to a client

[Tor Bug Tracker & Wiki]

#20611: Relays should log a message when they return a 503 error to a client
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  easy, tor-relay, logging  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 "a relay operator"?

 Tor relays will return 503 when they're close to empty on their rate
 limiting, and they don't want to waste bytes on serving a directory object
 (that would be an asymmetric use of their last little bit of bandwidth
 anyway).

 I'm not at all convinced that we should have notice-level logs of whenever
 the relay decided it was low on bandwidth. That probably happens every so
 often for most relays, and the whole "503, back off" thing is a feature
 designed to help us tolerate these situations. Telling the operator is
 like asking the operator to do something about it, and that's exactly what
 we're trying to avoid with the whole design.

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

Re: [tor-bugs] #24698 [Applications/Tor Browser]: Torbrowser keeps hanging and freezing, plus it takes a very long time to load after hibernation

[Tor Bug Tracker & Wiki]

#24698: Torbrowser keeps hanging and freezing, plus it takes a very long time to
load after hibernation
--+---
 Reporter:  justmeee  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by teor):

 I used to see rare hangs like this in 7.0 on macOS, now with 7.5 I see
 them all the time. They usually happen after I have resumed my laptop or
 resumed a VM. Sometimes that happen immediately, sometimes they happen
 after the network gets restored.

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+
Changes (by isis):

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


Comment:

 tiny nitpick/note: The code from d8307cb0e99d28daa4011e4e9d94e3f8c56cba23
 and d8307cb0e99d28daa4011e4e9d94e3f8c56cba23 has an `unwrap()` in an FFI
 function, which if it were to `panic!()` [https://doc.rust-lang.org/book
 /first-edition/ffi.html#ffi-and-panics would be UB]. However, the
 `unwrap()` and potential `panic!()` is, I think, the same level of
 "unsafety" as writing `unsafe{}` and making a bug, given that the same
 checks are still in place and we're operating with the same set of
 assumptions.

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

Re: [tor-bugs] #24698 [Applications/Tor Browser]: Torbrowser keeps hanging and freezing, plus it takes a very long time to load after hibernation

[Tor Bug Tracker & Wiki]

#24698: Torbrowser keeps hanging and freezing, plus it takes a very long time to
load after hibernation
--+---
 Reporter:  justmeee  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by justmeee):

 i can't intentionally duplicate it... it would take a very long time to
 try and find the last version that didn't do this... the problems happen
 randomly...

 the issue where it takes a very, VERY long time to load would take less
 time, but i will have to get back to that when i have more time for all
 the installing, uninstalling and testing..


 i have, however, tried one additional trouble shooting method that i hope
 will help you track it down...

 i have tried having two windows open at the same time and leaving it that
 way... eventually, one will freeze/hang/etc, but the other will still work
 normally... i'm not able to grab tabs from the non-working window, and it
 has all the problems described earlier... so i have to close the
 non=working window... but i can still use the working one normally...

 so from there, after i close the frozen/broken window and start using the
 working one, i then open another window again eventually the same
 thing will happen

 again, when the bad window breaks, it's almost always upon waking from
 hibernation... and no matter what i do, they always take a very long time
 to load upon waking, more than 10 times longer than my other browsers...

 also, i tried the version 8 alpha and it froze much more quickly, so i
 downgraded it was a lot worse... so i have had to downgrade back to
 7.5...

 overall, comparing the past several versions, when it comes to the
 freezing/hanging/etc, the 7.5 is doing the best... it doesn't happen
 nearly as often... it happens, but like i said not nearly as often... the
 VERY slow load has not changed though...

 have i sent you a speccy during the loading process?... is that something
 that would help you diagnose the slow loading?..

 thank you very much...

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+

Comment (by isis):

 Replying to [comment:18 isis]:
 > Thanks! I'll rebase and make a new branch for the utilities to avoid
 this type of issue again.

 The ticket for this is #25185.

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

Re: [tor-bugs] #22214 [Core Tor/Tor]: When authority certificates expire, give a better error message

[Tor Bug Tracker & Wiki]

#22214: When authority certificates expire, give a better error message
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 You can search for the log message in the tor source code to learn which
 file it is from.
 Many people use the "grep" command to search files.

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

Re: [tor-bugs] #20611 [Core Tor/Tor]: Relays should log a message when they return a 503 error to a client

[Tor Bug Tracker & Wiki]

#20611: Relays should log a message when they return a 503 error to a client
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  easy, tor-relay, logging  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Tor's logging API is in torlog.h. It handles writing to all the log files
 for you. This log should probably be at the notice level. And it should be
 rate limited, see above,

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

Re: [tor-bugs] #15019 [Core Tor/Tor]: Most FooStatistics entries in the man page don't mention ExtraInfo descriptors

[Tor Bug Tracker & Wiki]

#15019: Most FooStatistics entries in the man page don't mention ExtraInfo
descriptors
+--
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay doc easy  |  Actual Points:
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Most of the statistics were properly documented in #15550.
 Only PaddingStatistics has been added since then, it goes in the extra
 info descriptor.

 Edit tor/doc/tor.1.txt to change the generated man page.

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

Re: [tor-bugs] #23633 [Core Tor/Tor]: Why does roflcopter have an empty protocol line in the consensus?

[Tor Bug Tracker & Wiki]

#23633: Why does roflcopter have an empty protocol line in the consensus?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 When we make proto lines mandatory in descriptors, we should reject
 descriptors with empty proto lines:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n776

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

Re: [tor-bugs] #24954 [Metrics/Website]: Metrics performance measurements use v2 onion services

[Tor Bug Tracker & Wiki]

#24954: Metrics performance measurements use v2 onion services
-+-
 Reporter:  teor |  Owner:  karsten
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Thanks for doing this patch, I haven't had much volunteer coding time
 lately.
 Looks fine to me.

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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  not a
 Keywords:  bsd, test, 032-backport, |  bug
  031-backport   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Just like macOS, it is likely that only some compilers and architectures
 fail this test on FreeBSD.

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

Re: [tor-bugs] #20218 [Core Tor/Tor]: Fix and refactor and redocument routerstatus_has_changed

[Tor Bug Tracker & Wiki]

#20218: Fix and refactor and redocument routerstatus_has_changed
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 029-proposed, tor-control, |  Actual Points:  0.5
  easy, spec-conformance, review-group-31|
Parent ID:   | Points:  .1
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:31 nickm]:
 > teor, I think you have tor_addr_compare backwards. Its documentation
 says:
 > {{{
 >  * Given two addresses addr1 and addr2, return 0 if the
 two
 >  * addresses are equivalent under the mask mbits, less than 0 if addr1
 >  * precedes addr2, and greater than 0 otherwise.
 > }}}
 >
 > So the original use of tor_addr_compare (without "!") is correct.

 You're right. Oops!

 > (Unit tests would have caught this bug; that's one reason why unit tests
 are so great. ;) Any chance of writing those?)

 I think we should have unit tests.

 > As a smaller issue, it seems that this patch says the same line twice:
 > {{{
 >  a->is_hs_dir != b->is_hs_dir ||
 >  a->is_hs_dir != b->is_hs_dir ||
 > }}}
 >
 > ---
 > Another question: how did you decide on the list of fields to check?  It
 seems that some but not all of the fields in routerstatus_t are now
 checked for equality, but I don't understand the rationale about why the
 remaining ones (pv, exitsummary) are not.  Is that intentional?

 We only check the fields that are output via the control port.
 We should revise this like to say "only" not "also":
 {{{
 /* Given two router status entries for the same router identity, return 1
 if
  * if the contents have changed between them. Otherwise, return 0.
  * It also checks for changes for that are output by control port. */
 }}}

 
https://github.com/ArunaMaurya221B/tor/commit/e29292dda5ef68e441f267864357a7568b29588e
 #diff-fcb162b79906521706b54d280b939d57R1540

 > ---
 >
 > Teor asks:
 > >  How can we make sure we update functions when we add new members to a
 struct?
 >
 > In some cases, using a constructor for a struct instance will work,
 since we have turned on the options that let us know about any
 uninitialized members.  But in cases like this, I don't see an easy way to
 use a constructor.
 >
 > One option here would be to stop assuming that we list all relevant the
 members here.  We could instead change the code that we only list the
 ''irrelevant'' members, by:
 >   1. Making sure that when we construct routerstatus_t, we initialize
 the whole object to 0.
 >   2. In a function like this, using memcpy() to make a temporary copy of
 the routerstatus_t.
 >   3. Instead of listing all the relevant members in a comparison, we
 could just use fast_memeq() to compare.  If there are some members we
 don't want to compare, we would set them to 0 before calling fast_memeq().
 > I'm not sure if this is actually a good idea, though.

 I think it is enough to comment the control port printing function, and
 this function, and say that they must be kept in sync.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25185 [Core Tor/Tor]: Create utilities for using Rust static strings in C

[Tor Bug Tracker & Wiki]

#25185: Create utilities for using Rust static strings in C
--+
 Reporter:  isis  |  Owner:  isis
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:  SponsorM  |
--+
 This is a continuation of #25127, to provide some utilities for working
 with static strings across the FFI boundary without accidentally
 introducing leaks.

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+

Comment (by isis):

 Thanks! I'll rebase and make a new branch for the utilities to avoid this
 type of issue again.

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

Re: [tor-bugs] #25071 [Core Tor/Tor]: Add a test-rust make target to the Makefile

[Tor Bug Tracker & Wiki]

#25071: Add a test-rust make target to the Makefile
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #25071 [Core Tor/Tor]: Add a test-rust make target to the Makefile

[Tor Bug Tracker & Wiki]

#25071: Add a test-rust make target to the Makefile
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


Comment:

 I've made a simple patch here: `tests_rust`.

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

Re: [tor-bugs] #24030 [Core Tor/Tor]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#24030: Wrap types in protover.rs
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged that; thanks, frewsxcv!

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

Re: [tor-bugs] #25067 [Core Tor/Tor]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#25067: Wrap types in protover.rs
--+
 Reporter:  frewsxcv  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 I've merged this with d9826b0a30f42754dc5764ce02c7b0271d996c92.  Please
 let me know if I messed anything up, especially surrounding the conflicts
 with #25127.  Thanks again for the patch!

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+

Comment (by nickm):

 I've merged isis's branch above, with a couple of small tweaks (see
 d8307cb0e99d28daa4011e4e9d94e3f8c56cba23 and
 af049657eb4426f4c1e7c8aa603c6303c9a884cf). Now I'll try to merge #25067.
 Let's iterate from there.

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

Re: [tor-bugs] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pospeselr):

 After a reboot (and the patch applied) this build issue for windows goes
 away.

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

Re: [tor-bugs] #25183 [Core Tor/Tor]: Implement a way to tell if an IP address is a known relay

[Tor Bug Tracker & Wiki]

#25183: Implement a way to tell if an IP address is a known relay
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 029-backport,|  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24902   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => accepted
 * owner:  nickm => dgoulet


Comment:

 Got a `lgtm` by nickm on IRC.

 So we'll make this part of #24902 so this is now merged in branch
 `ticket24902_029_05`.

 Going back in `accepted` and we'll close it once #24902 is closed and
 backported.

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

Re: [tor-bugs] #25067 [Core Tor/Tor]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#25067: Wrap types in protover.rs
--+
 Reporter:  frewsxcv  |  Owner:  (none)
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => merge_ready
 * milestone:   => Tor: 0.3.3.x-final


Comment:

 This looks good to me!  I'd like to merge it once we get a minimal fix for
 the issues of #25127.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25184 [Metrics/Consensus Health]: consensus health says that signatures are sha1, but they're actually sha256

[Tor Bug Tracker & Wiki]

#25184: consensus health says that signatures are sha1, but they're actually 
sha256
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I guess this was accidentally hard-coded somewhere?

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

Re: [tor-bugs] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt tor-dirauth pending-disaster  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 >  It's been 2 years since this ticket was opened, are there's any new
 flags we should also clear?

 Probably!

 > Do you think we should zero the struct, then copy across the fields we
 want to keep?
 > Or do you think that touching the entire struct is a bad idea?

 I think it's probably fine to do the zero-and-copy approach.

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

Re: [tor-bugs] #24854 [Core Tor/Tor]: Extract the authority list from config.c

[Tor Bug Tracker & Wiki]

#24854: Extract the authority list from config.c
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-dirauth, 029-backport,  |  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24818   | Points:  0.2
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * reviewer:   => teor


Comment:

 (teor, it sounds like you'd like me to mark you reviewer on this one.
 please let me know if that's not right.)

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

Re: [tor-bugs] #23873 [Core Tor/Tor]: Remove the return value of node_get_prim_orport()

[Tor Bug Tracker & Wiki]

#23873: Remove the return value of node_get_prim_orport()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  #24403  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Thanks, neel!  This patch looks correct to me.  Let's take it early in the
 0.3.4.x series.

 The only change that I would suggest is that the function documentation
 should say that callers should check whether the result is valid before
 using it.  Either you can make that change, or I'll do it when I merge;
 either way is fine with me.

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

Re: [tor-bugs] #4187 [Core Tor/Tor]: A verified unverified-consensus should be renamed to cached-consensus

[Tor Bug Tracker & Wiki]

#4187: A verified unverified-consensus should be renamed to cached-consensus
-+-
 Reporter:  anonym   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.33
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, directory, rename, fs,   |  Actual Points:
  easy, 032-unreached|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 This patch looks good to me!  Let's take it once the 0.3.4.x merge window
 is open.

 I think there could still be remaining cases where the file doesn't get
 renamed, but this one at least should get fixed.

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

Re: [tor-bugs] #25081 [Core Tor/Tor]: use get_uptime() consistently

[Tor Bug Tracker & Wiki]

#25081: use get_uptime() consistently
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 (when we merge it, we'll need to make "stats_n_seconds_working" be
 declared static in src/or/main.c.)

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

Re: [tor-bugs] #25081 [Core Tor/Tor]: use get_uptime() consistently

[Tor Bug Tracker & Wiki]

#25081: use get_uptime() consistently
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Patch lgtm. Thanks for writing it!  Let's merge this once the 0.3.4.x
 merge window is open (should be next 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] #24714 [Core Tor/Tor]: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable

[Tor Bug Tracker & Wiki]

#24714: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable
+
 Reporter:  arma|  Owner:  valentecaio
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me!  I'll merge it once the 0.3.4.x merge window opens.

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

Re: [tor-bugs] #20424 [Core Tor/Tor]: Remove --enable-openbsd-malloc (Tor maxes CPU when --enable-openbsd-malloc is used)

[Tor Bug Tracker & Wiki]

#20424: Remove --enable-openbsd-malloc (Tor maxes CPU when 
--enable-openbsd-malloc
is used)
-+
 Reporter:  icanhasaccount   |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:  nickm|Sponsor:
-+

Comment (by Hello71):

 I still need to test what happens when rust is linked in.

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

Re: [tor-bugs] #20424 [Core Tor/Tor]: Remove --enable-openbsd-malloc (Tor maxes CPU when --enable-openbsd-malloc is used)

[Tor Bug Tracker & Wiki]

#20424: Remove --enable-openbsd-malloc (Tor maxes CPU when 
--enable-openbsd-malloc
is used)
-+
 Reporter:  icanhasaccount   |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:  nickm|Sponsor:
-+

Comment (by Hello71):

 I wanted to put all of the allocator-related configure.ac code together. I
 tested at least one of the versions of the patches both with and without
 jemalloc installed, but I only tested on Linux. The plan was to remove
 openbsd malloc first. I see no benefit to using it over jemalloc.

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

Re: [tor-bugs] #25183 [Core Tor/Tor]: Implement a way to tell if an IP address is a known relay

[Tor Bug Tracker & Wiki]

#25183: Implement a way to tell if an IP address is a known relay
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 029-backport,|  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24902   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 I've written unit tests for both using `address_set_t` and the integration
 with the nodelist.

 Quick thing though, I've renamed `addressset.c` to `address_set.c` because
 that triple 's' was kind of intense and difficult to brain-parse on what
 it is exactly. Furthermore, the namespace for this file is `address_set_*`
 so that just makes sense I think.

 Branch: `ticket25183_029_01`

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 I'm ok with merging these patches as is if we open a new ticket to
 abstract the creation of string or byte literals that are more C-friendly.
 Getting Travis builds working again is important.

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

Re: [tor-bugs] #25171 [Core Tor/Tor]: Clarify 'recognized' field in tor-spec

[Tor Bug Tracker & Wiki]

#25171: Clarify 'recognized' field in tor-spec
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Very Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Trivial| Resolution:
 Keywords:  tor-spec, doc  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

 * status:  needs_revision => needs_review


Comment:

 Thanks, good point. Changed it to a 'MAY' clause with an explanation for
 why.

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

Re: [tor-bugs] #25183 [Core Tor/Tor]: Implement a way to tell if an IP address is a known relay

[Tor Bug Tracker & Wiki]

#25183: Implement a way to tell if an IP address is a known relay
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 029-backport,|  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24902   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I've added some "is this a known relay" code to that branch too.  Still
 needs tests though; dgoulet has offered to write them.

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

Re: [tor-bugs] #20218 [Core Tor/Tor]: Fix and refactor and redocument routerstatus_has_changed

[Tor Bug Tracker & Wiki]

#20218: Fix and refactor and redocument routerstatus_has_changed
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 029-proposed, tor-control, |  Actual Points:  0.5
  easy, spec-conformance, review-group-31|
Parent ID:   | Points:  .1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 teor, I think you have tor_addr_compare backwards. Its documentation says:
 {{{
  * Given two addresses addr1 and addr2, return 0 if the two
  * addresses are equivalent under the mask mbits, less than 0 if addr1
  * precedes addr2, and greater than 0 otherwise.
 }}}

 So the original use of tor_addr_compare (without "!") is correct.

 (Unit tests would have caught this bug; that's one reason why unit tests
 are so great. ;) Any chance of writing those?)

 As a smaller issue, it seems that this patch says the same line twice:
 {{{
  a->is_hs_dir != b->is_hs_dir ||
  a->is_hs_dir != b->is_hs_dir ||
 }}}

 ---
 Another question: how did you decide on the list of fields to check?  It
 seems that some but not all of the fields in routerstatus_t are now
 checked for equality, but I don't understand the rationale about why the
 remaining ones (pv, exitsummary) are not.  Is that intentional?

 ---

 Teor asks:
 >  How can we make sure we update functions when we add new members to a
 struct?

 In some cases, using a constructor for a struct instance will work, since
 we have turned on the options that let us know about any uninitialized
 members.  But in cases like this, I don't see an easy way to use a
 constructor.

 One option here would be to stop assuming that we list all relevant the
 members here.  We could instead change the code that we only list the
 ''irrelevant'' members, by:
   1. Making sure that when we construct routerstatus_t, we initialize the
 whole object to 0.
   2. In a function like this, using memcpy() to make a temporary copy of
 the routerstatus_t.
   3. Instead of listing all the relevant members in a comparison, we could
 just use fast_memeq() to compare.  If there are some members we don't want
 to compare, we would set them to 0 before calling fast_memeq().
 I'm not sure if this is actually a good idea, though.

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

Re: [tor-bugs] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

[Tor Bug Tracker & Wiki]

#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 The patch for metrics-web looks to be what I was expecting.

 Relay Search does not actually use the summary documents anymore, and
 instead only makes one fetch for the details document (instead of the
 summary document followed by n fetches of details documents).

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

Re: [tor-bugs] #25036 [Core Tor/Tor]: Tor 0.3.2 rejects connections to raw ipv6 addresses

[Tor Bug Tracker & Wiki]

#25036: Tor 0.3.2 rejects connections to raw ipv6 addresses
--+
 Reporter:  pastly|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression ipv6 032-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:16 arma]:
 > I think we should ignore the spec and do the right thing. The right
 thing is that if you get an address string that is usable as a destination
 address, you should use it.

 Usability, I agree and less hassle of broken apps opening tickets. Flip
 side, we let flourish an ecosystem of broken applications that uses SOCKS
 the wrong way and in this case, Tor Browser.

 But I won't argue more, I think TB knows what to do to do it right and
 "tor" can just be lenient with what format the address comes in (binary or
 text).

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

Re: [tor-bugs] #23653 [Core Tor/Tor]: When accessing onion service with no fetchable descriptor, Tor sits around until timeout rather than hanging up

[Tor Bug Tracker & Wiki]

#23653: When accessing onion service with no fetchable descriptor, Tor sits 
around
until timeout rather than hanging up
--+
 Reporter:  arma  |  Owner:  asn
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => assigned
 * cc: asn (removed)


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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  not a
 Keywords:  bsd, test, 032-backport, |  bug
  031-backport   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 Thanks to Riastradh on IRC, seems 0.3.2.9 and master are not failing on
 NetBSD.

 Lets consider this over and *not* merge the SKIP patch above. We can
 reopen if that comes back.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25183 [Core Tor/Tor]: Implement a way to tell if an IP address is a known relay

[Tor Bug Tracker & Wiki]

#25183: Implement a way to tell if an IP address is a known relay
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-relay, tor-dos, 029-backport,
 Severity:  Normal   |  031-backport, 032-backport
Actual Points:   |  Parent ID:  #24902
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 For the DoS mitigation subsystem (#24902), we need a way to lookup the
 connection address and *quickly* know if it is a known relay or not. This
 is also needed for #2667 which would prevent Exit to reenter the network.

 nickm has started a branch to have IP addresses with bloom filter:
 `address_set_029`.

 Next step is to use that and bridge it with the nodelist so we can lookup
 an IP address and learn if it is known or not (not get the `node_t` back,
 that would require more work and probably lose in performance).

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

Re: [tor-bugs] #24954 [Metrics/Website]: Metrics performance measurements use v2 onion services

[Tor Bug Tracker & Wiki]

#24954: Metrics performance measurements use v2 onion services
-+--
 Reporter:  teor |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-24954&id=a3dd5b4eba62f875dac934575ef671c63c4f5b10
 commit a3dd5b4 in my task-24954 branch]. I edited the two graph
 descriptions and the CSV file specification, but I'm not sure if the new
 text is too complex now. Want to take a look and possibly tweak that text?

 Regarding the data selection label, I'd like to leave that as is, at least
 as long as we're only measuring v2 onion services. Of course, if we start
 measuring v3 onion services, we should rename that label to "v2 onion" and
 create a new "v3 onion" label. We're not there yet, though.

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

Re: [tor-bugs] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-dos tor-hs performance  |  Actual Points:
Parent ID:  #14006  | Points:  3
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * parent:   => #14006


Comment:

 This is now very related to #14006 that is for client we do have
 `MaxClientCircuitsPending` so at worst they do a burst of 32 circuits.

 For HS, this can go much bigger with 5+ configured service. I suspect that
 if we can find a solution in #14006, this is resolved. Not flagging it as
 duplicate because maybe that circuit limit rate idea is still something we
 want for an overall client.

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

Re: [tor-bugs] #20424 [Core Tor/Tor]: Remove --enable-openbsd-malloc (Tor maxes CPU when --enable-openbsd-malloc is used)

[Tor Bug Tracker & Wiki]

#20424: Remove --enable-openbsd-malloc (Tor maxes CPU when 
--enable-openbsd-malloc
is used)
-+
 Reporter:  icanhasaccount   |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Low  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:  nickm|Sponsor:
-+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 (I'm guessing that the second patch should be applied _without_ the first,
 right?)

 I like this patch, but I'm not so sure about having jemalloc be the
 default right away.  Let's let people test it as an option before we
 decide it's the best choice for everyone. Also, if I'm reading the patch
 right, this code will break on Linux if jemalloc isn't installed, which
 probably isn't what you'd intended?

 Other questions:
   * Why move the mlockall check?
   * Why does the patch move dmalloc?  Have you tested this?  Does it work?
   * Where and how have you tested this patch?

 Other notes:
   * This will need a changes file, explaining to people how to use this
 feature.
   * We'll still want to remove the openbsd_malloc 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] #25096 [Core Tor/DirAuth]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

[Tor Bug Tracker & Wiki]

#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
--+--
 Reporter:  arma  |  Owner:  dgoulet
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #25096 [Core Tor/DirAuth]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

[Tor Bug Tracker & Wiki]

#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
--+---
 Reporter:  arma  |  Owner:  dgoulet
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dgoulet):

 * status:  accepted => needs_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] #25096 [Core Tor/DirAuth]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

[Tor Bug Tracker & Wiki]

#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
--+--
 Reporter:  arma  |  Owner:  dgoulet
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * status:  new => accepted
 * cc: dgoulet (removed)
 * component:  Core Tor/Tor => Core Tor/DirAuth
 * milestone:  Tor: 0.3.3.x-final =>
 * owner:  (none) => dgoulet
 * type:  defect => task


Comment:

 Ok so this is a change in the dirauth-conf repository, nothing on the tor
 side afaict.

 Usually with consensus parameter change like that, I like to inform the
 dirauth list about the rationale.

 In the name of safety, what about ramping up to 200 by going through 150
 before? And we'll see how that goes with our relay stats or if someone
 does hack a client to checks delays on v2 onion vs v3 onion? And we can
 progressively ramp up more and more if we see that it helps. There is also
 an argument here to try to be more loud publicly about v3 adoption
 considering that we start squeezing out v2...

 If we have consensus, I can do the push and email.

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

Re: [tor-bugs] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

[Tor Bug Tracker & Wiki]

#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-24494&id=81c72b0531ecc474bfc92afcb62e4fb78348d2d8
 commit 81c72b0 in my Onionoo task-24494 branch] and
 [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-24494&id=d2178c350256563cb72d6c802be6285d8c2b5d7c
 commit d2178c3 in my metrics-web task-24494 branch]. Yet untested, except
 for unit tests.

 irl, if these reviews go through, you can safely assume that nickname will
 always be present for Relay Search. In fact, you can already do that for
 details documents, just not for summary documents. But feel free to wait
 for this change and new protocol version 5.1 to be deployed.

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

Re: [tor-bugs] #25182 [Core Tor/Tor]: systemd unit file starts Tor before IPv6 address is available

[Tor Bug Tracker & Wiki]

#25182: systemd unit file starts Tor before IPv6 address is available
--+
 Reporter:  sjmurdoch |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sjmurdoch):

 Replying to [comment:1 cypherpunks]:
 > Do you use these packages:
 > https://deb.torproject.org/torproject.org/dists/tor-
 experimental-0.3.3.x-xenial/

 Yes, I did.

 > They don't ship the same systemd service file as in upstream tor, so
 this might be the wrong component to report this.

 What would be the correct component? I found RPM packaging but not for
 Debian.

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

Re: [tor-bugs] #21961 [Applications/Tor Browser]: should torbrowser enable network.IDN_show_punycode by default?

[Tor Bug Tracker & Wiki]

#21961: should torbrowser enable network.IDN_show_punycode by default?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by y2875095):

 * severity:  Normal => Major


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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+---
 Reporter:  asn|  Owner:  asn
 Type:  defect | Status:
   |  needs_information
 Priority:  Immediate  |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Blocker| Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorV
---+---

Comment (by cypherpunks):

 Replying to [comment:69 asn]:
 > Hello, do you guys have any info logs for these issues by any chance?
 That would be really useful!

 {{{
 [notice] Your system clock just jumped 3902 seconds forward; assuming
 established circuits no longer work.
 [notice] Tried for 3915 seconds to get a connection to [scrubbed]:9878.
 Giving up. (waiting for rendezvous desc)
 [notice] Tried for 3915 seconds to get a connection to [scrubbed]:9878.
 Giving up. (waiting for rendezvous desc)
 [notice] Delaying directory fetches: No running bridges
 }}}

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

Re: [tor-bugs] #25180 [Applications/Tor Browser]: Protect against Referer Tracking in Tor Browser

[Tor Bug Tracker & Wiki]

#25180: Protect against Referer Tracking in Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Seems like it would break out a lot of websites.

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

Re: [tor-bugs] #21961 [Applications/Tor Browser]: should torbrowser enable network.IDN_show_punycode by default?

[Tor Bug Tracker & Wiki]

#21961: should torbrowser enable network.IDN_show_punycode by default?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by y2875095):

 TBB should prevent phishing.

 Browsers should format address bar like:
 https://www.xn--e1awd7f.com/ (displayed as: epic.com)

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

Re: [tor-bugs] #25037 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#25037: Add press clips to website
--+--
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kat5):

 * status:  new => needs_review


Comment:

 This should be ready to merge:
 !https://gitweb.torproject.org/user/kat/webwml.git/commit/?h=press-
 updates-20180208

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25037#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25181 [Applications/Tor Browser]: Protect against Referer Tracking in Tor Browser

[Tor Bug Tracker & Wiki]

#25181: Protect against Referer Tracking in Tor Browser
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate of #25180.

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

Re: [tor-bugs] #25182 [Core Tor/Tor]: systemd unit file starts Tor before IPv6 address is available

[Tor Bug Tracker & Wiki]

#25182: systemd unit file starts Tor before IPv6 address is available
--+
 Reporter:  sjmurdoch |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 another possible workaround:
 net.ipv6.ip_nonlocal_bind

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

Re: [tor-bugs] #25174 [Core Tor/Tor]: Update to February GeoIP2 database

[Tor Bug Tracker & Wiki]

#25174: Update to February GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-relay 025-backport|  implemented
  026-backport 027-backport 028-backport |  Actual Points:
  029-backport 030-backport 031-backport |
  032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to 0.2.5 and forward.  Thanks, Karsten!

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

Re: [tor-bugs] #25170 [Core Tor/Tor]: explicitly mention email address to contact for rejected relays

[Tor Bug Tracker & Wiki]

#25170: explicitly mention email address to contact for rejected relays
--+
 Reporter:  cypherpunks   |  Owner:  dgoulet
 Type:  enhancement   | Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 lgtm; 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] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bsd, test, 032-backport, |  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #25182 [Core Tor/Tor]: systemd unit file starts Tor before IPv6 address is available

[Tor Bug Tracker & Wiki]

#25182: systemd unit file starts Tor before IPv6 address is available
--+
 Reporter:  sjmurdoch |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Do you use these packages:
 https://deb.torproject.org/torproject.org/dists/tor-
 experimental-0.3.3.x-xenial/

 They don't ship the same systemd service file as in upstream tor, so this
 might be the wrong component to report this.

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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bsd, test, 032-backport, |  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => accepted
 * owner:  (none) => dgoulet


Comment:

 Here is a SKIP patch (can't test it though :S...) so we can move forward.
 Maybe someday we have a NetBSD pro to fix this... who knows.

 Based on 031 for backport: `bug23250_031_01`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25182 [Core Tor/Tor]: systemd unit file starts Tor before IPv6 address is available

[Tor Bug Tracker & Wiki]

#25182: systemd unit file starts Tor before IPv6 address is available
--+
 Reporter:  sjmurdoch |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 On Ubuntu xenial, systemd starts Tor before the IPv6 address is available
 and so Tor fails to assign an IPv6 address then exits. systemd tries to
 restart Tor (I think three times) but even by the last time there's still
 no IPv6 address assigned and hence Tor fails to start.

 As a work-around I added `RestartSec=10` to the systemd unit file to slow
 down the restart such that by the second time tor starts, there is an IPv6
 address available.

 See log file below.

 {{{
 Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor
 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent
 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
 .0alpha, and Libzstd N/A.
 Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't
 help you if you use it wrong! Learn how to be safe at
 https://www.torproject.org/download/download#warning
 Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This
 version is not a stable Tor release. Expect more bugs than usual.
 Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read
 configuration file "/usr/share/tor/tor-service-defaults-torrc".
 Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read
 configuration file "/etc/tor/torrc".
 Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on
 detected system memory, MaxMemInQueues is set to 8192 MB. You can override
 this by setting MaxMemInQueues by hand.
 Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor
 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent
 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
 .0alpha, and Libzstd N/A.
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't
 help you if you use it wrong! Learn how to be safe at
 https://www.torproject.org/download/download#warning
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This
 version is not a stable Tor release. Expect more bugs than usual.
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read
 configuration file "/usr/share/tor/tor-service-defaults-torrc".
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read
 configuration file "/etc/tor/torrc".
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on
 detected system memory, MaxMemInQueues is set to 8192 MB. You can override
 this by setting MaxMemInQueues by hand.
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler
 type KIST has been enabled.
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening
 Socks listener on 127.0.0.1:9050
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR
 listener on 0.0.0.0:9001
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR
 listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not
 bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested
 address
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening
 Directory listener on 0.0.0.0:9030
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing
 partially-constructed Socks listener on 127.0.0.1:9050
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing
 partially-constructed OR listener on 0.0.0.0:9001
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing
 partially-constructed Directory listener on 0.0.0.0:9030
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to
 parse/validate config: Failed to bind one of the listener ports.
 Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading
 config failed--see warnings above.
 Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process
 exited, code=exited, status=1/FAILURE
 -- Subject: Unit tor@default.service has failed
 -- Unit tor@default.service has failed.
 Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered
 failed state.
 Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with
 result 'exit-code'.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bug

[tor-bugs] #25181 [Applications/Tor Browser]: Protect against Referer Tracking in Tor Browser

[Tor Bug Tracker & Wiki]

#25181: Protect against Referer Tracking in Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In about:config, set
 network.http.referer.XOriginPolicy = 2
 to better protect against referer tracking in Tor Browser.

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

Re: [tor-bugs] #25179 [Applications/Tor Browser]: identity leakage, resolution

[Tor Bug Tracker & Wiki]

#25179: identity leakage, resolution
--+--
 Reporter:  y2875095  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:  tbb-team  |Sponsor:
--+--
Changes (by y2875095):

 * owner:  (none) => tbb-team
 * keywords:  browswer, security => tbb-security
 * component:  - Select a component => Applications/Tor Browser
 * reviewer:   => tbb-team


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25180 [Applications/Tor Browser]: Protect against Referer Tracking in Tor Browser

[Tor Bug Tracker & Wiki]

#25180: Protect against Referer Tracking in Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In about:config, set
 network.http.referer.XOriginPolicy = 2
 to better protect against referer tracking in Tor Browser.

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

Re: [tor-bugs] #25178 [Applications/Tor Browser]: Running 'make testbuild' does not build the windows-x86_64 version

[Tor Bug Tracker & Wiki]

#25178: Running 'make testbuild' does not build the windows-x86_64 version
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 Since the only case where we want to disable the windows-x86_64 build is
 when we have `--target release`, we can replace the `var/torbrowser-
 windows-x86_64` condition with `! c("var/release")`.

 I pushed a patch doing that in branch `bug_25178`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25178&id=707cf3d03024780124ab9cda854244ca2ffbccaf

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25179 [- Select a component]: identity leakage, resolution

[Tor Bug Tracker & Wiki]

#25179: identity leakage, resolution
--+
 Reporter:  y2875095  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Critical  |   Keywords:  browswer, security
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor browser is right about possible identity leak via resolution (plugins
 and such)

 but...

 Setting browser to custom resolution will give even MORE INFO!


 Use most popular resolution (less indentifying information), not most
 custom one (most precise identification)...

 Tor browser should send fake resolution every time...



 You don't walk with custom costume when you want to hide yourself...

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

Re: [tor-bugs] #25170 [Core Tor/Tor]: explicitly mention email address to contact for rejected relays

[Tor Bug Tracker & Wiki]

#25170: explicitly mention email address to contact for rejected relays
--+
 Reporter:  cypherpunks   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #25170 [Core Tor/Tor]: explicitly mention email address to contact for rejected relays

[Tor Bug Tracker & Wiki]

#25170: explicitly mention email address to contact for rejected relays
--+
 Reporter:  cypherpunks   |  Owner:  dgoulet
 Type:  enhancement   | Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * owner:  (none) => dgoulet
 * status:  new => accepted
 * milestone:  Tor: 0.3.4.x-final => Tor: 0.3.3.x-final


Comment:

 See branch: `ticket25170_033_01`

 I did the new message for both when a fingerprint or an address is marked
 as rejected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25178 [Applications/Tor Browser]: Running 'make testbuild' does not build the windows-x86_64 version

[Tor Bug Tracker & Wiki]

#25178: Running 'make testbuild' does not build the windows-x86_64 version
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When running `make testbuild` we don't build anymore the Window 64
 version.

 I think this is caused by the change from commit
 dc51005d4944d6be9ca1c06331c3f9ee1cee51fc:
 {{{
 diff --git a/projects/release/config b/projects/release/config
 index e53ea43..f0d95c7 100644
 --- a/projects/release/config
 +++ b/projects/release/config
 @@ -29,7 +29,7 @@ targets:
torbrowser-windows-i686: 1
torbrowser-windows-x86_64:
  var:
 -  torbrowser-windows-x86_64: 1
 +  torbrowser-windows-x86_64: '[% c("var/alpha") || c("var/nightly")
 %]'
torbrowser-osx-x86_64:
  var:
torbrowser-osx-x86_64: 1
 }}}

 The `testbuild` build is started with:
 {{{
 $(rbm) build release --target testbuild --target torbrowser-all
 }}}

 At this point (in projects/release), `var/alpha` or `var/nightly` is not
 yet set, so `var/torbrowser-windows-x86_64` is false.

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

Re: [tor-bugs] #23650 [Core Tor/Tor]: Tor source code has many typos

[Tor Bug Tracker & Wiki]

#23650: Tor source code has many typos
---+
 Reporter:  cypherpunks|  Owner:  arma
 Type:  defect | Status:  closed
 Priority:  Very Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Trivial| Resolution:  fixed
 Keywords:  easy, review-group-31  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by fristonio):

 Thanks for merging, I am looking forward to contribute 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

Re: [tor-bugs] #24459 [Webpages/Website]: Update references to Atlas, Compass and Globe

[Tor Bug Tracker & Wiki]

#24459: Update references to Atlas, Compass and Globe
--+
 Reporter:  t0wer |  Owner:  irl
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by irl):

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


Comment:

 This was merged.

 
https://gitweb.torproject.org/project/web/webwml.git/commit/?id=8fa5262a79d473476b820bacd6c43014e2bc6db3

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

Re: [tor-bugs] #24494 [Metrics/Onionoo]: Specification says nickname is optional in documents but it's always there

[Tor Bug Tracker & Wiki]

#24494: Specification says nickname is optional in documents but it's always 
there
-+--
 Reporter:  irl  |  Owner:  karsten
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Don't assume it just yet. But I'll take that question as a request and
 will try to make it so.

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

Re: [tor-bugs] #22423 [Metrics/Website]: Refactor R code to use modern R packages and methods (was: Refactor plot_networksize() to use modern R packages and methods)

[Tor Bug Tracker & Wiki]

#22423: Refactor R code to use modern R packages and methods
+--
 Reporter:  johnbwilliams   |  Owner:  karsten
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/Website |Version:
 Severity:  Minor   | Resolution:
 Keywords:  plot_networksize()  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

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


Comment:

 I'll pick this up and extend it to all R code we have, after writing
 [https://gitweb.torproject.org/metrics-
 web.git/tree/src/main/R/rserver/graphs.R#n1215 more recent R code] with
 help of `dplyr` and `tidyr`.

 johnbwilliams, if you're still around, maybe you'd like to review the
 changes?

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