Proposal: project hooks and policies

Jonathan S. Shapiro shap at eros-os.com
Tue Mar 11 08:00:44 CDT 2008


On Mon, 2008-03-10 at 13:09 -0400, Jesse Glick wrote:
> Jonathan S. Shapiro wrote:
> > Problem: you have a project. You want to ensure that some project-wide
> > policy (enforced by hooks) is maintained, and you want to ensure that
> > certain extensions are present (perhaps your scripts rely on them).
> 
> It is indeed not straightforward. For the repository I work on it was 
> necessary to insert code into the master build script to do some setup:
> 
> http://hg.netbeans.org/main/file/7acea67ce725/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/RegisterExternalHook.java
> 
> But it's a lot of work and people can get confused if they start running 
> VCS operations on a fresh clone without first running a build.

Yes. That is also an issue for us.

> > 2. The down-stream user's local path to the policy workspace may not 
> > match yours.
> 
> I'm not sure exactly what you're getting at here, but note that I have 
> submitted a patch (which has still not been applied) that lets you 
> specify an extension in .hg/hgrc using a relative path, which will be 
> resolved relative to the repository root.

I haven't looked at the patch, but what you describe (a) doesn't solve
the problem, and (b) should not be accepted because it creates a serious
security hole.

It doesn't address the problem because the extension section is not
cloned.

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. That is: a relative path is
only acceptable when it appears in a trusted HGRC file.

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.
There is no way to maintain a policy without introducing this policy,
but it is definitely a thing to be handled with care.

It would be possible to add a list of trusted RC files to ~/.hgrc, but
this wouldn't solve the "preservation under clone" problem.


shap



More information about the Mercurial-devel mailing list