src/lib/libpam/modules/pam_ssh, branch release/6.0.0_cvs

This commit was manufactured by cvs2svn to create tag

2005-11-03T00:35:26+00:00

'RELENG_6_0_0_RELEASE'.

This commit was manufactured to restore the state of the 6.0-RELEASE image.

MFC: don't take unprotected keys into account for authentication.

2005-09-30T14:02:29+00:00

PR:		bin/81231
Approved by:	re (kensmith)

Revert the commits that made libssh an INTERNALLIB; they caused too much

2005-06-07T09:31:28+00:00

trouble, especially on amd64.

Requested by:	ru

Fix libssh dependency.

2005-06-06T19:01:01+00:00

Join the 21st century: Cryptography is no longer an optional component

2004-08-06T07:27:08+00:00

of releases.  The -DNOCRYPT build option still exists for anyone who
really wants to build non-cryptographic binaries, but the "crypto"
release distribution is now part of "base", and anyone installing from a
release will get cryptographic binaries.

Approved by:	re (scottl), markm
Discussed on:	freebsd-current, in late April 2004

Mechanically kill hard sentence breaks.

2004-07-02T23:52:20+00:00

Fix numerous constness and aliasing issues.

2004-02-10T10:13:21+00:00

Deal better with the crypto version of the PAM library that goes

2004-01-18T14:58:07+00:00

on the release media -- only put what is different in the crypto
version compared to the base version.  This reduces PAM entries
in /usr/lib in the "crypto" distribution to:

	libpam.a
	libpam.so@
	libpam.so.2
	pam_krb5.so@
	pam_krb5.so.2
	pam_ksu.so@
	pam_ksu.so.2
	pam_ssh.so@
	pam_ssh.so.2

The libpam.so* is still redundant (it is identical to the "base"
version), but we can't set DISTRIBUTION differently for libpam.a
and libpam.so.

(The removal of libpam.so* from the crypto distribution could be
addressed by the release/scripts/crypto-make.sh script, but then
we'd also need to remove redundant PAM headers, and I'm not sure
this is worth a hassle.)

Ignore ECHILD from waitpid(2) (our child may have been reaped by the

2003-09-19T11:33:03+00:00

calling process's SIGCHLD handler)

PR:		bin/45669

This module is not WARNS-clean, due to brokenness in OpenSSL headers.

2003-03-10T09:19:08+00:00