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
help some ports that depend on libradius that recently gained
the dependency on libssl. This is also how the stock OpenSSL
build would link libssl.so on FreeBSD.
Prompted by: kris
OK'ed by: markm, nectar
because otherwise it will remain having a dependency upon libssl. This
breaks the non-crypto build that happens for release.3
While here, order the list of programs and libraries.
Speculating review feedback from: ru
a variant of the C code but with some scattered asm and things laid out
more optimally for the platform. This means that we need to the asm
directory to the search path for the amd64 case so that make can find
the source.
environment. This stops some ports keeling over on an OpenSSL assert.
(The patch is not exactly the one from the PR, but has been refined
based on advice from freebsd-threads.)
PR: 51205
Submitted by: Jim Westfall <jwestfall@surrealistic.net>
MFC after: 1 month
- Removed libopie and libmd; libopie used to serve auth-skey.c
which is compiled now only to ease maintenance, as well as
a few other auth-*.c sources.
Reviewed by: des
"kerberize" and "dekerberize" in kerberos5/Makefile. These can
be used to recompile bits with optional crypto support with and
without crypto, respectively.
Reviewed by: markm
and rebuilt some bits with crypto but without Kerberos support
(most notably SSH) during "make release", to put them into the
"crypto" distribution.
Now that we don't ship the separate "krb5" distribution anymore
(it's now part of the "crypto" distribuion), don't waste time
recompiling SSH bits without crypto and without Kerberos support
in an attempt to put them in the "base" distribution -- it just
doesn't work as SSH always uses crypto code.
We avoid this by not rebuilding KPROGS from kerberos5/Makefile in
release/Makefile and adding "libpam" to SPROGS in secure/Makefile
to ensure it's still rebuilt without crypto support for the "base"
distribution. (Disabling crypto (NOCRYPT) also disables building
of Kerberos-related PAM modules, and it's OK to depend on this.)
This should be a no-op change saving some "make release" time.
it. While not strictly required, it unbreaks the cross-build world that
is resulting from moving the libraries around.
I have a more permanent solution to this problem in the works, but I
asked des for permission to commit this to get the ball rolling. This
also makes the ssh build more along the lines of what the openssh-portable
and OpenBSD openssh Makefile glue does.
Reviewed by: des
binaries in /bin and /sbin installed in /lib. Only the versioned files
reside in /lib, the .so symlink continues to live /usr/lib so the
toolchain doesn't need to be modified.
Previously, there were two copies of telnet; a non-crypto version
that lived in the usual places, and a crypto version that lived in
crypto/telnet/. The latter was built in a broken manner somewhat akin
to other "contribified" sources. This meant that there were 4 telnets
competing with each other at build time - KerberosIV, Kerberos5,
plain-old-secure and base. KerberosIV is no longer in the running, but
the other three took it in turns to jump all over each other during a
"make buildworld".
As the crypto issue has been clarified, and crypto _calls_ are not
a problem, crypto/telnet has been repo-copied to contrib/telnet,
and with this commit, all telnets are now "contribified". The contrib
path was chosen to not destroy history in the repository, and differs
from other contrib/ entries in that it may be worked on as "normal"
BSD code. There is no dangerous crypto in these sources, only a
very weak system less strong than enigma(1).
Kerberos5 telnet and Secure telnet are now selected by using the usual
macros in /etc/make.conf, and the build process is unsurprising and
less treacherous.
libdes, and functionally close enough so that we created symlinks
(libdes -> libcrypto) to help older applications. With the import of
OpenSSL 0.9.7, this is no longer true and we no longer install these
symlinks. However, systems that are upgraded may have these symlinks,
which could cause non-obvious breakage at build-time. Therefore, blow
any old symlinks away in the `afterinstall' target.
When libdes was replaced with OpenSSL's libcrypto, there were a few
interfaces that the former implemented but the latter did not. Because
some software in the base system still depended upon these interfaces,
we simply included them in our libcrypto (rnd_keys.c).
Now, finally get around to removing the dependencies on these
interfaces. There were basically two cases:
des_new_random_key -- This is just a wrapper for des_random_key, and
these calls were replaced.
des_init_random_number_generator et. al. -- A few functions were used
by the application to seed libdes's PRNG. These are not necessary
when using libcrypto, as OpenSSL internally seeds the PRNG from
/dev/random. These calls were simply removed.
Again, some of the Kerberos 4 files have been taken off the vendor
branch. I do not expect there to be future imports of KTH Kerberos 4.
can only be built with MIT Kerberos.
If we didn't define this here, then SSL-using applications would have
to define OPENSSL_NO_KRB5 themselves in order to build.
