[PATCH 1/1] fix libssl version check

[Arran Cudbard-Bell]

On 16 Oct 2014, at 10:25, Herwin Weststrate <herwin at quarantainenet.nl> wrote:

> On 16-10-14 15:29, Christian Hesse wrote:
>> Arran Cudbard-Bell <a.cudbardb at freeradius.org> on Thu, 2014/10/16 09:14:
>>> 
>>> On 16 Oct 2014, at 06:15, Christian Hesse <list at eworm.de> wrote:
>>> 
>>>> From: Christian Hesse <mail at eworm.de>
>>>> 
>>>> When doing bitwise AND leading zeros do not matter, trailing ones do.
>>> 
>>> That's not all you changed, the mask bits are different, why?
>> 
>> I think I changed it to how it was intended. The update from openssl 1.0.1i
>> to 1.0.1j broke my system again as wrong bits were compared.
>> 
>> These are the correct masks:
>> 
>> 0x0000000f -> status
>> 0x00000ff0 -> patch
>> 0x000ff000 -> fix
>> 0x0ff00000 -> minor
>> 0xf0000000 -> major
>> 
>> Or did I miss anything?
> 
> The format is described in ssleay(3) and copied in the code above the
> function that's been updated:
> 
>  OpenSSL version number consists of:
>  MMNNFFPPS: major minor fix patch status
> 
> So it's actually 0xff0000000 to get the major version (although it may
> take a while before we'll actually get to version 16 ;)) and for
> readability, the other ones should have an extra 0 at the beginning. The
> first line of the patch (the status mismatch check) should be left as it
> is now.

OPENSSL_VERSION_NUMBER is a numeric release version identifier:

 MNNFFPPS: major minor fix patch status

The status nibble has one of the values 0 for development, 1 to e for betas 1 to 14, and f for release.

for example

 0x000906000 == 0.9.6 dev
 0x000906023 == 0.9.6b beta 3
 0x00090605f == 0.9.6e release

Versions prior to 0.9.3 have identifiers < 0x0930. Versions between 0.9.3 and 0.9.5 had a version identifier with this interpretation:

 MMNNFFRBB major minor fix final beta/patch

for example

 0x000904100 == 0.9.4 release
 0x000905000 == 0.9.5 dev

So OpenSSL versions >= 0.9.6 only used a nibble for the major version number.

> The rest of the code looks to me like a confusion between big-endian and
> little-endian.

Yes, that was the issue.

> The patch set looks pretty sane to me, as long as the
> extra 0 or f is added.
> I haven't tested if the endianness is actually the same as the
> documentation suggests.

It failed to fix some other issues, I just rolled my own locally.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20141016/65911db8/attachment-0001.pgp>