Re: [tor-bugs] #23576 [Core Tor/Tor]: Make service_intro_point_new() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23576: Make service_intro_point_new() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
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, fast-fix |
Parent ID:  #23493   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Pull request is:
 https://github.com/torproject/tor/pull/254

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26990 [Webpages/Website]: Please add job to website - Grants Manager

[Tor Bug Tracker & Wiki]

#26990: Please add job to website - Grants Manager
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 These sentences are duplicated:
 {{{
 The Tor Project's workforce is smart and committed. Experience working
 with open source communities and/or a dedication to Internet freedom are
 added pluses.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Hi Neel, thanks for this pull request.

 I did a review on the pull request on github:
 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] #26991 [Internal Services/Tor Sysadmin Team]: Please retire Heather's LDAP account

[Tor Bug Tracker & Wiki]

#26991: Please retire Heather's LDAP account
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by details):

 Uh oh. Chief Financial and Grants Officer of The Tor Project.
 Twitter account deleted.
 We need more details. no?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23576 [Core Tor/Tor]: Make service_intro_point_new() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23576: Make service_intro_point_new() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
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, fast-fix |
Parent ID:  #23493   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23576 [Core Tor/Tor]: Make service_intro_point_new() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23576: Make service_intro_point_new() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
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:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See my branch bug23576 on https://github.com/teor2345/tor.git

 This refactor also puts intro IPv6 link specifiers in onion service
 descriptors (#26992).

 It passes make check and make test-network-all on my machine, but will
 probably fail Appveyor CI due to #26986.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23576 [Core Tor/Tor]: Make service_intro_point_new() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23576: Make service_intro_point_new() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
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:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  dgoulet => teor
 * version:   => Tor: 0.3.2.1-alpha
 * milestone:  Tor: unspecified => Tor: 0.3.5.x-final


Comment:

 We can implement this ticket easily by replacing the link specifier part
 of service_intro_point_new() with get_lspecs_from_node().


 This refactor completes part of #23759.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26992 [Core Tor/Tor]: Add intro point IPv6 address to service descriptors

[Tor Bug Tracker & Wiki]

#26992: Add intro point IPv6 address to service descriptors
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23576   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * parent:  #23493 => #23576


Comment:

 Reviewing in #23576.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26992 [Core Tor/Tor]: Add intro point IPv6 address to service descriptors

[Tor Bug Tracker & Wiki]

#26992: Add intro point IPv6 address to service descriptors
-+-
 Reporter:  teor |  Owner:  teor
 Type:   | Status:  assigned
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  prop224, tor-hs, single-onion,
 Severity:  Normal   |  ipv6, 034-triage-20180328, 034-removed-20180328
Actual Points:   |  Parent ID:  #23493
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Implemented as a consequence of #23576, but I need a ticket number.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19664 [Core Tor/Tor]: IPv6-only Tor2web should use a 3-hop path on unreachable or failed intro or rend

[Tor Bug Tracker & Wiki]

#19664: IPv6-only Tor2web should use a 3-hop path on unreachable or failed 
intro or
rend
-+--
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor2web  |  Actual Points:
Parent ID:  #26367   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * parent:   => #26367


Comment:

 This ticket can close as "wontfix" when we merge #26367.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23759 [Core Tor/Tor]: Refactor common code out of setup_introduce1_data and intro point functions

[Tor Bug Tracker & Wiki]

#23759: Refactor common code out of setup_introduce1_data and intro point 
functions
-+-
 Reporter:  teor |  Owner:  dgoulet
 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, refactor, 034-triage-20180328,   |
  034-removed-20180328   |
Parent ID:  #22781   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #23576 => #22781


Old description:

> During #23577, we discovered that there's a lot of code in
> setup_introduce1_data() that's duplicated in service_intro_point_new()
> and hs_desc_lspec_to_trunnel().
>
> And in #23577, we want to copy more of it.
>
> So we should clean that up at some point, but it's complicated, because
> the intro point functions use hs_desc_link_specifier_t.
>
> Or we could add comments in the duplicate code to tell us to check the
> other functions when any one of them changes.

New description:

 During #23577, we discovered that there's a lot of code in
 setup_introduce1_data() that's duplicated in service_intro_point_new() and
 hs_desc_lspec_to_trunnel().

 In #23576, we removed the duplication across setup_introduce1_data() and
 service_intro_point_new(), creating node_get_link_specifier_smartlist().

 So we should clean that up at some point, but it's complicated, because
 the intro point functions use hs_desc_link_specifier_t. (See #22781)

 Edit: update after #23576.

--

Comment:

 Oops, no we don't.

 Fixing #23576 removes the duplication across setup_introduce1_data() and
 service_intro_point_new().

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26991 [Internal Services/Tor Sysadmin Team]: Please retire Heather's LDAP account

[Tor Bug Tracker & Wiki]

#26991: Please retire Heather's LDAP account
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Yes please (alas).

 And in this case I believe Erin means "inactive", not just "retire", since
 it's more of an employment thing so it shouldn't phase out over six
 months.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23759 [Core Tor/Tor]: Refactor common code out of setup_introduce1_data and intro point functions

[Tor Bug Tracker & Wiki]

#23759: Refactor common code out of setup_introduce1_data and intro point 
functions
-+-
 Reporter:  teor |  Owner:  dgoulet
 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, refactor, 034-triage-20180328,   |
  034-removed-20180328   |
Parent ID:  #23576   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #23493 => #23576


Comment:

 We need this refactor for #23576.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26991 [Internal Services/Tor Sysadmin Team]: Please retire Heather's LDAP account

[Tor Bug Tracker & Wiki]

#26991: Please retire Heather's LDAP account
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Please retire Heather’s LDAP account, effective immediately. Heather is no
 longer at TPI; formal announcement coming soon.
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAltf1pQACgkQugyUAPgP
 kc4Hww//eHrilThQR7Ug1nk/W8BMtsCa8azcFW1ZIqt+6bNiIvU71Y0Aq7/db+KH
 W+g7f0Y76jzPV99DkACcrPsEPjM48uNy6iNI4z3HsNxq9+eyHgMY6JOrJI4RAnar
 OIoY31AiccHFwZujAvGqnONoOXEfdnTDSw7f+6Bj0QRLfP1Ulk++wDOPp+Rc9V5l
 Zic+H6ls1e35UkYNNMIRcn8bci25DypYwsqM8WSyBAMBISk3uW/bB5ScPpUeL1t7
 MA80cBlZkeKswkJ88e+hhyIOvyI8IDvP9iA+U9txGJ4uWZt3gQ9Y2tiOPxAcpVok
 mHnLGQWrk0seRC3saeYovlqEtpDQQBqcoCFn0BVjeFWYTK24qgOb6uO6p1ZRMB7V
 ZrmzKXMVs61yGOS1T/dA5a77nG6pfsGU/4IhSvoanuuSBtsGnFV/tlslVjon4zJI
 p2AdGo/97ayukx9/AyFl3i9t95RS3hslKyt1kEJBJ4Ww/Skh2dW4rBleKcmmUHJ9
 nalA5zakPE37i3Y4tlAbGLJ+qe1c69U0vCC/NBUff238ncB6/ikL4GR3+N+a6xtL
 hebtfw/QiCk15XKtIi7j+BfIpSueBcPi37r+lT90iPp340s8gDxQFFFhwtAiavjz
 J8M7dMm/I7AO5EQVKL+s0cyMrIQIQR+B2iim/CDHRo0HXsLJcEM=
 =GLqy
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26990 [Webpages/Website]: Please add job to website - Grants Manager

[Tor Bug Tracker & Wiki]

#26990: Please add job to website - Grants Manager
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Internet Freedom Nonprofit Seeks Experienced Grants Manager

 The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human
 rights and freedoms by creating and deploying free and open source
 anonymity and privacy technologies, is seeking an experienced Grants
 Manager to provide fiscal oversight to our federal and foundation grants
 and contracts.

 The ideal candidate will have at least three years of experience
 monitoring federal grants and contracts, as well as multi-year grants from
 private foundations. This position reports to our CFO and will work
 closely with our fundraising and management teams.

 Tasks include, but are not limited to:

 •   Maintain files and documentation for our grants and
 contracts to ensure compliance with funder requirements and progress
 toward annual goals.
 •   Communicate the status of grant activities and progress
 toward objectives to stakeholders.
 •   Send monthly reports to front line managers indicating the
 current status of grants worked on by their teams.
 •   Manage invoicing and billing of federal contracts to
 ensure full payment is received.
 •   Pull financial reports to be used in grant reporting.
 •   Help with budgeting for new grant proposals.
 •   Monitor and track grants through our Granthub software.
 •   Review current organizational procedures and suggest ways
 to streamline processes, as requested.

 The person we seek should have the following qualities, skills, and
 abilities:

 •   Must be comfortable working in a paperless office.
 •   Experience creating spreadsheets to be used for predictive
 modelling.
 •   Proficient understanding of and ability to use technology;
 willingness and ability to learn and use new technologies.
 •   Conscientious, hard working, and highly organized with
 superior attention to detail.
 •   Must be a self-starter who thrives on working
 independently
 •   Willingness to seek additional assistance when new
 challenges present themselves.
 •   Willingness to travel to international meetings at least
 twice a year.

 The Tor Project's workforce is smart and committed. Experience working
 with open source communities and/or a dedication to Internet freedom are
 added pluses.

 The Tor Project's workforce is smart and committed. Experience working
 with open source communities and/or a dedication to Internet freedom are
 added pluses. The Tor Project currently has a paid and contract staff of
 around 35 developers and operational support staff, plus many thousands of
 volunteers who contribute to our work. The Tor Project is funded in part
 by government research and development grants, and in part by individual,
 foundation and corporate donations.

 Flexible salary, depending on experience. The Tor Project has a
 competitive benefits package, including a generous PTO policy; 14 paid
 holidays per year (including the week between Christmas and New Year's,
 when the office is closed); health, vision, dental, disability, and life
 insurance paid in full for employee; and flexible work schedule.

 This is a full-time, hands-on position, which can be done remotely or in
 our office in Seattle, WA. To apply, send a cover letter and your resume
 to hr at torproject dot org with “Grants Manager” in the subject line.
 Tell us why you think you’re the right person for this job and why you
 want to work at Tor Project. No phone calls please!

 The Tor Project, Inc., is an equal opportunity, affirmative action
 employer.


 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAltf1FQACgkQugyUAPgP
 kc5THA/7BoGyQmILYp8xFV+dDnwOoYU8LPlv72FeR6gRVSSAPRdSG9WKXu66Pal7
 AWwZP1eQjml/miigHgldJ++WSxH75rkHLQmbTDhigfUb3jpp+DafyhpoRWGwS3ju
 0XU7+eMYCnZs89s2CUy0+FUYK7vfJ767Q8zgw1J7SPGvFU7yqI8jEHkj5rZs4XqE
 5OLro/eL6dzEO5sQfJYHnYNpZpPhPKWNYoOpxUWaoehx/dHQyPkVGXynOYvwB1eb
 qPIycWO4G1nR2VtIDkOQRCs89txVpMojXhH+JkxVswYS91LtzsQ/PRckSbwrA3pc
 UFQtGU73bjOyChstNKAR3ziIOkycg9bg2wdZe0lr4yQO3DFit70zLP0kRGpyIckh
 ZpLs9P9sKyQkPAuqGyoeRICDSYSapar3Dgy9TjyGoyAUh6Pjtj6cUuEnHEiv42VR
 DkS4Q7BTs45o//gkX+m+Kz5BGaSFOHH3n9c3zILQwS3hWTEi+Ff2tvEL58be9y1M
 

[tor-bugs] #26989 [Webpages/Website]: Please add job to website - Grant Writer

[Tor Bug Tracker & Wiki]

#26989: Please add job to website - Grant Writer
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Internet Freedom Nonprofit Seeks Grant Writer

 The Tor Project, Inc., a 501(c)(3) nonprofit organization that provides
 technical infrastructure for privacy protection over the Internet, is
 seeking a strong grant writer to help us develop and write winning grant
 proposals designed to secure funding from public institutions, private
 foundations, corporations and other grant-making entities. The ideal
 candidate will be familiar with issues involving high-tech freedom and can
 make a compelling case about why our work is so important to current and
 potential funders. This person must be able to write clearly and provide
 context for the Tor Project’s complicated technology and activism
 projects. The ability to explain technical concepts to non-technical
 audiences is essential.

 The grant writer is responsible for researching grant opportunities,
 sending out letters of inquiry and proposals, keeping track of dates and
 deadlines, and submitting reports at the end of the grant periods. The Tor
 Project consists of several teams that each own multiple sub-projects with
 different needs and priorities. The grant writer will need to build a
 grant proposal pipeline by organizing our ideas and needs into a database
 that can be accessed as opportunities present themselves while
 coordinating prioritization with our leadership team.

 This person is also responsible for additional fundraising writing
 projects that might come up, such as updating the "one-pagers" we
 distribute at conferences. The Tor Project works on Internet freedom
 issues, and in many ways our grant proposals and reports are more like
 activism pieces than traditional pleas for funding, so a background in
 writing about these issues would be ideal.

 Qualifications:
 •At least 3 years of grant writing experience with private
 foundations, federal government contracts, and corporations.
 •Must be a strong writer with proven ability to create clear,
 structured, articulate, and persuasive proposals.
 •Comfortable with highly technical topics and able to explain them
 clearly and accurately to non-technical audiences.
 •Knowledge of and appreciation for the free and open source
 software movement.
 •Strong generalist understanding of the basic mechanics of how the
 Internet works, as well as issues related to privacy, security,
 censorship, and surveillance.
 •Experience with, or willingness to learn how to use,
 communications and collaboration technologies such as PGP, IRC, Jitsi,
 WordPress, and etherpads.
 •Hard-working and highly organized with superior attention to
 detail.
 •Highly collaborative with experience working with and as part of
 remote teams.
 •Self-starter who thrives on working independently with a
 dispersed workforce.
 •Experience working or living outside the United States is a plus.
 •Willingness to travel to international meetings twice a year.
 •Excellent social skills and a sense of humor.

 The ideal candidate will be energetic, unflappable and flexible, and will
 thrive in a highly-technical collaborative environment.

 The Tor Project's workforce is smart and committed. Experience working
 with open source communities and/or a dedication to Internet freedom are
 added pluses. The Tor Project currently has a paid and contract staff of
 around 35 developers and operational support staff, plus many thousands of
 volunteers who contribute to our work. The Tor Project is funded in part
 by government research and development grants, and in part by individual,
 foundation and corporate donations.

 Flexible salary, depending on experience. The Tor Project has a
 competitive benefits package, including a generous PTO policy; 14 paid
 holidays per year (including the week between Christmas and New Year's,
 when the office is closed); health, vision, dental, disability, and life
 insurance paid in full for employee; flexible work schedule; and
 occasional travel opportunities.

 This is a full-time position. The Tor Project’s main office is in Seattle,
 and we’d be delighted to supply a desk for this position there, however,
 this job can be done remotely.

 To apply, send a cover letter and your resume to hr at torproject dot org
 with the subject “Grant Writer." Tell us why you think you're the right
 person for this job, why you 

[tor-bugs] #26988 [Webpages/Website]: Please add job to website - Bookkeeper/Payroll Specialist

[Tor Bug Tracker & Wiki]

#26988: Please add job to website - Bookkeeper/Payroll Specialist
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Internet Freedom Nonprofit Seeks Experienced Bookkeeper/Payroll Specialist

 The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human
 rights and freedoms by creating and deploying free and open source
 anonymity and privacy technologies, is seeking an experienced non-profit
 QuickBooks Bookkeeper/Payroll Specialist.

 The ideal candidate will have at least five years of experience in
 bookkeeping for non-profit organizations, as well as multiple years of
 experience in domestic and international payroll implementation and
 processing. This position reports to our CFO and will work closely with
 the Grants Manager.

 Tasks include, but are not limited to:

 ·  Processing accounts payable and receivable
 ·  Reconciling bank accounts and credit card accounts
 ·  Reconciling expense reports, processing reimbursements, and
 tracking receipts
 ·  Processing domestic and foreign payrolls using multiple payroll
 platforms, including compliance with international, federal, and state
 requirements
 ·  Onboarding employees into the payroll systems
 ·  Integrating data from multiple software platforms
 ·  Assisting in the preparation of materials for annual 990 tax
 returns and audit
 ·  Tracking 1099 vendors and creating annual 1099s
 ·  Preparing annual 401K census reports
 ·  Creating general ledger entries
 ·  Assisting in the preparation of workers compensation audits
 ·  Willingness to do other miscellaneous bookkeeping-related tasks as
 needed

 The person we seek should have the following qualities, skills, and
 abilities:

 ·  At least 5+ years non-profit bookkeeping experience; Bachelor’s
 degree preferred
 ·  Highly competent in QuickBooks
 ·  Advanced working knowledge of Excel spreadsheets, specifically
 including complex formulas
 ·  Must be comfortable working in a paperless office
 ·  Proficient understanding of and ability to use technology;
 willingness and ability to learn and use new technologies
 ·  Conscientious, hard working, and highly organized with superior
 attention to detail
 ·  Must be a self-starter who thrives on working independently but who
 is also comfortable helping other staff members
 ·  Must be comfortable asking staff members for information, such as
 expense reports and required reporting data
 ·  Willingness to seek additional assistance when new challenges
 present themselves
 ·  Willingness to travel to international meetings at least twice a
 year

 The Tor Project's workforce is smart, passionate, and dedicated.
 Experience working with open source communities and/or a commitment to
 Internet civil liberties are added pluses for any candidate applying for
 this position.

 Flexible salary, depending on experience. The Tor Project has a
 competitive benefits package, including a generous PTO policy; 14 paid
 holidays per year (including the week between Christmas and New Year's,
 when the office is closed); health, vision, dental, disability, and life
 insurance paid in full for employee; and flexible work schedule.

 This is a full-time, hands-on position, which can be done remotely or in
 our office in Seattle, WA. To apply, send a cover letter and your resume
 to hr at torproject dot org with “Bookkeeper/Payroll Specialist” in the
 subject line. Tell us why you think you’re the right person for this job
 and why you want to work at Tor Project. No phone calls please!

 The Tor Project, Inc., is an equal opportunity, affirmative action
 employer.


 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAltf06wACgkQugyUAPgP
 kc5FCA//WHQk9rQAis+xqxF/DAsRJ4HZSDgzAQX4Z39J6M4CwCjqVaX9H67PJvfr
 a7TarbqgvzdWKhRulM6JCxUtF8Rnoph4+WXRhQ9yWZqheC/27CSe0w8tQBpYzSTp
 uVlZmcnTuO82EXAqX464Lq5F7BHzfWxaq78ZEG6sOmZyTrU27W4NF8RI1l2LBs72
 YtWbMpPDBhrfdNe6om6o5wy36ifnFvfkdHDsEH/jO0FNESHz+Dk6mwamKQAjLUi4
 PsGmEKpZ4uPhL/Ml/Lb6x8qBT5377v7dVqya/DG4V/OVqGhlqPzla/Zj+iLoPq1Q
 4wTnwlMre4SorwsqF/UFk7lGGIqahe4xVSpv0zRb+mzJyW9RwUm+ucMal2pKk6k0
 v2qk2l+RYghq/AXDd2aETxKVZSSjJYZBnd9JqgfjbTGkQCYcU7KGeTrtPsgdVudk
 5M0/J0i7oOA3KtoCMbY1rV8aOm84T/PbTKJ6leaP21kzhehGj4QY6PdJAv48D+2k
 CwH4+RvQ4SipgiK0oLu++LODQNbYQ7OA588UUDIApOG5ZRLAxVdKRk1ZSgQT7v0T
 A9B/7wdKCheAlddXkwEPjB+vrDQse4YL2c9c2ihnx0E4NH3M9mn0wC6t6fv0BhKH
 

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_review
 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:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * reviewer:   => teor


Comment:

 Appveyor builds on the latest master are failing due to #26986, so I
 merged the fix to b23588 and pushed to https://github.com/teor2345/tor.git

 I'll review your branch once the CI succeeds.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, certs,|  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711,   |
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 I don't think we need to backport to 0.3.2, because we're only supporting
 0.3.2 for another 10 weeks.

 Instead, we should encourage operators to upgrade to 0.3.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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, tor-relay, certs,|  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711,   |
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => 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] #26979 [Core Tor/Tor]: Appveyor CI IRC shows the wrong branch for pull requests

[Tor Bug Tracker & Wiki]

#26979: Appveyor CI IRC shows the wrong branch for pull requests
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, appveyor, windows, fast-fix  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 Please see my branch bug26979 on https://github.com/teor2345/tor.git

 It produces the following output on pull requests:
 {{{
 torproject/tor master pull teor2345/tor bug26979 c3fca338a2 - teor:
 Appveyor CI: always use HEAD for the short commit
 Build #1.0.470 failed. Details:
 https://ci.appveyor.com/project/torproject/tor/build/1.0.470
 Commit:
 https://github.com/teor2345/tor/commit/c3fca338a2c63241497b64a9f997c28f17ef1b6a
 Pull: https://github.com/torproject/tor/pull/253
 }}}

 And the following output on tags:
 {{{
 teor2345/tor bug26979-appveyor-tag-test 3d3e62d147 - teor: Appveyor CI:
 Switch to one URL per line
 Build #1.0.30 failed. Details:
 https://ci.appveyor.com/project/teor2345/tor/build/1.0.30
 Commit:
 https://github.com/teor2345/tor/commit/3d3e62d1474a386f6a46fe6a8c5d6c7c5bed4f85
 }}}

 The builds fail due to #26986.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22170 [Applications/Tor Browser]: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy safety on Android

[Tor Bug Tracker & Wiki]

#22170: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy 
safety
on Android
-+-
 Reporter:  gk   |  Owner:  sysrqb
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-mobile,|  Actual Points:
  TorBrowserTeam201807   |
Parent ID:  #21863   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:20 sysrqb]:
 > All files where Fennec uses `impl.client`
 >
 > {{{
 > $ git grep -n ch.boye.httpclientandroidlib.impl.client
 mobile/android/[bs]*
 >
 
mobile/android/base/java/org/mozilla/gecko/telemetry/TelemetryUploadService.java:15:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 We should never get here because its telemetry, but it's worth checking.
 The DefaultHttpClient is passed in, but not created. The `DATE` headers is
 set. A `BaseResource` is created and `BaseResource.postBlocking()` is
 called. The proxy will be set within `BaseResource.execute()`.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/background/fxa/FxAccountClient20.java:50:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 All connections are created via `BaseResource`. DefaultHttpClient is
 passed into an `addHeader()` where an `ACCEPT_LANGAUGE` and `ACCEPT`
 header is added.

 Note: FxA uses a unique user agent string in its request.
 https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/services/src/main/java/org/mozilla/gecko/fxa/FxAccountConstants.java?h
 =tor-browser-60.1.0esr-8.0-1#n40

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/background/fxa/oauth/FxAccountAbstractClient.java:30:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 DefaultHttpClient is passed into an `addHeader()` where an
 `ACCEPT_LANGAUGE` and `ACCEPT` header is added.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/push/autopush/AutopushClient.java:35:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 {{{
 /**
  * Interact with the autopush endpoint HTTP API.
  * 
  * The API is a Mozilla-proprietary interface, and not even specified to
 Mozilla's usual ad-hoc standards.
  * This client is written against a work-in-progress, un-deployed upstream
 commit.
  */
 }}}

 That's reassuring.

 All connections are created via `BaseResource`. DefaultHttpClient is
 passed into an `addHeader()` where an `ACCEPT_LANGAUGE` and `ACCEPT`
 header is added.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/AbstractBearerTokenAuthHeaderProvider.java:9:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 `DefaultHttpClient` isn't used. No network calls in this class.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/AuthHeaderProvider.java:11:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 This is an `interface`, no logic here.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java:51:import
 ch.boye.httpclientandroidlib.impl.client.BasicAuthCache;
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java:52:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 This class is probably proxy-safe. I'll need to look at this again (and a
 second pair of eyes would be welcome).

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResourceDelegate.java:8:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 This class only provides accessors and mutators, no network calls.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BasicAuthHeaderProvider.java:12:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 No network calls.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/HMACAuthHeaderProvider.java:23:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 `DefaultHttpClient` isn't used. No network calls.

 > {{{
 >
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/HawkAuthHeaderProvider.java:29:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 > }}}

 `DefaultHttpClient` isn't used. No network calls.

 > {{{
 >
 

Re: [tor-bugs] #26986 [Core Tor/Tor]: Appveyor CI fails on master due to #19506

[Tor Bug Tracker & Wiki]

#26986: Appveyor CI fails on master due to #19506
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, tor-ci, regression,|  Actual Points:
  035-must   |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * reviewer:   => ahf


Comment:

 Please see my branch bug26986 on https://github.com/teor2345/tor.git

 Assigning review to ahf because he is on CI this week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-

Comment (by Hello71):

 Replying to [comment:42 sbs]:
 > > Instead of a single static library, would a target that gives you a
 list of all the static libraries you need be acceptable?
 >
 > Yes, that would be acceptable!
 >
 > > [...] all the libraries you need to link for tor, in the correct
 order,
 >
 > This is especially useful because I was not super happy having to keep
 track of the correct order, especially in the future when switching to new
 releases; but having an authoritative source for the names and order is
 great.
 >
 > Is is correct to say that the reason why different `.a` libraries are
 built in tor, as opposed to a single library, is that you need to apply
 different compiler flags to different portions of the code base, or is
 there another reason?

 As I understand it, it's just an easy way to implement "module-like"
 functionality in autotools, since variable order is a problem (autotools
 doesn't support anything like the CMake "object library" function).

 > > [...] because Cargo builds its libraries as .lib rather than .a.
 >
 > Yeah, using non portable tricks was making me a little nervous because I
 feared something I was most likely not aware of could break.
 >
 > Curiosity: does this imply that rust produces binaries compatible with
 the format of MSVC as opposed to the one of GCC? Does this imply that
 MinGW is not used anymore for Windows, or is MinGW now able to cope with
 the format of MSVC?

 hey, I'm finally qualified to answer a question! Tor still uses mostly
 mingw to compile on Windows. MSVC is supported-ish but AFAIK no core Tor
 devs use it and Tor Browser still uses mingw. to use Rust on Windows, you
 must currently select to download the MSVC or the mingw version (which I
 assume are incompatible). Tor currently uses whatever you have installed,
 which now that I'm thinking about it, someone (hopefully not me) should
 write a configure test to ensure is linkable with the selected C
 toolchain, but it doesn't do 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] #26987 [Core Tor/Tor]: Tor seems to be reading from two different time sources in a macOS VM

[Tor Bug Tracker & Wiki]

#26987: Tor seems to be reading from two different time sources in a macOS VM
-+--
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  macos, tor-time  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * Attachment "nodes.1532996702.zip" added.

 chutney nodes directory

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26987 [Core Tor/Tor]: Tor seems to be reading from two different time sources in a macOS VM

[Tor Bug Tracker & Wiki]

#26987: Tor seems to be reading from two different time sources in a macOS VM
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  macos, tor-time
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I started chutney (and its tors) a few minutes after resuming from sleep,
 but Tor sometimes gets the time wrong by 15 hours. (Which is approximately
 the time the VM last slept.)

 I wonder if we're using the wrong macOS time APIs?
 Or it could be a VM or macOS issue.

 {{{
 FAIL: ipv6-exit-min
 Detail: chutney/tools/warnings.sh /Users/base/chutney/net/nodes.1532996702
 Warning: Couldn't store my own vote! (I told myself, 'Bad valid-after
 time'.) Number: 2
 Warning: Rejecting vote from 127.0.0.1 with valid-after time of 2018-07-31
 00:26:05; we were expecting 2018-07-31 00:25:10 Number: 2
 Warning: Your system clock just jumped 55189 seconds backward; assuming
 established circuits no longer work. Number: 3
 Warning: Your system clock just jumped 55191 seconds forward; assuming
 established circuits no longer work. Number: 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] #19506 [Core Tor/Tor]: Tool to inspect id signing certs

[Tor Bug Tracker & Wiki]

#19506: Tool to inspect id signing certs
-+-
 Reporter:  weasel   |  Owner:  rl1987
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.4-rc
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ed25519, tor-relay, monitor, |  Actual Points:
  tooling, admin-tools, 035-triaged-in-20180711  |
Parent ID:   | Points:  2
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by teor):

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


Comment:

 Oops. Let's deal with it in #26986.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19506 [Core Tor/Tor]: Tool to inspect id signing certs

[Tor Bug Tracker & Wiki]

#19506: Tool to inspect id signing certs
-+-
 Reporter:  weasel   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  ed25519, tor-relay, monitor, |  Actual Points:
  tooling, admin-tools, 035-triaged-in-20180711  |
Parent ID:   | Points:  2
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by teor):

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


Comment:

 Appveyor CI didn't run on this pull request or branch, then the merge to
 master broke on Windows. See #26986.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26986 [Core Tor/Tor]: Appveyor CI fails on master due to #19506

[Tor Bug Tracker & Wiki]

#26986: Appveyor CI fails on master due to #19506
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:  Tor: unspecified
  Tor/Tor|   Keywords:  fast-fix, tor-ci, regression,
 Severity:  Normal   |  035-must
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 For some reason, Appveyor CI didn't run on the pull request for #19506:
 https://github.com/torproject/tor/pull/216

 When #19506 was merged to master, it failed Appveyor with:
 {{{
 ../src/tools/tor-print-ed-signing-cert.c:52:67: error: unknown conversion
 type character 'z' in format [-Werror=format=]
  fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
^
 ../src/tools/tor-print-ed-signing-cert.c:52:21: error: too many arguments
 for format [-Werror=format-extra-args]
  fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
  ^~~
 ../src/tools/tor-print-ed-signing-cert.c:52:67: error: unknown conversion
 type character 'z' in format [-Werror=format=]
  fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
^
 ../src/tools/tor-print-ed-signing-cert.c:52:21: error: too many arguments
 for format [-Werror=format-extra-args]
  fprintf(stderr, "ed25519_cert_parse failed with return value %zd\n",
  ^~~
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-

Comment (by sbs):

 > Instead of a single static library, would a target that gives you a list
 of all the static libraries you need be acceptable?

 Yes, that would be acceptable!

 > [...] all the libraries you need to link for tor, in the correct order,

 This is especially useful because I was not super happy having to keep
 track of the correct order, especially in the future when switching to new
 releases; but having an authoritative source for the names and order is
 great.

 Is is correct to say that the reason why different `.a` libraries are
 built in tor, as opposed to a single library, is that you need to apply
 different compiler flags to different portions of the code base, or is
 there another reason?

 > [...] because Cargo builds its libraries as .lib rather than .a.

 Yeah, using non portable tricks was making me a little nervous because I
 feared something I was most likely not aware of could break.

 Curiosity: does this imply that rust produces binaries compatible with the
 format of MSVC as opposed to the one of GCC? Does this imply that MinGW is
 not used anymore for Windows, or is MinGW now able to cope with the format
 of MSVC?

 Thank you!

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

Re: [tor-bugs] #26951 [Applications/Tor Browser]: Linux tbb execdesktop argument passing is broken

[Tor Bug Tracker & Wiki]

#26951: Linux tbb execdesktop argument passing is broken
+--
 Reporter:  benburrill  |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by benburrill):

 Yes, I can confirm that clicking the icon in a file manager and in the
 Xfce whisker menu works -- execdesktop isn't even involved in that case,
 so there would be no reason why it wouldn't.

 Also, I realized after I posted this that it is a duplicate of #18022 (I
 tried searching earlier but somehow missed it then)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 One question: Instead of a single static library, would a target that
 gives you a list of all the static libraries you need be acceptable?

 Right now, you can get a complete list of all the libraries you need to
 link for tor, in the correct order, by running "make show-libs".  It's
 what we use in a few other places for external things like the clusterfuzz
 fuzzer that need to link "everything in tor".

 That way instead of saying "tor/src/or/libtor_complete.a" in your linking
 command, you'd say "(cd tor && make show-libs)".

 I suggest this instead of a single library because there are issues with
 Windows here, because Cargo builds its libraries as .lib rather than .a.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 Replying to [comment:37 sbs]:
 > Hello! My apologies for a late reply and having neglected this ticket
 for quite some time. I was rightfully prodded by hellais to explain what
 we exactly need and I understand that any way in which this is simpler is
 easier for you guys to maintain. Long story short, what we need is the
 following: a single static library compiled with `-fPIC` and a header. (I
 do understand that having a shared library is probably a nice value
 proposition for people that perhaps wants to link to Tor, but I can also
 feel that it would complicate the build, so, since we do not need it, I
 would not advocate for it.) Thanks! :-)

 This is much easier, and we can probably get it done in 0.3.5.

 I think we can get away with not using libtool here, since although the ar
 tricks described on that link are not universal, the easiest ones ought to
 be something we can hack together.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26947 [Core Tor/Tor]: Add function for reporting the tor version in tor_api.h

[Tor Bug Tracker & Wiki]

#26947: Add function for reporting the tor version in tor_api.h
--+
 Reporter:  hellais   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25510| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 We talked about this, and decided that the right subtlety here is not to
 return the version of tor, but the version and identity of "whatever is
 implementing the tor_api".  (The existence of libtorrunner makes this
 complicated but IMO worthwhile.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22170 [Applications/Tor Browser]: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy safety on Android

[Tor Bug Tracker & Wiki]

#22170: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy 
safety
on Android
-+-
 Reporter:  gk   |  Owner:  sysrqb
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-mobile,|  Actual Points:
  TorBrowserTeam201807   |
Parent ID:  #21863   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 All files where Fennec uses `impl.client`

 {{{
 $ git grep -n ch.boye.httpclientandroidlib.impl.client
 mobile/android/[bs]*
 
mobile/android/base/java/org/mozilla/gecko/telemetry/TelemetryUploadService.java:15:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/background/fxa/FxAccountClient20.java:50:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/background/fxa/oauth/FxAccountAbstractClient.java:30:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/push/autopush/AutopushClient.java:35:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/AbstractBearerTokenAuthHeaderProvider.java:9:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/AuthHeaderProvider.java:11:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java:51:import
 ch.boye.httpclientandroidlib.impl.client.BasicAuthCache;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java:52:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResourceDelegate.java:8:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BasicAuthHeaderProvider.java:12:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/HMACAuthHeaderProvider.java:23:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/HawkAuthHeaderProvider.java:29:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/ResourceDelegate.java:13:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/SyncStorageCollectionRequest.java:20:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/SyncStorageRequest.java:20:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/main/java/org/mozilla/gecko/tokenserver/TokenServerClient.java:37:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/test/java/org/mozilla/android/sync/test/helpers/MockResourceDelegate.java:9:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/test/java/org/mozilla/gecko/sync/net/test/TestHawkAuthHeaderProvider.java:12:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 
mobile/android/services/src/test/java/org/mozilla/gecko/sync/net/test/TestLiveHawkAuth.java:11:import
 ch.boye.httpclientandroidlib.impl.client.DefaultHttpClient;
 }}}

 All files where Fennec uses `conn`

 {{{
 $ git grep -n ch.boye.httpclientandroidlib.conn mobile/android/[bs]*
 mobile/android/base/java/org/mozilla/gecko/util/URIUtils.java:14:import
 ch.boye.httpclientandroidlib.conn.util.InetAddressUtils;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java:44:import
 ch.boye.httpclientandroidlib.conn.ClientConnectionManager;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java:45:import
 ch.boye.httpclientandroidlib.conn.params.ConnRoutePNames;
 
mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java:46:import
 ch.boye.httpclientandroidlib.conn.scheme.PlainSocketFactory;
 

Re: [tor-bugs] #26910 [Core Tor/Tor]: Could tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)

[Tor Bug Tracker & Wiki]

#26910: Could tor drop privileges even earlier? (before trying to access 
anything
on the filesystem beyond its torrc files)
--+--
 Reporter:  nusenu|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  035-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * keywords:   => 035-proposed


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26951 [Applications/Tor Browser]: Linux tbb execdesktop argument passing is broken

[Tor Bug Tracker & Wiki]

#26951: Linux tbb execdesktop argument passing is broken
+--
 Reporter:  benburrill  |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * 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] #26951 [Applications/Tor Browser]: Linux tbb execdesktop argument passing is broken

[Tor Bug Tracker & Wiki]

#26951: Linux tbb execdesktop argument passing is broken
+--
 Reporter:  benburrill  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201807R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Thanks for the patch, testing it on the command line works for me. Did you
 test it with a GUI, like having Tor Browser registered in a way that its
 icon shows up in the launcher? Or while clicking on the icon in a file
 manager? I fear we are breaking something in those cases... More testing
 is needed I guess.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26551 [Applications/Tor Launcher]: Tor Launcher shows up "missing PT" box but when I click on OK everything starts up and works

[Tor Bug Tracker & Wiki]

#26551: Tor Launcher shows up "missing PT" box but when I click on OK everything
starts up and works
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ff60-esr   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * status:  assigned => needs_information


Comment:

 I tested with a clean, new 8.0a9 on a 64bit Linux system and could not
 reproduce the bug with either obfs4 or snowflake chose during first start.
 I wonder whether an update from 8.0a8 is needed to reproduce it (maybe an
 8.0a8 even with one of those PTs configured while doing the 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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  needs_information => accepted
 * owner:  sbs => nickm


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

Re: [tor-bugs] #26456 [Applications/Tor Browser]: HTTP .onion sites inherit previous page's certificate information

[Tor Bug Tracker & Wiki]

#26456: HTTP .onion sites inherit previous page's certificate information
-+-
 Reporter:  pospeselr|  Owner:  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201807R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff60-esr, TorBrowserTeam201807 => ff60-esr,
 TorBrowserTeam201807R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26514 [Applications/Tor Browser]: intermittent updater failures on Win64 (Error 19)

[Tor Bug Tracker & Wiki]

#26514: intermittent updater failures on Win64 (Error 19)
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201807  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:10 gk]:
 > You need to compile with `--disable-accessibility` as there is a bug in
 newer mingw-w64 versions that is not figured out yet if accessibility is
 enabled.

 Thanks! Adding `--disable-accessibility` allowed me to build Tor Browser
 8.0a8 with the newer mingw-w64 toolchain. The result is that this bug
 still occurs. At this point, I think it makes sense to try again to
 reproduce this problem in an ESR60-based Tor Browser, since I cannot think
 of a reason why we would not have the same problem there. When I tested
 before (see comment:6) I may have included extra logging which Kathy and I
 learned later can cause this bug to not occur.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26456 [Applications/Tor Browser]: HTTP .onion sites inherit previous page's certificate information

[Tor Bug Tracker & Wiki]

#26456: HTTP .onion sites inherit previous page's certificate information
+--
 Reporter:  pospeselr   |  Owner:  pospeselr
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201807  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_revision => needs_review
 * cc: mcs, brade, arthuredelstein (added)


Comment:

 Replying to [comment:7 pospeselr]:
 > So (in the original code)the updateStatus flag does 2 things:
 > - first, it's used to determine whether mSSLStatus needs to be updated
 with the new cert info if the incoming info (nsISupports) is an
 nsISSLStatus
 > - second, it's passed on down to UpdateSecurityState where it is OR'd
 with other flags to determine whether a notification needs to go out that
 security info has changed.
 >
 > If the 'STATE_IS_SECURE' flag is set, than the mSSLStatus is cleared out
 later on in UpdateSecurityState.  The changes in the patch force the
 mSSLStatus to get null'd out early since the later check will fail because
 onion domains get the 'STATE_IS_SECURE' flag, even without SSL info.
 >
 > The patch makes it so HTTP onion pages clear out the mSSLStatus based on
 whether 'info' is an nsISSLStatusProvider.  For vanilla HTTP pages,
 mSSLStatus is now cleared out twice: once based on 'info' (as with HTTP
 onion pages) and once again when the security flags change to
 'lis_no_security'.

 Thanks for the explanation.

 > That all said, I'll run this (and the previous patch) through the
 firefox try server and verify we haven't broken anything.

 How did it go?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  accepted => merge_ready


Comment:

 Okay, scheduled for August 15, together with the suggested changes to per-
 graph CSV files (#25383). 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] #22170 [Applications/Tor Browser]: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy safety on Android

[Tor Bug Tracker & Wiki]

#22170: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy 
safety
on Android
-+-
 Reporter:  gk   |  Owner:  sysrqb
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-mobile,|  Actual Points:
  TorBrowserTeam201807   |
Parent ID:  #21863   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: tbb-team (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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  sbs
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-

Comment (by sbs):

 Addition: as far as I can tell, there is no portable way to make a single
 static library out of many static libraries. I remember discussing this
 with `ahf` and concluding that probably using `libtool` was a good
 solution. It is a also a bit of a bummer that what we need `libtool` for
 is to assemble the static library from the many other libraries produced
 by the build system. I think I initially considered making another diff
 that modified the build system to make a single static library, but then I
 started wondering about `rust` integration and then suddenly a `libool`
 rule for assembling a single static library from rust static libraries and
 the many `tor` folders was not that bad. Still I am unhappy of `libtool`
 because it makes the build slower (even with `--disable-shared` on by
 default IIRC it was a bit slower).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  sbs
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 034-included-20180402,|
  034-roadmap-subtask, 035-roadmap-subtask, 035  |
  -triaged-in-20180711   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8
-+-

Comment (by sbs):

 Hello! My apologies for a late reply and having neglected this ticket for
 quite some time. I was rightfully prodded by hellais to explain what we
 exactly need and I understand that any way in which this is simpler is
 easier for you guys to maintain. Long story short, what we need is the
 following: a single static library compiled with `-fPIC` and a header. (I
 do understand that having a shared library is probably a nice value
 proposition for people that perhaps wants to link to Tor, but I can also
 feel that it would complicate the build, so, since we do not need it, I
 would not advocate for it.) 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] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Alright, I just pushed [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-25383-2=f7793c7a309d9c2c86a1429dbebeb399c3db7ec6
 commit f7793c7] with a new page header to
 [https://gitweb.torproject.org/karsten/metrics-web.git/log/?h=task-25383-2
 my task-25383-2 branch]. Please take a look. We can still tweak the text
 there and provide more information. However, if possible, I'd like to
 deploy this page tomorrow and also announce it on tor-dev@, so that people
 have at least two weeks as a heads up before suggested changes become
 effective. 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] #24204 [Core Tor/Tor]: Improve the in-process Tor API: create owning control port

[Tor Bug Tracker & Wiki]

#24204: Improve the in-process Tor API: create owning control port
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Very Low |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 035-roadmap-subtask   |
Parent ID:  #25510   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #16824 [Core Tor/Tor]: Emit a warning message about side channel leaks when using relays as clients

[Tor Bug Tracker & Wiki]

#16824: Emit a warning message about side channel leaks when using relays as
clients
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  mike-can, tor-client, tor-relay, |  Actual Points:
  tor-log, sidechannel, easy, 035-triaged-   |
  in-20180711|
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by dmr):

 * cc: dmr (added)
 * keywords:
 mike-can, tor-client, tor-relay, sidechannel, logging, easy, 035
 -triaged-in-20180711
 =>
 mike-can, tor-client, tor-relay, tor-log, sidechannel, easy, 035
 -triaged-in-20180711


Comment:

 `tor-log` is a relatively new keyword; using instead of `logging`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24204 [Core Tor/Tor]: Improve the in-process Tor API: create owning control port

[Tor Bug Tracker & Wiki]

#24204: Improve the in-process Tor API: create owning control port
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 035-roadmap-subtask   |
Parent ID:  #25510   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by hellais):

 I am now a believe in this solution.

 The main advantages I see for a mobile app developer use-case, is the fact
 that:

 1. You can create out of this an event telling you that the Tor control
 port is ready to receive messages without relying on polling to see if teh
 port is open.

 ex. since the function returns a socket handle, you can just write
 directly to the socket and when you receive a response back you know the
 control port is ready

 2. You can use it to signal tor to shutdown cleanly, by simply closing the
 socket.

 As such this solution crossed out two of the items I listed in
 https://trac.torproject.org/projects/tor/ticket/25510#comment:7, namely:

 - Ability to know when the control port is ready
 - Ability to terminate tor cleanly without using the control port

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22170 [Applications/Tor Browser]: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy safety on Android

[Tor Bug Tracker & Wiki]

#22170: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy 
safety
on Android
-+-
 Reporter:  gk   |  Owner:  sysrqb
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-mobile,|  Actual Points:
  TorBrowserTeam201807   |
Parent ID:  #21863   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 This code is kinda scary. It's highly configurable, so we must be very
 careful that we don't miss something.

 In
 
`mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java`,
 when the connection is instantiated we configure the default proxy on the
 client connection.

 HttpClientAndroidLib is a crazy web of abstractions over HTTP connections.
 It uses connection pools for reusing existing connections, it uses routes
 for retrying connection requests that failed on different interfaces
 and/or using other proxy servers.

 As long as the `PlainSocketFactory` and `SSLSocketFactory` are
 instantiated without setting `nameResolver`, we should not leak the DNS
 lookup.

 The `client` is created as a `DefaultHttpClient` [0]. This is where we
 hard-code the proxy config:
 {{{
 HttpHost defaultProxy = new
 HttpHost(ProxySelector.getProxyHostAddress(),
 ProxySelector.getHttpProxyPort());
 client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY,
 defaultProxy);
 }}}

 `getParams()` returns a `HttpParams` [1] which is an instance of
 `SyncBasicHttpParams` [2]. Then, when `client.execute()` is called [3],
 after some levels of abstraction a `RequestDirector` is created as a
 `DefaultRequestDirector`[4]. Here a `BasicClientConnectionManager` is
 created as the `ClientConnectionManager`. In the
 `RequestDirector.execute()` method, the request's `HttpRoute` is found via
 the `DefaultRoutePlanner`[6] (created when the `Director` was created[7]).
 This is where the default proxy is checked (as it is set above) [8] and
 this information is passed into the `HttpRoute` constructor[9]. This
 configures the `proxyChain` array of proxies used by this route.

 Inside `RequestDirector.execute()`, at the first connection a new
 connection is created by calling `connManager.requestConnection()` in
 `BasicClientConnectionManager`. This then creates a new
 `ClientConnectionOperator` as a `DefaultClientConnectionOperator`[10].
 Then an `OperatedClientConnection` is created by
 `DefaultClientConnectionOperator.createConnection()`. last a
 `ManagedClientConnectionImpl` [11] is created and returned.

 Later in `execute()`, `tryConnect()` is called, where
 `ManagedClientConnectionImpl.open()` is then called. Here,
 `DefaultClientConnectionOperator.open()` connection is called where the
 target is the previously configured proxy [12]. In this method, a `Socket`
 is created by the respective `Scheme` factory for the proxy.

 NOTE: this resolved the proxy address using the system DNS resolver [13].
 This shouldn't leak anything, but we don't need this.


 [0]
 
`mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/client/DefaultHttpClient.java`
 [1]
 `mobile/android/thirdparty/ch/boye/httpclientandroidlib/params/HttpParams.java`
 [2]
 
`mobile/android/thirdparty/ch/boye/httpclientandroidlib/params/SyncBasicHttpParams.java`
 [3] https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java?h
 =tor-browser-60.1.0esr-8.0-1#n315
 [4] https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/client/AbstractHttpClient.java?h
 =tor-browser-60.1.0esr-8.0-1#n805
 [5]
 
`mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/conn/BasicClientConnectionManager.java`
 [6]
 
`mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/conn/DefaultHttpRoutePlanner.java`
 [7] https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/client/AbstractHttpClient.java?h
 =tor-browser-60.1.0esr-8.0-1#n811
 [8] https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/thirdparty/ch/boye/httpclientandroidlib/conn/params/ConnRouteParams.java?h
 =tor-browser-60.1.0esr-8.0-1#n68
 [9] https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/thirdparty/ch/boye/httpclientandroidlib/impl/conn/DefaultHttpRoutePlanner.java?h
 =tor-browser-60.1.0esr-8.0-1#n118
 [10] https://gitweb.torproject.org/tor-
 

Re: [tor-bugs] #25510 [Core Tor/Tor]: Collect feedback on mobile embedding API; resolve issues.

[Tor Bug Tracker & Wiki]

#25510: Collect feedback on mobile embedding API; resolve issues.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, 035-roadmap-master, |  Actual Points:
  034-triage-20180328, 034-included-20180328,|
  035-triaged-in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-must
-+-
Changes (by dmr):

 * cc: dmr (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] #26923 [Obfuscation/Pluggable transport]: Intent to create Pluggable Transport: HTTPS proxy

[Tor Bug Tracker & Wiki]

#26923: Intent to create Pluggable Transport: HTTPS proxy
-+-
 Reporter:  sf   |  Owner:  asn
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  pt httpsproxy|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dmr):

 * cc: dmr (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] #26551 [Applications/Tor Launcher]: Tor Launcher shows up "missing PT" box but when I click on OK everything starts up and works

[Tor Bug Tracker & Wiki]

#26551: Tor Launcher shows up "missing PT" box but when I click on OK everything
starts up and works
---+--
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ff60-esr   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by ProTipGuyFWIWWeLoveARMA):

 My intuition says that this is probably caused by (though not a bug in)
 SelfRando as I can't reproduce it on a ff60-esr Nightly before SelfRando
 came in. Can anyone corroborate 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] #26148 [Applications/Tor Browser]: Update binutils to a version more recent than 2.26.1

[Tor Bug Tracker & Wiki]

#26148: Update binutils to a version more recent than 2.26.1
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201805,   |  Actual Points:
  boklm201807|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 I filled an upstream binutils ticket for this issue:
 https://sourceware.org/bugzilla/show_bug.cgi?id=23466

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26985 [Applications/Tor Launcher]: help button icons missing

[Tor Bug Tracker & Wiki]

#26985: help button icons missing
+--
 Reporter:  mcs |  Owner:  mcs
 Type:  defect  | Status:  assigned
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201807  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 The image from ESR52 is chrome://browser/skin/menuPanel-help.png (in the
 source tree, the path is browser/themes/linux/menuPanel-help.png on Linux
 and similar images exist for Windows and macOS). The image contains
 multiple renderings to cover "on click" and "on hover" states which we use
 in Tor Launcher.

 The replacement image that is in ESR60 is
 chrome://global/skin/icons/help.svg (in the source tree there is just one
 image at toolkit/themes/shared/icons/help.svg). Since this image does not
 have "on click" and "on hover" renderings, we will need to decide what we
 want to do in those cases. In the hamburger menu where Firefox uses this
 new image, the background color of the entire menu row is changed upon
 hover but that is not appropriate in Tor Launcher since we use the help
 icons for standalone buttons.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26985 [Applications/Tor Launcher]: help button icons missing

[Tor Bug Tracker & Wiki]

#26985: help button icons missing
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Launcher   |   Keywords:  ff60-esr,
 Severity:  Normal   |  TorBrowserTeam201807
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When Tor Launcher is running inside an ESR60-based Tor Browser, the bridge
 and proxy help button icons are missing. This is because we reused an
 image that was part of Firefox, and Mozilla removed the image sometime
 between ESR52 and ESR60.

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

[tor-bugs] #26984 [Core Tor/Stem]: Tests should not fail due to a missing .gitignore

[Tor Bug Tracker & Wiki]

#26984: Tests should not fail due to a missing .gitignore
---+--
 Reporter:  irl|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  debian,packaging
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 It is very common that VCS-specific files are thrown away when packaging
 for distributions as distributions may not use the same VCS as you.

 The Debian package does not run any tests when building, and while I'm
 only guessing, this is probably due to the requirement that the original
 `.gitignore` is kept around.

 {{{
 Traceback (most recent call last):
   File "run_tests.py", line 36, in 
 import test
   File "/home/irl/debian/python-stem/test/__init__.py", line 71, in
 
 with open(os.path.join(STEM_BASE, '.gitignore')) as ignore_file:
 FileNotFoundError: [Errno 2] No such file or directory: '/home/irl/debian
 /python-stem/.gitignore'
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26960 [Applications/Tor Browser]: implement new about:tor start page

[Tor Bug Tracker & Wiki]

#26960: implement new about:tor start page
--+--
 Reporter:  mcs   |  Owner:  mcs
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201807R |  Actual Points:
Parent ID:  #25695| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Looks good! One additional thing I am wondering is whether we should make
 our "Questions? Check our Tor Browser Manual »" part larger/show it more
 prominently. After all, it provides useful information to actually stay
 secure with Tor Browser and is not just about questions that are showing
 up during usage.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26956 [Core Tor/Tor]: Privcount blinding and encryption: deny warnings

[Tor Bug Tracker & Wiki]

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

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


Comment:

 merged!

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 merged as part of #26956

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:  irl  |Sponsor:
-+--
Changes (by irl):

 * reviewer:   => irl


Comment:

 Will look at this tomorrow UTC morning unless anything more urgent comes
 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] #26983 [Metrics/Relay Search]: Add support for 6 months graphs in the plotting functions

[Tor Bug Tracker & Wiki]

#26983: Add support for 6 months graphs in the plotting functions
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25175| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 Will look at this this week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26983 [Metrics/Relay Search]: Add support for 6 months graphs in the plotting functions

[Tor Bug Tracker & Wiki]

#26983: Add support for 6 months graphs in the plotting functions
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #25175
   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] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+
Changes (by karsten):

 * status:  merge_ready => needs_revision


Comment:

 Replying to [comment:31 irl]:
 > Replying to [comment:29 karsten]:
 > >  - Does it make sense to specify our per-graph CSV files there, rather
 than in the CSV file header?
 >
 > I think yes. The CSV files are machine-readable first, human-readable is
 not the priority for these files.

 Agreed.

 > >  - Is the format with two subsections Parameters and Columns okay? Is
 something missing?
 >
 > I think this is OK. Perhaps we need an example GET request to start this
 document off. We're really documenting an HTTP API, not just the
 individual files.

 Good point. I'll add something.

 > Perhaps we need to say that either we do, or we don't, guarantee the
 ordering of the columns. If we add/remove columns later would we change
 the ordering? Especially with removal, would we pad with nulls or
 something like that? (Anything by transport is particularly affected by
 this).

 Good questions. I think I'd rather not want to guarantee the ordering of
 columns and instead require users to refer to columns by name and not
 index. In particular the null padding sounds like it would implicitly stop
 us from removing unnecessary changes, which seems bad. So, yes, let's
 state this at the start of the page. I'll add something.

 > >  - Are specifications roughly correct/plausible?
 >
 > Nothing is jumping out at me as obviously wrong. I haven't considered
 every one thoroughly yet though.

 Okay.

 > >  - Do the suggestions make sense? The rule of thumb for deciding which
 columns we need was: "it should require a code change to change columns,
 and neither the user should be able to control which columns exist by
 their choice of parameters, nor should the available data have any
 influence on that."
 >
 > The suggestions do make sense, and would solve the immediate column
 ordering issue (although we should still make a statement as to what we
 would expect to happen in the future). I commented on #26950 separately.

 Perfect!

 > > Regarding timing, how about we deploy this page still in July, make
 suggested changes by August 15, take out pre-aggregated stats files by
 September 15, and handle any questions coming out of that in the two weeks
 before the Mexico City meeting?
 >
 > Sounds good to me!
 >
 > merge_ready for this page.

 Setting to needs_revision for the page header part. Will move it back to
 needs_review for whenever I have something.

 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] #25177 [Metrics/Onionoo]: Remove redundant clients graphs

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [comment:6 irl]:
 > LGTM.

 Great!

 > Relay Search, at least, is not expecting fixed strings and does parse
 the keys. No objection to including this in the major protocol bump to
 give users more notice of the change.

 Alright!

 > merge_ready for Onionoo change, but do you also have a spec diff? (I
 guess it is trivial)

 I don't have a spec diff yet, but I'll be sure to put out one for review
 that covers all changes for the next minor and the next major version. And
 yes, the diff for this change in particular is likely going to be trivial.

 Leaving this in merge_ready for merging it as soon as we're putting out
 the next major version. 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] #26982 [Applications/Tor Browser]: TBA - httpclientandroidlib leaks information about Android version

[Tor Bug Tracker & Wiki]

#26982: TBA - httpclientandroidlib leaks information about Android version
-+-
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile,
 Severity:  Normal   |  TorBrowserTeam201807
Actual Points:   |  Parent ID:  #25703
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 While reviewing #22170, I noticed Fennec decides which TLS ciphers it
 supports[0] based on a lower-bound of the Android SDK version, and it
 chooses a TLS cipher within that list. This is another example of why we
 should use Necko (via GeckoView) instead of the Android SDK for
 networking.

 This is used by the Java networking in the Sync code[1].

 In the short term, we can always return the `else` clause:
 {{{
 } else {
   DEFAULT_CIPHER_SUITES = new String[]
   {
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",// 11+
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",  // 11+
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",// 11+

// For Sync 1.1.
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA",  // 9+
"TLS_RSA_WITH_AES_128_CBC_SHA",  // 9+
   };
 }
 }}}

 But that sure is sad. We need ciphers for 16+.

 [0] https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/services/src/main/java/org/mozilla/gecko/background/common/GlobalConstants.java?h
 =tor-browser-60.1.0esr-8.0-1#n47
 [1] https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/BaseResource.java?h
 =tor-browser-60.1.0esr-8.0-1#n261

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26832 [Applications/Tor Check]: Allow use of https://check.torproject.org/api/ip by content

[Tor Bug Tracker & Wiki]

#26832: Allow use of https://check.torproject.org/api/ip by content
+--
 Reporter:  arthuredelstein |  Owner:  arlolra
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

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


Comment:

 I was persuaded to re-open the ticket. :) It would be nice to have this
 change, though I'm not sure of the security downsides. Maybe someone in
 the know has a suggestion about how to do this safely.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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_information
 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:  merge_ready => needs_information


Comment:

 Great, thanks for looking! Merged the logging patch to master. Leaving
 this ticket open for actually removing the "fingerprint" parameter if we
 still like the idea after seeing the statistics.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26964 [Metrics/Relay Search]: support custom column selection for search result overview

[Tor Bug Tracker & Wiki]

#26964: support custom column selection for search result overview
--+--
 Reporter:  nusenu|  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * priority:  Medium => Low


Comment:

 I don't know about the datatables API for this, it may be easy it may be
 hard.

 Customising via the URL is definitely a hard problem for the same reason
 that #25673 is hard. We just don't have a way of easily adding key value
 pairs to the URL.

 Setting to low priority for now.

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

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

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


Comment:

 Will look at this this week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:
-+--

Comment (by irl):

 Replying to [comment:4 karsten]:
 > Keeping the data in the two other per-graph CSV files
 ([https://metrics.torproject.org/hidserv-dir-onions-seen.html this] and
 [https://metrics.torproject.org/hidserv-rend-relayed-cells.html that])
 takes zero additional effort. We need to compute the numbers anyway. I'd
 say if we take out the fractions graph ([https://metrics.torproject.org
 /hidserv-frac-reporting.html this one]) we should at the same time add the
 data to the other two graphs.

 I like 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] #25177 [Metrics/Onionoo]: Remove redundant clients graphs

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 LGTM.

 Relay Search, at least, is not expecting fixed strings and does parse the
 keys. No objection to including this in the major protocol bump to give
 users more notice of the change.

 merge_ready for Onionoo change, but do you also have a spec diff? (I guess
 it is trivial)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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 micah):

 Replying to [comment:19 irl]:
 >
 > When I followed up on the ITP with an extended description for the
 binary package, I realised that this is not only useful to directory
 authorities but may also be useful to those running test networks for
 research. I think on that basis this package would be suitable for
 inclusion in Debian as it's not limited to only the dirauths in its
 usefulness.

 If sbws is put into Debian, its likely that directory authorities are
 going to end up installing a newer version of the package from the deb.tpo
 package repositories. This is what we do now for core tor because the
 versions available in stable repositories are often too out of date for
 what the network requires. The ability to have a more rapid release cycle
 has been cited as a reason to have things on deb.tpo.

 If the above are all true, then putting sbws into Debian itself will only
 target those people who may want to use sbws for research. I'm uncertain
 if a version of sbws that is in the stable repository for several years
 will be useful for researchers, especially if there is an idea that there
 might be a 'rapid release cycle'. I'd think that researchers would be
 interested in the latest version of the code, and not a version that is
 'stable' (read: several years old). They can get that via the git
 repository, or via deb.tpo.

 All of the above makes me think that the best way forward for sbws, at
 least for the near term, is to get it packaged first for deb.tpo, and then
 evaluate after that is done and has been there for a while if it makes
 sense to put it into Debian itself. Because it will already be a package,
 the hardest part will already be done.

 Also, if there are library dependencies that aren't in Debian, those
 should be updated/packaged and put into Debian proper!

 Regarding the name, I think the idea of putting a "tor-" prefix on the
 package name doesn't make too much sense to me, I have not been convinced
 that this is necessary, or even desirable. Especially when the short/long
 description can be made to make it obvious what this is for.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:  merge_ready
 Priority:  Medium   |  Milestone:  Onionoo 1.16.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26871 [Core Tor/Tor]: prop289: randomize the unused part of relay payloads

[Tor Bug Tracker & Wiki]

#26871: prop289: randomize the unused part of relay payloads
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v  |
Parent ID:  #26288   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV
-+-

Comment (by nickm):

 I've squashed and merged the spec branch.

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

Re: [tor-bugs] #26228 [Core Tor/Tor]: Clarify/determine specification for padding bytes, (formerly also PADDING cell)

[Tor Bug Tracker & Wiki]

#26228: Clarify/determine specification for padding bytes, (formerly also 
PADDING
cell)
-+-
 Reporter:  dmr  |  Owner:  dmr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, prop295-assigned-  |  Actual Points:
  sponsor-v  |
Parent ID:  #26869   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by nickm):

 I've squashed and merged the spec branch; please close this ticket if
 there is no more to do here.

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

Re: [tor-bugs] #26870 [Core Tor/Tor]: Spec: clarify inconsistency for [V]PADDING/DROP cell content vs. padding bytes

[Tor Bug Tracker & Wiki]

#26870: Spec: clarify inconsistency for [V]PADDING/DROP cell content vs. padding
bytes
-+-
 Reporter:  dmr  |  Owner:  dmr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, prop295-assigned-  |  Actual Points:
  sponsor-v  |
Parent ID:  #26869   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by nickm):

 I've squashed and merged the spec branch; please close this ticket if
 there is no more to do here.

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

[tor-bugs] #26981 [Applications/Quality Assurance and Testing]: Update marionette_driver used in tbb-testsuite for esr60

[Tor Bug Tracker & Wiki]

#26981: Update marionette_driver used in tbb-testsuite for esr60
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  assigned
 Priority:  Very High|  Milestone:
Component:   |Version:
  Applications/Quality Assurance |
  and Testing|   Keywords:  TorBrowserTeam201807,
 Severity:  Normal   |  boklm201807
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In order to use our tests based on marionette with Tor Browser 8.0, we
 need to update the version of marionette_driver we use in the testsuite.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:29 karsten]:
 >  - Does it make sense to specify our per-graph CSV files there, rather
 than in the CSV file header?

 I think yes. The CSV files are machine-readable first, human-readable is
 not the priority for these files.

 >  - Is the format with two subsections Parameters and Columns okay? Is
 something missing?

 I think this is OK. Perhaps we need an example GET request to start this
 document off. We're really documenting an HTTP API, not just the
 individual files. Perhaps we need to say that either we do, or we don't,
 guarantee the ordering of the columns. If we add/remove columns later
 would we change the ordering? Especially with removal, would we pad with
 nulls or something like that? (Anything by transport is particularly
 affected by this).

 >  - Are specifications roughly correct/plausible?

 Nothing is jumping out at me as obviously wrong. I haven't considered
 every one thoroughly yet though.

 >  - Do the suggestions make sense? The rule of thumb for deciding which
 columns we need was: "it should require a code change to change columns,
 and neither the user should be able to control which columns exist by
 their choice of parameters, nor should the available data have any
 influence on that."

 The suggestions do make sense, and would solve the immediate column
 ordering issue (although we should still make a statement as to what we
 would expect to happen in the future). I commented on #26950 separately.

 > Regarding timing, how about we deploy this page still in July, make
 suggested changes by August 15, take out pre-aggregated stats files by
 September 15, and handle any questions coming out of that in the two weeks
 before the Mexico City meeting?

 Sounds good to me!

 merge_ready for this page.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26956 [Core Tor/Tor]: Privcount blinding and encryption: deny warnings

[Tor Bug Tracker & Wiki]

#26956: Privcount blinding and encryption: deny warnings
-+-
 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:  nickm|Sponsor:
-+-
Changes (by asn):

 * reviewer:   => nickm


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

Re: [tor-bugs] #26952 [Core Tor/Tor]: Try enabling ccache on Travis

[Tor Bug Tracker & Wiki]

#26952: Try enabling ccache on Travis
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #24629| Points:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => ahf


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26932 [Core Tor/Tor]: Soft assert in HS3 with vanguards ([warn] Invalid signature for service descriptor signing key: expired)

[Tor Bug Tracker & Wiki]

#26932: Soft assert in HS3 with vanguards ([warn] Invalid signature for service
descriptor signing key: expired)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs possible-regression bug easy  |  Actual Points:
  034-backport 033-backport-maybe 032-backport-  |
  maybe  |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => 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] #26946 [Core Tor/Tor]: Privcount blinding and encryption: warning fixes

[Tor Bug Tracker & Wiki]

#26946: Privcount blinding and encryption: warning fixes
-+-
 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:  nickm|Sponsor:
-+-
Changes (by asn):

 * reviewer:   => nickm


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

Re: [tor-bugs] #26885 [Core Tor/Tor]: tor-spec: Generalise "exit" to "end"

[Tor Bug Tracker & Wiki]

#26885: tor-spec: Generalise "exit" to "end"
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, fast-fix, prop295  |  Actual Points:
  -assigned-sponsor-v|
Parent ID:  #26869   | Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by asn):

 * reviewer:   => asn


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26869 [Core Tor/Tor]: tor-spec: Fix minor errors

[Tor Bug Tracker & Wiki]

#26869: tor-spec: Fix minor errors
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  parent-task, tor-spec, fast-fix, |  Actual Points:
  prop295-assigned-sponsor-v |
Parent ID:  #26886   | Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by asn):

 * reviewer:   => asn


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26851 [Core Tor/Tor]: doc: writing bandwidth files atomically

[Tor Bug Tracker & Wiki]

#26851: doc: writing bandwidth files atomically
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  parent-task   |  Actual Points:
Parent ID:  #26797| Points:
 Reviewer:  mikeperry |Sponsor:
--+--
Changes (by asn):

 * reviewer:   => mikeperry


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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_revision
 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:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Very sorry, but I can't find the branch `bug26876_033`. Is it one of the
 ones that got lost when you recreated your github repository?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  not-just-linux, tor-ci, teor-was-|  Actual Points:
  assigned, 034-triage-20180328, |
  034-removed-20180328, 034-backport,|
  035-removed-20180711, fast-fix |
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => catalyst


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26980 [Core Tor/Tor]: HSv3 descriptors rejected because of bad SRV start time computation

[Tor Bug Tracker & Wiki]

#26980: HSv3 descriptors rejected because of bad SRV start time computation
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|
 Severity:  Normal   |   Keywords:  035-must regression tor-hs hsv3
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When we introduced #25552, we started OPE encrypting the time diff since
 the start of the SRV run. We also have some logic on which SRV period we
 should use to calculate the time diff:
 {{{
   if (is_current) {
 srv_start = sr_state_get_start_time_of_previous_protocol_run();
   } else {
 srv_start = sr_state_get_start_time_of_current_protocol_run();
   }
 }}}

 There is a bug here, because when we cross from the 23:00 consensus to the
 00:00 consensus (or the 01:00 one), the start of the SRV protocol changes
 and screws up the revision counter monotonicity.

 This causes one descriptor batch upload to fail.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, certs,|  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711,   |
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by asn):

 I'm OK with not backporting this to 032. 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] #26816 [Core Tor/Tor]: Link NSS into Tor, while still using OpenSSL

[Tor Bug Tracker & Wiki]

#26816: Link NSS into Tor, while still using OpenSSL
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-subticket, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => 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] #26817 [Core Tor/Tor]: Use NSS for DH

[Tor Bug Tracker & Wiki]

#26817: Use NSS for DH
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-subticket, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  needs_revision => 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] #26815 [Core Tor/Tor]: Use NSS for our symmetric crypto, digests, and PRNG.

[Tor Bug Tracker & Wiki]

#26815: Use NSS for our symmetric crypto, digests, and PRNG.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-subticket, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Ah, pfew. Looks like I just missed one. I've made the fix to this branch.
 (I'm not planning to rebase later branches till this one is merged,
 though.)

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

Re: [tor-bugs] #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:
-+--

Comment (by karsten):

 Keeping the data in the two other per-graph CSV files
 ([https://metrics.torproject.org/hidserv-dir-onions-seen.html this] and
 [https://metrics.torproject.org/hidserv-rend-relayed-cells.html that])
 takes zero additional effort. We need to compute the numbers anyway. I'd
 say if we take out the fractions graph ([https://metrics.torproject.org
 /hidserv-frac-reporting.html this one]) we should at the same time add the
 data to the other two graphs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:
-+--

Comment (by irl):

 How much maintenance effort is it to keep the data in the CSV file? If we
 end up keeping the bulk of the code we could remove around, then I think
 we can just drop it. If it still allows us to remove the bulk of the code
 then I would prefer to keep a little effort to keep the frac there in the
 CSV. It could be the difference between us being very confused or very
 quickly being able to understand an event.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26890 [Core Tor/Tor]: Redefine coverity version of the BUG macro

[Tor Bug Tracker & Wiki]

#26890: Redefine coverity version of the BUG macro
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  035-must fast-fix ci coverity  |  Actual Points:
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 fixed and merged!

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

Re: [tor-bugs] #26447 [Core Tor/Tor]: Add check-includes to check-local?

[Tor Bug Tracker & Wiki]

#26447: Add check-includes to check-local?
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, ci, modularity, fast-fix, 035  |  Actual Points:
  -triaged-in-20180711   |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I've made the straightforward fix; better 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] #26627 [Core Tor/Tor]: HSv3 throws many "Tried connecting to router at [IP:port], but RSA identity key was not as expected"

[Tor Bug Tracker & Wiki]

#26627: HSv3 throws many "Tried connecting to router at [IP:port], but RSA 
identity
key was not as expected"
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, certs,|  Actual Points:
  handshake, ed25519, 035-roadmap-proposed,  |
  035-must, fast-fix, 035-triaged-in-20180711,   |
  032-backport, 033-backport, 034-backport   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 I've merged the 0.3.3 branches, and forward.  Let's think a little more
 about whether we want to backport this to 0.3.2, though?  It's only a
 warning, and the extra dependent backports seem a little tricky 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