Checkgroups handling

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> Suppose we have the following newsgroups in a checkgroups:
>
>  comp.binaries
>  comp.foo.bar
>  news.foo
>  news.foo.bar
>
> And now in control.ctl:
>
> 1/
>  checkgroups:from:comp.*:verify-...
>  checkgroups:from:news.*:doit
>
> How should we handle that?  Is it OK to use the most restrictive
> situation for the *whole* checkgroups, that is to say "verify" here, for
> both comp.* and news.*?

> Or, something that would be better, should we process the checkgroups
> twice?  (One time for comp.* [minus possible dropped newsgroups] and
> another time for news.* [minus possible dropped newsgroups] alone?)

> Any other suggestions?
>
> With INN 2.4, only the news.* part would be done and comp.* not treated
> at all.

control-archive currently extracts the first group from the checkgroups,
finds the rule in control.ctl that would correspond to that group, and
then applies the given pattern in control.ctl as a filter on the groups
that are processed.  So it also doesn't do quite the right thing with this
pattern.  Both currently require this be written as comp.*|news.*.

I think that processing it twice would make the most sense, but we have to
be careful about ensuring that overrides later in the file still work as
they do currently.  I think something like the following pseudocode would
do the right thing:

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.

> 2/
>  checkgroups:same-from:foo.*:verify-key-foo
>  checkgroups:same-from:bar.*:verify-key-bar
>
> Processing twice the checkgroups will allow the same sender to use two
> different keys.
>
> This currently cannot be done with INN 2.4.
> With INN 2.5, one will "pgpfail" and the other one will be properly verified.

The above pseudocode would handle that.

> 3/
>  checkgroups:from:comp.*,news.*:verify-...
>  checkgroups:*:*binaries*:drop
>
> In the new system for INN 2.5, I suggest that all control.ctl entries be
> checked.  Not only the last matching one.  It will then allow to drop
> the first newsgroup from the checkgroups.  The order of the "drop" and
> "verify" matters: here, it drops comp.binaries (otherwise, if "drop" is
> before, it will not impact this checkgroups, but the previous ones in
> control.ctl).
>
> Does it sound OK?

This is where my pseudocode doesn't work.  I'm not sure how to also handle
this case (which I think is important), and still handle the case of:

checkgroups:from:foo.*:verify-key-foo
checkgroups:from:foo.*:verify-key-bar

where the latter rule should completely override the former rule and
matching checkgroups signed with key-foo should not be honored.  (Consider
someone using control.ctl to override which key should be honored.)

We can't just make drop special since the user may use mail or some other
action in the override.  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.

> 4/
>  checkgroups:*:*:mail
>
> This default entry in control.ctl is bothering.  I suggest that we do not
> process it if a line other than "drop" has already matched the checkgroups.
>
>  checkgroups:*:*:mail
>  checkgroups:*:foo.*:drop
>
> will result with foo.* entries being dropped.  Then the body of the
> checkgroups is empty (if for foo.*) and it will not be mailed.  But
> bar.* will because the body of the checkgroups is not empty after the
> drop.

Hm, yes, that would work.

> 5/
>  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.  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*.

But those all require a significant syntax change, and hence are rather
hard.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.