janbar / openssl-cmake

Build OpenSSL with CMake on MacOS, Win32, Win64 and cross compile for Android, IOS
Other
277 stars 144 forks source link

CMake for OpenSSL 3.0 Support? #21

Open a770931435 opened 3 years ago

ghost commented 3 years ago

Would also love that

janbar commented 2 years ago

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.

hwhsu1231 commented 2 years ago

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:

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?

jimmy-park commented 1 year ago

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.

flagarde commented 1 year ago

Why not creating a repo with an action pregenerating the files for all the targets ?

Fsu0413 commented 1 year ago

(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.

Fsu0413 commented 1 year ago

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.

flagarde commented 1 year ago

@Fsu0413 wow seems very nice work. If you can succeeded to make it compile without perl it would be so nice 😊

Fsu0413 commented 1 year ago

@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 commented 1 year ago

@Fsu0413 why we need asm?

Fsu0413 commented 1 year ago

@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.

bsergean commented 1 year ago

asm is assembly, most likely to hardware accelerate a lot of operations. Without it some things might be pretty slow, like AES encryption/decryption.

flagarde commented 1 year ago

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

bsergean commented 1 year ago

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.

flagarde commented 1 year ago

@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

cristianadam commented 12 months ago

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 🤷🏻‍♂️

Fsu0413 commented 11 months ago

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.

Fsu0413 commented 8 months ago

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.