On Thu, Dec 11, 2014 at 6:41 AM, Lukas Tribus <luky...@hotmail.com> wrote:
>>> Many Lolz.. Lukas you just made my day......
>>>
>>> They've been misused that way, and more than once, by more than one
>>> project. This is why we really want it to be just a string, and
>>> strongly discourage people from using it in the way it has been
>>> abused.
>>>
>>> ... we could always change it so the string is wheezy, dopy, sneezy,
>>> drippy, or whatever for each release ;)
>>
>> Lukaz, is this the world you want:
>>
>> /* The following test is suggested by Richard Levitte */
>> if (((OPENSSL_VERSION_NUMBER ^ SSLeay()) & 0xffffff0f)
>>
>> Yes, it is. Because you are asking for it.
>
> I don't think it is. I'm perfectly fine with freezing OPENSSL_VERSION_NUMBER
> and LIBRESSL_VERSION_NUMBER forever and ever.
>
> I asked to bump the string in OPENSSL_VERSION_TEXT, which is currently
> set to "LibreSSL 2.1", but apparently that is just as bad. Of that I was not
> aware.
>
> Well then, let me ask you this: Why not drop the version in
> OPENSSL_VERSION_TEXT altogether and simply set it to "LibreSSL"? That
> way there is no confusion about what to expect from its content while
> still permitting applications accessing it to build.

I like that idea. That makes it consistently correct, rather than a
broken clock that's right twice a day.

>
> FYI: boringssl dropped this symbol completely, which means it breaks
> the build of applications accessing it. That I believe is too intrusive in
> the LibreSSL case.
>
>
> It looks like serious packaging (of portable) should explicitly look at
> major/minor in ssl/shlib_version then, instead of the actual libressl release,
> just as its done in ports (afaik).

For API/ABI compatibility, yes. I guess the only thing we haven't
addressed is security updates, which is probably why you wanted the
string in the first place. Does pkg-config --modversion openssl
scratch the itch properly for cases not using OS packages?

All of the ops shops I've worked at just made their own local apt or
yum package repos, so there wasn't any need to use package-specific
commands to determine what versions were installed. I guess in the
openssl(1) case, it has a longer history than most packages.

>
> Lukas
>
>

Reply via email to