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.
If it's yes, all local symbols of shared libraries are stripped
(default). If it's no, only temporary local symbols are stripped;
for example, symbols of static functions are kept. Keeping such
symbols is useful on using DTrace for userland libraries and
getting a backtrace from a rump server loading modules (shared
libraries).
Proposed and discussed on tech-kern and tech-toolchain
the support in the rest of the source tree.
X11 sets could use some cleaning up perhaps (just deletion, as
we've never really marked the old X11R6 as obsolete for native
xorg using platforms so far either.)
This variable separates CTF stuffs from MKDTRACE; we can build DTrace
solely without building and using them. This allows us to use DTrace
even if CTF stuffs have problems (actually they have now).
This variable would be merged into MKDTRACE eventually, once CTF stuffs
work correctly again.
MKKYUA defaults to no and will remain as such until the import is complete
and validated.
This knob does not currently have any effects on the build as nothing relies
on it yet. Upcoming imports and changes in this area will all be guarded by
this flag.
will break the system without either MKPAM=no or a customized PAM config.
As suggested by Ian D. Leroux on current-users and in PR 45263, but with
different text.
makes {MK,HAVE_}BINUTILS consistent with {MK,HAVE_}{GCC,GDB}.
Allow MKBFD to defines MKBINUTILS as a backwards compatibility hook.
Update the sets lists and add conditionals for lib{bfd,opcodes}.
0 Minimal output ("quiet")
1 Describe what is occurring
2 Describe what is occurring and echo the actual command
3 Ignore the effect of the "@" prefix in make commands
4 Trace shell commands using the shell's -x flag
The default remains MAKEVERBOSE=2.
- introduce X11FLAVOUR to choose src/x11 vs src/external/mit/xorg
for the X11 to build if MKX11=yes is set. it takes the values
of either Xorg or XFree86.
- default to Xorg on alpha, i386, macppc, shark, sparc and sparc64
- remove MKXORG_WITH_XSRC_XSERVER, unused and never useful
MAKEVERBOSE MKATF MKGCCCMDS MKINET6 MKISCSI MKLDAP MKNVI
MKPCC MKPCCCMDS MKPIE MKPUFFS MKSTATICLIB MKX11 MKXORG
USE_HESIOD USE_INET6 USE_JEMALLOC USE_KERBEROS USE_LDAP
USE_PAM USE_SKEY USE_SSP USE_YP
Part of PR 29233
We really need one place to document this stuff, or at least the
canonical "installed" reference. Currently we have:
src/share/mk/bsd.README
src/doc/BUILDING.mdoc (for src/BUILDING)
src/share/man/man5/mk.conf.5 (for mk.conf(5))
wiz