Re: [tor-bugs] #25164 [Applications/Tor Browser]: Reproducible Tor Browser for Android builds

[Tor Bug Tracker & Wiki]

#25164: Reproducible Tor Browser for Android builds
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201807  |  Actual Points:
Parent ID:  #26693| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sisbell):

 I've implemented building an Android apk with RBM at:
 https://github.com/sisbell/tor-browser-build/tree/android

 I'll open a git project at torproject and import it over for further
 review and cleanup.

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

Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
--+--
 Reporter:  chelseakomlo  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * status:  new => assigned
 * owner:  (none) => teor


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

Re: [tor-bugs] #26955 [Core Tor/Tor]: Privcount blinding and encryption: rustfmt

[Tor Bug Tracker & Wiki]

#26955: Privcount blinding and encryption: rustfmt
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:4 teor]:
 > Replying to [comment:3 chelseakomlo]:
 > > As a note to the future, we should probably set up a CI task for core
 tor to check if Rust files haven't been formatted with rustfmt (I don't
 think we do this currently after looking at the build). I can open a
 ticket to track this.
 >
 > Thanks! Please post the ticket number here.
 >
 > I opened #26973 for the same change to the privcount_shamir CI.

 Oh, I see, it's #26972 for core tor rustfmt.

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 The Appveyor Windows CI gives a good error:

 {{{
 bash.exe : In file included from ../src/core/or/or.h:51:0,
 At line:2 char:5
 + & $commandPath $args 2>&1
 + ~
 + CategoryInfo  : NotSpecified: (In file
 include...e/or/or.h:51:0,:String) [], RemoteException
 + FullyQualifiedErrorId : NativeCommandError

  from ../src/feature/hs/hs_common.c:14:
 ../src/feature/hs/hs_common.c: In function
 'hs_get_extend_info_from_lspecs':
 ../src/lib/net/address.h:308:49: error: null pointer dereference [-Werror
 =null-dereference]
  tor_addr_port_is_valid(&(ap)->addr, (ap)->port, (for_listening))
  ^
 ../src/lib/net/address.h:305:29: note: in definition of macro
 'tor_addr_port_is_valid'
   tor_port_is_valid((port), (for_listening)))
  ^~~~
 ../src/feature/hs/hs_common.c:1720:8: note: in expansion of macro
 'tor_addr_port_is_valid_ap'
if (!tor_addr_port_is_valid_ap(ap, 0) || !have_legacy_id) {
 ^
 ../src/feature/hs/hs_common.c:1729:64: error: null pointer dereference
 [-Werror=null-dereference]
   fascist_firewall_allows_address_addr(>addr, ap->port,
   ~~^~
 In file included from ../src/lib/crypt_ops/crypto_rsa.h:21:0,
  from ../src/lib/crypt_ops/crypto.h:20,
  from ../src/core/or/or.h:30,
  from ../src/feature/hs/hs_common.c:14:
 ../src/feature/hs/hs_common.c:1748:48: error: null pointer dereference
 [-Werror=null-dereference]
 "it: %s:%u", fmt_addr(>addr), ap->port);
   ~~^~~
 ../src/lib/log/log.h:250:51: note: in definition of macro 'log_fn'
log_fn_(severity, domain, __FUNCTION__, args, ##__VA_ARGS__)
^~~
 ../src/feature/hs/hs_common.c:1755:50: error: null pointer dereference
 [-Werror=null-dereference]
   onion_key, >addr, ap->port);
 ~~^~
 cc1.exe: all warnings being treated as errors
 make: *** [Makefile:8173: src/feature/hs/hs_common.o] Error 1
 make: *** Waiting for unfinished jobs
 }}}

 https://ci.appveyor.com/project/torproject/tor/build/job/7isiro2d4mryqtr0#L1825

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_revision
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


Comment:

 Replying to [comment:10 neel]:
 > My PR is here: https://github.com/torproject/tor/pull/252

 Thanks for this patch!

 The unit tests fail in the new function:
 https://travis-ci.org/torproject/tor/jobs/409667005#L3572

 Please add new commits to the branch to make them pass.

 You can run the unit tests before you push your branch using:
 {{{
 make check
 }}}

 You might be able to see the CI status on:
 https://github.com/torproject/tor/pull/252
 https://travis-ci.org/torproject/tor
 https://ci.appveyor.com/project/torproject/tor

 If you can't, let us know, and we'll work out how to get you access.

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

Re: [tor-bugs] #26955 [Core Tor/Tor]: Privcount blinding and encryption: rustfmt

[Tor Bug Tracker & Wiki]

#26955: Privcount blinding and encryption: rustfmt
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:3 chelseakomlo]:
 > There are a lot of changes in this PR so I didn't look at each one
 closely, but (from what I saw) if these changes are all automatic changes
 from running rustfmt on each file, then this looks good to merge to me.

 Thanks!

 > Btw, I set up my .vimrc to run rustfmt each time I save on the file that
 I'm working on, it might be helpful to do this for future work. This is
 what I used but I'm sure there are other options https://github.com/rust-
 lang/rust.vim#formatting-with-rustfmt

 I have done the same with emacs:
 https://github.com/rust-lang/rust-mode

 > As a note to the future, we should probably set up a CI task for core
 tor to check if Rust files haven't been formatted with rustfmt (I don't
 think we do this currently after looking at the build). I can open a
 ticket to track this.

 Thanks! Please post the ticket number here.

 I opened #26973 for the same change to the privcount_shamir CI.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26973 [Core Tor/Tor]: Privcount blinding and encryption: add rustfmt CI check

[Tor Bug Tracker & Wiki]

#26973: Privcount blinding and encryption: add rustfmt CI check
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  privcount, 035-roadmap-master, 035
 Severity:  Normal   |  -triaged-in-20180711, rust
Actual Points:   |  Parent ID:  #25669
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should check that rustfmt has been run on the privcount_shamir code in
 our CI. See:
 https://trac.torproject.org/projects/tor/ticket/26955?replyto=3#comment:3

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

Re: [tor-bugs] #26942 [Core Tor/Tor]: Privcount blinding and encryption: Rust code conventions

[Tor Bug Tracker & Wiki]

#26942: Privcount blinding and encryption: Rust code conventions
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:4 chelseakomlo]:
 > The fix for the function name looks good to me.
 >
 > I did another glance through for Rust conventions, and another
 convention fix I noticed is to follow Rust documentation conventions (see
 > https://doc.rust-lang.org/book/first-edition/comments.html and
 https://doc.rust-lang.org/book/second-edition/ch14-02-publishing-to-
 crates-io.html)
 >
 > For example,
 https://github.com/teor2345/privcount_shamir/blob/master/rust/src/shamir.rs#L22
 should probably be `///` to indicate a documentation comment and
 https://github.com/teor2345/privcount_shamir/blob/master/rust/src/shamir.rs#L1
 should probably be `//!` to indicate a crate/module comment

 Thanks!

 I'd like to fix the format of the doc comments when I add more doc
 comments in #26940.

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

Re: [tor-bugs] #26940 [Core Tor/Tor]: Privcount blinding and encryption: doc fixes

[Tor Bug Tracker & Wiki]

#26940: Privcount blinding and encryption: doc fixes
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 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:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I also need to fix the format of the doc comments, see:
 https://trac.torproject.org/projects/tor/ticket/26942?replyto=4#comment:4

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
--+
 Reporter:  chelseakomlo  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should have a CI task that ensures Rust files have been properly
 formatted- this will be helpful when reviewing PRs.

 Other linting tooling can be added here in the future (for example, any
 clippy warnings we want to explicitly check) but starting with rustfmt
 seems like a good first step.

 It looks like running rustfmt with `--check` will be helpful here:
 https://github.com/rust-lang-nursery/rustfmt#running

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 My PR is here: https://github.com/torproject/tor/pull/252

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

Re: [tor-bugs] #26955 [Core Tor/Tor]: Privcount blinding and encryption: rustfmt

[Tor Bug Tracker & Wiki]

#26955: Privcount blinding and encryption: rustfmt
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 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:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 There are a lot of changes in this PR so I didn't look at each one
 closely, but (from what I saw) if these changes are all automatic changes
 from running rustfmt on each file, then this looks good to merge to me.

 Btw, I set up my .vimrc to run rustfmt each time I save on the file that
 I'm working on, it might be helpful to do this for future work. This is
 what I used but I'm sure there are other options https://github.com/rust-
 lang/rust.vim#formatting-with-rustfmt

 As a note to the future, we should probably set up a CI task for core tor
 to check if Rust files haven't been formatted with rustfmt (I don't think
 we do this currently after looking at the build). I can open a ticket to
 track this.

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

Re: [tor-bugs] #26942 [Core Tor/Tor]: Privcount blinding and encryption: Rust code conventions

[Tor Bug Tracker & Wiki]

#26942: Privcount blinding and encryption: Rust code conventions
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | 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:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by chelseakomlo):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #26942 [Core Tor/Tor]: Privcount blinding and encryption: Rust code conventions

[Tor Bug Tracker & Wiki]

#26942: Privcount blinding and encryption: Rust code conventions
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 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:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 The fix for the function name looks good to me.

 I did another glance through for Rust conventions, and another convention
 fix I noticed is to follow Rust documentation conventions (see
 https://doc.rust-lang.org/book/first-edition/comments.html and https://doc
 .rust-lang.org/book/second-edition/ch14-02-publishing-to-crates-io.html)

 For example,
 https://github.com/teor2345/privcount_shamir/blob/master/rust/src/shamir.rs#L22
 should probably be `///` to indicate a documentation comment and
 https://github.com/teor2345/privcount_shamir/blob/master/rust/src/shamir.rs#L1
 should probably be `//!` to indicate a crate/module comment

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26971 [Core Tor/Tor]: Add rendezvous point unrecognised link specifiers to client introduce cells

[Tor Bug Tracker & Wiki]

#26971: Add rendezvous point unrecognised link specifiers to client introduce 
cells
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal|   Keywords:  prop224, tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Like #24181, we need to take unrecognised link specifiers from onion
 service descriptors, and put them in client introduce cells.

 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346

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

Re: [tor-bugs] #26925 [Core Tor/Tor]: Make link specifier handling in rend-spec-v3 more precise

[Tor Bug Tracker & Wiki]

#26925: Make link specifier handling in rend-spec-v3 more precise
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, doc, tor-relay, certs, |  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711|
Parent ID:  #26627   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Yes, we need to add IPv6 and unrecognized link specifiers to services in
 #24181, and unrecognised link specifiers to clients in #26971.

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

Re: [tor-bugs] #24181 [Core Tor/Tor]: Put IPv6 and unrecognised link specifiers in onion service EXTEND cells

[Tor Bug Tracker & Wiki]

#24181: Put IPv6 and unrecognised link specifiers in onion service EXTEND cells
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 prop224, tor-hs, single-onion, ipv6, tor-spec, 034-triage-20180328,
 034-removed-20180328
 =>
 prop224, tor-hs, single-onion, ipv6, 034-triage-20180328,
 034-removed-20180328


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

Re: [tor-bugs] #24181 [Core Tor/Tor]: Put IPv6 and unrecognised link specifiers in onion service EXTEND cells

[Tor Bug Tracker & Wiki]

#24181: Put IPv6 and unrecognised link specifiers in onion service EXTEND cells
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, tor-spec, 034-triage-20180328,   |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [ticket:24181 teor]:
 > Prop224 says:
 > {{{
 > The hidden service SHOULD NOT reject any LSTYPE fields which it
 > doesn't recognize; instead, it should use them verbatim in its EXTEND
 > request to the rendezvous point.
 > }}}
 > https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-
 ng.txt#n1689

 The latest reference is:

 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1714

 > ... we should:
 > * add a similar sentence for client descriptor lspecs

 I did this spec update in #26925. It's at:

 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:8 neel]:
 > In `ed25519_cert.h`, `link_specifier_t`/`link_specifier_st` looks like
 this:
 >
 > {{{
 > struct link_specifier_st {
 >   uint8_t ls_type;
 >   uint8_t ls_len;
 >   uint32_t un_ipv4_addr;
 >   uint16_t un_ipv4_port;
 >   uint8_t un_ipv6_addr[16];
 >   uint16_t un_ipv6_port;
 >   uint8_t un_legacy_id[20];
 >   uint8_t un_ed25519_id[32];
 >   TRUNNEL_DYNARRAY_HEAD(, uint8_t) un_unrecognized;
 >   uint8_t trunnel_error_code_;
 > };
 > }}}
 >
 > But the `fascist_firewall_choose_address_*` family of functions defines
 DirPorts in the function, like this:
 >
 > {{{
 > static void
 > fascist_firewall_choose_address_base(const tor_addr_t *ipv4_addr,
 >  uint16_t ipv4_orport,
 >  uint16_t ipv4_dirport,
 >  const tor_addr_t *ipv6_addr,
 >  uint16_t ipv6_orport,
 >  uint16_t ipv6_dirport,
 >  firewall_connection_t
 fw_connection,
 >  int pref_only,
 >  int pref_ipv6,
 >  tor_addr_port_t* ap)
 > }}}
 >
 > Should I then assume the `ipv4_dirport` and `ipv6_dirport` is `0`?

 Yes, link specifiers are only defined for ORPorts.
 Also, #24732 will remove the IPv6 DirPort code, because it's unused.

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

Re: [tor-bugs] #26953 [Core Tor/Tor]: Privcount blinding and encryption: add travis CI

[Tor Bug Tracker & Wiki]

#26953: Privcount blinding and encryption: add travis CI
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 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:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:3 chelseakomlo]:
 > This looks good to me, but someone else who has worked with Travis more
 should also take a look.

 I expect someone will be assigned to review this ticket today.

 I'll answer your other question in #26970.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26970 [Core Tor/Tor]: Privcount: plan the modules and components

[Tor Bug Tracker & Wiki]

#26970: Privcount: plan the modules and components
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  privcount, 035-roadmap-master, 035
 Severity:  Normal   |  -triaged-in-20180711, rust
Actual Points:   |  Parent ID:  #25669
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Replying to [26953#comment:3 chelseakomlo]:
 > Is the idea that this project will remain external to core tor, or will
 this one day be merged into the core codebase? Definitely having CI in the
 short term seems wise either way.

 That's a good question, nickm and I haven't discussed it yet. And I think
 we'd benefit from your advice.

 For PrivCount in Tor, we need to produce the following components:

  * a Rust "Data Collector" module in Tor that does blinding, encryption,
 and noise, based on a config
  * a separate "Tally Reporter" binary that does unblinding, decryption,
 aggregation, and reporting, based on a config
  * some tools for creating and validating configurations

 One possible design is:
 * Rust modules for blinding/encryption, noise, aggregation, reporting, and
 config
 * Glue code and module imports for the Tor Data Collector
 * Application code and module imports for the Tally Reporter
 * Application code and module imports for the tools

 Split off
 https://trac.torproject.org/projects/tor/ticket/26953?replyto=3#comment:3

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

Re: [tor-bugs] #26227 [Core Tor/Stem]: Review existing stem.client code

[Tor Bug Tracker & Wiki]

#26227: Review existing stem.client code
---+-
 Reporter:  dmr|  Owner:  dmr
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+-
Changes (by atagar):

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


Comment:

 Hi Dave, think everything's merged. Unsure there's value in keeping this
 open so tidying it up.

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

Re: [tor-bugs] #26226 [Core Tor/Stem]: Plan/discuss stem.client architecture/design

[Tor Bug Tracker & Wiki]

#26226: Plan/discuss stem.client architecture/design
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Hi Dave, tidying up our tickets a bit. We've discussed project scope since
 this so doubt we still need this ticket. Feel free to reopen if you think
 it's still useful.

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

Re: [tor-bugs] #19679 [Core Tor/Stem]: Collapsible FAQ items

[Tor Bug Tracker & Wiki]

#19679: Collapsible FAQ items
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  website easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

 * status:  needs_review => new


Comment:

 Oops, shame on me for not replying to this. Iirc this code contribution
 was part of a gsoc application a year back. One of the commits modifies
 the faq a bit and drops one of the answers. Might be a good starting point
 but needs some work.

 If someone picks them up I'd encourage for them to look at what we did for
 Nyx. If we can adapt that to work with Sphinx that would likely be best.

 https://nyx.torproject.org/#faq
 https://gitweb.torproject.org/nyx.git/tree/web

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

Re: [tor-bugs] #26053 [Core Tor/Stem]: controller.signal(stem.Signal.NEWNYM) gives error

[Tor Bug Tracker & Wiki]

#26053: controller.signal(stem.Signal.NEWNYM) gives  error
---+--
 Reporter:  cypherpunks|  Owner:  atagar
 Type:  project| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.3.5-rc
 Severity:  Normal | Resolution:  user disappeared
 Keywords:  controller |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

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


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

Re: [tor-bugs] #26967 [Core Tor/Stem]: Drop distutils dependency

[Tor Bug Tracker & Wiki]

#26967: Drop distutils dependency
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Fix pushed...

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

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

Re: [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:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by nusenu):

 yes I didn't open the ticket yet since my use-case needs the data in the
 new fields and the new fields are not filled with much data yet (might be
 somewhat related to #26963 even though the ticket is specifically about
 the old host_name)

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

Re: [tor-bugs] #26968 [- Select a component]: Dragging tor browser bundle icon on windows 10 start menu uses firefox icon

[Tor Bug Tracker & Wiki]

#26968: Dragging tor browser bundle icon on windows 10 start menu uses firefox 
icon
--+--
 Reporter:  spaceship9876 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.3.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ProTipGuyFWIWWeLoveARMA):

 For the ESR 60 based Tor Browser it has been fixed, see: #26519. The bug
 will no longer be found in the next alpha which should be coming in the
 next week or so.

 teor: We can no longer modify tickets to rectify trivial things such as
 inappropriate components, versions, keyword, ... Please kindly bring the
 previous permissions to let us make your triage and cleanup work easier (I
 can no longer close HTTPS-E bugs for example to clean them up).

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

Re: [tor-bugs] #23549 [Metrics/Website]: Move ExoneraTorServlet to metrics-web

[Tor Bug Tracker & Wiki]

#23549: Move ExoneraTorServlet to metrics-web
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_revision => accepted


Comment:

 Replying to [comment:16 irl]:
 > This patch looks good to me.

 Great! Pushed to metrics-base master.

 > Perhaps now there is a plan it is better to start again with a new
 ticket.

 The comment history is indeed long. But I think I'd prefer to keep it by
 staying on this ticket. After all, it was useful to discuss the possible
 options. What we can do is write down what steps remain before resuming
 work here and maybe even edit the summary to point to the comment with the
 summary. And if that turns out to be still too confusing, we can then
 switch to a new ticket. Hope that works for you, 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

[tor-bugs] #26969 [Metrics/Onionoo]: Uprade to latest metrics-base in order to produce a thin jar

[Tor Bug Tracker & Wiki]

#26969: Uprade to latest metrics-base in order to produce a thin jar
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Onionoo 1.16.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 As part of ExoneraTor ticket #23549, we're updating metrics-base to also
 produce a thin jar to be used in other code. We should upgrade to that
 metrics-base version in Onionoo before we put out the next release.

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

Re: [tor-bugs] #25177 [Metrics/Onionoo]: Remove redundant clients graphs

[Tor Bug Tracker & Wiki]

#25177: Remove redundant clients graphs
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Onionoo 1.16.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * milestone:   => Onionoo 1.16.0


Comment:

 Planning to do this for the upcoming release.

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

Re: [tor-bugs] #23713 [Metrics/Onionoo]: Expand parameters and fields around AS number and names

[Tor Bug Tracker & Wiki]

#23713: Expand parameters and fields around AS number and names
-+
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo 1.16.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+
Changes (by karsten):

 * status:  merge_ready => closed
 * resolution:   => implemented
 * milestone:   => Onionoo 1.16.0


Comment:

 Great, merging! Adding to the Onionoo 1.16.0 milestone so that we don't
 forget to document the change in metrics-web when we put out the release.
 Closing. Thanks!

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

Re: [tor-bugs] #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:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  reopened => needs_information


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

Re: [tor-bugs] #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:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 I noticed that you did not open that new ticket yet, unless I missed it.
 I'll reopen this one just to avoid that we're losing track of this feature
 request. We can still close this ticket if we're either working on this
 change as part of the other ticket, or deciding that we're not going to do
 it.

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

Re: [tor-bugs] #26968 [- Select a component]: Dragging tor browser bundle icon on windows 10 start menu uses firefox icon

[Tor Bug Tracker & Wiki]

#26968: Dragging tor browser bundle icon on windows 10 start menu uses firefox 
icon
--+--
 Reporter:  spaceship9876 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.3.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by spaceship9876):

 * Attachment "tor.png" added.


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

[tor-bugs] #26968 [- Select a component]: Dragging tor browser bundle icon on windows 10 start menu uses firefox icon

[Tor Bug Tracker & Wiki]

#26968: Dragging tor browser bundle icon on windows 10 start menu uses firefox 
icon
--+--
 Reporter:  spaceship9876 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.3.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 If i drag the tor browser bundle from the start menu list in windows 10 to
 the shortcut section of the start menu it changes to the firefox icon.
 This has happened for the past few months of updates of tor browser bundle
 stable. This also happens with the alpha version of tor browser bundle
 which uses firefox 60 ESR. Attached is a screenshot. Please fix this bug,
 kind regards.

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

Re: [tor-bugs] #26919 [Metrics/Onionoo]: Remove fingerprint parameter

[Tor Bug Tracker & Wiki]

#26919: Remove fingerprint parameter
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Onionoo 1.16.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * status:  new => needs_review
 * milestone:   => Onionoo 1.16.0


Comment:

 Replying to [comment:2 karsten]:
 > What we could do is extend the statistics to include less frequent
 parameter combinations beyond the top 3 without giving a request count for
 privacy reasons. Then we'd at least find out whether the fingerprint
 parameter is used at all, over a day or two.

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-26919=d767dba374bef548a6f64c1932b954b702b0cacb
 commit d767dba in my task-26919 branch].

 If this patch looks okay, let's include it in the next release and
 announce for a month later that we're going to remove the parameter. And
 just in case it turns out that the "fingerprint" parameter is used more
 than we thought, we can still leave it in. (We'll do another change in
 that next major version, which is the "version" parameter change, so there
 will still be a new major version.)

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

Re: [tor-bugs] #6947 [Metrics/Onionoo]: Allow filtering relays by version ranges

[Tor Bug Tracker & Wiki]

#6947: Allow filtering relays by version ranges
-+--
 Reporter:  rransom  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-6947=9740ce76bd10d11772ec7250b9c23d33b4e99866
 commit 9740ce7 in my task-6947 branch]. Once this patch is merge-ready,
 let's schedule the next major version for a month later and put the merge
 on hold for that time. 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] #26966 [- Select a component]: More public meek bridges to use

[Tor Bug Tracker & Wiki]

#26966: More public meek bridges to use
--+
 Reporter:  imwt  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by tgragnato):

 Providers are dropping support for domain fronting as a consequence of
 pressures.

 A covert website with real content is easy to set up and a domain costs a
 couple of bucks. HTTPS can still be used to bypass DPI, but I wonder how
 useful meek without fronting is.

 The launcher may be extended to ask for your own domain, but if you can
 set up a private meek instance, you are also able to set up meek in the
 browser.

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

Re: [tor-bugs] #23978 [Core Tor/Tor]: Write simulator to evaluate security of Prop247 parameter choices

[Tor Bug Tracker & Wiki]

#23978: Write simulator to evaluate security of Prop247 parameter choices
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  guard-discovery-prop247-experiments  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by asn):

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


Comment:

 This is done. See https://github.com/asn-d6/vanguard_simulator/wiki
 /Optimizing-vanguard-topologies for results.

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

Re: [tor-bugs] #26963 [Metrics/Onionoo]: regression in host_name field introduced in v6.1

[Tor Bug Tracker & Wiki]

#26963: regression in host_name field introduced in v6.1
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * priority:  Medium => High
 * cc: metrics-team (added)


Comment:

 Let's take a look at Onionoo's internal statistics:

 {{{
 2018-07-29 08:40:37,001 Reverse domain name resolver
 19 lookups performed
 11 verified results found
 1 unverified results found
 00:00.058 minutes minimum lookup time
 00:01.039 minutes median lookup time
 00:03.370 minutes maximum lookup time
 }}}

 Here's a plot of those six numbers for July 2018 so far:

 [[Image(onionoo-rdns-stats.png​)]]

 No doubt, there's a change on or around July 16 when we deployed the new
 lookup code. The total number of lookups performed per hour went down a
 lot. It didn't go down to zero, so it's still doing something, but it went
 down enough to be too low to be useful.

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

Re: [tor-bugs] #26963 [Metrics/Onionoo]: regression in host_name field introduced in v6.1

[Tor Bug Tracker & Wiki]

#26963: regression in host_name field introduced in v6.1
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "onionoo-rdns-stats.png" added.


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

Re: [tor-bugs] #26950 [Metrics/Website]: Remove "Fraction of relays reporting onion-service statistics" graph

[Tor Bug Tracker & Wiki]

#26950: Remove "Fraction of relays reporting onion-service statistics" graph
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Great, thanks for commenting! Leaving this ticket out here for a few more
 days, just in case anybody objects, and then killing the graph.

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