src-test2/lib, branch release/2.0_cvs

Tell stupid users to write the bootcode.

1994-11-22T10:58:58Z

This commit was manufactured to restore the state of the 2.0-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.

This commit was manufactured by cvs2svn to create branch 'RELEASE_2_0'.

1994-11-22T06:28:23Z

This commit was manufactured by cvs2svn to create branch 'BETA_2_0'.

1994-11-21T07:33:22Z

This commit was manufactured by cvs2svn to create branch 'ALPHA_2_0'.

1994-11-08T19:51:51Z

Forget to change = to += in previous commit

1994-11-08T17:33:22Z

Add missing link for shared libtermlib

1994-11-08T17:31:52Z

* ATTENTION * YOU MIGHT BE ABOUT TO BE HOSED * ATTENTION *

1994-11-07T21:07:09Z

This effectively changes the non-DES password algoritm. If you have the "securedist" installed you will have no problems with this. (Though you might want to consider using this password-encryption instead of the DES-based if your system is likely to be hacked) If you are running a -current system without the "securedist" installed: YOU WILL NEED TO CHANGE ALL PASSWORDS !! There is no backwards mode. Suggested procedure is: Update your sources cd /usr/src/lib/libcrypt make clean make all make install passwd root change password for any other users on the system. This algorithm is expected to be much better than the traditional DES- based algorithm. It uses the MD5 algorithm at what it is best at, as opposed to the DES algorithm at something it isn't good at at all. The algorithm is designed such that it should very hard to shortcut the calculations needed to build a dictionary, and to make partial knowledge (Hmm, his password starts with a 'P'...) useless. Of course if somebody breaks the MD5 algorithm this looses too. The salt is 48 bits (8 char @ base64). The encrypted password is 128 bits. And I am positively delighted to say that it takes 34 msec to crypt() a password on a Pentium/60Mhz, so building a dictionary is not really an option for hackers at the moment.

Added "const" to the arguments here and there.

1994-11-07T20:48:35Z

A semicolon was lost.

1994-11-07T19:54:55Z

From: "gj%pcs.dec.com@inet-gw-1.pa.dec.com"

1994-11-07T09:42:24Z

Given the right circumstances, a call to kvm_open can result in a core dump. The diff belows fixes this (note that this change is already in the NetBSD code). Could somebody apply this? Gary J. Submitted by: gj