netdev - Re: [PATCH iproute2] ip route: broken logic when using default word and family not specified

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171205174203.43dacd0a@xeon-e3>
Date:   Tue, 5 Dec 2017 17:42:03 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Alexander Zubkov <zubkov318@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH iproute2] ip route: broken logic when using default word
 and family not specified

On Sat, 18 Nov 2017 17:56:32 +0100
Alexander Zubkov <zubkov318@...il.com> wrote:

> I also opened earlier a ticket in bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=197899
> And Stephen Hemminger had couple of comments there which I want to argue:
> 
> > $ ip route list default
> > Means list all routes in any address family (ie same as any)
> > but
> >
> > $ ip route list 0/0
> > Means list all routes for IPv4 default route.  
> 
> This is not correct, because first command do not show routes in any
> address family. Now it do so only when table 0 is specified, otherwise
> only IPv4 routes are showed. Here is the code from iproute.c:
> 
>         if (do_ipv6 == AF_UNSPEC && filter.tb)
>                 do_ipv6 = AF_INET;
> 
> > It probably is worth a man page warning, but changing semantics
> > that have existed for many years is more likely to break some existing user.  
> 
> Yes, backward compatibility is a reason. But as I remember, that
> sematics already have changed earlier. Probably it was showing IPv4
> and IPv6 routes together without family specified - I do not remember
> exactly. And I have doubts that such feature could be lied on
> reliably.
> I as a end user would prefer to make the behaviour more consistent and
> without such excetptions. But of course there may be other opinions.

As a conservative maintainer, my preference is always to receive acknowledgments
from others before accepting something that may break existing users.

Backward compatibility is more important than the surprising result you discovered.
A confused new user is less of an issue than breaking some existing user
who may not even have contact back to network developers.

Since it has been that way for many years, waiting a couple of weeks for review
is not going to hurt anything.