Re: [RFC bpf-next 2/2] bpftool: Use libcrypto feature test to optionally support signing

[Alan Maguire <alan.maguire@oracle.com>]

On 29/10/2025 10:40, Quentin Monnet wrote:
> 2025-10-29 09:46 UTC+0000 ~ Alan Maguire <alan.maguire@oracle.com>
>> New libcrypto test verifies presence of openssl3 needed for BPF
>> signing; use that feature to conditionally compile signing-related
>> code so bpftool build will not break in the absence of libcrypto v3.
> 
> 
> Hi Alan, thanks for this work!
> 
> 
>>
>> Fixes: 40863f4d6ef2 ("bpftool: Add support for signing BPF programs")
>> Suggested-by: Quentin Monnet <qmo@kernel.org>
> 
> 
> This is not exactly what I suggested, I mentioned adding such a feature
> check and printing a more user-friendly error message at build time if
> the dependency is missing, not leaving out the program signing feature.
> 
> I've got reservations about the current approach: my concern is that
> people packaging bpftool may prefer to compile and ship it without
> program signing, if their build environment does not include the OpenSSL
> dependency. But it seems to me that it will be an important feature
> going forward, and that bpftool should ship with it.
> 
> Regarding the OpenSSL v3 vs. older version concern (from the build
> failure report thread):
> 
>> One issue here is that some distros package openssl v3 such that the
>> #include files are in /usr/include/openssl3 and libraries in
>> /usr/lib64/openssl3 so that older versions can co-exist. Maybe we could
>> figure out a feature test that handles that too?
> 
> In that case, we should have a feature probe that gives us the right
> build parameters to ensure that v3, and not some older version, is
> picked when building bpftool? (We could imagine falling back to an older
> version, but I see v3.0 is now the oldest OpenSSL supported version so
> it's probably not worth it?)
>

Actually there may be a simpler solution here; compilation at least
succeeds for openssl < 3 with the following change

diff --git a/tools/bpf/bpftool/sign.c b/tools/bpf/bpftool/sign.c
index b34f74d210e9..f9b742f4bb10 100644
--- a/tools/bpf/bpftool/sign.c
+++ b/tools/bpf/bpftool/sign.c
@@ -28,6 +28,12 @@

 #define OPEN_SSL_ERR_BUF_LEN 256

+/* Use deprecated in 3.0 ERR_get_error_line_data for openssl < 3 */
+#if !defined(OPENSSL_VERSION_MAJOR) || (OPENSSL_VERSION_MAJOR < 3)
+#define ERR_get_error_all(file, line, func, data, flags) \
+       ERR_get_error_line_data(file, line, data, flags)
+#endif
+
 static void display_openssl_errors(int l)
 {
        char buf[OPEN_SSL_ERR_BUF_LEN];


Given that openssl is already a build requirement for the kernel, that
may well be enough to resolve this issue without feature tests etc.
However I can't speak to whether there are other issues with using
openssl v1 aside from compile-time problem this solves.

Thanks!

Alan