Closed mshedsilegx closed 2 months ago
There is a fallback function already defined, but it would not be compiled since the assumption was made that any current Linux system would have that defined. Existence of this function can be easily tested (I just made code changes to do that), but I suspect you might run into other problems if you are trying to compile AES Crypt. For example, some of the C++ features employed are very modern C++ features that were not introduced into compilers until 2022. There are not many, but at least one that I know.
Isn't this OS about 10 years old? Is it really worth supporting on such an old OS?
Oh, I should have mentioned, there is a build container available to make it possible to build AES Crypt via docker. This gives you the flexibility of doing static linking (which we cannot do due to LGPL licensing) and to use in your private environment. You can find that here: https://github.com/terrapane/aescrypt_private_build
We will make the code changes, though, to address this issue. However, I just suspect you will encounter issues with more modern C++ usage.
@mshedsilegx Changes were made to (hopefully) get secutil to build in the absence of explicit_bzero(). Code was tested using newer OS releases to ensure nothing was broken, but we don't have an automated test for RHEL 7. We also changed that one newer C++ construct that has caused some older compilers to complain.
The latest AES Crypt CLI 4.0.5.0 might build now. If there are still issues that are easy to address, we can make more changes. It might prove that building a statically linked binary using that docker container I mentions is the simplest solution, though.
I appreciate your detailed answer and effort. the g++ compiler used in RHEL7 is gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) so quite recent, from devtoolset-11-gcc-c++-11.2.1-9.1.0.1.el7.x86_64 Can I try to retest now ?
Yeah, you can definitely try it. The current version tag is now 4.0.5 for the CLI version of AES Crypt.
Perfect, compiles great on RHEL7, 8, 9. Thanks again.
Very good!
CentOS/RHEL 7 has glibc 2.17, and it does not support explicit_bzero
Causing:
Can we make explicit_bzero conditional of having a recent glibc, and fallback to a different method if not ?