Re: Will OpenSSL's license change impact us?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sat, Mar 25, 2017 at 10:44 PM, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> On Sat, Mar 25, 2017 at 12:51:52AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> They're changing their license[1] to Apache 2 which unlike the current
>> fuzzy compatibility with the current license[2] is explicitly
>> incompatible with GPLv2[3].
>>
>> We use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.
>>
>> This still hasn't happened, but given the lifetime of git versions
>> packaged up by distros knowing sooner than later if this is going to
>> be a practical problem would be good.
>>
>> If so perhaps we could copy the relevant subset of the code int our
>> tree, or libressl's, or improve block-sha1.
>
> I think that most distros don't link against OpenSSL because they can't
> take advantage of the system library exception.  I don't think that's
> going to change.

"ldd -r" against git itself on my Debian testing doesn't return
libssl, but git-imap-send is dynamically linked to it:

$ ldd -r /usr/lib/git-core/git-imap-send|grep ssl
        libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
(0x00007f244b2f6000)
$ apt-cache show libssl1.0.2:amd64
Package: libssl1.0.2
Source: openssl1.0
Version: 1.0.2k-1
[...]
Homepage: https://www.openssl.org

> If we want to consider performance-related concerns, I think the easier
> solution is using Nettle, which is LGPL 2.1.  Considering that the
> current opinions for a new hash function are moving in the direction of
> SHA-3, which Nettle has, but OpenSSL does not, I think that might be a
> better decision overall.  It was certainly the implementation I would
> use if I were to implement it.

Yeah there's a lot of options open for just sha1-ing, but we also use
OpenSSL for TLS via imap-send.