| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Lot of work needed to add all the 3.x tests, but that can wait until all
is switched
|
|
by Tom Lane to give slower architectures a chance to complete it.
|
|
These may not be ready immediately.
|
|
Might help track down what's going on when this fails.
|
|
|
|
sufficient under qemu since the latest openssl update.
|
|
|
|
with the openssl update on 2019-06-09, and it is now timing out on
sparc. Increase the timeout by roughly the same factor.
|
|
|
|
on qemu/sparc.
|
|
test case on qemu/sparc since the import of openssl 1.1.0i on 2018-08-18.
|
|
|
|
one ones it adds though :-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
functional change)
|
|
|
|
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.html
https://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.html
https://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.
|
|
This option existed only because RC5 is covered by patents that, twenty
years ago, we had reason to suspect the patent holder, RSA, Inc., might
litigate. The two US patents in question are 5,724,428 and 5,835,600.
According to the USPTO Patent Term Calculator web site at
<https://www.uspto.gov/patent/laws-and-regulations/patent-term-calculator#heading-5>
(retrieved 2017-05-21), patents filed after 1995-06-07 expire twenty
years after the filing date.
number filing date
5,724,428 1995-11-01
5,835,600 1997-04-21
Thus, these patents appear to be expired.
As proposed on tech-crypto and tech-security:
https://mail-index.netbsd.org/tech-crypto/2017/05/05/msg000718.html
https://mail-index.netbsd.org/tech-security/2017/05/05/msg000927.html
|
|
CRYPTO_AES_CBC(=CRYPTO_RIJNDAEL128_CBC).
|
|
Expect at least one more commit until the tree builds again.
|
|
|
|
code. It runs rump.halt which returns an error status (since rump was
never started in the first place), and this causes atf to complain about
the cleanup routine's return status, logging the test as a failure!
|
|
|
|
|
|
XXX cases 3, 6, and 9 are currently disabled because we don't seem
to handle plain-text in other than 8-byte chunks.
|
|
|
|
is created for each test case.)
|
|
Use test cases defined in RFC 1321
|
|
|
|
|
|
|
|
|
|
|
|
|
|
make sure that all helpers actually check the results against the correct
values.
|
|
not (yet) support them.
|
|
|
|
Fixes latest build break.
|
|
|
|
|
|
|