Re: [tor-bugs] #20596 [Metrics]: streamline build.xml and metrics_checkstyle.xml throughout all java projects

[Tor Bug Tracker & Wiki]

#20596: streamline build.xml and metrics_checkstyle.xml throughout all java
projects
-+
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 The old sources .jar file contained paths like
 `org/torproject/descriptor/BandwidthHistory.java`, whereas the new file
 contains that file in
 `main/java/org/torproject/descriptor/BandwidthHistory.java`.  The new file
 also contains other sources and resources that the old file did not
 contain.  I'm not using sources .jar files anywhere, but I could imagine
 that some tools depend on the old directory structure, so it might be good
 to keep it.  But I don't know for sure.

 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] #20540 [Metrics]: define log-levels for all java metrics-products

[Tor Bug Tracker & Wiki]

#20540: define log-levels for all java metrics-products
-+--
 Reporter:  iwakeh   |  Owner:
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_information => needs_review


Comment:

 There, I think I made [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20540&id=30113b528dcfca39b9ecc8179f195e9558dc428d
 all changes as suggested].

 And I changed that one log statement back to an
 `IllegalArgumentException`, even though I think that's a stretch.  (I
 believe that we should only throw `RuntimeException`s at callers for
 things they're clearly responsible for, like passing `null` to us where we
 clearly said that they must not do such a thing.  But the caller does not
 have exclusive control over the file system, so it might not have been
 them who created the non-directory file.  Yeah, a stretch, gray area, edge
 case...  I don't know the final answer yet.)

 Want to take another look?

 Should I continue with the other metrics-lib classes, like
 `DescriptorReaderImpl`?

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

Re: [tor-bugs] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.

[Tor Bug Tracker & Wiki]

#11211: Multiple ServerTransportListenAddr entries should be allowed per 
transport.
-+-
 Reporter:  yawning  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, needs-proposal,  |  Actual Points:
  tor-pt, bridgedb-parsers, 028-triage, ipv6,|
  tor-03-unspecified-201612  |
Parent ID:  #10629   | Points:
 Reviewer:   |Sponsor:  T/U
-+-
Changes (by kaie):

 * cc: kaie@… (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] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.

[Tor Bug Tracker & Wiki]

#11211: Multiple ServerTransportListenAddr entries should be allowed per 
transport.
-+-
 Reporter:  yawning  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, needs-proposal,  |  Actual Points:
  tor-pt, bridgedb-parsers, 028-triage, ipv6,|
  tor-03-unspecified-201612  |
Parent ID:  #10629   | Points:
 Reviewer:   |Sponsor:  T/U
-+-

Comment (by kaie):

 I'm trying to contribute a fix for this issue.

 Would it be acceptable to use a different configuration syntax, that uses
 only a single line for each transport type, and allows multiple
 address:port combinations to be listed on the line, separated by space, as
 in the following example?

   ServerTransportListenAddr obfs3 0.0.0.0:443 [::]:443

 I discovered that the obfs4proxy tool already supports multiple addresses
 for the same transport type, as it already parses a comma separated list
 of type-address:port entries, which are passed to it by Tor in an
 environment variable.

 Looking at the Tor C code, it seems that many places assume that only a
 single configuration line (and state line) is used for any given transport
 type. My impression is, implementing the syntax I'm suggesting requires a
 much smaller amount of code changes.

 I'll attach an initial attempt to implement the above. It parses the above
 syntax, it passes the extended list to the external transport tool. It
 also saves extended TransportProxy lines into the state file, using the
 same approach that keeps a single line and allows multiple addresses.

 So far I've only tested with a test network, and only tested that the
 listeners are created. I haven't done real world testing yet.

 The code that loads and validates the state file only checks the first
 stored address:port, and will use the additional saved entries without
 validation. I've ran out of time today, this is a TODO.

 Looking forward to your feedback.

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

Re: [tor-bugs] #20596 [Metrics]: streamline build.xml and metrics_checkstyle.xml throughout all java projects

[Tor Bug Tracker & Wiki]

#20596: streamline build.xml and metrics_checkstyle.xml throughout all java
projects
-+
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by iwakeh):

 Replying to [comment:31 karsten]:
 > Okay, here's what I did and where I ran into issues:
 >
 >  - Pushed your two metrics-base patches to
 [https://gitweb.torproject.org/metrics-base.git/ metrics-base] without
 changes.
 >
 >  - Tried running `ant tar` in your
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/log/?h=task-20596-submod
 onionoo task-20596-submod branch], but it keeps telling me that signing of
 at least one of the .jars failed.  I didn't investigate further yet.  Does
 that work for you?

 That worked fine in the test setting I had, well. I'll look into it.

 >
 >  - Rebased your [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/log/?h=task-20596-submod metrics-lib task-20596-submod branch] and
 pushed it to [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-20596 branch task-20596 in my repository].  (Though
 I'm planning to squash your squash commit into "Implements task-20596"
 rather than "Added development description" when merging to master.)
 Realized that Gson is indeed unhappy, so we should keep your commit, but
 without explicit null-initializations, if possible.  However, I ran into
 two issues:
 >  - The sources jar contains sources in a different place than
 previous tarballs.
 >  - The executable jar contains other classes than just our own,
 which it shouldn't (as opposed to the other executable jars).
 >
 >  - Rebased your
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-20596-submod
 collector task-20596-submod branch] and pushed it to
 [https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-20596
 branch task-20596 in my repository].  Building seems to work fine, but I
 found this warning: "[javadoc] javadoc: error - Error while reading file
 /Users/karsten/src/collector/src/main/resources/overview.html".  I didn't
 compare .jar file contents yet but expect to find similar differences as I
 found in the metrics-lib .jar files.  Same goes for Onionoo above.
 >
 > Would you want to look into some of these issues?  I can do another
 round of tests and checks tomorrow.  Thanks!

 No problem, I'll take a look at all the issues.  Thanks for checking
 quickly!

 Could you specify the source location differences?
 And, (without knowing how weird the paths might be) is the new path
 structure problematic?

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

Re: [tor-bugs] #20596 [Metrics]: streamline build.xml and metrics_checkstyle.xml throughout all java projects

[Tor Bug Tracker & Wiki]

#20596: streamline build.xml and metrics_checkstyle.xml throughout all java
projects
-+
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Okay, here's what I did and where I ran into issues:

  - Pushed your two metrics-base patches to [https://gitweb.torproject.org
 /metrics-base.git/ metrics-base] without changes.

  - Tried running `ant tar` in your
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/log/?h=task-20596-submod
 onionoo task-20596-submod branch], but it keeps telling me that signing of
 at least one of the .jars failed.  I didn't investigate further yet.  Does
 that work for you?

  - Rebased your [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/log/?h=task-20596-submod metrics-lib task-20596-submod branch] and
 pushed it to [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-20596 branch task-20596 in my repository].  (Though
 I'm planning to squash your squash commit into "Implements task-20596"
 rather than "Added development description" when merging to master.)
 Realized that Gson is indeed unhappy, so we should keep your commit, but
 without explicit null-initializations, if possible.  However, I ran into
 two issues:
  - The sources jar contains sources in a different place than previous
 tarballs.
  - The executable jar contains other classes than just our own, which
 it shouldn't (as opposed to the other executable jars).

  - Rebased your
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-20596-submod
 collector task-20596-submod branch] and pushed it to
 [https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-20596
 branch task-20596 in my repository].  Building seems to work fine, but I
 found this warning: "[javadoc] javadoc: error - Error while reading file
 /Users/karsten/src/collector/src/main/resources/overview.html".  I didn't
 compare .jar file contents yet but expect to find similar differences as I
 found in the metrics-lib .jar files.  Same goes for Onionoo above.

 Would you want to look into some of these issues?  I can do another round
 of tests and checks tomorrow.  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] #20540 [Metrics]: define log-levels for all java metrics-products

[Tor Bug Tracker & Wiki]

#20540: define log-levels for all java metrics-products
-+---
 Reporter:  iwakeh   |  Owner:
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => needs_information


Comment:

 Set to needs_information for discussing the escalate vs. log question.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21134 [Core Tor/Tor]: Fail if file is too large to mmap.

[Tor Bug Tracker & Wiki]

#21134: Fail if file is too large to mmap.
--+---
 Reporter:  junglefowl|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal|   Keywords:  tor_mmap_file
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 If tor_mmap_file is called with a file which is larger than SIZE_MAX,
 only a small part of the file will be memory-mapped due to integer
 truncation.

 This can only realistically happen on 32 bit architectures with large
 file support.

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

Re: [tor-bugs] #21133 [Metrics/Consensus Health]: Add ed25519 relay key expire date

[Tor Bug Tracker & Wiki]

#21133: Add ed25519 relay key expire date
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by atagar):

 Briefly skimmed through the
 [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt dir-spec] for
 ed25519 and not spotting anything that looks like an expiration timestamp.
 Are these in the consensus?

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

Re: [tor-bugs] #20540 [Metrics]: define log-levels for all java metrics-products

[Tor Bug Tracker & Wiki]

#20540: define log-levels for all java metrics-products
-+--
 Reporter:  iwakeh   |  Owner:
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:8 karsten]:

 Good to continue on that!


 I really want to keep the info level
 [https://gitweb.torproject.org/user/karsten/metrics-
 
lib.git/diff/src/main/java/org/torproject/descriptor/DescriptorSourceFactory.java?h=task-20540&id=679577985141b44bed7e2a7e8dd65c3093a99243
 here], because this gives valuable runtime information.  Maybe, the text
 could be phrased differently to make it seem less 'techy'?  On the other
 hand, people running metrics-lib or other Metrics products can be expected
 to not be offended by such an info level statement.

 The two `if (log.isDebugEnabled())` are redundant as the logging statement
 is already in the good form, see
 [http://logback.qos.ch/manual/architecture.html#parametrized Parametrized
 Logging] in the Logback manual (especially the ''Better alternative''
 section). (Will add this to the wiki logging section.)

 [https://gitweb.torproject.org/user/karsten/metrics-
 
lib.git/tree/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java?id=679577985141b44bed7e2a7e8dd65c3093a99243#n56
 This] warning should contain a hint about what to do.  The sentence `Local
 directory already exists and is not a directory.` sounds quite cryptic.

 All info level statements in DescriptorIndexCollector are fine.
 [https://gitweb.torproject.org/user/karsten/metrics-
 
lib.git/tree/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java?id=679577985141b44bed7e2a7e8dd65c3093a99243#n91
 This] could be changed to `Finished descriptor collection.`?

 [https://gitweb.torproject.org/user/karsten/metrics-
 
lib.git/tree/src/main/java/org/torproject/descriptor/index/FileNode.java?id=679577985141b44bed7e2a7e8dd65c3093a99243#n70
 Here] I would add a hint to look at the error message, e.g., adding `The
 following error message provides more details.` or similar.  Something
 that makes operators pay attention and thus detect some file system errors
 or what ever.

 Why a slash in [https://gitweb.torproject.org/user/karsten/metrics-
 
lib.git/tree/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java?id=679577985141b44bed7e2a7e8dd65c3093a99243#n115
 here]: `log.debug("Fetching remote file /{} with expected ...`?

 [https://gitweb.torproject.org/user/karsten/metrics-
 
lib.git/tree/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java?id=679577985141b44bed7e2a7e8dd65c3093a99243#n57
 This] makes me raise the escalate vs. logging question, which is not yet
 covered in the logging definition.  The aborted descriptor collection
 should be propagated to the calling application, e.g., turn the warning
 into a RuntimeException with the same text.
 Thoughts?

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

Re: [tor-bugs] #17517 [Applications/Tor Messenger]: Consider using different color for "Add Exception"

[Tor Bug Tracker & Wiki]

#17517: Consider using different color for "Add Exception"
+--
 Reporter:  ilv |  Owner:  huyvq
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by ilv):

 white looks good!

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

Re: [tor-bugs] #17517 [Applications/Tor Messenger]: Consider using different color for "Add Exception"

[Tor Bug Tracker & Wiki]

#17517: Consider using different color for "Add Exception"
+--
 Reporter:  ilv |  Owner:  huyvq
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arlolra):

 Thanks, ok, let's go with that.

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

Re: [tor-bugs] #21059 [Core Tor/Tor]: shared-rand-current-value violates spec

[Tor Bug Tracker & Wiki]

#21059: shared-rand-current-value violates spec
--+
 Reporter:  atagar|  Owner:  asn
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Cut a Stem 1.5.4 hotfix release that drops this validation...

 https://gitweb.torproject.org/stem.git/commit/?id=d561974

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

Re: [tor-bugs] #21095 [Metrics/Onionoo]: Accept more values for the "order" parameter

[Tor Bug Tracker & Wiki]

#21095: Accept more values for the "order" parameter
-+--
 Reporter:  lukechilds   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-21095&id=f22b6626239a14f566d49081f55c5894fc5459a5
 this commit in my branch task-21095].

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

Re: [tor-bugs] #17517 [Applications/Tor Messenger]: Consider using different color for "Add Exception"

[Tor Bug Tracker & Wiki]

#17517: Consider using different color for "Add Exception"
+--
 Reporter:  ilv |  Owner:  huyvq
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by huyvq):

 The button is being hidden. (Please see the attachment)

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

Re: [tor-bugs] #21017 [Applications/Tor Messenger]: Tor messenger doesn't play nice with torproject jabber server

[Tor Bug Tracker & Wiki]

#21017: Tor messenger doesn't play nice with torproject jabber server
+
 Reporter:  mrphs   |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Closing since these issues are covered elsewhere.

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

Re: [tor-bugs] #18146 [Core Tor/Tor]: Tor's control protocol misspells "Dependent"

[Tor Bug Tracker & Wiki]

#18146: Tor's control protocol misspells "Dependent"
+
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Trivial | Resolution:
 Keywords:  doc tor-controller  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by jryans):

 * status:  needs_revision => merge_ready


Comment:

 Okay, updated with the expected fix version.  (I assume another round of
 review is not needed for this change.)

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

Re: [tor-bugs] #17517 [Applications/Tor Messenger]: Consider using different color for "Add Exception"

[Tor Bug Tracker & Wiki]

#17517: Consider using different color for "Add Exception"
+--
 Reporter:  ilv |  Owner:  huyvq
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  UX  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arlolra):

 The white looks clearer than the red, but what happens when you remove the
 highlight? (ie. create a second account and click on that to remove the
 blue background)

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

[tor-bugs] #21133 [Metrics/Consensus Health]: Add ed25519 relay key expire date

[Tor Bug Tracker & Wiki]

#21133: Add ed25519 relay key expire date
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 "Stem should presently support everything in descriptors." so hopefully
 the expiredate is in there.

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

Re: [tor-bugs] #20596 [Metrics]: streamline build.xml and metrics_checkstyle.xml throughout all java projects

[Tor Bug Tracker & Wiki]

#20596: streamline build.xml and metrics_checkstyle.xml throughout all java
projects
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:29 karsten]:
 > Whee, quite some code to review here.  Sure, a lot of code has just
 moved around, but that only makes it trickier to spot the little
 differences. ...

 Yes, that is how it feels to code this stuff ;-)
 I updated all branches and will attach the patches for metrics-base here.
 More in-line.

 > ...  But hopefully this initial feedback is useful anyway:

 Very useful!  Such a tasks just needs lots of testing/reviewing.

 >
 > https://gitweb.torproject.org/metrics-
 base.git/commit/?id=7a01d68f813cb5ae2904e73dbc81999ce0622eca
 >
 >  - The two properties `"libs"` and `"source-and-target-java-version"`
 are listed twice.

 Removed.

 >
 >  - Speaking of `"source-and-target-java-version"`, we should probably
 keep that property project-specific.  Otherwise we'll have to raise the
 Java version for all projects at once, including metrics-lib and projects
 depending on metrics-lib.

 If a project deviates from the base java version, only the property needs
 to be added to build.xml and takes precedence.  (Try setting it to java
 1.4 and see how the compile complains about generics.)

 I added a comment to the build.template.xml

 >
 >  - The Checkstyle configuration file `java/metrics_checks.xml` does not
 contain modules `SuppressWarningsFilter` and `SuppressWarningsHolder` that
 we added in metrics-lib's version nor module `UnusedImports` in Onionoo's
 version.  It also still defines a maximum line length of 100 rather than
 80.  Let's combine the latest settings from all three code bases here.

 Changed the line length check; all others were already part of the initial
 check-in.

 >
 >  - This is certainly a minor issue, but the usage instructions in the
 `usage` target should all use the same capitalization and sentence
 structure, like "'name' does XY", not "'name' Does XY" or "'name' XY".
 >
 >  - It's already time to update the copyright year in the `docs` target!
 Happy 2017!

 Good that this only needs a change in one place now :-)
 The year is now computed from the current time UTC.

 >
 > https://trac.torproject.org/projects/tor/attachment/ticket/20596/0001
 -Implements-part-of-task-20596.patch
 >
 >  - Typo in `java/build.xml.template`: "jarpatterprop" is missing an "n".

 Fixed.

 >
 >  - By the way, I already pushed this commit to facilitate testing.  We
 can fix things in subsequent commits.

 Very useful.

 >
 >
 
https://gitweb.torproject.org/user/iwakeh/onionoo.git/commit/?h=task-20596-submod&id=0442032f24c8764d6c055ed3b9f4e047fbaa886e
 >
 >  - Why did you change the `"jetty.version"` property to `""` rather than
 `"-8.1.16.v20140903"`?

 Fixed.

 >
 >  - The new generic `tar` target does not include the `DESIGN` file
 anymore.  I'd argue that we should remove that file anyway, but if you
 want to keep it, we'll have to include it in the release tarball, too.

 Removed.  Designs should be elsewhere, for example Tech-Reports.

 >
 >  - The script file `src/main/resources/bootstrap-development.sh` should
 be checked in with the executable flag.

 Done.

 >
 >  - This commit or a subsequent commit should remove
 `src/test/resources/metrics_checks.xml` which is now obsolete.

 Done.

 >
 > https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-20596-submod&id=60d20b85c4dac3d9d0905a185b7bc928736f7fcf
 >
 >  - Which tests did not pass prior to this commit?  They run through just
 fine here.

 Hmm, now these tests pass here, too.  I'll go hunting for the
 jdk/environment setting responsible, but this shouldn't affect this
 ticket.  Please, just cherry pick.

 >
 >  - It shouldn't be necessary to initialize attributes with `null` or
 `0`, which is the default anyway.  All new no-args constructors should be
 empty (except for a comment saying that they're empty on purpose).

 The compiler complains about uninitialized fields (those are final in the
 respective classes).  Otherwise, same as the previous.

 >
 > https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-20596-submod&id=946c403c357661a2290b424ecb1a1c70d70c1334
 >
 >  - The script file `src/main/resources/bootstrap-development.sh` should
 be checked in with the executable flag.

 Done.

 >
 >  - This commit or a subsequent commit should remove
 `src/test/resources/metrics_checks.xml` which is now obsolete.

 Done.

 >
 > https://gitweb.t

Re: [tor-bugs] #21132 [User Experience/Website]: Remove donation banner for 2016 campaign

[Tor Bug Tracker & Wiki]

#21132: Remove donation banner for 2016 campaign
-+--
 Reporter:  arthuredelstein  |  Owner:  Sebastian
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by arthuredelstein):

 * status:  new => needs_review


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

Re: [tor-bugs] #21132 [User Experience/Website]: Remove donation banner for 2016 campaign

[Tor Bug Tracker & Wiki]

#21132: Remove donation banner for 2016 campaign
-+---
 Reporter:  arthuredelstein  |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by arthuredelstein):

 Here's a patch that reverts the donation banner:

 https://github.com/arthuredelstein/webml/commit/21132

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21132 [User Experience/Website]: Remove donation banner for 2016 campaign

[Tor Bug Tracker & Wiki]

#21132: Remove donation banner for 2016 campaign
-+---
 Reporter:  arthuredelstein  |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 Now that the 2016 campaign is finished, we can remove the banner on the
 homepage.

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

Re: [tor-bugs] #21131 [Applications/Tor Browser]: Remove 2016 about:tor donation banner

[Tor Bug Tracker & Wiki]

#21131: Remove 2016 about:tor donation banner
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fundraising, |  Actual Points:
  TorBrowserTeam201701R  |
Parent ID:  #20413   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-fundraising => tbb-fundraising, TorBrowserTeam201701R
 * status:  new => needs_review
 * parent:   => #20413


Old description:

> The 2016 fundraising campaign is over. We should remove the donation
> banner on the next browser update.

New description:

 The 2016 fundraising campaign is over. We should remove the donation
 banner on the next browser update. (The banner was added in #20414.)

--

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications hardware, 2016-06 (was: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06)

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications
hardware, 2016-06
-+--
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

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

Re: [tor-bugs] #21131 [Applications/Tor Browser]: Remove 2016 about:tor donation banner

[Tor Bug Tracker & Wiki]

#21131: Remove 2016 about:tor donation banner
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fundraising   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 I simply reverted all 2016 donation banner patches and combined them into
 a single patch. Here it is for review:

 https://github.com/arthuredelstein/torbutton/commit/21131

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21131 [Applications/Tor Browser]: Remove 2016 about:tor donation banner

[Tor Bug Tracker & Wiki]

#21131: Remove 2016 about:tor donation banner
--+-
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-fundraising
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The 2016 fundraising campaign is over. We should remove the donation
 banner on the next browser update.

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
-+--
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 From changelog for some old  Signature Pack update:
 > Tor 5.5.5 mode= obfs4 wasn’t blocked in some specific flows
 > TOR might not be identified correctly when running with Skype in the
 background
 > Orbot mode obfs4 wasn’t blocked on Android 5.0.1
 > Some HTTPS based services weren’t accessible due to false positive
 Phison identification

 > In some edge use cases TOR Scramblesuit custom bridges cannot be
 blocked.

 > The material contained herein is proprietary, privileged, and
 confidential and owned by  or its third party licensors. This
 information herein is provided to the person or entity to which it is
 addressed, for its own use only and evaluation of this document, therefore
 no disclosure of the content of this document will be made to third
 parties, including without limitation  competitors, without the
 express written permission of 

   

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

Re: [tor-bugs] #21091 [Applications/Tor Browser]: Hide the "Check for Tor Browser Update..." menu entry when running under the sandbox.

[Tor Bug Tracker & Wiki]

#21091: Hide the "Check for Tor Browser Update..." menu entry when running under
the sandbox.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Eventually, I want to make the menu item work instead of hiding it, but
 since the sandbox is bundle version aware, having to do something
 different on my end isn't a big deal.

 `TOR_HIDE_UPDATE_CHECK_UI` works for, and since other people want it (IIRC
 one of the patches in #20557 is to do something similar) that's probably
 better.


 I'm on vacation (TM) this week, so feel free to change it in a branch, if
 not I'll do it this weekend or something, and someone could probably also
 close #20083 in favor of this, if we're going the env var route
 (Help->About Tor Browser's button gets disabled if you use
 autoconfig.js/mozilla.cfg, so I'm less worried about that 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] #21124 [Core Tor/Tor]: ChangeLog: reference to 18625 actually corresponds to 18626

[Tor Bug Tracker & Wiki]

#21124: ChangeLog: reference to 18625 actually corresponds to 18626
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.0.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] #21091 [Applications/Tor Browser]: Hide the "Check for Tor Browser Update..." menu entry when running under the sandbox.

[Tor Bug Tracker & Wiki]

#21091: Hide the "Check for Tor Browser Update..." menu entry when running under
the sandbox.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 These changes look okay to me.
 Do you expect to trigger other special behavior via the TOR_SANDBOX env
 variable? If not and if there is a chance that other people might want to
 hide this menu item as well, we should use a more specific env var name
 such as TOR_HIDE_UPDATE_CHECK_UI.

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

Re: [tor-bugs] #21095 [Metrics/Onionoo]: Accept more values for the "order" parameter

[Tor Bug Tracker & Wiki]

#21095: Accept more values for the "order" parameter
-+--
 Reporter:  lukechilds   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Alright, I had a look at the actual data, and it looks like you're right.
 I had assumed that there are dozens of new relays joining every hour, but
 that's not the case.  Here are the `"first_seen"` times of today (until
 15:00 UTC):

 {{{
 {"first_seen":"2017-01-03 15:00:00"},
 {"first_seen":"2017-01-03 15:00:00"},
 {"first_seen":"2017-01-03 15:00:00"},
 {"first_seen":"2017-01-03 14:00:00"},
 {"first_seen":"2017-01-03 14:00:00"},
 {"first_seen":"2017-01-03 14:00:00"},
 {"first_seen":"2017-01-03 14:00:00"},
 {"first_seen":"2017-01-03 14:00:00"},
 {"first_seen":"2017-01-03 13:00:00"},
 {"first_seen":"2017-01-03 13:00:00"},
 {"first_seen":"2017-01-03 13:00:00"},
 {"first_seen":"2017-01-03 12:00:00"},
 {"first_seen":"2017-01-03 11:00:00"},
 {"first_seen":"2017-01-03 11:00:00"},
 {"first_seen":"2017-01-03 11:00:00"},
 {"first_seen":"2017-01-03 11:00:00"},
 {"first_seen":"2017-01-03 10:00:00"},
 {"first_seen":"2017-01-03 10:00:00"},
 {"first_seen":"2017-01-03 09:00:00"},
 {"first_seen":"2017-01-03 09:00:00"},
 {"first_seen":"2017-01-03 08:00:00"},
 {"first_seen":"2017-01-03 06:00:00"},
 {"first_seen":"2017-01-03 05:00:00"},
 {"first_seen":"2017-01-03 05:00:00"},
 {"first_seen":"2017-01-03 04:00:00"},
 {"first_seen":"2017-01-03 04:00:00"},
 {"first_seen":"2017-01-03 04:00:00"},
 {"first_seen":"2017-01-03 04:00:00"},
 {"first_seen":"2017-01-03 03:00:00"},
 {"first_seen":"2017-01-03 01:00:00"},
 {"first_seen":"2017-01-03 01:00:00"},
 {"first_seen":"2017-01-03 01:00:00"},
 {"first_seen":"2017-01-03 01:00:00"},
 {"first_seen":"2017-01-03 00:00:00"},
 {"first_seen":"2017-01-03 00:00:00"},
 {"first_seen":"2017-01-03 00:00:00"},
 }}}

 I'll give this a try and see if I can build this by dinner.

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

Re: [tor-bugs] #20540 [Metrics]: define log-levels for all java metrics-products

[Tor Bug Tracker & Wiki]

#20540: define log-levels for all java metrics-products
-+--
 Reporter:  iwakeh   |  Owner:
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Alright, I finally got around to trying out those guidelines.  Please take
 a look at [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20540&id=679577985141b44bed7e2a7e8dd65c3093a99243
 this commit in my metrics-lib branch task-20540] where I wrote or tweaked
 log statements for `DescriptorIndexCollector` and friends.  Is that
 roughly what you intended when writing those guidelines?

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

Re: [tor-bugs] #20862 [Core Tor/Tor]: Unittest fail on master: FAIL src/test/test_options.c:662: expected log to contain "Could not resolve local Address "

[Tor Bug Tracker & Wiki]

#20862: Unittest fail on master: FAIL src/test/test_options.c:662: expected log 
to
contain "Could not resolve local Address "
--+
 Reporter:  asn   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #20862 [Core Tor/Tor]: Unittest fail on master: FAIL src/test/test_options.c:662: expected log to contain "Could not resolve local Address "

[Tor Bug Tracker & Wiki]

#20862: Unittest fail on master: FAIL src/test/test_options.c:662: expected log 
to
contain "Could not resolve local Address "
--+
 Reporter:  asn   |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => assigned
 * actualpoints:   => .1


Comment:

 Reproduced while on the Amtrak 93 Northeast Regional.  Thanks, Amtrak!

 There's a fix in `bug20862` for this bug, #20863, and a few other cases I
 found.

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

Re: [tor-bugs] #20863 [Core Tor/Tor]: Unittest fail on master: FAIL src/test/test_controller.c:190: assert(!cfg)

[Tor Bug Tracker & Wiki]

#20863: Unittest fail on master: FAIL src/test/test_controller.c:190: 
assert(!cfg)
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 Fixed as part of my `bug20862` branch; see #20862.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21130 [Internal Services/Service - git]: Please create user repository metrics-base for iwakeh

[Tor Bug Tracker & Wiki]

#21130: Please create user repository metrics-base for iwakeh
-+
 Reporter:  iwakeh   |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 i.e.
 user/iwakeh/metrics-base.git with description "iwakeh's personal metrics-
 base repository"

 Thanks a lot!

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

Re: [tor-bugs] #21127 [Internal Services/Tor Sysadmin Team]: Please refresh key 0xCB8FC772D1AA1D30

[Tor Bug Tracker & Wiki]

#21127: Please refresh key 0xCB8FC772D1AA1D30
-+
 Reporter:  sysrqb   |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #21059 [Core Tor/Tor]: shared-rand-current-value violates spec

[Tor Bug Tracker & Wiki]

#21059: shared-rand-current-value violates spec
--+
 Reporter:  atagar|  Owner:  asn
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:24 teor]:
 > Replying to [comment:23 atagar]:
 > > Hi teor, are you sure you want to go this route? The problem in this
 ticket isn't that clients are unable to accept misordered fields. Stem can
 still read the consensus just fine. Rather, the trouble is that its
 **descriptor validator** was telling us that tor's actual behavior doesn't
 match the spec.
 > >
 > > I see two options...
 > >
 > > * Fix the ordering in the spec, and be careful in the future that we
 don't keep making this mistake.
 > > * Loosen the requirement from MUST to SHOULD so it's no big whoop if
 tor's order matches the spec or not.
 > >
 > > Considering that I found three separate instances of these fields
 being misordered I don't think this is a detail we want to keep contending
 with.
 >
 > I think we agree here.
 >
 > I also think my patch does what you want, with the extra constraint that
 the arbitrary order of consensus lines may vary between consensus methods,
 but must be consistent for a particular consensus method:
 >

 Hey, why do you think this consensus method consistency rule is important?
 I feel it makes the text confusing.

 Personally, given the inconsistencies that atagar noted, I think the
 patches in comment:6 and comment:20 look good to me.

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

[tor-bugs] #21129 [Core Tor/Tor]: Bug: src/or/entrynodes.c:1204: remove_guard_from_confirmed_and_primary_lists: Non-fatal assertion !(guard != found_guard) failed.

[Tor Bug Tracker & Wiki]

#21129: Bug: src/or/entrynodes.c:1204:
remove_guard_from_confirmed_and_primary_lists: Non-fatal assertion !(guard
!= found_guard) failed.
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal|   Keywords:  tor-guard
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Similar to #21128, I was messing around with my state file to simulate
 various guard scenarios, and I ended up getting the following non-fatal
 assert. This happened when I replaced `confirmed_on=2016` with
 `confirmed_on=2014` and `sampled_on=2016` with `sampled_on=2014` in my
 state file, so that I test guard expiry:

 {{{
 Jan 03 14:20:52.000 [warn] Removing sampled guard quadhead
 ($BF0FB582E37F738CD33C3651125F2772705BB8E8): it was sampled over 120 days
 ago, and confirmed over 60 days ago.
 Jan 03 14:20:52.000 [warn] tor_bug_occurred_(): Bug:
 src/or/entrynodes.c:1204: remove_guard_from_confirmed_and_primary_lists:
 Non-fatal assertion !(guard != found_guard) failed. (on Tor 0.3.0.0-alpha-
 dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: Non-fatal assertion !(guard !=
 found_guard) failed in remove_guard_from_confirmed_and_primary_lists at
 src/or/entrynodes.c:1204. Stack trace: (on Tor 0.3.0.0-alpha-dev
 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libasan.so.1(backtrace+0x3a) [0x7fb92745b48a] (on Tor 0.3.0.0-alpha-
 dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(log_backtrace+0x46) [0x7fb928e1b806] (on Tor
 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(tor_bug_occurred_+0x12f) [0x7fb928e6b6df]
 (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(entry_guards_update_all+0x12f2)
 [0x7fb928de5b82] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(guards_update_all+0x83) [0x7fb928dea8e3] (on
 Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(directory_info_has_arrived+0xa5)
 [0x7fb928aa8fe5] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(do_main_loop+0x17b) [0x7fb928aa9b6b] (on Tor
 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(tor_main+0x1385) [0x7fb928aaebc5] (on Tor
 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(main+0x1c) [0x7fb928a9cddc] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf5) [0x7fb924f35b45] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:20:52.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x574e9b) [0x7fb928a9ee9b] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 }}}

 Seems like some assumption is not true during guard removal. Please let me
 know if you think my manual state string replacements might have put Tor
 into some unrealistic state and hence this bug is bogus.

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

Re: [tor-bugs] #21128 [Core Tor/Tor]: Bug: src/or/entrynodes.c:2266: entry_guard_failed: Non-fatal assertion !(*guard_state_p == NULL) failed. (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)

[Tor Bug Tracker & Wiki]

#21128: Bug: src/or/entrynodes.c:2266: entry_guard_failed: Non-fatal assertion
!(*guard_state_p == NULL) failed. (on Tor 0.3.0.0-alpha-dev
5a97a46e60c95b6f)
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by asn:

Old description:

> I was messing around with my state file to simulate various guard
> scenarios, and I ended up getting the following non-fatal assert. This
> happened when I replaced `confirmed_on=2016` with `confirmed_on=2014` in
> my state file, so that I test guard expiry:
>
> {{{
> Jan 03 14:09:42.000 [warn] Tried connecting to router at
> 91.219.236.222:443, but RSA identity key was not as expected: wanted
> EC413181CEB1C8EDC17608BBB177CD5FD8535E99 + no ed25519 key but got
> 20704E7DD51501DC303FA51B738D7B7E61397CF6 + no ed25519 key.
> Jan 03 14:09:42.000 [warn] tor_bug_occurred_(): Bug:
> src/or/entrynodes.c:2266: entry_guard_failed: Non-fatal assertion
> !(*guard_state_p == NULL) failed. (on Tor 0.3.0.0-alpha-dev
> 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: Non-fatal assertion !(*guard_state_p ==
> NULL) failed in entry_guard_failed at src/or/entrynodes.c:2266. Stack
> trace: (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /usr/lib/x86_64-linux-
> gnu/libasan.so.1(backtrace+0x3a) [0x7f8a4383a48a] (on Tor 0.3.0.0-alpha-
> dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(log_backtrace+0x46) [0x7f8a451fa806] (on
> Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(tor_bug_occurred_+0x12f) [0x7f8a4524a6df]
> (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(entry_guard_chan_failed+0x1f3)
> [0x7f8a451bac43] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(connection_or_client_learned_peer_id+0x8d7)
> [0x7f8a4510b3f7] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(channel_tls_handle_var_cell+0x613b)
> [0x7f8a45015d3b] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(+0x7faa0f) [0x7f8a45103a0f] (on Tor 0.3.0.0
> -alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(+0x7dc2f8) [0x7f8a450e52f8] (on Tor 0.3.0.0
> -alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(+0x57df56) [0x7f8a44e86f56] (on Tor 0.3.0.0
> -alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/libevent-2.0.so.5(event_base_loop+0x937)
> [0x7f8a430bc8d7] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(do_main_loop+0x385) [0x7f8a44e88d75] (on
> Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(tor_main+0x1385) [0x7f8a44e8dbc5] (on Tor
> 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(main+0x1c) [0x7f8a44e7bddc] (on Tor 0.3.0.0
> -alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /lib/x86_64-linux-
> gnu/libc.so.6(__libc_start_main+0xf5) [0x7f8a41314b45] (on Tor 0.3.0.0
> -alpha-dev 5a97a46e60c95b6f)
> Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
> US/Browser/TorBrowser/Tor/tor(+0x574e9b) [0x7f8a44e7de9b] (on Tor 0.3.0.0
> -alpha-dev 5a97a46e60c95b6f)
> }}}
>
> The error message with the RSA identity key has nothing to do with
> `confirmed_on` so that was a bit surprising.

New description:

 I was messing around with my state file to simulate various guard
 scenarios, and I ended up getting the following non-fatal assert. This
 happened when I replaced `confirmed_on=2016` with `confirmed_on=2014` in
 my state file, so that I test guard expiry:

 {{{
 Jan 03 14:09:42.000 [warn] Tried connecting to router at
 91.219.236.222:443, but RSA identity key was not as expected: wanted
 EC413181CEB1C8EDC17608BBB177CD5FD8535E99 + no ed25519 key but got
 20704E7DD51501DC303FA51B738D7B7E61397CF6 + 

[tor-bugs] #21128 [Core Tor/Tor]: Bug: src/or/entrynodes.c:2266: entry_guard_failed: Non-fatal assertion !(*guard_state_p == NULL) failed. (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)

[Tor Bug Tracker & Wiki]

#21128: Bug: src/or/entrynodes.c:2266: entry_guard_failed: Non-fatal assertion
!(*guard_state_p == NULL) failed. (on Tor 0.3.0.0-alpha-dev
5a97a46e60c95b6f)
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal|   Keywords:  tor-guard
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I was messing around with my state file to simulate various guard
 scenarios, and I ended up getting the following non-fatal assert. This
 happened when I replaced `confirmed_on=2016` with `confirmed_on=2014` in
 my state file, so that I test guard expiry:

 {{{
 Jan 03 14:09:42.000 [warn] Tried connecting to router at
 91.219.236.222:443, but RSA identity key was not as expected: wanted
 EC413181CEB1C8EDC17608BBB177CD5FD8535E99 + no ed25519 key but got
 20704E7DD51501DC303FA51B738D7B7E61397CF6 + no ed25519 key.
 Jan 03 14:09:42.000 [warn] tor_bug_occurred_(): Bug:
 src/or/entrynodes.c:2266: entry_guard_failed: Non-fatal assertion
 !(*guard_state_p == NULL) failed. (on Tor 0.3.0.0-alpha-dev
 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: Non-fatal assertion !(*guard_state_p ==
 NULL) failed in entry_guard_failed at src/or/entrynodes.c:2266. Stack
 trace: (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libasan.so.1(backtrace+0x3a) [0x7f8a4383a48a] (on Tor 0.3.0.0-alpha-
 dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(log_backtrace+0x46) [0x7f8a451fa806] (on Tor
 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(tor_bug_occurred_+0x12f) [0x7f8a4524a6df]
 (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(entry_guard_chan_failed+0x1f3)
 [0x7f8a451bac43] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(connection_or_client_learned_peer_id+0x8d7)
 [0x7f8a4510b3f7] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(channel_tls_handle_var_cell+0x613b)
 [0x7f8a45015d3b] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x7faa0f) [0x7f8a45103a0f] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x7dc2f8) [0x7f8a450e52f8] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x57df56) [0x7f8a44e86f56] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/libevent-2.0.so.5(event_base_loop+0x937)
 [0x7f8a430bc8d7] (on Tor 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(do_main_loop+0x385) [0x7f8a44e88d75] (on Tor
 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(tor_main+0x1385) [0x7f8a44e8dbc5] (on Tor
 0.3.0.0-alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(main+0x1c) [0x7f8a44e7bddc] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf5) [0x7f8a41314b45] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 Jan 03 14:09:42.000 [warn] Bug: /home/user/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x574e9b) [0x7f8a44e7de9b] (on Tor 0.3.0.0
 -alpha-dev 5a97a46e60c95b6f)
 }}}

 The error message with the RSA identity key has nothing to do with
 `confirmed_on` so that was a bit surprising.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21127 [Internal Services/Tor Sysadmin Team]: Please refresh key 0xCB8FC772D1AA1D30

[Tor Bug Tracker & Wiki]

#21127: Please refresh key 0xCB8FC772D1AA1D30
-+-
 Reporter:  sysrqb   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Please refresh 0xCB8FC772D1AA1D30 in the tpo keyring. There are three new
 subkeys, the old subkeys expired.
 {{{
 amnesia@amnesia:~$ gpg -k D1AA1D30
 pub   4096R/0xCB8FC772D1AA1D30 2014-06-26 [expires: 2017-07-10]
   Key fingerprint = CE17 8262 4600 EE98 764C  6D9C CB8F C772 D1AA 1D30
 uid [ unknown] Matthew Finkel 
 uid [ unknown] Matthew Finkel 
 sub   3072R/0x94C3F7353E6F398E 2017-01-01 [expires: 2017-06-30]
 sub   3072R/0x2D09A4BC84DF32F7 2017-01-01 [expires: 2017-06-30]
 sub   3072R/0x5336559425C90BF4 2017-01-01 [expires: 2017-06-30]
 }}}
 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] #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:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+--
Changes (by intrigeri):

 * cc: intrigeri (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] #21095 [Metrics/Onionoo]: Accept more values for the "order" parameter

[Tor Bug Tracker & Wiki]

#21095: Accept more values for the "order" parameter
-+--
 Reporter:  lukechilds   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by lukechilds):

 Would `?order=-first_seen&limit=10` not return the 10 most recent relays
 to join the network?

 `?first_seen_days=-1&order=-consensus_weight&limit=10` seems like it could
 definitely be helpful, however the first method would be ideal. If there
 haven't been many new relays on the current day we might need to go back
 to yesterday. And for users specifically trying to get a clean IP, age
 would be more important than performance.

 If we could get sorting by `first_seen` that would be awesome!

 I've had a look through the file you linked. I've never touched a line of
 Java in my life and to be honest I'm kind of struggling to grok it.

 It looks like I could just copy and past the `orderRelaysByConsensusWeight
 ` bits for  `first_seen` but I'm not quite sure how that wires up with the
 `order` URL parameter.

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

Re: [tor-bugs] #21095 [Metrics/Onionoo]: Accept more values for the "order" parameter

[Tor Bug Tracker & Wiki]

#21095: Accept more values for the "order" parameter
-+--
 Reporter:  lukechilds   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Hmm, I wonder if `"?order=-first_seen&limit=10"` would really give you (or
 your users) a useful list of relays.  There are probably dozens or
 hundreds of relays in that list, most of them tiny and some not even
 around anymore.

 Another option would be
 `"?first_seen_days=-1&order=-consensus_weight&limit=10"` to obtain the 10
 fastest relays that showed up in the past 24 hours.  Want to take a look
 and maybe give that a try?  (It's already implemented!)

 But if the first option seems more promising, let's implement that one,
 too.  As I said, `"first_seen"` is relatively easy.

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

Re: [tor-bugs] #21071 [Internal Services/Tor Sysadmin Team]: [onion] blog.torproject.org

[Tor Bug Tracker & Wiki]

#21071: [onion] blog.torproject.org
-+-
 Reporter:  righnaw  |  Owner:  tpa
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:  #19805   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 We expect the blog to move to 3rd party hosting soon.  We should not make
 this more difficult by adding more services to 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

[tor-bugs] #21126 [Internal Services/Tor Sysadmin Team]: restart redis stunnel before CRL expires

[Tor Bug Tracker & Wiki]

#21126: restart redis stunnel before CRL expires
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-


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

[tor-bugs] #21125 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere compleatly breaks idnes.cz

[Tor Bug Tracker & Wiki]

#21125: HTTPS Everywhere compleatly breaks idnes.cz
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |   Keywords:  httpse-
 Severity:  Normal   |  ruleset-bug
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hello,

 HTTPS everywhere completely breaks loading of any article at
 [http://www.idnes.cz/]

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

Re: [tor-bugs] #21095 [Metrics/Onionoo]: Accept more values for the "order" parameter

[Tor Bug Tracker & Wiki]

#21095: Accept more values for the "order" parameter
-+--
 Reporter:  lukechilds   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by lukechilds):

 Re use case, it was requested that there be a way to list the newest
 relays on the network on Tor Explorer as these relays have a lower chance
 of being blacklisted:
 https://github.com/lukechilds/tor-explorer/issues/5

 I've got it working by getting all details docs from
 https://onionoo.torproject.org/details and ordering locally. The thing is
 Onionoo takes around 15 seconds to respond with all this info and it's
 over 2MB of JSON to sort through. I don't think it's really a viable
 solution.

 I only need the top ten for the first page, so it would be much more
 elegant if I could tell Onionoo to order by `first_seen` and then limit to
 10. Then for the next page do the same query but offset by 10 etc.

 The main value I think would be useful would be `first_seen`, however I
 was thinking of adding a drop down box to Tor Explorer to allow the user
 to order by whichever properties they want. Obviously if that's going to
 be a lot of effort on the Onionoo end then it's probably not worth 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] #20759 [Metrics]: check if LICENSE file is up-to-date

[Tor Bug Tracker & Wiki]

#20759: check if LICENSE file is up-to-date
-+--
 Reporter:  iwakeh   |  Owner:  hiro
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_review => new


Comment:

 All three patches applied, thanks a lot!  Looks like the only remaining
 license file is [https://gitweb.torproject.org/metrics-
 web.git/tree/LICENSE metrics-web's].  Want to submit a patch for that,
 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