netdev - Re: [RFC PATCH iproute2-next 2/2] dcb: add new subcommand for apptrust object

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: <87wna8czpu.fsf@nvidia.com>
Date:   Mon, 12 Sep 2022 18:34:31 +0200
From:   Petr Machata <petrm@...dia.com>
To:     <Daniel.Machon@...rochip.com>
CC:     <stephen@...workplumber.org>, <netdev@...r.kernel.org>,
        <Allan.Nielsen@...rochip.com>, <UNGLinuxDriver@...rochip.com>,
        <maxime.chevallier@...tlin.com>, <vladimir.oltean@....com>,
        <petrm@...dia.com>, <kuba@...nel.org>, <vinicius.gomes@...el.com>,
        <thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH iproute2-next 2/2] dcb: add new subcommand for
 apptrust object


<Daniel.Machon@...rochip.com> writes:

> Den Fri, Sep 09, 2022 at 08:06:31AM -0700 skrev Stephen Hemminger:
>> [You don't often get email from stephen@...workplumber.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> 
>> On Fri, 9 Sep 2022 12:37:01 +0200
>> Daniel Machon <daniel.machon@...rochip.com> wrote:
>> 
>> >       } else if (matches(*argv, "app") == 0) {
>> >               return dcb_cmd_app(dcb, argc - 1, argv + 1);
>> > +     } else if (matches(*argv, "apptrust") == 0) {
>> > +             return dcb_cmd_apptrust(dcb, argc - 1, argv + 1);
>> >       } else if (matches(*argv, "buffer") == 0) {
>> 
>> Yet another example of why matches() is bad.
>> 
>> Perhaps this should be named trust instead of apptrust.
>
> Hah, that slipped my mind.
>
> Obviously this wont do. Will have to come up with some different naming 
> in an eventual non-RFC patch.

Wait, this doesn't change anything, does it? "a", "ap" and "app"
previously referred to dcb_cmd_app, which they still do with the patch.
"appt" etc. were previously rejected, now refer to apptrust.

I've been known to miss issues in this area in the past, and for that
reason agree with the sentiment on matches(). But what problem does this
patch introduce?

And yeah, +1 for "trust".