Skip to content
Snippets Groups Projects
  1. Aug 02, 2016
  2. Aug 01, 2016
  3. Jul 31, 2016
  4. Jul 30, 2016
    • Katsunori FUJIWARA's avatar
      demandimport: avoid infinite recursion at actual module importing (issue5304) · 8960fcb7
      Katsunori FUJIWARA authored
      Before this patch, importing C module on Windows environment causes
      infinite recursion call, if py2exe is used with -b2 option.
      
      At importing C module "a.b", extra hooking by zipextimporter of py2exe
      causes:
      
        0. assumption before accessing "b" of "a":
      
           - built-in module object is created for "a",
             (= "a" is actually imported)
           - _demandmod is created for "a.b" as a proxy object, and
             (= "a.b" is not yet imported)
           - an attribute "b" of "a" is initialized by the latter
      
        1. invocation of __import__ via _hgextimport() in _demandmod._load()
           for "a.b" implies _demandimport() for "a.b"
      
           This is unintentional, because _demandmod might be returned by
           _hgextimport() instead of built-in module object.
      
        2. _demandimport() at (1) is invoked with not context of "a", but
           context of zipextimporter
      
           Just after invocation of _hgextimport() in _demandimport(), an
           attribute "b" of the built-in module object for "a" is still
           bound to the proxy object for "a.b", because context of "a" isn't
           updated by actual importing "a.b". even though the built-in
           module object for "a.b" already appears in sys.modules.
      
           Therefore, chainmodules() returns _demandmod for "a.b", which is
           gotten from the attribute "b" of "a".
      
        3. processfromitem() on "a.b" causes _demandmod._load() for "a.b"
           again
      
           _demandimport() takes context of "a" in this case.
      
           Therefore, attributes below are bound to built-in module object
           for "a.b", as expected:
      
           - "b" of built-in module object for "a"
           - _module of _demandmod for "a.b"
      
        4. but _demandimport() invoked at (1) returns _demandmod object
      
           because _demandimport() just returns the object returned by
           chainmodules() at (3) above.
      
        5. then, _demandmod._load() causes infinite recursion call
      
           _demandimport() returns _demandmod for "a.b", and it is "self" at
           _demandmod._load().
      
      To avoid infinite recursion at actual module importing, this patch
      uses self._module, if _hgextimport() returns _demandmod itself. If
      _demandmod._module isn't yet bound at this point, execution should be
      aborted, because actual importing failed.
      
      In this patch, _demandmod._module is examined not on _demandimport()
      side, but on _demandmod._load() side, because:
      
        - the former has some exit points
        - only the latter uses _hgextimport(), except for _demandimport()
      
      BTW, this issue occurs only in the code path for non .py/.pyc files in
      zipextimporter (strictly speaking, in _memimporter) of py2exe.
      
      Even if zipextimporter is enabled, .py/.pyc files are handled by
      zipimporter, and it doesn't imply unintentional _demandimport() at
      invocation of __import__ via _hgextimport().
      8960fcb7
  5. Jul 28, 2016
  6. Jul 29, 2016
  7. Jul 27, 2016
  8. Jul 28, 2016
  9. Jul 27, 2016
  10. Jul 25, 2016
  11. Jul 18, 2016
    • Matt Mackall's avatar
      extdiff: escape path for docstring (issue5301) · 67b180c0
      Matt Mackall authored
      The existing code (a) assumed path would be specified in
      encoding.encoding and (b) assumed unicode() objects wouldn't cause
      other parts of Mercurial to blow up. Both are dangerous assumptions.
      
      Since we don't know the encoding of path and can't pass non-ASCII
      through docstrings, just escape the path and drop the early _(). Will
      have to suffice until we can teach docstrings to handle UTF-8b
      escaping.
      
      This has the side-effect that the line containing the path is now
      variable by the time it reaches _() and thus can't be translated.
      67b180c0
  12. Jul 21, 2016
    • Kostia Balytskyi's avatar
      update: fix bug when update tries to modify folder symlink · b33c0c38
      Kostia Balytskyi authored
      In 1e4512eac59e, I introduced a new bug:
      when a symlink points to a folder in commit A and to another folder
      in commit B, while updating from A to B, Mercurial will try to use
      removedir on this symlink, which will fail. This is a very bad bug,
      since it basically renders symlinks to folders unusable in repos.
      
      Added test case fails without a fix and passes with it.
      b33c0c38
  13. Jul 25, 2016
  14. Jul 22, 2016
  15. Jul 20, 2016
  16. Jul 19, 2016
  17. Jul 20, 2016
    • Gregory Szorc's avatar
      sslutil: improve messaging around unsupported protocols (issue5303) · 53e80179
      Gregory Szorc authored
      There are various causes for the inability to negotiate common SSL/TLS
      protocol between client and server. Previously, we had a single, not
      very actionable warning message for all of them.
      
      As people encountered TLS 1.0 servers in real life, it was quickly
      obvious that the existing messaging was inadequate to help users
      rectify the situation.
      
      This patch makes the warning messages much more verbose in hopes of
      making them more actionable while simultaneously encouraging users
      and servers to adopt better security practices.
      
      This messaging flirts with the anti-pattern of "never blame the
      user" by signaling out poorly-configured servers. But if we're going to
      disallow TLS 1.0 by default, I think we need to say *something* or
      people are just going to blame Mercurial for not being able to connect.
      The messaging tries to exonerate Mercurial from being the at fault
      party by pointing out the server is the entity that doesn't support
      proper security (when appropriate, of course).
      53e80179
    • Gregory Szorc's avatar
      sslutil: capture string string representation of protocol · fbf4adc0
      Gregory Szorc authored
      This will be used in a subsequent patch to improve messaging.
      fbf4adc0
    • Gregory Szorc's avatar
      sslutil: allow TLS 1.0 when --insecure is used · 2960ceee
      Gregory Szorc authored
      --insecure is our psuedo-supported footgun for disabling connection
      security.
      
      The flag already disables CA verification. I think allowing the use of
      TLS 1.0 when specified is appropriate.
      2960ceee
    • Gregory Szorc's avatar
      hg: copy [hostsecurity] options to remote ui instances (issue5305) · 3fde328d
      Gregory Szorc authored
      TIL that ui instances for remote/peer repos don't automagically inherit
      config options from .hg/hgrc files.
      
      This patch makes remote ui instances inherit options from the
      [hostsecurity] section. We were already inheriting options
      from [hostfingerprints] and [auth]. So adding [hostsecurity] to the
      list seems appropriate.
      3fde328d
  18. Jul 18, 2016
    • Mads Kiilerich's avatar
      rbc: fix superfluous rebuilding from scratch - don't abuse self._rbcnamescount · a2a380e2
      Mads Kiilerich authored
      The code used self._rbcnamescount as if it was the length of self._names ...
      but actually it is just the number of good entries on disk. This caused the
      cache to be populated inefficiently. In some cases very inefficiently.
      
      Instead of checking the length before lookup, just try a lookup in self._names
      - that is also in most cases faster.
      
      Comments and debug messages are tweaked to help understanding the issue
      and the fix.
      a2a380e2
Loading