A miscellaneous '\' was accidently added to set FIPSKEY=$(FIPSKEY) which was causing some
external CI build loops to not produce test results.
It looks like it was accidently copied from the unix variant which requires the '\'.
Thanks to Wolfgang Beck for tracking down the issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12661)
Change default FIPS HMAC KEY from all-zero's
Use default FIPSKEY if not given on command line.
Make all -macopt in fipsinstall optional
Make all tests, except fipsinstall, use the default -macopt and
-mac_name flags.
Define and use FIPSDIR variable on VMS/MMS.
Also use SRCDIR/BLDDIR in SRCTOP/BLDTOP.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12235)
The fips.so and legacy.so providers were not being installed because of
a typo in the makefile templates.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11615)
The Windows command line has its limits, and we're hitting it hard.
We therefore generate one 'del' command for each explicit file for the
'clean' target.
Fixes#11163
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11171)
util/progs.pl depends on the build tree (on configdata.pm,
specifically), so it needs to be run from the build tree. But why
stop there? We might as well generate apps/progs.c and apps/progs.h
when building.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11185)
Since we've now switched to use util/wrap.pl to wrap uninstalled
programs everywhere, there's no need to set the environment variables
OPENSSL_ENGINES and OPENSSL_MODULES globally for the tests.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11110)
Remove unused util/process_docs.pl
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10856)
We had all tests run with test/test-runs/ as working directory, and
tests cleaned up after themselves... which is well and good, until
you want to have a look at what went wrong when a complex test fails,
and you have to recreate everything it does manually.
To remedy this, we have OpenSSL::Test create the result directory
dynamically (and cleaning it up first if it's already there) and let
the test recipe have that as working directory.
Test recipes are now encouraged to name their diverse output files
uniquely, and not to clean them up, to allow a developer to have a
look at the files that were produced.
With continuous integration that allows this, the result directories
could also be archived and be left as a build artifact.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11080)
When generating html or manpages from POD files, we used $< or $? to
get the file name to process. It turns out, though, that some make
implementations only define $< with implicit rules, so its expansion
remains empty in explicit rules. $? is a fine replacement, but only
as long as we have one dependency, so it may cause problems in the
future.
The final solution seems to be to use explicit POD file names
instead. That leaves no doubts.
Fixes#10817
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/10849)
The nmake rule contains actually two errors:
1. The $< target[1] does not work for regular rules and is
expanded to an empty string after issuing the warning
NMAKE : warning U4006: special macro undefined : '$<"'
Solution: replace $< by $?
2. The substitution regex is not quoted correctly, which leads
to the following error message by cmd.exe:
'href' is not recognized as an internal or external command,
operable program or batch file.
Solution: Quoting arguments for cmd.exe is really a nightmare,
but with the help of the excellent description [2] I was able to
properly quote the regex. Things were complicated by the fact that
a lot of levels of unquoting needed to be considered:
* perl (windows-makefile.tmpl -> makefile)
* make (reading the makefile)
* cmd.exe (executed by make)
* perl (scanning command line using CommandLineToArgvW())
The fix works, but the regex has become unmaintainable. It would actually
be better to wrap the entire command (including the regex) into a little
perl script which can be called by make directly.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/filename-macros
[2] https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/Fixes#10648Fixes#10749
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10719)
For some reason, we didn't use some of the possible target attributes
in the Unix Makefile template, and there was a similar but much
smaller lack of use in the Windows makefile template as well.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10753)
Fixes#8322
The leak-checking (and backtrace option, on some platforms) provided
by crypto-mdebug and crypto-mdebug-backtrace have been mostly neutered;
only the "make malloc fail" capability remains. OpenSSL recommends using
the compiler's leak-detection instead.
The OPENSSL_DEBUG_MEMORY environment variable is no longer used.
CRYPTO_mem_ctrl(), CRYPTO_set_mem_debug(), CRYPTO_mem_leaks(),
CRYPTO_mem_leaks_fp() and CRYPTO_mem_leaks_cb() return a failure code.
CRYPTO_mem_debug_{malloc,realloc,free}() have been removed. All of the
above are now deprecated.
Merge (now really small) mem_dbg.c into mem.c
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10572)
We were not consistently using one or the other, and the perlasm
code assumes dashes, which MSVC tolerates.
Fixes#10075
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10222)
For files GENERATEd from templates (.in files), any perl module (.pm
file) that the file depends on will automatically be used.
This means that these two lines:
GENERATE[foo]=foo.in
DEPEND[foo]=whatever.pm
will emit this command in a Makefile (or corresponding):
foo: foo.in whatever.pm configdata.pm
$(PERL) -I. -Ipathto -Mwhatever -Mconfigdata $(SRCDIR)/util/dofile.pl \\
foo.in > foo
Note that configdata.pm is automatically added, since util/dofile.pl
itself depends on it.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10162)
The build.info grammar's regular expressions were a horrible read.
By assigning certain sub-expressions to variables, we hope to make
it a little more readable.
Also, the handling of build.info attributes is reworked to use a
common function instead of having copies of the same code.
Finally, the attributes are reorganized to specify if they belong with
programs, libraries, modules or scripts. This will enable more
intricate attribute assignment in changes to come.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
- Make the last argument always be the output file.
- Make the first argument always be the flavour, even if there is no
flavour (i.e. it might become the empty string).
- Make the next to last argument to be $(PROCESSOR) if that one has a
value.
- Remaining arguments are C prepropressor arguments.
Perl scripts that should handle this may use the following code:
$output = pop;
$flavour = shift;
if ($ARGV[$#ARGV] eq '386') {
# Do 386 specific things
} else {
# Do whatever else, with the knowledge the @ARGV contains
# C preprocessor arguments
}
Some scripts don't care about anything than $output, and that's ok.
Some scripts do care, but handle it a little differently, and that's
ok too (notably, the x86 scripts call asm_init() with the first and
the last argument after having popped $output).
As long as they handle the argument order right, they are going to
be fine.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9884)
There are various C macro definitions that are passed via the compiler
to enable AES assembler optimisation. We need to make sure that these
defines are also passed during compilation of the FIPS module.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9038)
All invokations of $(PERL) need to be quoted, in case it contains
spaces. That was forgotten in one spot.
Fixes#9060
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9062)
- Allow user-defined RCFLAGS
- Pass RCFLAGS to RC
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8803)
The naming of generated assembler wasn't done quite right. There are
assembler files that are generated from a perl script, and there are
those who are not. Only the former must be renamed to the platform
specific asm extension.
Furthermore, we need to make sure that 'OSSL_provider_init' isn't case
sensitive on VMS, to allow for the least surprise for provider
builders.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8529)
These will be used to point out general OpenSSL modules directory.
ENGINE modules are kept apart for backward compatibility.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8287)
The only thing that makes an ENGINE module special is its entry
points. Other than that, it's a normal dynamically loadable module,
nothing special about it. This change has us stop pretending anything
else.
We retain using ENGINE as a term for installation, because it's
related to a specific installation directory, and we therefore also
mark ENGINE modules specifically as such with an attribute in the
build.info files.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8147)
We have two classes of scripts to be installed, those that are
installed as "normal" programs, and those that are installed as "misc"
scripts. These classes are installed in different locations, so the
build file templates must pay attention.
Because we didn't have the tools to indicate what scripts go where, we
had these scripts hard coded in the build template files, with the
maintenance issues that may cause. Now that we have attributes, those
can be used to classify the installed scripts, and have the build file
templates simply check the attributes to know what's what.
Furthermore, the 'tsget.pl' script exists both as 'tsget.pl' and
'tsget', which is done by installing a symbolic link (or copy). This
link name is now given through an attribute, which results in even
less hard coding in the Unix Makefile template.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7581)
This means that all PROGRAMS_NO_INST, LIBS_NO_INST, ENGINES_NO_INST
and SCRIPTS_NO_INST are changed to be PROGRAM, LIBS, ENGINES and
SCRIPTS with the associated attribute 'noinst'.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7581)
Add platform::Windows, which is a generic Windows module, and
platform::Windows::MSVC, which is a module specifically for MS Visual
C.
This reworks Configurations/windows-makeffile.tmpl to work out product
names in platform::Windows. Something to be noted is that the new
functionality ignores the *_extension config attributes, as they were
never used.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7473)
Since `$config{version}` and `$config{version_num}` were removed
in commit 3a63dbef15, the configure output displays an empty
version number string in parentheses instead of the version number.
This pull request fixes that by adding new config variables
`version` and `full_version`, analogous to `OPENSSL_VERSION_STR`
and `OPENSSL_FULL_VERSION_STR`.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7841)
We're strictly use version numbers of the form MAJOR.MINOR.PATCH.
Letter releases are things of days past.
The most central change is that we now express the version number with
three macros, one for each part of the version number:
OPENSSL_VERSION_MAJOR
OPENSSL_VERSION_MINOR
OPENSSL_VERSION_PATCH
We also provide two additional macros to express pre-release and build
metadata information (also specified in semantic versioning):
OPENSSL_VERSION_PRE_RELEASE
OPENSSL_VERSION_BUILD_METADATA
To get the library's idea of all those values, we introduce the
following functions:
unsigned int OPENSSL_version_major(void);
unsigned int OPENSSL_version_minor(void);
unsigned int OPENSSL_version_patch(void);
const char *OPENSSL_version_pre_release(void);
const char *OPENSSL_version_build_metadata(void);
Additionally, for shared library versioning (which is out of scope in
semantic versioning, but that we still need):
OPENSSL_SHLIB_VERSION
We also provide a macro that contains the release date. This is not
part of the version number, but is extra information that we want to
be able to display:
OPENSSL_RELEASE_DATE
Finally, also provide the following convenience functions:
const char *OPENSSL_version_text(void);
const char *OPENSSL_version_text_full(void);
The following macros and functions are deprecated, and while currently
existing for backward compatibility, they are expected to disappear:
OPENSSL_VERSION_NUMBER
OPENSSL_VERSION_TEXT
OPENSSL_VERSION
OpenSSL_version_num()
OpenSSL_version()
Also, this function is introduced to replace OpenSSL_version() for all
indexes except for OPENSSL_VERSION:
OPENSSL_info()
For configuration, the option 'newversion-only' is added to disable all
the macros and functions that are mentioned as deprecated above.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7724)
We only had the main 'install' target depend on 'all'. This changes
the dependencies so targets like install_dev, install_runtime_libs,
install_engines and install_programs depend on build targets that are
correspond to them more specifically. This increases the parallel
possibilities.
Fixes#7466
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7583)
When trying 'make -j{n} install', you may occasionally run into
trouble because to sub-targets (install_dev and install_runtime) try
to install the same shared libraries. That makes parallel install
difficult.
This is solved by dividing install_runtime into two parts, one for
libraries and one for programs, and have install_dev depend on
install_runtime_libs instead of installing the shared runtime
libraries itself.
Fixes#7466
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7583)
This makes sure that any resulting directory target in the build files
also depend on object files meant for shared libraries.
As a side effect, we move the production of the dirinfo structure from
common.tmpl to Configure, to make it easier to check the result.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7452)
We made the build of foo.obj depend on foo.d, meaning the latter gets
built first. Unfortunately, the way the compiler works, we are forced
to redirect all output to foo.d, meaning that if the source contains
an error, the build fails without showing those errors.
We therefore remove the dependency and force the build of foo.d to
always happen after build of foo.obj.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7469)
When building shared libraries on Windows, we had a clash between
'libcrypto.lib' the static routine library and 'libcrypto.lib' the
import library.
We now change it so the static versions of our libraries get '_static'
appended to their names. These will never get installed, but can
still be used for our internal purposes, such as internal tests.
When building non-shared, the renaming mechanism doesn't come into
play. In that case, the static libraries 'libcrypto.lib' and
'libssl.lib' are installed, just as always.
Fixes#7492
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7496)
We only had targets for the "simple" shared library names (libfoo.so
and not libfoo.so.x.y on Unix, import library libfoo.lib but not
libfoo.dll on Windows). This has created some confusion why it wasn't
possible to rebuild the less "simple" name directly (just as an
example, someone who mistook the import library on Windows for a
static library, removed the DLL and then found it was difficult to
rebuild directly), so we change the target to include all possible
names.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7451)
When looking at configured macro definitions, we must look at both
what comes from the config target AND what comes from user
configuration.
Fixes#7396
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7402)
Move the .num updating functionality to util/mknum.pl.
Rewrite util/mkdef.pl to create .def / .map / .opt files exclusively,
using the separate ordinals reading module.
Adapt the build files.
Adapt the symbol presence test.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7191)
The generation of linker scripts was badly balanced, as all sorts of
platform dependent stuff went into the top build.info, when that part
should really be made as simply and generic as possible.
Therefore, we move a lot of the "magic" to the build files templates,
since they are the place for platform dependent things. What remains
is to parametrize just enough in the build.info file to generate the
linker scripts correctly for each associated library.
"linker script" is a term usually reserved for certain Unix linkers.
However, we only use them to say what symbols should be exported, so
we use the term loosely for all platforms. The internal extension is
'.ld', and is changed by the build file templates as appropriate for
each target platform.
Note that this adds extra meaning to the value of the shared_target
attribute.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7333)
The possibility to do this was killed when we started producing object
file names with encoded intention (and possibly different builds), and
leads to build errors.
With that, 'libobj2shlib' is renamed to 'obj2shlib' to reflect this
design change. The old name is still used if the new one isn't
available, for the sake of backward compatibility.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7198)
