freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crypto backend in freeipmi


From: Al Chu
Subject: Re: Crypto backend in freeipmi
Date: Wed, 26 Jun 2024 11:10:41 -0700
User-agent: Mozilla Thunderbird

Hi Pavel,

You guessed correctly, linking with libgcrypt was specifically due to licensing issues with openssl when I wrote all that code eons ago (ehhhh 2005-ish?).

Skimming the libfreeipmi code, I think the `libcommon/ipmi-crypt.c` file is the only place that needs modification.  There's a lot of macros WITH_ENCRYPTION macos lingering in there, so we probably need to refactor out a "gcrypt" and "openssl" into their own files.

If you'd like I can do a mini-refactor to get the gcrypt code into it's own file.  That way you can hopefully just pug in a openssl equivalent implementation?

Al

On 6/26/24 10:39, Pavel Cahyna wrote:
Hello,

I would like to ask about the crypto backend used by freeipmi. Currently
it is using libgcrypt for AES cipher and digests. This library is less
used and less actively developed than other crypto libraries, which
makes one less confident using it. Other crypto libraries also have the
advantage of easier certification and better integration with system
crypto policies for users who care about this. I thus propose adding
support for another (better supported) crypto library. This would be
selected at compile time (no pluggable modules or anything runtime like
that).

Choices for the other library are GnuTLS or OpenSSL. For OpenSSL one
will find many more tutorials and examples as it is much more widely
used and many more people are more or less familiar with it, so I think
it should be the preferred choice. In the past its license used to be a
problem for GPL programs, but now it is relicensed to the Apache 2
License in part to make it directly compatible with GPLv3 programs, so
there is no problem there. But GnuTLS would be ok as well.

Have there been any plans for such a change? If not, what do you think
about it? If we reach an agreement on this, I can start working on the
change and send patches.

Best regards,
Pavel Cahyna
Red Hat


--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory




reply via email to

[Prev in Thread] Current Thread [Next in Thread]