-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add HeaderVersion() and LibraryVersion() functions #371
Comments
The following patch works as expected (documentation comments removed for brevity):
If nothing special is done, then everything operates as expected. A failure can be introduced that mimics mixing/matching library versions:
Running
|
These function are intended to catch mining and matching of library versions. BuildVersion provides CRYPTOPP_VERSION when the shared object was built. RuntimeVersion provides CRYPTOPP_VERSION the app compiled against, which could be different than the shared object's version
Cleared at Commit 6f7339c81b26985a. Function names updated at Commit 42af35fd2bcf00e9. |
We've been following a thread from Ethereum. One of the side/related issues appears to be determining the Crypto++ version.
The problem is,
CRYPTOPP_VERSION
is a macro inconfig.h
, around line 65, and it can be a bit misleading. Someonecould be runtime linking against a shared object version 5.5, but if library versions are mixed/matched, then they could get 5.6.5 from the header.I think we need two functions in the
CryptoPP
namespace:int HeaderVersion()
int LibraryVersion()
HeaderVersion
would returnCRYPTOPP_VERSION
fromconfig.h
. Its the version of the library the app was built against. The function should be declared in a header, and the definition should be in the header, too.LibraryVersion
would returnCRYPTOPP_VERSION
used to build the library. The function should be declared in a header, and the definition should be in a source file to ensure it records what a distro builds and distributes the library, and it does not change when an app builds against it.Both
LibraryVersion
andHeaderVersion
should reside int heCryptoPP
namespace. BothLibraryVersion
andHeaderVersion
should use C linkage (extern "C"
) so that those whodlsym
for it don't have to contend with name mangling.Later, if users mix and match library versions, then they will be able to detect the condition. For app code, it could be as simple as:
OpenSSL and other projects have the same problem and similar mechanisms. For example, here is OpenSSL's
SSLeay_version
man page, which returns build-time version information. And here is theOPENSSL_VERSION_NUMBER
macro man page, which provides the app's runtime version.The text was updated successfully, but these errors were encountered: