[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libssh and libgcrypt recent vulnerability
[Thread Prev] | [Thread Next]
[Date Prev] | [Date Next]
- Subject: Re: libssh and libgcrypt recent vulnerability
- From: Andreas Schneider <asn@xxxxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Sat, 30 Jan 2021 20:36:03 +0100
- To: libssh@xxxxxxxxxx
- Cc: Aris Adamantiadis <aris@xxxxxxxxxx>
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
libssh and libgcrypt recent vulnerability | Aris Adamantiadis <aris@xxxxxxxxxx> |