[tor-bugs] #18973 [Applications/Tor Messenger]: Possible authentication bug

[Tor Bug Tracker & Wiki]

#18973: Possible authentication bug
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Major   |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 > First we started a fresh conversation and messages went through. We
 > compared our fingerprints using other channel and they didn't match.
 After
 > this I restarted my Tor Messenger and then fingerprints matched. All the
 > time we used same devices.

 See the thread on tor-talk https://lists.torproject.org/pipermail/tor-
 talk/2016-May/040872.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] #18962 [Core Tor/Tor]: Merge feature 18483 cleaup commits to master

[Tor Bug Tracker & Wiki]

#18962: Merge feature 18483 cleaup commits to master
---+
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID:  #18483 | Points:  small
 Reviewer:  nickm  |Sponsor:
---+

Comment (by teor):

 Replying to [comment:3 nickm]:
 > These commits looked okay to me; I reviewed feature18483-cleanup since I
 couldn't find the other branch.

 See #18483 for the changes in #18483 due to #18929.
 I also rebased this branch feature18483-cleanup-v2 on top of the latest
 #18483, it can go in 0.2.9 because it's all cosmetic. Or 0.2.8 if you
 want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18483 [Core Tor/Tor]: Clients should always tunnel connections, and never fall back to a DirPort

[Tor Bug Tracker & Wiki]

#18483: Clients should always tunnel connections, and never fall back to a 
DirPort
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:  #18809   |  Actual Points:  2 hours
 Reviewer:  nickm| Points:  small
 |Sponsor:  None
-+-

Comment (by teor):

 Replying to [comment:13 nickm]:
 > NOTE to '''nickm''': I'll have to rebase this one last time since I went
 and squashed and merged #18921.  That's on me, though.

 I did the rebase into my branch feature18483-028-v2 because of changes in
 #18929:

 Old commit / New commit / Name
 0de9faa a5b5447 Make clients always use begindir for directory requests
 15fe5e8 950eae4 Make clients only select directories with reachable
 ORPorts
 aec84c5 8febffe Only choose directory DirPorts on relays

 The following commits were deleted because this no longer depends on
 #18929:
 8adbfab Merge branch 'bug18921' into feature18483-028
 1100a70 Revert "Remove must_have_or from
 router_has_non_preferred_address_rs"
 5c8fde2 Only fall back to nodes with valid ORPorts when using begindir

 > 0de9faa402bebc98a58c9f65149e72e598926184:
 >   * begindir_reason will never be set!  You need to declare the `reason`
 argument in `directory_command_should_use_begindir` as "const char * *",
 not `const char *`.

 Oops! Pointer handling error.
 Calling this NM1.
 9f01dc4 fixup! Make clients always use begindir for directory requests

 > Otherwise, this looks good.

 Let's get it merged, I am much happier with it now it's disentangled and
 #18929 has shrunk.
 (And it merges fine on top of both maint-0.2.8 and the new #18929.)

 See #18962 for a rebased feature18483-cleanup-v2, which can go in 0.2.9.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18929 [Core Tor/Tor]: Fix selection of directories with non-preferred address families

[Tor Bug Tracker & Wiki]

#18929: Fix selection of directories with non-preferred address families
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605  |  0.2.8.1-alpha
Parent ID:  #18483   | Resolution:
 Reviewer:  isis,nickm   |  Actual Points:  2 hours
 | Points:  small
 |Sponsor:
-+-

Old description:

> In #17840 in 0.2.8.1-alpha, we sometimes fail to fall back to directories
> with addresses in non-preferred IP families:
> * we didn't identify relays that we could fall back to correctly;
> * we incorrectly assumed that every node would have an IPv4 address -
> this doesn't apply to bridges;
> * we counted relays when we had already fallen back to non-preferred
> addresses.
>
> This likely affected bridge clients with IPv4 bridges, and clients in
> small networks.

New description:

 In #17840 in 0.2.8.1-alpha, we sometimes fail to fall back to directories
 with addresses in non-preferred IP families:
 * we didn't identify relays that we could fall back to correctly;
 * we incorrectly assumed that every node would have an IPv4 address~~ -
 this doesn't apply to bridges~~;
 * we counted relays when we had already fallen back to non-preferred
 addresses.

 This likely affected ~~bridge clients with IPv4 bridges, and~~ clients in
 small networks.

--

Comment (by teor):

 Wow, you're right, let's do it the simple way - delete the bad check:
 bug18929-v3

 (I thought I was saving client speed at the cost of complexity. For most
 clients, this would have imposed more checks on every directory for no
 benefit, and for clients where it mattered, I didn't have actual
 performance figures.)

 I will need to rebuild a simpler #18483 branch now there's no dependency
 between them.

 For the record:
 > NM2 For router_has_non_preferred_address_node -- an unlisted bridge has
 a node_t, but does not have a routerstatus. Can this function ever get
 called on a bridge? Do we care?

 This function never gets called on a bridge, as
 directory_get_from_dirserver handles bridges.
 So this bug never affected bridges or bridge clients, sorry, isis!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17799 [Core Tor/Tor]: Hash All PRNG output before use

[Tor Bug Tracker & Wiki]

#17799: Hash All PRNG output before use
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201605,   |  Actual Points:
  TorCoreTeam-postponed-201604   | Points:  small/medium-
Parent ID:   |  remaining
 Reviewer:  asn  |Sponsor:
-+-

Comment (by cypherpunks):

 More CSPRNG test suites to run:
 * https://www-labs.iro.umontreal.ca/~simardr/testu01/tu01.html
 * https://sourceforge.net/projects/pracrand/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
+
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  must-fix-before-028-rc  |  Actual Points:
Parent ID:  | Points:  small
 Reviewer:  nickm   |Sponsor:
+
Changes (by teor):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:6 nickm]:
 > f2e9af1b859287d24201a65213ab6ad5362e9c99 --
 >   * looks fine, though the comment was a little unclear to me.  I'll fix
 that though.  '''nickm''' -- clarify the comment on
 download_status_cert_init to clarify that download_status_cert_init() is
 _not_ okay to call after the first failure has occurred.
 >
 > 87fdbb6 and bea0819 --
 >   * I'm not sure about these, because they bring back the presence of
 authorities as client enumerators.  With these patches, since every
 fallback will go down _sometimes_, every client will try an authority
 _sometimes_, and the authorities will still be able to enumerate them.
 What if, as an alternative solution, we just use a sdifferent schedule for
 certificate downloads?   Are they still really necessary with f2e9af1 ?

 I guess I worry about a situation where all the fallbacks are blocked, but
 the authorities are not. Then Tor 0.2.8 won't be able to bootstrap
 reliably, where 0.2.7 could. (I know this is rare.)

 And even if fallbacks don't go down, the authorities are still present in
 the list of fallbacks. With the current 100 fallbacks at weight 10 and 9
 authorities at weight 1, clients will try authorities 9 / 1009 ~= 1% of
 the time.

 That said, these certificate fetches only happen rarely - once on initial
 client bootstrap, and once each time a certificate expires. If a client
 has a valid consensus when a certificate expires, it fetches the
 certificates from a random directory in the consensus.

 So the overall chance of any client contacting an authority is:
 * 1% on initial bootstrap,
 * 1% each time its consensus stops being reasonably live (if tor isn't run
 for 72 hours)
 * on authority certificate expiry:
   * 1% if the consensus is not reasonably live
   * vanishingly small with a live consensus (the authorities I checked
 have consensus weight 20)

 We can do a few things to fix this:
 * don't fall back to an authority, always use fallbacks (revert 87fdbb6
 and bea0819)
 * fall back to a fallback first, then an authority (revert bea0819)
 * merge #18963 to re-use the same directory that gave us the consensus for
 certificates
 * weight the fallbacks higher (but equally) so the authorities see less
 than 1% of traffic

 I like a combination of:
 * fall back to an authority only after trying the fallback that gave you
 the consensus (#18963), and another fallback (merge #18963, revert
 bea0819)
 * decide how much traffic we want the authorities to get, and weight the
 fallbacks accordingly
  * one in a thousand would need a weight of 100
  * one in a million would need a weight of 100,000

 Thoughts?

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

Re: [tor-bugs] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed   |  0.2.8.1-alpha
Parent ID:  #18816   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by teor):

 (My branch bug19683-remember is based on my branch bug18816)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17901 [Core Tor/Tor]: Tor would bind ControlPort to public ip address if it has no localhost interface

[Tor Bug Tracker & Wiki]

#17901: Tor would bind ControlPort to public ip address if it has no localhost
interface
--+
 Reporter:  s7r   |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.10
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_information => new


Comment:

 The two checks are:
 * The interface for 127.0.0.1 must have the loopback flag set
 * Binding to 127.0.0.1 must actually bind to 127.0.0.1
 (And I still have to confirm the second check works on an actual FreeBSD
 jail.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13953 [Core Tor/Tor]: Self-test reachability test - Listen address from ORPort is ignored, it uses default address unless specified via Address argument

[Tor Bug Tracker & Wiki]

#13953: Self-test reachability test - Listen address from ORPort is ignored, it
uses default address unless specified via Address argument
--+
 Reporter:  s7r   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.10
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #17782| Points:  medium
 Reviewer:|Sponsor:
--+

Comment (by teor):

 When building a descriptor:
 * warn if the ORPort address on the advertised IPv4 ORPort doesn't match
 the IPv4 address in the descriptor
 * warn if the DirPort address on the advertised IPv4 DirPort doesn't match
 the IPv4 address in the descriptor
 In both cases, tell the user to set "Address" to the correct IPv4 address.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed   |  0.2.8.1-alpha
Parent ID:  #18816   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:3 nickm]:
 > Did you forget to push that branch? I don't see it on your github repo;
 I only see the bug19683 branch that you say not to merge.

 Pushed now.

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

Re: [tor-bugs] #18902 [Core Tor/Tor]: Avoid variable shadowing in Tor

[Tor Bug Tracker & Wiki]

#18902: Avoid variable shadowing in Tor
---+--
 Reporter:  teor   |  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy refactor  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:3 nickm]:
 > Suggestion 1: Think about reviewability as you go. I can easily see this
 patch becoming huge.

 I would hope to be able to verify the modifications by running the same
 automated script (see below).

 > Suggestion 2: Think about automation wherever possible. This test is
 mostly automatable.

 It may help to do this patch in several stages:
 * automatically rename every shadowed variable
 * manually cleanup long lines to appease `make check-spaces`
 * turn on `-Wshadow` in the tor makefile

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18972 [Internal Services/Tor Sysadmin Team]: Refresh Colin's OpenPGP subkeys

[Tor Bug Tracker & Wiki]

#18972: Refresh Colin's OpenPGP subkeys
-+-
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The subkeys for my key {{{7268 24BE 9D8D 5CF0 09C5  F039 FF9D 1C57 779F
 B883}}} have been updated. Could you please refresh it from the (SKS)
 keyservers?

 Thanks!

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

[tor-bugs] #18971 [Applications/Tor Browser]: Disable Firefox malware by default

[Tor Bug Tracker & Wiki]

#18971: Disable Firefox malware by default
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 webgl.disabled
 browser.search.geoip.timeout
 datareporting.healthreport.documentServerURI
 devtools.devices.url
 dom.vibrator.enabled
 dom.vr.oculus.enabled
 dom.vr.oculus050.enabled
 dom.workers.websocket.enabled
 dom.webnotifications.enabled
 geo.wifi.xhr.timeout

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18970 [Applications/Tor Browser]: TBB never remember "Exeptions - Cookie" domains

[Tor Bug Tracker & Wiki]

#18970: TBB never remember "Exeptions - Cookie" domains
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 1. Disable Torbutton and TorLauncher.
 2. about:preferences#privacy
 History: "Use custom settings for history"
 [X] Always use private browse mode
 [_] Accept cookie from sites
 3. Click "Exceptions" and add "www.nsa.gov", "Allow for sessions", "Save
 changes".
 4. Go to "www.nsa.gov" and do some work.
 5. Close TBB and start again. Go to "www.nsa.gov".

 Expected result:
 TBB should accept NSA's cookie.

 Actual result:
 TBB forgot all "Exeptions - Cookie" domains.
 -
 History: "Use custom settings for history"
 [X] Always use private browse mode
 [_] Accept cookie from sites
 -
 these doesn't change, but all "Exeptions" are gone.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18969 [Applications/Tor Browser]: Let user configure proxy settings with Torbutton enabled

[Tor Bug Tracker & Wiki]

#18969: Let user configure proxy settings with Torbutton enabled
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I'm using TBB as normal browser, using HTTP proxy(privoxy).
 To do this you have to disable Torbutton and TorLauncher.

 By disabing Torbutton, I can set my own http proxy.
 However, when it's disabled,

 1. =(burger mark) > "(arrow) Firefox sync" button is appear
 2. = > (?) > "About Tor Browser" > it now says "Firefox ESR 6.0a5".
 etc.

 So, why not allow user to set their own proxy with Torbutton enabled?
 When it's enabled, "Firefox ESR" will be replaced to "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

[tor-bugs] #18968 [Applications/Tor Check]: bulkexitlist is so much larger than exit-addresses

[Tor Bug Tracker & Wiki]

#18968: bulkexitlist is so much larger than exit-addresses
+-
 Reporter:  arlolra |  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 Should probably revert
 
https://gitweb.torproject.org/check.git/commit/?id=026e43b08656d78398b15742ddf510f6b17f859e

 See the thread https://lists.torproject.org/pipermail/tor-
 dev/2016-March/010559.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] #18954 [Internal Services/Service - trac]: Trac should not make request to next/related bug

[Tor Bug Tracker & Wiki]

#18954: Trac should not make request to next/related bug
--+--
 Reporter:  gk|  Owner:  qbi
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [comment:9 cypherpunks]:
 > Replying to [comment:7 bugzilla]:
 > > It's the behavior of internal FF's prefetcher that tries to predict
 the "next" your move based on its prediction algorithm which is based on
 history of your navigation.
 > You're talking out of your ass. Stop it. Kthx.
 This is how normal prefetcher should work (see e.g. CPU manuals), and it's
 not interesting that Mozilla was going to do it, but did only a "link rel
 next" reader. And what cookie are you talking about, dirty animal?

 gk:
 Next ticket becomes next in Custom Query or Report if you've opened a
 ticket from them. It's not login-related.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18851 [Core Tor/Tor]: Clarify GETINFO status/reachability-succeeded/dir with no DirPort

[Tor Bug Tracker & Wiki]

#18851: Clarify GETINFO status/reachability-succeeded/dir with no DirPort
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  TorCoreTeam201605, torspec  |  Actual Points:
Parent ID:  #18616  | Points:  small
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #17799 [Core Tor/Tor]: Hash All PRNG output before use

[Tor Bug Tracker & Wiki]

#17799: Hash All PRNG output before use
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201605,   |  Actual Points:
  TorCoreTeam-postponed-201604   | Points:  small/medium-
Parent ID:   |  remaining
 Reviewer:  asn  |Sponsor:
-+-

Comment (by nickm):

 Sounds like we're in for a few more batches of threading revision before
 merge.  So I'm really asking for review of everything *but* the threading
 code: the crypto needs to be solid, or we absolutely shouldn't merge this
 one.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18483 [Core Tor/Tor]: Clients should always tunnel connections, and never fall back to a DirPort

[Tor Bug Tracker & Wiki]

#18483: Clients should always tunnel connections, and never fall back to a 
DirPort
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:  #18809   |  Actual Points:  2 hours
 Reviewer:  nickm| Points:  small
 |Sponsor:  None
-+-

Comment (by nickm):

 Oh, one last thing: Did you forget to push feature18483-028?  All I see is
 feature18483 and feature18483-cleanup.

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

Re: [tor-bugs] #18962 [Core Tor/Tor]: Merge feature 18483 cleaup commits to master

[Tor Bug Tracker & Wiki]

#18962: Merge feature 18483 cleaup commits to master
---+
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID:  #18483 | Points:  small
 Reviewer:  nickm  |Sponsor:
---+
Changes (by nickm):

 * reviewer:   => nickm


Comment:

 These commits looked okay to me; I reviewed feature18483-cleanup since I
 couldn't find the other branch.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #16861, #17592, #17604

[Tor Bug Tracker & Wiki]

Batch modification to #16861, #17592, #17604 by nickm:


Action: needs_revision

Comment:
My current understanding here is that mike means to revise this branch based on 
other merges we're doing.  Moving these to needs_revision in the meantime.  
Please let me know if I'm incorrect.

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] #18930 [Core Tor/Tor]: Segmentation fault: entry->parsed->intro_nodes

[Tor Bug Tracker & Wiki]

#18930: Segmentation fault: entry->parsed->intro_nodes
-+-
 Reporter:  juha |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_information
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Critical |  0.2.8.x-final
 Keywords:  tor2web, crash, must-fix-|Version:  Tor:
  before-028-rc, TorCoreTeam201605   |  0.2.7.1-alpha
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_information


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

Re: [tor-bugs] #18929 [Core Tor/Tor]: Fix selection of directories with non-preferred address families

[Tor Bug Tracker & Wiki]

#18929: Fix selection of directories with non-preferred address families
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605  |  0.2.8.1-alpha
Parent ID:  #18483   | Resolution:
 Reviewer:  isis,nickm   |  Actual Points:  2 hours
 | Points:  small
 |Sponsor:
-+-
Changes (by nickm):

 * reviewer:  isis => isis,nickm


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

Re: [tor-bugs] #18483 [Core Tor/Tor]: Clients should always tunnel connections, and never fall back to a DirPort

[Tor Bug Tracker & Wiki]

#18483: Clients should always tunnel connections, and never fall back to a 
DirPort
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:  #18809   |  Actual Points:  2 hours
 Reviewer:  nickm| Points:  small
 |Sponsor:  None
-+-
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #18929 [Core Tor/Tor]: Fix selection of directories with non-preferred address families

[Tor Bug Tracker & Wiki]

#18929: Fix selection of directories with non-preferred address families
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605  |  0.2.8.1-alpha
Parent ID:  #18483   | Resolution:
 Reviewer:  isis |  Actual Points:  2 hours
 | Points:  small
 |Sponsor:
-+-

Comment (by nickm):

 Okay, on reading #18483 I see some of my questions answered, but I'd still
 like to know about the other ones above. Also, please make sure I was
 right to strikethrough the strikethroughed item.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18483 [Core Tor/Tor]: Clients should always tunnel connections, and never fall back to a DirPort

[Tor Bug Tracker & Wiki]

#18483: Clients should always tunnel connections, and never fall back to a 
DirPort
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:  #18809   |  Actual Points:  2 hours
 Reviewer:   | Points:  small
 |Sponsor:  None
-+-

Comment (by nickm):

 NOTE to '''nickm''': I'll have to rebase this one last time since I went
 and squashed and merged #18921.  That's on me, though.

 0de9faa402bebc98a58c9f65149e72e598926184:
   * begindir_reason will never be set!  You need to declare the `reason`
 argument in `directory_command_should_use_begindir` as "const char * *",
 not `const char *`.

 Otherwise, this looks good.

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

Re: [tor-bugs] #18929 [Core Tor/Tor]: Fix selection of directories with non-preferred address families

[Tor Bug Tracker & Wiki]

#18929: Fix selection of directories with non-preferred address families
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605  |  0.2.8.1-alpha
Parent ID:  #18483   | Resolution:
 Reviewer:  isis |  Actual Points:  2 hours
 | Points:  small
 |Sponsor:
-+-

Comment (by nickm):

 okay, trying this again!

 First, I'm reviewing the first two commits
 (aaa6ac0a1a94f2cf058c3bb45879c1919889f6df and
 cbb834587b8eed1148125a382891c7f6003ebf60) as one, since they're supposed
 to get squashed eventually.
* This is cosmetic, but I don't understand why
 `router_has_non_preferred_address` takes prefer_ipv6_or as an argument,
 but derives perfer_ipv6_dir for iteslf.
* For router_has_non_preferred_address_node -- an unlisted bridge has a
 node_t, but does not have a routerstatus.  Can this function ever get
 called on a bridge?  Do we care?
* Maybe you now handle this in #18483 or someplace else -- I haven't
 reviewed that yet -- but I'm a little confused about how
 router_has_non_preferred_address* looks at both the ORPort and the
 DirPort, but it doesn't actually take into account whether we're picking a
 directory for a connection where we would absolutely not use the ORPort or
 absolutely not use the DirPort.

 All other patches on this branch look fine to me.

 One last question:

* Would it be even simpler to just omit most of this patch, remove
 `n_not_preferred`, and just do this?
 {{{
  #define RETRY_ALTERNATE_IP_VERSION(retry_label)
 \
STMT_BEGIN
 \
  if (result == NULL && try_ip_pref && options->ClientUseIPv4
 \
  && fascist_firewall_use_ipv6(options) && !server_mode(options)
 \
 -&& n_not_preferred && !n_busy) {
 \
 +&& !n_busy) {
 \
n_excluded = 0;
 \
n_busy = 0;
 \
try_ip_pref = 0;
 \
 -  n_not_preferred = 0;
 \
goto retry_label;
 \
  }
 \
STMT_END
 \
 }}}

 Sure, we would sometimes make two passes needlessly, but not in a common
 case. What do you think?

 Now I'm going to get more tea and read #18483; we'll see how much of this
 I ~~strikethrough~~ once I'm done. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18954 [Internal Services/Service - trac]: Trac should not make request to next/related bug

[Tor Bug Tracker & Wiki]

#18954: Trac should not make request to next/related bug
--+--
 Reporter:  gk|  Owner:  qbi
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:7 bugzilla]:
 > It's the behavior of internal FF's prefetcher that tries to predict the
 "next" your move based on its prediction algorithm which is based on
 history of your navigation.
 You're talking out of your ass. Stop it. Kthx.

 gk, qbi:
 What you are seeing here is default Trac behaviour (at least in branch
 1.0, the one I looked at), not particular to this instance.

 Trac is setting a few `` elements with a `rel` type related to
 'sequential navigation' (or something). Looking
 [https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types here] you'll
 find: 'index', 'up', 'first', 'last', 'prev', and 'next'. (Plus non-
 standard synonyms.) According to that page, all except 'prev' and 'next'
 have been obsoleted.

 Except for 'index' I've seen Trac set all of these. According to the
 source, they are used in various components, not just tickets. (Actually,
 it seems there's a little bug in Trac: it uses both 'first' and 'start',
 an incorrect synonymous for 'first', with different targets. I looked at
 trunk and it's still there.)

 When Firefox sees 'next' (or 'prefetch') ``s, prefetching kicks in,
 if not disabled. Is not clear to me if the Trac developers had prefetching
 in mind when coding this.

 The 'sequence' Trac thinks of, in the case of tickets, is the global list
 of tickets (all in the db) or those produced by the 'context query', if
 Trac can find one. This 'context query' appears to be some query
 associated with the value of a cookie (maybe the session cookie itself?).

 So, if Trac can't associate the ticket view request with a context query,
 'next' ends up being the next ticket number available in the database.
 Otherwise, 'next' is the next ticket among the results of said query.

 Some of the mentioned links are in fact clickable. If you look right below
 the main navigation bar, in a ticket view, you'll see the 'Context
 navigation' (disable CSS and it willl be obvious): `prev | up (*) | next`.
 (*) 'up' might be missing. It will be present if there's a context query:
 e.g. 'Back to Query'.

 For the implementation see (search for functions `add_link` and
 `add_ticket_link`):
 * trac/web/chrome.py
 * trac/ticket/web_ui.py
 For the HTML see (search for `chrome.links`):
 * trac/templates/layout.html (``)
 * trac/templates/macros.html (``)

 Replying to [comment:5 gk]:
 > Oh, and the prefetched resources aren't even cached in Tor Browser. So,
 basically, this only results in unnecessary overhead.

 This seems like a good argument for disabling prefetching in Tor Browser,
 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] #18954 [Internal Services/Service - trac]: Trac should not make request to next/related bug

[Tor Bug Tracker & Wiki]

#18954: Trac should not make request to next/related bug
--+--
 Reporter:  gk|  Owner:  qbi
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:7 bugzilla]:
 > Replying to [comment:4 gk]:
 > > I understand that this is prefetch related but that ticket is not
 something about flipping the related pref or not. Rather, about the
 behavior of our Trac instance, see comment:2
 > What do you want from Trac?
 > It's the behavior of internal FF's prefetcher that tries to predict the
 "next" your move based on its prediction algorithm which is based on
 history of your navigation.

 No. Take a fresh new Tor Browser and you'll see the same. Reading up on
 how link prefetching works would explain you why this is the case.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:16 bugzilla]:
 > Huh, of course, you can be sure you've fixed a bug without STR if you
 know what you're doing. Just reading the code and understanding the
 processes are enough to search, localize and fix the bugs. E.g. see
 https://mxr.mozilla.org/mozilla-esr45/source/configure.in#5448. Do you see
 that {{{-DPIC}}} is missing? So much time passed, so much testing
 passed... Where are the tickets? And what kind should they be? Just
 reports of random crashes in non-related tickets, and you've written that
 it's your preferred option... OK, if so, please, post here how you can do
 things like that, based on this example: how you do search in Bugzilla
 (criteria), how you detect that found tickets are caused by -DPIC
 underlying problem, and, of course, your STR for this issue! (And who told
 you that every bug had STR...)

 I think you misunderstood me. I was talking about STR in this context:
 crashes on closed source software which oneself cannot reproduce. Even if
 I think I have a fix and give it to a user to test she/he needs to have
 some steps to say, "Yes, it works" or "No, it does not work".

 I closed this ticket as duplicate because this seemed to be mainly about
 EMET.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18921 [Core Tor/Tor]: Fix IPv6 bridge client directory address selection

[Tor Bug Tracker & Wiki]

#18921: Fix IPv6 bridge client directory address selection
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Normal   |Version:  Tor:
 Keywords:  must-fix-before-028-rc,  |  0.2.8.1-alpha
  TorCoreTeam201605, TorCoreTeam-| Resolution:  fixed
  postponed-201604   |  Actual Points:  1 hour
Parent ID:  #18483   | Points:  small
 Reviewer:  isis |Sponsor:
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #18921 [Core Tor/Tor]: Fix IPv6 bridge client directory address selection

[Tor Bug Tracker & Wiki]

#18921: Fix IPv6 bridge client directory address selection
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604   | Resolution:
Parent ID:  #18483   |  Actual Points:  1 hour
 Reviewer:  isis | Points:  small
 |Sponsor:
-+-

Comment (by nickm):

 Okay, this is much easier to review.  Thanks!

 This looks right to me.  I'm squashing and merging it in 0.2.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] #18312 [Core Tor/Tor]: MapAddress should recommend fingerprints, not nicknames

[Tor Bug Tracker & Wiki]

#18312: MapAddress should recommend fingerprints, not nicknames
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
Component:  Core Tor/Tor   |  0.2.8.x-final
 Severity:  Normal |Version:
 Keywords:  easy, docs, TorCoreTeam201605  | Resolution:  fixed
Parent ID: |  Actual Points:  very small
 Reviewer: | Points:  very small
   |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Since it only touches the docs, and since it's only two lines, I re-
 reviewed myself and merged it to 0.2.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] #18768 [Metrics/Analysis]: Calculate the fraction of dist.torproject.org traffic for Tor Browser downloads and updates

[Tor Bug Tracker & Wiki]

#18768: Calculate the fraction of dist.torproject.org traffic for Tor Browser
downloads and updates
--+-
 Reporter:  karsten   |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by karsten):

 Here's a new row for `/update_2/` which contains almost all of those 38%
 of requests that were previously contained in the "other" row and an
 additional column with the mean number of bytes per request:

 ||=Pattern =||= Number of Bytes=||= Fraction of Bytes=||= Number of
 Requests=||= Fraction of Requests=||= Mean Number of Bytes per Request=||
 ||`\.exe$` || 62650080788327|| 55%|| 2360824|| 3%|| 25 MiB||
 ||`\.tar\.xz$` || 12497704216145|| 11%|| 227004|| 0%|| 53 MiB||
 ||`\.dmg$` || 8352205765328|| 7%|| 156397|| 0%|| 51 MiB||
 ||`\.mar$` || 29958084372393|| 26%|| 43530110|| 58%|| 672 KiB||
 ||`/update_2/` || 2930515856|| 0%|| 28256673|| 38%|| 103 B||
 ||other || 228397786432|| 0%|| 265993|| 0%|| 839 KiB||
 ||total || 11368940381|| 100%|| 74797001|| 100%|| 1 MiB||

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18686 [Core Tor/Tor]: tor port forwarding claims to kill long-dead forwarder

[Tor Bug Tracker & Wiki]

#18686: tor port forwarding claims to kill long-dead forwarder
--+
 Reporter:  chadmiller|  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.7.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.6
 Severity:  Major | Resolution:
 Keywords:  027-backport  |  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  TorCoreTeam201605 => 027-backport
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.7.x-final


Comment:

 I think a comment change would cover that then.  We just document that
 tor_terminate_process means "kill the process if it has not already
 exited."  One way to succeed at that is to do nothing, because it already
 exited.

 I've taken that approach (better documenting what we do) in branch
 `bug18686_025`, which I've merged to 0.2.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] #18733 [Metrics/CollecTor]: contributor's guide incl. coding guidelines for java projects

[Tor Bug Tracker & Wiki]

#18733: contributor's guide incl. coding guidelines for java projects
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID:  #18730 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Replying to [comment:5 karsten]:
 > I think I agree with that ordering, but let me give an example and hear
 from you whether that's what you had in mind:
 >
 > {{{
 > class A {
 >   int a;
 >   int b;
 >   void m() {
 > n();
 > p();
 >   }
 >   void n() {
 > o();
 >   }
 >   void o() {}
 >   void p() {}
 > }
 > }}}
 >
 > Your preference is to put `o()` above of `p()`, because `o()` is the
 lower-level function that gets called in `n()`?  Hmm, or would `p()` go
 first, because it's a lower-level function called in `m()`?
 >
 That is a tricky question :-)
 but the solution listed above looks ok.
 Imagine, we're reading source code (on a remote server using) `less` or
 similar:
  When reading `m()` and then trying to find out what `n()` does, it'll be
 good to have `o()` immediately below `n()`.
  Whereas, when we want to find out what `p()` is about we scroll down and
 read `p()`'s declaration.
  Even if `p()` would use `o()`, too, that's ok, b/c we scrolled by `o()`'s
 declaration already, or read it while finding out about `n()`.

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

Re: [tor-bugs] #18952 [Applications/Tor Browser]: Tor Browser without Tor

[Tor Bug Tracker & Wiki]

#18952: Tor Browser without Tor
--+-
 Reporter:  cypherpunks   |  Owner:  cypherpunks
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Where has Transparent Torification gone?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
+
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  must-fix-before-028-rc  |  Actual Points:
Parent ID:  | Points:  small
 Reviewer:  nickm   |Sponsor:
+
Changes (by nickm):

 * reviewer:   => nickm


Comment:

 f2e9af1b859287d24201a65213ab6ad5362e9c99 --
   * looks fine, though the comment was a little unclear to me.  I'll fix
 that though.  '''nickm''' -- clarify the comment on
 download_status_cert_init to clarify that download_status_cert_init() is
 _not_ okay to call after the first failure has occurred.

 87fdbb6 and bea0819 --
   * I'm not sure about these, because they bring back the presence of
 authorities as client enumerators.  With these patches, since every
 fallback will go down _sometimes_, every client will try an authority
 _sometimes_, and the authorities will still be able to enumerate them.
 What if, as an alternative solution, we just use a sdifferent schedule for
 certificate downloads?   Are they still really necessary with f2e9af1 ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18389 [Applications/Tor Messenger]: Support CAPTCHA-authorization

[Tor Bug Tracker & Wiki]

#18389: Support CAPTCHA-authorization
+--
 Reporter:  WitnessofTruth  |  Owner:  sukhbir
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by clokep):

 * cc: tor@… (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] #18861 [Metrics/metrics-lib]: start thinking about using java8

[Tor Bug Tracker & Wiki]

#18861: start thinking about using java8
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 Oh, you're right. Sorry, I was so happy to see java8 finally in Debian
 that I overlook the backports entry in sources.list.

 Hope this doesn't totally out-rule thinking about it here?

 At least backports is a debian service just for this purpose.
 Quote from [https://wiki.debian.org/Backports debian]:

 > You are running [https://wiki.debian.org/DebianStable Debian stable]
 because you prefer the stable Debian tree. It runs great, there is just
 one problem: The software is a little bit outdated compared to other
 distributions. That is where backports come in.


 
 What about the benchmark-source-code? Shouldn't it be added somewhere to
 the metrics-lib repo?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed   |  0.2.8.1-alpha
Parent ID:  #18816   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by nickm):

 Did you forget to push that branch? I don't see it on your github repo; I
 only see the bug19683 branch that you say not to merge.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18710 [Core Tor/Tor]: dnsserv.c asserts when no supported questions are requested

[Tor Bug Tracker & Wiki]

#18710: dnsserv.c asserts when no supported questions are requested
-+-
 Reporter:  geekmug  |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Major|  0.2.7.x-final
 Keywords:  dns, dnsport, tor-client |Version:  Tor:
  027-backport   |  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:  small
 | Points:  very
 |  small
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:  dns, dnsport, tor-client, must-fix-before-028-rc,
 TorCoreTeam201605 => dns, dnsport, tor-client 027-backport
 * actualpoints:   => small
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.7.x-final


Comment:

 okay, the analysis does look right.  Merging your fix to 0.2.8 and
 forward; marking this ticket for possible backport.  (If we backport, I've
 got the fix with a changes file in my branch `bug18710_025` .)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 Oh, and you haven't answered the main question: why did you close this
 ticket about MS & related bugs as a dupe of TBB's vulnerability one?
 Bug in comment:8 is still actual (and, yes, without EMET), but what about
 STR? It happens sometimes with STR in comment:7, sometimes even when JS
 off, and even when Trac is updating the writing of this comment! What to
 do with 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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 Huh, of course, you can be sure you've fixed a bug without STR if you know
 what you're doing. Just reading the code and understanding the processes
 are enough to search, localize and fix the bugs. E.g. see
 https://mxr.mozilla.org/mozilla-esr45/source/configure.in#5448. Do you see
 that {{{-DPIC}}} is missing? So much time passed, so much testing
 passed... Where are the tickets? And what kind should they be? Just
 reports of random crashes in non-related tickets, and you've written that
 it's your preferred option... OK, if so, please, post here how you can do
 things like that, based on this example: how you do search in Bugzilla
 (criteria), how you detect that found tickets are caused by -DPIC
 underlying problem, and, of course, your STR for this issue! (And who told
 you that every bug had STR...)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18895 [Core Tor/Tor]: --enable-expensive-hardening has hard-to-debug failures when run-time libraries aren't installed

[Tor Bug Tracker & Wiki]

#18895: --enable-expensive-hardening has hard-to-debug failures when run-time
libraries aren't installed
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:  SponsorS-can
--+
Changes (by nickm):

 * keywords:  029-proposed, 029-nickm-unsure =>
 * milestone:   => Tor: 0.2.9.x-final


Comment:

 Including this in 0.2.9, since it won't be too hard.  BUT I must remember
 not to work on it till my ftrapv/fwrapv branch is merged, since that
 branch touches this code too.

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

Re: [tor-bugs] #18909 [Core Tor/Tor]: Is time-caching necessary in tor_gettimeofday_cached_monotonic?

[Tor Bug Tracker & Wiki]

#18909: Is time-caching necessary in tor_gettimeofday_cached_monotonic?
+---
 Reporter:  nickm   |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  029-proposed, 029-nickm-unsure  |  Actual Points:
Parent ID:  | Points:  small
 Reviewer:  |Sponsor:
+---

Comment (by nickm):

 Poor performance of non-VDSO time means that we're likely to be able to do
 this only on some systems OR do it only for cases where higher-accuracy
 time is worth paying for.

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

Re: [tor-bugs] #18938 [Core Tor/Tor]: Authorities should reject non-ASCII content in ExtraInfo descriptors

[Tor Bug Tracker & Wiki]

#18938: Authorities should reject non-ASCII content in ExtraInfo descriptors
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  needs-proposal-maybe  |  Actual Points:
Parent ID:  #18656| Points:  small
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  029-proposed, needs-proposal-maybe, 029-nickm-unsure => needs-
 proposal-maybe
 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.x-final


Comment:

 Minimal alternative: Authorities just start rejecting these when they are
 uploaded to the authorities.

 (We have to make sure that if you're an authority who rejects these
 descriptors, you won't go crazy re-fetching them if other authorities list
 them.  But I think we fixed that 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] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
+
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  must-fix-before-028-rc  |  Actual Points:
Parent ID:  | Points:  small
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * keywords:  029-proposed, 029-nickm-unsure, must-fix-before-028-rc =>
 must-fix-before-028-rc


Comment:

 Since this is now with-code in 0.2.8, I'm yanking it out of 029-proposed
 entirely.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13953 [Core Tor/Tor]: Self-test reachability test - Listen address from ORPort is ignored, it uses default address unless specified via Address argument

[Tor Bug Tracker & Wiki]

#13953: Self-test reachability test - Listen address from ORPort is ignored, it
uses default address unless specified via Address argument
--+
 Reporter:  s7r   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.10
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #17782| Points:  medium
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.x-final


Old description:

> Tor: 0.2.5.10
> OS: Debian Wheezy 64 bit
> Installation: apt-get from deb.torproject.org
>
> Configuration of server (one gigabit network card):
> em0: IP1
> em0:0 IP2
> em0:1 IP3
> em0:2 IP4
> em0:3 IP5
>
> I tried to run multiple Tor instances to saturate the CPU of the server.
> I configured instances with different pid, datadirecotry and logfile as
> manual recommends, and specified the different IP as follows in each
> config file:
>
> tor1.cfg
> ORPort IP1:port
> DirPort IP1:port
> OutboundBindAddress IP1
>
> tor2.cfg
> ORPort IP2:port
> DirPort IP2:port
> OutboundBindAddress IP2
>
> etc. so on
>
> The first Tor instance started just fine, but the following ones didn't
> publish server descriptor because self reachability test did not pass.
> Why? They were all thinking they should be reachable on IP1 (default IP,
> em0 interface). Obviously that IP did not had the requried ports open for
> the additonal Tor instances so the test could not possibly pass.
>
> Fix:
> I have added in each config file:
> Address IP1
> Address IP2 and so on
>
> After that it did the self reachability test on the correct IP address,
> and it passed of course, so server descriptor was published.
>
> Tor should know to prase the IP address from ORPort and/or DirPort and
> make tests on that, obviously that's the address where the port should be
> open. Caution at -noadvertise and -nolisten options when this bug is
> inspected.

New description:

 Tor: 0.2.5.10
 OS: Debian Wheezy 64 bit
 Installation: apt-get from deb.torproject.org

 Configuration of server (one gigabit network card):
 em0: IP1
 em0:0 IP2
 em0:1 IP3
 em0:2 IP4
 em0:3 IP5

 I tried to run multiple Tor instances to saturate the CPU of the server. I
 configured instances with different pid, datadirecotry and logfile as
 manual recommends, and specified the different IP as follows in each
 config file:

 tor1.cfg
 ORPort IP1:port
 DirPort IP1:port
 OutboundBindAddress IP1

 tor2.cfg
 ORPort IP2:port
 DirPort IP2:port
 OutboundBindAddress IP2

 etc. so on

 The first Tor instance started just fine, but the following ones didn't
 publish server descriptor because self reachability test did not pass.
 Why? They were all thinking they should be reachable on IP1 (def spend a
 huge amount of time on this.ault IP, em0 interface). Obviously that IP did
 not had the requried ports open for the additonal Tor instances so the
 test could not possibly pass.

 Fix:
 I have added in each config file:
 Address IP1
 Address IP2 and so on

 After that it did the self reachability test on the correct IP address,
 and it passed of course, so server descriptor was published.

 Tor should know to prase the IP address from ORPort and/or DirPort and
 make tests on that, obviously that's the address where the port should be
 open. Caution at -noadvertise and -nolisten options when this bug is
 inspected.

--

Comment:

 Oh wait, teor said he thinks this one should go in, and that the code to
 detect a mismatch and warn will be simple.

 If it's really a simple solution, let's do that in 0.2.9, but let's watch
 out for scope-creep.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17901 [Core Tor/Tor]: Tor would bind ControlPort to public ip address if it has no localhost interface

[Tor Bug Tracker & Wiki]

#17901: Tor would bind ControlPort to public ip address if it has no localhost
interface
--+
 Reporter:  s7r   |  Owner:  teor
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.10
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.x-final


Comment:

 Oh, wait, teor  said he thinks this should go in.

 I think we can take it if we do the a simple version where we exit if you
 don't have `lo`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #17901, #13953, #18840, #18852

[Tor Bug Tracker & Wiki]

Batch modification to #17901, #13953, #18840, #18852 by nickm:
keywords to 029-proposed 029-nickm-says-no

Comment:
Nobody objected to these, so they aren't going into 029 milestone. Please 
re-add 029-proposed if you disagree, and let me know why.

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #16702, #18857, #18888, #18889, #18897, #18901, #18906, #18907, #18934, #18839

[Tor Bug Tracker & Wiki]

Batch modification to #16702, #18857, #1, #18889, #18897, #18901, #18906, 
#18907, #18934, #18839 by nickm:
keywords to 029-proposed 029-nickm-says-yes
milestone to Tor: 0.2.9.x-final

Comment:
Nobody objected to including any of these, so I guess they are in.

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] #18719 [Metrics/CollecTor]: provide executable jar

[Tor Bug Tracker & Wiki]

#18719: provide executable jar
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Great, merged to master!

 In the future, consider pushing your changes to a separate task branch,
 like task-18719 (or whatever naming scheme you prefer).  The downsides of
 using your master branch is that it may derive from the official master
 and that you can only have one change under review.

 Closing this ticket as implemented.  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] #18483 [Core Tor/Tor]: Clients should always tunnel connections, and never fall back to a DirPort

[Tor Bug Tracker & Wiki]

#18483: Clients should always tunnel connections, and never fall back to a 
DirPort
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:
  TorCoreTeam201605  | Resolution:
Parent ID:  #18809   |  Actual Points:  2 hours
 Reviewer:   | Points:  small
 |Sponsor:  None
-+-
Changes (by bugzilla):

 * keywords:  must-fix-before-028-rc, CoreTorTeam201605 => must-fix-
 before-028-rc, TorCoreTeam201605


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18929 [Core Tor/Tor]: Fix selection of directories with non-preferred address families

[Tor Bug Tracker & Wiki]

#18929: Fix selection of directories with non-preferred address families
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605  |  0.2.8.1-alpha
Parent ID:  #18483   | Resolution:
 Reviewer:  isis |  Actual Points:  2 hours
 | Points:  small
 |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:  must-fix-before-028-rc, CoreTorTeam201605, TorCoreTeam201605
 => must-fix-before-028-rc, TorCoreTeam201605


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18930 [Core Tor/Tor]: Segmentation fault: entry->parsed->intro_nodes

[Tor Bug Tracker & Wiki]

#18930: Segmentation fault: entry->parsed->intro_nodes
-+-
 Reporter:  juha |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Critical |Version:  Tor:
 Keywords:  tor2web, crash, must-fix-|  0.2.7.1-alpha
  before-028-rc, TorCoreTeam201605   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:  small
 |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:
 tor2web, crash, CoreTorTeam201605, must-fix-before-028-rc,
 TorCoreTeam201605
 => tor2web, crash, must-fix-before-028-rc, TorCoreTeam201605


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 I am not sure I understand the latter question. How can you be sure you
 fixed a bug without having steps to reproduce it? I prefer a new ticket
 for each crash which is not a duplicate and not caused by the same
 underlying problem, yes. Otherwise I can't work on it properly, like
 investigating and closing the case.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18703 [Applications/Tor Browser]: Videos loaded via the Page Info dialog are going over the catch-all circuit

[Tor Bug Tracker & Wiki]

#18703: Videos loaded via the Page Info dialog are going over the catch-all 
circuit
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-linkability, | Resolution:  fixed
  TorBrowserTeam201605R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good to me, thanks! Fixed in commit
 ac739a883c7960eda72ce71e82e8b3f704381c4d on tor-browser-45.1.0esr-6.0-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] #18947 [Applications/Tor Browser]: 6.0a5 is not starting on OS X if put into /Applications

[Tor Bug Tracker & Wiki]

#18947: 6.0a5 is not starting on OS X if put into /Applications
--+---
 Reporter:  gk|  Owner:  mcs
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201605  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 I had an idea that a difference might be that some people are running with
 a "Standard" account (vs. an "Admin" account). But using a Standard
 account did not allow me to reproduce the problem.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18962 [Core Tor/Tor]: Merge feature 18483 cleaup commits to master

[Tor Bug Tracker & Wiki]

#18962: Merge feature 18483 cleaup commits to master
---+
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:
Parent ID:  #18483 | Points:  small
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * keywords:  CoreTorTeam201605 => TorCoreTeam201605


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18962 [Core Tor/Tor]: Merge feature 18483 cleaup commits to master

[Tor Bug Tracker & Wiki]

#18962: Merge feature 18483 cleaup commits to master
---+
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  CoreTorTeam201605  |  Actual Points:
Parent ID:  #18483 | Points:  small
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * 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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 This ticket was filed as a tracking bug for all issues on Windows, because
 of its crappy new updates. You need both 32 and 64 bit Windows test
 machines to discover them. They appear so often that it's boring to re-
 login and write comments... And it's not proved that it's because of EMET.
 So, your decision looks strangely...
 Do you prefer a new ticket for each crash? And how can it be, in general,
 that stack overflows have STR?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16794 [Core Tor/Tor]: All cryptography unit test coverage should be over 95%; all should have test vectors

[Tor Bug Tracker & Wiki]

#16794: All cryptography unit test coverage should be over 95%; all should have
test vectors
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  testing, 028-triage, tor-tests-  |Version:
  coverage, tor-tests-unit, TorCoreTeam201605| Resolution:
Parent ID:  #16791   |  Actual Points:
 Reviewer:   | Points:  medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 Now I see 95.32%.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18734 [Metrics/CollecTor]: Installation Guide for Operators

[Tor Bug Tracker & Wiki]

#18734: Installation Guide for Operators
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by iwakeh):

 The new url for the
 [https://gitweb.torproject.org/collector.git/tree/INSTALL.md existing
 document] (the one listed in the description above is broken).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17101 [Core Tor/Tor]: Tests for connection_ap_handshake_rewrite_and_attach

[Tor Bug Tracker & Wiki]

#17101: Tests for connection_ap_handshake_rewrite_and_attach
-+-
 Reporter:  ipazmino |  Owner:
 Type:  defect   |  ipazmino
 Priority:  Medium   | Status:
Component:  Core Tor/Tor |  needs_revision
 Severity:  Normal   |  Milestone:  Tor:
 Keywords:  coverage, merge-ready, tor-tests-|  0.2.9.x-final
  coverage, tor-tests-unit, TorCoreTeam201605,   |Version:
  TorCoreTeam-postponed-201604   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:  asn  | Points:  medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hello,

 thanks for the code! Here is an initial review:

 - It seems like branch `connection_edge_handshake_tests` has the master
 branch '''merged into it''', instead of it being '''rebased''' on top of
 the master branch. This will not apply cleanly on top of upstream master.
 I'd suggest you start with the master branch and then apply your changes
 on top of it. Or git-rebase master on top of your changes.

 - The
 `conn_edge_ap_handshake/rewrite_and_attach_closes_conn_for_excluded_exit`
 test seems to crash as follows:
 {{{
 May 04 16:33:06.300 [err] tor_assertion_failed_(): Bug:
 src/common/container.c:1410: strmap_set: Assertion val failed; aborting.
 (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: Assertion val failed in strmap_set at
 src/common/container.c:1410. Stack trace: (on Tor 0.2.8.1-alpha-dev
 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(log_backtrace+0x52)
 [0x7fc4dd28a1c2] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug:
 ./src/test/test(tor_assertion_failed_+0xa4) [0x7fc4dd29eaa4] (on Tor
 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(strmap_set+0x197)
 [0x7fc4dd296fd7] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(+0x204ab9)
 [0x7fc4dcf25ab9] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(+0x3b87fa)
 [0x7fc4dd0d97fa] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(testcase_run_one+0x165)
 [0x7fc4dd0d99c5] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(tinytest_main+0x11e)
 [0x7fc4dd0da11e] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(main+0x347)
 [0x7fc4dcddb8c7] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf5) [0x7fc4db593b45] (on Tor 0.2.8.1
 -alpha-dev 9c6a817c53093831)
 May 04 16:33:06.300 [err] Bug: ./src/test/test(+0xbc0c2)
 [0x7fc4dcddd0c2] (on Tor 0.2.8.1-alpha-dev 9c6a817c53093831)
 }}}

   The `strmap_set()` call seems to be the offending call here. Also what
 does:
   {{{  routerset_t *excluded_nodes = excluded_nodes = routerset_new()}}}
 do?
   Let me know if you can't reproduce this and you need help debugging this
 further.

 - There seem to be some unnecessary whitespace changes in
 `src/test/include.am`.

 - There seem to be some printf calls left over in the tests.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18905 [Applications/Tor Browser]: Remove unused menu items from Tor Browser help menu

[Tor Bug Tracker & Wiki]

#18905: Remove unused menu items from Tor Browser help menu
+--
 Reporter:  arthuredelstein |  Owner:
 Type:  defect  |  arthuredelstein
 Priority:  Medium  | Status:  closed
Component:  Applications/Tor Browser|  Milestone:
 Severity:  Normal  |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605  | Resolution:  fixed
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--
Changes (by gk):

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


Comment:

 Looks good now and is applied to master as commit
 b72f495c9593bb7df8fab34b642325c22e4e7393, 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] #18902 [Core Tor/Tor]: Avoid variable shadowing in Tor

[Tor Bug Tracker & Wiki]

#18902: Avoid variable shadowing in Tor
---+--
 Reporter:  teor   |  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy refactor  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by nickm):

 Suggestion 1: Think about reviewability as you go. I can easily see this
 patch becoming huge.

 Suggestion 2: Think about automation wherever possible. This test is
 mostly automatable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18902 [Core Tor/Tor]: Avoid variable shadowing in Tor

[Tor Bug Tracker & Wiki]

#18902: Avoid variable shadowing in Tor
---+--
 Reporter:  teor   |  Owner:  cypherpunks
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy refactor  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * owner:   => cypherpunks
 * status:  new => assigned


Comment:

 Working on patches. A quick look at the result of enabling `-Wshadow`
 showed tons of warnings so it's going to take some time to fix every
 instance without breaking other 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] #18961 [Core Tor/Tor]: tor_bug_occurred_(): Bug: ../src/or/dnsserv.c:298

[Tor Bug Tracker & Wiki]

#18961: tor_bug_occurred_(): Bug: ../src/or/dnsserv.c:298
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  029-proposed dnsserv  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by nickm):

 * keywords:   => 029-proposed dnsserv
 * severity:  Normal => Minor


Comment:

 Proposing that we look at this for 0.2.9; also proposing that we assign it
 a "minor" priority: this is not actually causing a problem; it's just
 hitting a "tor_fragile_assert()" line.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18965 [Applications/Tor Browser]: Zoom sets to 124% after minimalizing and maximalizing

[Tor Bug Tracker & Wiki]

#18965: Zoom sets to 124% after minimalizing and maximalizing
--+---
 Reporter:  zielony   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 Seems related to
 https://trac.torproject.org/projects/tor/ticket/18937#comment:30.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18937 [Applications/Tor Browser]: What's new (bugs) in Tor Browser 6.0a5 -- April 28 2016

[Tor Bug Tracker & Wiki]

#18937: What's new (bugs) in Tor Browser 6.0a5 -- April 28 2016
--+--
 Reporter:  bugzilla  |  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:
--+--

Comment (by bugzilla):

 Update for
 https://trac.torproject.org/projects/tor/ticket/18678#comment:2:
 TBB stops to steal 1 px. But awful zooming in F11. Still different zoom
 modes on different tabs - seems that only active tab and the others with
 the same site are re-zoomed while switching modes or something like
 this... Some tabs retain the zoom level after maximizing...
 The results page on ip-check.info with Browser window size could help as
 it is updating real-time. But Zoom in hamburger menu moved to toolbar next
 to search-bar lies about the zoom :(

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18719 [Metrics/CollecTor]: provide executable jar

[Tor Bug Tracker & Wiki]

#18719: provide executable jar
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Here's the patch:
 
https://gitweb.torproject.org/user/iwakeh/collector.git/patch/?id=2be9f6890af28bcb78d29fb00eb66b8cd8edf9c2

 Finally :-)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18967 [Metrics/Onionoo]: Add UUID to families in Onionoo

[Tor Bug Tracker & Wiki]

#18967: Add UUID to families in Onionoo
-+--
 Reporter:  seansaito|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:  persistence,
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This is an enhancement of the implementation proposed in #16599.

 Some services that depend onOnionoorequire persistence in family data. For
 instance, some of the proposed features of Roster such as replacing Tor
 Weather require knowing when a certain relay goes down. Analogous to Tor
 spec proposal #242,Onionoo should implement such a scheme.

 Put simply, the implementation would be as follows:

  * Each family will have some UUID, which would be tagged on all member
 relays (like an extra fingerprint).
  * A new relay will be tagged by its family's UUID by looking up the ID of
 older relatives.
  * There are two schemes for storing key-value based data. One is for
 looking up families via UUID, the other for looking up a UUID via relay
 fingerprint.

 Unlike #16599, this implementation does not require any a priori
 information about the family. The UUIDs are guaranteed to be unique.
 Currently, Roster has a half-baked implementation of the above. Despite
 the simplicity of the implementation, the benefits are potentially great,
 as querying for and storing persistent data of families would become
 possible.

 [1] https://trac.torproject.org/projects/tor/ticket/16599

 [2] https://gitweb.torproject.org/torspec.git/tree/proposals/242-better-
 families.txt

 On uniqueness of UUIDs

 [3] https://stackoverflow.com/questions/703035/when-are-you-truly-forced-
 to-use-uuid-as-part-of-the-design/786541#786541

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 Priority:  High |  needs_revision
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  tbb-security, tbb-crash, tbb-| Resolution:
  usability-stoppoint-app, fuck-mingw-gcc,   |  Actual Points:
  TorBrowserTeam201605, GeorgKoppen201605| Points:
Parent ID:  #12820   |Sponsor:
 Reviewer:   |  SponsorU
-+-
Changes (by gk):

 * cc: bugzilla (added)


Comment:

 Resolved #18935 as duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  needs_information => closed
 * resolution:   => duplicate


Comment:

 Replying to [comment:12 bugzilla]:
 > Replying to [comment:11 gk]:
 > > Replying to [comment:9 bugzilla]:
 > > > Well, fully updated system with EAF disabled brought us to:
 > > > {{{
 > > > Faulting application name: firefox.exe, version: 45.1.0.0, time
 stamp: 0x
 > > > Faulting module name: xul.dll, version: 45.1.0.0, time stamp:
 0x
 > > > Exception code: 0xc005
 > > > Fault offset: 0x0003fb34
 > > > }}}
 > > > Seems opening a lot of Trac tickets in the background is a good
 stress-test.
 > >
 > > Seems to work for me on an up-to-date Win 7 system. I bookmarked 20
 trac tickets and opened them at the same time. Everything still worked. Do
 you have more detailed steps to reproduce the crashes?
 > >
 > > At a more generic level: What are we supposed to do with this ticket
 and the numerous issues you mentioned? How is this still actionable?
 > You installed the latest EMET on an up-to-date Win 7, selected Max Sec,
 copied the ruleset for FF to TB's firefox.exe, disabled EAF in it,
 selected Audit Mode (or welcome SimExecFlow
 https://trac.torproject.org/projects/tor/ticket/13893#comment:56), and
 restarted the system. Then you did STR, right?

 Actually, no. I assumed as done in other comments in this ticket this was
 without EMET. So, I am marking this a duplicate of the EMET ticket
 (#13893). Please, file separate bugs for the other crashes making sure
 they are no duplicate. Having steps to reproduce them would rock.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18937 [Applications/Tor Browser]: What's new (bugs) in Tor Browser 6.0a5 -- April 28 2016

[Tor Bug Tracker & Wiki]

#18937: What's new (bugs) in Tor Browser 6.0a5 -- April 28 2016
--+--
 Reporter:  bugzilla  |  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:
--+--

Comment (by bugzilla):

 Surprise with resolution :) Like in
 https://trac.torproject.org/projects/tor/ticket/14429#comment:22
 STR: Click Customize in hamburger menu. Click Title Bar twice, exit
 Customize. Surprise!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18861 [Metrics/metrics-lib]: start thinking about using java8

[Tor Bug Tracker & Wiki]

#18861: start thinking about using java8
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Hmm, are you sure that OpenJDK 8 is available in Debian stable?

 https://packages.debian.org/search?keywords=openjdk-8-jre

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 Replying to [comment:11 gk]:
 > Replying to [comment:9 bugzilla]:
 > > Well, fully updated system with EAF disabled brought us to:
 > > {{{
 > > Faulting application name: firefox.exe, version: 45.1.0.0, time stamp:
 0x
 > > Faulting module name: xul.dll, version: 45.1.0.0, time stamp:
 0x
 > > Exception code: 0xc005
 > > Fault offset: 0x0003fb34
 > > }}}
 > > Seems opening a lot of Trac tickets in the background is a good
 stress-test.
 >
 > Seems to work for me on an up-to-date Win 7 system. I bookmarked 20 trac
 tickets and opened them at the same time. Everything still worked. Do you
 have more detailed steps to reproduce the crashes?
 >
 > At a more generic level: What are we supposed to do with this ticket and
 the numerous issues you mentioned? How is this still actionable?
 You installed the latest EMET on an up-to-date Win 7, selected Max Sec,
 copied the ruleset for FF to TB's firefox.exe, disabled EAF in it,
 selected Audit Mode (or welcome SimExecFlow
 https://trac.torproject.org/projects/tor/ticket/13893#comment:56), and
 restarted the system. Then you did STR, right?

 At generic: this ticket is a general warning for users of TBB on Windows
 that shows what is happening in various situations if they do or don't
 install or install partially the latest updates from MS, install EMET,
 etc. Also it is a recycle bin for all TBB crashes on Windows that users
 can report into. And if somebody has a free time and willing to
 investigate some he is welcome.

 TBB Team: it's not worth effort to dig the MS crap.
 0xc005 = ACCESS_VIOLATION or SIGSEGV or GPF - it could be anything...
 0xc0fd = STACK_OVERFLOW - it seems to be the thing you've discovered
 on hardened...
 And your CYGWIN WIN 6.3 x64 test machine is affected with vulnerable
 ntdll.dll
 That's 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] #18954 [Internal Services/Service - trac]: Trac should not make request to next/related bug

[Tor Bug Tracker & Wiki]

#18954: Trac should not make request to next/related bug
--+--
 Reporter:  gk|  Owner:  qbi
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [comment:4 gk]:
 > I understand that this is prefetch related but that ticket is not
 something about flipping the related pref or not. Rather, about the
 behavior of our Trac instance, see comment:2
 What do you want from Trac?
 It's the behavior of internal FF's prefetcher that tries to predict the
 "next" your move based on its prediction algorithm which is based on
 history of your navigation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #11179 [Core Tor/Tor]: Combine setevents circ and stream

[Tor Bug Tracker & Wiki]

#11179: Combine setevents circ and stream
-+-
 Reporter:  grarpamp |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  unspecified
 Severity:  Normal   |Version:  Tor:
 Keywords:  tor-client controller needs- |  0.2.4.21
  proposal   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by arma):

 * severity:   => Normal


Comment:

 I wonder if the stem library could do what you want here, e.g. by
 reconstructing what happened from an event log, and telling you the things
 you wanted to know?

 I suggest it because there doesn't seem to be any motion toward putting
 this new feature into Tor, and maybe it's best solved externally.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18965 [Applications/Tor Browser]: Zoom sets to 124% after minimalizing and maximalizing

[Tor Bug Tracker & Wiki]

#18965: Zoom sets to 124% after minimalizing and maximalizing
--+---
 Reporter:  zielony   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information
 * keywords:  zoom =>
 * component:  - Select a component => Applications/Tor Browser


Comment:

 What Tor Browser version are you using? On which operating system? Is this
 a new behavior? If so, when did it change? Could you give us steps to
 reproduce your problem?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18955 [Metrics/CollecTor]: javadoc coverage

[Tor Bug Tracker & Wiki]

#18955: javadoc coverage
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Thanks for starting this discussion.  Two suggestions:
  1. We make the easy changes now.  That includes turning comments into
 Javadoc, rephrasing Javadoc that doesn't start with a summary sentence
 (happy to conform to that rule if it's in the guide), and maybe others
 that require less than a minute per comment.
  1. We defer the non-easy changes and general decisions until we have
 finished the metrics-lib Javadoc ticket (#16873) and made bigger
 refactoring measures like removing dead code.  This could take a few
 weeks, and it doesn't make much sense to clutter the checkstyle output
 with warnings we cannot fix right now.  We should mention in the
 checkstyle document that this is a temporary measure.

 How does that sound?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17101 [Core Tor/Tor]: Tests for connection_ap_handshake_rewrite_and_attach

[Tor Bug Tracker & Wiki]

#17101: Tests for connection_ap_handshake_rewrite_and_attach
-+-
 Reporter:  ipazmino |  Owner:
 Type:  defect   |  ipazmino
 Priority:  Medium   | Status:
Component:  Core Tor/Tor |  needs_review
 Severity:  Normal   |  Milestone:  Tor:
 Keywords:  coverage, merge-ready, tor-tests-|  0.2.9.x-final
  coverage, tor-tests-unit, TorCoreTeam201605,   |Version:
  TorCoreTeam-postponed-201604   | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:  asn  | Points:  medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #18761 [Core Tor/Tor]: Make logging of rendezvous to private address quieter

[Tor Bug Tracker & Wiki]

#18761: Make logging of rendezvous to private address quieter
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc, tor-hs,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.2-alpha
  postponed-201604   | Resolution:
Parent ID:   |  Actual Points:  very
 Reviewer:  asn  |  small
 | Points:  small
 |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #18719 [Metrics/CollecTor]: provide executable jar

[Tor Bug Tracker & Wiki]

#18719: provide executable jar
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  needs_review => merge_ready


Comment:

 Thanks for making that change.  For some reason I'm unable to apply your
 patch using `git am`.  Would you mind pushing your branch to your shiny
 new git.torproject.org repository?

--
Ticket URL: 

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

Re: [tor-bugs] #18952 [Applications/Tor Browser]: Tor Browser without Tor

[Tor Bug Tracker & Wiki]

#18952: Tor Browser without Tor
--+-
 Reporter:  cypherpunks   |  Owner:  cypherpunks
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gk):

 * status:  needs_information => assigned
 * owner:   => cypherpunks


Comment:

 That's not something we support actually. So, we won't work on it. Not
 sure whether we even would merge a patch supporting this 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] #18894 [Internal Services/Service - git]: Please create user repositories metrics-lib and collector for iwakeh

[Tor Bug Tracker & Wiki]

#18894: Please create user repositories metrics-lib and collector for iwakeh
-+
 Reporter:  iwakeh   |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

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


Comment:

 [x]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18966 [Applications/Tor Browser]: Avoid verbose ssh output in KVM builds

[Tor Bug Tracker & Wiki]

#18966: Avoid verbose ssh output in KVM builds
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-gitian
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 `QUIET_FLAG="-vP"` has the consequence that we have huge ssh log output we
 probably don't want. We should fix that in our gitian-builder setup and
 upstream that patch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18719 [Metrics/CollecTor]: provide executable jar

[Tor Bug Tracker & Wiki]

#18719: provide executable jar
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Oops, thanks for noticing the oversized runtime jar!

 The patch is replaced and the resulting runtime jar is reduced by a factor
 of ten.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18960 [User Experience/Website]: Tor Address Change

[Tor Bug Tracker & Wiki]

#18960: Tor Address Change
-+---
 Reporter:  jselon   |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Description changed by arma:

Old description:

> Tor's Organizational address should be changed to our Seattle address.
> The original address was 7 Temple Street, Suite A, Cambridge, MA 02139.
> The new Seattle mailing address is:
> 217 1st Ave South #4903
> Seattle, WA 98194

New description:

 Tor's Organizational address should be changed to our Seattle address. The
 original address was 7 Temple Street, Suite A, Cambridge, MA 02139.  The
 new Seattle mailing address is:
 {{{
 217 1st Ave South #4903
 Seattle, WA 98194
 }}}

--

--
Ticket URL: 

Tor Bug Tracker & Wiki 
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] #18964 [Metrics/CollecTor]: jenkins builds for and file structure in Metrics Team (java) projects

[Tor Bug Tracker & Wiki]

#18964: jenkins builds for and file structure in Metrics Team (java) projects
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Replying to [ticket:18964 iwakeh]:
 > I couldn't find a cross-concern Metrics Component for the following,
 That's why this is placed in CollecTor.

 True, there is no component for that.  But how about we start with
 CollecTor tickets for these issues, list things like "Jenkins integration"
 and "file structure" in the
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Documentation#GuideDocuments
 guides], and later create tickets for other components when we change
 focus to them?

 > For implementation child-tickets should be opened with the appropriate
 component.
 > 
 > Wouldn't it be nice to have a group of tasks in
 https://jenkins.torproject.org
 > for all the Metrics projects (no matter which language) or at least all
 the java ones?
 >
 > **1)** The Jenkins builds could just run in this clean environment
 whenever a check-in takes place.
 > Thus, not generating too much strain on the server(s) Jenkins uses. The
 builds are much smaller than the Tor ones anyway.
 > In addition, the last build's javadoc and reports as well as test
 results would be immediately available for viewing.

 That would be nice, but maybe on a lower priority than making sure that
 we're not missing descriptors, for example.  A ticket wouldn't hurt
 though.

 > **2)** Another cross-Metrics concern for java projects is the file
 structure.
 > It might be useful to unify the structure to the following (sort of
 similar to the typical maven layout):
 > "src" and "generated" as top level. "generated" should be used as in
 collector.
 > "src" should have the substructure "main" and "test" (as already started
 in Onionoo).
 > "main" contains "java", "resources", "web", ...
 > Same with "test" where appropriate.

 Sure.  How about we simply pick
 [https://maven.apache.org/guides/introduction/introduction-to-the-
 standard-directory-layout.html Maven's Standard Directory Layout] (without
 switching to Maven, of course)?  I don't mind much what directory
 structure we use, and using an existing layout would make documentation a
 bit easier.  Happy to discuss more on a separate ticket.

 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] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:229 tarmick]:
 > it's one thing for cloudflare to care about solving tor (which i think
 they do, by way of engaging here) but it's another for google to do
 something about their captcha. i just don't understand why cloudflare
 doesn't use something else or something special for tor users. It's pretty
 clear google either do not care about Tor users or they can't because
 their security solution doesn't scale well.

 We're actively looking into two things: fewer CAPTCHAs and a better
 CAPTCHA solution. The latter is pretty hard because we need something that
 scales to our size, works internationally, actually does what it says on
 the tin. We have made changes (with the help on Google) to reduce the
 complexity of CAPTCHAs being seen by Tor users and continue to work on
 this.

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

[tor-bugs] #18965 [- Select a component]: Zoom sets to 124% after minimalizing and maximalizing

[Tor Bug Tracker & Wiki]

#18965: Zoom sets to 124% after minimalizing and maximalizing
--+--
 Reporter:  zielony   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  zoom
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Zoom sets to 124% after minimalizing and maximalizing

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18719 [Metrics/CollecTor]: provide executable jar

[Tor Bug Tracker & Wiki]

#18719: provide executable jar
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Looks good!  Just one thing: Can you change `` to just
 include the libraries that are necessary for running CollecTor?  Two
 reasons: the .jar file will be smaller and it won't contain classes from
 packages that are not in Debian stable.  Other than that, ready to merge.
 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] #18798 [Metrics/CollecTor]: analysis of descriptor completeness

[Tor Bug Tracker & Wiki]

#18798: analysis of descriptor completeness
---+---
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 Replying to [comment:8 iwakeh]:
 > I added the referencing descriptor analysis to the todo list.

 Great!

 > Another question regarding the logging statements:
 >
 > What do the following numbers mean, i.e. how reliable are these numbers?
 > Also, the difference between "importing" and "downloading"?
 >
 > [...]

 CollecTor receives its descriptors from two sources:
  1. it first fetches copies of cached descriptors from directory authority
 gabelmoo using `wget` on the command line outside of the directory
 protocol and imports them (the "import" step);
  1. it looks which descriptors it's still missing and fetches them via the
 directory protocol from most directory authorities except a few that have
 been too slow in the past (the "download" step).

 I believe that the numbers in the logs are reliable, but I don't know for
 certain.

 > And:
 > Why are there so many "404 Not found" like
 > [...]
 >
 > Does this mean that just one of the requested descriptors wasn't found?
 > Or, that there was no answer, or ...?
 > Hope I didn't overlook anything obvious in the tor-spec.

 Fine question, let's simply try it out.  The current extra-info descriptor
 digest of TorLand1 is `352c235cd4134d0d8ff41c1f88c653a450bd4137`:

 {{{
 curl -v
 http://154.35.32.5/tor/extra/d/352c235cd4134d0d8ff41c1f88c653a450bd4137 >
 /dev/null   # 200 OK
 curl -v
 http://154.35.32.5/tor/extra/d/ >
 /dev/null   # 404 Not found
 curl -v
 
http://154.35.32.5/tor/extra/d/352c235cd4134d0d8ff41c1f88c653a450bd4137+
 > /dev/null   # 200 OK
 }}}

 So, looks like "404 Not found" means that none of the requested descriptor
 was found.  Maybe the spec agrees, I didn't look.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18935 [Applications/Tor Browser]: MS bugs - Danger! Windows updates break everything on their way!

[Tor Bug Tracker & Wiki]

#18935: MS bugs - Danger! Windows updates break everything on their way!
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:9 bugzilla]:
 > Well, fully updated system with EAF disabled brought us to:
 > {{{
 > Faulting application name: firefox.exe, version: 45.1.0.0, time stamp:
 0x
 > Faulting module name: xul.dll, version: 45.1.0.0, time stamp: 0x
 > Exception code: 0xc005
 > Fault offset: 0x0003fb34
 > }}}
 > Seems opening a lot of Trac tickets in the background is a good stress-
 test.

 Seems to work for me on an up-to-date Win 7 system. I bookmarked 20 trac
 tickets and opened them at the same time. Everything still worked. Do you
 have more detailed steps to reproduce the crashes?

 At a more generic level: What are we supposed to do with this ticket and
 the numerous issues you mentioned? How is this still actionable?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18964 [Metrics/CollecTor]: jenkins builds for and file structure in Metrics Team (java) projects

[Tor Bug Tracker & Wiki]

#18964: jenkins builds for and file structure in Metrics Team (java) projects
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 I couldn't find a cross-concern Metrics Component for the following,
 That's why this is placed in CollecTor.
 For implementation child-tickets should be opened with the appropriate
 component.
 
 Wouldn't it be nice to have a group of tasks in
 https://jenkins.torproject.org
 for all the Metrics projects (no matter which language) or at least all
 the java ones?

 **1)** The Jenkins builds could just run in this clean environment
 whenever a check-in takes place.
 Thus, not generating too much strain on the server(s) Jenkins uses. The
 builds are much smaller than the Tor ones anyway.
 In addition, the last build's javadoc and reports as well as test results
 would be immediately available for viewing.

 **2)** Another cross-Metrics concern for java projects is the file
 structure.
 It might be useful to unify the structure to the following (sort of
 similar to the typical maven layout):
 "src" and "generated" as top level. "generated" should be used as in
 collector.
 "src" should have the substructure "main" and "test" (as already started
 in Onionoo).
 "main" contains "java", "resources", "web", ...
 Same with "test" where appropriate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #9135 [Applications/TorBirdy]: TorBirdy NightOwl Deliverables

[Tor Bug Tracker & Wiki]

#9135: TorBirdy NightOwl Deliverables
---+-
 Reporter:  sukhbir|  Owner:  ioerror
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by sukhbir):

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


Comment:

 It's been three years since we did NightOwl. Closing this parent ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18929 [Core Tor/Tor]: Fix selection of directories with non-preferred address families

[Tor Bug Tracker & Wiki]

#18929: Fix selection of directories with non-preferred address families
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, TorCoreTeam201605   |  0.2.8.1-alpha
Parent ID:  #18483   | Resolution:
 Reviewer:  isis |  Actual Points:  2 hours
 | Points:  small
 |Sponsor:
-+-

Comment (by teor):

 I split #18483, #18921, and #18929 into three separate branches for 0.2.8,
 and a branch for 0.2.9.
 Please see bug18929-v2 on https://github.com/teor2345/tor.git for this
 issue. It has no dependencies.

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