Skip to content
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

CMake for OpenSSL 3.0 Support? #21

Open
a770931435 opened this issue Jun 10, 2021 · 18 comments
Open

CMake for OpenSSL 3.0 Support? #21

a770931435 opened this issue Jun 10, 2021 · 18 comments

Comments

@a770931435
Copy link

No description provided.

@ghost
Copy link

ghost commented Oct 26, 2021

Would also love that

@janbar
Copy link
Owner

janbar commented Jan 23, 2022

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
Copy link

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.cmake module to execute perl command (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?

@jimmy-park
Copy link

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
Copy link

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

@Fsu0413
Copy link

Fsu0413 commented Jun 10, 2023

(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
Copy link

Fsu0413 commented Jun 11, 2023

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
Copy link

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

@Fsu0413
Copy link

Fsu0413 commented Jun 12, 2023

@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
Copy link

@Fsu0413 why we need asm?

@Fsu0413
Copy link

Fsu0413 commented Jun 12, 2023

@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
Copy link

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
Copy link

flagarde commented Sep 15, 2023

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
Copy link

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
Copy link

@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
Copy link

At openssl/openssl#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 openssl/openssl#22257 🤷🏻‍♂️

@Fsu0413
Copy link

Fsu0413 commented Dec 10, 2023

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
Copy link

Fsu0413 commented Mar 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants