Re: libssh and libgcrypt recent vulnerability

[Jakub Jelen <jjelen@xxxxxxxxxx>]

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:
> > https://twitter.com/FiloSottile/status/1355192385123340296
>
> 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.
> >
> > https://gitlab.com/arisada/libssh-mirror/-/commit/1ed690e8f5c33ea73d06ab83fc
> > 9eb3283fdfbedf
>
> Will look into it on Monday. Thanks!

Hi,
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.

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