Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h
Thanks for a fast and clear reply! On Mon, Apr 14, 2014 at 1:58 PM, Kurt Roeckx via RT r...@openssl.org wrote: Then a program linking to this library can read either of these global variables at runtime and fail to start or emit a warning if the version isn't up-to-date. Please don't do that. You only create problems if you check the version. I've actually had to remove checks like that from existing programs because it only causes problems. We'd like to make sure that the libraries we're linking to are up-to-date. There are third parties who build our codebase who might not be as careful as we might like. Is there some other way to accomplish this?
Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h
On Mon, Apr 14, 2014 at 11:51:53AM +0200, Tom Swirly via RT wrote: Hello. This is a small feature request that's applicable to all operating systems. *The problem.* The version numbers for OpenSSL appear in the header opensslv.h as macro symbols: OPENSSL_VERSION_NUMBER OPENSSL_VERSION_TEXT Unfortunately, it seems that neither of these two variables are actually used in the OpenSSL library. This is a pity, because it means that a program that links to the OpenSSL library has no way to tell if it's *linking* to the correct library - you can only tell if you are *compiling* with the right header. *A possible solution.* A possible solution is to have two global variables declared in opensslv.h, defined as: long long openssl_version_number = OPENSSL_VERSION_NUMBER; const char* openssl_version_text = OPENSSL_VERSION_TEXT; That last thing will not work properly because it would create a relocation for that with a fixed size to copy it from the shared library to the program, because you can't have text relocations. So the program that links to it might not see the whole string, or might copy a too long string. You really want to use a function. There are also already those function: const char *SSLeay_version(int type); unsigned long SSLeay(void); Then a program linking to this library can read either of these global variables at runtime and fail to start or emit a warning if the version isn't up-to-date. Please don't do that. You only create problems if you check the version. I've actually had to remove checks like that from existing programs because it only causes problems. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h
Thanks for a fast and clear reply! On Mon, Apr 14, 2014 at 1:58 PM, Kurt Roeckx via RT r...@openssl.org wrote: Then a program linking to this library can read either of these global variables at runtime and fail to start or emit a warning if the version isn't up-to-date. Please don't do that. You only create problems if you check the version. I've actually had to remove checks like that from existing programs because it only causes problems. We'd like to make sure that the libraries we're linking to are up-to-date. There are third parties who build our codebase who might not be as careful as we might like. Is there some other way to accomplish this? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h
On Mon, Apr 14, 2014 at 08:27:17PM +0200, Tom Swirly via RT wrote:
We'd like to make sure that the libraries we're linking to are
up-to-date. There are third parties who build our codebase who
might not be as careful
as we might like.
Postfix issues warnings whent the run-time library version looks
sufficiently different from the compile-time library. However, it
is not possible to use the run-time reported patch level to detect
whether a particular fix is applied. Many vendor releases of
OpenSSL backport fixes without updating the library patch level.
In part this is because OpenSSL patch levels are still not just
patches. For example, a new feature (padding extension) was added
between 1.0.1f and 1.0.1g. This is unfortunate, as new features
were not supposed to be added in patch releases starting with 1.0.0.
It would be good to actually move to a strict buf-fix only policy
for patch releases as of some future OpenSSL release.
/*
* Parsed OpenSSL version number.
*/
typedef struct {
int major;
int minor;
int micro;
int patch;
int status;
} TLS_VINFO;
/* tls_version_split - Split OpenSSL version number into major, minor, ... */
static void tls_version_split(long version, TLS_VINFO *info)
{
/*
* OPENSSL_VERSION_NUMBER(3):
*
* OPENSSL_VERSION_NUMBER is a numeric release version identifier:
*
* MMNNFFPPS: 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. Parsed OpenSSL version number. 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
*
* Version 0.9.5a had an interim interpretation that is like the current
* one, except the patch level got the highest bit set, to keep continu-
* ity. The number was therefore 0x0090581f.
*/
if (version 0x0930) {
info-status = 0;
info-patch = version 0x0f;
version = 4;
info-micro = version 0x0f;
version = 4;
info-minor = version 0x0f;
version = 4;
info-major = version 0x0f;
} else if (version 0x00905800L) {
info-patch = version 0xff;
version = 8;
info-status = version 0xf;
version = 4;
info-micro = version 0xff;
version = 8;
info-minor = version 0xff;
version = 8;
info-major = version 0xff;
} else {
info-status = version 0xf;
version = 4;
info-patch = version 0xff;
version = 8;
info-micro = version 0xff;
version = 8;
info-minor = version 0xff;
version = 8;
info-major = version 0xff;
if (version 0x00906000L)
info-patch = ~0x80;
}
}
/* tls_check_version - Detect mismatch between headers and library. */
voidtls_check_version(void)
{
TLS_VINFO hdr_info;
TLS_VINFO lib_info;
tls_version_split(OPENSSL_VERSION_NUMBER, hdr_info);
tls_version_split(SSLeay(), lib_info);
if (lib_info.major != hdr_info.major
|| lib_info.minor != hdr_info.minor
|| lib_info.micro != hdr_info.micro)
msg_warn(run-time library vs. compile-time header version mismatch:
OpenSSL %d.%d.%d may not be compatible with OpenSSL %d.%d.%d,
lib_info.major, lib_info.minor, lib_info.micro,
hdr_info.major, hdr_info.minor, hdr_info.micro);
}
--
Viktor.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3306] OpenSSL Enhancement: the binary library should contain the version strings found in the header opensslv.h
On Mon, Apr 14, 2014, Tom Swirly via RT wrote: We'd like to make sure that the libraries we're linking to are up-to-date. Take a look at the postfix code: tls_check_version(). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
