Log Message:
py-mercurial: update to 4.5.2.

Mercurial 4.5.1 / 4.5.2 (2018-03-06)

(4.5.2 was released immediately after 4.5.1 to fix a release
oversight.)

This is a regularly-scheduled bugfix release.

1.1. Security Fixes

All versions of Mercurial prior to 4.5.2 have vulnerabilities in
the HTTP server that allow permissions bypass to:

    Perform writes on repositories that should be read-only
    Perform reads on repositories that shouldn't allow read access

The nature of the vulnerabilities is:

    Wire protocol commands that didn't explicitly declare their
    permissions had no permissions checking done. The web.{allow-pull,
    allow-push, deny_read, etc} config options governing access
    control were never consulted when running these commands. This
    allowed permissions bypass for impacted commands.

    The batch wire protocol command did not list its permission
    requirements nor did it enforce permissions on individual
    sub-commands.

The implication of these vulnerabilities is that no permissions
checking was performed on commands and this could lead to accessing
data that web.* config options were supposed to prevent access to
or modifying data (via wire protocol commands that can mutate data)
without authorization. A Mercurial HTTP server in its default
configuration is supposed to be read-only. However, a well-crafted
batch command could invoke commands that perform writes.

The batch write permissions bypass has been present since Mercurial
1.9. The flaw of not checking permissions for wire protocol commands
that don't declare their needed permissions has been present since
Mercurial 1.0.

Assuming you are running a server without any custom commands
provided by extensions, your exposure is unauthorized data access
(if relying on the web.* config options to limit access) and
unauthorized data mutation via the batch command.

Server operators can detect unauthorized use of the batch command
by looking for requests to URLs of the form repo?cmd=batch with
arguments containing pushkey or unbundle. This may produce false
positives. A more comprehensive check would decode the argument
string and verify that pushkey or unbundle are command names (not
values). The arguments specified via x-hgarg-<N> request headers
can span multiple headers. So advanced attackers could hide the
vulnerability by splitting a pushkey or unbundle string across
multiple headers. So the only reliable way to detect if this
vulnerability is being exploited is to decode these headers like
Mercurial does. The format for specifying arguments is documented
at
https://www.mercurial-scm.org/repo/hg/file/4.5/mercurial/help/internals/wireprotocol.txt#l26.
Python code for decoding headers is at
https://www.mercurial-scm.org/repo/hg/file/4.5/mercurial/hgweb/protocol.py#l70.

Mercurial 4.5.2 fixes these vulnerabilities by:

    Performing permissions checking on all wire protocol commands,
    not just commands that list their permissions.

    Checking permissions on sub-commands issued to the batch command.

Wire protocol commands not declaring wire protocol permissions will
be assumed to be read-write commands and a server in its default
configuration (which only allows read-only access), will refuse to
execute these commands.

For package maintainers needing to backport the fixes, the relevant
changesets from 4.5.2 are 2c647da851ed::2ecb0fc535b1. These can be
viewed online at e.g.
https://www.mercurial-scm.org/repo/hg/rev/2ecb0fc535b1. The author
of these commits has backports to 4.4 and 4.3 on a personal fork
at https://hg.mozilla.org/users/gszorc_mozilla.com/hg. The backports
for 4.4 are a4843835c835::7cf827e5f8af and for 4.3 are
db527ae12671::86f9a022ccb8. To obtain these changesets, run e.g.
hg pull -r 7cf827e5f8af https://hg.mozilla.org/users/gszorc_mozilla.com/hg.

1.2. Backwards Compatibility Changes

    The "batch" wire protocol command now enforces permissions of
    each invoked sub-command. Wire protocol commands must define
    their operation type or the "batch" command will assume they
    can write data and will prevent their execution on HTTP servers
    unless the HTTP request method is POST, the server is configured
    to allow pushes, and the (possibly authenticated) HTTP user is
    authorized to perform a push.
    Wire protocol commands not defining their operation type in
    "wireproto.PERMISSIONS" are now assumed to be used for "push"
    operations and access control to run those commands is now
    enforced accordingly.

1.3. Bug Fixes

    fileset: don't abort when running copied() on a revision with a removed file
    date: fix parsing months

    setup: only allow Python 3 from a source checkout (issue5804)

    annotate: do not poorly split lines at CR (issue5798)

    subrepo: don't attempt to share remote sources (issue5793)
    subrepo: activate clone pooling to enable sharing with remote URLs
    changegroup: do not delta lfs revisions
    revlog: do not use delta for lfs revisions
    revlog: resolve lfs rawtext to vanilla rawtext before applying delta