[PATCH 1 of 5] clonebundles: support for seeding clones from pre-generated bundles

[Gregory Szorc]

On Tue, Sep 29, 2015 at 5:48 PM, Gregory Szorc <gregory.szorc at gmail.com>
wrote:

> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1443565495 25200
> #      Tue Sep 29 15:24:55 2015 -0700
> # Node ID f2353a7a0ac6388085300648ce34325c4b7d9030
> # Parent  19d946cf2a1bf921e78de18f52cfabcc3401035f
> clonebundles: support for seeding clones from pre-generated bundles
>

I should have mentioned https://www.mercurial-scm.org/wiki/StaticBundlePlan.

One of the things that isn't yet considered in this series is the security
aspect. Right now we do a blind hand off from Mercurial server to
(possibly) another HTTP server. There is potential to intercept connections
to that 3rd server.

We should consider defining file hashes as part of the entry attributes and
have clients validate hashes during download. To do this properly, you
verify the hash before applying any data, otherwise a vulnerability in the
bundle processing or compression libraries could lead to compromise.
However, that means buffering >1GB data in the case of mozilla-central.
That also means slowing down clones since you have to wait for the entire
bundle to download before you start applying it. Security or convenience:
pick one.

This is an existing areas of weakness in Mercurial's transfer mechanism, so
I'm not sure what the proper solution is. I'm leaning towards exposing
hashes and verifying after full download by default. Of course, a
compromised bundle could modify the Mercurial process code and nullify this
check. So I don't think it provides much security value. We could also
offer a paranoid mode that verifies the hash before application. Again,
these would all be improvements over what Mercurial does today. Not sure
they are necessary for the initial implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150930/98989b41/attachment.html>