Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:7 nickm]:
 >   * Possibly, unanimity should not be required; best effort unanimity,
 falling back to unanimity-minus-one, may be enough.

 I think when writing the council guidelines we didn't provide anywhere
 near this level of instruction for the council members.

 I think (at present) that means it's up to the council to figure out how
 it functions.

 I see that this could be problematic, e.g. if some council people disagree
 about how things should be done, so writing down more of the expectations,
 though constraining, could also be freeing.

 I heard that a lot of what the first (elected) council did was to try to
 decide about its policies and procedures in more detail. Maybe we can ask
 them to publish some of those choices, and we can codify the ones we like,
 and/or help to identify areas where the current instructions are too
 vague?

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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Another community council change that somebody suggested to me in Rome:
 choose the members of the council holistically, rather than having a bunch
 of people apply and then just pushing together the top k vote-getters.
 Holistically could mean to make sure to have the right skills on it (a
 lawyer, a psychologist, etc) or it could aim to make sure different
 backgrounds or perspectives are represented.

 More generally, we should think about what are reasons are for "vote
 individually, and call the top k people the council" -- so they feel they
 have the mandate of the people? so we don't have to answer the question of
 who would pick the council otherwise? so we're being "fair" to the
 candidates? something else? -- and brainstorm whether some other mechanism
 would do better for us.

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

Re: [tor-bugs] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, compression, tor-dos, |  Actual Points:
  review-group-34|
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 Should be fixed 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] #23883 [Core Tor/Tor]: document how to get Travis or GitLab CI running on your fork of tor

[Tor Bug Tracker & Wiki]

#23883: document how to get Travis or GitLab CI running on your fork of tor
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  new-developers tor-ci tor-doc  |  Actual Points:
Parent ID:  #25550 | Points:
 Reviewer: |Sponsor:  Sponsor3
---+---
Changes (by catalyst):

 * parent:   => #25550


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

Re: [tor-bugs] #23883 [Core Tor/Tor]: document how to get Travis or GitLab CI running on your fork of tor

[Tor Bug Tracker & Wiki]

#23883: document how to get Travis or GitLab CI running on your fork of tor
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  new-developers tor-ci tor-doc  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor3
---+---
Changes (by catalyst):

 * sponsor:   => Sponsor3
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing  |  Actual Points:
Parent ID:  #25550   | Points:
 Reviewer:   |Sponsor:  Sponsor3
-+
Changes (by catalyst):

 * sponsor:   => Sponsor3


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

Re: [tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
-+
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-testing  |  Actual Points:
Parent ID:  #25550   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by catalyst):

 * parent:   => #25550


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25550 [Core Tor/Tor]: improve continuous integration support

[Tor Bug Tracker & Wiki]

#25550: improve continuous integration support
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor3  |
--+


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

Re: [tor-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yawning):

 There are at least two issues that I know of that prevent running Firefox
 without `/proc` mounted.

 The first is that Firefox uses `/proc/self/task` to see if it spawned any
 threads.  The warning can be ignored on any kernel that supports
 `SECCOMP_FILTER_FLAG_TSYNC` (>= 3.17), but may result in "bad" if the
 kernel is old, and no, I do not remember what the bad is.

 The second is that Firefox will crash with `too much recursion` if `/proc`
 is not mounted.  The culprit there is that Firefox will query the stack
 size with `pthread_attr_getstack()` which will return a stack size of `0`,
 if `/proc` is not mounted for the default thread (`tid == pid`).

 Note that there may be other horrific things that happen, or other things
 that break without `/proc`, but I was not able to find any at the time
 that I cared about this.  Finding and debugging such things is left as an
 exercise for the student.  Fixing this properly probably requires upstream
 to care about this use case.

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

[tor-bugs] #25549 [Core Tor/Tor]: Add tor CI config for AppVeyor

[Tor Bug Tracker & Wiki]

#25549: Add tor CI config for AppVeyor
--+-
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci, tor-testing
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 At the Rome meeting, it was discussed (apparently, I wasn't there that
 time) to have an AppVeyor config for tor.  As I understand it (and please
 feel free to correct this ticket!), the idea is to have multiple CI
 systems running (which is a thing we already do!). For example, currently,
 we have [https://jenkins.torproject.org Jenkins] and we also have TravisCI
 for personal (Github-based) forks (as per #22636): Jenkins tests
 (essentially) (Debian package-based) builds on `master` and known
 (supported) tor versions, while Travis tests ''anything any developer
 pushes'' (albeit only for GCC/Clang on Linux, because everything else is
 unsupported/slow).

 We should setup an AppVeyor config for testing tor on Windows. Ideally, it
 should match the testing behaviour of our Jenkins/Travis builds, so that
 we don't get spurious errors on one system or another.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-
Changes (by nickm):

 * status:  reopened => needs_review


Comment:

 I think that my branch `move_torlog_rust_declarations` shoudl fix this, if
 I have it diagnosed properly.  Currently trying it with Travis on github.

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

Re: [tor-bugs] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 A few proposed amendments to the community council guidelines and
 procedures.  Many of these would require votes.

   * I think people should be able to publicly nominate others for the
 community council; nominees  should be free to decline or accept the
 nomination.

   * Community council deliberations should come with a self-imposed time
 limit, and a policy of what happens if the council cannot reach a
 decision.  A suggested time limit is one month, or two months at the most.
 Possible fallback actions are: "Take no action"; "Declare that they cannot
 come to a decision"; "Choose some mutually agreed upon project member to
 arbitrate and decide";

   * Community council members terms should be somehow staggered or
 arranged to overlap, so that the entire council is not so likely to all
 have their terms end at once.

   * Possibly, unanimity should not be required; best effort unanimity,
 falling back to unanimity-minus-one, may be enough.

   * Possibly, the CC should adopt the policy that the Tor bylaws have for
 absent board members, to survive attendance issues.

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

Re: [tor-bugs] #25534 [Core Tor/Tor]: Reachability of fallback directories

[Tor Bug Tracker & Wiki]

#25534: Reachability of fallback directories
-+
 Reporter:  anadahz  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  reachability, tcp connect, ooni  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by anadahz):

 Replying to [comment:3 nickm]:
 > Terminology note: these are "fallback directories", not "fallback
 directory authorities".

 Thanks for the terminology note, updated the ticket accordingly.

 > Should this be an Ooni ticket? It doesn't seem to be something we can
 address in Core Tor...

 Perhaps the contents of `fallback_dirs.inc` should be populated in a
 format (ticket:25534#comment:2) that can be added directly to ooni-
 resources repository ([https://github.com/OpenObservatory/ooni-
 resources/blob/master/bridge_reachability/tor-bridges-ip-port.csv|bridge
 reachability input list]). Having such a format ensures that we are going
 to have the input list up to date. Ideally this should also happen to the
 bridges (at least the ones listed in Tor Browser), directory authorities
 are not changing that often.

 The relevant OONI ticket: https://github.com/OpenObservatory/ooni-
 resources/issues/11

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

Re: [tor-bugs] #25534 [Core Tor/Tor]: Reachability of fallback directories (was: Reachability of fallback directory authorities)

[Tor Bug Tracker & Wiki]

#25534: Reachability of fallback directories
-+
 Reporter:  anadahz  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  reachability, tcp connect, ooni  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by anadahz:

Old description:

> The OONI probe TCP connect test (run by default from many probes)
> currently tests the TCP connectivity (successful connection: true/false)
> of the directory authorities and brigdes.
>
> This ticket is about adding the fallback directory authorities
> (https://gitweb.torproject.org/tor.git/plain/src/or/fallback_dirs.inc)
> to the TCP connect OONI probe test (https://github.com/TheTorProject
> /ooni-spec/blob/master/test-specs/ts-008-tcp-connect.md).
>
> Ideally this list should be easily generated (with the help of a script)
> and be accurate (up to date). The list currently lives on the ooni-
> resource repository:
> https://github.com/OpenObservatory/ooni-
> resources/blob/master/bridge_reachability/tor-bridges-ip-port.csv

New description:

 The OONI probe TCP connect test (run by default from many probes)
 currently tests the TCP connectivity (successful connection: true/false)
 of the directory authorities and brigdes.

 This ticket is about adding the fallback directories
 (https://gitweb.torproject.org/tor.git/plain/src/or/fallback_dirs.inc)
 to the TCP connect OONI probe test (https://github.com/TheTorProject/ooni-
 spec/blob/master/test-specs/ts-008-tcp-connect.md).

 Ideally this list should be easily generated (with the help of a script)
 and be accurate (up to date). The list currently lives on the ooni-
 resource repository:
 https://github.com/OpenObservatory/ooni-
 resources/blob/master/bridge_reachability/tor-bridges-ip-port.csv

--

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

Re: [tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
+--
 Reporter:  isis|  Owner:  (none)
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-doc, review-group-35  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorM
+--

Comment (by nickm):

 I'm okay with doing just the script update (to not remove dependencies,
 and to allow duplicate copies) for now. :)

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-
Changes (by isis):

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


Comment:

 Clang builds are [https://travis-
 ci.org/isislovecruft/tor/jobs/355600626#L1373 failing] on Travis because
 of `-Wmissing-variable-definitions`:

 {{{
 src/common/log.c:57:11: error: no previous extern declaration for non-
 static
   variable 'LOG_WARN_' [-Werror,-Wmissing-variable-declarations]
 const int LOG_WARN_ = LOG_WARN;
 }}}

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

Re: [tor-bugs] #24031 [Core Tor/Tor]: Protover.rs could use a better algorithm

[Tor Bug Tracker & Wiki]

#24031: Protover.rs could use a better algorithm
+
 Reporter:  nickm   |  Owner:  isis
 Type:  defect  | Status:  needs_revision
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust 033-must protover  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by isis):

 * status:  accepted => needs_revision


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

Re: [tor-bugs] #24031 [Core Tor/Tor]: Protover.rs could use a better algorithm

[Tor Bug Tracker & Wiki]

#24031: Protover.rs could use a better algorithm
+
 Reporter:  nickm   |  Owner:  isis
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust 033-must protover  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by isis):

 Okay, I have an WIP (done actually, but I need to split it nicely into
 commits) implementation in my `bug24031` branch.

 Warning that I uh… also went a bit nuts on refactoring to have actual
 types for different things, moving functions into them as methods, and
 making them more rusty e.g. implementing proper traits like `impl
 std::str::FromStr for ProtoEntry` instead of having stuff like
 `SupportedProtocols::from_proto_entries_string`. The types are much nicer
 however, they really helped me reason about the code, and also I found
 several differences in behaviour to the C (which were due to us not having
 as much type safety as we could, e.g. if something doesn't parse correctly
 into a type, we want to make sure we're treating it the same way as when C
 can't parse it into a `proto_entry_t` or whatever, instead of just saying
 "this is a String" and "this is a HashMap").

 Caveat emptor that even though I found some differences in return
 codes/parsing/etc to the C, I'm still not fully convinced there aren't
 more, and we should definitely do #24265 soon.

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

Re: [tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
+--
 Reporter:  isis|  Owner:  (none)
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-doc, review-group-35  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorM
+--

Comment (by isis):

 Replying to [comment:6 nickm]:
 > Hm.  I'm hoping that it's okay to take this in 0.3.3 and 0.3.4: it
 rebases cleanly to 0.3.3, but getting it into 0.3.2 would take more
 conflict-resolution than I have.
 >
 > Assuming that's the case, I made a branch called `bug25310_033` ... and
 then I ran into trouble.  If I don't update the libc dependency in tor-
 rust-dependencies, then the build will fail.  But if I do update the
 dependency, then 0.3.1 and 0.3.2 will fail (assuming they use libc), since
 the updateRustDependencies script will delete libc-0.2.2.22.
 >
 > Two options here:
 >
 >   1. Maybe we should update the updateRustDependencies.sh script so that
 it adds new crates, but does not remove the old ones, since they may still
 be needed for older Tors?
 >   2. Maybe we should update all the old tor branches to libc-0.2.39 for
 now, but also search for a better solution?

 (Oh no… why do I feel like this is going to result in us eventually
 implementing a custom dependency resolution algorithm… oh no… oh no…)

 I feel like !#1 would be the best option for now? And probably I should
 add a table in the README of tor-rust-dependencies, for each version we're
 currently maintaining, like:

 0.3.2

 || dependency || version  ||
 || libc   || 0.2.2.22 ||

 0.3.3

 || dependency || version  ||
 || libc   || 0.2.2.39 ||

 0.3.4

 || dependency || version  ||
 || libc   || 0.2.2.39 ||
 || rand   || 0.4.2||

 etc.? Then when a tor version drops out of support, we can remove
 whichever dependencies are no longer in a maintained version? Does that
 sound like a good idea? (Also document that we do this, of course.)

 I guess the other thing to do would be to just keep them all forever…
 doing so would at least allow someone to build older, unsupported tors
 later if they wanted to.

 I'll update the script to no longer remove dependencies and allow
 duplicate copies of dependencies.

 Re !#2: we might want to update 0.3.1 and 0.3.2 for now, if we care about
 *BSD and Solaris (I think there's also a few *nix patches between 0.2.22
 and 0.2.39 as well, but I didn't really look to see how vital any of them
 were)? But then again, it means the next versions in those series will
 build, while older/current ones will not (not sure how much we care).

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-

Comment (by nickm):

 Great!  Merged that one to master, with minor conflict resolution, in
 d8893bc93c52e1edd0a76b81f5d65bb10d790474

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  implemented
  review-group-34|  Actual Points:
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
+--
 Reporter:  isis|  Owner:  (none)
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-doc, review-group-35  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorM
+--

Comment (by nickm):

 Hm.  I'm hoping that it's okay to take this in 0.3.3 and 0.3.4: it rebases
 cleanly to 0.3.3, but getting it into 0.3.2 would take more conflict-
 resolution than I have.

 Assuming that's the case, I made a branch called `bug25310_033` ... and
 then I ran into trouble.  If I don't update the libc dependency in tor-
 rust-dependencies, then the build will fail.  But if I do update the
 dependency, then 0.3.1 and 0.3.2 will fail (assuming they use libc), since
 the updateRustDependencies script will delete libc-0.2.2.22.

 Two options here:

   1. Maybe we should update the updateRustDependencies.sh script so that
 it adds new crates, but does not remove the old ones, since they may still
 be needed for older Tors?
   2. Maybe we should update all the old tor branches to libc-0.2.39 for
 now, but also search for a better solution?

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 New PNG and PDF look good! Thanks!

 Next step: write the code to include these files if no graph can be
 generated.

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

Re: [tor-bugs] #25450 [Core Tor/Tor]: Intermittent test failures for hs_service/service_intro_point

[Tor Bug Tracker & Wiki]

#25450: Intermittent test failures for hs_service/service_intro_point
-+-
 Reporter:  isis |  Owner:  isis
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Minor| Resolution:  fixed
 Keywords:  tor-unittests review-group-35|  Actual Points:
  031-backport 032-backport  |
Parent ID:   | Points:  .5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


Comment:

 Okay, cool!  I've cherry-picked that to 0.3.2 and merged it forward.
 Marking this ticket closed again ... this time for reals?

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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh |Sponsor:
---+-

Comment (by karsten):

 colchicifolium only uses 93G of its 245G right now. That number goes up
 over time, until I manually clean up. But in theory, 145G should also be
 sufficient for colchicifolium.

 Anyway, let's rather discuss these issues at the team meeting than here.

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

Re: [tor-bugs] #22594 [Metrics/Onionoo]: Escape characters in contact lines break hourly updater

[Tor Bug Tracker & Wiki]

#22594: Escape characters in contact lines break hourly updater
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Looks good! Two things:
  - Can you add a change log entry? Maybe something like this: ''Don't
 attempt to un-escape character sequences in contact lines (like "\uk")
 that only happen to start like escaped utf-8 characters (like "\u0055").''
  - There's similar code where we replace `"u"` with `"\\u"` in
 `ResponseBuilder`. Does it make sense to use the new method there, too?

 Thanks!

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Anything new on this topic? There still seem to be open questions.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-

Comment (by isis):

 Replying to [comment:44 nickm]:
 > When I try to build this, I get some wide-line warnings in torlog.h from
 your d560384fd948ad24625312ee07e04f0cb60ac5b5 .
 >
 > Also, I think that d560384fd948ad24625312ee07e04f0cb60ac5b5 is breaking
 the compilation, since I see a bunch of these linker warnings:
 > {{{
 > src/common/libor-
 event.a(procmon.o):/home/nickm/src/tor/src/common/torlog.h:146: multiple
 definition of `LOG_WARN_'
 > src/or/libtor.a(main.o):/home/nickm/src/tor/./src/common/torlog.h:146:
 first defined here
 > }}}
 >
 > Maybe we should just remove d560384fd948ad24625312ee07e04f0cb60ac5b5 and
 merge the rest?

 Sounds good to me. I've made `bug23881_r1` which is exactly the same
 branch, just without d560384f.

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

Re: [tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
+--
 Reporter:  isis|  Owner:  (none)
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-doc, review-group-35  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorM
+--

Comment (by isis):

 Replying to [comment:4 nickm]:
 > This LGTM.  Should I take it 0.3.3 or earlier, or is 0.3.4-only fine?

 Whichever backports you're okay with? We started supported Rust in 0.3.1,
 right? And I started documenting our standards in 0.3.2… so if you decide
 to backport, maybe take it back to 0.3.2?

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

Re: [tor-bugs] #25450 [Core Tor/Tor]: Intermittent test failures for hs_service/service_intro_point

[Tor Bug Tracker & Wiki]

#25450: Intermittent test failures for hs_service/service_intro_point
-+-
 Reporter:  isis |  Owner:  isis
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Minor| Resolution:
 Keywords:  tor-unittests review-group-35|  Actual Points:
  031-backport 032-backport  |
Parent ID:   | Points:  .5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * status:  reopened => merge_ready


Comment:

 Okay, there's a fix for that, as another commit in my `bug25450` branch
 (along with a comment above the test so that nobody misses the distinction
 between the two assertions like I just did again).

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

Re: [tor-bugs] #25450 [Core Tor/Tor]: Intermittent test failures for hs_service/service_intro_point

[Tor Bug Tracker & Wiki]

#25450: Intermittent test failures for hs_service/service_intro_point
-+-
 Reporter:  isis |  Owner:  isis
 Type:  defect   | Status:
 |  reopened
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.3-alpha
 Severity:  Minor| Resolution:
 Keywords:  tor-unittests review-group-35|  Actual Points:
  031-backport 032-backport  |
Parent ID:   | Points:  .5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by isis):

 Replying to [comment:11 nickm]:
 > I've seen this on one of the jenkins builders:
 > {{{
 > 10:21:25 hs_service/service_intro_point: [forking]
 > 10:21:25   FAIL ../tor/src/test/test_hs_service.c:423:
 assert(ip->time_to_expire OP_LE now +
 > INTRO_POINT_LIFETIME_MAX_SECONDS - 500): 1521540810 vs 1521540658
 > }}}
 >
 > Should that `-` be a `+`?

 Hmmm… originally it was a `+`, but that appeared to cause ''more''
 failures, so I changed it to a `-` with
 [https://trac.torproject.org/projects/tor/ticket/25450#comment:3 this
 reasoning (above)].

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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh |Sponsor:
---+-

Comment (by iwakeh):

 corsicum runs 1.5.1, too, and snych's webstats from now on.

 One prerequisite for making corsicum the main instance is more space:
  colchicifolium has 245G
  corsicum 145G

 But, now that there is more data sources webstats and soon to come contrib
 it might be good to set that to 500G.

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201803R,  |  Actual Points:
  boklm201803|
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:54 gk]:
 > Replying to [comment:53 cypherpunks]:
 > > Replying to [comment:52 gk]:
 > > > Replying to [comment:49 cypherpunks]:
 > > > > Replying to [comment:48 boklm]:
 > > > > You can easily back out the above mentioned 3-line patch and test
 the latest binutils. Switching to ucrtbase.dll from your home-made
 msvcrt.dll hack looks better, though.
 > > >
 > > > Yes, but the ucrtbase approach is not ready yet, alas. It's not
 sufficiently mature yet for getting used for our Windows builds.
 > > It has been run on TC for quite some time, and Tom didn't file any
 issue with it. So, could you explain what is missing?
 >
 > Beacuse he is not using ucrtbase yet but plain msvcrt (you are using the
 former with `--with-default-msvcrt=ucrtbase`).
 Oh, he was going to solve some issues by using it, but it didn't happen,
 heh.
 > See: https://bugzilla.mozilla.org/show_bug.cgi?id=1390583#c51 for an
 unresolved issue.
 Weird. Does `--with-default-msvcrt=msvcr100` work for you?

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

Re: [tor-bugs] #24203 [Core Tor/Tor]: AppArmor default config blocks Snowflake from running with system tor

[Tor Bug Tracker & Wiki]

#24203: AppArmor default config blocks Snowflake from running with system tor
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  snowflake |  Actual Points:
Parent ID:  #19409| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arlolra):

 Yes, but I assumed that was part of #19409

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

Re: [tor-bugs] #25509 [Applications/Tor Launcher]: Tor browser tells me "A local proxy is needed when connecting through a company, school, or university network"

[Tor Bug Tracker & Wiki]

#25509: Tor browser tells me "A local proxy is needed when connecting through a
company, school, or university network"
---+---
 Reporter:  arma   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201803   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: isabela, tbb-team (added)
 * owner:  tbb-team => brade
 * component:  Applications/Tor Browser => Applications/Tor Launcher


Comment:

 We had a ticket for this (#24200) but Isabela closed it :)

 We could use some feedback from the UX team and/or from real users, but
 "might be needed" certainly seems like an improvement to me. Does anyone
 want to volunteer to lead a process for improving the text or should we
 just do the simple thing and implement Roger's suggested change?

 For the record, the question and explanatory text that previously appeared
 on the wizard screen (prior to Tor Browser 7.5) was:
  Does this computer need to use a local proxy to access the Internet?
  o Yes
  o No

  In most cases a local proxy is not needed, but it may be required when
 connecting through a company, school, or university network.

  If you are not sure how to answer this question, look at the Internet
 settings in another browser or check your system's network settings to see
 whether a local proxy is needed.

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

Re: [tor-bugs] #24203 [Core Tor/Tor]: AppArmor default config blocks Snowflake from running with system tor

[Tor Bug Tracker & Wiki]

#24203: AppArmor default config blocks Snowflake from running with system tor
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  snowflake |  Actual Points:
Parent ID:  #19409| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Aren't the `/etc/apparmor.d/abstractions/tor` changes still needed?

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

Re: [tor-bugs] #20887 [Core Tor/Tor]: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead

[Tor Bug Tracker & Wiki]

#20887: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d 
instead
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.8.1-alpha
 Severity:  Normal  | Resolution:  fixed
 Keywords:  easy, refactor, logging, tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

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


Comment:

 merged to master as bc5f79b95c5f809635bc84dbdd3010350bfbc269 with a tweak
 to the changes file so make check would pass.

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

Re: [tor-bugs] #20887 [Core Tor/Tor]: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead

[Tor Bug Tracker & Wiki]

#20887: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d 
instead
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor, logging, tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 lgtm; thanks for the fast turnaround!  Merging to master.

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

Re: [tor-bugs] #20887 [Core Tor/Tor]: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead

[Tor Bug Tracker & Wiki]

#20887: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d 
instead
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor, logging, tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by neel):

 Replying to [comment:9 nickm]:
 > There's a problem with this patch -- it removes the blank spaces before
 the quotation marks at the end of some of the lines.  Without those blank
 spaces, there will not be appropriate spacing between words in the log
 message.
 >
 > For example, this code
 > {{{
 >  tor_asprintf(msg, "Being a directory cache (default) with less
 than"
 >  "%d MB of memory is not recommended and may
 consume"
 >  "most of the available resources, consider
 disabling "
 >  "this functionality by setting the DirCache option
 "
 >  "to 0.", DIRCACHE_MIN_MEM_MB);
 > }}}
 > will produce a log message beginning with:
 > > Being a directory cache (default) with less than300 MB of memory is
 not recommended and may consumemost of the available resources...
 >
 > Note the "than300" and "consumemost" problem.
 >
 > Also, while we're changing this, let's replace the comma before
 "consider" with a period: those are two separate sentences.


 I made the changes in the patch `b20887-p2.patch`.

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

Re: [tor-bugs] #20887 [Core Tor/Tor]: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead

[Tor Bug Tracker & Wiki]

#20887: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d 
instead
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor, logging, tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by neel):

 * Attachment "b20887-p2.patch" added.

 [PATCH] Change to tor_asprintf for DIRCACHE_MIN_MB_BANDWIDTH in
 have_enough_mem_for_dircache() (Revision 1)

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

Re: [tor-bugs] #20212 [Applications/Tor Browser]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
-+-
 Reporter:  gacar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:9 cypherpunks]:
 > Why limit the number of onion addresses that can be embedded instead of
 limiting the number of circuits that can be created for onions in a single
 origin?

 The former should be relatively easy to implement in Tor Browser, while
 the latter would presumably be much more difficult and error prone (if
 implemented by monitoring circuit events on the control port). The simple
 approach of limiting the number of onions seems like it would indirectly
 limit the number of circuits, but reading the above question I'm suddenly
 having doubts. (How quickly can Tor Browser cause more circuits to be made
 by continually retrying just one onion that is failing to rendezvous?)

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

Re: [tor-bugs] #24203 [Core Tor/Tor]: AppArmor default config blocks Snowflake from running with system tor

[Tor Bug Tracker & Wiki]

#24203: AppArmor default config blocks Snowflake from running with system tor
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  snowflake |  Actual Points:
Parent ID:  #19409| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arlolra):

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


Comment:

 > This will continue to be a problem until we bump the version.

 Should be resolved by #25449

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

Re: [tor-bugs] #9898 [Applications/Tor Browser]: Provide a clean fix for the strcmpi issue in mingw-w64 for NSPR if TBBs are built with rbm

[Tor Bug Tracker & Wiki]

#9898: Provide a clean fix for the strcmpi issue in mingw-w64 for NSPR if TBBs 
are
built with rbm
--+--
 Reporter:  gk|  Owner:  tom
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, ff60-esr |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:8 gk]:
 > Having this solved would still be pretty helpful.
 Yes, as Martin solved it for ucrt only.
 > While the `strcmpi` issue is gone for ESR60 as we don't support Win XP
 anymore
 In ticket:9084#comment:25 you wrote something a little bit different.
 > we have a new one with a missing `_create_locale` on Windows 7 only.
 Only that? Or is #23811 needed too?

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

Re: [tor-bugs] #25424 [Webpages/Blog]: view-by-tag has broken output

[Tor Bug Tracker & Wiki]

#25424: view-by-tag has broken output
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

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


Comment:

 Closing since mysteriously now it works.

 Theories include: "the blog software has been updated a few times since
 this ticket, maybe that fixed it" and "I wonder if you loaded the page
 during or right after an update".

 Who knows. Let's try to check every so often and see if it re-broke.

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

Re: [tor-bugs] #23854 [Metrics/Website]: Add an RSS feed for https://metrics.torproject.org/news.html

[Tor Bug Tracker & Wiki]

#23854: Add an RSS feed for https://metrics.torproject.org/news.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:8 irl]:
 > Can you point me at the tool you're using to import changes from the
 wiki? I wonder if I can do a little sanitising of the data there that
 would greatly simplify the output of the ATOM and remove the special
 cases.

 Please find it attached. I'm using `jq "." news-raw.json > news.json` to
 produce the final output.

 If you feel like cleaning up this code a bit and adding it to the tree,
 great. But feel free to send me a modified version back, and we'll add it
 to the repository when we have more time.

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

Re: [tor-bugs] #25518 [Metrics/Relay Search]: RS fails to display bw graphs for relays where onionoo provides 3_days level and not 1_month level data

[Tor Bug Tracker & Wiki]

#25518: RS fails to display bw graphs for relays where onionoo provides 3_days
level and not 1_month level data
--+
 Reporter:  cypherpunks   |  Owner:  irl
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by irl):

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


Comment:

 The thing I thought it would be is actually not something that could cause
 this, if there is more data than expected then the extra data is just
 ignored. As this currently looks to be working and I can't reproduce the
 error, I will close this ticket. If it happens again, then please reopen
 the ticket. It could have been a transient error in fetching the data and
 the failure was cached and not retried.

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

Re: [tor-bugs] #23854 [Metrics/Website]: Add an RSS feed for https://metrics.torproject.org/news.html

[Tor Bug Tracker & Wiki]

#23854: Add an RSS feed for https://metrics.torproject.org/news.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "UpdateNews.java" 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] #23854 [Metrics/Website]: Add an RSS feed for https://metrics.torproject.org/news.html

[Tor Bug Tracker & Wiki]

#23854: Add an RSS feed for https://metrics.torproject.org/news.html
-+--
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I have implemented the first plan in my
 [[https://gitweb.torproject.org/user/irl/metrics-
 web.git/log/?h=task/23854|task/23854 branch]]. There are a couple of
 special cases that I'd like to not have to deal with though.

 Currently the news.json assumes that the output will be HTML and that it's
 OK to have HTML inline, but ATOM is XML and has a different root
 namespace.

 Can you point me at the tool you're using to import changes from the wiki?
 I wonder if I can do a little sanitising of the data there that would
 greatly simplify the output of the ATOM and remove the special cases.

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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:6 iwakeh]:
 > Release tar.gz looks fine and passes all.

 Good!

 > Once colchicifolium has the new release I deploy it on corsicum in order
 to keep these two on the same release.

 Sounds good.

 > What about synch'ing logs to corsicum?

 Sure, why not. Going one step further, I could imagine making corsicum the
 new primary instance and syncing over everything from colchicifolium. But
 that's related to recent stability issues with colchicifolium, not to the
 new data. Let's discuss this more on Thursday.

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

Re: [tor-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * cc: mcs (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] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh |Sponsor:
---+-

Comment (by iwakeh):

 Release tar.gz looks fine and passes all.

 Once colchicifolium has the new release I deploy it on corsicum in order
 to keep these two on the same release.

 What about synch'ing logs to corsicum?

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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Release tarball is available at
 https://dist.torproject.org/collector/1.5.1/

 No need to put out an announcement for this point release, IMO.

 I'll deploy on colchicifolium shortly.

 Closing. Thanks!

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

Re: [tor-bugs] #25459 [Metrics/Analysis]: Compare total consensus weights across bandwidth authorities

[Tor Bug Tracker & Wiki]

#25459: Compare total consensus weights across bandwidth authorities
--+--
 Reporter:  teor  |  Owner:  karsten
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nikita):

 * cc: nikita (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] #22594 [Metrics/Onionoo]: Escape characters in contact lines break hourly updater

[Tor Bug Tracker & Wiki]

#22594: Escape characters in contact lines break hourly updater
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/commit/?h=task-22594
 this patch], which avoid the above troubles, i.e., NFE, by only un-
 escaping valid utf.

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

Re: [tor-bugs] #20212 [Applications/Tor Browser]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
-+-
 Reporter:  gacar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Why limit the number of onion addresses that can be embedded instead of
 limiting the number of circuits that can be created for onions in a single
 origin?

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

Re: [tor-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pospeselr):

 * status:  new => assigned
 * owner:  tbb-team => pospeselr


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

Re: [tor-bugs] #9898 [Applications/Tor Browser]: Provide a clean fix for the strcmpi issue in mingw-w64 for NSPR if TBBs are built with rbm

[Tor Bug Tracker & Wiki]

#9898: Provide a clean fix for the strcmpi issue in mingw-w64 for NSPR if TBBs 
are
built with rbm
--+--
 Reporter:  gk|  Owner:  tom
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, ff60-esr |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: tbb-team (added)


Comment:

 Having this solved would still be pretty helpful. While the `strcmpi`
 issue is gone for ESR60 as we don't support Win XP anymore we have a new
 one with a missing `_create_locale` on Windows 7 only.

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

Re: [tor-bugs] #20212 [Applications/Tor Browser]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
-+-
 Reporter:  gacar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: mcs, brade (added)
 * keywords:  guard-discovery => guard-discovery, TorBrowserTeam201803


Comment:

 Replying to [comment:7 gk]:
 > Replying to [comment:6 asn]:
 > > How should we proceed here? Leif suggested we introduce a
 `Max3rdPartyOnions` option ''to limit the number of onion addresses that
 an origin is allowed to cause the browser to make connections to''.
 > >
 > > Do we think this is a reasonable approach? And what should the default
 value be? Can we add this to our TB roadmap in some capacity?
 >
 > You mean this should be fixed on the browser side? It seems to me having
 a patch in tor makes more sense.

 After some more discussion happened, let's try to fix that on the browser
 side (first). mcs/brade: can you look into 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] #17965 [Applications/Tor Browser]: Isolate HPKP and HSTS to url bar domain

[Tor Bug Tracker & Wiki]

#17965: Isolate HPKP and HSTS to url bar domain
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201803   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Why does improving Tor Browser have a lower prio than upstreaming?

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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh |Sponsor:
---+--

Comment (by iwakeh):

 Branch looks fine, pre-release compiles fine, passes all tests,
 bytecode is reproducible from given sources, jar signatures are fine.

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

[tor-bugs] #25548 [Applications/Tor Browser]: Update macOS SDK for Tor Browser builds to 10.11

[Tor Bug Tracker & Wiki]

#25548: Update macOS SDK for Tor Browser builds to 10.11
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr
Actual Points:|  Parent ID:  #24632
   Points:|   Reviewer:
  Sponsor:|
--+--
 We need for ESR60-based Tor Browsers a newer macOS SDK.

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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh |Sponsor:
---+--
Changes (by karsten):

 * cc: metrics-team, iwakeh (added)
 * reviewer:   => iwakeh


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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 Please check this
 [https://people.torproject.org/~karsten/volatile/collector-1.5.1-pre0.tar.gz
 pre-release tarball].

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * Attachment "no-data-available.tar.xz" added.

 XCF, PNG and PDF, resized to the correct dimensions this time

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

Re: [tor-bugs] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Please review [https://gitweb.torproject.org/karsten/metrics-
 db.git/commit/?h=task-25547=60ac1936169e35d598f5bcbdad616dabd656729d
 commit 60ac193 in my task-25547 branch]. Pre-release tarball follows
 shortly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25547 [Metrics/CollecTor]: Put out CollecTor 1.5.1

[Tor Bug Tracker & Wiki]

#25547: Put out CollecTor 1.5.1
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 We have an important fix in CollecTor master that fixes sanitizing
 webstats files. Let's put out a point release and then deploy the new
 release on colchicifolium. Tracking the release process 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] #25525 [Metrics/CollecTor]: Fix either spec or code regarding full path of sanitized webstats files

[Tor Bug Tracker & Wiki]

#25525: Fix either spec or code regarding full path of sanitized webstats files
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

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


Comment:

 Sounds good. Fixed the spec. Closing. Thanks!

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

Re: [tor-bugs] #25517 [Core Tor/Tor]: TROVE-2018-005

[Tor Bug Tracker & Wiki]

#25517: TROVE-2018-005
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  trove |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #24765 [Core Tor/Tor]: What version of Rust does Tor require for 0.3.2?

[Tor Bug Tracker & Wiki]

#24765: What version of Rust does Tor require for 0.3.2?
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, doc |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 "Latest nightly" makes me pretty nervous, but I think "latest stable"
 isn't too bad.

 In Rome I talked to Ximin about Debian's Rust packaging, and learned that
 Debian is apparently tracking latest stable too, so we probably won't get
 forced to freeze a rust version until the next Debian release starts to
 freeze.

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

Re: [tor-bugs] #20887 [Core Tor/Tor]: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead

[Tor Bug Tracker & Wiki]

#20887: DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d 
instead
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor, logging, tor-relay  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * status:  merge_ready => needs_revision
 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


Comment:

 There's a problem with this patch -- it removes the blank spaces before
 the quotation marks at the end of some of the lines.  Without those blank
 spaces, there will not be appropriate spacing between words in the log
 message.

 For example, this code
 {{{
  tor_asprintf(msg, "Being a directory cache (default) with less than"
"%d MB of memory is not recommended and may
 consume"
"most of the available resources, consider
 disabling "
"this functionality by setting the DirCache option
 "
"to 0.", DIRCACHE_MIN_MEM_MB);
 }}}
 will produce a log message beginning with:
 > Being a directory cache (default) with less than300 MB of memory is not
 recommended and may consumemost of the available resources...

 Note the "than300" and "consumemost" problem.

 Also, while we're changing this, let's replace the comma before "consider"
 with a period: those are two separate sentences.

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

Re: [tor-bugs] #25541 [Metrics/Relay Search]: Tor metrics says my relay has been off-line for a day but SSHing to it shows no problems

[Tor Bug Tracker & Wiki]

#25541: Tor metrics  says my relay has been off-line for a day but SSHing to it
shows no problems
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  metrics-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 cypherpunks beat me to replying, but that was pretty much what I was going
 to say.

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

Re: [tor-bugs] #25541 [Metrics/Relay Search]: Tor metrics says my relay has been off-line for a day but SSHing to it shows no problems

[Tor Bug Tracker & Wiki]

#25541: Tor metrics  says my relay has been off-line for a day but SSHing to it
shows no problems
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  metrics-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 there has been a temporary outage of onionoo (not providing new data for
 several hours),
 so if it was down shortly it looked like it was down for longer on RS.

 Since it is up again I consider this as closed, please reopen if you
 disagree.

 (metrics does not decide if your relay is up or not, it merely displays
 dir auth data)

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

Re: [tor-bugs] #25245 [Core Tor/Tor]: Crash in assert_connection_ok when changing Exit options

[Tor Bug Tracker & Wiki]

#25245: Crash in assert_connection_ok when changing Exit options
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  crash, regression?, tor-exit, tor-   |  Actual Points:
  relay, ipv6|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Hm.  We don't actually want to close all of the "Foo" connections when the
 "FooListener" is closed.  If we did that, then our hibernation code would
 break, since it assumes that you we continue servicing existing
 connections after we've closed all the listeners.

 I think instead the problem here is that there is something wrong with the
 tor_assert().  Can you help me understand how the problem here relates to
 the fix?  That is, why does setting ExitRelay 0 make these connections
 trigger the assertion if they do not get closed?

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

Re: [tor-bugs] #25541 [Metrics/Relay Search]: Tor metrics says my relay has been off-line for a day but SSHing to it shows no problems

[Tor Bug Tracker & Wiki]

#25541: Tor metrics  says my relay has been off-line for a day but SSHing to it
shows no problems
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * component:  Metrics => Metrics/Relay Search


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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Yes, I think it looks better in gray.

 Do you mind cutting off a few pixels at the top to make it 728 by ''455''
 (not 728 by 479)? That's the dimensions we're using for all graphs.

 And can you provide a PDF file with the same dimensions?

 If you want to grab this ticket and write the code, feel free to do it.

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

Re: [tor-bugs] #24487 [Core Tor/Tor]: Reverse path selection (choose outer hops first)

[Tor Bug Tracker & Wiki]

#24487: Reverse path selection (choose outer hops first)
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller   |  Actual Points:
  needs-proposal |
Parent ID:  #25546   | Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-
Changes (by asn):

 * parent:  #9001 => #25546


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

Re: [tor-bugs] #25400 [Core Tor/Tor]: CIRC_BW event miscounts, should count all circ data

[Tor Bug Tracker & Wiki]

#25400: CIRC_BW event miscounts, should count all circ data
+--
 Reporter:  mikeperry   |  Owner:  mikeperry
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-stats, review-group-34  |  Actual Points:
Parent ID:  #25546  | Points:
 Reviewer:  dgoulet |Sponsor:
+--
Changes (by asn):

 * parent:   => #25546


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25546 [Core Tor/Tor]: Merge last vanguard-related tor patches

[Tor Bug Tracker & Wiki]

#25546: Merge last vanguard-related tor patches
--+---
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-guard guard-discovery
Actual Points:|  Parent ID:
   Points:|   Reviewer:  asn
  Sponsor:|
--+---
 There are a few remaining vanguard-related tor patches that need to be
 merged to little-t-tor to improve correctness and performance of the
 vanguard 3rd-party script.

 Let's get these merged.

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

Re: [tor-bugs] #25541 [Metrics]: Tor metrics says my relay has been off-line for a day but SSHing to it shows no problems

[Tor Bug Tracker & Wiki]

#25541: Tor metrics  says my relay has been off-line for a day but SSHing to it
shows no problems
---+--
 Reporter:  Dbryrtfbcbhgf  |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics|Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by nickm):

 * owner:  (none) => metrics-team
 * component:  Core Tor/Tor => Metrics


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25545 [Core Tor/Tor]: Figure out default vanguard script parameters

[Tor Bug Tracker & Wiki]

#25545: Figure out default vanguard script parameters
--+---
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-guard guard-discovery
Actual Points:|  Parent ID:
   Points:|   Reviewer:  mikeperry
  Sponsor:  SponsorV  |
--+---
 We should run our vanguard security simulator to figure out good values
 for the default number of guards in each guard layer so that security is
 good and performance is also reasonable.

 This is a master ticket for our roadmap.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-

Comment (by nickm):

 Other than that, I'm pretty satisfied that my review issues were all
 addressed.  If I find anything else, it can be a post-merge followup
 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

[tor-bugs] #25544 [Core Tor/Tor]: Complete vanguard specification

[Tor Bug Tracker & Wiki]

#25544: Complete vanguard specification
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core   |Version:
  Tor/Tor  |
 Severity:  Normal |   Keywords:  tor-guard torspec guard-discovery
Actual Points: |  Parent ID:
   Points: |   Reviewer:  asn
  Sponsor:  SponsorV   |
---+---
 We should revise the vanguard proposal (prop247) to be less ambitious and
 more down-to-earth and closer to what mike's vanguard script is going to
 be doing.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-dos, tor-relay, review-  |  Actual Points:
  group-30, 029-backport, 031-backport,  |
  032-backport, review-group-31, SponsorV|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by cypherpunks):

 FWIW, Firefox can open more than 100 connections at once, so it is a
 relatively small threshold.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 When I try to build this, I get some wide-line warnings in torlog.h from
 your d560384fd948ad24625312ee07e04f0cb60ac5b5 .

 Also, I think that d560384fd948ad24625312ee07e04f0cb60ac5b5 is breaking
 the compilation, since I see a bunch of these linker warnings:
 {{{
 src/common/libor-
 event.a(procmon.o):/home/nickm/src/tor/src/common/torlog.h:146: multiple
 definition of `LOG_WARN_'
 src/or/libtor.a(main.o):/home/nickm/src/tor/./src/common/torlog.h:146:
 first defined here
 }}}

 Maybe we should just remove d560384fd948ad24625312ee07e04f0cb60ac5b5 and
 merge the rest?

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, review-group-29,   |  Actual Points:
  review-group-34|
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-

Comment (by nickm):

 Replying to [comment:40 isis]:
 > Yesterday I tried to find a way to get the name of the current function
 we're being called from, so that we wouldn't have to manually type it out
 everytime we log something. It seems like there [https://github.com/rust-
 lang/rfcs/pull/1719 was a proposed RFC] to make this info available, but
 it unfortunately stalled out.

 Hm.  Yeah, if this isn't available, it isn't available.  Let's put it on
 the wishlist (assuming we have one?)

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

Re: [tor-bugs] #14389 [Applications/Tor Browser]: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: Improve TBB UI of hidden service client authorization
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by antonela):

 * Attachment "14389-2.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] #14389 [Applications/Tor Browser]: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: Improve TBB UI of hidden service client authorization
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by antonela):

 Thanks for your reply Arthur!

 Replying to [comment:25 arthuredelstein]:
 >
 > * I am reluctant to save a list of websites and passwords on the user's
 machine. On the other hand, it's inconvenient to have to repeatedly enter
 a password. So maybe we could allow saving the onion password behind a
 master password, using Firefox's password manager? (I don't know anything
 about Firefox's password manager yet. We would need the encrypted password
 database to hide the list of individual usernames and sites.)

 Got it. Saving credentials were something we talked about, but I can
 understand the risks of it. If we are not going to offer this feature to
 users, maybe an HTTP Basic Auth dialog box is fair enough. An UI like this
 could works better.

 > * I think it could be useful to mention in the UI that this is an Onion
 Authentication (distinct from an HTTP Basic Authentication). Maybe we even
 want a special logo. :) Also, it might help to include a "more info"
 button or similar.

 I'd love to include an onion+lock icon. I'll work on 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] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 https://styleguide.torproject.org/visuals/#colors has the approved colors.
 I could also make SVG, PDF, etc. versions if that is useful. If we do
 include a new image to be used, we should also update Relay Search at the
 same time, I can make a patch for that quite easily and then both could be
 deployed together.

 The white version of the Tor logo comes from
 https://github.com/TheTorProject/tor-media/tree/master/Tor%20Logo if you'd
 like to have a go at making your own 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] #25188 [Core Tor/Tor]: Spec bug in formal definition of Document in dir-spec.txt

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Applied to torspec as 3e533e974b15d0. Thanks again!

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

Re: [tor-bugs] #25543 [Applications/Tor Browser]: Rebase Tor Browser patches for ESR60

[Tor Bug Tracker & Wiki]

#25543: Rebase Tor Browser patches for ESR60
--+-
 Reporter:  gk|  Owner:  arthuredelstein
 Type:  task  | Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201803  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gk):

 * status:  new => assigned
 * cc: arthuredelstein (removed)
 * cc: tbb-team (added)
 * owner:  tbb-team => arthuredelstein


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25543 [Applications/Tor Browser]: Rebase Tor Browser patches for ESR60

[Tor Bug Tracker & Wiki]

#25543: Rebase Tor Browser patches for ESR60
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201803
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This is the ticket to discuss and review the rebase of our patches for
 ESR60

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Replying to [comment:7 witchof0x20]:
 > I can't immediately think of an ambiguity that would be fixed by this,
 but would it be worth it to also say 'A Keyword cannot be "-END"'?

 I think this change would make the current implementation incorrect, so
 I'm going to leave this part alone.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Sorry for the delay: yes, that looks fine.  I'll apply it to torspec 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] #25372 [Core Tor/Tor]: relay: Allocation for compression goes very high

[Tor Bug Tracker & Wiki]

#25372: relay: Allocation for compression goes very high
-+-
 Reporter:  dgoulet  |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, compression, tor-dos, |  Actual Points:
  review-group-34|
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 ahf: lgtm but please add a changes file?

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

Re: [tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies

[Tor Bug Tracker & Wiki]

#25310: Document our policy for Rust dependencies
+--
 Reporter:  isis|  Owner:  (none)
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-doc, review-group-35  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  SponsorM
+--
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 This LGTM.  Should I take it 0.3.3 or earlier, or is 0.3.4-only fine?

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

Re: [tor-bugs] #25264 [Metrics/Website]: Decide what graph to display when there's no data to graph

[Tor Bug Tracker & Wiki]

#25264: Decide what graph to display when there's no data to graph
-+--
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * Attachment "nodata.2.png" added.

 Style guide compliant no data available image - grey and resized

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 So, the somewhat safer approach I had in mind is only really possible with
 C11, which we haven't standardized on.  And my idea of how to test was
 pretty wrong: it relied on there being no padding holes within the
 routerstatus_t structure.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 oh, I did find bugs!

   * We should use memcpy() to copy the identity and descriptor digests:
 strncpy will stop copying if those digests contain any 0-valued bytes.
   * We should use strlcpy() and sizeof() to copy the nickname.

 I think that we can have a somewhat safer approach.  Hang on...

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Hm.  I think this is probably correct, but I wonder if it could be even
 more simple.

 My main concern with this patch now is that we have a new failure mode:
 instead of maybe forgetting to clear a flag, we can now maybe forget to
 preserve a field.

 Either approach would be okay if we could come up with some kind of unit
 test that ensures that we haven't missed any fields.  I think we could
 build one -- just a second...

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

Re: [tor-bugs] #20212 [Applications/Tor Browser]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
--+--
 Reporter:  gacar |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  guard-discovery   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:6 asn]:
 > How should we proceed here? Leif suggested we introduce a
 `Max3rdPartyOnions` option ''to limit the number of onion addresses that
 an origin is allowed to cause the browser to make connections to''.
 >
 > Do we think this is a reasonable approach? And what should the default
 value be? Can we add this to our TB roadmap in some capacity?

 You mean this should be fixed on the browser side? It seems to me having a
 patch in tor makes more sense.

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