> -----Original Message-----
> From: Arno van Amersfoort [mailto:arn...@rocky.eld.leidenuniv.nl]
> Sent: Friday, February 24, 2012 3:33 PM
> To: Slade, Zac
> Cc: 658...@bugs.debian.org; julia.long...@gmail.com; Lonnie Abelbeck
> Subject: Re: arno-iptables-firewall syntax changes
>
> Dear Zac,
>
> Your assumption is wrong. One can still use the short form
> "SRC_PORT>INT_IP~INT_PORT". So the only real problem is when people
> use(d) the undocumented, no longer working,
> "~SRC_PORT>INT_IP~INT_PORT"
> form. The version that no longer allowed this form, is ALSO the version that
> introduced rule sanity checking which IS mentioned in the CHANGELOG. This
> means, as I also told Julia, that the firewall does report that it was unable
> to
> parse *ALL* rules properly. It even reports which rule fails and it certainly
> doesn´t cause any security issues.
My opening paragraph did say that didn't it.... Sorry for that. By the end of
the mail I had corrected that:
> > This does not seem to allow the syntax you were using. Notice the form
> "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port}". This seems to
> indicate to me that the ~ in your previous examples is what caused your
> breakage. Can you confirm that the documentation is correct and that you can
> set NAT_FORWARD_TCP=SRC_PORT>INT_IP~INT_PORT and it work correctly?
Sorry for the confusion. I should have amended my message before hitting send.
I never suggested this was a security vulnerability. Clearly it isn't. I
think Julia's frustration is that when reloading the firewall rules after the
upgrade she gets a broken firewall and a WARNING message. Is there a way to
prevent loading of the rules entirely and preserving the original firewall
state in the case of a parsing error? Maybe that's reaching a little; I'm just
curious if that might be a good path forward to prevent future updates from
blowing away currently running firewalls when the administrator is unaware of
configuration file changes (even parser fixes)? This will happen again I'm
sure(completely by accident). See the history of bash for more examples(and
bash upgrades are generally really clean).
> Furthermore it's impossible for us to (regression) test any previously
> undocumented/unintended functionality and report it in the CHANGELOG
> accordingly.
Agreed. You cannot regression test against undocumented features.
Regards,
Zac Slade
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
