Hi pavel,
Great, gimme a little time to do that refactor. I can ping you off-list
when it's done.
Al
On 6/26/24 11:29, Pavel Cahyna wrote:
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://urldefense.us/v3/__https://github.com/aide/aide/pull/164/files__;!!G2kpM7uM-TzIFchu!3MX84O25FdmuZ4MxTNfHV_dnmsLTtDRqo8Jbi9uJ9XAUDvO4m2fZLlXk2FT6LPsJ4nsLiGWNKFbIqVHu$
and
https://urldefense.us/v3/__https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/md_crypto.c__;!!G2kpM7uM-TzIFchu!3MX84O25FdmuZ4MxTNfHV_dnmsLTtDRqo8Jbi9uJ9XAUDvO4m2fZLlXk2FT6LPsJ4nsLiGWNKGeouan9$
https://urldefense.us/v3/__https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/md_gcrypt.c__;!!G2kpM7uM-TzIFchu!3MX84O25FdmuZ4MxTNfHV_dnmsLTtDRqo8Jbi9uJ9XAUDvO4m2fZLlXk2FT6LPsJ4nsLiGWNKBwu3d2e$
(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
--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory
