Proposal: project hooks and policies

[Jesse Glick]

Jonathan S. Shapiro wrote:
>> I have submitted a patch [...] that lets you specify an extension
>> in .hg/hgrc using a relative path [...]
> 
> It doesn't address the problem because the extension section is not 
> cloned.

Right, you still need to register the extension in the repository by 
other means. The advantage of the patch is that having done so, you can 
freely move the repository around on disk even if the extension lives 
inside the repository. Also, if a patch for config file includes were 
available, it would be possible to keep an entire config file fragment 
including extension registration as part of versioned sources, further 
simplifying maintenance.

(A potential problem with keeping extensions or other config inside the 
repository as versioned sources is that it is vulnerable to being 
corrupted or even deleted by e.g. merge conflicts, hg up -r null, etc. 
You can move config inside the .hg directory to prevent such problems 
but then you must write your own code to maintain the config when it is 
changed. For the NetBeans repository I have chosen to keep a custom 
extension as part of versioned sources, registered initially by the 
build script, which also reregisters it in case the repository is moved 
to a new filesystem location.)

> It is a security hole because I (the user) cannot and must not trust
> arbitrary scripts. In consequence, I must not be placed in the position
> of running code derived from a potentially untrusted repository merely
> as a consequence of cloning that repository.

There is no security hole. Cloning the repository does not put anything 
into .hg/hgrc (other than paths.default). The user who created the clone 
has to explicitly add anything to hgrc, or run some script (Makefile, 
build.xml, ...) which does so on their behalf.

> Part of maintaining a "policy repository" is accepting that the number
> of people authorized to revise the policy needs to be severely
> restricted. This is necessary because these people are in a position to
> cause arbitrary code to be executed on the downstream user's machine.

Ideally yes. In practice every development project I have come into 
contact with has some sort of build script which is run with the 
developer's permissions and can run arbitrary shell commands, and is 
usually modifiable by any developer with write access to the source 
repository. This is a threat to CI builder machines as much as to 
individual developers. I guess you could devise a build tool that runs 
in a restricted sandbox (a "buildlet"?), or trust everyone with write 
access, or just monitor changes to build scripts carefully.

An interesting comparison is to Emacs. Files are permitted to declare 
buffer-local Elisp variables in a special header (or footer), e.g.

<?xml version="1.0"?> <!-- -*- xml-wacky-formatting: true -*- -->
<document><child
/></document>

Emacs will automatically load such definitions for most variables. 
Certain variables are considered security sensitive, and files can also 
include arbitrary s-expressions (i.e. code) in these headers; in such 
cases Emacs will prompt you before loading the declarations.

Perhaps a similar system would be useful for Mercurial. An interactive 
'hg clone' would prompt you to accept a predefined hgrc fragment. Of 
course such an enhancement would not work for noninteractive clones 
(e.g. on CI machines) and would not help with long-term maintenance of 
configuration in existing clones. However unlike Emacs, where the loaded 
code cannot change "under your feet" (since only you are editing the 
buffer), extensions registered in your .hg/hgrc and present in the 
repository could silently become malicious after a routine 'hg fetch'.