openssl-cmake
openssl-cmake copied to clipboard
janbar
CMake for OpenSSL 3.0 Support？
For now it is not possible, as the build system of openssl-3 uses lot of perl scripts to generate headers depending of input args. So a pure cmake project as it is here cannot configure properly the project.
For now it is not possible, as the build system of openssl-3 uses lot of perl scripts to generate headers depending of input args. So a pure cmake project as it is here cannot configure properly the project.
@janbar
How about "using Perl in CMakeLists.txt"? Details as follows:
- Using the built-in
FindPerl.cmakemodule to executeperlcommand (PERL_EXECUTABLE). - Preparing some CMake Cache Entries to pass those input args to perl scripts.
If it is not possible to create a pure CMake project, I think the senod best option is to just use cmake command to complete the compilation and installation.
How about that? Is it possible/feasible?
I had the same issue about building OpenSSL and linking it in CMake. I agree that the pure CMake project for recent version of OpenSSL is not possible at this time. So I decided to write my own openssl-cmake It's basically a CMake wrapper of Perl scripts and Make build system.
Why not creating a repo with an action pregenerating the files for all the targets ?
(Following investigation is done on OpenSSL 3.0.9 and 1.1.1u)
According to my investigation, most of the files in the include directory which should be generated in OpenSSL 3.0 via Perl uses only following Perl module.
{-
use OpenSSL::stackhash qw(***);
-}
... with the exception of following files:
include/openssl/configuration.h.in # mostly same as previous opensslconf.h.in in 1.1.1. Format of the file is changed a little bit.
include/openssl/fipskey.h.in # FIPS key related, predefined in Configure but can be set by user.
include/openssl/opensslv.h.in # version information, can be pre-generated by release version
include/crypto/bn_conf.in # exactly same as 1.1.1
include/crypto/dso_conf.in # exactly same as 1.1.1
OpenSSL::stackhash is util/perl/OpenSSL/stackhash.pm.
I checked this file and it don't use configdata.pm which is generated during Configure runs, which means it generate same set of code provided the stackhash.pm has no modification.
So most of the files can be pre-generated by release version (just as opensslv.h.in)
fipskey.h.in can also be pre-generated by release version by using the value predefined in Configure.
I don't think there would be any use case that some one will change it.
Other files may be just generated in the way where 1.1.1 did.
I hope the above investigation result will help with OpenSSL 3.0 support of this repository.
(Edit 2023/6/11) I have achieved to generate the files. There is something different from original file generated by Perl but I don't think it will affect anything in behavior.
https://github.com/Fsu0413/openssl-externalCMake/blob/3.0/crypto/stackhash.cmake
Br.
2023/6/11 Update:
Another set of files is generated in providers/common/der and providers/common/include/prov directory from some ASN1 files in the source code.
Generation of these files also doesn't use the configdata.pm. It is using providers/common/der/oids_to_c.pm
providers/common/der/oids_to_c.pm is using an algorithm to calculate the values used by the generated files.
I dumped the algorithm and implemented it using CMake.
https://github.com/Fsu0413/openssl-externalCMake/blob/3.0/providers/generateder.cmake
Br.
@Fsu0413 wow seems very nice work. If you can succeeded to make it compile without perl it would be so nice 😊
@flagarde
Perl is needed for ASM so a build without Perl can only be no asm. Also Perl is used for building documentation.
My project (Fsu0413/openssl-externalCMake) may be currently able to build without Perl on 1.0.2 and 1.1.1 branch. I designed the workflow but never tested it. It will produce only binary without ASM, no documentation. Maybe you can try it.
@flagarde
It is a feature of OpenSSL, instead of something "we need". ASM is just original feature of OpenSSL, where building with ASM improves performance on most platforms.
It should be always up to the user choosing whether the build is using ASM (i.e. whether the ASM feature is used), even when using OpenSSL original Perl-based Configure.
Br.
asm is assembly, most likely to hardware accelerate a lot of operations. Without it some things might be pretty slow, like AES encryption/decryption.
asm is assembly, most likely to hardware accelerate a lot of operations. Without it some things might be pretty slow, like AES encryption/decryption.
@bsergean you are right assembly can improve performance, but they say it improves safety too. The thing here is maybe asm is necessary for good performance/safety, using perl to generate asm is purely developper choice and I wonder if they are some ways (easy ones) to avoid to have perl. One could be to pregenerate the asm
My guess, from reading a few github PR in openssl, is that perl has been used for many, many years in OpenSSL for all sort of things, so switching from perl to something else would be a non trivial effort.
But I never really look in details in the openssl code base ... so that doesn't mean much.
@bsergean yes is what it seems to be. This makes it more diffucult to compile on windows etc. On linux perl is mainly available so it's not a big problem. Openssl is not cross-platform friendly
At https://github.com/openssl/openssl/issues/10902 there is a CMake generator for their new perl Makefile generator. But failed to get support and is not merged.
On Windows you can have perl from the git package ("C:\Program Files\Git\usr\bin\perl.exe"), which is good enough for building Qt. No idea if it's enough for OpenSSL.
Having a CMake port of OpenSSL would help people which try to build for QNX like here https://github.com/openssl/openssl/issues/22257 🤷🏻♂️
2023/12/10 Update
OpenSSL 3.2.0 introduces paramnames.pm which generates 3 files in the code. It doesn't need configdata.pm.
I dumped the logic and rewrote it using CMake and currently it is served here:
https://github.com/Fsu0413/openssl-externalCMake/blob/3.2/crypto/paramnames.cmake
Also OpenSSL 3.1 series introduces nothing to the build process. Build process run on 3.0 can be run unmodified on 3.1.
2024/3/24 Update
stackhash.pm and paramnames.pm are modified in OpenSSL 3.3.0-alpha1.
The dumped CMake scripts should be modified.
There is nothing new in the progress though.