Re: iptables: reverting 34f085b16073 ("Revert "xshared: Print protocol numbers if --numeric was given"")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 03, 2024 at 06:52:41PM +0200, Phil Sutter wrote:
> Hi Jeremy,
> 
> On Wed, Jul 03, 2024 at 05:02:04PM +0100, Jeremy Sowden wrote:
> > At the beginning of the year you committed 34f085b16073 ("Revert
> > "xshared: Print protocol numbers if --numeric was given""), which
> > reverts da8ecc62dd76 ("xshared: Print protocol numbers if --numeric was
> > given").
> 
> I did this in response to nfbz#1729[1] which argued the names are more
> descriptive. This is obviously true and since commit b6196c7504d4d there
> is no real downside to printing the name if available anymore (--numeric
> still prevents calls to getprotobynumber()).
> 
> Personally I don't mind that much about changing --list output as it is
> not well suited for parsing anyway. I assume most scripts use
> --list-rules or iptables-save output which wasn't affected by
> da8ecc62dd76. Of course I am aware of those that have to parse --list
> output for one or the other reason and their suffering. The only bright
> side here is that whoever had to adjust to da8ecc62dd76 will know how to
> adjust to 34f085b16073, too. Plus it's not a moving target as there are
> merely twelve names which remain in '-n -L' output.
> 
> > In response to a Debian bug-report:
> > 
> >     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067733
> > 
> > I applied the change to the iptables package and uploaded it.  However,
> > this caused test failures in the Debian CI pipeline for firewalld
> > because its test-suite has been updated to expect the new numeric
> > protocol output.  Michael Biebl, the firewalld Debian maintainer, (cc'ed
> > so he can correct me if I misquote him) raised a point which I think has
> > some merit.  It is now eighteen months since 1.8.9 was released.  One
> > imagines that the majority of iptables users, who presumably are not
> > building iptables directly from git, must, therefore, have adjusted to
> > the new output.  Is it, then, worth it to revert this change and force
> > them to undo that work after what may have been a couple of years by the
> > time 1.8.11 comes out?
> > 
> > What do you think?
> 
> I think it's a mess and there's no clean way out. The current code is at
> least consistent between '-S' and '-L' output (iptables-save should not
> be "less numeric" than '-n -L'). If it helps, I can work with Eric to
> solve the problem for firewalld so Michael will have something to
> backport to fix it.

The firewalld testuite failures have been fixed [1]. The revert exposed
a bug in the testsuite normalization. It's not actually caused by the
revert of iptables da8ecc62dd76.

Michael could backport this to Sid.

[1]: https://github.com/firewalld/firewalld/pull/1360

> All in all I have not seen many complaints about this change, I expect
> few people scraping iptables output and only a fraction doing --list.
> In addition to that, I plan on soon having a 1.8.11 release (we're far
> ahead already to make backports a pain).
> 
> What do you think?

I'm indifferent. As you say, there is no clean way out.





[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux