[tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:  core-tor-wants, ipv6
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We'd like to track relay support for IPv6 in two graphs:
 * relays that have a reachable IPv6 ORPort address in the consensus (this
 is what clients will eventually use to check if a relay supports IPv6, see
 #21637 and #20916)
 * relays that have any IPv6 ports in their exit policy summary in their
 microdescriptor (this is what most clients use to check if an exit
 supports IPv6)

 This will help us answer questions like:

 "How many relays support IPv6?"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23760 [Core Tor/Tor]: Use node_get_curve25519_key() in extend_info_from_node()

[Tor Bug Tracker & Wiki]

#23760: Use node_get_curve25519_key() in extend_info_from_node()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  prop224, tor-hs, single-onion,
 Severity:  Normal   |  ipv6, refactor
Actual Points:   |  Parent ID:  #23577
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In #23577, we are going to implement a node_get_curve25519_key() function.
 We can use this in extend_info_from_node() if we want to.

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

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

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:6 neel]:
 > I am working on a new patch, but I have two questions:
 >
 > 1. For the IPv6 check, I am making use of the function
 {{{link_specifier_set_un_ipv6_addr()}}}, and it has a parameter {{{size_t
 idx}}}. What is the {{{idx}}} parameter and what is it used for?

 I'd suggest you copy the IPv6 code out of hs_desc_lspec_to_trunnel().
 We'll fix up the duplicate code in #23759.

 > 2. I am introducing two new functions:
 >   a. {{{ curve25519_pubkey_eq()}}} in
 {{{src/common/crypto_curve25519.c}}} and
 {{{src/common/crypto_curve25519.h}}}

 I don't think you need to implement this function.

 >   b. {{{ node_get_curve25519_id()}}} in {{{src/or/nodelist.c}}} and
 {{{src/or/nodelist.h}}}

 If I'm guessing correctly, you're writing node_get_curve25519_id() by
 copying and modifying node_get_ed25519_id().

 But the curve25519 key is an encryption key, not an authentication id.

 And it's much easier to find in a node:
 1. If there's an ri, use the curve25519 key from it
 2. If there's an md, use the curve25519 key from it
 3. Otherwise, the entire function should fail and return NULL

 See the last few lines of extend_info_from_node() for an example, or copy
 and modify node_has_curve25519_onion_key().

 >  Do I need to implement a regression test for these two functions?

 node_get_curve25519_key() would be useful, and we might want to refactor
 other code to use it. I'll open a child ticket for this task.

 > I hope you can respond in a timely manner.

 I'm on leave right now, and then there's a meeting next week, so it might
 take some time for me to reply.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  prop224, tor-hs, single-onion,
 Severity:  Normal   |  ipv6, refactor
Actual Points:   |  Parent ID:  #23493
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 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.

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

Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
--+
 Reporter:  ewong |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  code-style|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Thanks for your work on this.

 There's one last thing you need to fix:
 1. Put all the changes to check-spaces.pl in one commit. In the latest
 branch, the script is changed in the first and third commits.

 Once that's done, I'll send this to the release manager and see if they
 are happy with the manual mass change.
 We can use diff's ignore whitespace option to check that only whitespace
 was modified.
 But we'll still need to manually confirm that none of the whitespace was
 significant.

 Then, after final review, we need to:
 2. Merge this patch to master, and fix any spacing issues it identifies in
 new code

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

Re: [tor-bugs] #22788 [Applications/Tor Browser]: PDF.js overloads CPU when opening large PDFs on higher security slider levels (was: Tor Browser rendering hangs when downloading large PDFs on higher

[Tor Bug Tracker & Wiki]

#22788: PDF.js overloads CPU when opening large PDFs on higher security slider
levels
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > I had to restart the browser.
 No, you hadn't. It's not a hang. You can wait until your tasks complete :)
 Enjoy the JIT-less world!

 As mentioned above, it'll be replaced in ESR59 because of many issues,
 including
 {{{
 Warning: AcroForm/XFA is not supported  viewer.js:7221
 Warning: Unimplemented widget field type "Btn", falling back to base field
 type. pdf.worker.js:3830
 }}}

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

Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
--+
 Reporter:  ewong |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  code-style|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ewong):

 * 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] #18660 [Core Tor/Stem]: OSX's man command lacks '--encoding' argument

[Tor Bug Tracker & Wiki]

#18660: OSX's man command lacks '--encoding' argument
---+--
 Reporter:  Sebastian  |  Owner:  atagar
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  utils  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by ewong):

 * status:  reopened => 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] #23758 [Core Tor/Tor]: test config/include_no_permission fails on gitlab.com CI because Docker?

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails on gitlab.com CI because Docker?
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 Apparently the Docker image used by the gitlab.com shared CI runners is
 privileged, so the whole job runs as root.   That would explain why
 `opendir()` succeeded on an unreadable directory.  Maybe that test should
 get skipped if it's running as root.

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

Re: [tor-bugs] #18660 [Core Tor/Stem]: OSX's man command lacks '--encoding' argument

[Tor Bug Tracker & Wiki]

#18660: OSX's man command lacks '--encoding' argument
---+--
 Reporter:  Sebastian  |  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  utils  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by ewong):

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


Comment:

 the test_from_man_when_manual_is_unavailable() test needs to also include
 the patch() line for HAS_ENCODING_ARG.  otherwise, it'll still run
 and since the resulting command = 'man -P cat tor' (on bsd, mac and
 slackware),
 won't be equal to 'man --encoding=ascii -P cat tor' ..   it'll fail.

 https://github.com/ewongbb/stem/tree/fix_test_from_man_unavailable

 this should fix it.

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

Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
--+
 Reporter:  ewong |  Owner:  (none)
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:  code-style|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ewong):

 This is my attempt at a 'mass change'
 https://github.com/ewongbb/tor/tree/chkspace_f

 I had attempted to do a mass change with a script but the amount of time
 trying to
 figure out the code which should be changed compared to those that
 shouldn't
 would've been better used on reading and looking for the general instances
 that apply.  So I apologize as this 'mass change' was pretty much a manual
 process.


 Do note I took a few liberties at the following:

 1) changed indent where I think would be proper (though I probably missed
 quite
a few)
 2) reformatted some lines to make it less 'Wide'

 As such some caveats:
 a) haven't touched C code(and even then, I was just a beginner)
 b) I'm not familiar with the tor code and didn't want to do too much
 damage,
particularly with some whitespace which I think should be there but
 didn't
change.  i.e.   if conditions with all the conditions whitespaceless..
  if (i=0;i<10;i++) {... }   [no, this isn't from the code.. just
 an example]

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

Re: [tor-bugs] #23758 [Core Tor/Tor]: test config/include_no_permission fails on gitlab.com CI because Docker?

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails on gitlab.com CI because Docker?
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 To get that amount of detail, I needed to patch `.gitlab-ci.yml` to also
 run `cat test-suite.log` like `.travis.yml` already does.  (See also
 #23757.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23758 [Core Tor/Tor]: test config/include_no_permission fails on gitlab.com CI because Docker?

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails on gitlab.com CI because Docker?
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci tor-tests
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I managed to get the gitlab.com CI running using the `.gitlab-ci.yml` on
 master.  (There are other issues with that CI configuration; see #23755
 and #23756.)  It fails with
 {{{
 config/include_no_permission:
   FAIL src/test/test_config.c:4975:
 assert(config_get_lines_include(torrc_contents, , 0,_used)
 OP_EQ -1): 0 vs -1
   [include_no_permission FAILED]
 }}}

 As far as I can tell, this can only happen if `opendir()` can succeed on a
 mode `0100` directory.  Maybe this strange thing can happen in the Docker
 environment that runs gitlab.com CI jobs?  I don't know enough about
 Docker to say how plausible that explanation is.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23757 [Core Tor/Tor]: tor's .gitlab-ci.yml doesn't have the same behaviour as our .travis.yml

[Tor Bug Tracker & Wiki]

#23757: tor's .gitlab-ci.yml doesn't have the same behaviour as our .travis.yml
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal|   Keywords:  tor-ci
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 When new contributors come to us saying, "Hi, I made a patch, but the CI
 seems to be failing" it seems like a bad starting place to respond with
 "Which CI is failing?"

 In #22891, it seemed like we were in agreement to have both our Gitlab CI
 and Travis CI do (as much as possible) the same things.

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

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

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 I am working on a new patch, but I have two questions:

 1. For the IPv6 check, I am making use of the function
 {{{link_specifier_set_un_ipv6_addr()}}}, and it has a parameter {{{size_t
 idx}}}. What is the {{{idx}}} parameter and what is it used for?
 2. I am introducing two new functions:
   a. {{{ curve25519_pubkey_eq()}}} in {{{src/common/crypto_curve25519.c}}}
 and {{{src/common/crypto_curve25519.h}}}
   b. {{{ node_get_curve25519_id()}}} in {{{src/or/nodelist.c}}} and
 {{{src/or/nodelist.h}}}
  Do I need to implement a regression test for these two functions?

 I hope you can respond in a timely manner.

 Best,

 Neel

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

Re: [tor-bugs] #23756 [Core Tor/Tor]: tor's .gitlab-ci.yml is doing mirroring? why?

[Tor Bug Tracker & Wiki]

#23756: tor's .gitlab-ci.yml is doing mirroring? why?
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by isis:

Old description:

> Currently in master we have the following stanza in our .gitlab-ci.yml
> (from #22891):
>
> {{{
> update:
>   script:
> - "apt-get install -y --fix-missing git openssh-client"
>
> # Run ssh-agent (inside the build environment)
> - eval $(ssh-agent -s)
>
> # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent
> store
> - ssh-add <("$DEPLOY_KEY")
>
> # For Docker builds disable host key checking. Be aware that by
> adding that
> # you are suspectible to man-in-the-middle attacks.
> # WARNING: Use this only with the Docker executor, if you use it with
> shell
> # you will overwrite your user's SSH config.
> - mkdir -p ~/.ssh
> - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking
> no\n\n" > ~/.ssh/config'
> # In order to properly check the server's host key, assuming you
> created the
> # SSH_SERVER_HOSTKEYS variable previously, uncomment the following
> two lines
> # instead.
> - mkdir -p ~/.ssh
> - '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" >
> ~/.ssh/known_hosts'
> - echo "merging from torgit"
> - git config --global user.email "labad...@oniongit.eu"
> - git config --global user.name "gitadmin"
> - "mkdir tor"
> - "cd tor"
> - git clone --bare https://git.torproject.org/tor.git
> - git push --mirror g...@oniongit.eu:network/tor.git
> }}}
>
> Why are we doing this? Can we put a cronjob on the oniongit.eu server
> instead? It's pretty weird and frankly unexpected that my personal fork
> of tor at https://gitlab.com/isis/tor is cloning the official tor repo
> and then trying to mirror it to oniongit.eu. It also has a bunch of other
> problems:
>
> * The `ssh-add` line [https://gitlab.com/isis/tor/-/jobs/34990901 is
> broken, causing CI to fail because it sits there forever waiting for a
> passphrase].
>
>   I was originally going to patch the `ssh-add` line to instead be `[[ -n
> "${DEPLOY_KEY}" -a -r "$DEPLOY_KEY" ]] && ssh-add "$DEPLOY_KEY" <<<""`
> but if I fix that, then all the rest of this script would run, so I'm
> rather glad it's failing on a more innocuous command.
>
> * Even if the `ssh-add` line weren't broken, this whole thing fails
> unless it's being run from a fork on oniongit.eu.
> * Why is it disabling SSH hostkey checking?!
> * Why is it making the `~/.ssh` directory twice?
> * Why is it assuming that environment variables are set? e.g. `$FOO`
> versus `${FOO}` or better `test -n ${FOO}`
> * Why is it unconditionally setting (global!) git config options? (I
> assume to disable the warning that git spits out when you don't have
> `$GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL}` set, but why would a CI config set
> them globally instead of just setting the correct environment variables?)
> * Why are the mirror URLs hardcoded?
> * Why is the git username and email hardcoded?
> * Why is any of this even running when I push to
> https://gitlab.com/isis/tor?
> * Why is it unconditionally starting an ssh-agent?
>

> I'm sorry if this is all necessary and I'm just not understanding the
> setup, but it's all just extremely unexpected behaviour from what is
> supposed to be a CI config file. Further, it's not even doing the same
> testing as our .travis.yml, but I'll make another ticket for that issue.

New description:

 Currently in master we have the following stanza in our .gitlab-ci.yml
 (from #22891):

 {{{
 update:
   script:
 - "apt-get install -y --fix-missing git openssh-client"

 # Run ssh-agent (inside the build environment)
 - eval $(ssh-agent -s)

 # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent
 store
 - ssh-add <("$DEPLOY_KEY")

 # For Docker builds disable host key checking. Be aware that by adding
 that
 # you are suspectible to man-in-the-middle attacks.
 # WARNING: Use this only with the Docker executor, if you use it with
 shell
 # you will overwrite your user's SSH config.
 - mkdir -p ~/.ssh
 - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking
 no\n\n" > ~/.ssh/config'
 # In order to properly check the server's host key, assuming you
 created the
 # SSH_SERVER_HOSTKEYS variable previously, uncomment the following two
 lines
 # instead.
 - mkdir -p ~/.ssh
 - '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" >
 ~/.ssh/known_hosts'
 - 

[tor-bugs] #23756 [Core Tor/Tor]: tor's .gitlab-ci.yml is doing mirroring? why?

[Tor Bug Tracker & Wiki]

#23756: tor's .gitlab-ci.yml is doing mirroring? why?
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal|   Keywords:  tor-ci
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Currently in master we have the following stanza in our .gitlab-ci.yml
 (from #22891):

 {{{
 update:
   script:
 - "apt-get install -y --fix-missing git openssh-client"

 # Run ssh-agent (inside the build environment)
 - eval $(ssh-agent -s)

 # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent
 store
 - ssh-add <("$DEPLOY_KEY")

 # For Docker builds disable host key checking. Be aware that by adding
 that
 # you are suspectible to man-in-the-middle attacks.
 # WARNING: Use this only with the Docker executor, if you use it with
 shell
 # you will overwrite your user's SSH config.
 - mkdir -p ~/.ssh
 - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking
 no\n\n" > ~/.ssh/config'
 # In order to properly check the server's host key, assuming you
 created the
 # SSH_SERVER_HOSTKEYS variable previously, uncomment the following two
 lines
 # instead.
 - mkdir -p ~/.ssh
 - '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" >
 ~/.ssh/known_hosts'
 - echo "merging from torgit"
 - git config --global user.email "labad...@oniongit.eu"
 - git config --global user.name "gitadmin"
 - "mkdir tor"
 - "cd tor"
 - git clone --bare https://git.torproject.org/tor.git
 - git push --mirror g...@oniongit.eu:network/tor.git
 }}}

 Why are we doing this? Can we put a cronjob on the oniongit.eu server
 instead? It's pretty weird and frankly unexpected that my personal fork of
 tor at https://gitlab.com/isis/tor is cloning the official tor repo and
 then trying to mirror it to oniongit.eu. It also has a bunch of other
 problems:

 * The `ssh-add` line [https://gitlab.com/isis/tor/-/jobs/34990901 is
 broken, causing CI to fail because it sits there forever waiting for a
 passphrase].

   I was originally going to patch the `ssh-add` line to instead be `[[ -n
 "${DEPLOY_KEY}" -a -r "$DEPLOY_KEY" ]] && ssh-add "$DEPLOY_KEY" <<<""` but
 if I fix that, then all the rest of this script would run, so I'm rather
 glad it's failing on a more innocuous command.

 * Even if the `ssh-add` line weren't broken, this whole thing fails unless
 it's being run from a fork on oniongit.eu.
 * Why is it disabling SSH hostkey checking?!
 * Why is it making the `~/.ssh` directory twice?
 * Why is it assuming that environment variables are set? e.g. `$FOO`
 versus `${FOO}` or better `test -n ${FOO}`
 * Why is it unconditionally setting (global!) git config options? (I
 assume to disable the warning that git spits out when you don't have
 `$GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL}` set, but why would a CI config set
 them globally instead of just setting the correct environment variables?)
 * Why are the mirror URLs hardcoded?
 * Why is the git username and email hardcoded?
 * Why is any of this even running when I push to
 https://gitlab.com/isis/tor?
 * Why is it unconditionally starting an ssh-agent?


 I'm sorry if this is all necessary and I'm just not understanding the
 setup, but it's all just extremely unexpected behaviour from what is
 supposed to be a CI config file. Further, it's not even doing the same
 testing as our .travis.yml, but I'll make another ticket for that issue.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23755 [Core Tor/Tor]: conditionalize mirroring script in .gitlab-ci.yml

[Tor Bug Tracker & Wiki]

#23755: conditionalize mirroring script in .gitlab-ci.yml
--+---
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci continuous-integration
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 A few of us have experimented with using the `.gitlab-ci.yml` to run
 continuous integration jobs on gitlab.com and oniongit.eu.  Right now
 they're failing in the "update" job because `$DEPLOY_KEY` isn't
 configured.  At the very least we should make the job cleanly exit if the
 key is not configured.

 Typical output from the "update" job:

 {{{
 $ eval $(ssh-agent -s)
 Agent pid 4533
 $ ssh-add <(echo "$DEPLOY_KEY")
 Enter passphrase for /dev/fd/63: ERROR: Job failed: exit code 1
 }}}

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 In ticket #23585 I posted a patch that might fix the issue.

 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23585=a48690ea2873d699351929b25c9fd667f31e0890

 Could you try it to see if that fix the issue for you?

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sysrqb):

 kkuehl, what version of runc is installed? `sudo runc --version`

 We started working on this [0], but then I became busy and didn't have
 time to respond to boklm.

 I recently tried again, and it building is successful with runc-1.0.0-rc2
 when the config.json for  runc-0.1.1 is used. So I believe the json config
 file should only use the new object format when runc is v1.1 or newer.

 [0] https://lists.torproject.org/pipermail/tbb-
 dev/2017-September/000616.html

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json (was: make failing)

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by isis):

 * owner:  tbb-team => boklm
 * component:  Applications/Tor Browser => Applications/rbm


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

Re: [tor-bugs] #23754 [Applications/Tor Browser]: make failing

[Tor Bug Tracker & Wiki]

#23754: make failing
--+--
 Reporter:  kkuehl@…  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kkuehl@…):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #23754 [- Select a component]: make failing

[Tor Bug Tracker & Wiki]

#23754: make failing
--+
 Reporter:  kkuehl@…  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by kkuehl@…):

 Host OS:
 lsb_release -a
 No LSB modules are available.
 Distributor ID: Ubuntu
 Description:Ubuntu 17.04
 Release:17.04
 Codename:   zesty

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23754 [- Select a component]: make failing

[Tor Bug Tracker & Wiki]

#23754: make failing
--+
 Reporter:  kkuehl@…  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The original error looked as follows:
 git clone https://git.torproject.org/builders/tor-browser-build.git
 sudo apt-get install -y libyaml-libyaml-perl libtemplate-perl \
 libio-handle-util-perl libio-all-perl \
 libio-captureoutput-perl libfile-slurp-perl \
 libstring-shellquote-perl libsort-versions-perl \
 libdigest-sha-perl libdata-uuid-perl libdata-dump-perl \
 libfile-copy-recursive-perl git libgtk2.0-dev curl runc

 cd tor-browser-build
 make submodule-update
 make testbuild-linux-x86_64
 git submodule update --init
 ./rbm/rbm build release --target testbuild --target torbrowser-linux-
 x86_64
 Building project tor-browser - tor-browser-7.5a5-linux-x86_64-a14a6a
 Building project container-image - container-image_wheezy-
 amd64-df3a332e7b34.tar.gz
 Building project debootstrap-image - container-image_wheezy-amd64.tar.gz
 Using file /home/kkuehl/Downloads/tor-browser-build/out/debootstrap-image
 /container-image_ubuntu-base-17.04-base-amd64.tar.gz
 Error: Error starting remote:

 json: cannot unmarshal object into Go value of type []string

 Makefile:69: recipe for target 'testbuild-linux-x86_64' failed
 make: *** [testbuild-linux-x86_64] Error 1

 After determining that the error was being emitted from rbm/lib/RBB.pm
 I added a print statement to producte the following more verbose output:

 $ make testbuild-linux-x86_64
 git submodule update --init
 ./rbm/rbm build release --target testbuild --target torbrowser-linux-
 x86_64
 Building project tor-browser - tor-browser-7.5a5-linux-x86_64-a14a6a
 Building project container-image - container-image_wheezy-
 amd64-df3a332e7b34.tar.gz
 Building project debootstrap-image - container-image_wheezy-amd64.tar.gz
 Using file /home/kkuehl/Downloads/tor-browser-build/out/debootstrap-image
 /container-image_ubuntu-base-17.04-base-amd64.tar.gz
 project debootstrap-image command #!/bin/sh
 set -e
 if [ $(ls -1 '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-VfB1R
 /container-image_'* | wc -l) -ne 1 ]
 then
   echo "Can't find container image in input files" >&2
   ls -l '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-VfB1R' >&2
   exit 1
 fi
 mkdir -p '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm
 sudo tar -C '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs
 -xf $(ls -1 '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-VfB1R
 /container-image_'*)
 #!/bin/sh
 set -e
 mkdir -p '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm
 echo '#!/bin/sh' > '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-
 qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm/cmd
 echo 'id rbm >/dev/null 2>&1 || adduser -m rbm || useradd -m rbm' >>
 '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm/cmd
 echo '#!/bin/sh' > '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-
 qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm/run

 echo 'su - root -c /rbm/cmd' >> '/home/kkuehl/Downloads/tor-browser-
 build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm/run
 chmod +x '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm/cmd
 chmod +x '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/rootfs/rbm/run
 cat > '/home/kkuehl/Downloads/tor-browser-build/tmp/rbm-qUfJ9d/rbm-
 
containers/342cf55668a5bfef12e5fa4af3b57de63b7534dcae071c61e816d79c9b5af2b7'/config.json
 << EOF
 {
 "ociVersion": "1.0.0",
 "platform": {
 "os": "linux",
 "arch": "amd64"
 },
 "process": {
 "terminal": false,
 "user": {
 "uid": 0,
 "gid": 0
 },
 "args": [
 "/rbm/run"
 ],
 "env": [
 

Re: [tor-bugs] #22788 [Applications/Tor Browser]: Tor Browser rendering hangs when downloading large PDFs on higher security slider levels

[Tor Bug Tracker & Wiki]

#22788: Tor Browser rendering hangs when downloading large PDFs on higher 
security
slider levels
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security-slider   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 I can confirm that this happens even if the tor process is no longer
 downloading PDFs.
 In fact, it still happens even after the tabs containing the PDFs have
 been closed!

 To reproduce:
 1. Go to
 http://www.mitsubishielectric.com.au/Air_Conditioning_User_Manuals.html
 2. Open a few of the PDFs (I tried about 10)
 3. Wait for some to load and start to render
 4. Close their tabs
 5. Try to open another site

 It took a long time for the tabs and window to close, and I couldn't open
 any other sites, even after tor had stopped downloading anything. I had to
 restart the browser.

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

Re: [tor-bugs] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pastly):

 Looks good to me. I added a callsite in my ticket23753_032_01 (on gitweb
 this time).

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

Re: [tor-bugs] #2878 [Core Tor/Tor]: Don't bootstrap from an old consensus if we're about to replace it

[Tor Bug Tracker & Wiki]

#2878: Don't bootstrap from an old consensus if we're about to replace it
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  performance, bootstrap, tor-client,  |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #23605 [Core Tor/Tor]: BOOTSTRAP PROGRESS=80 is a lie

[Tor Bug Tracker & Wiki]

#23605: BOOTSTRAP PROGRESS=80 is a lie
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap clock-skew tor-guard   |  Actual Points:
  usability ux   |
Parent ID:  #22266   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #23745 [Applications/Tor Browser]: Tab crashes when using Tor Browser to access Google Drive

[Tor Bug Tracker & Wiki]

#23745: Tab crashes when using Tor Browser to access Google Drive
-+-
 Reporter:  angelotheram2|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-e10s, |  Actual Points:
  TorBrowserTeam201710   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by angelotheram2):

 It does go away when I set browser.tabs.remote.autostart.2 to false and
 restart the browser.
 I then set browser.tabs.remote.autostart.2 to back to true and the problem
 returns.
 This setting is a clue and a workaround, 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] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 I'm asking for a convenience option to configure which activates the right
 set of flags.
 Then if it works well, we can enable it as part of --enable-fragile-
 hardening, if the compiler supports those options.

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 I'll take a look. Given the recent findings above, this is now lower
 priority for 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

Re: [tor-bugs] #17521 [Core Tor/Tor]: Support capsicum(4) on FreeBSD

[Tor Bug Tracker & Wiki]

#17521: Support capsicum(4) on FreeBSD
-+-
 Reporter:  yawning  |  Owner:
 |  shawn.webb
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security, sandboxing, |  Actual Points:
  BSD, capsicum  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by shawn.webb):

 The problem is that seccomp2 uses a filtering approach. Essentially, once
 you've whitelisted the things you want to access, you can call open(2),
 socket(2), etc. at will and on demand.

 Capsicum takes a completely different approach, one that's fully
 incompatible with seccomp2. I've writting a PoC do demonstrate the
 approach I'm taking with this ticket:
 https://github.com/lattera/PoCs/tree/master/capsicum_fdpassing

 Note that the code I've written in the Tor codebase has diverged quite a
 bit from the PoC. The PoC is ugly code meant to serve as a brain dump and
 code testing area.

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by shawn.webb):

 That's unneeded, actually. Since configure honors external CFLAGS and
 LDFLAGS, users can simply set the required CFLAGS and LDFLAGS. That's what
 we're now doing in the HardenedBSD ports tree for Tor.

 To see the CFLAGS and LDFLAGS that get applied, take look here:
 https://github.com/HardenedBSD/hardenedbsd-
 ports/blob/master/Mk/Uses/cfi.mk

 In the HardenedBSD ports tree, we make sure that the proper llvm toolchain
 bits are there: https://github.com/HardenedBSD/hardenedbsd-
 ports/blob/master/Mk/bsd.hardening.mk#L234-L239

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

Re: [tor-bugs] #17521 [Core Tor/Tor]: Support capsicum(4) on FreeBSD

[Tor Bug Tracker & Wiki]

#17521: Support capsicum(4) on FreeBSD
-+-
 Reporter:  yawning  |  Owner:
 |  shawn.webb
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security, sandboxing, |  Actual Points:
  BSD, capsicum  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Tor has an existing abstraction layer for accessing seccomp'd syscalls on
 Linux, using a bunch of functions prefixed with sandbox_.
 Is it possible to extend or modify that abstraction layer, rather than
 adding a separate interface for FreeBSD?
 That would make it easier to maintain once it's 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] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Thank you for the patch, Neel.

 Here's my review:

 Functionality

 The reason we want to make this change is that the node sometimes has an
 IPv6 address.
 If the node has an IPv6 address, we need to add it to the link specifiers.
 Then we can remove the existing (incorrect) comment:
 {{{XXX: IPv6 is not clearly a thing in extend_info_t?}}}

 On some clients and relays, nodes don't have a routerinfo (ri is NULL).
 So you need to use the accessor functions for the primary (IPv4) and IPv6
 addresses for the node, which do the right thing.
 I think they're called something like node_get_primary_orport and
 node_get_ipv6_orport.

 Testing

 Did you test this code before you submitted it?
 Do the unit tests (make test) need changes so they pass with these code
 changes?
 Does chutney work with these changes? (make test-network-all)

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

Re: [tor-bugs] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Oh and this is what the output looks like (I've intentionally trigger
 one):

 {{{
 Oct 03 14:34:41.153 [warn] tor_bug_occurred_(): Bug:
 src/or/scheduler_kist.c:119: channel_outbuf_length: Non-fatal assertion
 !((channel_tls_from_base((chan)))->conn != ((void *)0)) failed. (on Tor
 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug: Non-fatal assertion
 !((channel_tls_from_base((chan)))->conn != ((void *)0)) failed in
 channel_outbuf_length at src/or/scheduler_kist.c:119. Stack trace: (on Tor
 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libasan.so.4(+0x55810) [0x7f0a3ea65810] (on Tor 0.3.2.2-alpha-dev
 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(log_backtrace+0x45)
 [0x5644509cdd05] (on Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(tor_bug_occurred_+0x12c)
 [0x564450a2cbfc] (on Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(+0x805d8d) [0x564450708d8d] (on
 Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(+0x7fa39d) [0x5644506fd39d] (on
 Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x1f8f5) [0x7f0a3e26a8f5] (on Tor 0.3.2.2-alpha-dev
 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f0a3e26b227] (on Tor
 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(do_main_loop+0x410)
 [0x5644505a3680] (on Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(tor_main+0x143d)
 [0x5644505a8efd] (on Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(main+0x1c) [0x5644505948ac] (on
 Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7f0a3c2301c1] (on Tor 0.3.2.2
 -alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] Bug:
 /home/dgoulet/Documents/git/tor/src/or/tor(_start+0x2a) [0x5644505972ba]
 (on Tor 0.3.2.2-alpha-dev 9733102b55884039)
 Oct 03 14:34:41.165 [warn] scheduler_bug_occurred(): Bug: Channel 2 in
 state open and scheduler state 1. Num cells on cmux: 0. Connection outbuf
 len: 2727. Num pending channels: 0. Channel in pending list: no (on Tor
 0.3.2.2-alpha-dev 9733102b55884039)
 }}}

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

Re: [tor-bugs] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 See branch: `ticket23753_032_01`.

 Only 5 callsites of `SCHED_BUG()` for now but there are probably more
 places we could benefit from those.

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

Re: [tor-bugs] #17521 [Core Tor/Tor]: Support capsicum(4) on FreeBSD

[Tor Bug Tracker & Wiki]

#17521: Support capsicum(4) on FreeBSD
-+-
 Reporter:  yawning  |  Owner:
 |  shawn.webb
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security, sandboxing, |  Actual Points:
  BSD, capsicum  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by shawn.webb):

 I've made a ton of progress on this. I now have a mostly capsicumized Tor.
 The very basics are working as of this writing.

 As it stands, what's left to do:

 1. Write sandbox wrappers for a few more libc calls (gmtime(3),
 socketpair(2), etc).
 2. Implement proper memory management (like, call free(3) where
 appropriate).
 3. Clean up a whole freakton of debug code.
 4. Write the Linux equivalent wrapper code (likely macros that just point
 to the corresponding libc functions).
 5. Build full body-suit armor as the person who's tasked with reviewing
 the ensuing patch will likely want to stab me.

 I will have a solution to demo in place by the time the Montreal meetup
 happens.

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

Re: [tor-bugs] #23605 [Core Tor/Tor]: BOOTSTRAP PROGRESS=80 is a lie

[Tor Bug Tracker & Wiki]

#23605: BOOTSTRAP PROGRESS=80 is a lie
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap clock-skew tor-guard   |  Actual Points:
  usability ux   |
Parent ID:  #22266   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * sponsor:   => Sponsor8-can


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

Re: [tor-bugs] #2878 [Core Tor/Tor]: Don't bootstrap from an old consensus if we're about to replace it

[Tor Bug Tracker & Wiki]

#2878: Don't bootstrap from an old consensus if we're about to replace it
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  performance, bootstrap, tor-client,  |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * severity:  Blocker => Major


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

Re: [tor-bugs] #2878 [Core Tor/Tor]: Don't bootstrap from an old consensus if we're about to replace it

[Tor Bug Tracker & Wiki]

#2878: Don't bootstrap from an old consensus if we're about to replace it
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  performance, bootstrap, tor-client,  |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (added)
 * severity:   => Blocker


Comment:

 What's more, the 85% (`BOOTSTRAP_STATUS_HANDSHAKE_OR`, "Finishing
 handshake with first hop") is very likely caused by the handshake with a
 directory mirror to attempt downloading a more current consensus.  Look at
 how `control_event_bootstrap()` decodes the special status
 `BOOTSTRAP_STATUS_HANDSHAKE`.  On the other hand, I think it takes a
 three-hop circuit to reach `BOOTSTRAP_STATUS_DONE` (100%).

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

Re: [tor-bugs] #23514 [Internal Services/Tor Sysadmin Team]: Please update my PGP public key

[Tor Bug Tracker & Wiki]

#23514: Please update my PGP public key
-+
 Reporter:  gk   |  Owner:  tpa
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #23747 [Applications/Tor Browser]: "Temporarily allow all this page" breaks JS on all other tabs (was: "Temporarily allow all this page" disables JS on all other tabs)

[Tor Bug Tracker & Wiki]

#23747: "Temporarily allow all this page" breaks JS on all other tabs
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 You're asking as if it were a Windows-only issue. Medium/High is required,
 of course.
 Starting with many tabs, search something in DDG, open that example.com
 and allow JS for it. That's all. JS on all other tabs stopped functioning
 (until reload).

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

Re: [tor-bugs] #23750 [Core Tor/Tor]: Isolate libevent usage to a few locations

[Tor Bug Tracker & Wiki]

#23750: Isolate libevent usage to a few locations
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  refactoring technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 I've started some work here as `isolate_libevent`.  Let's take a look and
 maybe merge it when 0.3.3 rolls around.

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

Re: [tor-bugs] #23603 [Core Tor/Tor]: hs: Cleanup race between circuit close and free with the HS circuitmap

[Tor Bug Tracker & Wiki]

#23603: hs: Cleanup race between circuit close and free with the HS circuitmap
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Agree!!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Bug such as #23751 and #23676 are very difficult to diagnose or reproduce
 so once we hit a BUG(), we should try to extract as much information as we
 can from the channel and state of the scheduler.

 Thus I propose `SCHED_BUG()`.

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

Re: [tor-bugs] #23712 [Core Tor/Tor]: sched: DESTROY cell on a circuit bypasses the scheduler

[Tor Bug Tracker & Wiki]

#23712: sched: DESTROY cell on a circuit bypasses the scheduler
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 One quick note here. When a DESTROY cell is sent, it is from
 `circuit_about_to_free()` which means that the "circuit_t" will get freed
 momentarily. However, we put a cell on the circuit queue for which we
 should be updating our cmux cell count (`circuitmux_set_num_cells()`) but
 that function takes a circuit object that we can't use... The circ ID is
 available but we can't do much with it with the current interface.

 That is "OK" because for the scheduler to know if more needs to be
 flushed, it uses `circuitmux_num_cells()` which counts the cell + destroy
 cell.

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Use java.util.stream functionality (cf.
 https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-
 summary.html#package.description).
 Here we should also think about where the parallelization would be most
 beneficial.

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

Re: [tor-bugs] #23751 [Core Tor/Tor]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
+--
 Reporter:  Felixix |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-channel, tor-sched, tor-buffer  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by pastly):

 Here's some thoughts.

 - Isn't the outbuf limited to like 32KB in size?
 - If the scheduler was what filled up the outbuf, would Vanilla done the
 same thing? Why or why not? Does Vanilla check a limit that KIST/KISTLite
 doesn't? Since Vanilla doesn't write outbuf->kernel, wouldn't it be
 __more__ likely to hit this?
 - What was the state of the channel that got a full outbuf? Was it
 closing? Was data continuing to pour in and for some reason we were never
 able to write, and thus the outbuf filled up? How many scheduling rounds
 did it take for this to happen? Did it all happen in one?

 Bah.

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

Re: [tor-bugs] #23751 [Core Tor/Tor]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
+--
 Reporter:  Felixix |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-channel, tor-sched, tor-buffer  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by dgoulet):

 From the stacktrace it seems a channel outbuf was filled up which
 triggered the assert when the limit was reached. It then released the
 channel but the scheduler couldn't find it in the pending list so it tried
 to free the channel and the two last BUG() are basically that. Bottom
 line, that channel was never in the scheduler loop.

 This is very weird. The fact that the outbuf was completely full is
 worrying that is:

 1. Was it filled up by then the scheduler?
 2. Or we have a bug where in `KISTLite` mode we didn't allow somehow to
 let the channel write to kernel?

 For (1), currently the only possible way I could find for a channel outbuf
 to be used without the scheduler knowing is during the connection
 handshake but that shouldn't fill up of `INT_MAX` data...

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Use java.time.* classes for date and time parsing and processing.  Some
 examples are in the patches for #22428 and #22983.  More can be found in
 the java.time package description.
 (See http://www.oracle.com/technetwork/articles/java/jf14-date-
 time-2125367.html and https://docs.oracle.com/javase/8/docs/api/java/time
 /package-summary.html#package.description)

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+--
 Reporter:  arlolra|  Owner:  arlolra
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arlolra):

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


Comment:

 I'll probably be working on this next week at the dev meeting.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The new features of java 8 should be used.  This ticket starts collecting
 the features and approaches we want to use and comments should add and
 discuss the various topics one per comment in order to have the tickets
 for the various products simply refer to a comment number (if possible).

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

Re: [tor-bugs] #22428 [Metrics/CollecTor]: Add webstats module

[Tor Bug Tracker & Wiki]

#22428: Add webstats module
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2017   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_information => needs_review


Comment:

 Please review
 [​https://gitweb.torproject.org/user/iwakeh/collector.git/?h=task-22428-3
 this task branch], which is based on the current master and already uses
 java 8 features.

 The implementation changed quite a bit as it could build on the web server
 log specification (#23243). That's why I didn't continue on the earlier
 branch, because I think the code is easier to review in total here.
 It builds on 2.1.0-dev version of metrics-lib.
 Besides the (j)unit tests I ran system tests for sync and local import
 functionality with the supplied real logs.
 The metrics-lib version needs to be adapted as soon as a release with log
 descriptors is available.

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

Re: [tor-bugs] #23751 [Core Tor/Tor]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
+--
 Reporter:  Felixix |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-channel, tor-sched, tor-buffer  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * keywords:   => tor-channel, tor-sched, tor-buffer
 * priority:  Medium => High
 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: 0.3.2.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] #23710 [Core Tor/Tor]: sched: channel_more_to_flush() is probably looking at the wrong queue

[Tor Bug Tracker & Wiki]

#23710: sched: channel_more_to_flush() is probably looking at the wrong queue
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Quick note: #23709 is a thing, the `incoming_queue` is always empty so it
 doesn't affect `channel_more_to_flush()` as it it basically always true
 that it is empty so it will never return 1 in the case of it being non
 empty.

 Thus, it is safe for now to leave it that way.

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

Re: [tor-bugs] #23711 [Core Tor/Tor]: sched: KIST writes to kernel and get a "wants to write" notification right after

[Tor Bug Tracker & Wiki]

#23711: sched: KIST writes to kernel and get a "wants to write" notification 
right
after
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 This won't really get fixed until #23744 so postponing.

 For now, I think it is fine, KIST recovers properly from that.

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

[tor-bugs] #23751 [- Select a component]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
--+
 Reporter:  Felixix   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Duplicate to #23676 ?
 But the buffers.c:690 seems new.

 {{{
 [warn] tor_bug_occurred_: Bug: src/common/buffers.c:690: buf_add: Non-
 fatal assertion !(buf->datalen >= INT_MAX - string_len) failed.
 [warn] tor_bug_occurred_: Bug: src/or/scheduler_kist.c:406:
 update_socket_written: Non-fatal assertion !((!ent)) failed.
 [warn] tor_bug_occurred_: Bug: src/or/scheduler_kist.c:374:
 socket_can_write: Non-fatal assertion !((!ent)) failed.
 }}}

 At the end of the log file's time the tor process stays at 100% cpu.
 Server hang up and a reboot was necessary.
 I jumped on 3.2.2a already.

 {{{
 Sep 21 23:14:06.010 [notice] Tor 0.3.2.1-alpha (git-290274dbb5428bc5)
 running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.4,
 Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.1.
 }}}

 
 {{{
 Oct 02 02:14:18.000 [notice] Heartbeat: Tor's uptime is 10 days 2:59
 hours, with 193846 circuits open. I've sent 6390.97 GB and received
 6348.01 GB.
 Oct 02 02:14:18.000 [notice] Circuit handshake stats since last time:
 4007/4007 TAP, 132384/132384 NTor.
 Oct 02 02:14:18.000 [notice] Since startup, we have initiated 0 v1
 connections, 0 v2 connections, 0 v3 connections, and 418760 v4
 connections; and received 2215 v1 connections, 43847 v2 connections,
 101525 v3 connections, and 746328 v4 connections.
 Oct 02 02:31:24.000 [notice] Scheduler type KISTLite has been enabled.
 Oct 02 02:58:02.000 [warn] tor_bug_occurred_: Bug:
 src/common/buffers.c:690: buf_add: Non-fatal assertion !(buf->datalen >=
 INT_MAX - string_len) failed. (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: Non-fatal assertion !(buf->datalen >=
 INT_MAX - string_len) failed in buf_add at src/common/buffers.c:690. Stack
 trace: (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x11a2bf8  at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x11bd82c  at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x11a435b  at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x1129572
  at /usr/local/bin/tor (on Tor
 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x10f2d38
  at /usr/local/bin/tor (on Tor
 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x10e78cb
  at /usr/local/bin/tor (on Tor
 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x10e7ed8
  at /usr/local/bin/tor (on Tor
 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x109e20a
  at /usr/local/bin/tor (on
 Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x10e8702
  at /usr/local/bin/tor (on Tor
 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x10db0f6
  at /usr/local/bin/tor (on Tor 0.3.2.1-alpha
 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x10d9912  at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x801b37a96
  at /usr/local/lib/libevent-2.1.so.6
 (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x801b33cfe  at
 /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x1072d15  at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x1075119  at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x1070b69  at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] Bug: 0x1070a61 <_start+0x1a1> at
 /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5)
 Oct 02 02:58:02.000 [warn] write_to_buf failed on an orconn; notifying of
 error (fd 1935)
 Oct 02 02:58:02.000 [warn] Scheduler asked to release channel 1994256 but
 it wasn't in channels_pending
 Oct 02 02:58:02.000 [warn] 

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

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * 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] #23749 [Obfuscation/Snowflake]: Snowflake-client potentially suffers from memory leaks

[Tor Bug Tracker & Wiki]

#23749: Snowflake-client potentially suffers from memory leaks
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * cc: dcf (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] #23740 [Core Tor/Tor]: prop224: tor_bug_occurred_(): Bug: src/or/hs_service.c:403: service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor 0.3.2.1-alpha 290274dbb5428bc5)

[Tor Bug Tracker & Wiki]

#23740: prop224: tor_bug_occurred_(): Bug: src/or/hs_service.c:403:
service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor
0.3.2.1-alpha 290274dbb5428bc5)
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224 tor-ipv6, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 This is in single onion service mode. We should wait until #23493 is
 sorted out before doing anything with this even though the fix is simple.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * cc: dcf (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] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_information => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/log?h=task-22983-3 this task branch], which is based on the
 current master and already uses java 8 features.

 The implementation changed quite a bit as it could build on the web server
 log specification (#23243).  That's why I didn't continue on the earlier
 branch,  because I think the code is easier to review in total here.
 This dev version of metrics-lib was also system-tested as part of
 CollecTor's new module, i.e., used for sync and local imports there.

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

Re: [tor-bugs] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
-+
 Reporter:  cathugger|  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 See branch: `bug23748_032_01`

 It takes cathugger's patch and add a changes file.

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

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

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 I have created a patch to address this. The filename is
 001-setup_introduce1_data_node.patch.

 -Neel

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

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

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * Attachment "001-setup_introduce1_data_node.patch" added.

 Patch to make setup_introduce1_data() take a node & create
 get_lspecs_from_node() & remove legacy get_lspecs_from_extend_info() in
 hs_circuit.c

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

Re: [tor-bugs] #23740 [Core Tor/Tor]: prop224: tor_bug_occurred_(): Bug: src/or/hs_service.c:403: service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor 0.3.2.1-alpha 290274dbb5428bc5)

[Tor Bug Tracker & Wiki]

#23740: prop224: tor_bug_occurred_(): Bug: src/or/hs_service.c:403:
service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor
0.3.2.1-alpha 290274dbb5428bc5)
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224 tor-ipv6, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:  prop224 tor-ipv6 => prop224 tor-ipv6, tor-hs


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

Re: [tor-bugs] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
-+
 Reporter:  cathugger|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * 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] #23733 [Applications/Tor Browser]: Tor failed to launch in OSX

[Tor Bug Tracker & Wiki]

#23733: Tor failed to launch in OSX
--+--
 Reporter:  jakob4800 |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability ux  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * keywords:   => tbb-usability ux


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

Re: [tor-bugs] #23672 [Core Tor/Tor]: hs-v3: With multiple SOCKS connection to the same .onion, don't trigger a descriptor fetch for each connection

[Tor Bug Tracker & Wiki]

#23672: hs-v3: With multiple SOCKS connection to the same .onion, don't trigger 
a
descriptor fetch for each connection
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, tor-client, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 thanks for the updates! merging.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23750 [Core Tor/Tor]: Isolate libevent usage to a few locations

[Tor Bug Tracker & Wiki]

#23750: Isolate libevent usage to a few locations
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  refactoring technical-debt
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 With #21841, we restricted openssl header usage to a small number of
 modules.  We should do the same with libevent.

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

Re: [tor-bugs] #23745 [Applications/Tor Browser]: Tab crashes when using Tor Browser to access Google Drive

[Tor Bug Tracker & Wiki]

#23745: Tab crashes when using Tor Browser to access Google Drive
-+-
 Reporter:  angelotheram2|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-e10s, |  Actual Points:
  TorBrowserTeam201710   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-crash => tbb-crash, tbb-e10s, TorBrowserTeam201710


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

Re: [tor-bugs] #23745 [Applications/Tor Browser]: Tab crashes when using Tor Browser to access Google Drive

[Tor Bug Tracker & Wiki]

#23745: Tab crashes when using Tor Browser to access Google Drive
--+--
 Reporter:  angelotheram2 |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: mcs, brade, arthuredelstein (added)
 * status:  needs_information => assigned


Comment:

 Replying to [comment:1 gk]:
 > Is that reproducible? Does it go away if you set
 `browser.tabs.remote.autostart.2` to `false` in your `about:config` and
 try again after restart? Does it happen with a vanilla Firefox 52 ESR as
 well? (see https://www.mozilla.org/en-US/firefox/organizations/all/ for a
 download option)

 Without e10s the crash does not happen and Firefox is not affected. mcs,
 brade, arthur: Can anybody of you take a look at that and figure out what
 is going on?

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

Re: [tor-bugs] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
-+
 Reporter:  cathugger|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cathugger):

 * Attachment "addsplitcheck.patch" 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] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
-+
 Reporter:  cathugger|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cathugger):

 So it looks like currently keeping public key around is good idea.
 I'll add patch which add proper checking of public_key and recreating it
 if it gets deleted.
 INIT_ED_KEY_MISSING_SECRET_OK flag can be added later for blinded keys
 usecase.

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

Re: [tor-bugs] #23733 [Applications/Tor Browser]: Tor failed to launch in OSX

[Tor Bug Tracker & Wiki]

#23733: Tor failed to launch in OSX
--+--
 Reporter:  jakob4800 |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * cc: catalyst (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] #23747 [Applications/Tor Browser]: "Temporarily allow all this page" disables JS on all other tabs

[Tor Bug Tracker & Wiki]

#23747: "Temporarily allow all this page" disables JS on all other tabs
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:2 cypherpunks]:
 > Maybe, you just don't notice that?
 > Open http://example.com/
 > Press "Temporarily allow all this page"
 > And check that JS-dependent features stopped to function on Trac
 >
 > Opened DDG Search page will show you
 > > You are being redirected to
 the non-JavaScript site.Click here if
 it doesn't happen automatically.

 Could you give us some steps to reproduce your issue? Where are you
 starting from? Are you setting the security slider to "high"? Or "medium"?

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

 * priority:  Medium => High
 * severity:  Normal => Major


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23749 [Obfuscation/Snowflake]: Snowflake-client potentially suffers from memory leaks

[Tor Bug Tracker & Wiki]

#23749: Snowflake-client potentially suffers from memory leaks
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 It uses up to 160.5 MiB on my system after 6 hours of use, so it seems
 that it's due to some memory leak, 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] #23749 [Obfuscation/Snowflake]: Snowflake-client potentially suffers from memory leaks

[Tor Bug Tracker & Wiki]

#23749: Snowflake-client potentially suffers from memory leaks
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

 * priority:  Medium => High
 * severity:  Normal => Major


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

Re: [tor-bugs] #23672 [Core Tor/Tor]: hs-v3: With multiple SOCKS connection to the same .onion, don't trigger a descriptor fetch for each connection

[Tor Bug Tracker & Wiki]

#23672: hs-v3: With multiple SOCKS connection to the same .onion, don't trigger 
a
descriptor fetch for each connection
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replied to Nickm's comment

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

Re: [tor-bugs] #23722 [Core Tor/Tor]: Somebody should profile a Tor 0.3.1.7 relay

[Tor Bug Tracker & Wiki]

#23722: Somebody should profile a Tor 0.3.1.7 relay
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 ~5.1MB/sec at the time for ~100 minutes.

 Aren't we using the AES-ni if available, would it be seen in the profile?

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

Re: [tor-bugs] #23722 [Core Tor/Tor]: Somebody should profile a Tor 0.3.1.7 relay

[Tor Bug Tracker & Wiki]

#23722: Somebody should profile a Tor 0.3.1.7 relay
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Weird! Was the server seeing much traffic at the time? I'm surprised that
 none of the compression algorithms, digest algorithms, or AES appeared on
 profile.

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+---
 Reporter:  asn|  Owner:  asn
 Type:  defect | Status:
   |  needs_information
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+---

Comment (by asn):

 We merged #23671 and #23670  to master today, and hopefully those new logs
 will help us debug this issue better. If you are hunting for this bug,
 please upgrade to latest master :) 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] #23733 [Applications/Tor Browser]: Tor failed to launch in OSX

[Tor Bug Tracker & Wiki]

#23733: Tor failed to launch in OSX
--+--
 Reporter:  jakob4800 |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #23672 [Core Tor/Tor]: hs-v3: With multiple SOCKS connection to the same .onion, don't trigger a descriptor fetch for each connection

[Tor Bug Tracker & Wiki]

#23672: hs-v3: With multiple SOCKS connection to the same .onion, don't trigger 
a
descriptor fetch for each connection
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 https://oniongit.eu/dgoulet/tor/merge_requests/8

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

Re: [tor-bugs] #23727 [Archived/Ooni]: Allow to turn off notification for the ooniprobe android app

[Tor Bug Tracker & Wiki]

#23727: Allow to turn off notification for the ooniprobe android app
---+--
 Reporter:  torland|  Owner:  hellais, anadahz
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Archived/Ooni  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * owner:  (none) => hellais, anadahz
 * component:  - Select a component => Archived/Ooni


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

Re: [tor-bugs] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
-+
 Reporter:  cathugger|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 The public key is really not useful to tor right now.

 The reason we have tor write it to disk is because of the not implemented
 offline key feature where tor will need the public key to generate the
 .onion but won't load any private key. Instead, it will load a series of
 blinded key pre-generated by the operator.

 That being said, we don't have this feature anyway but we still put the
 public key on disk so if we get the offline keys let say next version, an
 operator would be able to remove the private key and tor would work out
 with the public key.

 But true, tor should write the public key on disk if only the private key
 is found.

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

[tor-bugs] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
--+-
 Reporter:  cathugger |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  0.3.2.2-alpha
 Severity:  Normal|   Keywords:  tor-hs, prop224
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 When creating directory for v3 onion services, tor generates 3 files:
 "hs_ed25519_secret_key" consisting 64 bytes expanded secret key,
 "hs_ed25519_public_key" consisting 32 bytes public key and "hostname"
 consisting base32 representation of public key plus checksum, version
 identifier and ".onion" suffix.
 When reading existing v3 onion service directory, however, tor reads only
 "hs_ed25519_secret_key" file, completely ignoring "hs_ed25519_public_key",
 even if it holds public key not matching secret key in
 "hs_ed25519_secret_key".
 This can lead to potentially confusing behavior, when
 hs_ed25519_secret_key is changed, tor subsequently generates new hostname,
 but hs_ed25519_public_key stays old.
 Either hs_ed25519_public_key should not be generated in the first place,
 as it's unnecessary and redundant, or it should be checked for
 correctness.

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

Re: [tor-bugs] #23671 [Core Tor/Tor]: Say how many other nodes we're missing descriptors for

[Tor Bug Tracker & Wiki]

#23671: Say how many other nodes we're missing descriptors for
---+---
 Reporter:  teor   |  Owner:  asn
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
   |  implemented
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Implemented with the merge of #23670.

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

Re: [tor-bugs] #23670 [Core Tor/Tor]: Say how many primary entry guards we're missing descriptors for

[Tor Bug Tracker & Wiki]

#23670: Say how many primary entry guards we're missing descriptors for
---+---
 Reporter:  teor   |  Owner:  asn
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
   |  implemented
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Looks good! Testing and merging.

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

Re: [tor-bugs] #23739 [Core Tor/Tor]: improve documentation on how we use gcov

[Tor Bug Tracker & Wiki]

#23739: improve documentation on how we use gcov
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  new-developers tor-doc tor-tests-|  implemented
  coverage   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Another step forward! Merging in 0.3.2.

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

Re: [tor-bugs] #23747 [Applications/Tor Browser]: "Temporarily allow all this page" disables JS on all other tabs

[Tor Bug Tracker & Wiki]

#23747: "Temporarily allow all this page" disables JS on all other tabs
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Maybe, you just don't notice that?
 Open http://example.com/
 Press "Temporarily allow all this page"
 And check that JS-dependent features stopped to function on Trac

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

Re: [tor-bugs] #23670 [Core Tor/Tor]: Say how many primary entry guards we're missing descriptors for

[Tor Bug Tracker & Wiki]

#23670: Say how many primary entry guards we're missing descriptors for
---+---
 Reporter:  teor   |  Owner:  asn
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 Pushed two new commits addressing both comments above.

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

Re: [tor-bugs] #23739 [Core Tor/Tor]: improve documentation on how we use gcov

[Tor Bug Tracker & Wiki]

#23739: improve documentation on how we use gcov
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  new-developers tor-doc tor-tests-|  Actual Points:
  coverage   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_revision => needs_review


Comment:

 Thanks!  I pushed an update to the merge request fixing that.  (I was
 adjusting fill column settings and one escaped.)

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

Re: [tor-bugs] #23724 [Applications/Tor Browser]: NoScript restartless update breaks Security Slider and its icon disappears

[Tor Bug Tracker & Wiki]

#23724: NoScript restartless update breaks Security Slider and its icon 
disappears
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 This madness was reported for 5.1rc2, but it was released untested! See
 https://forums.informaction.com/viewtopic.php?f=7=2

 After restart NoScript resets to TBB's defaults (Low), ignoring the
 Security Slider settings.

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

Re: [tor-bugs] #23747 [Applications/Tor Browser]: "Temporarily allow all this page" disables JS on all other tabs

[Tor Bug Tracker & Wiki]

#23747: "Temporarily allow all this page" disables JS on all other tabs
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

 * status:  new => needs_information


Comment:

 I don't reproduce that. Clicking on "Temporarily allow all this page" does
 not enable or disable JS on other tabs for 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

Re: [tor-bugs] #13575 [Applications/Tor Browser]: Disable randomised Firefox HTTP cache decay user test groups

[Tor Bug Tracker & Wiki]

#13575: Disable randomised Firefox HTTP cache decay user test groups
-+-
 Reporter:  isis |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-pref, tbb-fingerprinting,|  Actual Points:
  ff52-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  new => needs_review


Comment:

 > we should be setting `browser.cache.frecency_experiment` to `-1`
 to fix this ticket without patching.

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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  new => needs_review


Comment:

 Set `dom.disable_window_showModalDialog` to `true` to fix the obvious part
 of this ticket without patching.

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

Re: [tor-bugs] #23670 [Core Tor/Tor]: Say how many primary entry guards we're missing descriptors for

[Tor Bug Tracker & Wiki]

#23670: Say how many primary entry guards we're missing descriptors for
---+---
 Reporter:  teor   |  Owner:  asn
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => needs_revision


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