Per project config options

[Angel Ezquerra]

On Wed, Apr 25, 2012 at 10:59 PM, Steve Hoelzer <shoelzer at gmail.com> wrote:
> On Wed, Apr 25, 2012 at 2:20 PM, Michael Diamond <dimo414 at gmail.com> wrote:
>> The general use case for not needing security goes something like this: "My
>> project doesn't need to worry about Mercurial security concerns, because {I
>> trust my developers | it's totally internal | I'm the only person using it |
>> it's not a standard source code repository}."  There's two issues with this,
>> most notably, all of those factors can change, and when they do it's highly
>> likely repository configuration security is not going to be a top concern.
>> Secondly, such use cases are far from the norm, and far more often people
>> *think* security isn't a concern for their repository, but are mistaken.
>> These two factors all but guarantee (in my mind) that this will never be an
>> option in core Mercurial.  I'm not saying your in that second category, just
>> that if you are in fact safe from security concerns, that's far from the
>> norm.
>>
>> The consequence of these two factors is that no matter what, you will have
>> to do a second step after hg clone to apply new configuration files, be that
>> enable an extension (or have it enabled for the user already) or run some
>> sort of script.  Matt pointed out some of the issues of your solution #1,
>> and #2 would require a hook or extension of some sort, and to me seems like
>> a very rough and unintuitive behavior.
>>
>> I think your best bet is the extension Angel suggested, or if that's too
>> much for what you need, track a .hgrc file, and expect users to run `echo
>> "\n\n%include = ../.hgrc" >> .hg/hgrc` or drop that into a bash script like
>> 'update_hgrc.sh', then you can quite easily do (or instruct users to do):
>>
>> hg clone http://example.com/hg/myproject
>> cd myproject
>> ./update_hgrc.sh
>>
>> And you're golden.  Doesn't seem like too much work to me, and has the added
>> advantage of ensuring that anyone using the repo must knowingly apply the
>> changes to their hgrc file.
>>
>> Another factor to remember is that one (highly intentional) "limitation" of
>> distributed VCS is that you can't enforce any sort of settings, hooks, or
>> extensions on other people's repositories, and you should never trust new
>> changes to have been created with your configurations in place.  The only
>> guarantee you have is that they cannot change the history without you
>> knowing.  If you need additional control, you do this by designating a
>> centralized repository people push/pull to, and locking down access to that
>> repository, and/or applying push restrictions via a server-side hook.
>
> Very good points. I think I'm convinced that security should always be
> a priority. Thanks for your detailed response.
>
> Steve

That is exactly why the ProjrcExtension is "safe" by default, in the
sense that it will not apply any remote "project settings" unless the
user enables _and_ configures it (selecting which which remote repo
settings to accept from the project settings file).

However, I think that it is quite easy to setup (especially if you use
the TortosieHg GUI). But as others said in this tread, you must be
careful. Do not enable it for any repo that you don't trust! Be
specially careful when accepting hooks and/or extension settings.

Angel