tests/test-revlog.t

test-lfs-test-server: add a testcase for `hg serve`

I haven't figured out yet how to make the authentication checks work for a
specific list of users, so the 'web.allow-push' list is wildcarded.  (It appears
that the client doesn't react to a 401 by sending authentication data, which may
be caused in part by not having all of the headers in httpbasicauthhandler's
http_error_auth_reqed(), compared to a run of test-http.t.  But in any case, we
should probably have a separate set of tests for various authentication
scenarios.  As it is, without the wildcard, no push access is granted.)

There are several deviations from the `lfs-test-server` case:

 - `hg serve` emits a Server header.  I think Gregory indicated that this isn't
   easily suppressed.

 - `hg serve` names the "basic" transfer handler in the Batch API response.  Not
   having to specify it was for backwards compatability, so this seems like the
   right thing to do.  (`lfs-test-server` doesn't name it, whether it was
   explicitly requested by the client or not.)

 - PUT status for a newly created file is 201, per RFC-2616 [1].  The Basic
   Transfer API [2] shows an example upload transcript with a 200 response.  It
   doesn't make much sense to re-upload a file (unless it is corrupt) in an
   example, but I wouldn't be surprised if some other implementations also
   expect 200 because of this.  But the RFC says MUST use 201 for creation.

 - The Content-Type for the file transfers is "application/octet-stream", like
   the sample transcript (though I don't see it explicitly called out in the
   text elsewhere).  Using "text/plain" seems clearly wrong.

 - `lfs-test-server` isn't removing the action property and sending back an
   error code like the spec calls out when a file is missing or corrupt.  Doing
   so on the `hg serve` side reveals a bug in our client code when handling the
   response- it indicates the remote file is missing instead of corrupt around
   line 452.

I'll probably glob over the Content-Length differences once this settles down.
Prior to the recent hgweb refactoring, the Batch API response was using chunked
encodings instead.

Back to the RFC, I have no idea if the python framework handles the "MUST NOT
ignore any Content-* (e.g. Content-Range) headers that it does not understand or
implement and MUST return a 501" for a PUT request.

[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[2] https://github.com/git-lfs/git-lfs/blob/master/docs/api/basic-transfers.md#uploads

  $ hg init empty-repo
  $ cd empty-repo

Flags on revlog version 0 are rejected

  >>> with open('.hg/store/00changelog.i', 'wb') as fh:
  ...     fh.write(b'\x00\x01\x00\x00')

  $ hg log
  abort: unknown flags (0x01) in version 0 revlog 00changelog.i!
  [255]

Unknown flags on revlog version 1 are rejected

  >>> with open('.hg/store/00changelog.i', 'wb') as fh:
  ...     fh.write(b'\x00\x04\x00\x01')

  $ hg log
  abort: unknown flags (0x04) in version 1 revlog 00changelog.i!
  [255]

Unknown version is rejected

  >>> with open('.hg/store/00changelog.i', 'wb') as fh:
  ...     fh.write(b'\x00\x00\x00\x02')

  $ hg log
  abort: unknown version (2) in revlog 00changelog.i!
  [255]

  $ cd ..

Test for CVE-2016-3630

  $ hg init

  >>> open("a.i", "wb").write(
  ... b"""eJxjYGZgZIAAYQYGxhgom+k/FMx8YKx9ZUaKSOyqo4cnuKb8mbqHV5cBCVTMWb1Cwqkhe4Gsg9AD
  ... Joa3dYtcYYYBAQ8Qr4OqZAYRICPTSr5WKd/42rV36d+8/VmrNpv7NP1jQAXrQE4BqQUARngwVA=="""
  ... .decode("base64").decode("zlib"))

  $ hg debugindex a.i
     rev    offset  length  delta linkrev nodeid       p1           p2
       0         0      19     -1       2 99e0332bd498 000000000000 000000000000
       1        19      12      0       3 6674f57a23d8 99e0332bd498 000000000000
  $ hg debugdata a.i 1 2>&1 | egrep 'Error:.*decoded'
  (mercurial\.\w+\.mpatch\.)?mpatchError: patch cannot be decoded (re)