[PATCH v5 03/12] libbpf: Implement SHA256 internal helper

[Eric Biggers]

On Sat, Sep 27, 2025 at 11:33:12PM +0100, Alexei Starovoitov wrote:
> On Sat, Sep 27, 2025 at 10:03 PM Eric Biggers <ebiggers at kernel.org> wrote:
> >
> > On Sun, Sep 21, 2025 at 03:31:24PM +0200, KP Singh wrote:
> > > Use AF_ALG sockets to not have libbpf depend on OpenSSL. The helper is
> > > used for the loader generation code to embed the metadata hash in the
> > > loader program and also by the bpf_map__make_exclusive API to calculate
> > > the hash of the program the map is exclusive to.
> > >
> > > Acked-by: Andrii Nakryiko <andrii at kernel.org>
> > > Signed-off-by: KP Singh <kpsingh at kernel.org>
> >
> > Nacked-by: Eric Biggers <ebiggers at kernel.org>
> >
> > No more users of AF_ALG, please.  It's a huge mistake and has been
> > incredibly problematic over the years.
> 
> Lol. True, but good luck with that. AF_ALG is uapi and it will be removed
> only when the last user retires many years from now.

Many Linux systems never enabled AF_ALG in the first place, and those
that have it enabled often only have a few users of it or even none at
all.  Sure, AF_ALG support will remain in-tree for a very long time or
even forever.  But many systems can keep it disabled, or can disable it,
if new users are not introduced and existing users continue to be fixed.

Let's do the right thing here, instead of making the situation even
worse and also adding undocumented kconfig dependencies to libbpf.

> > If you don't want to depend on a library, then just include some basic
> > SHA-256 code, similar to what I'm doing for iproute2 and SHA-1 at
> > https://lore.kernel.org/netdev/20250925225322.13013-1-ebiggers@kernel.org/.
> > I'd even be glad to write the patch for you, if you want.
> 
> Yes. Please. If you can craft sha256 without external dependencies
> we can certainly use it.
> Certainly agree that it would be better than AF_ALG.

Sure, I'll do that.

- Eric