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.)
dated 2009-11-30, but was not added to src/doc/BUILDING.mdoc,
so the changes were lost.
The original log message was:
- - - -
revision 1.90
date: 2009-11-30 16:13:22 +0000; author: uebayasi; state: Exp; lines: +22 -0;
Support "extsrc", externally added programs and libraries. Users can write
their own reach-overs, cross-build, install, and get set files just like base
and X11 / X.org. (These sets are not included as TNF releases.)
- - - -
These were documented in revision 1.97 of src/BUILDING, but were
not documented in src/doc/BUILDING.sh. The original log message
was:
revision 1.97
date: 2012/01/22 03:53:32; author: tsutsui; state: Exp; lines: +39 -0
Add "live-image" and "install-image" target support to build.sh.
"live-image" target builds pre-installed disk images that can be used on
emulators or boot from USB memory sticks to try NetBSD without installation.
Currently amd64, i386, pmax, sparc, sparc64, sun2, sun3, and vax
(which have working emulators and don't require extra tools like preparing
msdosfs or partitioning MD label structures) support this target.
"install-image" target builds an bootable installation disk image that can
be used as an install CD but burned into USB memory sticks etc.
Current only amd64 and i386 (which would support USB boot) have this target.
For more details (and known issue) see following posts on netbsd-bugs@:
http://mail-index.NetBSD.org/netbsd-bugs/2011/08/06/msg023639.htmlhttp://mail-index.NetBSD.org/netbsd-bugs/2011/09/23/msg024207.htmlhttp://mail-index.NetBSD.org/netbsd-bugs/2011/12/07/msg025166.htmlhttp://mail-index.NetBSD.org/netbsd-bugs/2011/12/08/msg025178.html
No particular comments about implementation, and
"go ahead" comments from mrg@, riz@ and christos@.
Closes PR toolchain/45153 and PR misc/45155.
src/doc/BUILDING.mdoc, so those changes were lost when src/BUILDING
was regenerated in revision 1.94.
Now update src/doc/BUILDING.mdoc and regenerate src/BUILDING to
reinstate the lost changes. (I also edited one of the changes, to use
the phrase "space-separated list" for consistency with other parts of
the document.)
The original changes were:
----------------------------
revision 1.93
date: 2011/08/06 19:52:49; author: jnemeth; state: Exp; lines: +5 -0
Add description of MKKMOD, part of PR misc/45216
----------------------------
revision 1.92
date: 2011/01/29 16:56:26; author: jym; state: Exp; lines: +6 -4
Pass down INSTALLSETS variable to installsets target. Use :Q to escape
shell meta-characters, as the variable contains a list of sets, separated
by spaces.
$ ./build.sh -V INSTALLSETS="base etc" install=idir
should now work as expected.
Reviewed by apb@ on tech-toolchain.
----------------------------
Use getmakevar to expand MAKEOBJDIRPREFIX or MAKEOBJDIR, or (if
neither of those variables is set) use a non-recursive "make obj" in
the top level source directory.
* Do not let TOP_objdir default to ${TOP}. It's now set only by the
-M or -O command line options, or after using getmakevar to expand
MAKEOBJDIRPREFIX or MAKEOBJDIR.
* Make try_set_TOOLDIR handle MAKEOBJDIRPERFIX passed from the
environment. It runs too early to use getmakevar, so it will not work
if the value contains embedded '${...}' variable references.
* Use '$TOOLDIR' (with a literal '$') instead of 'nonexistent' in
a message when rebuilding make when TOOLDIR is not yet known.
leot