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

Durham Goode durham at fb.com
Wed Aug 7 18:43:07 CDT 2013


On 8/7/13 4:23 PM, "Angel Ezquerra" <angel.ezquerra at gmail.com> wrote:

>
>On Aug 8, 2013 12:40 AM, "Durham Goode" <durham at fb.com> wrote:
>>
>>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


It's totally possible the schema stuff isn't appropriate for upstream
core. I'm open to that response from the community. The fact that we only
need a small subset of the projrc functionality and the fact that projrc
requires particularly careful consideration of how we can keep it secure,
means I'd rather implement the 30 lines I need and keep the security model
super simple. I am a security dummy and have zero faith in me being able
to design a secure generic solution to this problem.



More information about the Mercurial-devel mailing list