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

Re: libssh and libgcrypt recent vulnerability

On 1/30/21 8:36 PM, Andreas Schneider wrote:
On Friday, 29 January 2021 22:42:27 CET Aris Adamantiadis wrote:
Hi everyone.

Hi Aris,
Libgcrypt has been an itch that scratched both Andreas and me for a
while. Till now, the biggest problem was the workload associated in
maintaining the gcrypt backend (mostly with external contributions, but
still). This backend was generously contributed by people who wanted
libssh in debian at a time when OpenSSL had licensing issues, and I
accepted it at a time when I wasn't aware of the implications.

Today it seems to me that that in addition to this workload problem, the
libgcrypt maintainers aren't on the same page as libssh in terms of CI
and code quality in general, especially for a security software. This
twitter thread in particular highlights this:

I also saw this thread already.
I propose we evaluate how many users depend on our libgcrypt build and
get rid of it for the next version, if it's possible.

I agree.

Licensing issues
with OpenSSL is in my opinion not a sufficient reason anymore to keep
libgcrypt support.

We have a mbedtls backend and mbedtls is available under GPL 2.0 or Apache 2.0
License. If someone really wants a diffent backend I would suggest to add a
libnettle based backend.

By stripping libgcrypt out, we can also more easily
introduce new ciphers and focus on getting them right on two backends
instead of three. This has been one of the reasons I haven't worked on
libssh recently. Adding diffie-helman-group-exchange with support for
three crypto backend was a very tedious task.

This would also mean that we can e.g. get rid of our chacha2020-poly1305
implementation as both OpenSSL and mbedtls are offering it!

Here is my patch, feel free to comment and test it.


Will look into it on Monday. Thanks!

thank you for starting this discussion with actual commit proposed. We talked about this for some time already and this incident is raising the issue more priority again. For Fedora, we do not need libgcrypt backend, but I would certainly like to get hold of the ones who contributed this code before we will remove it altogether (I was not here at that time so I do not know the whole story).

On the technical note, the changeset is missing is removal of libgcrypt reference from doc/introduction.dox (and sign-off trailers).

The other question is whether we want to remove it now or after 0.10.0 release which should be at sight. I am still a bit hesitant to do it from day to day without announcement and some grace-period.

Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: libssh and libgcrypt recent vulnerabilityAris Adamantiadis <aris@xxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org