Re: Crypto backend in freeipmi

[Pavel Cahyna]

Hi Al,

thank you for your quick reply, yes, if you can do a refactor to make
this work easier, that would be great! My colelagues more experienced
with crypto recommend to not introduce wrappers ass they would make the
code much more complicated especially if there are only a few uses. Here
are two examples of code with configurable crypto backends:

https://github.com/aide/aide/pull/164/files

and
https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/md_crypto.c
https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/md_gcrypt.c

(my understanding is that the first one uses ifdefs, in the second one
there is one file for each implementation).

Best regards, Pavel

On Wed, Jun 26, 2024 at 11:10:41AM -0700, Al Chu wrote:
> 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
> 
>