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

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

[Jeremy Sowden]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

Hi, Phil.

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").

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?

J.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Phil Sutter]

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.
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?

Thanks, Phil

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

[Eric Garver]

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.

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

[Jeremy Sowden]

[-- Attachment #1: Type: text/plain, Size: 3378 bytes --]

On 2024-07-03, at 15:17:52 -0400, Eric Garver wrote:
> On Wed, Jul 03, 2024 at 06:52:41PM +0200, Phil Sutter wrote:
> > 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

Michael has picked this up.

> > 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.

Let's leave things as they are.

Thanks for your time, all.

J.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]