Checkgroups handling

[Julien ÉLIE]

Hi Russ,

> 1. Build a list of applicable rules by suppressing earlier rules that are
>    overridden by later ones.  I think we can do this by saying that if the
>    first three components of the rule are the same, the later rule is
>    taken to be an override of the earlier rule and the earlier rule is
>    deleted.  (However, see below.)
>
> 2. For an incoming checkgroups, find all checkgroups rules that match that
>    from address.  If any of them have verify actions, ensure that the
>    checkgroups is signed by that key and discard all rules where that
>    validation fails.
>
> 3. For each rule remaining, apply the pattern as a filter and act on the
>    checkgroups after non-matching lines have been filtered out.

[...]

> We can't just make drop special since the user may use mail or some other
> action in the override.

Why not something like that:

  foo.bar1
  foo.bar2.first
  foo.bar2.second
  foo.bar3.first
  foo.bar3.second
  foo.bar4
  foo.bar5

checkgroups:from:foo.*:verify-key-foo
checkgroups:from:foo.bar2.*:doit
checkgroups:from:foo.bar3.*:mail
checkgroups:from:foo.bar5:drop

(4) => exclusion-list=foo.bar5
(3) => We check for foo.bar3.first and foo.bar3.second in foo.bar3.*
       (minus the exclusion-list) and mail the result.
       exclusion-list=foo.bar5,foo.bar3.*
(2) => We check for foo.bar2.first and foo.bar2.second in foo.bar2.*
       (minus the exclusion-list) and do the necessary changes.
       exclusion-list=foo.bar5,foo.bar3.*,foo.bar2.*
(1) => We check for foo.bar1 and foo.bar4 in foo.* (minus the
       exclusion-list) and do the necessary changes if the checkgroups
       is verified.


> This gets rather complicated, and in thinking
> about it for five minutes or so, I'm having a hard time coming up with the
> right mental model for it.

Then why not just add to your step 3 the fact that after processing each rule,
an exclusion list is updated (and also passed as the second argument to
docheckgroups).


>>  Do you see other control.ctl issues?
>
> Well, there's the basic syntactical problem that the current syntax
> unfortunately conflates verification (verify-key) and action.   The key
> should really be a separate field.

Hopefully we can handle everything with the current syntax (verify-*=file,
verify-*=mail and verify-*).


> There's also the problem that the
> syntax doesn't distinguish between additive rules that should also be
> processed and overrides of existing rules.
> Also, it would be nice to use wildmats instead of the weird | thing so
> that you can say something like comp.*,!*binaries*.

Sure.  Maybe we do not need to make a change there, especially if control.ctl
is converted one day so that it can be parsed by the configuration parser
you wrote.

-- 
Julien ÉLIE

« Mon âme a son secret, ma vie a son mystère. » (Félix Arvers)