[PATCH 1 of 4] schemas: add schemas to repositories

[Angel Ezquerra]

On Aug 8, 2013 12:40 AM, "Durham Goode" <durham at fb.com> wrote:
>
> On 8/6/13 11:34 PM, "Angel Ezquerra" <angel.ezquerra at gmail.com> wrote:
>
> >On Wed, Aug 7, 2013 at 2:28 AM, Durham Goode <durham at fb.com> wrote:
> >> # HG changeset patch
> >> # User Durham Goode <durham at fb.com>
> >> # Date 1375827328 25200
> >> #      Tue Aug 06 15:15:28 2013 -0700
> >> # Node ID f6fca02b697a67bec6e6ca2c9a48d7c7d7f1d077
> >> # Parent  3e34e7b223d10bbe8814f82d7a1f53575fe09096
> >> schemas: add schemas to repositories
> >>
> >> This adds the concept of schemas to repositories. A schema is a
> >>key/value pair
> >> indicating alternative means of accessing the remote repository. For
> >>example,
> >> the largefiles extension might provide a schema such as:
> >>
> >> largefiles http://some.cdn.com/myrepo
> >>
> >> When a user interacts with the repository, if the client knows how to
> >>handle
> >> the largefiles schema, it will read the url and obtain largefiles from
> >>the
> >> url. Thus letting you serve large files from a CDN.
> >>
> >> The key difference between this and normal hgrc config options is that
> >>it is
> >> copied across to the client during clone/pull. So if a client clones
> >>from
> >> another client, they will also see the available schemas from the
> >>original
> >> server. The logic for clone/pull will happen in a later patch.
> >>
> >> This change enables an extension we're working on that will keep all of
> >>the
> >> file history on the server, and clients will all have shallow repos.
> >
> >Durham,
> >
> >have you had a look at the projrc extension? You can find it at
> >http://mercurial.selenic.com/wiki/ProjrcExtension
> >
> >It seems to cover the use case you describe (if I understood what your
> >extension does correctly) but it also seems to cover other important
> >use cases.
> >
> >Basically, it lets you define a ".projrc" file which contains an hgrc
> >configuration that is transmitted to the client on clone and pull. The
> >client can configure which subset of the .projrc configuration is
> >willing to accept, on a server by server basis, which is meant to make
> >the extension as safe as such an extension can be (for example you can
> >chose to never accept extension or hook configurations).
> >
> >This extension was developed by Martin Geisler for one of its clients
> >(Lantiq) and I have been maintaining it. It is bundled with
> >TortoiseHg.
> >
> >I wonder if perhaps bundling the projrc extension with mercurial would
> >not cover your needs?
> >
> >Now, regarding your patch, if you still want to go ahead with your
> >"schemas" file, perhaps it would be best if it had a more .hgrc like
> >syntax (i.e. "key= value", rather than "key value")?
> >
> >Cheers,
> >
> >Angel
> >
>
> I wasn't aware of the projrc extension, but I did discuss that concept
> internally and with Matt. I think the problem is that it just isn't secure
> enough.  If one of our users is dumb and sets up "servers = *, include =
> *", they could execute arbitrary code from bitbucket within our network.
>
> Durham

I understand your concern but the extension does not blindly accept new
configurations. In fact I think it is actually pretty safe and it has been
developed to be as safe as possible. In particular by default the extension
requires confirmation whenever the projrc file changes. Currently it does
not show which settings changed but it could do so. It could also require
explicit confirmation before accepting changes to the "dangerous" sections.

Additionally the extension could be tweaked to be even safer. For example
the extension could be changed so that it would only accept projrc settings
from your internal servers. Another option would be to make it necessary to
explicitly include dangerous settings such as hooks and extensions (i.e.
include = * would only include safe settings).

On the other hand I feel that your proposed schemas functionality is a bit
narrow to be included as part of mercurial core. Distributing a common
mercurial config is a common problem. IMHO it would be nice if mercurial
offered a generic solution to that problem. I don't think your proposal is
such a solution.

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130808/769b37d4/attachment.html>