netdev - Re: [PATCH iproute2-next 3/3] lib: utils: Add parse_one_of_deprecated(), parse_on_off

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6d053928-fe27-4e6d-9850-d8f7587507ec@gmail.com>
Date: Mon, 20 Nov 2023 14:27:13 -0800
From: David Ahern <dsahern@...il.com>
To: Petr Machata <petrm@...dia.com>,
 Stephen Hemminger <stephen@...workplumber.org>
Cc: netdev@...r.kernel.org, Patrisious Haddad <phaddad@...dia.com>
Subject: Re: [PATCH iproute2-next 3/3] lib: utils: Add
 parse_one_of_deprecated(), parse_on_off_deprecated()

On 11/15/23 8:57 AM, Petr Machata wrote:
> 
> Stephen Hemminger <stephen@...workplumber.org> writes:
> 
>> On Wed, 15 Nov 2023 16:31:59 +0100
>> Petr Machata <petrm@...dia.com> wrote:
>>
>>> The functions parse_on_off() and parse_one_of() currently use matches() for
>>> string comparison under the hood. This has some odd consequences. In
>>> particular, "o" can be used as a shorthand for "off", which is not obvious,
>>> because "o" is the prefix of both. By sheer luck, the end result actually
>>> makes some sense: "on" means on, anything else means off (or errors out).
>>> Similar issues are in principle also possible for parse_one_of() uses,
>>> though currently this does not come up.
>>
>> This was probably a bug, I am open to breaking shorthand usage in this case.
> 
> There were uses of matches() for on/off parsing even before adding
> parse_on_off(). The bug was converting _everyone_ to matches().
> 
> I figured you'd be against just s/matches/strcmp, but if you think it's
> OK, I have no problem with that. Shorthanding on/off just makes no
> sense to me, not even by mistake.

+1

> 
> How about the parse_one_of() users? E.g. the disabled/check/strict for
> macsec validate, I could see someone mistyping it as "disable", so now
> it lives in some deployment script, or testing harness, or whatever.
> 
> Maybe do the warning thing in this case? And retire it a couple releases
> down the line in favor of just accepting strcmp?

I think the macsec example needs to stay as is; it could be moved to a
parse_one_of_legacy() in ipmacsec to avoid copy-and-paste. The rest seem
safe to convert to your proposal.