In message <[email protected]> on Fri, 21 Sep 2018 12:29:43 -0400, Viktor Dukhovni <[email protected]> said:
> > > > On Sep 21, 2018, at 12:14 PM, Matt Caswell <[email protected]> wrote: > > > > I support Richard's proposal with an epoch of 1. > > Grudgingly I would accept an epoch in the 3-8 range. > > I would oppose an epoch of 2. > > I can live with that, though it might mean that a minority of > applications will interpret (based on obsolete nibble extraction) > that OpenSSL 2.0.0 (0x1020000FUL) is actually OpenSSL 1.2.0, but > that's probably harmless. It does mean we might never reclaim the > version numbers with 0x2 for the high nibble. The applications who currently care since the release of 1.0.0 use 0xfff0000fL as a mask, meaning that they might as well view 0x102 (258 decimal) as the internal major version number. I haven't seen any example where anyone cares about the exact nibbles, just that 0xfff00000L gives them something to compare. For pre-processing, that might be different, I have no clue how people figure out the exact number to compare OPENSSL_VERSION_NUMBER... I assume, though, that they follow the path of least resistance and simply pick the current number from opensslv.h. -- Richard Levitte [email protected] OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
