netdev - Re: Bpftool mirror now available

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzaiUbAT4hBKTVYadGdygccA3c6jgPsu8VW9sLo+4Ofsvw@mail.gmail.com>
Date:   Thu, 20 Jan 2022 11:07:58 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Quentin Monnet <quentin@...valent.com>
Cc:     bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Dave Thaler <dthaler@...rosoft.com>
Subject: Re: Bpftool mirror now available

On Thu, Jan 20, 2022 at 4:35 AM Quentin Monnet <quentin@...valent.com> wrote:
>
> 2022-01-19 22:25 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@...il.com>
> > On Wed, Jan 19, 2022 at 6:47 AM Quentin Monnet <quentin@...valent.com> wrote:
>
> [...]
>
> >> 2. Because it is easier to compile and ship, this mirror should
> >> hopefully simplify bpftool packaging for distributions.
> >
> > Right, I hope disto packagers will be quick to adopt the new mirror
> > repo for packaging bpftool. Let's figure out bpftool versioning schema
> > as a next step. Given bpftool heavily relies on libbpf and isn't
> > really coupled to kernel versions, it makes sense for bpftool to
> > reflect libbpf version rather than kernel's. WDYT?
>
> Personally, I don't mind finding another scheme, as long as we keep it
> consistent between the reference sources in the kernel repo and the mirror.
>
> I also agree that it would make sense to align it to libbpf, but that
> would mean going backward on the numbers (current version is 5.16.0,
> libbpf's is 0.7.0) and this will mess up with every script trying to
> compare versions. We could maybe add a prefix to indicate that the
> scheme has changed ('l_0.7.0), but similarly, it would break a good
> number of tools that expect semantic versioning, I don't think this is
> any better.
>
> The other alternative I see would be to pick a different major version
> number and arbitrarily declare that bpftool's version is aligned on
> libbpf's, but with a difference of 6 for the version number. So we would
> start at 6.7.0 and reach 7.0.0 when libbpf 1.0.0 is released. This is
> not ideal, but we would keep some consistency, and we can always add the
> version of libbpf used for the build to "bpftool version"'s output. How
> would you feel about it? Did you have something else in mind?

Yeah, this off-by-6 major version difference seems ok-ish to me, I
don't mind that. Another alternative is to have a completely
independent versioning (and report used libbpf version in bpftool
--version output  separately). But I think divorcing it from kernel
version is a must, too much confusion.

>
> Quentin