On 2025-04-13 at 22:53:45, Simon McVittie wrote: > openldap is not the only relevant dependency chain. There is also at least: > > git -> libcurl3t64-gnutls -> libgssapi-krb5-2 -> libkrb5-3 -> libssl3t64
I think this dependency only exists because of the spake preauth plugin and the main libkrb5.so.3 isn't linked with OpenSSL. I don't know why a preauth plugin would actually be used outside something like kinit to get credentials, so I doubt this is a problem. (I do use Kerberos, but I can't call myself an expert, so I am happy to be corrected.) In any event, if necessary, I think this can be fixed with `--with-crypto-impl=builtin` without a problem. > git -> libcurl3t64-gnutls -> libssh2-1t64 -> libssl3t64 > > (in the case of at least libssh2-1t64 it's for OpenSSL's lower-level > libcrypto library rather than the actual libssl, but Debian packages those > two libraries together in the libssl3t64 package, and as far as I know they > are both under the same license). I think if libcurl-gnutls dropped libssh2 (which used to have a GnuTLS variant but no longer does) and OpenLDAP that would fix the problem. I've never seen any code that uses SSH or LDAP support via curl or libcurl and although I'm sure some does exist, I doubt it's very common and many versions are compiled without those features anyway. Or, of course, OpenLDAP could switch back to GnuTLS and those features could be kept, although I agree that's undesirable for other reasons. With a rebuilt version of libcurl3t64-gnutls with those two items dropped, neither libcurl3t64-gnutls nor git-remote-https (nor git-imap-send) link against libssl or libcrypto. (I accidentally rebuilt curl from experimental, but I'm sure unstable would work the same way.) -- brian m. carlson (they/them) Toronto, Ontario, CA
signature.asc
Description: PGP signature
