[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libssh and libgcrypt recent vulnerability
- Subject: libssh and libgcrypt recent vulnerability
- From: Aris Adamantiadis <aris@xxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Fri, 29 Jan 2021 22:42:27 +0100
- To: libssh@xxxxxxxxxx
Hi everyone.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 propose we evaluate how many users depend on our libgcrypt build and get rid of it for the next version, if it's possible. Licensing issues with OpenSSL is in my opinion not a sufficient reason anymore to keep libgcrypt support. 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.
Here is my patch, feel free to comment and test it. https://gitlab.com/arisada/libssh-mirror/-/commit/1ed690e8f5c33ea73d06ab83fc9eb3283fdfbedf Best regards, Aris
|Re: libssh and libgcrypt recent vulnerability
|Andreas Schneider <asn@xxxxxxxxxxxxxx>