Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 03 Dec 2015 13:23:46 -0800] rev 27234
context: use a the nofsauditor when matching file in history (issue4749)
Before this change, asking for file from history (eg: 'hg cat -r 42 foo/bar')
could fail because of the current content of the working copy (eg: current
"foo" being a symlink). As the working copy state have no influence on the
content of the history, we can safely skip these checks.
The working copy context class have a different 'match'
implementation. That implementation still use the repo.auditor will
still catch symlink traversal.
I've audited all stuff calling "match" and they all go through a ctx
in a sensible way. The most unclear case was diff which still seemed
okay. You raised my paranoid level today and I double checked through
tests. They behave properly.
The odds of someone using the wrong (matching with a changectx for
operation that will eventually touch the file system) is non-zero
because you are never sure of what people will do. But I dunno if we
can fight against that. So I would not commit to "never" for "at this
level" and "in the future" if someone write especially bad code.
However, as a last defense, the vfs itself is running path auditor in
all cases outside of .hg/. So I think anything passing the 'matcher'
for buggy reason would growl at the vfs layer.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 03 Dec 2015 13:22:36 -0800] rev 27233
localrepo: add a second auditor without file system check
Auditors keeps a cache of audited paths. Therefore we cannot use the same
auditor for working copy and history operation. We create a new one without
file system check for this purposes.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 03 Dec 2015 10:40:19 -0800] rev 27232
pathauditor: add a way to skip file system check
We need to be able to skip it when looking at data within the history.
Doing them in all cases leads to buggy behavior like issue4749.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 03 Dec 2015 12:22:48 -0800] rev 27231
pathauditor: move file system specific check in their own function
This will make it easy to disable that part when not relevant (eg: auditing
filename for operation in history)
Yuya Nishihara <yuya@tcha.org> [Sat, 07 Nov 2015 16:31:04 +0900] rev 27230
contrib: disable SSLv3_method() to build old Python with recent libssl
Because OpenSSL is compiled without SSLv3 support on Debian sid, Python 2.6.9
can't be built without this hack. Python 2.7 is patched appropriately, but
2.6 isn't.
http://bugs.python.org/issue22935
Laurent Charignon <lcharignon@fb.com> [Thu, 03 Dec 2015 08:31:20 -0800] rev 27229
rebase: only clear rebase status after the rebase transaction has completed
In 405320cd6198, I made the mistake of moving the step "clearing the status
after a rebase" to inside the rebase transaction.
This was wrong, since we don't want to clear the status (and the rebase state)
if something went wrong during the transaction: if something goes wrong we
want to keep the rebase state to be able to abort.
It broke rebase with evolve + inhibit.
Sietse Brouwer <sbbrouwer@gmail.com> [Thu, 03 Dec 2015 01:38:21 +0100] rev 27228
dirstate: don't write repo.currenttransaction to repo.dirstate if repo
is None (issue4983)
Some hooks, such as post-init and post-clone, do not get a repo parameter in
their environment. If there is no repo, there is no repo.currenttransaction();
attempting to retrieve it anyway was causing crashes. Now currenttransaction is
only retrieved and written if the repo is not None.
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 02 Dec 2015 14:20:13 -0800] rev 27227
tests: test changegroup generation for filtered changesets (issue4982)
The test demonstrates the buggy behavior from issue4982 where the
changegroup contains changesets it shouldn't.
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Dec 2015 23:04:58 +0900] rev 27226
parsers: fix parse_dirstate to check len before unpacking header (issue4979)
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 03 Dec 2015 21:25:05 -0800] rev 27225
mercurial: support loading modules from zipimporter
The previous refactor to module importing broke module loading when
mercurial.* modules were loaded from a zipfile (using a zipimporter).
This scenario is likely encountered when using py2exe.
Supporting zipimporter and the traditional importer side-by-side
turns out to be quite a pain. In Python 2.x, the standard, file-based
import mechanism is partially implemented in C. The sys.meta_path
and sys.path_hooks hook points exist to allow custom importers in
Python/userland. zipimport.zipimporter and our "hgimporter" class
from earlier in this patch series are 2 of these.
In a standard Python installation (no matter if running in py2exe
or similar or not), zipimport.zipimporter appears to be registered
in sys.path_hooks. This means that as each sys.path entry is
consulted, it will ask zipimporter if it supports that path and
zipimporter will be used if that entry is a zip file. In a
py2exe environment, sys.path contains an entry with the path to
the zip file containing the Python standard library along with
Mercurial's Python files.
The way the importer mechanism works is the first importer that
declares knowledge of a module (via find_module() returning an
object) gets to load it. Since our "hgimporter" is registered
in sys.meta_path and returns an interest in specific mercurial.*
modules, the zipimporter registered on sys.path_hooks never comes
into play for these modules. So, we need to be zipimporter aware
and call into zipimporter to load modules.
This patch teaches "hgimporter" how to call out into zipimporter
when necessary. We detect the necessity of zipimporter by looking
at the loader for the "mercurial" module. If it is a zipimporter
instance, we load via zipimporter.
The behavior of zipimporter is a bit wonky.
You appear to need separate zipimporter instances for each directory
in the zip file. I'm not sure why this is. I suspect it has
something to do with the low-level importing mechanism (implemented
in C) operating on a per-directory basis. PEP-302 makes some
references to this. I was not able to get a zipimporter to
import modules outside of its immediate directory no matter how
I specified the module name. This is why we use separate
zipimporter instances for the ".zip/mercurial" and
".zip/mercurial/pure" locations.
The zipimporter documentation for Python 2.7 explicitly states that
zipimporter does not import dynamic modules (C extensions). Yet from
a py2exe distribution on Windows - where the .pyd files are *not*
in the zip archive - zipimporter imported these dynamic modules
just fine! I'm not sure if dynamic modules can't be imported from
*inside* the zip archive or whether zipimporter looks for dynamic
modules outside the zip archive. All I know is zipimporter does
manage to import the .pyd files on Windows and this patch makes
our new importer compatible with py2exe.
In the ideal world, We'd probably reimplement or fall back to parts
of the built-in import mechanism instead of handling zipimporter
specially. After all, if we're loading Mercurial modules via
something that isn't the built-in file-based importer or zipimporter,
our custom importer will likely fail because it doesn't know how to
call into it. I'd like to think that we'll never encounter this
in the wild, but you never know. If we do encounter it, we can
come up with another solution.
It's worth nothing that Python 3 has moved a lot of the importing
code from C to Python. Python 3 gives you near total control over
the import mechanism. So in the very distant future when Mercurial
drops Python 2 support, it's likely that our custom importer code
can be refactored to something a bit saner.