Skip to content
Snippets Groups Projects
  1. Apr 18, 2017
  2. Apr 12, 2017
    • Augie Fackler's avatar
      dispatch: protect against malicious 'hg serve --stdio' invocations (sec) · 77eaf9539499
      Augie Fackler authored
      Some shared-ssh installations assume that 'hg serve --stdio' is a safe
      command to run for minimally trusted users. Unfortunately, the messy
      implementation of argument parsing here meant that trying to access a
      repo named '--debugger' would give the user a pdb prompt, thereby
      sidestepping any hoped-for sandboxing. Serving repositories over HTTP(S)
      is unaffected.
      
      We're not currently hardening any subcommands other than 'serve'. If
      your service exposes other commands to users with arbitrary repository
      names, it is imperative that you defend against repository names of
      '--debugger' and anything starting with '--config'.
      
      The read-only mode of hg-ssh stopped working because it provided its hook
      configuration to "hg serve --stdio" via --config parameter. This is banned for
      security reasons now. This patch switches it to directly call ui.setconfig().
      If your custom hosting infrastructure relies on passing --config to
      "hg serve --stdio", you'll need to find a different way to get that configuration
      into Mercurial, either by using ui.setconfig() as hg-ssh does in this patch,
      or by placing an hgrc file someplace where Mercurial will read it.
      
      mitrandir@fb.com provided some extra fixes for the dispatch code and
      for hg-ssh in places that I overlooked.
      4.1.3
      77eaf9539499
  3. Apr 13, 2017
  4. Feb 25, 2017
  5. Apr 17, 2017
    • Yuya Nishihara's avatar
      dispatch: ignore further SIGPIPE while handling KeyboardInterrupt · cde72a195f32
      Yuya Nishihara authored
      I got the following error by running "hg log" and quitting the pager
      immediately. Any output here may trigger another SIGPIPE, so only thing
      we can do is to swallow the exception and exit with an error status.
      
        Traceback (most recent call last):
          File "./hg", line 45, in <module>
            mercurial.dispatch.run()
          File "mercurial/dispatch.py", line 83, in run
            status = (dispatch(req) or 0) & 255
          File "mercurial/dispatch.py", line 167, in dispatch
            req.ui.warn(_("interrupted!\n"))
          File "mercurial/ui.py", line 1224, in warn
            self.write_err(*msg, **opts)
          File "mercurial/ui.py", line 790, in write_err
            self._write_err(*msgs, **opts)
          File "mercurial/ui.py", line 798, in _write_err
            self.ferr.write(a)
          File "mercurial/ui.py", line 129, in _catchterm
            raise error.SignalInterrupt
        mercurial.error.SignalInterrupt
      
      Perhaps this wasn't visible before de5c9d0e02ea because the original stderr
      handle was restored very late.
      cde72a195f32
  6. Apr 15, 2017
  7. Apr 05, 2017
  8. Apr 17, 2017
  9. Apr 12, 2017
    • Pierre-Yves David's avatar
      upgrade: register all format variants in a list · 189778a06743
      Pierre-Yves David authored
      Now that all known format variants exists outside of the function, we can gather
      them in a lists. This build a single entry point other code can use (current
      target: extensions).
      
      The repository upgrade code is updated to simply use entries from this list.
      
      As a side effect this will also allow extensions to register their own format
      variants, to do this "properly" we should introduce a "registrar" for this
      category of object. However I prefer to keep this series simple, and that will
      be adventure for future time.
      189778a06743
    • Pierre-Yves David's avatar
      upgrade: move descriptions and selection logic in individual classes · 11a2461fc9b1
      Pierre-Yves David authored
      Our goal here is to get top level definition for all the format variants. Having
      them defined outside of the function enabled other users of that logic.
      
      They are two keys components of a format variant:
      
      1) the name and various descriptions of its effect,
      
      2) the code that checks if the repo is using this variant and if the config
         enables it.
      
      That second items make us pick a class-based approach, since different variants
      requires different code (even if in practice, many can reuse the same logic).
      Each variants define its own class that is then used like a singleton.  The
      class-based approach also clarify the definitions part a bit since each are
      simple assignment in an indented block.
      
      The 'fromdefault' and 'fromconfig' are respectively replaced by a class
      attribute and a method to be called at the one place where "fromconfig"
      matters.
      
      Overall, they are many viable approach for this, but this is the one I picked.
      11a2461fc9b1
  10. Apr 10, 2017
  11. Apr 17, 2017
  12. Apr 16, 2017
    • Pierre-Yves David's avatar
      color: also enable by default on windows · 8b7f794d6a9d
      Pierre-Yves David authored
      I've not found anything related to color + windows on the bug tracker. So I'm
      suggesting we get bolder and turn it on for windows too in the release
      candidate. We can always backout this changeset if we find serious issue on
      windows.
      8b7f794d6a9d
    • Pierre-Yves David's avatar
      color: turn on by default (but for windows) · 57042e91521a
      Pierre-Yves David authored
      Color support is all in core for a couple of months. I've browsed the bug tracker
      without finding any blocker bug. So I'm moving forward and enable color on by
      default before '4.2-rc'. In the worse case, having it on in the release
      candidate will help us to find blocker bug and we can turn it off for the final
      release.
      
      I remember people talking about issue with Windows during the freeze so I'm
      keeping it off by default on that OS.
      
      We could do various cleaning of the color used and the label issued.  However
      the label are probably already in our backward compatibility envelope since the
      color extensions has been around since for ever and I do not think the color
      choice themself should be considered BC. So I think we should rather gives color
      to all user sooner than later.
      
      A couple of test needs to be updated to avoid having color related control code
      spoil the tested output.
      57042e91521a
    • Pierre-Yves David's avatar
      pager: stop using the color extension in tests · d323d9e0d7b4
      Pierre-Yves David authored
      The feature is in core so let us use the core config knob directly.
      d323d9e0d7b4
    • Gregory Szorc's avatar
      bundle2: ignore errors seeking a bundle after an exception (issue4784) · ad41739c6b2b
      Gregory Szorc authored
      Many have seen a "stream ended unexpectedly" error. This message is
      raised from changegroup.readexactly() when a read(n) operation fails
      to return exactly N bytes.
      
      I believe most occurrences of this error in the wild stem from
      the code changed in this patch. Before, if bundle2's part applicator
      raised an Exception when processing/applying parts, the exception
      handler would attempt to iterate the remaining parts. If I/O
      during this iteration failed, it would likely raise the
      "stream ended unexpectedly" exception.
      
      The problem with this approach is that if we already encountered
      an I/O error iterating the bundle2 data during application, then
      any further I/O would almost certainly fail. If the original stream
      were closed, changegroup.readexactly() would obtain an empty
      string, triggering "stream ended unexpectedly" with "got 0." This is
      the error message that users would see. What's worse is that the
      original I/O related exception would be lost since a new exception
      would be raised. This made debugging the actual I/O failure
      effectively impossible.
      
      This patch changes the exception handler for bundle2 application to
      ignore errors when seeking the underlying stream. When the underlying
      error is I/O related, the seek should fail fast and the original
      exception will be re-raised. The output changes in
      test-http-bad-server.t demonstrate this.
      
      When the underlying error is not I/O related and the stream can be
      seeked, the old behavior is preserved.
      ad41739c6b2b
    • Gregory Szorc's avatar
      error: rename RichIOError to PeerTransportError · a29580905771
      Gregory Szorc authored
      This is a more descriptive name. RichIOError was introduced just
      hours ago, so it doesn't need to be marked as BC.
      a29580905771
    • Gregory Szorc's avatar
      httppeer: don't send empty Vary request header · e5d7f99a3063
      Gregory Szorc authored
      As part of writing test-http-bad-server.t, I noticed that some
      requests include an empty Vary HTTP request header.
      
      The Vary HTTP request header indicates which headers should be taken
      into account when determining if a cached response can be used. It also
      accepts the special value of "*".
      
      The previous code unconditionally added a Vary header. This could lead
      to an empty header value. While I don't believe this violates the HTTP
      spec, this is weird and just wastes bytes. So this patch changes
      behavior to only send a Vary header when it has a value.
      
      Some low-level wire protocol byte reporting tests changed. In some
      cases, the exact point of data termination changed. However, the
      behavior being tested - that clients react when the connection is
      closed in the middle of an HTTP request line or header - remains
      unchanged.
      e5d7f99a3063
  13. Apr 17, 2017
  14. Apr 15, 2017
    • Pierre-Yves David's avatar
      obsolescence: add test for the "branch replacement" logic during push, case D7 · 090fff9b6d65
      Pierre-Yves David authored
      Mercurial checks for the introduction of new heads on push. Evolution comes
      into play to detect if existing branches on the server are being replaced by
      some of the new one we push.
      
      This changeset adds test for the improved "branch replacement" logic introduce
      in an earlier commits. This tests initially lived in the evolve extensions.
      Since we now have the code handling this logic in core, it make sense to have
      the tests in core too.
      
      See inline documentation for details about the test case added in this
      changeset.
      090fff9b6d65
    • Pierre-Yves David's avatar
      obsolescence: add test for the "branch replacement" logic during push, case D5 · 9f7ba0daada1
      Pierre-Yves David authored
      Mercurial checks for the introduction of new heads on push. Evolution comes
      into play to detect if existing branches on the server are being replaced by
      some of the new one we push.
      
      This changeset adds test for the improved "branch replacement" logic introduce
      in an earlier commits. This tests initially lived in the evolve extensions.
      Since we now have the code handling this logic in core, it make sense to have
      the tests in core too.
      
      See inline documentation for details about the test case added in this
      changeset.
      9f7ba0daada1
    • Pierre-Yves David's avatar
      obsolescence: add test for the "branch replacement" logic during push, case D3 · 43c91eb53806
      Pierre-Yves David authored
      Mercurial checks for the introduction of new heads on push. Evolution comes
      into play to detect if existing branches on the server are being replaced by
      some of the new one we push.
      
      This changeset adds test for the improved "branch replacement" logic introduce
      in an earlier commits. This tests initially lived in the evolve extensions.
      Since we now have the code handling this logic in core, it make sense to have
      the tests in core too.
      
      See inline documentation for details about the test case added in this
      changeset.
      43c91eb53806
Loading