durin42 abandoned this revision.
durin42 added a comment.
Let's reopen this if/when we return to it.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D98
To: durin42, #hg-reviewers, quark, indygreg
Cc: durin42, yuja, mharbison72, quark, mercurial-devel
indygreg added a comment.
There are a number of security and user control issues at play here.
For security, we need to take a long hard look at what configs can be
modified by in-repo files. Revsets already have a "safe" flag that controls
what to expose on hgweb. We likely need more
quark added a comment.
In https://phab.mercurial-scm.org/D98#6041, @mharbison72 wrote:
> I thought about doing this, instead of fixing up a stripped down projrc
extension. But then you have to get every developer to edit the local .hg/hgrc
file for every clone they have. So even if we
yuja added a comment.
> I couldn't tell from Yuya's comment if "... not add such revset functions"
means
I meant "don't load unsafe extensions." revsets and filesets have to be
secure against
malicious input because they are accessible through the Web UI. It's up to
users to
make a
mharbison72 added a comment.
In https://phab.mercurial-scm.org/D98#4834, @quark wrote:
> It seems to me that a lot of security work (ex. knowing the "origin" when
executing a revset, marking config items or sections as safe or unsafe by
extensions) are required to be able to turn on
yuja added a comment.
> Security-wise, the "shelling out revset" seems hard to solve cleanly.
Yes, and IMHO the only reasonable solution is to not add such revset
functions.
revsets and filesets can be executed through the web UI.
REPOSITORY
rHG Mercurial
REVISION DETAIL
quark added a comment.
Security-wise, the "shelling out revset" seems hard to solve cleanly. By
having `%include ../hgrc` in `$REPO/.hg/hgrc`, we could already read config in
working copy for a trusted repo today.
It seems to me that a lot of security work (ex. knowing the "origin" when
yuja added a comment.
> What else should we allow in here? Are there security concerns we should
think through?
Probably safe, but could be used for DoS attack:
- `filesetalias` (not implemented)
- `revsetalias`
- `committemplate`
- `templatealias`
- `templates`
Unsafe
durin42 added a comment.
In https://phab.mercurial-scm.org/D98#2104, @yuja wrote:
> Can we have a single source file for project's revset/fileset aliases and
maybe templates?
> I don't think it's good idea to create `.hgxxx` file per config section.
>
> [revsetalias]
>
yuja added a comment.
Can we have a single source file for project's revset/fileset aliases and
maybe templates?
I don't think it's good idea to create `.hgxxx` file per config section.
[revsetalias]
filealiasall = all()
[filesetalias]
...
Perhaps they could be
mharbison72 added a comment.
Big +1 on this functionality, and I'd be happy to experiment with it now. I
couldn't quite figure it out from an extension. Also +1 on doing this for
filesets.
My use case is less about generic revsets (e.g.,` nudge = push -r .`), and
more about defining
indygreg added a comment.
This should probably be considered an RFC patch, especially given how late in
the cycle it is. I'm not opposed to punting this to the next cycle.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D98
EMAIL PREFERENCES
indygreg created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.
REVISION SUMMARY
It is common for projects or companies to define/recommend
common customizations for Mercurial. However, distributing these
customizations can be difficult
13 matches
Mail list logo
