Re: [PATCH 2/2] extensions: restore matching any SPI id by default

[Jan Engelhardt <jengelh@inai.de>]

On Monday 2015-08-10 14:04, Pablo Neira Ayuso wrote:
>> I oppose that idempotent expressions in rules, implicit or explicit,
>> shall lead to output when the ruleset is read back. A rule like
>> 
>> 	-A INPUT -m policy --dir in
>> 
>> should not, by default, cause `iptables -S` to output a
>> rule with terms essentially irrelevant to the human reader.
>> 
>> 	-A INPUT -m policy --dir in --reqid 0:4294967295 [...]
>
>The point is that this has been broken for two years, chances that
>users have fixed this in the ruleset without reporting is high, so
>restoring the old behaviour may break things again for them.

Users that went that route have nothing to worry. If their input
ruleset explicitly specified some --reqid x:y, then they will get the
desired x <= reqid <= y test no matter the iptables version.


>That's why I'm insisting on the fact that switching to a less obscure
>behaviour is a good idea in the very specific case of 'ah' since they
>can easily detect that things have change by diffing the new and old
>iptables-save output.

Mind you, diffing is exactly how this bug _was_ discovered. A modified 
print/save function would have done _nothing_ to prevent the bug.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html