Fix no-sm2

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5673)

Add SM2 signature and ECIES schemes

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull

Add SM2 signature and ECIES schemes

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4793)

show more ...

Configure: pass -no-integrated-as.

Occasionally you have to pass -no-integrated-as to clang, but we
consider any -no-option as no-option. Don't touch -no-integrated-as.

Reviewed

Configure: pass -no-integrated-as.

Occasionally you have to pass -no-integrated-as to clang, but we
consider any -no-option as no-option. Don't touch -no-integrated-as.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5613)

show more ...

Configure: maintain compability with pre-"make variables" Configure

There were a few environment variables that we supported in earlier
Configure versions which got transfered to the %us

Configure: maintain compability with pre-"make variables" Configure

There were a few environment variables that we supported in earlier
Configure versions which got transfered to the %user table. This
change makes sure that we still support them, by simply pre-populating
the corresponding %user entries with those environment values.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)

show more ...

Configure: Don't fail if there were "make variables" set in env

The original intent was that if someone had a "make variable" set in
any kind of way, be it as an environment variable or

Configure: Don't fail if there were "make variables" set in env

The original intent was that if someone had a "make variable" set in
any kind of way, be it as an environment variable or as an argument to
Configure, we wouldn't allow compiler or linker flags as arguments as
well. That made both of these configurations equivalently impossible:

./Configure target CFLAGS=-foo -lextra

CFLAGS=-foo ./Configure target -lextra

While this makes things look nice and consistent, real world use makes
this hard, as many projects where OpenSSL is a component also set
these variables for other components that use GNU autotools.

Therefore, we need to adapt our Configure accordingly. By
consequence, the two Configure lines above will not be equivalent any
more:

./Configure target CFLAGS=-foo -lextra

This command line will still fail, because the "make variable" was
given as a command line argument. This cannot be a mistake and is
therefore not allowed.

CFLAGS=-foo ./Configure target -lextra

This command line will work, but because there is a linker flag as
a command line argument, the environment (i.e. CFLAGS) is ignored.
That isn't quite consistent with the previous command, but is the old
Configure behavior, before the support for "make variables" was added,
and is therefore the backward compatible behavior.

Fixes google/oss-fuzz#1244

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)

show more ...

Configure: allow to enable afalgeng if target does not start with Linux

The Debian build system uses a `debian' target which sets CFLAGS and
then we have for instance debian-amd64 which

Configure: allow to enable afalgeng if target does not start with Linux

The Debian build system uses a `debian' target which sets CFLAGS and
then we have for instance debian-amd64 which inherits from
linux-x86_64 and debian [0]. So far so good.

Unless there are different suggestions how to do this, I would keep it.
However since the target name does not start with `linux', the build
system does not enable the afalg engine. So in order to get enabled, I
added a
`enable => [ "afalgeng" ],'
to the generic linux config which sets it explicit (as suggested by
Richard Levitte). Having this set, we can check for it instead matching
the target name.

[0] https://sources.debian.org/src/openssl/1.1.0g-2/Configurations/20-debian.conf/
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5169)

show more ...

Configure: catch the build tree configdata.pm

There are things depending on configdata.pm. However, it's perfectly
possible that there is one in the source directory from a previous

Configure: catch the build tree configdata.pm

There are things depending on configdata.pm. However, it's perfectly
possible that there is one in the source directory from a previous
build, and that might disrupt an out of source build. To avoid this
conflict, make sure never to use the source tree configdata.pm in that
case, i.e. make the hard assumption that it's a generated file in the
build tree, which it is.

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5546)

show more ...

Configure: don't mangle the directory again when checking DEPEND inclusion

When generating the correct inclusion directory for DEPEND, we mangled
it to be relative to the build or the so

Configure: don't mangle the directory again when checking DEPEND inclusion

When generating the correct inclusion directory for DEPEND, we mangled
it to be relative to the build or the source directory. However, the
value we handle already come with a correct directory, so we only need
to use it as is.

Fixes #5543

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5546)

show more ...

Configure et al: Move the definition of library only flags

We're currently using the attributes 'defines', 'cppflags', 'cflags'
etc quite liberally, with no regard for where that ends up

Configure et al: Move the definition of library only flags

We're currently using the attributes 'defines', 'cppflags', 'cflags'
etc quite liberally, with no regard for where that ends up. Quite a
few of those flags are actually only relevant for the libraries
(mostly libcrypto), so it's safe to say that those could be applied to
the libraries only.

So, we move some of those flags to 'lib_defines', 'lib_cppflags',
'lib_cflags', etc.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5560)

show more ...

Configure: correct the check of env vars vs command line flags

The check to detect if env / make variables conflicted with compiler /
linker flags on the configure command line went a li

Configure: correct the check of env vars vs command line flags

The check to detect if env / make variables conflicted with compiler /
linker flags on the configure command line went a little too far, and
would stop the configuration process if any such command line flag was
given, with no regard for the env / make variables at all.

This change refines the check so the stop only gets triggered if any
such flags were given AND any of the corresponding variables are set.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5561)

show more ...

Configure: disallow the mixture of compiling flags and env / make variables

Note that this might give surprising results if someone forgets an environment
variable that has been set prev

Configure: disallow the mixture of compiling flags and env / make variables

Note that this might give surprising results if someone forgets an environment
variable that has been set previously.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

show more ...

Configure et al: get rid of last traces of plib_lflags / PLIB_LDFLAGS

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

config: Pass diverse flags to Configure via the environment

Passing flags "discovered" by 'config' on the command line to
'Configure' mixes them up with flags given by the user. That is

config: Pass diverse flags to Configure via the environment

Passing flags "discovered" by 'config' on the command line to
'Configure' mixes them up with flags given by the user. That is
contrary to their intention, so they need to be passed in a different
manner.

Enter the environment variables __CNF_CPPDEFINES, __CNF_CPPINCLUDES,
__CNF_CPPFLAGS, __CNF_CFLAGS, __CNF_CXXFLAGS, __CNF_LDFLAGS, and
__CNF_LDLIBS, initialised by 'config', and then used by Configure to
initialise these %config values: defines, includes, cppflags, cflags,
cxxflags, lflags, and ex_libs.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

show more ...

Make "make variables" config attributes for overridable flags

With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a differ

Make "make variables" config attributes for overridable flags

With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).

Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.

We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

show more ...

Configure et al: rename all dso_* to module_* in shared-info.pl

Because there are already attributes with the dso_ prefix that are
used instead of the corresponding lib_ attributes rathe

Configure et al: rename all dso_* to module_* in shared-info.pl

Because there are already attributes with the dso_ prefix that are
used instead of the corresponding lib_ attributes rather than in
addition to them, it gets confusing to have similar or exactly the
same attributes working with different semantics on Unix.

So we rename those by changing the prefix dso_ to module_, and having
those work just like the shared_ attributes, but for DSOs.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

show more ...

Configure: fix small spelling error

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5533)

configdata.pm: ensure $prefix is defined

Fixes #5471

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5472)

Replace the message about configdata.pm as a script

The new message is geared toward issue reports

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/ope

Replace the message about configdata.pm as a script

The new message is geared toward issue reports

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

show more ...

Add a comment in configdata.pm regarding script-only variables

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

Make CROSS_COMPILE another supported "make variable" in Configure

No more special casing for that one, and this means it gets displayed
by 'perl configdata.pm --make-variables' among all

Make CROSS_COMPILE another supported "make variable" in Configure

No more special casing for that one, and this means it gets displayed
by 'perl configdata.pm --make-variables' among all the others.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

show more ...

Have configdata.pm display information on perl

Specifically, the specific perl that was used to run Configure

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://git

Have configdata.pm display information on perl

Specifically, the specific perl that was used to run Configure

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

show more ...

Configure: engage x25519 assembly support.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pu

Configure: engage x25519 assembly support.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5408)

show more ...

Configure: avoid uninit data in configdata.pm

Fixes #5394

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5399)

Configure: move down the treatment of seed sources

Most of all, this is so it doesn't output mysterious text when we're
treating the phony config targets LISH, HASH and TABLE

Re

Configure: move down the treatment of seed sources

Most of all, this is so it doesn't output mysterious text when we're
treating the phony config targets LISH, HASH and TABLE

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5383)

show more ...

Auto-size more of configdata.pm "disabled features"

configdata.pm -d prints out a lot of information, including a table
of what features are disabled, why, and the effect of that disable

Auto-size more of configdata.pm "disabled features"

configdata.pm -d prints out a lot of information, including a table
of what features are disabled, why, and the effect of that disablement
(in terms of preprocessor symbols defined and directories skipped).
The first column is already auto-sized, to easily accomodate future
disableable features with long names. Also auto-size the second column,
to accomodate future reasons for disablement with long names as well.

Failing to take such precautions results in stderr spew from
configdata.pm -d when such long reasons are in use:

Negative repeat count does nothing at ./configdata.pm line 14504.

Such output is pretty distracting from the actual desired output,
so try to avoid it if possible.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5371)

show more ...