Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
restore ABI compatibility with previous releases for ieeefp.h on sh3.
add namespace.h protection for all the fenv interfaces.
use MKSOFTFLOAT on sh3 instead of assuming softfloat.
standardize on comparing MKSOFTFLOAT with "no".
remove the arm-specific softfloat fenv code (which also had several bugs).
fix logic errors in the arm hardfloat feraiseexcept() and feupdateenv().
- reenable cxx rt support
- don't grab insn-modes.h, we build it
- rename the c98 and c11 subdir codecvt.cc files while extracting
them with mknative
- grab GGC_H as well, and use it in dependency lists
- remove GCC 4.5 stuff, add most very basic GCC 5 stuff.
- use mknative-gcc.old for GCC 4.8
- copy mknative-gcc to mknative-gcc.old (should have done this when we
switched to using gcc.old.)
this should not affect current builds.
- pass --enable-libstdcxx-threads to enable a bunch of tests and thus
get the right answers
- MKNATIVE_CONFIG_TARGET_LIBS needs to do libgcc before libstdc++-v3,
for the GCC 4.8 case.
with these we now get the right threading options in the headers.
- convert to using ${EXTERNAL_GCC_SUBDIR}
- define base-external-gpl3-gcc* subdir as GCC_SUBDIR
- use <bsd.init.mk> over <bsd.own.mk> for a bunch of places; mostly
because it arranges for ../Makefile.inc to be included earlier, and
don't bother including the latter if the former is already included.
- move all .PATH: settings after <bsd.{own,lib}.mk> so that all
valid variables are set before it is evaluated
- rename mknative-gcc* to match their subdir name.
XXX the relationship between the Makefile.inc/Makefile.gcc_path files
is kind of sketchy, it would be great if this was fixed.
mrg