Re: [tor-bugs] #26891 [Obfuscation/meek]: Problem running meek server without CDN, stuck at Performing bandwidth self-test...done

[Tor Bug Tracker & Wiki]

#26891: Problem running meek server without CDN, stuck at Performing bandwidth
self-test...done
--+---
 Reporter:  weiruo|  Owner:  dcf
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  meek server   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dcf):

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


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

Re: [tor-bugs] #26891 [Obfuscation/meek]: Problem running meek server without CDN, stuck at Performing bandwidth self-test...done

[Tor Bug Tracker & Wiki]

#26891: Problem running meek server without CDN, stuck at Performing bandwidth
self-test...done
--+-
 Reporter:  weiruo|  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek server   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by weiruo):

 Great, I delete ~/.tor/state and it works. Thank you very much!

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

Re: [tor-bugs] #26906 [Internal Services/Service - deb.tpo]: Add sbws Debian package in deb.tpo

[Tor Bug Tracker & Wiki]

#26906: Add sbws Debian package in deb.tpo
-+-
 Reporter:  juga |  Owner:  juga
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  sbws
 |  1.0 (MVP must)
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #26848   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_information


Comment:

 Replying to [ticket:26906 juga]:
 > It still not in Debian archive and afaik, only packages in Debian
 archive will be also available in deb.tpo to avoid having unmaintained
 packages.

 The network team will maintain sbws, if it passes our acceptance criteria.
 (It must work on the network, and it must work better than torflow.)

 > But we are not reaching consensus on whether or not there should be a
 sbws package in Debian archive, so would it be possible to have it on
 deb.tpo in the meanwhile?.

 Sometimes we need to make decisions, even if we can't reach consensus.
 When we don't have consensus, we let the people who are most involved
 decide. In this case, that's the sbws developers, sbws operators, and the
 debian package admins:

 https://trac.torproject.org/projects/tor/ticket/26848#comment:13

 Please keep on making a package.

 When the package is ready, we can decide where to put 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] #26848 [Core Tor/sbws]: Create Debian package for sbws

[Tor Bug Tracker & Wiki]

#26848: Create Debian package for sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 Replying to [comment:12 juga]:
 > Replying to [comment:11 atagar]:
 > > > irl, i can't tell if you're "really not convinced it's a good idea"
 or if you're "really convinced it's not a good idea". :)
 > >
 > > I'm pretty convinced this *is* a bad idea but we've already discussed
 this multiple times on irc. If pastly would like to vend sbws through the
 debian repos then this is up to him.

 irl, thank you for your feedback.

 We need to make a Debian package to get sbws deployed on some directory
 authorities.  Deployment is a top priority. If it doesn't happen, the
 project is blocked. We will consider the issues you've raised, but as far
 as I can tell, none of them are blockers.

 > pastly wrote to the dir-auth ml, which is our user target and i
 thought/think it was a good idea. Unfortunately, IRC discussions missed
 the context of the private discussions with had with dirauths. They would
 not install something from pypi nor git cause of known security issues,
 plus i add, it requires further system configuration.
 >
 > i'm adding dirauths that expressed an opinion as CC here. Please
 dirauths, let me know if i should remove you.
 >
 > We need dirauths to start running sbws. Afaik, the way to install sbws
 is blocking them right now, and we don't seem to reach consensus out of
 dir-auth ml, so, all i can do right now is try to get it at list on
 deb.tpo, and then see...?

 Juga, sometimes we need to make decisions, even if we can't reach
 consensus.

 Here are my suggestions for moving forward:
 * keep going with the Debian package process
 * prioritise issues raised by people who can block the debian package from
 being created
 * prioritise issues raised by directory authority operators

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26906 [Internal Services/Service - deb.tpo]: Add sbws Debian package in deb.tpo

[Tor Bug Tracker & Wiki]

#26906: Add sbws Debian package in deb.tpo
-+-
 Reporter:  juga |  Owner:  juga
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  sbws 1.0
Component:  Internal Services/Service -  |  (MVP must)
  deb.tpo|Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #26848
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 It still not in Debian archive and afaik, only packages in Debian archive
 will be also available in deb.tpo to avoid having unmaintained packages.
 But we are not reaching consensus on whether or not there should be a sbws
 package in Debian archive, so would it be possible to have it on deb.tpo
 in the meanwhile?.

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

Re: [tor-bugs] #26848 [Core Tor/sbws]: Create Debian package for sbws

[Tor Bug Tracker & Wiki]

#26848: Create Debian package for sbws
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

 * cc: juga@… (removed)
 * cc: juga, stefani@…, arma, mail@…, micah@…, adejoode@… (added)


Comment:

 Replying to [comment:11 atagar]:
 > > irl, i can't tell if you're "really not convinced it's a good idea" or
 if you're "really convinced it's not a good idea". :)
 >
 > I'm pretty convinced this *is* a bad idea but we've already discussed
 this multiple times on irc. If pastly would like to vend sbws through the
 debian repos then this is up to him.

 pastly wrote to the dir-auth ml, which is our user target and i
 thought/think it was a good idea. Unfortunately, IRC discussions missed
 the context of the private discussions with had with dirauths. They would
 not install something from pypi nor git cause of known security issues,
 plus i add, it requires further system configuration.

 i'm adding dirauths that expressed an opinion as CC here. Please dirauths,
 let me know if i should remove you.

 We need dirauths to start running sbws. Afaik, the way to install sbws is
 blocking them right now, and we don't seem to reach consensus out of dir-
 auth ml, so, all i can do right now is try to get it at list on deb.tpo,
 and then see...?

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

Re: [tor-bugs] #26303 [Core Tor/Tor]: IPv6-Flagging of Relay not accurate

[Tor Bug Tracker & Wiki]

#26303: IPv6-Flagging of Relay not accurate
+--
 Reporter:  ruebezahl   |  Owner:  metrics-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: 0.3.3.6
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  ipv6, 035-roadmap-proposed  |  Actual Points:
Parent ID:  #24864  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * status:  needs_information => closed
 * resolution:   => duplicate
 * parent:  #24403 => #24864


Comment:

 We think this happened due to the delayed descriptor updates in #24864, or
 the missing IPv6 reachability checks in #24403.

 If it happens again, please open a new ticket with:
 * the descriptor timestamp from consensus health, and
 * the descriptor timestamp from the relay itself:
   * ​http://217.115.10.131/tor/server/authority

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

Re: [tor-bugs] #26876 [Core Tor/Tor]: tor.real fails to start on macOS 10.9

[Tor Bug Tracker & Wiki]

#26876: tor.real fails to start on macOS 10.9
-+-
 Reporter:  mcs  |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-needs, regression, |  Actual Points:
  fast-fix, 033-backport, 034-backport,  |
  035-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:5 nickm]:
 > (That is, according to
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SupportedPlatforms
 , we wouldn't ordinarily support 10.9, since it's "OSX past EOL".  But if
 TB needs it, we should support it, and we should maybe revise our policy,
 I guess.)

 Replying to [comment:6 gk]:
 > https://www.mozilla.org/en-US/firefox/60.0esr/system-requirements/ has
 the system requirements for Firefox which we follow. Thus, if you could
 support 10.9 for the time being that would be neat.

 I updated our support policy so that we will Maintain:
 * OS X / macOS supported by Tor Browser (but not Apple)
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SupportedPlatforms?action=diff=13

 Let's handle support for unsupported Windows and Linux as 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] #3723 [Core Tor/Tor]: Report version of bwscanners in votes

[Tor Bug Tracker & Wiki]

#3723: Report version of bwscanners in votes
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, 035-triaged-in-20180711  |  Actual Points:
Parent ID:  #25925   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:42 juga]:
 > Replying to [comment:40 nickm]:
 > > I mean, would we ever want to have a field that would be part of the
 bandwidth file, but _not_ copied into the vote?
 >
 > i can not find a reason for that right now. I guess if we need it at
 some point, we would need to change the spec and this code again.

 The current headers don't contain any sensitive information:
 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n105

 Also, we want to make the entire bandwidth file public, see #21377 and:
 https://gitweb.torproject.org/torspec.git/tree/proposals/296-expose-
 bandwidth-files.txt

 But before we make the entire file public, we need to work out if the
 individual relay bandwidths make it easier to run attacks, see #26904.

 If you'd like, we could update the bandwidth file spec to say that the
 headers and the file content are public.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26905 [Core Tor/Tor]: Work out if we need to round observed relay bandwidths to protect individual client usage

[Tor Bug Tracker & Wiki]

#26905: Work out if we need to round observed relay bandwidths to protect
individual client usage
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-dirauth, metrics, tor-bwauth,
 Severity:  Normal   |  035-roadmap-proposed
Actual Points:   |  Parent ID:  #25925
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Relays maintain detailed information about their maximum network load.
 After #24104, relays only report their maximum bandwidth once a day, over
 10 seconds of measurement.

 How sensitive is this bandwidth information?

 Should we round these bandwidths to:
 * a number of decimal places?
 * a set amount of client usage that we want to protect?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26904 [Core Tor/Tor]: Work out if we need to round scanner measured bandwidths to protect individual client usage

[Tor Bug Tracker & Wiki]

#26904: Work out if we need to round scanner measured bandwidths to protect
individual client usage
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-dirauth, metrics, tor-bwauth,
 Severity:  Normal   |  035-roadmap-proposed
Actual Points:   |  Parent ID:  #21377
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Network scanners like torflow and sbws maintain detailed information about
 relay load. This information is only collected occasionally (perhaps once
 or twice a day), over a few seconds of measurement.

 How sensitive is this bandwidth information?

 Should we round these bandwidths to:
 * a number of decimal places?
 * a set amount of client usage that we want to protect?

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

Re: [tor-bugs] #3723 [Core Tor/Tor]: Report version of bwscanners in votes

[Tor Bug Tracker & Wiki]

#3723: Report version of bwscanners in votes
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, 035-triaged-in-20180711  |  Actual Points:
Parent ID:  #25925   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:40 nickm]:
 > I mean, would we ever want to have a field that would be part of the
 bandwidth file, but _not_ copied into the vote?

 i can not find a reason for that right now. I guess if we need it at some
 point, we would need to change the spec and this code 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] #3723 [Core Tor/Tor]: Report version of bwscanners in votes

[Tor Bug Tracker & Wiki]

#3723: Report version of bwscanners in votes
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, 035-triaged-in-20180711  |  Actual Points:
Parent ID:  #25925   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => merge_ready


Comment:

 Added 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] #17949 [Core Tor/Tor]: Make loopback address search more accurate

[Tor Bug Tracker & Wiki]

#17949: Make loopback address search more accurate
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-client, tor-relay, |  Actual Points:
  loopback, weird-configuration, 035-triaged-|
  in-20180711|
Parent ID:  #17991   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 rl1987, are your extra commits ready for 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] #26903 [Core Tor/Tor]: Document what 'GETINFO net/listeners/*' do (was: Document what 'GETINFO net/listeners/*' are)

[Tor Bug Tracker & Wiki]

#26903: Document what 'GETINFO net/listeners/*' do
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 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] #26903 [Core Tor/Tor]: Document what 'GETINFO net/listeners/*' are

[Tor Bug Tracker & Wiki]

#26903: Document what 'GETINFO net/listeners/*' are
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi lovely tor folks. Minor thing but a recent spec addition made me
 realize that we should document what the listener ports do...

 https://gitweb.torproject.org/torspec.git/commit/?id=a8a838f

 Personally I haven't a clue what extor or httptunnel endpoints are, and if
 I'm puzzled by them I suspect others might be as well. ;)

 This is an existing problem. Control, dns, and such weren't documented
 either. Since they were self explanatory it didn't seem worth bringing
 this up when we first added the field, but now that the endpoints are
 getting more exotic I'd appreciate a short description in the spec for
 what they do.

 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

[tor-bugs] #26902 [Core Tor/Stem]: Download and parse bwauth files

[Tor Bug Tracker & Wiki]

#26902: Download and parse bwauth files
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  descriptor
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Recently tor added its bandwidth authority files to the DirPort...

 https://gitweb.torproject.org/torspec.git/commit/?id=365d371

 We should add a parser and support in stem.descriptor.remote. This feature
 was added in tor 0.3.5 which the dirauths aren't yet running. Gonna wait
 to see this working in practice before we add stem 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] #25669 [Core Tor/Tor]: Privcount: blinding and encryption should be finished up

[Tor Bug Tracker & Wiki]

#25669: Privcount: blinding and encryption should be finished up
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #22898   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by chelseakomlo):

 Overall, this is looking good. This review is purely a Rust convention and
 code quality review, I didn't actually look deeply at how logic is
 implemented. Doctests and more unit tests would help in being able to do a
 deeper review for logic though.

 As a more meta point, there is a lot of good and very detailed information
 in our Rust coding standards: tor/docs/HACKING/CodingStandardsRust.md. I
 would recommend taking a look, particularly for safety if/when this code
 integrates with tor C code.

 Let me know if you want to talk over any of this on irc/etc.

 == Types
 - In several places, it looks like `usize` is being used interchangeably
 for integer types (such as `test_combination`). I would recommend doing a
 review to ensure if using explicit fixed-size representations would be
 safer in these cases, as usize is of pointer size, so its size changes
 depending on the architecture. https://doc.rust-
 lang.org/std/primitive.usize.html.

 == Documentation
 - Doctests should probably be added to all public functions- this is
 helpful for both documenting the code and also verifying that the
 documentation is valid.
 - Readme needs to be updated:
 https://github.com/nmathewson/privcount_shamir
 - Per our Rust coding standards (in
 tor/docs/HACKING/CodingStandardsRust.md, `#[deny(missing_docs)]` must be
 included

 == External Dependencies
 - I see that this crate depends on several external crates. `rust-crypto`
 states that it doesn't have strong security guarantees- is there something
 else that we should be using? https://crates.io/crates/rust-crypto. Should
 we have an auditing process for when we choose to import/use new external
 crates?

 == Rust code conventions
 - Snake case in the function name:
 
https://github.com/nmathewson/privcount_shamir/blob/master/rust/src/server.rs#L69

 == Integration
 - How will this code be executed? Will something in core Tor call into
 these public functions? If so, where is the FFI layer?
 - Should any logging be added to this module?
 - Will this code call into Tor's C code at all? It doesn't currently but I
 was curious if there are plans for this in the case of the code moving
 into the core tor codebase.

 == Safety
 - Ensure that if this code is being called from C, there aren't unexpected
 places that would lead to UB. For example, everything needs to be
 explicitly handled in the case of errors:
 
https://github.com/nmathewson/privcount_shamir/blob/master/rust/src/encrypt.rs#L122
 as one example, but I see `assert!` in several places as well as
 `assert_eq!`, etc:
 
https://github.com/nmathewson/privcount_shamir/blob/f679aa90ef3ce0d264c50f7e010b2b8022b96c7c/rust/src/shamir.rs#L90
 - Are there bounds checks that should happen in these places?
 
https://github.com/nmathewson/privcount_shamir/blob/f679aa90ef3ce0d264c50f7e010b2b8022b96c7c/rust/src/shamir.rs#L50
 and
 
https://github.com/nmathewson/privcount_shamir/blob/34db770b2bed5ee7217bc01a530e39b1a90bad17/rust/src/data.rs#L87
 - Handle error cases and don't call unwrap directly.
 
https://github.com/nmathewson/privcount_shamir/blob/fe039e5600c25b99acd4bd23b0e609874789fd79/rust/src/client.rs#L25
 and
 
https://github.com/nmathewson/privcount_shamir/blob/fe039e5600c25b99acd4bd23b0e609874789fd79/rust/src/client.rs#L100
 for example.

 == Testing
 === Unit tests
 - I see a couple modules without unit tests (client, data). Per our coding
 standards, all code must be unit and integration tests. For extremely
 basic functions, doctests are likely sufficient (such as to string
 methods) but this should be in only in extremely simple cases and not the
 default.
 - Ensure test names are descriptive of what they are testing, or add
 comments:
 
https://github.com/nmathewson/privcount_shamir/blob/f679aa90ef3ce0d264c50f7e010b2b8022b96c7c/rust/src/shamir.rs#L131
 - Remove print statements in tests :)
 

Re: [tor-bugs] #26892 [Core Tor/Tor]: log_addr_has_changed() does not heed SafeLogging

[Tor Bug Tracker & Wiki]

#26892: log_addr_has_changed() does not heed SafeLogging
--+--
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

 * status:  new => needs_review


Comment:

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26901 [Metrics/Onionoo]: use a DNSSEC validating resolver while doing DNS lookups for onionoo

[Tor Bug Tracker & Wiki]

#26901: use a DNSSEC validating resolver while doing DNS lookups for onionoo
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 onionoo does DNS lookups for some fields, please use a DNSSEC validating
 resolver.

 I don't think it is necessary to add new fields but lets
 add it to the description of the _host_names fields

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26900 [Core Tor/Tor]: Reduce background compression thread priority

[Tor Bug Tracker & Wiki]

#26900: Reduce background compression thread priority
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As I understand, the compression is not latency-sensitive, i.e. if we get
 it done 30 seconds or 1 minute later, nobody really minds, but if we
 process 1 packets 200 ms slower, that materially affects user
 experience. Also, I think if you do not set the thread priority, modern
 schedulers may assume that because it runs infrequently, the compression
 task is a "foreground" or "interactive" task and the actual cell relaying
 is a "background" task that may be slowed down to minimize user impact,
 exactly the opposite of what we want.

 Therefore, this should improve single-CPU relay performance (and multi-CPU
 relay performance once we implement better multithreading).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26899 [Core Tor/Tor]: Rev counter prevents easy move of v3 onion service

[Tor Bug Tracker & Wiki]

#26899: Rev counter prevents easy move of v3 onion service
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This weekend I was moving a v3 onion service to another box. Copying the
 folder alone was not enough. I also had to manually edit the rev counter
 in the state file otherwise the hs descriptors were always rejected as
 invalid. It took me a while to figure this out, perhaps I was looking in
 the wrong place or perhaps this isn't documented.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26898 [Metrics/Onionoo]: add parameters for verified_host_names and unverified_host_names

[Tor Bug Tracker & Wiki]

#26898: add parameters for verified_host_names and unverified_host_names
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 the 'host_name' field is deprecated, lets add two search parameters
 for the new fields recently added:
 * verified_host_names
 * unverified_host_names

 and lets deprecate the host_name parameter in addition to the host_name
 field.

 context:
 people can then use the verified_host_names parameter to search for all
 their relays in a way that is less vulnerable to attacks where a random
 operator injects himself into the result set.
 https://github.com/neelchauhan/FamilyGenerator

 The implementer decides whether these parameters accept single or multiple
 values.

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