[PATCH 5 of 6 V3] hgweb: blacklist heavyweight revset functions in hgweb search
Alexander Plavin
alexander at plav.in
Fri Sep 13 08:37:40 UTC 2013
13.09.2013, 03:03, "Matt Mackall" <mpm at selenic.com>:
> On Thu, 2013-09-12 at 19:58 +0400, Alexander Plavin wrote:
>
>> 12.09.2013, 07:39, "Matt Mackall" <mpm at selenic.com>:
>>> On Mon, 2013-09-02 at 22:57 -0500, Kevin Bullock wrote:
>>>> On 1 Sep 2013, at 1:25 AM, Alexander Plavin wrote:
>>>>> 01.09.2013, 08:54, "Kevin Bullock" <kbullock+mercurial at ringworld.org>:
>>>>>> On 22 Aug 2013, at 10:11 AM, Alexander Plavin wrote:
>>>>>>> # HG changeset patch
>>>>>>> # User Alexander Plavin <alexander at plav.in>
>>>>>>> # Date 1374269558 -14400
>>>>>>> # Sat Jul 20 01:32:38 2013 +0400
>>>>>>> # Node ID 3767921c4b274499fe4254bdafef56bba346b088
>>>>>>> # Parent 5734dd4b2bd2a859a2ef0be6e0f4485f028abf6e
>>>>>>> hgweb: blacklist heavyweight revset functions in hgweb search
>>>>>>>
>>>>>>> Disallow usage of functions 'contains' and 'grep'.
>>>>>> It will be verbose, but I'd rather have a whitelist of known-safe(-ish) revsets. That way when we add the next (possibly unexpectedly!) compute-intensive revset, we won't be opening our users up to new DoS attacks because we forgot to blacklist it.
>>>>> Agree, makes sense. And what about moving this part of code to revset.py?
>>>> No strong opinion either way.
>>> Seems a good idea to me.
>> In the more recent version of these patches (namely, those with V5 flag) I'd done this. It would be nice if you looked at them too :)
>
> Argh. V5, he says! V5 of WHICH of the eight or so hard-to-distinguish
> series currently clogging my inbox??
>
> It's extremely difficult for me to determine what's new and what's
> obsolete in my inbox anymore, because I have pages and pages of
> patchsets with the same author and similar summaries and no good way to
> spot duplicates. It's a maze of twisty little messages, all slightly
> different and I don't want to spend all my time sorting through this
> mess. And not sorting through this mess means my patch acceptance rate
> (and your progress) has suffered for weeks. That your mentor has failed
> to throttle[1] you earlier is unfortunate.
>
> I _really_ should just dump absolutely everything from you currently in
> my inbox so I can get back on top of things, but that means I would miss
> existing review comments to figure out whether your future patches are
> acceptable and what's already been addressed.
>
> Recommended reading:
>
> http://mercurial.selenic.com/wiki/ContributingChanges#Flow_control
> http://www.selenic.com/inbox
I've read this already, and my submissions satisfy almost all of the points at #Flow_control. For example, there are only 8 my patches which are marked with 'Action Required' at patchwork, and it doesn't seem a great number. And quick re-sends of newer versions also match the advice given on that page, namely 'Try to respond quickly to feedback before we forget what your patch is about'. So, I don't know where I'm wrong now and how to do this correctly.
>
> [1] pun intended?
>
> --
> Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list