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.
The test cases transfer data over TCP by using nc with IPsec just enabled
(no SA/SP is configured) and confirm the commit "Fix diagnostic assertion
failure in ipsec_init_policy" really fixes the issue.
Upi really (really!) don't want to know!
Also, add a comment (in another section) and avoid giving messages
to atf_fail that include newlines - AFT really doesn't like that.
Instead, convert the \n's to ;'s so at least the content is retained.
contain a # character, can get parsed (which amounts to 86 extra checks,
any Australian can tell you why I decided to stop there and not add one
more...)
These tests are cloned from t_cxxruntime and check proper order of destructor
calls. They must be reported in reverse order of constructor completion.
Added tests:
- static_destructor
- static_destructor_pic
- static_destructor_pie
- static_destructor32
This test file replaces src/regress/usr.bin/c++/static_destructor.
This is a copy of t_hello from usr.bin/cc.
Added tests:
- hello
- hello_pic
- hello_pie
- hello32
These tests do not use c++ runtime library functions.
Protect these tests with MKCXX.
use with mprotect(2), but without enabling them immediately.
Extend the mremap(2) interface to allow duplicating mappings, i.e.
create a second range of virtual addresses references the same physical
pages. Duplicated mappings can have different effective protections.
Adjust PAX mprotect logic to disallow effective protections of W&X, but
allow one mapping W and another X protections. This obsoletes using
temporary files for purposes like JIT.
Adjust PAX logic for mmap(2) and mprotect(2) to fail if W&X is requested
and not silently drop the X protection.
Improve test cases to ensure correct operation of the changed
interfaces.
includes source-code line numbers in the messages, so rather than
hard-coding them in the test, just use a reg-ex to match the text.
Fixes PR bin/52207
the corresponding pad device open, or we get EIO from audio accesses
Explained and fix provided by Nathanial Sloss <nat@n.o>
Note: if we are testing and using real audio hardware, the open
of /dev/pad0 is irrelevant (but harmless, so we don't attempt to
check) and what's more it doesn't matter if it succeeds or fails.
If we're testing under qemu (or any other situation where the only
audio "hardware" is pad) then the open will work, and there should be
no more EIO.
If there is no audio hardware of any kind on the system being tested,
the attempt top open /dev/mixer should fail, and the test will be
skipped.
PR kern/52167 signal3/t_ptrace_wait* timeouts on sparc 32-bit
This test is also marked as failure on other platforms:
PR kern/51918 ptrace tracee can prevent tracer to get its signals by masking
Both issues are valid on sparc 32-bit, but the timeout one wins.
christos