[cooker] RPM why not use internal beecrypt ?

TPG · September 24, 2019, 9:27pm

Hi,

why our RPM uses external crypto engine which is set to OpenSSL ?
Isn't this a overkill ?

OpenMandrivaAssociation/rpm/blob/e8e84444006f608eee038c4acb7484943f50e439/rpm.spec#L555


    --sharedstatedir=%{_var}/lib \
    --with-vendor=%{_real_vendor} \
    %{?_with_debug} \
    --with-external-db \
    --with-lua \
    --without-selinux \
    --with-cap \
    --with-acl \
    %{?with_ndb: --with-ndb} \
    --enable-python \
    --with-crypto=openssl


%make_build
cd python
%py2_build
%py3_build
cd -


%install
%make_install

I'd like to suggest ti use RPM's internal beecrypt as a crypto engine. WDYT
?

ngompa · September 24, 2019, 9:33pm

No. BeeCrypt is completely unmaintained these days. And RPM does not
bundle beecrypt either. You still need to ship the library.

We use OpenSSL because it's currently the fastest and best maintained
crypto backend. I explicitly picked it because of that. In the future,
we may switch to the newer gcrypt backend, but for now, we're using
OpenSSL.

NSS is a ridiculous pain to deal with these days with constant ABI/API
breaks, so it's not a reasonable option for RPM.

TPG · September 25, 2019, 7:54am

Thanks for clarification. I had that wrong idea about that beecrypt is
completed
I saw that latest commits adds libgcrypt support to RPM. Do you think that
switching to libgcrypt may give us some benefits ?

ngompa · October 4, 2019, 11:46am

I need to do some more tests, but at least there's a preliminary
benefit of speed (hashing functions take 50% less time). And with
gcrypt ABI breaking a lot less often than OpenSSL, it's a very
attractive option.