subrepo: disable git and svn subrepos by default (BC) (SEC) We have a security issue with git subrepos. I'm not sure if svn subrepo is vulnerable, but it seems not 100% safe to allow writing arbitrary data into a metadata directory. So for now, only hg subrepo is enabled by default. Maybe we should improve the help to describe why git/svn subrepos are disabled.

subrepo: extend config option to disable subrepos by type (SEC) This allows us to minimize the behavior change introduced by the next patch. I have no idea which config style is preferred in UX POV, but I decided to get things done. a) list: 'allowed = hg, git, svn' b) sub option: 'allowed.hg = True' or 'allowed:hg = True' c) per-type action: 'hg = allow', 'git = abort'

subrepo: add config option to reject any subrepo operations (SEC) This is an alternative workaround for the issue5730. Perhaps this is the simplest way of disabling subrepo operations. It does nothing clever, but just aborts if Mercurial starts accessing to a subrepo. I think Greg's patch is more useful since it allows us to at least check out the parent repository. However, that would be confusing if the default is flipped to checkout=False and subrepos are silently ignored. I don't like the config name 'allowed', but I couldn't get any better name.

subrepo: disallow symlink traversal across subrepo mount point (SEC) It wasn't easy to extend the pathauditor to check symlink traversal across subrepos because pathauditor._checkfs() rejects a directory having ".hg" directory. That's why I added the explicit islink() check. No idea if this patch is necessary after we've fixed the issue5730 by splitting submerge() into planning and execution phases.

tests: show symlink traversal across subrepo mount point (SEC) Also adds a couple of tests where the auditor does work as expected.

share: move config item declarations into core These config items control share behavior that is implemented in core. Since the functionality is implemented in core, extensions may leverage it. Mozilla has one such extension. And, it needs to access share.pool. Before this patch, a devel warning regarding accessing an unregistered config option would be issued unless the share extension were loaded. Moving the registration of the config options to core fixes this.

morestatus: don't crash with different drive letters for repo.root and CWD Previously, if there were unresolved files and the CWD drive was different from the repo drive, `hg status -v` would page the normal status, followed by the exception header. A stacktrace was waiting when the pager exited. The underlying cause was the same as f445b10dc7fb. Unfortunately, I don't see any reasonable way to write a test this [1]. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/107401.html

pathutil: add doctests for canonpath() This is a followup to f445b10dc7fb. Since there's no way to ensure that more drive letters than C: exist, this seems like the only way to test it. This is enough to catch the f445b10dc7fb scenario, as well as CWD outside of the repo when the path isn't prefixed with path/to/repo.

share: handle --relative shares to a different drive letter gracefully This had the same problem as f445b10dc7fb. Banning os.path.relpath() is tempting, but the hint it provides is useful here.

py3: handle keyword arguments in hgext/gpg.py Differential Revision: https://phab.mercurial-scm.org/D1303