[tor-bugs] #23043 [Obfuscation/BridgeDB]: leekspin's except/error code handling in generator.py is strange

[Tor Bug Tracker & Wiki]

#23043: leekspin's except/error code handling in generator.py is strange
--+--
 Reporter:  Samdney   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Minor |   Keywords:  leekspin
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In /leekspin/generator.py you have in "def
 createRelayOrBridgeDescriptors(...)"

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   def createRelayOrBridgeDescriptors(count, bridge=True, **kwargs):
 ...
 try:
   ...
 except KeyboardInterrupt as keyint:
   logging.warn("Received keyboard interrupt.")
   logging.warn("Stopping descriptor creation and exiting.")
   code = 1515
 finally:
   ...
   logging.info("Done.")
   code = 0
   sys.exit(code)
   }}}
 }}}

 The same in a similiar way also in "def
 createHiddenServiceDescriptors(...)"

 I think your way of handling the code-variable isn't right. If you have an
 Keyboard exception if follows: code = 1515. But the "try ... except ...
 finally" - block always "finally" execute the code within the finally
 block. So it will always exit with code = 0, sys.exit(0)!

 In generally, the execution of (some) parts of the finally block after an
 keyboard interruption makes no sense for me.

 (I haven't found time to examinate the full source code until now. Hence,
 for the case that all has a good reason, please ignore me :)

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

Re: [tor-bugs] #23042 [Internal Services/Service - lists]: emails to the wtf@ email list are bouncing

[Tor Bug Tracker & Wiki]

#23042: emails to the wtf@ email list are bouncing
---+-
 Reporter:  t0mmy  |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords:  wtf|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by arma):

 Your screenshot says "toproject.org".

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

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
+--
 Reporter:  asn |  Owner:
|  mikeperry
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery  |  Actual Points:
Parent ID:  #9001   | Points:
 Reviewer:  |Sponsor:
|  SponsorV-can
+--

Comment (by mikeperry):

 Just FYI - I updated asn's branch to current origin/master and renamed the
 option to HSLayer2Guards. It also now applies to all HS circuit purpose
 types (not just rends).

 New branch location is mikeperry/prop247_torrc-rebased.

 Adding HSLayer3Guards next. After that, we can play with stem + onionperf.

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

Re: [tor-bugs] #22947 [Webpages/Blog]: Possible Security Issue (Information Disclosure) with Drupal on blog.torproject.org

[Tor Bug Tracker & Wiki]

#22947: Possible Security Issue (Information Disclosure) with Drupal on
blog.torproject.org
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  security   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 After searching found this to be the same error message I got: #22850

 I bet this ticket is a duplicate and the OP got the same message as us.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23042 [Internal Services/Service - lists]: emails to the wtf@ email list are bouncing

[Tor Bug Tracker & Wiki]

#23042: emails to the wtf@ email list are bouncing
---+-
 Reporter:  t0mmy  |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:  wtf
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-


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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201707R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mcs):

 Replying to [comment:11 pospeselr]:
 > I can go through another round, fix these issues, and upload a new patch
 if you like (while disabling sublime's 'trim trailing white-space'
 option).

 If you can quickly produce a new patch, please proceed. But maybe it makes
 sense to wait for feedback from another member of our team. gk, please let
 pospeselr know if you want a revised patch right away.

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

Re: [tor-bugs] #17639 [Core Tor/Tor]: provide an option to display the expiry date of a given ed25519 signing key

[Tor Bug Tracker & Wiki]

#17639: provide an option to display the expiry date of a given ed25519 signing 
key
+--
 Reporter:  cypherpunks |  Owner:  isis
 Type:  enhancement | Status:
|  needs_revision
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.7.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-ed25519-proto, review-group-21  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  nickm   |Sponsor:
+--
Changes (by nickm):

 * status:  needs_information => needs_revision


Comment:

 I vote for something like
 {{{
 signing-cert-expiry: 2017-07-25 08:30:15 UTC
 }}}
 for the output format, and document that you need to grep for the signing-
 cert-expiry.

 I guess that's probably enough, plus the manpage.  What do you think?

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201707R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pospeselr):

 Thanks for the feedback!

 In regards to the ToNewUnicode() call, it looks like you are completely
 correct!  Not only is it less C++ code but the generated machine code is
 shorter too: https://godbolt.org/g/hyurar

 Generated code for when that link eventually dies (gcc version 7.1 with
 -03):
 {{{
 ; int func_local(void** aPtr)
 ; {
 ; if(!aPtr)
 ; {
 ; return FAILURE;
 ; }
 ; auto ptr = get_ptr();
 ; if(ptr)
 ; {
 ; *aPtr = ptr;
 ; return SUCCESS;
 ; }
 ; *aPtr = nullptr;
 ; return FAILURE;
 ; }
 func_local(void**):
 testrdi, rdi
 je  .L7
 pushrbx
 mov rbx, rdi
 callget_ptr()
 testrax, rax
 je  .L6
 mov QWORD PTR [rbx], rax
 xor eax, eax
 pop rbx
 ret
 .L7:
 mov eax, -1
 ret
 .L6:
 mov QWORD PTR [rbx], 0
 mov eax, -1
 pop rbx
 ret

 ; int func_ptr(void** aPtr)
 ; {
 ; if(!aPtr)
 ; {
 ; return FAILURE;
 ; }
 ; *aPtr = get_ptr();
 ; if(*aPtr)
 ; {
 ; return SUCCESS;
 ; }
 ; return FAILURE;
 ; }
 func_ptr(void**):
 testrdi, rdi
 je  .L14
 pushrbx
 mov rbx, rdi
 callget_ptr()
 testrax, rax
 mov QWORD PTR [rbx], rax
 seteal
 movzx   eax, al
 neg eax
 pop rbx
 ret
 .L14:
 mov eax, -1
 ret
 }}}

 I can go through another round, fix these issues, and upload a new patch
 if you like (while disabling sublime's 'trim trailing white-space'
 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] #22636 [Core Tor/Tor]: Add Travis configs so GitHub forks get CI coverage

[Tor Bug Tracker & Wiki]

#22636: Add Travis configs so GitHub forks get CI coverage
-+-
 Reporter:  catalyst |  Owner:
 |  patrickod
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci testing|  implemented
  best-practice unit-testing new-developers  |  Actual Points:  1
  travis review-group-21 |
Parent ID:   | Points:  .5
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 {{{
 m
  e
   r
g
 e
  d
 }}}
 !

 Now let's see what happens.

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

Re: [tor-bugs] #22947 [Webpages/Blog]: Possible Security Issue (Information Disclosure) with Drupal on blog.torproject.org

[Tor Bug Tracker & Wiki]

#22947: Possible Security Issue (Information Disclosure) with Drupal on
blog.torproject.org
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  security   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Different person from the OP but I got this error message show up after
 posting a comment:

 {{{
 Warning: mkdir(): File exists in
 Drupal\Component\PhpStorage\FileStorage->createDirectory() (line 157 of
 core/lib/Drupal/Component/PhpStorage/FileStorage.php).
 }}}

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

Re: [tor-bugs] #22542 [Applications/Tor Browser]: Tor Browser 7.0 Security Settings Window too small on macOS 10.12

[Tor Bug Tracker & Wiki]

#22542: Tor Browser 7.0 Security Settings Window too small on macOS 10.12
-+-
 Reporter:  teor |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-security-slider, TorBrowserTeam201707R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by brade):

 I replied to the comment in oniongit.

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

Re: [tor-bugs] #17639 [Core Tor/Tor]: provide an option to display the expiry date of a given ed25519 signing key

[Tor Bug Tracker & Wiki]

#17639: provide an option to display the expiry date of a given ed25519 signing 
key
+--
 Reporter:  cypherpunks |  Owner:  isis
 Type:  enhancement | Status:
|  needs_information
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.7.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-ed25519-proto, review-group-21  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  nickm   |Sponsor:
+--
Changes (by isis):

 * status:  needs_revision => needs_information


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

Re: [tor-bugs] #17639 [Core Tor/Tor]: provide an option to display the expiry date of a given ed25519 signing key

[Tor Bug Tracker & Wiki]

#17639: provide an option to display the expiry date of a given ed25519 signing 
key
+--
 Reporter:  cypherpunks |  Owner:  isis
 Type:  enhancement | Status:
|  needs_revision
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.7.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-ed25519-proto, review-group-21  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  nickm   |Sponsor:
+--

Comment (by isis):

 Replying to [comment:23 nickm]:
 > This looks comparatively solid to me!  A few things to consider as
 possibilities, though maybe they're not needed:
 >
 >  - Maybe this should printf() something to stdout, instead of using the
 log facility, and run at --quiet by default?

 Yes, this makes sense. TBH, I didn't know if I was allowed/encouraged to
 do printf(), since it seems like there's a lot of ways "interfaces" over
 stdin/stdout can be bad/broken/wrong, particularly when they are relied
 upon by other scripts/programs (cf. gnupg). I think it does make sense
 though to work even with --quiet, and in this case the user is asking a
 question like "hey parse this thing and tell me what it says", not
 intending any operation or for the binary to run as a daemon or anything
 more complicated, so it makes sense here.

 >  - Maybe the output format should be machine-readable?

 Yeah! But what should this look like?

 Literally just spit out the expiry in ISO8601 format? (With or without the
 underscore in between the date and the time?) Or some more easily machine
 parseable (but less human readable) format, like seconds-since-epoch?

 Should it be in the local timezone, or in UTC? (Probably UTC, right? if we
 expect scripts to be able to process it?)

 >  - Maybe it should dump information about the installed authority auth
 key as well
 >  - I wonder what it should do about hidden service keys?

 Yes, I can add these. I thought about the first one before, but I didn't
 know how to make the interface, plus had worries about the patch being
 large/invasive. I think the "proper" way to do it would be to add a
 suboptions parser so that the user could be like "--key-expiration auth"
 or "--key-expiration sign"; this way, it would more easily extendable to
 further changes in supported cert types moving forward.

 I'm not sure what to do about onion service keys/certs at all. I imagine
 there are users with multiple hidden services. Frankly, I didn't even know
 OS keys/certs ''could'' expire. Is that just a v2 thing? Is there some
 canonical way to refer to an onion service such that I could provide some
 option like "--key-expiration specifier-for-my-onion-service"? Should I
 optionally take an onion service's address and learn the keys from the
 configured onion service directory?

 >  - Technically speaking, keys don't expire: certificates do. The user
 needs to replace both of them, not just one.

 Right. How should we communicate this to users? I'm not a UX person at
 all, but I can vaguely naïvely foresee confusion of like "but I was asking
 about my keys".  Should I change to the cmdline flag to --cert-expiration?

 >  - The buffer in log_ed_key_expiration() can probably just be stack-
 allocated.

 Yep, done in `cc2af48569`.

 >  - Documentation on the new option should go into the manpage

 Yeah… it would probably be the nice thing to do to tell operators how to
 use it. :) I will add this once we agree on what the commandline flags and
 output should be like.

 > Please fix whatever from above you agree with. :)

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

Re: [tor-bugs] #21321 [Applications/Tor Browser]: .onion HTTP is shown as non-secure in Tor Browser

[Tor Bug Tracker & Wiki]

#21321: .onion HTTP is shown as non-secure in Tor Browser
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  ff52-esr, tbb-7.0-issues, tbb-   |  Actual Points:
  usability, ux-team, TorBrowserTeam201707R, |
  GeorgKoppen201707, tbb-7.0-frequent|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by brade):

 I added a comment in oniongit.

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201707R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * status:  needs_review => needs_revision


Comment:

 I was unable to apply the 13398-pospeselr.patch; it looks like trailing
 whitespace has been removed from the patch. In any case, we typically
 avoid touching lines that we are not otherwise changing because larger
 patches are more work to maintain (but hopefully we can convince Mozilla
 to accept this patch upstream).

 After I manually applied the patch, I then encountered a linker error
 while building on OSX (I attempted a non-gitian build). To fix the
 problem, I had to add an empty destructor to
 `toolkit/components/startup/nsUserInfoMac.mm`:
 {{{
 nsUserInfo::~nsUserInfo() {}
 }}}
 Using userinfotest.xpi I verified that the fix is effective. Good work!

 I have mixed feelings about refactoring the OSX nsUserInfo implementation.
 This seems like a good clean up, but this also may make patch maintenance
 more difficult.

 Please match the style of most other Mozilla code for the `if` statements
 (include a space after `if`).

 In the code that calls `ToNewUnicode()` it would be slightly more compact
 to directly assign to the output parameter, e.g.,
 {{{
 NS_IMETHODIMP
 nsUserInfo::GetFullname(char16_t** aFullname)
 {
   NS_ENSURE_ARG_POINTER(aFullname);

   if (sHideUserInfo) {
 *aFullname = ToNewUnicode(NS_LITERAL_STRING(""));
 if (aFullname) {
   return NS_OK;
 }

 return NS_ERROR_FAILURE;
   }

   return this->GetFullnameImpl(aFullname);
 }
 }}}

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

Re: [tor-bugs] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

[Tor Bug Tracker & Wiki]

#22865: Explicitly set Content-Length to zero when there is no data to send
--+
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

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


Comment:

 I merged your patch and made a new tag [https://gitweb.torproject.org
 /pluggable-transports/meek.git/tag/?h=0.28 0.28].

 Thanks for your help in understanding this tricky issue.

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

Re: [tor-bugs] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

[Tor Bug Tracker & Wiki]

#22865: Explicitly set Content-Length to zero when there is no data to send
--+-
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

 * status:  needs_review => merge_ready


Comment:

 Thanks to your example code, I was finally able to reproduce the 411
 "Length Required" error, and I think I have traced the source of the
 problem. It comes down to http2 not treating body==http.NoBody the same as
 body==nil in Go 1.8. Even though http.NewRequest correctly special-cases
 *bytes.Reader, sets req.ContentLength = 0, and sets req.Body = http.NoBody
 (as noted in comment:9), the http2 code doesn't recognize http.NoBody as
 being special, and resets req.ContentLength = -1, which causes the
 Content-Length header to be omitted when it should be included.
 [https://github.com/golang/net/commit/973f3f3bbd50e92b13faa6c53ec16f49b45e851c
 A change] to make body==http.NoBody and body==nil have the same meaning in
 the http2 code is not due until Go 1.9.

 The fix is attachment:0001-Explicitly-set-Content-Length-to-zero-when-
 there-is-.patch, which sets body = nil. Setting body = http.NoBody, which
 would seem to even more clearly signal an empty body, does ''not'' work,
 for the reasons explained above.

 The problem occurs only when:
  * Using HTTP/2
  * Sending a 0-length body
 In the case of App Engine, you additionally have to be:
  * Using the App Engine flexible environment (not the standard
 environment)
  * Domain fronting (as mentioned in comment:6)

 Here is the go commit that added http.NoBody (it's the resolution of https
 ://go-review.googlesource.com/c/31445/ from the ticket description).
 Notice how they expand `r.Body == nil` into `r.Body == nil || r.Body ==
 NoBody`—but only for http code, not http2.
 [https://github.com/golang/go/commit/b992c391d4aae64e147fc64c77ad41d61be8e2e7
 net/http: add NoBody, don't return nil from NewRequest on zero bodies]
 Here is a bug report about http2 not honoring http.NoBody, and the ensuing
 code change (that is not in Go 1.8):
   https://github.com/golang/go/issues/18891
 [https://github.com/golang/net/commit/973f3f3bbd50e92b13faa6c53ec16f49b45e851c
 #diff-afca25314e6df5ed75ab7a17d573b254 http2: make Transport treat
 http.NoBody like it were nil]
 The important diff is
 [https://github.com/golang/net/commit/973f3f3bbd50e92b13faa6c53ec16f49b45e851c
 #diff-afca25314e6df5ed75ab7a17d573b254 here], which causes
 
[https://github.com/golang/net/blob/973f3f3bbd50e92b13faa6c53ec16f49b45e851c/http2/transport.go#L693
 actualContentLength] to return 0 instead of -1 for http.NoBody. The value
 of 0 in turn causes
 
[https://github.com/golang/net/blob/973f3f3bbd50e92b13faa6c53ec16f49b45e851c/http2/transport.go#L1168
 shouldSendReqContentLength] to return true instead of false.

 I made a [[attachment:demo.go|demo program]] that demonstrates all the
 possibilities. It allows you to represent an empty body as a 0-length
 *strings.Reader (the default), a nil pointer (`-nil` option), or
 http.NoBody (`-nobody` option). It additionally allows you to set a front
 domain with the `-front` option.

  * example.com (only nil or non-empty body works)
{{{
 $ ./demo https://example.com/ ""
 HTTP/2.0 411 Length Required
 $ ./demo -nil https://example.com/ ""
 HTTP/2.0 200 OK
 $ ./demo -nobody https://example.com/ ""
 HTTP/2.0 411 Length Required
 $ ./demo https://example.com/ "content"
 HTTP/2.0 200 OK
 }}}
  * App Engine flexible environment without front domain (everything works)
{{{
 $ ./demo https://xxx.appspot.com/ ""
 HTTP/2.0 200 OK
 $ ./demo -nil https://xxx.appspot.com/ ""
 HTTP/2.0 200 OK
 $ ./demo -nobody https://xxx.appspot.com/ ""
 HTTP/2.0 200 OK
 $ ./demo https://xxx.appspot.com/ "content"
 HTTP/2.0 200 OK
 }}}
  * App Engine flexible environment with front domain (only nil or non-
 empty body works)
{{{
 $ ./demo -front www.google.com https://xxx.appspot.com/ ""
 HTTP/2.0 411 Length Required
 $ ./demo -front www.google.com -nil https://xxx.appspot.com/ ""
 HTTP/2.0 200 OK
 $ ./demo -front www.google.com -nobody https://xxx.appspot.com/ ""
 HTTP/2.0 411 Length Required
 $ ./demo -front www.google.com https://xxx.appspot.com/ "content"
 HTTP/2.0 200 OK
 }}}

 You can get a lot of HTTP/2 debugging info by setting
 `GODEBUG=http2debug=1` in the environment. Here we can see that the header
 `"content-length" = "0"` is not encoded when using a 0-length Reader, but
 it when using nil:
 {{{
 $ GODEBUG=http2debug=1 ./demo https://example.com/ ""
 2017/07/26 11:13:53 http2: Transport failed to get 

Re: [tor-bugs] #23041 [Webpages/Website]: Add new press clips to website

[Tor Bug Tracker & Wiki]

#23041: Add new press clips to website
--+-
 Reporter:  steph |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by steph):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23041 [Webpages/Website]: Add new press clips to website

[Tor Bug Tracker & Wiki]

#23041: Add new press clips to website
--+-
 Reporter:  steph |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Add new clips from attached .csv to the press page. Link article titles to
 URLs and follow page formatting:
 https://www.torproject.org/press/press.html.en

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

Re: [tor-bugs] #23030 [Core Tor/Tor]: Review coverity build warnings

[Tor Bug Tracker & Wiki]

#23030: Review coverity build warnings
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport 030-backport|  Actual Points:  .1
  031-backport coverity  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.2.9.x-final


Comment:

 Cherry-picked to bug23030_029_v2 and merged to 0.2.9 and forward.

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail with libzstd 1.3.0

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail with libzstd 1.3.0
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-dir, review-group-21  |  Actual Points:  1
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 thanks; merged to 0.3.1 and forward.

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

Re: [tor-bugs] #22915 [Core Tor/Tor]: clang 4.0 double promotion warnings in clamp_double_to_int64()

[Tor Bug Tracker & Wiki]

#22915: clang 4.0 double promotion warnings in clamp_double_to_int64()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-21  |
Parent ID:   | Points:  .1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Fixed and merged; 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] #20247 [Core Tor/Tor]: seccomp2 crash after closing and opening ipv6 DirPort + OrPort

[Tor Bug Tracker & Wiki]

#20247: seccomp2 crash after closing and opening ipv6 DirPort + OrPort
-+-
 Reporter:  toralf   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.8
 Severity:  Normal   | Resolution:
 Keywords:  easy, crash, 028-backport, ipv6, |  Actual Points:
  review-group-21|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

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

Re: [tor-bugs] #22915 [Core Tor/Tor]: clang 4.0 double promotion warnings in clamp_double_to_int64()

[Tor Bug Tracker & Wiki]

#22915: clang 4.0 double promotion warnings in clamp_double_to_int64()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-backport, review-group-21  |
Parent ID:   | Points:  .1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

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


Comment:

 Minor typo in a comment:

 {{{
 since clang things we're promoting a double to a long double.
 }}}

 should be:

 {{{
 since clang thinks we're promoting a double to a long double.
 }}}

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

Re: [tor-bugs] #22883 [Core Tor/Tor]: Bridge unavailable during differential consensus update

[Tor Bug Tracker & Wiki]

#22883: Bridge unavailable during differential consensus update
-+-
 Reporter:  torvlnt33r   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, usage, review-  |  Actual Points:  1
  group-21   |
Parent ID:   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 The more complex approach looks good to me as well. There is a minor typo
 in a docstring that should be fixed before this land in the repository.

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

Re: [tor-bugs] #22428 [Metrics/CollecTor]: add webstats module to collector

[Tor Bug Tracker & Wiki]

#22428: add webstats module to collector
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git?h=task-22428 this
 branch] with the webstats implementation.
 It depends on the functionality provided in metrics-lib task #22983.

 It implements local import with log-sanitation as well as sync-
 functionality.
 The commits try to make the different steps clear.

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

Re: [tor-bugs] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  new => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/log/?h=task-22983 this branch].

 The [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22983=20a9f82d06adbf960f1da8ff9853e50c5c1c5e25
 first commit] adds the new interfaces and their implementations.

 LogDescriptor contains all methods that will be hopefully applicable for
 all log-types possible.
 WebServerAccessLog is the specialization for access-logs.

 LogDescriptor also offers a sub-interface:
 {{{
/**
* Providing a single function for removing sensitive data from a
* given Apache Access Log log line.
*/
   public interface Sanitizer {

 /** Returns a cleaned log line, i.e., without possibly privacy
  * sensitive values. */
 public String clean(String line);
   }
 }}}

 and a method `sanitize()`.  The latter applies the cleaning procedure to
 all log lines and sorts the resulting lines.  The default sanitizer
 returns the line w/o any changes.  This setup keeps all descriptor
 parsing, compression, un-compression in metrics-lib; CollecTor is not
 forced to re-implement parsing functionality and only needs to provide the
 log cleaning procedure.  (A similar approach could be thought up for
 bridge-sanitation, too.)

 The [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22983=d4ece5649573f315a8c63f43e490c3594f35affd
 second commit] makes `DescriptorParser` aware of the new types and avoids
 implementation javadoc comment generation for the new package.

 All of the code is covered by tests which are added in
 [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22983=e07bca5e9429b2b93bb2cd3c0ef6911ad42ec32e
 this commit].  Total coverage even improved by one percent :-)

 The addition of another sub-interface `LogDescriptor.LogLine` (and the
 extensions to WebServerAccessLogLine) will be part of a new ticket, which
 will also provide unrecognized lines for access-logs.

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

Re: [tor-bugs] #22927 [Core Tor/Tor]: zstd tests fail with libzstd 1.3.0

[Tor Bug Tracker & Wiki]

#22927: zstd tests fail with libzstd 1.3.0
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dir, review-group-21  |  Actual Points:  1
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

Re: [tor-bugs] #15421 [Core Tor/Tor]: Relay crash when reloading and resolv.conf is empty

[Tor Bug Tracker & Wiki]

#15421: Relay crash when reloading and resolv.conf is empty
-+-
 Reporter:  TvdW |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay resolv.conf  dns dos-  |  Actual Points:
  maybe  |
Parent ID:  #21900   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 Yup. It's Ubuntu 16.04.

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

Re: [tor-bugs] #15421 [Core Tor/Tor]: Relay crash when reloading and resolv.conf is empty

[Tor Bug Tracker & Wiki]

#15421: Relay crash when reloading and resolv.conf is empty
-+-
 Reporter:  TvdW |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay resolv.conf  dns dos-  |  Actual Points:
  maybe  |
Parent ID:  #21900   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-relay resolv.conf  dns => tor-relay resolv.conf  dns dos-
 maybe
 * milestone:  Tor: unspecified => Tor: 0.3.3.x-final


Comment:

 This could be a potential DoS risk if DNS goes down for an exit, and it is
 HUP'ed while DNS its down. It would be nice to get it fixed in the next
 year or so.

 Damian, can you confirm that your system is non-macOS?

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

Re: [tor-bugs] #21900 [Core Tor/Tor]: evdns fails when resolv.conf is missing, but succeeds when resolv.conf is empty

[Tor Bug Tracker & Wiki]

#21900: evdns fails when resolv.conf is missing, but succeeds when resolv.conf 
is
empty
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, dns, crash, tor- |  Actual Points:
  relay, macos   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:1 teor]:
 > This is not such an important crash, because it only happens on
 platforms which remove resolv.conf (which as far as I know, is only macOS
 when the network is down). And I think it only happens on relays, not
 clients. But it would still be nice to fix it.

 Turns out this happens with some Linux configs, too.

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

Re: [tor-bugs] #15421 [Core Tor/Tor]: Relay crash when reloading and resolv.conf is empty

[Tor Bug Tracker & Wiki]

#15421: Relay crash when reloading and resolv.conf is empty
+--
 Reporter:  TvdW|  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.7.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay resolv.conf  dns  |  Actual Points:
Parent ID:  #21900  | Points:  small
 Reviewer:  |Sponsor:
+--

Comment (by atagar):

 Hi there, yesterday I ran into an issue that looks like this too. Here's
 the repro steps I provided from #23036 with the latest git tip (tor commit
 bb66a48).

 **Repro steps:**

 * Start system without a network connection.

 * Start tor, torrc I used was...

 {{{
 % cat ~/.tor/torrc
 ControlPort 9051
 ExitPolicy reject *:*
 }}}

 * Set the ORPort with "SETCONF ORPort=9090".

 **Result:**

 Tor process terminates with...

 {{{
 Jul 25 19:21:33.000 [warn] ControlPort is open, but no authentication
 method has been configured.  This means that any program on your computer
 can reconfigure your Tor.  That's bad!  You should upgrade your Tor
 controller as soon as possible.
 Jul 25 19:21:33.000 [notice] Opening OR listener on 0.0.0.0:9090
 Jul 25 19:21:33.000 [notice] You are running a new relay. Thanks for
 helping the Tor network! If you wish to know what will happen in the
 upcoming weeks regarding its usage, have a look at
 https://blog.torproject.org/blog/lifecycle-of-a-new-relay
 Jul 25 19:21:33.000 [notice] It looks like I need to generate and sign a
 new medium-term signing key, because I don't have one. To do that, I need
 to load (or create) the permanent master identity key. If the master
 identity key was not moved or encrypted with a passphrase, this will be
 done automatically and no further action is required. Otherwise, provide
 the necessary data using 'tor --keygen' to do it manually.
 Jul 25 19:21:33.000 [notice] Your Tor server's identity key fingerprint is
 'Unnamed 4853AB6F9215A837EA3562CF4AF00713737FDF01'
 Jul 25 19:21:33.000 [warn] Unable to parse '/etc/resolv.conf', or no
 nameservers in '/etc/resolv.conf' (6)
 Jul 25 19:21:33.000 [err] set_options(): Bug: Acting on config options
 left us in a broken state. Dying. (on Tor 0.3.2.0-alpha-dev
 bb66a48541aa5110)
 }}}

 Cheers! -Damian

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

Re: [tor-bugs] #23036 [Core Tor/Tor]: 'SETCONF ORPort' crashes tor without network

[Tor Bug Tracker & Wiki]

#23036: 'SETCONF ORPort' crashes tor without network
--+---
 Reporter:  atagar|  Owner:
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

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


Comment:

 Certainly sounds like it - thanks Nick! I'll dedup with that and note the
 repro steps there.

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

Re: [tor-bugs] #23030 [Core Tor/Tor]: Review coverity build warnings

[Tor Bug Tracker & Wiki]

#23030: Review coverity build warnings
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:  .1
  031-backport coverity  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Hard to test locally, but looks good to me. Let's get it in and see how
 Coverity handles 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

[tor-bugs] #23040 [Webpages/Website]: job post for tor browser mobile (android)

[Tor Bug Tracker & Wiki]

#23040: job post for tor browser mobile (android)
--+-
 Reporter:  isabela   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Please add this job post to the website (this is a different position from
 the current one that we have there !https://www.torproject.org/about/jobs-
 browserdeveloper.html.en):

 !https://pad.riseup.net/p/Ym1PUFJGEXP2

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

Re: [tor-bugs] #23036 [Core Tor/Tor]: 'SETCONF ORPort' crashes tor without network

[Tor Bug Tracker & Wiki]

#23036: 'SETCONF ORPort' crashes tor without network
--+-
 Reporter:  atagar|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by nickm):

 Thanks, Damian!  Could this be a duplicate of #15421?

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

Re: [tor-bugs] #23037 [Webpages/Website]: Search.TorProject.org

[Tor Bug Tracker & Wiki]

#23037: Search.TorProject.org
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Why do you think this would be a good idea? There's already DuckDuckGo by
 default which does its job pretty well. I don't think they have the
 resources to do and maintain such a task.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23039 [Applications/Tor Browser]: Make the rbm build system work with runc 1.0.0

[Tor Bug Tracker & Wiki]

#23039: Make the rbm build system work with runc 1.0.0
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #17379
   Points:|   Reviewer:
  Sponsor:|
--+
 The new build system has been tested with runc 0.1.1 (which is the version
 included in Debian stretch, and jessie-backports). However version 1.0.0
 (Debian sid currently has version 1.0.0~rc2) includes some incompatible
 changes, so we will need to adapt how we use runc to make that work.

 In version 1.0.0, the `runc start` command has been replaced by `runc
 run`:
 
https://github.com/opencontainers/runc/commit/c669b8d1568633c68bd915561ceb2e5ecc1bfc6a

 We will need to detect which version of runc is installed to use the
 correct command.

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

Re: [tor-bugs] #22288 [Metrics/Metrics website]: Use newly recognized OnionPerf keys

[Tor Bug Tracker & Wiki]

#22288: Use newly recognized OnionPerf keys
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * priority:  Medium => High


Comment:

 Ugh, looks like we forgot this ticket, and after updating to a metrics-lib
 version that recognizes the new OnionPerf keys and hence does not include
 them in `getUnrecognizedKeys()` anymore, the
 
[https://metrics.torproject.org/torperf.html?start=2017-04-27=2017-07-26=all=onion=50kb
 onion server graph] is all empty since mid-May. Raising priority to 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] #19001 [Obfuscation/Snowflake]: Tor Browser with Snowflake

[Tor Bug Tracker & Wiki]

#19001: Tor Browser with Snowflake
---+-
 Reporter:  dcf|  Owner:
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by dcf):

 I made a post on the discuss-webrtc list explaining our process for cross-
 compiling libwebrtc for mac.
   https://groups.google.com/d/msg/discuss-webrtc/ca_R9ocEHus/LWhtmhhPAwAJ

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23038 [- Select a component]: Failure to install via my mirror/ISP???

[Tor Bug Tracker & Wiki]

#23038: Failure to install via my mirror/ISP???
--+-
 Reporter:  Birdclaw  |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This is the first time I have used tor on my main linux machine: downlaods
 well BUT with the current ISP I cannot seem to install it. I want to learn
 how to use this, as I have concerns about privacy. Masyb e I am just a
 fool trying to be clever? What gives? This is a great piece of
 software...donated once before, and will agian!

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