lib{crypto,ssl}: regenerate Makefiles
Needs ReviewPublic
Actions

Authored by ngie on Mon, Aug 18, 11:28 PM.

Details

Reviewers

Summary

This change regenerates the Makefiles in an automated manner using the
output from gmake and some semi-complex templating logic written in
python using the Jinja2 templating framework.

Sources and headers have been moved to more appropriate areas and the
Makefiles have been partitioned in a way to better represent how the
upstream build functions in terms of the [intermediate] provided
libraries, e.g., libcommon.a, libdefault.a, liblegacy.a, etc.

This corrects the legacy provider by ensuring that legacy algorithms are
no longer loaded as part of the base/default providers, but instead are
only loaded as part of the legacy provider (where they should be). This
helps ensure that algorithms deemed legacy (generally insecure) aren't
enabled in libcrypto, etc, in the default configuration. Loading the
legacy provider (added in 3.0) has required one of the following be met:

The administrator must specify the needed config file entries to load the base and legacy providers (if legacy is needed).
Developers must explicitly load the base and legacy providers.

This change also builds in locale specific crypto providers like aria
(South Korea), sm2 (China), etc. This was done to ensure that the
version of libcrypto/libssl shipped with FreeBSD is universally
applicable to more global users.

Relnotes: yes

Test Plan

I compared and contrasted the outputs from the Makefiles (before and after) in order to confirm that the delta was to be expected versus the upstream provided Makefile/buildinfo files.

legacy provider differences (SRCS): https://reviews.freebsd.org/P669
libcrypto differences (INCS): https://reviews.freebsd.org/P667
libcrypto differences (SRCS): https://reviews.freebsd.org/P667
libssl differences (SRCS): https://reviews.freebsd.org/P666

TODO:

Rebuilding OpenSSL and will confirm that the legacy provider functions as desired [on amd64].
Will do "make tinderbox" after a sanity test of the legacy provider is completed.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 66483
Build 63366: arc lint + arc unit

Event Timeline

ngie created this revision.Mon, Aug 18, 11:28 PM

Herald added a subscriber: imp. · View Herald TranscriptMon, Aug 18, 11:28 PM

ngie requested review of this revision.Mon, Aug 18, 11:28 PM

Harbormaster completed remote builds in B66335: Diff 160575.Mon, Aug 18, 11:28 PM

ngie edited the test plan for this revision. (Show Details)Mon, Aug 18, 11:33 PM

ngie added a reviewer: khorben.

ngie added a subscriber: philip.

ngie edited the test plan for this revision. (Show Details)Mon, Aug 18, 11:35 PM

ngie added subscribers: ARM, MIPS, PowerPC and 2 others.

kevans mentioned this in D51935: build: remove certctl requirement for host OpenSSL libs on macOS.Mon, Aug 18, 11:51 PM

Chase D51663: update the Makefiles again for algorithms change

Harbormaster completed remote builds in B66337: Diff 160580.Tue, Aug 19, 4:16 AM

Update with working content

This compiles on amd64 at least. make tinderbox's in progress.

I'll work on polishing up the directions, templates, etc, for
general consumption.

Herald added subscribers: emaste, bdrewery. · View Herald TranscriptSat, Aug 23, 4:44 AM

Harbormaster completed remote builds in B66477: Diff 160869.Sat, Aug 23, 4:44 AM

ngie edited the test plan for this revision. (Show Details)Sat, Aug 23, 5:30 AM

ngie added inline comments.Sat, Aug 23, 4:29 PM

secure/lib/libcrypto/Makefile
1338–1344	These should never be installed. Not sure why my Makefile generator didn't handle this properly...
1492	For some odd reason this isn't showing up in DT_NEEDED when I compile this library, which is resulting in downstream issues with libssl, etc 🤔 (they claim they need libpthread, even though libcrypto _should_ be getting linked to libpthread).. I'm not sure why yet.

Do not install internal headers

Harbormaster completed remote builds in B66483: Diff 160885.Sat, Aug 23, 4:32 PM

Should we involve secteam@ regarding the extra algorithms enabled?
I am not aware of any security concern there as of today, but I think we had stuck with OpenSSL's own list of default algorithms so far for the base system.

AFAICT this should probably also be reflected in crypto/openssl/include/configuration.h, by removing the defines OPENSSL_NO_ARIA, OPENSSL_NO_SM2, OPENSSL_NO_SM3, and OPENSSL_NO_SM4.