levels. The root of the problem was that make was attempting to run up
to three concurrent asn1_compile commands to produce the three outputs
that it was declared to produce. The failure was caused when the
asn1_compiles were started out of sync and a later one was truncating
the files that another thread was trying to copy. In reality it is
supposed to be run exactly once and all three outputs are produced in
one pass.
Use the same hack as for the parent's Makefile.inc for the compile_et
multi-output rule.
libkafs5 needs a header from libkrb5, it includes this from
${.OBJDIR}/mumble, this used to work fine as long as you happen to have
a krb_err.h in your base system, this doesn't work for bootstrapping or
using a cross-compiler with a different sysroot. This is just a
best-effort bandaid, sufficient parallelism can still break it.
Fix a SRCS override that dropped krb5_err.h.
Discussed with: stas
private shared libraries, instead of hacked-together archives of PIC
objects. This makes it possible to build a static libkrb5 that works.
Reviewed by: stas
Approved by: re (gjb)
that it handles the ERANGE error return case. Without this fix, authentication
of users for certain system setups could fail unexpectedly.
Reported by: Elias Martenson (lokedhs@gmail.com)
Tested by: Elias Martenson (earlier version)
MFC after: 2 weeks
of the version map just exported all the symbols, which caused a
binutils bug being triggered when ld fails to link two objects, one
of which exports a versioned version of the symbol, and another --
unversioned. [1]
- Also add version map for libkafs5.
Submitted by: jchandra@ (based on)
This makes our naming scheme more closely match other systems and the
expectations of much third-party software. MIPS builds which are little-endian
should require and exhibit no changes. Big-endian TARGET_ARCHes must be
changed:
From: To:
mipseb mips
mipsn32eb mipsn32
mips64eb mips64
An entry has been added to UPDATING and some foot-shooting protection (complete
with warnings which should become errors in the near future) to the top-level
base system Makefile.
several new kerberos related libraries and applications to FreeBSD:
o kgetcred(1) allows one to manually get a ticket for a particular service.
o kf(1) securily forwards ticket to another host through an authenticated
and encrypted stream.
o kcc(1) is an umbrella program around klist(1), kswitch(1), kgetcred(1)
and other user kerberos operations. klist and kswitch are just symlinks
to kcc(1) now.
o kswitch(1) allows you to easily switch between kerberos credentials if
you're running KCM.
o hxtool(1) is a certificate management tool to use with PKINIT.
o string2key(1) maps a password into key.
o kdigest(8) is a userland tool to access the KDC's digest interface.
o kimpersonate(8) creates a "fake" ticket for a service.
We also now install manpages for some lirbaries that were not installed
before, libheimntlm and libhx509.
- The new HEIMDAL version no longer supports Kerberos 4. All users are
recommended to switch to Kerberos 5.
- Weak ciphers are now disabled by default. To enable DES support (used
by telnet(8)), use "allow_weak_crypto" option in krb5.conf.
- libtelnet, pam_ksu and pam_krb5 are now compiled with error on warnings
disabled due to the function they use (krb5_get_err_text(3)) being
deprecated. I plan to work on this next.
- Heimdal's KDC now require sqlite to operate. We use the bundled version
and install it as libheimsqlite. If some other FreeBSD components will
require it in the future we can rename it to libbsdsqlite and use for these
components as well.
- This is not a latest Heimdal version, the new one was released while I was
working on the update. I will update it to 1.5.2 soon, as it fixes some
important bugs and security issues.
kerberos libraries were not linked properly (missing dependencies),
which causes 3rd party applications linking to fail when --as-needed
ld flag is used. I also added the --no-undefined ld(1) flag to make
sure that there're no missing dependencies.
MFC after: 3 days
is based on an old implementation from the University of Michigan with lots of
changes and fixes by me and the addition of a Solaris-compatible API.
Sponsored by: Isilon Systems
Reviewed by: alfred
libraries had not had their versions bumped relative to 6.3-REL but
had indeed been changed. We need to bump their version so they can be
properly added to the compat6x port:
libasn1.so.8 libgssapi.so.8 libhdb.so.8 libkadm5clnt.so.8
libkadm5srv.so.8 libkafs5.so.8 libkrb5.so.8 libobjc.so.2
MFC After: 1 day
similar the the Solaris implementation. Repackage the krb5 GSS mechanism
as a plugin library for the new implementation. This also includes a
comprehensive set of manpages for the GSS-API functions with text mostly
taken from the RFC.
Reviewed by: Love Hörnquist Åstrand <lha@it.su.se>, ru (build system), des (openssh parts)
- Dropped support for standalone builds, this was only partially
supported anyway, and required so much magic in makefiles that
made life dangerous (e.g., by using the custom yacc rules).
- Got rid of .OBJDIR in makefiles -- makes building of individual
files possible again.
- Made the .x.c transformations -j safe.
- Reprogrammed LDADD to fix static build of some utilities that
was broken.
- Fixed LDFLAGS and DPADD in the WITH_OPENLDAP case -- positively
affects the contents of .depend files.
- Removed redundant .h's from SRCS, only kept those that are
generated.
- libkrb5/ INCS were bogusly installed again with libgssapi/.
- Made build-tools real tools with their own makefiles in
separate directories. This allows us to properly track
their dependencies, etc.
- Faster build, 21% less of makefile code!
Approved by: nectar
Reviewed by: markm
Silence on: arch
looking ${.OBJDIR} work that has the up-side of actually working
in upgrade and make -jN cases.
This needs to be revisited further, and it is conceivable that
the ${.OBJDIR} stuff can be simplified, but the sheer number of
edge cases and other causes make this Hard(tm). For now, this works.
looking ${.OBJDIR} work that has the up-side of actually working
in upgrade and make -jN cases.
This needs to be revisited further, and it is conceivable that
the ${.OBJDIR} stuff can be simplified, but the sheer number of
edge cases and other causes make this Hard(tm). For now, this works.
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.
Tests with openldap20 where successful whereas openldap21 didn't like
the way hdb-ldap accessed openldap (doesn't like non-bind access).
To activate the support put a USE_OPENLDAP=yes in your make.conf.
The OPENLDAPBASE is also optional and points to /usr/local as default.
Approved by: markm
MFC after: 2 weeks
FreeBSD. This method attempts to centralize all the necessary hacks
or work arounds in one of two places in the tree (src/Makefile.inc1
and src/tools/build). We build a small compatibility library
(libbuild.a) as well as selectively installing necessary include
files. We then include this directory when building host binaries.
This removes all the past release compatibilty hacks from various
places in the tree. We still build on tip of stable and current. I
will work with those that want to support more, although I anticipate
it will just work.
Many thanks to ru@, obrien@ and jhb@ for providing valuable input at
various stage of implementation, as well as for working together to
positively effect a change for the better.
