>> 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.


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).



Lukas

                                          

Reply via email to