1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1094969: Bug#976991: closed by Ryan Tandy (Re: Bug

    From Chris Hofstaedtler@21:1/5 to brian m. carlson on Sat Apr 12 23:50:01 2025
    On Thu, Feb 13, 2025 at 01:50:26AM +0000, brian m. carlson wrote:
    I think this is a serious license violation which definitely needs to be fixed before trixie.

    I'll address it with the ftp-masters.

    So, did anything come out of this? I see you cloned this bug as
    #1095859, but then closed that later.

    Chris

    PS: I guess the fun option is to disable libcurl in git.

    Adding curl maintainers to CC:.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Runxi Yu@21:1/5 to All on Sun Apr 13 11:10:01 2025
    Hi,

    I'm writing to express my opinion that distributing them on the same ISO
    is probably not a problem as it is "Mere Aggregation"; see <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#TOCGPLAndNonfreeOnSameMachine>
    and <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#MereAggregation>.

    However, I concur that linking them is problematic. There might be some
    merit to consider OpenSSL a system library, but I would err on the side
    of caution.

    --
    Best regards,

    Runxi Yu (they/them)
    https://runxiyu.org
    YK Pao School

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Henrique@21:1/5 to Chris Hofstaedtler on Sun Apr 13 12:30:01 2025
    Hello everyone,

    On Sat, 12 Apr 2025 at 22:40, Chris Hofstaedtler <zeha@debian.org> wrote:

    On Thu, Feb 13, 2025 at 01:50:26AM +0000, brian m. carlson wrote:
    I think this is a serious license violation which definitely needs to be fixed before trixie.

    I'll address it with the ftp-masters.

    So, did anything come out of this? I see you cloned this bug as
    #1095859, but then closed that later.

    Brian, if you think this is serious you have to bring this up to the ftp-master team.

    We shouldn't do anything unless they confirm this is an issue.

    The following is not an argument on whether this is right or wrong:

    I've done a quick analysis on other distros, I don't have 100% confidence in the findings because I didn't install and run ldd on all, some were build recipe analysis:

    1) Links git with libcurl-openssl:
    Arch, CentOS (RedHat I suppose), Fedora, Gentoo, OpenSUSE and Parabola.

    2) Links git with libcurl-gnutls:
    Debian, GuixOS and Ubuntu links git with a gnutls libcurl.

    But all three of them still have libssl linked to something on git, GuixOS directly links "git-imap-send" to libssl/OpenSSL.

    Adding curl maintainers to CC:.

    Thank you for CCing us.

    Regards,


    --
    Samuel Henrique <samueloph>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Henrique@21:1/5 to All on Sun Apr 13 13:10:01 2025
    Based on the replies to https://mastodon.social/@bagder/114329630276196304, where there was some uncertainty around where the issue comes from, I figured I should clarify it here:

    git on Debian ends up indirectly linked to OpenSSL through the following:
    git -> libcurl-gnutls -> libldap -> libssl

    The openldap package switched to linking to OpenSSL in January this year (2025) for Debian unstable.

    Other distros either have a more direct link between them:
    git -> libcurl-openssl -> libssl

    Or they link to libssl directly, which is what I saw on GuixOS with "git-imap-send".

    Then this bug is about whether this will result in license incompatibilities between GPL-2.0 and Apache-2.0, but regardless of the licensing question, it's also sad to lose GnuTLS support for OpenLDAP.

    This means it's impossible to have a GnuTLS build of libcurl with ldap support without also pulling OpenSSL transitively.

    But as Ryan said, that's the case "unless someone else steps up to maintain that support".

    Regards,

    --
    Samuel Henrique <samueloph>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ryan Tandy@21:1/5 to Samuel Henrique on Sun Apr 13 17:50:01 2025
    On Sun, Apr 13, 2025 at 11:58:57AM +0100, Samuel Henrique wrote:
    but regardless of the licensing question, it's also sad to lose GnuTLS >support for OpenLDAP.

    This means it's impossible to have a GnuTLS build of libcurl with ldap support >without also pulling OpenSSL transitively.

    I apologize for not announcing the change before implementing it. I
    should have remembered that libcurl-gnutls exists, and initiated a
    discussion about it.

    If the switch regresses some use case, I can try to help fix things, or
    at worst revert it for trixie, to buy more time.

    On Sun, Apr 13, 2025 at 11:23:08AM +0100, Samuel Henrique wrote:
    Brian, if you think this is serious you have to bring this up to the ftp-master
    team.

    We shouldn't do anything unless they confirm this is an issue.

    Agreed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Sun Apr 13 19:40:01 2025
    BTW, could somebody clarify why git upstream has this ./configure
    option:

    --with-openssl use OpenSSL library (default is YES)
    ARG can be prefix for openssl library and headers

    ..., and defaulting to YES?

    It looks like git upstream -expects- to be linked to OpenSSL. But if
    the position of upstream committers is that this would produce
    something undistributable, that would be very surprising.

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From brian m. carlson@21:1/5 to Chris Hofstaedtler on Sun Apr 13 22:00:01 2025
    On 2025-04-13 at 17:29:53, Chris Hofstaedtler wrote:
    BTW, could somebody clarify why git upstream has this ./configure
    option:

    --with-openssl use OpenSSL library (default is YES)
    ARG can be prefix for openssl library and headers

    ..., and defaulting to YES?

    It looks like git upstream -expects- to be linked to OpenSSL. But if
    the position of upstream committers is that this would produce
    something undistributable, that would be very surprising.

    This is totally fine if I'm building against the distro OpenSSL and I'm
    not distributing OpenSSL. For instance, a company I'm familiar with
    shipped Git linked against the distro OpenSSL and distributed only Git,
    but not OpenSSL.

    The system library exception states this:

    However, as a special exception, the source code distributed need not
    include anything that is normally distributed (in either source or
    binary form) with the major components (compiler, kernel, and so on)
    of the operating system on which the executable runs, unless that
    component itself accompanies the executable.

    In Debian's case, the component (OpenSSL) accompanies the executable
    (Git) on the mirrors and on install media, so it doesn't apply. In the
    case of that company, they could avail themselves of the distro OpenSSL
    since they were not distributing it, only Git. So for most people
    building Git for local use, this is a fine default.

    Also, as a practical matter, nobody upstream actually uses the configure
    script and if it breaks (which is not infrequent), the direction is just
    to use the Makefile with a `config.mak` file to set the settings you
    want. The configure script tends to be maintained by one-off patches
    from people and it is not reflective of what upstream actually thinks
    you should use, especially since it doesn't control many of the options available in the Makefile. All of the contributors configure a local `config.mak` file with various options (such as using clang in order to
    get LSP support) and it's expected that most others will as well for
    various reasons.

    For instance, Debian Policy ยง3.4.1 prohibits hardlinks in packages,
    which are the default for placing files in `/usr/lib/git-core`. For
    most people, the default of using hardlinks is fine, but Debian must
    configure `NO_INSTALL_HARDLINKS` to comply with policy. So the defaults
    are not necessarily designed for every use, or even to please distros by default.
    --
    brian m. carlson (they/them)
    Toronto, Ontario, CA

    -----BEGIN PGP SIGNATURE-----

    wr0EABYKAG8Fgmf8FcoJEHwMSWKIh6KBRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z LnNlcXVvaWEtcGdwLm9yZzLjT59goCAaZFz6ONyDnVzmn2QmKmsBlSvjIj67Rriu FiEECCzmip28ZfuD0cORfAxJYoiHooEAAAwIAP4h0LJHH8rRSjOEdPiNi46mD54u kAPQO2m+t+0DUrY6CAEAicx9G4LuttAEa7hYpTRZmUv8JdLUYIHsaqD625HL+As=
    =K68u
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From brian m. carlson@21:1/5 to Simon McVittie on Mon Apr 14 02:30:01 2025
    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

    -----BEGIN PGP SIGNATURE-----

    wr0EABYKAG8Fgmf8VgIJEHwMSWKIh6KBRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z LnNlcXVvaWEtcGdwLm9yZypEkBZGZpMJofACxvyaOGXvDAozNjJqn+PGPJvVoxrv FiEECCzmip28ZfuD0cORfAxJYoiHooEAAIVHAP9JyJ055PGASvVhEXSeq98M4ifC bzqLSjRCyysalxFkjAD/QfGCFqyXNbMNzVbUBjBRhxSarEkyA4bC1pUG4yup+gA=
    =DANA
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)