1. 27 Nov, 2018 7 commits
  2. 26 Nov, 2018 2 commits
  3. 21 Nov, 2018 1 commit
  4. 05 Nov, 2018 2 commits
  5. 10 Jun, 2018 1 commit
    • David Fifield's avatar
      Log to io.Discard if no log file is set. · 6077141f
      David Fifield authored
      https://bugs.torproject.org/25600#comment:14
      
      Snowflake in Tor Browser has been hanging after surfing for a while.
      (Tor reports "no running bridges".) It only began happening after commit
      12922a23, which caused snowflake-client not to log to a file by
      default (leaving it to log to its default stderr). What seems to be
      happening is that tor doesn't read from its PT clients' stderr, leaving
      a buffer to fill up that eventually causes a hang.
      6077141f
  6. 08 May, 2018 1 commit
  7. 30 Apr, 2018 1 commit
  8. 18 Apr, 2018 1 commit
    • David Fifield's avatar
      Fix text-shadow CSS. · fd9efa10
      David Fifield authored
      The semicolons made it look like the end of a declaration. I got these
      errors in the Firefox console:
      
      Expected declaration but found ‘1px’.  Skipped to next declaration. 1 embed.html:29:17
      Expected declaration but found ‘-1px’.  Skipped to next declaration. 1 embed.html:30:17
      fd9efa10
  9. 17 Apr, 2018 2 commits
  10. 16 Apr, 2018 9 commits
  11. 22 Mar, 2018 1 commit
  12. 21 Mar, 2018 3 commits
  13. 20 Mar, 2018 1 commit
  14. 15 Mar, 2018 2 commits
  15. 14 Mar, 2018 6 commits
    • Arlo Breault's avatar
      Try to protect against crash from dereferencing a NULL in go-proxy · f2abf5b6
      Arlo Breault authored
      Follow up to ff8f3851
      
      Similar to c834c76f
      f2abf5b6
    • David Fifield's avatar
    • Arlo Breault's avatar
      Allow broker base url to have a path · 42ec097a
      Arlo Breault authored
      42ec097a
    • David Fifield's avatar
      Add a "starting" log line to proxy-go. · 44ab82bc
      David Fifield authored
      44ab82bc
    • David Fifield's avatar
      Wait briefly after calling ListenAndServe{TLS} to see if it errors. · ea7b9c02
      David Fifield authored
      This is a port of commit e3f3054f8b74caa639a6d9be09702693af9a70e7 from
      meek.
      
      In the previous commit, we changed from separate Listen and Serve steps
      to always calling ListenAndServe. However, we would really like to
      immediately get feedback if any errors happen in the Listen step inside
      the call, because it's much better for debugging if those errors get
      reported to tor through SMETHOD-ERROR--rather than reporting success to
      tor and actually logging an error only in the snowflake log. So we wait
      100 ms for an error to occur before deciding that the Listen succeeded.
      
      We don't need to apply this hack to the ACME HTTP-01 listener, because
      it's a plaintext listener. Unlike in the TLS case, there isn't any
      internal magic that the net library does that we have to rely on. We
      just call net.ListenTCP and check for an error.
      ea7b9c02
    • David Fifield's avatar
      Use ListenAndServe{TLS} rather than separate Listen and Serve. · 19b317e7
      David Fifield authored
      This is a port of commit cea86c937dc278ba6b2100c238b1d5206bbae2f0 from
      meek. Its purpose is to remove the need to copy-paste parts of
      net/http.Server.ListenAndServeTLS. Here is a copy of the commit message
      from meek:
      
          The net/http package provides ListenAndServe and ListenAndServeTLS
          functions, but it doesn't provide a way to set up a listener without
          also entering an infinite serve loop. This matters for
          ListenAndServeTLS, which sets up a lot of magic behind the scenes for
          TLS and HTTP/2 support. Formerly, we had copy-pasted code from
          ListenAndServeTLS, but that code has only gotten more complicated in
          upstream net/http.
      
          The price we pay for this is that it's no longer possible for a server
          bindaddr to ask to listen on port 0 (i.e., a random ephemeral port).
          That's because we never get a change to find out what the listening
          address is, before entering the serve loop.
      
          What we gain is HTTP/2 support; formerly our copy-pasted code had the
          side effect of disabling HTTP/2, because it was copied from an older
          version and did things like
                  config.NextProtos = []string{"http/1.1"}
      
          The new code calls http2.ConfigureServer first, but that's not what's
          providing HTTP/2 support. HTTP/2 support happens by default. The reason
          we call http2.ConfigureServer is because we need to set
          TLSConfig.GetCertificate, and http2.ConfigureServer is a convenient way
          to initialize TLSConfig in a way that is guaranteed to work with HTTP/2.
      19b317e7