Re: libssh and libgcrypt recent vulnerability
Hi Jakub, 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). IIRC this code was created in 2007 by Jean-Philippe Garcia Ballester who wanted to make libssh suitable for debian, due to the compatibility problems between GPL and OpenSSL's license. I do not know who worked on libgcrypt on purpose last (e.g. with the intend of actually use libgcrypt). I'd really like to have their opinion before taking a harsh decision. The Debian debate seems to be recently settled (thanks Laurent Bigonville for the research) http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972181 On the technical note, the changeset is missing is removal of libgcrypt reference from doc/introduction.dox (and sign-off trailers). I've been made aware of a few typos too, I'll fix this. 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. I agree. let's take some time to collect feedback and let distro maintainers some time to prepare before pulling the plug. We can add a big fat warning in the cmake build process that libgcrypt will not be supported anymore. Regards, Aris
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: 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.
Re: libssh and libgcrypt recent vulnerability
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! Andreas
