Re: [tor-bugs] #20969 [Core Tor/DocTor]: Detect relays that don't update their onion keys every 7 days.

[Tor Bug Tracker & Wiki]

#20969: Detect relays that don't update their onion keys every 7 days.
-+
 Reporter:  dgoulet  |  Owner:  atagar
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by atagar):

 Hi David, just wanted to leave a quick note apologizing for not getting
 back to ya yet. This is on my radar - sadly along with a dozen 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] #21059 [Core Tor/Tor]: shared-rand-current-value violates spec

[Tor Bug Tracker & Wiki]

#21059: shared-rand-current-value violates spec
--+-
 Reporter:  atagar|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Yeah, I think we loosen the spec to let them appear in whatever order, and
 then we put them in the order we want (I guess in a future consensus
 method if it's different from what we do 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] #15426 [Core Tor/Tor]: Update ciphers.inc to match ciphers from current Firefox

[Tor Bug Tracker & Wiki]

#15426: Update ciphers.inc to match ciphers from current Firefox
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  027-triaged-1-out, nickm-|  Actual Points:
  deferred-20160905, tor-03-unspecified-201612   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by jryans):

 * cc: jryans@… (added)


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

[tor-bugs] #21060 [Applications/Tor Browser]: Disabled SVG should fall back to other image formats

[Tor Bug Tracker & Wiki]

#21060: Disabled SVG should fall back to other image formats
--+---
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  svg tbb-usability
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 At https://www.bamsoftware.com/papers/fronting/, the figures don't show up
 with the security slider on the "High" setting in Tor Browser 6.5a6.
 Instead, it just shows the alt text:

 [[Image(fig-fronting.png)]]

 The HTML is using the [https://developer.mozilla.org/en-
 US/docs/Web/HTML/Element/picture picture] element to allow fallback from
 SVG to PNG:
 {{{
 
 
 
 
 }}}

 It would be nice if the way Tor Browser disabled SVG was compatible with
 this usage, to allow the browser to try PNG next.

 On the other hand, I see the MDN page says these API are experimental, so
 go ahead and close this if it seems esoteric or unsupported.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21059 [Core Tor/Tor]: shared-rand-current-value violates spec

[Tor Bug Tracker & Wiki]

#21059: shared-rand-current-value violates spec
--+-
 Reporter:  atagar|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Hi Nick. Shared randomness just made it into the consensus and it's making
 Stem's validator squawk. Trouble is that it's in the wrong position in the
 header. [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt
 According to the spec]...

 {{{
 The preamble contains the following items.  They MUST occur in the
 order given here:
 }}}

 However, shared-rand-current-value appears last...

 {{{
 % wget http://128.31.0.39:9131/tor/status-vote/current/consensus
 % less consensus
 ...
 required-client-protocols Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3
 HSRend=1 Link=4 LinkAuth=1 Microdesc=1-2 Relay=2
 required-relay-protocols Cons=1 Desc=1 DirCache=1 HSDir=1 HSIntro=3
 HSRend=1 Link=3-4 LinkAuth=1 Microdesc=1 Relay=1-2
 params CircuitPriorityHalflifeMsec=3 NumDirectoryGuards=3
 NumEntryGuards=1 NumNTorsPerTAP=100 Support022HiddenServices=0
 UseNTorHandshake=1 UseOptimisticData=1 bwauthpid=1 cbttestfreq=60
 pb_disablepct=0 usecreatefast=0
 shared-rand-current-value 6 nwr/w2uC49g/ZxbGpshs0w2nqWWqCsrHWzQhkuelAgA=
 dir-source dannenberg 0232AF901C31A04EE9848595AF9BB7620D4C5B2E
 dannenberg.torauth.de 193.23.244.244 80 443
 contact Andreas Lehner
 ...
 }}}

 Think I'll mark this as 'high' since it's a new regression in the live
 consensuses. Gonna hazard to guess we'll need to update the spec rather
 than tor since this has already made it into a release?

 Kinda unfortunate since it means it won't live with the other shared
 randomness attributes...

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

Re: [tor-bugs] #20956 [Core Tor/Tor]: optionally do not write command line config to torrc

[Tor Bug Tracker & Wiki]

#20956: optionally do not write command line config to torrc
--+
 Reporter:  mcs   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-wants |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by neel):

 I have created a patch which converts the ControlPort and SocksPort to
 _ControlPort and _SocksPort.

 Thank You,
 Neel Chauhan

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

Re: [tor-bugs] #15426 [Core Tor/Tor]: Update ciphers.inc to match ciphers from current Firefox

[Tor Bug Tracker & Wiki]

#15426: Update ciphers.inc to match ciphers from current Firefox
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  027-triaged-1-out, nickm-|  Actual Points:
  deferred-20160905, tor-03-unspecified-201612   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * priority:  Medium => High
 * milestone:  Tor: unspecified => Tor: 0.3.0.x-final


Comment:

 well then. how hard could it be?

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

Re: [tor-bugs] #15426 [Core Tor/Tor]: Update ciphers.inc to match ciphers from current Firefox

[Tor Bug Tracker & Wiki]

#15426: Update ciphers.inc to match ciphers from current Firefox
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  027-triaged-1-out, nickm-|  Actual Points:
  deferred-20160905, tor-03-unspecified-201612   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 This is now being used in places in England to block access to Tor. Can
 confirm Gatwick Airport uses this.

 Modifying the header using for example Fiddler on Windows makes Tor
 network accessible again.

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

[tor-bugs] #21058 [- Select a component]: Manual Modifications: Correction and Improvement

[Tor Bug Tracker & Wiki]

#21058: Manual Modifications: Correction and Improvement
--+-
 Reporter:  agd   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Please modify the Manual as follows: 1) At StrictNodes: A) Please change
 "will treat" to "treats '''solely'''"; B) At the end of the first
 sentence, please add "(StrictNodes applies to neither ExcludeExitNodes nor
 to ExitNodes)"; 2) At ExcludeExitNodes, please bold "'''outside'''"  3) At
 ExitNodes: A) please bold both usages of "'''outside'''"; B) In the third
 paragraph, to the end of the second sentence, please add: "(i.e. Onion
 Circuits shows third nodes which DO NOT ''EXIT'' the Tor network, but are
 used exclusively internally by Tor)".

 For further discussion of this,
 https://tor.stackexchange.com/questions/13134 has some relevance.

 It is imperative, in order to maintain user trust in Tor, that the manual
 accurately and precisely describe Tor's behavior.

 '''PLEASE NOTE:''' I am uncertain if, in fact, StrictNodes applies
 'solely' to ExcludeNodes; so please verify that as necessary. I am
 quite certain regarding the other requested modification [1B] to
 StrictNodes. All other requested modifications merely improve
 understandability.

 In-line, the above modifications would modify the relevant portions of the
 Manual to read as follows [modifications offset by ">>" and "<<"]:


 StrictNodes 0|1

 If StrictNodes is set to 1, Tor >>treats '''solely'''<< the
 ExcludeNodes option as a requirement to follow for all the circuits you
 generate, even if doing so will break functionality for you >>(StrictNodes
 applies to neither ExcludeExitNodes nor to ExitNodes)<<. If StrictNodes is
 set to 0, Tor will still try to avoid nodes in the ExcludeNodes list, but
 it will err on the side of avoiding unexpected errors. Specifically,
 StrictNodes 0 tells Tor that it is okay to use an excluded node when it is
 '''necessary''' to perform relay reachability self-tests, connect to a
 hidden service, provide a hidden service to a client, fulfill a .exit
 request, upload directory information, or download directory information.
 (Default: 0)


 ExcludeExitNodes node,node,…

 A list of identity fingerprints, country codes, and address patterns
 of nodes to never use when picking an exit node---that is, a node that
 delivers traffic for you >>'''outside'''<< the Tor network. Note that any
 node listed in ExcludeNodes is automatically considered to be part of this
 list too. See the '''ExcludeNodes''' option for more information on how to
 specify nodes. See also the caveats on the "ExitNodes" option below.


 ExitNodes node,node,…

 A list of identity fingerprints, country codes, and address patterns
 of nodes to use as exit node---that is, a node that delivers traffic for
 you >>'''outside'''<< the Tor network. See the '''ExcludeNodes''' option
 for more information on how to specify nodes.

 Note that if you list too few nodes here, or if you exclude too many
 exit nodes with ExcludeExitNodes, you can degrade functionality. For
 example, if none of the exits you list allows traffic on port 80 or 443,
 you won’t be able to browse the web.

 Note also that not every circuit is used to deliver traffic
 >>'''outside'''<< of the Tor network. It is normal to see non-exit
 circuits (such as those used to connect to hidden services, those that do
 directory fetches, those used for relay reachability self-tests, and so
 on) that end at a non-exit node >>(i.e. Onion Circuits shows third nodes
 which DO NOT ''EXIT'' the Tor network, but are used exclusively internally
 by Tor)<<. To keep a node from being used entirely, see ExcludeNodes and
 StrictNodes.

 The ExcludeNodes option overrides this option: any node listed in both
 ExitNodes and ExcludeNodes is treated as excluded.

 The .exit address notation, if enabled via AllowDotExit, overrides
 this option.

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
---+---
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, triage-out-030-201612  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorR-can
---+---
Changes (by s7r):

 * cc: s7r (added)


Comment:

 Recently got this message (16 December 2016 and respectively 18 December
 2016) 3 times on 0.2.9.6-rc, so it's still happening.

 Branch `bug15618_030-testing` in dgoulet's repo includes a patch that will
 help us confirm or infirm the theory described at comment:8 . I have
 compiled that branch and hardcoded the relay running it as RP, but can't
 properly test it at this time because of #21056 so we'll have to wait
 little more, I'll revert with results after.

 The problem is the message:
 {{{
 [warn] BLAM. Circuit has_opened() called 3 times.
 }}}
 is logged on the '''client''' instance when trying to open more ( > 1 )
 concurrent connections to the same onion service with the same (hardcoded)
 RP but different circuits because requests are sent with socks username /
 password isolation. Nothing unusual on the '''relay''' instance - no
 warnings at all.

 Having the log at debug level on client instance I was able to see that
 the hardcoded RP is in majority of circuits hop number 4 which means
 cannibalization, because the RP counted from client side should be hop
 number 3, right?

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

Re: [tor-bugs] #20332 [Core Tor/Tor]: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS

[Tor Bug Tracker & Wiki]

#20332: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS
---+---
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, triage-out-030-201612  |  Actual Points:
Parent ID: | Points:  ?
 Reviewer: |Sponsor:  SponsorR-can
---+---
Changes (by s7r):

 * cc: s7r (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] #21056 [Core Tor/Tor]: Could not pick one of the responsible hidden service directories, because we requested them all recently without success.

[Tor Bug Tracker & Wiki]

#21056: Could not pick one of the responsible hidden service directories, 
because
we requested them all recently without success.
--+
 Reporter:  joeyh |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by s7r):

 * cc: s7r (added)
 * priority:  Medium => High


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

Re: [tor-bugs] #21056 [Core Tor/Tor]: Could not pick one of the responsible hidden service directories, because we requested them all recently without success.

[Tor Bug Tracker & Wiki]

#21056: Could not pick one of the responsible hidden service directories, 
because
we requested them all recently without success.
--+
 Reporter:  joeyh |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by s7r):

 I confirm this happens heavily on git master with otherwise available up
 and running onion services. It only happens when you open more ( > 1 )
 concurrent socks requests (either to different hidden services or to the
 same hidden service with isolation).

 I won't attach another debug log because this is very easy to reproduce:
 just open at least 2 or 3 socks requests simultaneously to the same up and
 running hidden service but use a different socks username / password for
 each request so they are isolated. The hidden service will become
 unreachable immediately, because Tor will think it tried all HSDirs and
 couldn't get a valid descriptor. It works normally if you make just one
 request at a time, but it's clearly a bug.

 I can also confirm this wasn't happening in previous releases (could have
 been introduced with a socks patch). I used the same script to open many
 concurrent rendezvous circuits to the same onion service to stress test
 OnionBalance back then and I didn't experience this 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] #20546 [Metrics/CollecTor]: implement CleanUtils

[Tor Bug Tracker & Wiki]

#20546: implement CleanUtils
---+---
 Reporter:  iwakeh |  Owner:  aegis2501
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by aegis2501):

 Replying to [comment:7 iwakeh]:
 > Cool!
 >
 > I didn't look deeply, e.i. think my way through the code, yet, but it's
 a very clean style.
 > Your test coverage is also up to 93% for CleanUtils, great.  (I didn't
 reply to your question
 > in comment:5, because trac doesn't mail anything for edited comments.
 So I didn't see the question.)
 >
 > Maybe, try to think up some tests that trigger exceptions and also to
 find out, what happens when unexpected input is given, like `null` or
 empty Strings or a file disappeared before being erased or never existed
 etc.
 >
 > And, we also have a Checkstyle and task `ant checks`, which currently
 complains a little about CleanUtils and CleanUtilsTest.  Nothing dramatic,
 mostly indentation and spacing.
 > Could you get that to pass again?
 >
 > Thanks a lot for that work!

 No problem! I'll work on 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] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
  |  chelseakomlo
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc, triage-out-030-201612  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by chelseakomlo):

 Thanks for the feedback- see
 `g...@github.com:chelseakomlo/tor_patches.git`, branch
 `documentation_integ_tests` with these changes.

 Replying to [comment:21 cypherpunks]:
 > With #5500 being implemented, `make check` now runs the `check-spaces`
 target. Because `make distcheck` also runs `make check` when it tests the
 distribution, asking developers to call `make check-spaces` separately is
 redundant. Maybe you can remove the lines mentioning `make check-spaces`?

 Sure, good point. See `dfde58db6b4ca0b406b872d7b049efbe07d7a0fe`

 > Also IMHO the commit message of
 `ff085157a5b8ecff00604e3a78295d271cda0c51` is too long.

 Fair. See `d95678ca8f97ac6e648598af01b4394840999e72`

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

Re: [tor-bugs] #21044 [Core Tor/Tor]: ORPort self reachability test happens also when it shouldn't

[Tor Bug Tracker & Wiki]

#21044: ORPort self reachability test happens also when it shouldn't
--+
 Reporter:  s7r   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by s7r):

 Thinking again the protocol to guess `Address` is OK to be called even
 when `ORPort` is explicitly configured as a loopback or NAT address
 because there might be such setups. This is why there is a log message
 instructing about IP address mismatch and how to use `NoAdvertise` and
 `NoListen` flags along with `Address` to fix it.

 So, the first two behaviors (bypass the protocol to guess `Address` and
 bypass self reachability tests) should only happen when
 `PublishServerDescriptor 0` is set and `ORPort` is a loopback or NAT
 address, otherwise use the current behavior which is fine for cases where
 user wants to run a public relay / bridge.

 Also, there might be use cases where one does not want to publish the
 descriptor but uses a separate tool that does this or just needs to export
 the descriptor and use it somehow, so `PublishServerDescriptor 0` should
 build it, but not publish it as it currently does - we just need to
 correct the self reachability tests when this option is set.

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

Re: [tor-bugs] #21045 [Core Tor/Tor]: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4

[Tor Bug Tracker & Wiki]

#21045: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4
+--
 Reporter:  downie  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  OSX Tiger 10.4  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by downie):

 Compiling with gcc-4.2 worked (I was prompted to disable 'stack
 protection' whatever that is (What does it protect it from? Bears?) so
 hope that's ok). Something in the new Tor is incompatible with gcc-4.0.
 Something to do with those 'redundant declarations'?

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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
  |  chelseakomlo
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc, triage-out-030-201612  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by cypherpunks):

 With #5500 being implemented, `make check` now runs the `check-spaces`
 target. Because `make distcheck` also runs `make check` when it tests the
 distribution, asking developers to call `make check-spaces` separately is
 redundant. Maybe you can remove the lines mentioning `make check-spaces`?

 Also IMHO the commit message of `ff085157a5b8ecff00604e3a78295d271cda0c51`
 is too long.

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

Re: [tor-bugs] #20653 [Core Tor/Tor]: Test targets should gracefully handle missing dependencies

[Tor Bug Tracker & Wiki]

#20653: Test targets should gracefully handle missing dependencies
-+-
 Reporter:  chelseakomlo |  Owner:
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  test, tor-03-unspecified-201612  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 With #5500 being fixed, `make check-spaces` now does nothing when Perl
 isn't found.

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
-+--
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:159 dcf]:
 > Replying to [comment:156 cypherpunks]:
 > > Redirect generated by KZ box for blocked site:
 > > https://paste.debian.net/plainh/39d8508f
 > > (can't paste here for spam filter block)
 >
 > {{{
 > HTTP/1.1 302 Found\r\n
 > }}}

 kzblocked found a similar 302 redirect in a Stack Overflow question,
 apparently from a www.google.co.in frontend server:

 https://stackoverflow.com/questions/29861189/302-found-response-for-
 google-com
 {{{
 HTTP/1.1 302 Found
 Cache-Control: private
 Content-Type: text/html; charset=UTF-8
 Location: http://www.google.co.in/?gfe_rd=cr=Uhw7Vbe6H_PI8Ae_qICIBA
 Content-Length: 261
 Date: Sat, 25 Apr 2015 04:47:14 GMT
 Server: GFE/2.0
 Alternate-Protocol: 80:quic,p=1

 
 302 Moved
 302 Moved
 The document has moved
 http://www.google.co.in/?gfe_rd=crei=Uhw7Vbe6H_PI8Ae_qICIBA;>here.
 
 }}}

 The header is rather different; also notice `302 Moved` rather than `302
 Found` in the HTML body.

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
-+--
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 kzblocked showed me that the HTTP injection is bidirectional: you get the
 injection even if you send a request for a blocked Host from the outside
 to the inside:
 {{{
 $ echo -n $'GET / HTTP/1.0\r\nHost: bash.im\r\n\r\n' | nc government.kz 80
 HTTP/1.1 302 Found
 Content-Length: 210
 Location: http://92.63.88.128/?NTDzLZ
 Content-Type: text/html; charset=UTF-8

 
 302 Found
 302 Found
 The document has moved
 http://92.63.88.128/?NTDzLZ;>here
 
 }}}

 The KZ firewall is stateful: it doesn't respond to naked TCP payloads but
 requires a connection to be established first. I.e., in scapy, this
 doesn't work:
 {{{
 sr(IP(dst="government.kz")/TCP(flags="PA", seq=123456, ack=1000)/"GET /
 HTTP/1.0\r\nHost: bash.im\r\n\r\n")
 }}}
 But it works if you do a TCP handshake first:
 {{{
 r = sr(IP(dst="government.kz")/TCP(flags="S", seq=1000))[0][0][1]
 sr(IP(dst="government.kz")/TCP(flags="PA", seq=123456, ack=r.seq+1)/"GET /
 HTTP/1.0\r\nHost: bash.im\r\n\r\n")
 }}}

 In comment:161 I found an ISP in Russia (209.ru) that had an almost
 identical injection as the Kazakh firewall, with only the redirected-to
 URL differing. kzblocked found that the same ISP ''also'' injects
 responses for censorship purpose: you get an iframe with a block page if
 you request a forbidden Host. Ordinary site (example.com) takes you to a
 payment page:
 {{{
 $ echo -n $'GET / HTTP/1.0\r\nHost: example.com\r\n\r\n' | nc
 37.192.17.117 80
 HTTP/1.1 302 Found
 Content-Length: 202
 Location: http://0.209.ru
 Content-Type: text/html; charset=UTF-8

 
 302 Found
 302 Found
 The document has moved
 http://0.209.ru;>here
 
 }}}
 Blocked site (ej.ru) takes you to a block page:
 {{{
 $ echo -n $'GET / HTTP/1.0\r\nHost: ej.ru\r\n\r\n' | nc 37.192.17.117 80
 HTTP/1.1 200 OK
 Connection: close
 Content-Type: text/html; charset=iso-8859-1

 
 Access Denied
 
 
 http://zapret.209.ru; width=100%" height="1250"
 frameborder="0"> 
 
 
 
 
 }}}
 "zapret" =
 [https://en.wiktionary.org/wiki/%D0%B7%D0%B0%D0%BF%D1%80%D0%B5%D1%82#Russian
 запрет] = "prohibition, interdiction, ban". The block page has a cute
 matryoshka doll and a link to http://blocklist.rkn.gov.ru/. The 209.ru
 responses have the same TTL and TCP option anomalies as in comment:166.
 This ISP uses the same tech for both payment enforcement and censorship,
 and all indications are that it is the same tech as in Kazakhstan.

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

Re: [tor-bugs] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 
https://gitweb.torproject.org/nickm/tor.git/commit/?h=bug21035=a757f769676cf0a942fb1c909ff4cf469d362d12

 This looks ok to me.

 Somewhat related, I think the tests will fail to compile on U*IX systems
 that lack `CLOCK_MONOTONIC_COARSE` entirely.
 (`test_util.c:test_util_monotonic_time()` calls `monotime_coarse_get()`
 which is behind a `#ifdef`).

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

Re: [tor-bugs] #21048 [Applications/Tor Browser Sandbox]: Adwaita theme directory not available in Debian and newer Ubuntu versions

[Tor Bug Tracker & Wiki]

#21048: Adwaita theme directory not available in Debian and newer Ubuntu 
versions
--+-
 Reporter:  qbi   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 The theme is split into two packages, `gnome-themes-standard` which
 contains the `libadwaita.so` engine, and `gnome-themes-standard-data`
 which contains the assets.  The code was more forgiving about the shared
 object being missing than the assets (as in, it would log, but continue),
 while if the assets were missing it would bail out.

 I think for the theme to work properly, both packages should be installed,
 but as of master any combination of none, just the shared object, just the
 assets, and both should work, with "both" being preferred.

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

Re: [tor-bugs] #21048 [Applications/Tor Browser Sandbox]: Adwaita theme directory not available in Debian and newer Ubuntu versions

[Tor Bug Tracker & Wiki]

#21048: Adwaita theme directory not available in Debian and newer Ubuntu 
versions
--+-
 Reporter:  qbi   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by qbi):

 JFTR: The package {{{gnome-themes-standard-data}}} was needed and is
 sufficient to successfully start sandboxed-tor-browser. It contains the
 files in {{{/usr/share/themes/Adwaita}}}.

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

Re: [tor-bugs] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+

Comment (by tmpname0901):

 Seems to be working.

 I did a recursive diff of your branch and the released v0.2.9.8 tarball,
 and there were a *lot* of differences (3MB patch file).  So I applied only
 your changes to ~/tor/src/common/compat_time.c to the released version to
 avoid muddying the water with extraneous changes.  Rebuilt and all seems
 to be well.

 

 Dec 21 20:15:36.000 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) opening
 log file.
 Dec 21 20:15:36.704 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) running on
 Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
 Dec 21 20:15:36.704 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Dec 21 20:15:36.704 [notice] Read configuration file "/etc/tor/torrc".
 Dec 21 20:15:36.707 [notice] Based on detected system memory,
 MaxMemInQueues is set to 6144 MB. You can override this by setting
 MaxMemInQueues by hand.
 Dec 21 20:15:36.707 [notice] Opening Socks listener on 127.0.0.1:9050
 Dec 21 20:15:36.707 [notice] Opening OR listener on 46.29.248.238:443
 Dec 21 20:15:36.708 [notice] Opening Directory listener on
 46.29.248.238:80
 Dec 21 20:15:36.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
 Dec 21 20:15:36.000 [notice] Parsing GEOIP IPv6 file
 /usr/share/tor/geoip6.
 Dec 21 20:15:36.000 [notice] Configured to measure statistics. Look for
 the *-stats files that will first be written to the data directory in 24
 hours from now.
 Dec 21 20:15:36.000 [notice] Your Tor server's identity key fingerprint is
 'Unnamed 7452E7D19ACD2C39DE10C0207032E6BC05DB78F2'
 Dec 21 20:15:36.000 [notice] Bootstrapped 0%: Starting
 Dec 21 20:15:46.000 [notice] Bootstrapped 80%: Connecting to the Tor
 network
 Dec 21 20:15:46.000 [notice] Self-testing indicates your ORPort is
 reachable from the outside. Excellent.
 Dec 21 20:15:47.000 [notice] Bootstrapped 85%: Finishing handshake with
 first hop
 Dec 21 20:15:47.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
 Dec 21 20:15:47.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Dec 21 20:15:47.000 [notice] Bootstrapped 100%: 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

[tor-bugs] #21057 [Applications/Tor Browser Sandbox]: Change the metadata URL(s) for the stable bundle.

[Tor Bug Tracker & Wiki]

#21057: Change the metadata URL(s) for the stable bundle.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This is a trivial change to a bunch of JSON files, but prior to all of
 such things moving to `aus1.torproject.org` (6.5?), the base URL needs to
 be updated from it's current location.

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

Re: [tor-bugs] #20546 [Metrics/CollecTor]: implement CleanUtils

[Tor Bug Tracker & Wiki]

#20546: implement CleanUtils
---+---
 Reporter:  iwakeh |  Owner:  aegis2501
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by iwakeh):

 Cool!

 I didn't look deeply, e.i. think my way through the code, yet, but it's a
 very clean style.
 Your test coverage is also up to 93% for CleanUtils, great.  (I didn't
 reply to your question
 in comment:6, because trac doesn't mail anything for edited comments.  So
 I didn't see the question.)

 Maybe, try to think up some tests that trigger exceptions and also to find
 out, what happens when unexpected input is given, like `null` or empty
 Strings or a file disappeared before being erased or never existed etc.

 And, we also have a Checkstyle and task `ant checks`, which currently
 complains a little about CleanUtils and CleanUtilsTest.  Nothing dramatic,
 mostly indentation and spacing.
 Could you get that to pass again?

 Thanks a lot for that work!

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

Re: [tor-bugs] #19769 [Core Tor/Tor]: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)

[Tor Bug Tracker & Wiki]

#19769: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, dns,   |  Actual Points:
  TorCoreTeam201609  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nicoo):

 * cc: nicoo (added)


Comment:

 Regarding MIN_DNS_TTL, Microsoft Windows used (still does?) to have a
 minimum TTL of 15 minutes for it's client-side cache, IIRC.
 Given how prevalent that platform is, I guess a 1 minute MIN_DNS_TTL is
 very unlikely to break things.

 Are there plans to allow more values than {MIN,MAX}_DNS_TTL?

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

Re: [tor-bugs] #19769 [Core Tor/Tor]: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)

[Tor Bug Tracker & Wiki]

#19769: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, dns,   |  Actual Points:
  TorCoreTeam201609  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by pulls):

 == Concretely ==


 {{{
 MIN_DNS_TTL = 5*60;
 MAX_DNS_TTL = 60*60;

 dns_clip_ttl(uint32_t ttl)
 {
   if (ttl < MIN_DNS_TTL)
 return MIN_DNS_TTL;
   else
 return MAX_DNS_TTL;
 }
 }}}


 - Fix #19025 (otherwise ttl above will always be MIN_DNS_TTL).
 - Potentially refactor the DNS caching code to support evictions (while
 doing this, maybe rip out all old client-side DNS caching code?).
 - Add some form of logging to track cache size, usage, and eviction rate.
 - dns_get_expiry_ttl should be the same as dns_clip_ttl above. Please note
 that we are not sure these are the only relevant functions.


 == Given ==

 - For popular websites, caching at exits is highly likely, and DefecTor
 attacks are the same as WF attacks.
 - For unpopular websites, caching and TTLs are moot, since the probability
 of an DNS record being chached is negligible. Caching these records are
 just an extra burden on the exit and in a sense also a risk due to leaking
 recent activity at the exit on compromise. DefecTor attacks will be more
 precise than WF attacks here, and Tor needs WF defenses to mitigate
 (another long-term topic).
 - For long TTLs, for what it is worth, we know from #19025 that the real-
 world impact of ignoring these long TTLs are not a serious issue.
 - For short TTLs, the impact of increasing it is our primary worry since
 we might break something.
 - We want to prevent fine-grained TTLs to protect against tagging attacks.
 - We do not want too high TTLs to have a chance to auto-magically resolve
 DNS cache poisoning.
 - The total size of the cache might be a vector for DoS.
 - The client-side DNS cache remains off.


 == Goals for DefectTor mitigation ==

 - Allow long TTLs to be long(er).
 - For short TTLs, go as far up as we are comfortable to without
 significantly risking breaking things.


 == Proposal ==

 Stage changes: start with repairing the TTL bug #19025 and change clipping
 to 5*60 seconds for MIN_DNS_TTL and 60*60 seconds for MAX_DNS_TTL,
 honoring no intermediate values (see code above). Wait for feedback on
 unexpected breaks. If all manageable, increase MIN_DNS_TTL to 60*60 in a
 future patch, effectively always caching for 60 minutes. If DefecTor
 attacks become a real concern short-term, encourage concerned site owners
 to consider longer TTLs to hit the MAX_DNS_TTL value. Make the cache size
 limited and eviction when full uniformly random. We random to give an
 attacker less control since it can presumably cause evictions at will
 (LIFO is easy to manipulate for an attacker).

 Getting feedback on real-world cache size, usage, and eviction rate from
 exit operators would be useful, so perhaps some form of log output is
 reasonable?

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

Re: [tor-bugs] #21056 [Core Tor/Tor]: Could not pick one of the responsible hidden service directories, because we requested them all recently without success.

[Tor Bug Tracker & Wiki]

#21056: Could not pick one of the responsible hidden service directories, 
because
we requested them all recently without success.
--+
 Reporter:  joeyh |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:   => tor-hs
 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: 0.3.0.x-final


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

[tor-bugs] #21056 [- Select a component]: Could not pick one of the responsible hidden service directories, because we requested them all recently without success.

[Tor Bug Tracker & Wiki]

#21056: Could not pick one of the responsible hidden service directories, 
because
we requested them all recently without success.
--+--
 Reporter:  joeyh |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.2.9.8
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I am seeing connections to hidden services reliably fail, with this in the
 log:

 Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach():
 Got a hidden service request for ID '[scrubbed]'
 Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach():
 Unknown descriptor [scrubbed]. Fetching.
 Dec 21 13:50:16.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2
 rendezvous descriptor for service [scrubbed]
 Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the
 responsible hidden service directories, because we requested them all
 recently without success.
 Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the
 responsible hidden service directories, because we requested them all
 recently without success.
 Dec 21 13:50:16.000 [info] fetch_v2_desc_by_addr(): Could not pick one of
 the responsible hidden service directories to fetch descriptors, because
 we already tried them all unsuccessfully.

 In my test case, I have 2 hidden services running on a machine. Both have
 been started up for the first time in the past 5-10 minutes. On the same
 machine, I open concurrently two socks connections, one to each hidden
 service. Reiably, one of the socks connections succeeds, and the other
 fails. After it starts failing, retries using that onion address continue
 to fail for several minutes.

 Kind of looks like one socks request is breaking the other one. This seems
 similar to #16501 and #15937 but I am pretty sure I am only making 2 socks
 connections, to two different onion addresses.

 Attached log shows this occurring, and then after a while the bad state
 cleared and a retry to connect to the hidden service that it had not been
 able to resolve succeeded.

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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
  |  chelseakomlo
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc, triage-out-030-201612  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by chelseakomlo):

 * status:  assigned => needs_review


Old description:

> Currently, it is easy to submit a patch for code changes without first
> running integration tests locally.
>
> Two changes could help with this:
> 1. Adding this information to documentation for contributors
> 2. Adding a make task that runs all necessary tasks before contributing
> new code, which are:
>
> `make check-spaces`
> `make check .`
> `make test-network-all`
>
> We should investigate how to handle:
> - Someone not having have chutney
> - Someone not having the necessary network connection for integration
> tests to succeed
> - If chutney tests fail because of flakiness (race conditions for
> example) rather than legitimate failures.

New description:

 Currently, it is easy to submit a patch for code changes without first
 running integration tests locally.

 Two changes could help with this:
 1. Adding this information to documentation for contributors
 2. Adding a make task that runs all necessary tasks before contributing
 new code, which are:

 `make check-spaces`
 `make check`
 `make test-network-all`

 We should investigate how to handle:
 - Someone not having have chutney
 - Someone not having the necessary network connection for integration
 tests to succeed
 - If chutney tests fail because of flakiness (race conditions for example)
 rather than legitimate failures.

--

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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
  |  chelseakomlo
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc, triage-out-030-201612  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by chelseakomlo):

 I think this ticket can be closed with only documentation changes. Other
 larger todos, such as fixing Chutney flakiness and incorporating Chutney
 into the Jenkins pipeline, are captured in tickets mentioned above.

 Replying to [comment:12 teor]:

 > I suggest you split this ticket into a subticket for each set of
 changes.
 > * Your changes to the tor documentation could be reviewed by any of the
 current developers, or just given straight to nickm.

 See documentation changes at
 `g...@github.com:chelseakomlo/tor_patches.git`, branch
 `documentation_integ_tests.` This adds the recommendation to run
 integration tests before submitting code patches. It also recommends
 running `make distcheck,` per cypherpunks feedback above.

 > * Your changes to jenkins and docker are best reviewed by people
 familiar with them - I'm not sure who that is, but weasel does admin our
 jenkins instances.

 Great, I opened tickets for these & weasel reviewed. Docker doesn't make
 sense for the Jenkins pipeline, but the PoC is translatable to the work
 required to set up a task to run chutney on every build.

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

Re: [tor-bugs] #21055 [Applications/Tor Browser Sandbox]: Fall back "gracefully" if the Adwaita theme isn't present?

[Tor Bug Tracker & Wiki]

#21055: Fall back "gracefully" if the Adwaita theme isn't present?
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


Comment:

 https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=8aaa94a766a4154be4027a65aa86ad000d696f07

 This works on my Ubuntu 16.04 VM without `gnome-themes-standard`
 installed.  Since that's the only box I have that doesn't have the theme
 or it's assets available, I am marking this as fixed and working.

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

Re: [tor-bugs] #21048 [Applications/Tor Browser Sandbox]: Adwaita theme directory not available in Debian and newer Ubuntu versions

[Tor Bug Tracker & Wiki]

#21048: Adwaita theme directory not available in Debian and newer Ubuntu 
versions
--+-
 Reporter:  qbi   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 I opened #21055 as a consolation prize.

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

Re: [tor-bugs] #20546 [Metrics/CollecTor]: implement CleanUtils

[Tor Bug Tracker & Wiki]

#20546: implement CleanUtils
---+---
 Reporter:  iwakeh |  Owner:  aegis2501
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-help   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by aegis2501):

 Replying to [comment:4 iwakeh]:
 > Great!  Help is very much appreciated.
 >
 > There is a section
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Volunteers#Howtocontribute
 How to contribute] in our wiki.
 > If you have any questions, just ask here.
 >
 > Please assign this ticket to your user name when you start working.
 >
 > Thanks a lot!
 >

 Hi. I think I'm done: https://github.com/aegis2501/CollecTor

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21055 [Applications/Tor Browser Sandbox]: Fall back "gracefully" if the Adwaita theme isn't present?

[Tor Bug Tracker & Wiki]

#21055: Fall back "gracefully" if the Adwaita theme isn't present?
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 It's the "standard" GNOME Gtk2 theme, but apparently some people have
 trouble installing (#21048).

 The code should fall back to no theme, even though the interface will look
 like total dogshit, so people can complain about something else.

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

Re: [tor-bugs] #21048 [Applications/Tor Browser Sandbox]: Adwaita theme directory not available in Debian and newer Ubuntu versions

[Tor Bug Tracker & Wiki]

#21048: Adwaita theme directory not available in Debian and newer Ubuntu 
versions
--+-
 Reporter:  qbi   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


Comment:

 http://packages.ubuntu.com/yakkety/gnome-themes-standard
 http://packages.ubuntu.com/yakkety/gnome-themes-standard-data

 https://packages.debian.org/sid/gnome-themes-standard
 https://packages.debian.org/sid/gnome-themes-standard-data

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

[tor-bugs] #21054 [Core Tor/Tor]: hs: BUG() is triggered with ephemeral service on config reload

[Tor Bug Tracker & Wiki]

#21054: hs: BUG() is triggered with ephemeral service on config reload
--+--
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Normal|   Keywords:  tor-hs, prop224, refactoring
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:  SponsorR-can  |
--+--
 Ticket #20853 introduced the issue with commit
 `63d3ba96f973735ded16e78bd0b8406b6fcdec35` (tor-0.3.0.1-alpha) with:

 {{{
 +if (BUG(rend_service_is_ephemeral(new)) ||
 +BUG(rend_service_is_ephemeral(old))) {
 +  continue;
 }}}

 The new service list does not ONLY contains ephemeral service so if you
 have one regular service and then you add an ephemeral one, a config
 reload will trigger `BUG(rend_service_is_ephemeral(new)` because that
 `new` object is from the global list containing all types of service.

 Furthermore, this whole loop that is suppose to copy the intro points from
 the current service to the newly configured one is broken with that
 commit.

 I'm working on a refactoring to first fix this bug then extract this large
 loop into a function and improve few things along the way _with_ unit
 tests. It is also an important piece of work for #20657 (prop224 service)
 because we'll need it for the v3 service list.

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

Re: [tor-bugs] #21038 [Core Tor/Tor]: configure step and "implicit-function-declaration"

[Tor Bug Tracker & Wiki]

#21038: configure step and "implicit-function-declaration"
--+
 Reporter:  toralf|  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.1-alpha
 Severity:  Minor | Resolution:
 Keywords:  configure gentoo  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 This sounds like a duplicate of #19220.

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

Re: [tor-bugs] #20654 [Applications/Tor Browser]: Language detection IPv6

[Tor Bug Tracker & Wiki]

#20654: Language detection IPv6
--+
 Reporter:  Chuqui|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:  location IPv6 language|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Chuqui):

 What I did though, was uninstall Chrome. Tinfoil hat is out.

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

Re: [tor-bugs] #20654 [Applications/Tor Browser]: Language detection IPv6

[Tor Bug Tracker & Wiki]

#20654: Language detection IPv6
--+
 Reporter:  Chuqui|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:  location IPv6 language|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Chuqui):

 Can't reproduce it now although system didn't change much. I will mark as
 resolved.

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

Re: [tor-bugs] #20654 [Applications/Tor Browser]: Language detection IPv6

[Tor Bug Tracker & Wiki]

#20654: Language detection IPv6
--+
 Reporter:  Chuqui|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:  location IPv6 language|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Chuqui):

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


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

Re: [tor-bugs] #21045 [Core Tor/Tor]: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4

[Tor Bug Tracker & Wiki]

#21045: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4
+--
 Reporter:  downie  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  OSX Tiger 10.4  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by downie):

 I don't know what would be the 'right' flags - the CFLAGS above were given
 to me by someone on the mailing list, and have worked for every previous
 version.
  My previous Tor was 0.2.8.9; it worked with and was compiled with this
 openssl 1.0.2j_0.

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

Re: [tor-bugs] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Oops!  "bug21035", not "bug20135".

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

Re: [tor-bugs] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+

Comment (by tmpname0901):

 Hmmm


  $ git clone -b bug20135 https://git.torproject.org/nickm/tor.git
  Cloning into 'tor'...
  fatal: Remote branch bug20135 not found in upstream origin

 What am I doing wrong here, Nick?

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

Re: [tor-bugs] #20843 [User Experience]: Tor Browser: How do we help users to use higher security?

[Tor Bug Tracker & Wiki]

#20843: Tor Browser: How do we help users to use higher security?
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #21053 [Applications/Tor Browser]: No obvious way to restart Tor after dialog dismissed

[Tor Bug Tracker & Wiki]

#21053: No obvious way to restart Tor after dialog dismissed
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 I agree that we could make this more obvious.  For future reference, the
 "Tor Network Settings" window does display a "Restart Tor" button after
 Tor Launcher detects that tor has exited.

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

Re: [tor-bugs] #20852 [Core Tor/Tor]: prop224: Update HSDir prop224 code based on newest descriptor changes

[Tor Bug Tracker & Wiki]

#20852: prop224: Update HSDir prop224 code based on newest descriptor changes
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224,  TorCoreTeam201612  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by dgoulet):

 Agree. (a) is the priority. I think (b) has its own ticket already for 031
 so if you can do it, great! But I would say not a priority for 030.
 Thanks!

 Side note, this change will bring quite a much bigger descriptor that we
 have now so we should just make sure the current code doesn't actually
 have "max length" check too low.

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

Re: [tor-bugs] #21045 [Core Tor/Tor]: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4

[Tor Bug Tracker & Wiki]

#21045: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4
+--
 Reporter:  downie  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  OSX Tiger 10.4  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 I am afraid I don't know!  Honestly, this is something that I don't
 personally have the hardware to test. It looks like OPENSSL is doing
 something questionable in  OPENSSL_ppc64_probe that triggers an exception
 from your CPU, but I don't know enough about PPC assembly and
 compatibility to figure out what it might be.

 Maybe try compiling your own openssl to see if that helps?

 Oh.  And when you build Tor with "make V=1", do the compiler flags look
 right for PPC?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21053 [Applications/Tor Browser]: No obvious way to restart Tor after dialog dismissed

[Tor Bug Tracker & Wiki]

#21053: No obvious way to restart Tor after dialog dismissed
--+--
 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:|
--+--
 When running Tor Browser 6.5a6-hardened, sometimes the Tor daemon
 disappears (always because of the Linux OOM killer I think). Usually I
 restart from the "Tor unexpectedly exited" dialog and everything is fine,
 but last time I accidentally dismissed that dialog and found no way to
 recover from this situation. I had to restart the browser completely,
 which was annoying because I had tabs open and some text typed in a form
 and I don't want any of this state on disk.

 The "New Identity" and "New Tor Circuit" commands should pop up the "Tor
 exited" dialog if the daemon's not running, because what are they going to
 do otherwise? And how about putting a "restart" button on the "Proxy
 refusing connections" page?

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

Re: [tor-bugs] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Sure!  https://gitweb.torproject.org/nickm/tor.git is the web URL;
 https://git.torproject.org/nickm/tor.git is the URL that you give to git.
 The branch is `bug20135`, which is based on `maint-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] #20852 [Core Tor/Tor]: prop224: Update HSDir prop224 code based on newest descriptor changes

[Tor Bug Tracker & Wiki]

#20852: prop224: Update HSDir prop224 code based on newest descriptor changes
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224,  TorCoreTeam201612  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by asn):

 OK, I did some preliminary investigation for this ticket. IMO, there are
 two steps here:

 == a) Fix the HSDir code to conform to prop224 ==

 Only fixing the HSDir part here is the minimum viable product for 0.3.0,
 so that the network is prepared. It will basically make HSDirs understand
 the newest prop224 format (with `superencrypted` etc.). Since this is
 HSDir-only, we don't need to implement the whole client-auth logic; we
 just need to be able to parse the plaintext part of the descriptor.

 == b) Fix the rest of the descriptor code to conform to prop224 ==

 This part would involve actually implementing the client-auth parts of the
 descriptor, and making clients and hidden services actually be able to
 parse those. IMO, this is a much bigger project than the above, and it's
 not strictly required for 0.3.0 since it belongs to the client/HS code.

 

 My plan is to finish (a) ASAP, and then only do (b) if there is enough
 time.

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

Re: [tor-bugs] #21045 [Core Tor/Tor]: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4

[Tor Bug Tracker & Wiki]

#21045: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4
+--
 Reporter:  downie  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  OSX Tiger 10.4  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by downie):

 Openssl is MacPorts 1.0.2j_0 - the latest. Do you suggest going back a
 version? Will I need to recompile Tor?

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

Re: [tor-bugs] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+

Comment (by tmpname0901):

 > Also, tmpname0901, is this something you can test?

 Sure, I can test it.

 I'm not very familiar with the Tor repository branches. Can you point me
 to your repository?  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] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:  .1
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => .1


Comment:

 Branch `bug21035` in my public repository has a fix here.  It could use
 some review.

 Also, tmpname0901, is this something you can test?

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

Re: [tor-bugs] #21035 [Core Tor/Tor]: Assertion in 0.2.9.8: monotime_coarse_get

[Tor Bug Tracker & Wiki]

#21035: Assertion in 0.2.9.8: monotime_coarse_get
--+
 Reporter:  tmpname0901   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted
 * points:   => .2


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

Re: [tor-bugs] #21052 [Core Tor/Tor]: Bad prop271 behavior when exhausting all guards

[Tor Bug Tracker & Wiki]

#21052: Bad prop271 behavior when exhausting all guards
+--
 Reporter:  asn |  Owner:  nickm
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop271, tor-guard, regression  |  Actual Points:
Parent ID:  #20822  | Points:  1.5
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * points:  0.7 => 1.5


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

Re: [tor-bugs] #21052 [Core Tor/Tor]: Bad prop271 behavior when exhausting all guards

[Tor Bug Tracker & Wiki]

#21052: Bad prop271 behavior when exhausting all guards
+--
 Reporter:  asn |  Owner:  nickm
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop271, tor-guard, regression  |  Actual Points:
Parent ID:  #20822  | Points:  0.7
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * priority:  Medium => High
 * keywords:  prop271, tor-guard => prop271, tor-guard, regression
 * status:  new => accepted
 * owner:   => nickm
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #21045 [Core Tor/Tor]: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4

[Tor Bug Tracker & Wiki]

#21045: Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4
+--
 Reporter:  downie  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.8
 Severity:  Normal  | Resolution:
 Keywords:  OSX Tiger 10.4  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 OSX 10.4 on PPC, huh?  Wow!

 These two together make me think that your openssl might be doing
 something weird:
 {{{
 Exception:  EXC_BAD_INSTRUCTION (0x0002)
 }}}

 {{{
 Thread 0 Crashed:
 0   libcrypto.1.0.0.dylib   0x0120a4e0 OPENSSL_ppc64_probe + 0
 1   libcrypto.1.0.0.dylib   0x0120a744 OPENSSL_cpuid_setup + 196
 }}}

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

Re: [tor-bugs] #21051 [Core Tor/Tor]: configure complains of missing libevent C-headers

[Tor Bug Tracker & Wiki]

#21051: configure complains of missing libevent C-headers
--+
 Reporter:  rainwolf  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Major | Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Hm. Actually, it should probably look for event_base_new rather than
 event_init -- event_init is only a backward compatibility method for the
 libevent 1 API, and we don't support libevent 1 any more.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21052 [Core Tor/Tor]: Bad prop271 behavior when exhausting all guards

[Tor Bug Tracker & Wiki]

#21052: Bad prop271 behavior when exhausting all guards
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop271, tor-guard
Actual Points:|  Parent ID:  #20822
   Points:  0.7   |   Reviewer:
  Sponsor:|
--+
 Here is a weird prop271 behavior. If you get Tor to exhaust all of its
 primary/confirmed/sampled guards, it will just get stuck until a guard
 gets
 marked for retry (which can take half an hour or more).

 Specifically, if you disable the network until Tor starts hitting:
 {{{
 if (guard == NULL) {
   log_warn(LD_GUARD, "Absolutely no sampled guards were available.");
   return NULL;
 }
 }}}
 it will just get stuck in a `"Absolutely no sampled guards were
 available."`
 loop until a guard gets marked for retry.

 In our pre-prop271 guard algorithm, we used to mark all guards as
 retriable if
 we exhaust all of them. I think this is a strictly better behavior than
 just
 waiting until a guard retry timeout triggers.

 Furthermore in our pre-prop271 guard algorithm, when we exhaust all of our
 guards, we mark our network as likely-down. The idea is that if our
 network was
 marked as likely-down and then we managed to connect to a guard, we would
 treat
 that as a network-up event and then start trying guards from the top of
 our
 list.

 This was a pretty effective heuristic that really saved lots of guard
 exposure
 to people with unstable internet. We have a similar one for prop271 but
 it's
 only based on time (get_internet_likely_down_interval() etc.) and not on
 behavior. I think doing
 this old heuristic in prop271 might be a great idea. Here is how it could
 work:

 When we exhaust all our guards, we mark all guards as retriable. The next
 time
 we manage to connect to a guard, we stall the circuit and we call
 mark_primary_guards_maybe_reachable() so that we attempt to connect to our
 primaries again, before using that low-priority guard.

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

Re: [tor-bugs] #21051 [Core Tor/Tor]: configure complains of missing libevent C-headers

[Tor Bug Tracker & Wiki]

#21051: configure complains of missing libevent C-headers
--+
 Reporter:  rainwolf  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Major | Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * priority:  Medium => High
 * keywords:   => regression
 * milestone:   => Tor: 0.2.9.x-final


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

[tor-bugs] #21051 [Core Tor/Tor]: configure complains of missing libevent C-headers

[Tor Bug Tracker & Wiki]

#21051: configure complains of missing libevent C-headers
--+--
 Reporter:  rainwolf  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The configure script aborts with the following output:

 {{{
 WARNING: We found the libraries for libevent, but we could not find the C
 header files.  You may need to install a devel package.
 }}}
 The test that fails complains of an implicit function declaration of
 event_init. This can be resolved by including the headers

 {{{
 event2/event_compat.h
 }}}
 I have attached the patch I used (taken from iCepa) to accomplish this.

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

Re: [tor-bugs] #21050 [Metrics/Onionoo]: Onionoo serves invalid cache headers

[Tor Bug Tracker & Wiki]

#21050: Onionoo serves invalid cache headers
-+--
 Reporter:  lukechilds   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by lukechilds):

 Sorry, where I said

 > the Date header wasn't updated so the max-age was calculated from an old
 date.

 I meant age not max-age

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21050 [Metrics/Onionoo]: Onionoo serves invalid cache headers

[Tor Bug Tracker & Wiki]

#21050: Onionoo serves invalid cache headers
-+--
 Reporter:  lukechilds   |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Onionoo serves invalid cache headers the first time you receive a 304. All
 304 responses after that are ok until the cache max-age is reached. Then
 the next 304 response will have invalid headers and after that it's ok
 again until the new max-age is reached etc.

 They are invalid because the Date header isn't reset once the max-age is
 reached and the Age header carries on incrementing. This results in an age
 that is higher than the max-age, which means the headers are saying the
 content has already expired before it's been sent.

 Example:

 

 Make a request at 09:10:32

 {{{
 Response code: 200
 Date: Wed, 21 Dec 2016 09:10:32 GMT
 Age: 0
 Cache-Control: public, max-age=300
 Last-Modified: Wed, 21 Dec 2016 08:23:36 GMT
 }}}

 AKA This content is from 09:10:32 (now) and you can cache it until
 09:15:32 (5 minutes)

 

 Now lets make a request at 09:15:41, it's been more than 5 minutes so
 we'll set the If-Modified-Since header to see if our cached version is
 still up to date

 {{{
 Response code: 304
 Date: Wed, 21 Dec 2016 09:10:32 GMT
 Age: 309
 Cache-Control: public, max-age=300
 Last-Modified: Wed, 21 Dec 2016 08:23:36 GMT
 }}}

 AKA This content is from 09:15:41 (now) and you can cache it until
 09:15:32 (9 seconds ago).

 So the headers are saying it was out of date 9 seconds before the response
 was sent. It wasn't, it's still fresh, it's just the Date header wasn't
 updated so the max-age was calculated from an old date.

 

 If we make another request with If-Modified-Since set at 09:15:54 (13
 seconds later) everything catches up:

 {{{
 Response code: 304
 Date: Wed, 21 Dec 2016 09:15:41 GMT
 Age: 13
 Cache-Control: public, max-age=300
 Last-Modified: Wed, 21 Dec 2016 08:23:36 GMT
 }}}

 AKA This content is from 09:15:54 (now) and you can cache it until
 09:20:41 (4:47 minutes)

 Notice how the Date header is now correctly set as the date of our
 previous request with the age header calculated from that.

 

 This is technically not abiding by the HTTP protocol:

 https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
 > 14.9 Cache-Control
 >
 > The Cache-Control general-header field is used to specify directives
 that MUST be obeyed by all caching mechanisms along the request/response
 chain.

 In the second request in the example above the max-age in the Cache-
 Control headers is 300 and the age is 309 which means that Onionoos
 caching mechanism isn't obeying the Cache-Control header.

 The end result of this is that the first time a 304 response is sent it
 will never be cached by a client even though the content is still fresh.
 In the above example 3 HTTP requests needed to be made, if the headers
 were set correctly only 2 requests would have been required. Fixing this
 should reduce the amount of traffic that hits the Onionoo server.

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
-+--
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 92.63.88.128:80 has begun refusing connections. Recall that this is the
 server referred to in injected HTTP redirects: `Location:
 http://92.63.88.128/?NTDzLZ`.

 92.63.88.128:22 is still `OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)`.

 {{{
 nmap -v -Pn -A --defeat-rst-ratelimit -oA %Y%m%d-%H%M%S 92.63.88.128

 Nmap scan report for ip88-128.mwtv.lv (92.63.88.128)
 Host is up (0.36s latency).
 Not shown: 744 filtered ports, 255 closed ports
 PORT   STATE SERVICE VERSION
 22/tcp open  ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
 Aggressive OS guesses: Linux 3.11 - 3.13 (94%), Linux 3.2 - 3.8 (91%),
 IPFire firewa
 ll 2.11 (Linux 2.6.32) (90%), Linux 2.6.32 (90%), Linux 3.12 (90%), Linux
 3.1 - 3.2
 (90%), Linux 2.6.18 - 2.6.22 (89%), IGEL UD3 thin client (Linux 2.6)
 (89%), Linux 2.6.35 (89%), DD-WRT v24-sp1 (Linux 2.4) (89%)
 No exact OS matches for host (test conditions non-ideal).
 Uptime guess: 6.225 days (since Wed Dec 14 21:15:51 2016)

 TRACEROUTE (using port 22/tcp)
 HOP RTT   ADDRESS
 1   286.81 ms 10.11.0.1
 2   284.61 ms 185.120.77.1
 3   284.39 ms telecom.gohost.kz (88.204.195.89)
 4   284.50 ms 212.154.195.97
 5   378.69 ms 92.47.151.204
 6   356.39 ms 95.59.172.11
 7   325.15 ms 95.59.172.19
 8   358.67 ms mosc-mx-1.online.kz (92.47.145.110)
 9   360.67 ms msk-ix2.lattelecom.lv (195.208.208.24)
 10  374.88 ms mx960-vl2000.telenet.lv (91.90.239.21)
 11  360.95 ms 195.13.238.30
 12  361.16 ms ip88-128.mwtv.lv (92.63.88.128)
 }}}

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
-+--
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 > NX01

 Detected in kz 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

[tor-bugs] #21049 [Internal Services/Tor Sysadmin Team]: Make some of torproject.org's onion services into single onion services

[Tor Bug Tracker & Wiki]

#21049: Make some of torproject.org's onion services into single onion services
-+-
 Reporter:  arma |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 https://blog.torproject.org/blog/whats-new-tor-0298#comment-226818
 asks "Which of the services listed in onion.torproject.org
 (http://yz7lpwfhhzcdyc5y.onion/) are single hop services?"

 I think that's a great question. I think the answer right now is "none",
 but we could change that. Should we?

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

Re: [tor-bugs] #21048 [Applications/Tor Browser Sandbox]: Adwaita theme directory not available in Debian and newer Ubuntu versions

[Tor Bug Tracker & Wiki]

#21048: Adwaita theme directory not available in Debian and newer Ubuntu 
versions
--+-
 Reporter:  qbi   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 On my jessie, I have that theme in this package:

 {{{
 $ dpkg -l|grep adwaita
 ii  adwaita-icon-theme  3.14.0-2
 }}}

 Looks like it's here?
 https://packages.debian.org/search?keywords=adwaita-icon-theme

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21048 [Applications/Tor Browser Sandbox]: Adwaita theme directory not available in Debian and newer Ubuntu versions

[Tor Bug Tracker & Wiki]

#21048: Adwaita theme directory not available in Debian and newer Ubuntu 
versions
--+-
 Reporter:  qbi   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I cloned {{{480a7c13406cf12a0cd71910a8b36c9c48a6c0c4}}} from git,
 installed dependencies and make'd the package. When I started sandboxed-
 tor-browser the following message appeared:

 {{{
 launch: Failing with error: sandbox: roBind source does not exist:
 /usr/share/themes/Adwaita/gtk-2.0
 }}}

 I run Debian unstable on this machine. So I tried to find a package which
 contains this path
 {{{
 > dpkg -S /usr/share/themes/Adwaita
 dpkg-query: no path found matching pattern /usr/share/themes/Adwaita
 }}}
 Also on an Ubuntu machine I couldn't find a package. The documentation at
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux
 recommends gnome-themes-standard. While the package in Ubuntu 12.04 uses
 this path all other versions don't seem to use 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] #20778 [Applications/Tor Browser Sandbox]: Check and download updates in the background.

[Tor Bug Tracker & Wiki]

#20778: Check and download updates in the background.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  accepted
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Yawning201612 |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 I think Tor Browser does its checks every 12 hours? It would be nice to
 match their schedule, since I think the metrics folks have been planning
 to estimate extant Tor Browser users by counting update checks and
 dividing by 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] #20995 [Core Tor/Tor]: Clean up tickets with incorrect milestones

[Tor Bug Tracker & Wiki]

#20995: Clean up tickets with incorrect milestones
--+---
 Reporter:  cypherpunks   |  Owner:
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Right before i made this ticket, nickm deleted the `Tor 0.3.???` milestone
 which solved part of the problem. My initial thought for this ticket was
 changing the milestone of these tickets to the proper milestone in which
 some of them were implemented. I realize this is too much work for too
 little gain.

 Instead I'd like to suggest to move the tickets from the `Tor: very long
 term` milestone to the `Tor: unspecified` milestone and delete the former.
 Both milestones are very similar and the later seems to be used more.

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