<p dir="ltr"><br>
On Aug 9, 2013 5:04 PM, "Augie Fackler" <<a href="mailto:raf@durin42.com">raf@durin42.com</a>> wrote:<br>
><br>
> On Thu, Aug 08, 2013 at 08:36:29AM +0200, Angel Ezquerra wrote:<br>
> > On Thu, Aug 8, 2013 at 1:43 AM, Durham Goode <<a href="mailto:durham@fb.com">durham@fb.com</a>> wrote:<br>
> > > On 8/7/13 4:23 PM, "Angel Ezquerra" <<a href="mailto:angel.ezquerra@gmail.com">angel.ezquerra@gmail.com</a>> wrote:<br>
> > ><br>
> > >><br>
> > >>On Aug 8, 2013 12:40 AM, "Durham Goode" <<a href="mailto:durham@fb.com">durham@fb.com</a>> wrote:<br>
> > >>><br>
> > >>>I wasn't aware of the projrc extension, but I did discuss that concept<br>
> > >>> internally and with Matt. I think the problem is that it just isn't<br>
> > >>>secure<br>
> > >>> enough.  If one of our users is dumb and sets up "servers = *, include =<br>
> > >>> *", they could execute arbitrary code from bitbucket within our network.<br>
> > >>><br>
> > >>> Durham<br>
> > >>I understand your concern but the extension does not blindly accept new<br>
> > >>configurations. In fact I think it is actually pretty safe and it has<br>
> > >>been developed to be as safe as possible. In particular by default the<br>
> > >>extension requires confirmation<br>
> > >> whenever the projrc file changes. Currently it does not show which<br>
> > >>settings changed but it could do so. It could also require explicit<br>
> > >>confirmation before accepting changes to the "dangerous" sections.<br>
> > >>Additionally the extension could be tweaked to be even safer. For example<br>
> > >>the extension could be changed so that it would only accept projrc<br>
> > >>settings from your internal servers. Another option would be to make it<br>
> > >>necessary to explicitly include<br>
> > >> dangerous settings such as hooks and extensions (i.e. include = * would<br>
> > >>only include safe settings).<br>
> > >>On the other hand I feel that your proposed schemas functionality is a<br>
> > >>bit narrow to be included as part of mercurial core. Distributing a<br>
> > >>common mercurial config is a common problem. IMHO it would be nice if<br>
> > >>mercurial offered a generic solution<br>
> > >> to that problem. I don't think your proposal is such a solution.<br>
> > >>Angel<br>
> > ><br>
> > ><br>
> > > It's totally possible the schema stuff isn't appropriate for upstream<br>
> > > core. I'm open to that response from the community.<br>
> ><br>
> > Maybe I was too categorical. What I meant to say is that your proposal<br>
> > seems a bit too narrow in scope. It would be nice if mercurial had a<br>
> > built-in, secure way to distribute (default) settings.<br>
><br>
> The difficulty here is that many config knobs can lead to arbitrary<br>
> code exection (eg [alias] stuff).<br>
><br>
> ><br>
> > That being said to a certain extent this is already the case for many<br>
> > users, since TortoiseHg bundles the projrc extension.<br>
><br>
> It's off by default, right?<br>
></p>
<p dir="ltr">Like mercurial, every extension we ship is off by default.</p>
<p dir="ltr">Cheers,</p>
<p dir="ltr">Angel<br>
</p>