Re: [tor-bugs] #26487 [Applications/Tor Browser]: When I click the onion next to the .onion once it works, when I click it again after the new circuit panel is gone, nothing happens

[Tor Bug Tracker & Wiki]

#26487: When I click the onion next to the .onion once it works, when I click it
again after the new circuit panel is gone, nothing happens
--+--
 Reporter:  Dbryrtfbcbhgf |  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 Dbryrtfbcbhgf):

 gk, after running mozregression, I found this patch that seams to fix the
 issue.

  9:00.76 INFO: Last good revision:
 d8d0222927b44d384e9caef796ee52372050659e
  9:00.76 INFO: First bad revision:
 c2daa4c032b7f23a708a89237940ac8c49bba6cf
 https://hg.mozilla.org/mozilla-
 
central/pushloghtml?fromchange=d8d0222927b44d384e9caef796ee52372050659e=c2daa4c032b7f23a708a89237940ac8c49bba6cf

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

Re: [tor-bugs] #17873 [Core Tor/Tor]: replacing 0.0.0.0 listeners at runtime fails

[Tor Bug Tracker & Wiki]

#17873: replacing 0.0.0.0 listeners at runtime fails
+--
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-client port bind switching  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  ahf |Sponsor:
+--

Comment (by teor):

 ahf, are you waiting for me on this ticket?

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

Re: [tor-bugs] #25935 [Core Tor/Tor]: Allow DA address to be specified as FQDN

[Tor Bug Tracker & Wiki]

#25935: Allow DA address to be specified as FQDN
--+
 Reporter:  somlo |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

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


Comment:

 We'll implement #26488 instead,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26488 [Core Tor/Tor]: Stop resolving hard-coded authority DNS names that start with a digit

[Tor Bug Tracker & Wiki]

#26488: Stop resolving hard-coded authority DNS names that start with a digit
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-dirauth, security-low
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Instead, we should:
 * require IP addresses for authorities in the public network
 * allow any DNS name for non-default authorities or in test networks

 See #25935 and https://github.com/torproject/tor/pull/59 for background.

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

Re: [tor-bugs] #25999 [Core Tor/Stem]: Build an abstraction layer over different consensus flavours

[Tor Bug Tracker & Wiki]

#25999: Build an abstraction layer over different consensus flavours
---+---
 Reporter:  teor   |  Owner:  atagar
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:1 atagar]:
 > Hi teor. I'm a little unclear, are you asking for the consensus class to
 call controller methods to fetch microdescritpors?

 No, I'm asking for Stem (or Tor) to provide a class that abstracts over
 the differences between ns consensuses, full relay descriptors, microdesc
 consensuses, and microdescriptors.

 The class should be generic, so it can take a stem.descriptor.remote
 instance, or a controller, or a list of directory document objects (or
 maybe even a data directory?).

 For example, when I ask this class for a relay's IPv6 address:
 * if there is a ns consensus containing that relay, use that IPv6 address,
 or
 * if there is a microdesc consensus containing that relay, and the
 consensus method is 27 or later, use that IPv6 address, or
 * if there is a full descriptor for that relay, use that IPv6 address, or
 * if there is a microdescriptor for that relay, and the consensus method
 is 27 or earlier, use that IPv6 address.

 IPv6 is one of the most complicated cases, because it moved between
 directory documents.

 Here's a simpler example:

 If I ask this class for a relay's ed25519 id:
 * if there is a ns consensus containing that relay, use that ed25519 id,
 or
 * if there is a full descriptor for that relay, use that ed25519 id, or
 * if there is a microdescriptor for that relay, use that ed25519 id.

 > The proper solution I suspect is for tor to provide two controller
 methods so it's unambiguous what kind of consensus the caller gets.

 That's a good idea, but it doesn't solve the problem on clients, which
 only have one type of consensus. And it doesn't solve the general issue,
 which is that people need to know where relay attributes are located
 before they can write correct stem 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] #25461 [Core Tor/Tor]: main event-loop spins consuming 100% of a CPU core at times

[Tor Bug Tracker & Wiki]

#25461: main event-loop spins consuming 100% of a CPU core at times
-+-
 Reporter:  Dhalgren |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  performance, 034-roadmap-subtask,|  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #25500   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:12 Dhalgren]:
 > seeing CPU saturation today with 0.3.4.1-alpha
 >
 > removed all `tc` police rules with no effect, so not the comment:5
 theory
 >
 > TAP handshakes skyrocketed and perhaps it's all TAP handshake CPU
 consmption

 We can adjust this on a network-wide basis using NumNTorsPerTAP, but
 there's no torrc option for individual relays.

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

Re: [tor-bugs] #4363 [Core Tor/Tor]: Dirauths should save a copy of a consensus that didn't get enough signatures

[Tor Bug Tracker & Wiki]

#4363: Dirauths should save a copy of a consensus that didn't get enough
signatures
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth auditability save dump   |  Actual Points:
  033-backport-maybe 034-backport-maybe  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-dirauth auditability save dump =>
 tor-dirauth auditability save dump 033-backport-maybe 034-backport-
 maybe


Comment:

 #4539 makes authorities write mismatching signatures to disk, it isn't as
 useful as the consensus, but we might want to fix it in the same release.

 Also, I wonder if we want to backport this patch?
 (All noj

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

Re: [tor-bugs] #4363 [Core Tor/Tor]: Dirauths should save a copy of a consensus that didn't get enough signatures

[Tor Bug Tracker & Wiki]

#4363: Dirauths should save a copy of a consensus that didn't get enough
signatures
+--
 Reporter:  Sebastian   |  Owner:  (none)
 Type:  enhancement | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-dirauth auditability save dump  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by teor):

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


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

Re: [tor-bugs] #26486 [Applications/Tor Browser]: Grey out DNT options so the user can't disable it by accident

[Tor Bug Tracker & Wiki]

#26486: Grey out DNT options so the user can't disable it by accident
--+--
 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):

 related(but this ticket is old):
 https://trac.torproject.org/projects/tor/ticket/7921

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:44 s7r]:
 > Now I have over 1000. I am attaching a print screen that will speak for
 itself how annoying and abnormal this is.

 It has been occurring at faster rates on most of my (large) Guard and Exit
 relays since at least 2017.

 > I am willing to run any customized branch to fix this.

 We could downgrade it to a protocol warning. That's a simple patch, which
 is better than downgrading it to info level.

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

Re: [tor-bugs] #26486 [Applications/Tor Browser]: Grey out DNT options so the user can't disable it by accident

[Tor Bug Tracker & Wiki]

#26486: Grey out DNT options so the user can't disable it by accident
--+--
 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):

 >  TB devs have been (rightly) always opposed to enabling meaningless
 wastes of bytes such as DNT.

 But DNT is already enabled in Tor Browser 7.x.
 Are you saying DNT will be turned off(like default Mozilla Firefox) in the
 next version?

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

Re: [tor-bugs] #24546 [Core Tor/Tor]: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses

[Tor Bug Tracker & Wiki]

#24546: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4
addresses
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, ipv6,   |  Actual Points:
  033-triage-20180320, 033-removed-20180320  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

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


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

Re: [tor-bugs] #26460 [Core Tor/Tor]: Some? autoconf tests that include stdio.h fail with a missing ssp.h on cygwin

[Tor Bug Tracker & Wiki]

#26460: Some? autoconf tests that include stdio.h fail with a missing ssp.h on
cygwin
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 033-backport  |  Actual Points:
Parent ID:  #26356| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:4 nickm]:
 >  Is this new with 0.3.3, or did 0.3.2 have the same issue?

 Apparently 0.3.2 worked, but I want to confirm it's not a compiler upgrade
 issue:

 https://trac.torproject.org/projects/tor/ticket/26356#comment:7

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

Re: [tor-bugs] #26487 [Applications/Tor Browser]: When I click the onion next to the .onion once it works, when I click it again after the new circuit panel is gone, nothing happens

[Tor Bug Tracker & Wiki]

#26487: When I click the onion next to the .onion once it works, when I click it
again after the new circuit panel is gone, nothing happens
--+--
 Reporter:  Dbryrtfbcbhgf |  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:
--+--
Changes (by Dbryrtfbcbhgf):

 * Attachment "bug.mov" added.


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

[tor-bugs] #26487 [Applications/Tor Browser]: When I click the onion next to the .onion once it works, when I click it again after the new circuit panel is gone, nothing happens

[Tor Bug Tracker & Wiki]

#26487: When I click the onion next to the .onion once it works, when I click it
again after the new circuit panel is gone, nothing happens
--+--
 Reporter:  Dbryrtfbcbhgf |  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:|
--+--
 When I click the onion next to the .onion once it works, when I click it
 again after the new circuit panel is gone, nothing happens. I attached a
 video showing that nothing happens when I click the icon, I'm running
 macOS and TorBrowser 8.0a9
 Version of macOS encrypted with gk's PGP key

 -BEGIN PGP MESSAGE-

 hQIMA1d4Bx7i3mdbARAA43GBSo0gPTGzD1fKUu3PUIkcMeILp/OFybNw5N5ivzoi
 NU51/nIEYOPvBuL+T18UITLpB+XiARACKHq1HfBat7x0ZBCHA8tiCbGNwOXRkZpS
 gtWIyfgFIatXcUbdQycZtwMJY9p9BXrTwvzhoUziVPpRnvEypkAvNdEBQFHzSSuC
 aJMt4K0X5i3bKWssjGj5kAg91SwY7dE6fTBfvN1uG46A46PsOvwcKS4LkySWOPBX
 epvcmddho5gDQx48uDwHmvcFb9baa3YUsqTOe1Qrx/eur/zEfiTZKYfUHxpYvGjx
 pFwJA0g0iCQd82MXnv0Sihzp7J2wMcVYtnkethjN2CHKtwzoUEl9JQ5Kn4HLVTyD
 l5zNTcnnSYQlyCDIBfffXCwfDfiRrke3Fkls0zczpKzXHFH7CJmGvFMF/ProZRft
 uncU+DOw4nw6j8igz4zV+WGzAaQC/SIO0E8lzK49gEvrreWg4BM3gvF4b2MCX1J+
 vy6XX7lNveXitwuU6SWj9nfv35MJsGiXblC67tqmVJqBcfdszG+gB2A/rSVeavnI
 BgrlcDGhqHpa8+1BRBxaAa4G1sQdZsgO1D9pv3yyzVFvviby9TiVZv/AEhCRQlQu
 V42kqWMRiHCZTRrzrFw/Enwv3FuKOKw7yPmOJrD/vEoRGsBdPzp6szgzHL/Pou7S
 hgH4CG1CTX2TVrlKU8avUtkPHqkbdOEQIkI5nP5NkgfEJe4cD51I6ydL6EUGhFdJ
 qeTDXnogV0Tn5DArOhZm90h713r6sUumAMXIxK52tnsuLKI6LerRT7H9OEjYocwE
 7ffWFTRUywHsfOvAVJz6wQxpL/h4n8FTl4zrdHEeST+/AhF8T9vW
 =kQOp
 -END PGP MESSAGE-

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

Re: [tor-bugs] #26356 [Core Tor/Tor]: Tor 0.3.3.6 fails to compile under cygwin (x86_64)

[Tor Bug Tracker & Wiki]

#26356: Tor 0.3.3.6 fails to compile under cygwin (x86_64)
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:6 nickm]:
 > Is this new with 0.3.3, or did 0.3.2 have the same issue?

 Apparently it's new with 0.3.3, and 0.3.2 worked:

 > I try to build latest tor 0.3.3.6 from source under "x86_64 Cygwin".
 > Earlier versions did compile, I'm running now "Tor version 0.3.2.9 (git-
 9e8b762fcecfece6)."

 But I'm wondering if a compiler upgrade could have caused this issue.

 rolex0815, have you tried compiling 0.3.2 with your current Cygwin
 environment?

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

Re: [tor-bugs] #26486 [Applications/Tor Browser]: Grey out DNT options so the user can't disable it by accident

[Tor Bug Tracker & Wiki]

#26486: Grey out DNT options so the user can't disable it by accident
--+--
 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):

 > You need to lock "Send websites a “Do Not Track” signal that you don’t
 want to be tracked" option to "Always".

 Maybe just a typo from your part but TB devs have been (rightly) always
 opposed to enabling meaningless wastes of bytes such as DNT.

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

Re: [tor-bugs] #8494 [Core Tor/Tor]: Document MaxAdvertisedBandwidth in the bandwidth list spec

[Tor Bug Tracker & Wiki]

#8494: Document MaxAdvertisedBandwidth in the bandwidth list spec
-+-
 Reporter:  alphawolf|  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:19 juga]:
 > Collecting all commented lines and including the examples, we would
 have:
 >
 > Bandwidth generators MUST limit the relays' measured bandwidth based
 on the MaxAdvertisedBadwidth.
 > A relay's MaxAdvertisedBandwidth limits the bandwidth-avg in its
 descriptor. bandwidth-avg is the minimum of MaxAdvertisedBandwidth,
 BandwidthRate, RelayBandwidthRate, BandwidthBurst, and
 RelayBandwidthBurst.
 > Therefore, generators MUST limit a relay's measured bandwidth to its
 descriptor's bandwidth-avg. This limit needs to be implemented in the
 generator, because generators may scale consensus weights before sending
 them to Tor.
 > Generators SHOULD NOT limit measured bandwidths based on
 descriptors' bandwidth-observed, because that penalises new relays.
 >
 > sbws limits the relay's measured bandwidth to the bandwidth-avg
 advertised.
 >
 > Torflow partitions relays based on their bandwidth. For unmeasured
 relays, Torflow uses the minimum of all descriptor bandwidths, including
 bandwidth-avg (MaxAdvertisedBandwidth) and bandwidth-observed. Then
 Torflow measures the relays in each partition against each other, which
 implicitly limits a relay's measured bandwidth to the bandwidths of
 similar relays.
 >
 > Torflow also generates consensus weights based on the ratio between
 the measured bandwidth and the minimum of all descriptor bandwidths (at
 the time of the measurement). So when an operator reduces the
 MaxAdvertisedBandwidth for a relay, Torflow reduces that relay's measured
 bandwidth.
 >
 > > What do you think about these subsections?
 > >
 > > > > No Zero Bandwidths
 > > > > Bandwidth Aggregation
 > > > > Bandwidth Scaling
 > > > > MaxAdvertisedBandwidth
 >
 > Sounds good, just not sure how you have in mind to include them.
 > A possibility would be:
 >
 >   "bw=" Bandwidth
 >
 > [Exactly once.]
 >
 > The measured bandwidth of this relay.
 >
 > No Zero Bandwidths:
 > Tor accepts zero bandwidths, but they trigger bugs in older Tor
 > implementations. Therefore, implementations SHOULD NOT produce zero
 > bandwidths. Instead, they SHOULD use one as their minimum bandwidth.
 > If there are zero bandwidths, the parser MAY ignore them.
 >
 > Bandwidth Aggregation:
 > Multiple measurements can be aggregated using an averaging scheme,
 > such as a mean, median, or decaying average.
 >
 > Bandwidth Scaling:
 > Torflow scales bandwidths to kilobytes per second. Other
 > implementations SHOULD use kilobytes per second for their initial
 > bandwidth scaling.
 >
 > If different implementations or configurations are used in votes for
 > the same network, their measurements MAY need further scaling. See
 > Appendix B for information about scaling, and one possible scaling
 > method.
 >
 > MaxAdvertisedBandwidth:
 > Bandwidth generators MUST limit the relays' measured bandwidth based
 > on the MaxAdvertisedBadwidth. See Appendix C for more information.
 >
 > [...]
 >
 > C. MaxAdvertisedBandwidth
 >
 > [The text above without 1st sentence]
 >
 > Does this sounds good?

 The sections look good.

 But I'm not sure about the appendix. Appendixes are used for extra
 information. We put important MUSTs and SHOULD NOTs in the main text, so
 people don't miss them.

 We could put the explanation of bandwidth-avg in an apprendix, but it's
 only one sentence.

 If you want to make the MaxAdvertisedBandwidth section shorter, you can
 put the sbws and torflow examples in sections 2.4.1 and 2.4.2.

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

[tor-bugs] #26486 [Applications/Tor Browser]: Grey out DNT options so the user can't disable it by accident

[Tor Bug Tracker & Wiki]

#26486: Grey out DNT options so the user can't disable it by accident
--+--
 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:
--+--
 TBB 8 (60) series

 You need to lock "Send websites a “Do Not Track” signal that you don’t
 want to be tracked" option to "Always".

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

Re: [tor-bugs] #26486 [Applications/Tor Browser]: Grey out DNT options so the user can't disable it by accident

[Tor Bug Tracker & Wiki]

#26486: Grey out DNT options so the user can't disable it by accident
--+--
 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:|
--+--
Changes (by cypherpunks):

 * Attachment "dnt.jpg" added.

 DNT

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

Re: [tor-bugs] #26478 [Core Tor/Tor]: Unify bandwidth related terms in dir-spec and Tor code.

[Tor Bug Tracker & Wiki]

#26478: Unify bandwidth related terms in dir-spec and Tor code.
--+--
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth, 035-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:  tor-bwauth => tor-bwauth, 035-proposed
 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #26225 [Core Tor/Stem]: Jenkins test failure: test_get_microdescriptors - test may be unreliable

[Tor Bug Tracker & Wiki]

#26225: Jenkins test failure: test_get_microdescriptors - test may be unreliable
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  testing|  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Dave! 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

[tor-bugs] #26485 [Core Tor/DirAuth]: June mystery: the microdesc consensus is getting 9 sigs, but the ns consensus is getting only 5

[Tor Bug Tracker & Wiki]

#26485: June mystery: the microdesc consensus is getting 9 sigs, but the ns
consensus is getting only 5
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Lately (in the past few days) the dir auths are not getting all 9
 signatures on the same document. Frequently we're getting 5 that sign one
 and 4 that sign a different one.

 Some more digging shows that it's the ns consensus that they're
 disagreeing about, and the microdesc consensus is actually doing fine:
 {{{
 Jun 24 18:00:00.337 [info] A consensus needs 5 good signatures from
 recognized authorities for us to accept it. This ns one has 6 (dannenberg
 longclaw bastet moria1 dizum Faravahar). 3 (tor26 maatuska gabelmoo) of
 the authorities we know didn't sign it.
 Jun 24 18:00:00.538 [info] A consensus needs 5 good signatures from
 recognized authorities for us to accept it. This ns one has 6 (dannenberg
 longclaw bastet moria1 dizum Faravahar). 3 (tor26 maatuska gabelmoo) of
 the authorities we know didn't sign it.
 Jun 24 18:00:00.643 [info] A consensus needs 5 good signatures from
 recognized authorities for us to accept it. This microdesc one has 9
 (dannenberg tor26 longclaw bastet maatuska moria1 dizum gabelmoo
 Faravahar).
 Jun 24 18:00:00.871 [info] A consensus needs 5 good signatures from
 recognized authorities for us to accept it. This microdesc one has 9
 (dannenberg tor26 longclaw bastet maatuska moria1 dizum gabelmoo
 Faravahar).
 }}}

 I've hacked up moria1 to write out the consensus document that it
 generates, for each flavor, in #4363. The theory is that we need to figure
 out how the ns consensus that we generated differs from the one that the
 other dir auths generated.

 Next step is for moria1 to be the minority voter and me to notice it in
 time, or for more people to start running the patch in #4363 and try to
 catch the bug in action for themselves.

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

Re: [tor-bugs] #26421 [Core Tor/Stem]: Include info about the --quiet / -q option in --help

[Tor Bug Tracker & Wiki]

#26421: Include info about the --quiet / -q option in --help
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  dev testing|  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Dave! 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

[tor-bugs] #26484 [Applications/Tor Browser]: Remove the Windows bustage workaround implemented in #26476

[Tor Bug Tracker & Wiki]

#26484: Remove the Windows bustage workaround implemented in #26476
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We needed to back out ESR60 commits in the last minute to unblock our
 alpha build. We should remove the workaround once
 https://bugzilla.mozilla.org/show_bug.cgi?id=1470772 is fixed on Mozilla's
 side.

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

Re: [tor-bugs] #26476 [Applications/Tor Browser]: Tor Browser candidates for 8.0a9 on Windows don't start anymore

[Tor Bug Tracker & Wiki]

#26476: Tor Browser candidates for 8.0a9 on Windows don't start anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201806,|  Actual Points:
  GeorgKoppen201806, tbb-rbm |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201806 => TorBrowserTeam201806,
 GeorgKoppen201806, tbb-rbm
 * status:  new => closed
 * resolution:   => fixed


Comment:

 `bug_26476` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26476=43cefe3afeb58e7416f7b1e508c8a251b12efb72)
 works for me. I merged it to `master` (commit
 43cefe3afeb58e7416f7b1e508c8a251b12efb72).
 I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1470772 to track the
 issue on Mozilla's side.

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

Re: [tor-bugs] #4363 [Core Tor/Tor]: Dirauths should save a copy of a consensus that didn't get enough signatures

[Tor Bug Tracker & Wiki]

#4363: Dirauths should save a copy of a consensus that didn't get enough
signatures
+--
 Reporter:  Sebastian   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-dirauth auditability save dump  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Here's the hack I'm using on moria1 today:
 {{{
 diff --git a/src/or/dirauth/dirvote.c b/src/or/dirauth/dirvote.c
 index 1643990..b832b51 100644
 --- a/src/or/dirauth/dirvote.c
 +++ b/src/or/dirauth/dirvote.c
 @@ -3351,6 +3351,16 @@ dirvote_compute_consensuses(void)
pending[flav].body = consensus_body;
pending[flav].consensus = consensus;
n_generated++;
 +
 +  /* write it out to disk too, for dir auth debugging purposes */
 +  {
 +  char *filename;
 +  tor_asprintf(, "my-consensus-%s",
 +   networkstatus_get_flavor_name(flav));
 +  write_str_to_file(get_datadir_fname(filename), consensus_body, 0);
 +  tor_free(filename);
 +  }
 +
consensus_body = NULL;
consensus = NULL;
  }
 }}}

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

Re: [tor-bugs] #26417 [Applications/Tor Browser]: Tor Browser build is not working with the runc version in debian testing

[Tor Bug Tracker & Wiki]

#26417: Tor Browser build is not working with the runc version in debian testing
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by sisbell):

 I'm also seeing this on Ubuntu 18.04. The patch fixes the issue.

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

Re: [tor-bugs] #26469 [Core Tor/Tor]: tor on SunOS: [err] Error from libevent: evport.c:425: Assertion evpd->ed_pending[i] == fd failed in evport_del

[Tor Bug Tracker & Wiki]

#26469: tor on SunOS: [err] Error from libevent: evport.c:425: Assertion
evpd->ed_pending[i] == fd failed in evport_del
-+-
 Reporter:  ruebezahl|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.7
 Severity:  Critical | Resolution:
 Keywords:  libevent crash 033-backport  |  Actual Points:
  034-proposed   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ruebezahl):

 as stated above: Libevent 2.1.8-stable, also also for 0.3.3.6 - Did not
 run the Node with 0.3.2.x - I can test another version if you like.

 Also, a Illumos-Zone with gcc etc for compiling  & testing can easily be
 provided, just say the word (and your ssh-pubkey ;) )

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

Re: [tor-bugs] #26417 [Applications/Tor Browser]: Tor Browser build is not working with the runc version in debian testing

[Tor Bug Tracker & Wiki]

#26417: Tor Browser build is not working with the runc version in debian testing
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by ahf):

 The patch that fixed the issue for me (from boklm):

 {{{
 diff --git a/rbm.conf b/rbm.conf
 index de5102d..1ef492c 100644
 --- a/rbm.conf
 +++ b/rbm.conf
 @@ -390,7 +390,7 @@ ENV:
# We will need to update this when there is a new spec version
 available
runc_spec100 => sub {
  my ($out) = capture_exec('sudo', 'runc', '--version');
 -return $out =~ m/^spec: 1\.0\.0$/m;
 +return $out =~ m/^runc version spec: 1\.0\..$/m;
},
  },
)
 }}}

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

Re: [tor-bugs] #8941 [Applications/Tor Browser]: Small Torbutton icons should be 16x16 pixels

[Tor Bug Tracker & Wiki]

#8941: Small Torbutton icons should be 16x16 pixels
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 We have a better solution with #26430, thus 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] #26430 [Applications/Tor Browser]: New torbutton icons

[Tor Bug Tracker & Wiki]

#26430: New torbutton icons
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201806R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Looks good and works for me on Linux and Windows. Merged to `master`
 (commit 32e63d587ac4de0f47ef13db8625a474d0492d34) and I guess I'll squeeze
 into 8.0a9.

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

Re: [tor-bugs] #25976 [Core Tor/Tor]: connection_dir_finished_flushing(): Bug: called in unexpected state 3

[Tor Bug Tracker & Wiki]

#25976: connection_dir_finished_flushing(): Bug: called in unexpected state 3
--+--
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression, 034-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Hit this on moria1 too.

 {{{
 Jun 22 11:00:10.976 [warn] connection_dir_finished_flushing(): Bug: called
 in unexpected state 3. (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:10.977 [warn] tor_bug_occurred_(): Bug:
 src/or/directory.c:5238: connection_dir_finished_flushing: This line
 should not have been reached. (Future instances of this warning will be
 silenced.) (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: Line unexpectedly reached at
 connection_dir_finished_flushing at src/or/directory.c:5238. Stack trace:
 (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(log_backtrace+0x42)
 [0x560ad42dd842] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug:
 ../git/src/or/tor(tor_bug_occurred_+0xca) [0x560ad42f853a] (on Tor 0.3.5.0
 -alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug:
 ../git/src/or/tor(connection_dir_finished_flushing+0x195) [0x560ad428c9b5]
 (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug:
 ../git/src/or/tor(connection_handle_write+0x68e) [0x560ad4267cde] (on Tor
 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(+0x5244e)
 [0x560ad41a744e] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug:
 /usr/lib64/libevent-2.0.so.5(event_base_loop+0x53c) [0x7fd0165b5f8c] (on
 Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(do_main_loop+0x47c)
 [0x560ad41a87ec] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(tor_run_main+0x28c)
 [0x560ad41a8c1c] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(tor_main+0x43)
 [0x560ad41a08d3] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(main+0x19)
 [0x560ad41a0769] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug:
 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fd0157d1d1d] (on Tor 0.3.5.0
 -alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(+0x4b679)
 [0x560ad41a0679] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] conn_write_callback(): Bug: unhandled error on
 write for Directory connection (fd 1112); removing (on Tor 0.3.5.0-alpha-
 dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] tor_bug_occurred_(): Bug: src/or/main.c:943:
 conn_write_callback: This line should not have been reached. (Future
 instances of this warning will be silenced.) (on Tor 0.3.5.0-alpha-dev
 e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: Line unexpectedly reached at
 conn_write_callback at src/or/main.c:943. Stack trace: (on Tor 0.3.5.0
 -alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(log_backtrace+0x42)
 [0x560ad42dd842] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug:
 ../git/src/or/tor(tor_bug_occurred_+0xca) [0x560ad42f853a] (on Tor 0.3.5.0
 -alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(+0x525d2)
 [0x560ad41a75d2] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug:
 /usr/lib64/libevent-2.0.so.5(event_base_loop+0x53c) [0x7fd0165b5f8c] (on
 Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.008 [warn] Bug: ../git/src/or/tor(do_main_loop+0x47c)
 [0x560ad41a87ec] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.009 [warn] Bug: ../git/src/or/tor(tor_run_main+0x28c)
 [0x560ad41a8c1c] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.009 [warn] Bug: ../git/src/or/tor(tor_main+0x43)
 [0x560ad41a08d3] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.009 [warn] Bug: ../git/src/or/tor(main+0x19)
 [0x560ad41a0769] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.009 [warn] Bug:
 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fd0157d1d1d] (on Tor 0.3.5.0
 -alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.009 [warn] Bug: ../git/src/or/tor(+0x4b679)
 [0x560ad41a0679] (on Tor 0.3.5.0-alpha-dev e4e949e901400c85)
 Jun 22 11:00:11.079 [warn] connection_dir_finished_flushing(): Bug: called
 in unexpected state 3. (on Tor 0.3.5.0-alpha-dev 

Re: [tor-bugs] #24546 [Core Tor/Tor]: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses

[Tor Bug Tracker & Wiki]

#24546: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4
addresses
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, ipv6,   |  Actual Points:
  033-triage-20180320, 033-removed-20180320  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by neel):

 My PR for this bug is here: https://github.com/torproject/tor/pull/177

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26483 [Core Tor/Stem]: Static check results in "local variable 'exc' is assigned to but never used"

[Tor Bug Tracker & Wiki]

#26483: Static check results in "local variable 'exc' is assigned to but never
used"
---+--
 Reporter:  dmr|  Owner:  dmr
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 
[[https://github.com/PyCQA/pyflakes/commit/efddb93524db7949322181d5e14c32681779a6e8|pyflakes
 updated to 2.0.0]] now additionally "[checks] for unused exception binding
 in `except:` block", causing the following lint errors:
 {{{
 STATIC CHECKS
 * /path/to/stem/descriptor/reader.py
   line 515  - local variable 'exc' is assigned to but never used | except
 TypeError as exc:

 * /path/to/stem/util/system.py
   line 1327 - local variable 'exc' is assigned to but never used | except
 CallTimeoutError as exc:

 * /path/to/stem/interpreter/__init__.py
   line 148  - local variable 'exc' is assigned to but never used | except
 (KeyboardInterrupt, stem.SocketClosed) as exc:
   line 172  - local variable 'exc' is assigned to but never used | except
 stem.SocketClosed as exc:
   line 184  - local variable 'exc' is assigned to but never used | except
 (KeyboardInterrupt, EOFError, stem.SocketClosed) as exc:
 }}}
 line numbers as of
 
[[https://gitweb.torproject.org/stem.git/tree/stem/?id=3818cf41cae98ae7558f5002ef3a5152ede5b2fb|3818cf41cae98ae7558f5002ef3a5152ede5b2fb]]

 Strangely, those only appear for py35 runs - I didn't see them in my py27
 runs. Not sure why that is.

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

Re: [tor-bugs] #26476 [Applications/Tor Browser]: Tor Browser candidates for 8.0a9 on Windows don't start anymore

[Tor Bug Tracker & Wiki]

#26476: Tor Browser candidates for 8.0a9 on Windows don't start anymore
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 {{{
 +  default=milestone.is_release_or_beta,
 }}}
 is the line that is crashing the Windows builds on start-up. This got
 added in https://bugzilla.mozilla.org/show_bug.cgi?id=1467041. I guess we
 should back out the fix for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1464084 as well as crashes
 were seen without the former but the latter. I am testing a fix right now.

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: Link Rust Tests to C Dependencies in Tor (allow integration testing from Rust to C)

[Tor Bug Tracker & Wiki]

#25386: Link Rust Tests to C Dependencies in Tor (allow integration testing from
Rust to C)
-+-
 Reporter:  Hello71  |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-test, 033-backport,|  Actual Points:
  review-group-34, 034-triage-20180328,  |
  034-included-20180401  |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
 |  SponsorQ
-+-

Comment (by nickm):

 > Can we make it optional?

 Sure -- but someone will need to come up with a mechanism that works and
 doesn't cause too much pain.

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

Re: [tor-bugs] #26469 [Core Tor/Tor]: tor on SunOS: [err] Error from libevent: evport.c:425: Assertion evpd->ed_pending[i] == fd failed in evport_del

[Tor Bug Tracker & Wiki]

#26469: tor on SunOS: [err] Error from libevent: evport.c:425: Assertion
evpd->ed_pending[i] == fd failed in evport_del
-+-
 Reporter:  ruebezahl|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.7
 Severity:  Critical | Resolution:
 Keywords:  libevent crash 033-backport  |  Actual Points:
  034-proposed   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 What version of libevent are you using?  Did the same version work okay
 with Tor 0.3.2.x?

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

Re: [tor-bugs] #26379 [Core Tor/Tor]: Rend-spec isn't clear about role of first layer of descriptor encryption

[Tor Bug Tracker & Wiki]

#26379: Rend-spec isn't clear about role of first layer of descriptor encryption
--+
 Reporter:  sjmurdoch |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #26460 [Core Tor/Tor]: Some? autoconf tests that include stdio.h fail with a missing ssp.h on cygwin (was: Some? autoconf tests that include studio.h fail with a missing ssp.h on cygwin

[Tor Bug Tracker & Wiki]

#26460: Some? autoconf tests that include stdio.h fail with a missing ssp.h on
cygwin
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 033-backport  |  Actual Points:
Parent ID:  #26356| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #26457 [Core Tor/Tor]: Rewrite the UTF-8 conformity section of prop#285

[Tor Bug Tracker & Wiki]

#26457: Rewrite the UTF-8 conformity section of prop#285
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torspec, fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer:  nickm  |Sponsor:
---+
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #26460 [Core Tor/Tor]: Some? autoconf tests that include studio.h fail with a missing ssp.h on cygwin

[Tor Bug Tracker & Wiki]

#26460: Some? autoconf tests that include studio.h fail with a missing ssp.h on
cygwin
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 033-backport  |  Actual Points:
Parent ID:  #26356| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Is this new with 0.3.3, or did 0.3.2 have the same issue?

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

Re: [tor-bugs] #26356 [Core Tor/Tor]: Tor 0.3.3.6 fails to compile under cygwin (x86_64)

[Tor Bug Tracker & Wiki]

#26356: Tor 0.3.3.6 fails to compile under cygwin (x86_64)
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Is this new with 0.3.3, or did 0.3.2 have the same issue?

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

Re: [tor-bugs] #26427 [Core Tor/Tor]: Remove circularity surrounding functions called by tor_logv()

[Tor Bug Tracker & Wiki]

#26427: Remove circularity surrounding functions called by tor_logv()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  refactoring   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by nickm):

 I closed #19328 as a duplicate of 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] #19328 [Core Tor/Tor]: Try not to log from inside functions called from inside log functions

[Tor Bug Tracker & Wiki]

#19328: Try  not to log from inside functions called from inside log functions
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  recursion, logging, tor-relay,   |  duplicate
  technical-debt, refactor, stack-overflow,  |  Actual Points:
  blob, callgraph, tor-dos   |
Parent ID:  #16764   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


Comment:

 Yes!  Closing this ticket as a duplicate of #26427.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26482 [Core Tor/Tor]: Refactor log.c and everything below it into separate libraries

[Tor Bug Tracker & Wiki]

#26482: Refactor log.c and everything below it into separate libraries
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #26481
   Points:|   Reviewer:
  Sponsor:|
--+
 This is currently under review as
 https://github.com/torproject/tor/pull/174 -- but since it wasn't a same-
 day merge, I should really have a ticket for it.

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by Dhalgren):

 My thought was the client fix might inhibit the behavior, though of course
 old and hacked clients could still make attempts and trigger the message.

 Anyway the fix is trivial:

 {{{
 --- src/or/rendmid.c.orig
 +++ src/or/rendmid.c
 @@ -227,7 +227,7 @@
 (unsigned)circ->p_circ_id);

if (circ->base_.purpose != CIRCUIT_PURPOSE_OR) {
 -log_warn(LD_PROTOCOL,
 +log_info(LD_PROTOCOL,
   "Tried to establish rendezvous on non-OR circuit with
 purpose %s",
   circuit_purpose_to_string(circ->base_.purpose));
  goto err;
 }}}

 and perfectly safe since the `goto err` means such circuits are discarded.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26481 [Core Tor/Tor]: Split src/common into src/lib

[Tor Bug Tracker & Wiki]

#26481: Split src/common into src/lib
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This work has already begun; we should have a ticket for it.

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 I don't understand how this could be related. I am obviously running a Tor
 version that includes the DoS protection.

 {{{
 Jun 24 09:50:55.000 [notice] DoS mitigation since startup: 0 circuits
 killed with too many cells. 0 circuits rejected, 0 marked addresses. 0
 connections closed. 0 single hop clients refused.
 }}}

 Do we treat different single hop client is the relay is also an Exit? The
 thing is, I don't see these warnings on my middle relays and bridges,
 while I do run the same Tor version everywhere (alpha-dev).

 Why would Exit relays treat rend circuits any different? Why would clients
 pick Exit relays in the RP position?

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by Dhalgren):

 Not certain but I suspect the recently crafted DoS mitigation support
 #24902 addresses the problem on the client side:

 {{{
 DoS mitigation since startup: . . . 1733 single hop clients refused.
 }}}

 If the above is true the exit message can probably be lowered from [warn]
 to [info].  If it makes you crazy enough tweaking the source for this and
 building would solve it sooner for your relays.

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

Re: [tor-bugs] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Yes, which is why I write "8.0a9" and not "7.5.5".

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by s7r):

 * Attachment "excessive_redenzvous_pending_warnings.png" added.


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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 Now I have over 1000. I am attaching a print screen that will speak for
 itself how annoying and abnormal this is.

 I am willing to run any customized branch to fix 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] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by TorUser):

 * status:  closed => reopened
 * version:   => Tor: unspecified
 * resolution:  fixed =>
 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #26479 [Core Tor/Tor]: Fix 0.3.4: appveyor failures on win32 (test_dir)

[Tor Bug Tracker & Wiki]

#26479: Fix 0.3.4: appveyor failures on win32 (test_dir)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 See branch `appveyor_fix_0623` for this ticket and its child, both
 apparently caused by my fixes for #25787.

 PR at https://github.com/torproject/tor/pull/176.

 This pair of bugs is a release-blocker for 0.3.4.3-alpha.

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

Re: [tor-bugs] #24243 [Applications/Tor Browser]: Tor Browser only render HTML for local pages via file://, no images/CSS

[Tor Bug Tracker & Wiki]

#24243: Tor Browser only render HTML for local pages via file://, no images/CSS
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by TorUser):

 Replying to [comment:14 gk]:
 > This should be fixed in Tor Browser 8.0a9.

 I just installed Tails, and I couldn't load My Ether Wallet JS, using the
 Tails TOR. It comes with TOR 7.5.5. Tor

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

Re: [tor-bugs] #26480 [Core Tor/Tor]: Fix 0.3.4: appveyor failures on win32 (geoip binary mode)

[Tor Bug Tracker & Wiki]

#26480: Fix 0.3.4: appveyor failures on win32 (geoip binary mode)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26479| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 See parent for ticket to 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] #26480 [Core Tor/Tor]: Fix 0.3.4: appveyor failures on win32 (geoip binary mode)

[Tor Bug Tracker & Wiki]

#26480: Fix 0.3.4: appveyor failures on win32 (geoip binary mode)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26479| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


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

[tor-bugs] #26480 [Core Tor/Tor]: Fix 0.3.4: appveyor failures on win32 (geoip binary mode)

[Tor Bug Tracker & Wiki]

#26480: Fix 0.3.4: appveyor failures on win32 (geoip binary mode)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #26479
   Points:|   Reviewer:
  Sponsor:|
--+
 See parent -- this ticket is for the failing geoip tests.

 the issue here is that we were storing the geoip files in text mode,
 leading to CRLF conversion errors.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26479 [Core Tor/Tor]: Fix 0.3.4: appveyor failures on win32 (test_dir)

[Tor Bug Tracker & Wiki]

#26479: Fix 0.3.4: appveyor failures on win32 (test_dir)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There are two problems on windows right now: test_dir.c fails with
 warnings, and the geoip tests are still failing.

 This is the ticket for the test_dir fix.  Both will be on the same branch.

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

Re: [tor-bugs] #26413 [- Select a component]: chaptca broken

[Tor Bug Tracker & Wiki]

#26413: chaptca broken
--+--
 Reporter:  Dollface86|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major | Resolution:  user disappeared
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mikeperry):

 * status:  needs_information => closed
 * resolution:   => user disappeared


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

Re: [tor-bugs] #8494 [Core Tor/Tor]: Document MaxAdvertisedBandwidth in the bandwidth list spec

[Tor Bug Tracker & Wiki]

#8494: Document MaxAdvertisedBandwidth in the bandwidth list spec
-+-
 Reporter:  alphawolf|  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Collecting all commented lines and including the examples, we would have:

 Bandwidth generators MUST limit the relays' measured bandwidth based
 on the MaxAdvertisedBadwidth.
 A relay's MaxAdvertisedBandwidth limits the bandwidth-avg in its
 descriptor. bandwidth-avg is the minimum of MaxAdvertisedBandwidth,
 BandwidthRate, RelayBandwidthRate, BandwidthBurst, and
 RelayBandwidthBurst.
 Therefore, generators MUST limit a relay's measured bandwidth to its
 descriptor's bandwidth-avg. This limit needs to be implemented in the
 generator, because generators may scale consensus weights before sending
 them to Tor.
 Generators SHOULD NOT limit measured bandwidths based on descriptors'
 bandwidth-observed, because that penalises new relays.

 sbws limits the relay's measured bandwidth to the bandwidth-avg
 advertised.

 Torflow partitions relays based on their bandwidth. For unmeasured
 relays, Torflow uses the minimum of all descriptor bandwidths, including
 bandwidth-avg (MaxAdvertisedBandwidth) and bandwidth-observed. Then
 Torflow measures the relays in each partition against each other, which
 implicitly limits a relay's measured bandwidth to the bandwidths of
 similar relays.

 Torflow also generates consensus weights based on the ratio between
 the measured bandwidth and the minimum of all descriptor bandwidths (at
 the time of the measurement). So when an operator reduces the
 MaxAdvertisedBandwidth for a relay, Torflow reduces that relay's measured
 bandwidth.

 > What do you think about these subsections?
 >
 > > > No Zero Bandwidths
 > > > Bandwidth Aggregation
 > > > Bandwidth Scaling
 > > > MaxAdvertisedBandwidth

 Sounds good, just not sure how you have in mind to include them.
 A possibility would be:

   "bw=" Bandwidth

 [Exactly once.]

 The measured bandwidth of this relay.

 No Zero Bandwidths:
 Tor accepts zero bandwidths, but they trigger bugs in older Tor
 implementations. Therefore, implementations SHOULD NOT produce zero
 bandwidths. Instead, they SHOULD use one as their minimum bandwidth.
 If there are zero bandwidths, the parser MAY ignore them.

 Bandwidth Aggregation:
 Multiple measurements can be aggregated using an averaging scheme,
 such as a mean, median, or decaying average.

 Bandwidth Scaling:
 Torflow scales bandwidths to kilobytes per second. Other
 implementations SHOULD use kilobytes per second for their initial
 bandwidth scaling.

 If different implementations or configurations are used in votes for
 the same network, their measurements MAY need further scaling. See
 Appendix B for information about scaling, and one possible scaling
 method.

 MaxAdvertisedBandwidth:
 Bandwidth generators MUST limit the relays' measured bandwidth based
 on the MaxAdvertisedBadwidth. See Appendix C for more information.

 [...]

 C. MaxAdvertisedBandwidth

 [The text above without 1st sentence]

 Does this sounds good?

 > Please open another ticket for changes to other specs.

 i've created #26478

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26478 [Core Tor/Tor]: Unify bandwidth related terms in dir-spec and Tor code.

[Tor Bug Tracker & Wiki]

#26478: Unify bandwidth related terms in dir-spec and Tor code.
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-bwauth
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Unifying these terms would make following what these bandwidth do in the
 code and the spec less confusing.
 For instance:
 - what is called `bandwidthrate` [0] in the code when building the
 descriptor, it is called `bandwidth-avg` in `dir-spec.txt` [1].
 - what is called `bandwidthcapacity` [2] in the code, it is called
 `bandwidth-observed` in `dir-spec.txt`[1]

 I don't know if it is prefered to modify terms in the spec or in the code.

 It'd be also helpful to add formulae or more detailed descriptions on how
 the different bandwidth terms are generated in dir-spec.txt

 [0] ​https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2370
 [1] ​https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n427
 [2] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2376

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26477 [Applications/Tor Browser]: Meek is broken in ESR60-based Tor Browser

[Tor Bug Tracker & Wiki]

#26477: Meek is broken in ESR60-based Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff60-esr,
 Severity:  Normal   |  TorBrowserTeam201806
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Meek is not working in an ESR60-based Tor Browser. Instead of being able
 to use this pluggable transport a new browser Window pops up and a bunch
 of modal dialogs claiming that Tor Browser is already running. This
 affects Moat as well.

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

Re: [tor-bugs] #8494 [Core Tor/Tor]: Document MaxAdvertisedBandwidth in the bandwidth list spec (was: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it?)

[Tor Bug Tracker & Wiki]

#8494: Document MaxAdvertisedBandwidth in the bandwidth list spec
-+-
 Reporter:  alphawolf|  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 (Changing the ticket name to describe what we're doing in the ticket)

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

Re: [tor-bugs] #8494 [Core Tor/Tor]: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it?

[Tor Bug Tracker & Wiki]

#8494: Does MaxAdvertisedBandwidth do anything useful and if not, can we 
deprecate
it?
-+-
 Reporter:  alphawolf|  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:16 juga]:
 > Replying to [comment:15 teor]:
 > > This spec tells us what a bandwidth generator needs to do to be
 compatible with the Tor network.
 > > Sometimes it is useful to give examples of how sbws or torflow
 implements a feature.
 > > But first we need to say what *any* generator must do. Then we can
 give examples.
 >
 > ACK
 >
 > >
 > > So let's start with a sentence like this:
 > >
 > > If a relay sets MaxAdvertisedBandwidth, generators MUST give it a
 similar weight to relays with that bandwidth capacity.
 > > Replying to [comment:13 juga]:
 > > > Bandwidth terms are different in `dir-spec.txt` and the code.
 > > > If i'm not mistaken, what is called `bandwidthrate` [0] in the code
 when creating the descriptor, is called `bandwidth-avg` in `dir-spec.txt`
 [1].
 > > > And it is calculated as the min(BandwidthRate,
 MaxAdvertisedBandwidth, RelayBandwidthRate) [2].
 >
 > Is this correct or i'm mistaken?
 >

 bandwidth-avg is min(BandwidthRate, MaxAdvertisedBandwidth,
 RelayBandwidthRate, BandwidthBurst, RelayBandwidthBurst)

 > > > If this is correct, the paragraph to add in `bandwidth-file-
 spec.txt` could be:
 > > >
 > > > sbws limits the relay's measured bandwidth to the bandwidth-avg
 advertised
 > >
 > > Please say "Bandwidth generators MUST limit the relay's weight based
 on", not "sbws limits the relay's measured bandwidth to".
 > >
 > > > in the relay's descriptor, which is the minimum between
 BandwidthRate,
 > > > MaxAdvertisedBandwidth and RelayBandwidthRate in the relay's
 configuration.
 > > >
 > > > Though probably the last sentence not needed.
 > >
 > > I think we need the last sentence, because we need to explain why
 bandwidth generators need to implement MaxAdvertisedBandwidth.
 > >
 > > Let's also say:
 > >
 > > Relays limit their bandwidth when BandwdithRate or
 RelayBandwidthRate are set. These options reduce a relay's bandwidth
 capacity. But MaxAdvertisedBandwidth doesn't change the relay's bandwidth
 capacity. Instead, it asks the bandwidth generator to limit the weight of
 the relay as if the relay's measured bandwidth was min(measured bandwidth,
 MaxAdvertisedBandwidth).
 > > Generators SHOULD NOT limit weights based on bandwidth-observed,
 because that penalises new relays.
 > >
 >
 > In all your suggestions, i would not use the word `weight` to do not
 confuse it with the `weight` generated in the consensus.

 When I say "weight", I mean "the weight generated in the consensus",
 rather than "the bandwidth measured for the relay".

 Some generators don't measure relay bandwidth. For example, peerflow
 aggregates a relay's observed bandwidths from other relays. That's why I
 said "consensus weight".

 But we are not making that distinction in the spec, so we can just say
 "measured bandwidth".

 > I also would not use the word `capacity` to do not confuse it with the
 `bandwidth-observed` in the descriptors that it's called
 `bandwidthcapacity` in the code and comes from relays' self-tests.

 When I said "capacity", I mean "the total amount of bandwidth the relay
 can handle". I didn't want to say "measured bandwidth", because that's
 "the extra amount of bandwidth the relay can handle". But we're not making
 that distinction in the spec either, so we can just say "measured
 bandwidth" here as well.

 >
 > > Then we can give an example of what sbws does:
 > >
 > > sbws measures relay bandwidths, then caps the measured bandwidth
 using bandwidth-avg (MaxAdvertisedBandwidth).
 >
 > as mentioned above, isn't bandwidth-avg = min(MaxAdvertisedBandwidth,
 MaxAdvertisedBandwidth, RelayBandwidthRate)?

 No, see above.

 > > > If Torflow is using also `bandwidth-avg`, then it could also be
 added in `bandwidth-file-spec.txt`:
 > > >
 > > > Torflow does not need to limit the relay's measured bandwidth
 since it
 > > > partions relays to be measured by bandwidth-avg
 > > >
 > > > Is this correct?.
 > >
 > 

Re: [tor-bugs] #26476 [Applications/Tor Browser]: Tor Browser candidates for 8.0a9 on Windows don't start anymore

[Tor Bug Tracker & Wiki]

#26476: Tor Browser candidates for 8.0a9 on Windows don't start anymore
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 The good news is it's not one of our patches or the rebase that broke
 Windows builds. The bad news is that it seems to be some Mozilla commit:

 `bug_26476_test2` is based on a59817849caddc8475595855a03f7dcf5c4ba855
 which works
 `bug_26476_test1` is based on f4f2ffd2aa14ca8a144e9fc8d773fca4c040e3f5
 which is broken

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

Re: [tor-bugs] #8494 [Core Tor/Tor]: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it?

[Tor Bug Tracker & Wiki]

#8494: Does MaxAdvertisedBandwidth do anything useful and if not, can we 
deprecate
it?
-+-
 Reporter:  alphawolf|  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:15 teor]:
 > This spec tells us what a bandwidth generator needs to do to be
 compatible with the Tor network.
 > Sometimes it is useful to give examples of how sbws or torflow
 implements a feature.
 > But first we need to say what *any* generator must do. Then we can give
 examples.

 ACK

 >
 > So let's start with a sentence like this:
 >
 > If a relay sets MaxAdvertisedBandwidth, generators MUST give it a
 similar weight to relays with that bandwidth capacity.
 > Replying to [comment:13 juga]:
 > > Bandwidth terms are different in `dir-spec.txt` and the code.
 > > If i'm not mistaken, what is called `bandwidthrate` [0] in the code
 when creating the descriptor, is called `bandwidth-avg` in `dir-spec.txt`
 [1].
 > > And it is calculated as the min(BandwidthRate, MaxAdvertisedBandwidth,
 RelayBandwidthRate) [2].

 Is this correct or i'm mistaken?

 > > If this is correct, the paragraph to add in `bandwidth-file-spec.txt`
 could be:
 > >
 > > sbws limits the relay's measured bandwidth to the bandwidth-avg
 advertised
 >
 > Please say "Bandwidth generators MUST limit the relay's weight based
 on", not "sbws limits the relay's measured bandwidth to".
 >
 > > in the relay's descriptor, which is the minimum between
 BandwidthRate,
 > > MaxAdvertisedBandwidth and RelayBandwidthRate in the relay's
 configuration.
 > >
 > > Though probably the last sentence not needed.
 >
 > I think we need the last sentence, because we need to explain why
 bandwidth generators need to implement MaxAdvertisedBandwidth.
 >
 > Let's also say:
 >
 > Relays limit their bandwidth when BandwdithRate or
 RelayBandwidthRate are set. These options reduce a relay's bandwidth
 capacity. But MaxAdvertisedBandwidth doesn't change the relay's bandwidth
 capacity. Instead, it asks the bandwidth generator to limit the weight of
 the relay as if the relay's measured bandwidth was min(measured bandwidth,
 MaxAdvertisedBandwidth).
 > Generators SHOULD NOT limit weights based on bandwidth-observed,
 because that penalises new relays.
 >

 In all your suggestions, i would not use the word `weight` to do not
 confuse it with the `weight` generated in the consensus.
 I also would not use the word `capacity` to do not confuse it with the
 `bandwidth-observed` in the descriptors that it's called
 `bandwidthcapacity` in the code and comes from relays' self-tests.


 > Then we can give an example of what sbws does:
 >
 > sbws measures relay bandwidths, then caps the measured bandwidth
 using bandwidth-avg (MaxAdvertisedBandwidth).

 as mentioned above, isn't bandwidth-avg = min(MaxAdvertisedBandwidth,
 MaxAdvertisedBandwidth, RelayBandwidthRate)?

 > > If Torflow is using also `bandwidth-avg`, then it could also be added
 in `bandwidth-file-spec.txt`:
 > >
 > > Torflow does not need to limit the relay's measured bandwidth
 since it
 > > partions relays to be measured by bandwidth-avg
 > >
 > > Is this correct?.
 >
 > No, Torflow partitions based on:
 > * bandwidth-consensus, if available, or
 > * min(bandwidth-avg, bandwidth-burst, bandwidth-observed), or
 > * 1, if either bandwidth is zero.
 >
 > https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n376
 > https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n459
 >
 > Torflow also calculates weights based on the descriptor bandwidth to
 measured bandwidth ratio.
 >
 > So let's say:
 >
 > Torflow partitions relays based on their bandwidth. For unmeasured
 relays, Torflow uses the minimum of all descriptor bandwidths, including
 bandwidth-avg (MaxAdvertisedBandwidth)

 as mentioned above, isn't bandwidth-avg = min(MaxAdvertisedBandwidth,
 MaxAdvertisedBandwidth, RelayBandwidthRate)?

 > and bandwidth-observed. Then Torflow measures the relays in each
 partition against each other, which implicitly limits a relay's measured
 bandwidth to the bandwidths of similar relays.
 >
 > Torflow also generates consensus 

Re: [tor-bugs] #19328 [Core Tor/Tor]: Try not to log from inside functions called from inside log functions

[Tor Bug Tracker & Wiki]

#19328: Try  not to log from inside functions called from inside log functions
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  recursion, logging, tor-relay,   |  Actual Points:
  technical-debt, refactor, stack-overflow,  |
  blob, callgraph, tor-dos   |
Parent ID:  #16764   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorS-can
-+-

Comment (by teor):

 nickm, have we solve this ticket already?

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

Re: [tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  regression, triaged-out-20170124,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 These schedules use  exponential backoff with decorrelated jitter, with no
 maximums. That seems to be working well enough,

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

Re: [tor-bugs] #20605 [Core Tor/Tor]: Reduce the exponential backoff variance

[Tor Bug Tracker & Wiki]

#20605: Reduce the exponential backoff variance
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  backoff, tor-client download-|  Actual Points:
  schedule   |
Parent ID:  #20534   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 We already fixed this ticket using decorrelated jitter.

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

Re: [tor-bugs] #20607 [Core Tor/Chutney]: Revise chutney download schedules for exponential backoff

[Tor Bug Tracker & Wiki]

#20607: Revise chutney download schedules for exponential backoff
--+-
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:  #20534| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

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


Comment:

 We won't fix this ticket, the current solution seems to be working well
 enough.

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

Re: [tor-bugs] #26476 [Applications/Tor Browser]: Tor Browser candidates for 8.0a9 on Windows don't start anymore

[Tor Bug Tracker & Wiki]

#26476: Tor Browser candidates for 8.0a9 on Windows don't start anymore
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Testing essentially 60.1.0esr with `bug_26476_test1`.

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

Re: [tor-bugs] #26155 [Core Tor/Tor]: Bandwidth file Timestamp is the latest scanner result, not the file creation time

[Tor Bug Tracker & Wiki]

#26155: Bandwidth file Timestamp is the latest scanner result, not the file
creation time
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+
Changes (by juga):

 * status:  needs_revision => merge_ready


Comment:

 Rebased to master, should be fine now

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

Re: [tor-bugs] #26473 [Applications/Tor Browser]: Tor Browser high CPU usage while browsing Facebook

[Tor Bug Tracker & Wiki]

#26473: Tor Browser high CPU usage while browsing Facebook
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:4 cypherpunks]:
 > Replying to [comment:3 teor]:
 > > The safest security setting turns off JavaScript, but it also turns
 off a lot of optimisations. (Because optimisations are fingerprintable.)
 > Optimisations of JS (i.e. basically JIT) have nothing to do with that
 since JS itself is entirely blocked, so why am I getting 100% CPU usage in
 a simple forum on high security setting? (precision: while it's loading
 up, when the page finally loads up it becomes better)

 JavaScript isn't the only thing that browsers optimise.

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

Re: [tor-bugs] #26473 [Applications/Tor Browser]: Tor Browser high CPU usage while browsing Facebook

[Tor Bug Tracker & Wiki]

#26473: Tor Browser high CPU usage while browsing Facebook
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 On the bright side: a FF60-esr based Tor Browser alpha is coming out very
 soon which will likely not have such a bug. On the darker side: using it
 will make you more fingerprintable.

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

Re: [tor-bugs] #26476 [Applications/Tor Browser]: Tor Browser candidates for 8.0a9 on Windows don't start anymore

[Tor Bug Tracker & Wiki]

#26476: Tor Browser candidates for 8.0a9 on Windows don't start anymore
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 The first one that is broken is the nightly from yestderday. From 6/22 it
 is still working. Probably something in our rebase to 60.1.0esr broke,
 sigh.

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

Re: [tor-bugs] #8494 [Core Tor/Tor]: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it?

[Tor Bug Tracker & Wiki]

#8494: Does MaxAdvertisedBandwidth do anything useful and if not, can we 
deprecate
it?
-+-
 Reporter:  alphawolf|  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 This spec tells us what a bandwidth generator needs to do to be compatible
 with the Tor network.
 Sometimes it is useful to give examples of how sbws or torflow implements
 a feature.
 But first we need to say what *any* generator must do. Then we can give
 examples.

 So let's start with a sentence like this:

 If a relay sets MaxAdvertisedBandwidth, generators MUST give it a
 similar weight to relays with that bandwidth capacity.

 Replying to [comment:13 juga]:
 > Bandwidth terms are different in `dir-spec.txt` and the code.
 > If i'm not mistaken, what is called `bandwidthrate` [0] in the code when
 creating the descriptor, is called `bandwidth-avg` in `dir-spec.txt` [1].
 > And it is calculated as the min(BandwidthRate, MaxAdvertisedBandwidth,
 RelayBandwidthRate) [2].
 > If this is correct, the paragraph to add in `bandwidth-file-spec.txt`
 could be:
 >
 > sbws limits the relay's measured bandwidth to the bandwidth-avg
 advertised

 Please say "Bandwidth generators MUST limit the relay's weight based on",
 not "sbws limits the relay's measured bandwidth to".

 > in the relay's descriptor, which is the minimum between
 BandwidthRate,
 > MaxAdvertisedBandwidth and RelayBandwidthRate in the relay's
 configuration.
 >
 > Though probably the last sentence not needed.

 I think we need the last sentence, because we need to explain why
 bandwidth generators need to implement MaxAdvertisedBandwidth.

 Let's also say:

 Relays limit their bandwidth when BandwdithRate or RelayBandwidthRate
 are set. These options reduce a relay's bandwidth capacity. But
 MaxAdvertisedBandwidth doesn't change the relay's bandwidth capacity.
 Instead, it asks the bandwidth generator to limit the weight of the relay
 as if the relay's bandwidth capacity was min(generated bandwidth capacity,
 MaxAdvertisedBandwidth).

 Generators SHOULD NOT limit weights based on bandwidth-observed,
 because that penalises new relays.

 Then we can give an example of what sbws does:

 sbws measures relay bandwidths, then caps the measured bandwidth using
 bandwidth-avg (MaxAdvertisedBandwidth).

 > If Torflow is using also `bandwidth-avg`, then it could also be added in
 `bandwidth-file-spec.txt`:
 >
 > Torflow does not need to limit the relay's measured bandwidth since
 it
 > partions relays to be measured by bandwidth-avg
 >
 > Is this correct?.

 No, Torflow partitions based on:
 * bandwidth-consensus, if available, or
 * min(bandwidth-avg, bandwidth-burst, bandwidth-observed), or
 * 1, if either bandwidth is zero.

 https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n376
 https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n459

 Torflow also calculates weights based on the descriptor bandwidth to
 measured bandwidth ratio.

 So let's say:

 Torflow partitions relays based on their bandwidth. For unmeasured
 relays, Torflow uses the minimum of all descriptor bandwidths, including
 bandwidth-avg (MaxAdvertisedBandwidth) and bandwidth-observed. Then
 Torflow measures the relays in each partition against each other, which
 implicitly limits a relay's measured bandwidth to the bandwidths of
 similar relays.

 Torflow also generates consensus weights based on the ratio between
 the measured bandwidth and the minimum of all descriptor bandwidths (at
 the time of the measurement). So when an operator reduces
 MaxAdvertisedBandwidth in a relay, Torflow reduces that relay's bandwidth
 rate.

 > [0] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2370
 > [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n427
 > [2] https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n1693

 Once we add these paragraphs, the bandwidth section will be really long.

 Let's split it up into subsections:

 No Zero Bandwidths
 Bandwidth Aggregation
 Bandwidth Scaling
 MaxAdvertisedBandwidth

--
Ticket URL: 

Re: [tor-bugs] #26476 [Applications/Tor Browser]: Tor Browser candidates for 8.0a9 on Windows don't start anymore (was: Tor Browser candidates for 8.0a8 on Windows don't start anymore)

[Tor Bug Tracker & Wiki]

#26476: Tor Browser candidates for 8.0a9 on Windows don't start anymore
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

[tor-bugs] #26476 [Applications/Tor Browser]: Tor Browser candidates for 8.0a8 on Windows don't start anymore

[Tor Bug Tracker & Wiki]

#26476: Tor Browser candidates for 8.0a8 on Windows don't start anymore
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201806
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Suddenly our Windows bundles are not starting anymore, both 32bit and
 64bit.

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

Re: [tor-bugs] #26473 [Applications/Tor Browser]: Tor Browser high CPU usage while browsing Facebook

[Tor Bug Tracker & Wiki]

#26473: Tor Browser high CPU usage while browsing Facebook
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:3 teor]:
 > The safest security setting turns off JavaScript, but it also turns off
 a lot of optimisations. (Because optimisations are fingerprintable.)
 Optimisations of JS (i.e. basically JIT) have nothing to do with that
 since JS itself is entirely blocked, so why am I getting 100% CPU usage in
 a simple forum on high security setting?

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

Re: [tor-bugs] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducibly with Stylo enabled (was: ESR60-based .dmg images are not built reproducible)

[Tor Bug Tracker & Wiki]

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

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

Re: [tor-bugs] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducible

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducible
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806,   |  Actual Points:
  GeorgKoppen201806  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201806 => tbb-rbm,
 TorBrowserTeam201806, GeorgKoppen201806
 * priority:  Immediate => Very High


Comment:

 Disabling stylo solves this for now. I'll leave this bug open for further
 investigation, 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] #8494 [Core Tor/Tor]: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it?

[Tor Bug Tracker & Wiki]

#8494: Does MaxAdvertisedBandwidth do anything useful and if not, can we 
deprecate
it?
-+-
 Reporter:  alphawolf|  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * owner:  tom => juga
 * status:  new => assigned
 * cc: juga (removed)
 * parent:   => #25925


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

Re: [tor-bugs] #8494 [Core Tor/Tor]: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it?

[Tor Bug Tracker & Wiki]

#8494: Does MaxAdvertisedBandwidth do anything useful and if not, can we 
deprecate
it?
-+-
 Reporter:  alphawolf|  Owner:  tom
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, consensus, bandwidth,  |  Actual Points:
  MaxAdvertisedBandwidth tor-relay tor-dirauth   |
  needs-insight tor-bwauth   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Bandwidth terms are different in `dir-spec.txt` and the code.
 If i'm not mistaken, what is called `bandwidthrate` [0] in the code when
 creating the descriptor, is called `bandwidth-avg` in `dir-spec.txt` [1].
 And it is calculated as the min(BandwidthRate, MaxAdvertisedBandwidth,
 RelayBandwidthRate) [2].
 If this is correct, the paragraph to add in `bandwidth-file-spec.txt`
 could be:

 sbws limits the relay's measured bandwidth to the bandwidth-avg
 advertised
 in the relay's descriptor, which is the minimum between BandwidthRate,
 MaxAdvertisedBandwidth and RelayBandwidthRate in the relay's
 configuration.

 Though probably the last sentence not needed.
 If Torflow is using also `bandwidth-avg`, then it could also be added in
 `bandwidth-file-spec.txt`:

 Torflow does not need to limit the relay's measured bandwidth since it
 partions relays to be measured by bandwidth-avg

 Is this correct?.

 [0] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2370
 [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n427
 [2] https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n1693

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

Re: [tor-bugs] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducible

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducible
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Immediate  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 I compared two obj-macos dirs and gkrust seems to be the culprit (as
 assumed).

 `diff -u <(xxd tpo/gkrust-d3a9de07b53ab691.gkrust0.rcgu.o) <(xxd uninett
 /gkrust-d3a9de07b53ab691.gkrust0.rcgu.o)`

 gives me among others

 {{{
  00440e20: ff48 8b07 488b 4f08 4889 8d70  ff48  .H..H.O.H..p...H
  00440e30: 8985 68ff  488d 0500  0048 8985  ..h...H..H..
  00440e40: 38ff  48c7 8540  ff06  0048  8...H..@...H
 -00440e50: 8b3d   ff17 8078 2100 0f85 da01  .=...x!.
 +00440e50: 8b3d   ff17 8078 2100 0f85 d801  .=...x!.
  00440e60:  488b 3d00  00ff 1780 7820 0075  ..H.=...x .u
  00440e70: 1f48 8b3d   ff17 4889 c348 8d3d  .H.=..H..H.=
  00440e80:   4889 dee8   c643 2001  HC .
 -00440e90: 488b 3d00  00ff 1748 8338 0174 6748  H.=..H.8.tgH
 +00440e90: 488b 3d00  00ff 1748 8338 0174 6548  H.=..H.8.teH
  00440ea0: 8b3d   ff17 660f 6f40 100f 57c9  .=..f.o@..W.
 -00440eb0: 0f29 4810 b901  0066 480f 6ec9 488b  .)H..fH.n.H.
 -00440ec0: 0866 0f7f 0848 85c9 7429 6648 0f7e c348  .f...H..t)fH.~.H
 -00440ed0: 85db 741f 660f 70c0 4e66 490f 7ec6 4889  ..t.f.p.NfI.~.H.
 -00440ee0: df41 ff16 4983 7e08 0074 0848 89df e800  .A..I.~..t.H
 -00440ef0:  0048 8b3d   ff17 4883 3801  ...H.=..H.8.
 -00440f00: 0f85 8102  488b 3d00  00ff 1748  ..H.=..H
 -00440f10: 8378 0800 7477 e800  0048 89c3 4889  .x..tw.H..H.
 -00440f20: 9d48  ff48 8b45 9048 8945 d048 8b45  .H...H.E.H.E.H.E
 -00440f30: 8848 8945 c848 8b45 8048 8945 c048 8b85  .H.E.H.E.H.E.H..
 -00440f40: 78ff  4889 45b8 488b 8568  ff48  x...H.E.H..h...H
 -00440f50: 8b8d 70ff  4889 4db0 4889 45a8 488d  ..p...H.M.H.E.H.
 -00440f60: 7dd8 488d b548  ff48 8d55 a8e8   }.H..H...H.U
 -00440f70:  f048 ff0b 0f85 a100  488d bd48  ...HH..H
 -00440f80:  ffe8   e990  0048 8b3d  .H.=
 -00440f90:   ff17 48c7 4008   488d  ..H.@.H.
 -00440fa0: 4808 488d 5010 4889 9548  ff48 898d  H.H.P.H..H...H..
 -00440fb0: 50ff  488b 7010 4885 f60f 84b0 0100  P...H.p.H...
 -00440fc0: 0048 8b3d   ff17 4889 c348 8b45  .H.=..H..H.E
 -00440fd0: 9048 8945 d048 8b43 1848 8b4d 8848 894d  .H.E.H.C.H.M.H.M
 -00440fe0: c848 8b4d 8048 894d c048 8b8d 78ff   .H.M.H.M.H..x...
 -00440ff0: 4889 4db8 488b 8d68  ff48 8b95 70ff  H.M.H..h...H..p.
 -00441000:  4889 55b0 4889 4da8 488d 7dd8 488d  ..H.U.H.M.H.}.H.
 -00441010: 55a8 ff50 3048 c743 0800  008b 45d9  U..P0H.C..E.
 -00441020: 8945 e88a 45d8 0fb7 4ddd 6689 4dec 8a4d  .E..E...M.f.M..M
 -00441030: df88 4dee 3c04 0f85 8000  e800   ..M.<...
 -00441040: 0048 89c3 4889 9d48  ff48 8b45 9048  .H..H..H...H.E.H
 -00441050: 8945 d048 8b45 8848 8945 c848 8b45 8048  .E.H.E.H.E.H.E.H
 -00441060: 8945 c048 8b85 78ff  4889 45b8 488b  .E.H..x...H.E.H.
 -00441070: 8568  ff48 8b8d 70ff  4889 4db0  .h...H..p...H.M.
 -00441080: 4889 45a8 488d 7d98 488d b548  ff48  H.E.H.}.H..H...H
 -00441090: 8d55 a8e8   f048 ff0b 750c 488d  .U...H..u.H.
 -004410a0: bd48  ffe8   807d 9803 7531  .H.}..u1
 -004410b0: 4881 c4c0  005b 415e 5dc3 8845 9848  H..[A^]..E.H
 -004410c0: 8b45 e08b 4de8 894d 990f b74d ec66 894d  .E..M..M...M.f.M
 -004410d0: 9d8a 4dee 884d 9f48 8945 a080 7d98 0374  ..M..M.H.E..}..t
 -004410e0: cf48 8b45 9848 8b4d a048 894d e048 8945  .H.E.H.M.H.M.H.E
 -004410f0: d848 8d85 38ff  4889 8548  ff48  .H..8...H..H...H
 -00441100: 8d05   4889 8550  ff48 8d45  ..H..P...H.E
 -00441110: d848 8985 58ff  488d 0500  0048  .H..X...H..H
 -00441120: 8985 60ff  488d 0500  0048 8945  ..`...H..H.E
 -00441130: a848 c745 b002  0048 8d05    .H.E.H..
 -00441140: 4889 45b8 48c7 45c0 0200  488d 8548  H.E.H.E.H..H
 -00441150:  ff48 8945 c848 c745 d002  0048  ...H.E.H.E.H
 -00441160: 8d35   488d 7da8 e800  000f  .5H.}...
 -00441170: 0b48 8b3d   ff17 48c7 4008   .H.=..H.@...
 -00441180:  e98f fdff ff48 8d3d   e800  ...H.=..
 -00441190:  000f 0b66 662e 0f1f 8400    

Re: [tor-bugs] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducible

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducible
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Immediate  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Replying to [comment:2 boklm]:
 > Maybe comparing the `obj-macos` directory from two builds can help debug
 the issue.
 >
 > I have started a build with this patch:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_26475=1ceef284b016441783d276ba32542e9fcd9bfd75
 >
 I pushed a fixup commit for that:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_26475=a5bb5818b3563a1a7a7d13a8068ef0e55943c13d

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

Re: [tor-bugs] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducible

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducible
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Immediate  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 Maybe comparing the `obj-macos` directory from two builds can help debug
 the issue.

 I have started a build with this patch:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_26475=1ceef284b016441783d276ba32542e9fcd9bfd75

 with the command:
 {{{
 $ ./rbm/rbm build firefox --target alpha --target torbrowser-osx-x86_64
 }}}

 And will upload the result when it finish.

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

Re: [tor-bugs] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducible

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducible
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Immediate  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201806  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Only `XUL` is different in our case:
 {{{
 --- /dev/fd/63  2018-06-24 08:54:28.175516977 +0200
 +++ /dev/fd/62  2018-06-24 08:54:28.175516977 +0200
 @@ -201,8 +201,8 @@
  0c80:          
  0c90:     104f 5805 a616   .OX.
  0ca0:          
 -0cb0: 1b00  1800  ddc1 d65d f3d8 3a65  ...]..:e
 -0cc0: 8465 a64e d247 5b4d 2400  1000   .e.N.G[M$...
 +0cb0: 1b00  1800  18a4 cc7a 95d7 325d  ...z..2]
 +0cc0: 96c5 6f08 51ec 0b4e 2400  1000   ..o.Q..N$...
  0cd0: 0007 0a00 0006 0a00 0c00  5800   X...
  0ce0: 1800  0200   1600  0100  
  0cf0: 2f53 7973 7465 6d2f 4c69 6272 6172 792f  /System/Library/
 @@ -3732284,59 +3732284,59 @@
  038f33b0: ff48 8b07 488b 4f08 4889 8d70  ff48  .H..H.O.H..p...H
  038f33c0: 8985 68ff  488d 051e 432a 0048 8985  ..h...H...C*.H..
  038f33d0: 38ff  48c7 8540  ff06  0048  8...H..@...H
 -038f33e0: 8d3d 9adf bf01 ff17 8078 2100 0f85 da01  .=...x!.
 +038f33e0: 8d3d 9adf bf01 ff17 8078 2100 0f85 d801  .=...x!.
  038f33f0:  488d 3d87 dfbf 01ff 1780 7820 0075  ..H.=...x .u
  038f3400: 1f48 8d3d 78df bf01 ff17 4889 c348 8d3d  .H.=x.H..H.=
  038f3410: fc95  4889 dee8 c0c1 0100 c643 2001  HC .
 -038f3420: 488d 3d59 dfbf 01ff 1748 8338 0174 6748  H.=Y.H.8.tgH
 +038f3420: 488d 3d59 dfbf 01ff 1748 8338 0174 6548  H.=Y.H.8.teH
  038f3430: 8d3d 4adf bf01 ff17 660f 6f40 100f 57c9  .=J.f.o@..W.
 -038f3440: 0f29 4810 b901  0066 480f 6ec9 488b  .)H..fH.n.H.
 -038f3450: 0866 0f7f 0848 85c9 7429 6648 0f7e c348  .f...H..t)fH.~.H
 -038f3460: 85db 741f 660f 70c0 4e66 490f 7ec6 4889  ..t.f.p.NfI.~.H.
 -038f3470: df41 ff16 4983 7e08 0074 0848 89df e8c7  .A..I.~..t.H
 -038f3480: b001 0048 8d3d f6de bf01 ff17 4883 3801  ...H.=..H.8.
 -038f3490: 0f85 8102  488d 3de3 debf 01ff 1748  ..H.=..H
 -038f34a0: 8378 0800 7477 e895 f2ff ff48 89c3 4889  .x..tw.H..H.
 -038f34b0: 9d48  ff48 8b45 9048 8945 d048 8b45  .H...H.E.H.E.H.E
 -038f34c0: 8848 8945 c848 8b45 8048 8945 c048 8b85  .H.E.H.E.H.E.H..
 -038f34d0: 78ff  4889 45b8 488b 8568  ff48  x...H.E.H..h...H
 -038f34e0: 8b8d 70ff  4889 4db0 4889 45a8 488d  ..p...H.M.H.E.H.
 -038f34f0: 7dd8 488d b548  ff48 8d55 a8e8 8ef9  }.H..H...H.U
 -038f3500:  f048 ff0b 0f85 a100  488d bd48  ...HH..H
 -038f3510:  ffe8 58c0  e990  0048 8d3d  XH.=
 -038f3520: 5cde bf01 ff17 48c7 4008   488d  \.H.@.H.
 -038f3530: 4808 488d 5010 4889 9548  ff48 898d  H.H.P.H..H...H..
 -038f3540: 50ff  488b 7010 4885 f60f 84b0 0100  P...H.p.H...
 -038f3550: 0048 8d3d 28de bf01 ff17 4889 c348 8b45  .H.=(.H..H.E
 -038f3560: 9048 8945 d048 8b43 1848 8b4d 8848 894d  .H.E.H.C.H.M.H.M
 -038f3570: c848 8b4d 8048 894d c048 8b8d 78ff   .H.M.H.M.H..x...
 -038f3580: 4889 4db8 488b 8d68  ff48 8b95 70ff  H.M.H..h...H..p.
 -038f3590:  4889 55b0 4889 4da8 488d 7dd8 488d  ..H.U.H.M.H.}.H.
 -038f35a0: 55a8 ff50 3048 c743 0800  008b 45d9  U..P0H.C..E.
 -038f35b0: 8945 e88a 45d8 0fb7 4ddd 6689 4dec 8a4d  .E..E...M.f.M..M
 -038f35c0: df88 4dee 3c04 0f85 8000  e86f f1ff  ..M.

Re: [tor-bugs] #26472 [Applications/Tor Browser]: Generating incremental mars for tbb-8.0a9-build2 fails

[Tor Bug Tracker & Wiki]

#26472: Generating incremental mars for tbb-8.0a9-build2 fails
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201806  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 As a data point: this happens for me as well but not with copied over mar-
 tools from older releases. It seems something in the script got changed
 from ESR52-ESR60. Let's see what exactly...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26475 [Applications/Tor Browser]: ESR60-based .dmg images are not built reproducible

[Tor Bug Tracker & Wiki]

#26475: ESR60-based .dmg images are not built reproducible
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201806
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Contrary to our testing results the .dmg bundles we produce for 8.0a9 are
 differing on two machines.

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