Commit 1876de606e exposed missing symbols that the port security/krb5
installed that the base system did not install. Part of the solution
was to make libprofile.so private (not libprofile.a) just as the port
does, Red Hat Enterprise Linux does, and as installing MIT KRB5 by hand
does. The actual fix for this was to put symbols and their corresponding
functions into the correct librarires, i.e. libkrb5.so and othes, just
as the port, Red Hat, and manually installed via tarball do.
Unfortunately INTERNALLIB disables the include of bsd.incs.mk and the
install of header files. This is still needed to install profile.h into
/usr/include (just as the port installs it into ${LOCALBASE}/include
and RHEL installs it in /usr/include). This commit fixes this by
installing profile.h into /usr/include from the krb5/include Makfile.
Reported by: fluffy
Tested by: fluffy
Reviewed by: fluffy
Fixes: 1876de606e
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58286
compile_et.sh is run during buildworld and prints a bunch of debug
output. It's intrusive and probably not needed, at least by default, so
let's make the build output a bit cleaner. This is an upstream script,
but it hasn't been modified in 15 years so the local modification is
unlikely to cause any pain.
Also remove a print that shows up in buildworld -s output.
Reviewed by: cy
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55317
Add symbols found in the port but not in base. This requires replacing
a shared libkrb5profile.so with libkrb5profile.a (with -fPIC so it can
be used by shared libraries). We do this by making libkrb5profile
INTERNALLIB.
Base currently has libkrb5profile in a shared library. The patch moves
those functions to the various "consumer" libraries as the port does.
Symbols that should be in the other libraries are in libkrb5profile.so.
This is causing some ports issues.
PR: 291695
Reported by: michaelo, markj, Chris Inacio <[email protected]>
Tested by: michaelo
Fixes: ae07a5805b
Reviewed by: michaelo (previous version)
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D54323
Otherwise etcupdate apparently can fail if its private object directory
under /var/db is in a filesystem mounted noexec. We shouldn't be
building this target at all, but for now, just apply this workaround.
PR: 291043
Reviewed by: ivy, cy, des
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53861
libkadm5clnt_mit installs a symlink from libkadm5clnt.so for backward
compatibility, but it neglected to include the package tags, so the
symlink was missing from pkgbase builds. Add ${DEV_TAG_ARGS} to the
install command.
Reported by: Mark Millard <[email protected]>
MFC after: 1 day
Reviewed by: emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53574
__GLIBC__ is not pre-defined by the toolchain, it comes from features.h,
so we need to make sure that's included by this point.
Fixes: 4dd2b869cd ("krb5: Fix -Wint-conversion when bootstrapping on GNU/Linux")
PRINC_LOOK_AHEAD is the upstream default. Normally ksu determines the
target princiapl by (quoted from the man page)
a. default principal of the source cache
b. target_user@local_realm
c. source_user@local_realm
With PRINC_LOOK_AHEAD emabled, for each candidate in the above
list, select an authorized principal that has the same realm name
and first part of the principal name equal to the prefix of the
candidate. For example if candidate a) is [email protected] and
jqpublic/[email protected] is authorized to access the target account
then the default principal is set to jqpublic/[email protected].
Case 2: source user is root.
If the target user is non-root then the default principal name
is target_user@local_realm. Else, if the source cache exists
the default principal name is set to the default principal of
the source cache. If the source cache does not exist, default
principal name is set to root\@local_realm.
This commit restores the same behaviour as Heimdal ksu.
Reported by: Dan Mahoney <[email protected]>
Requested by: Dan Mahoney <[email protected]>
MFC after: 3 days
MFC to: 15/stable
Differential revision: https://reviews.freebsd.org/D52478
For some packages (OpenSSL, Kerberos) we want to ship runtime libraries
in a separate package, e.g. openssl and openssl-lib. Currently this is
done using PACKAGE=openssl-lib, but that creates packages with strange
names like openssl-lib-lib32.
Instead, add a new LIB_PACKAGE option to bsd.lib.mk that causes runtime
libraries to be placed in a new -lib subpackage. This significantly
improves the set of packages we create; for example, OpenSSL goes from:
FreeBSD-openssl
FreeBSD-openssl-dbg
FreeBSD-openssl-lib
FreeBSD-openssl-lib-dbg
FreeBSD-openssl-lib-dbg-lib32
FreeBSD-openssl-lib-dev
FreeBSD-openssl-lib-dev-lib32
FreeBSD-openssl-lib-lib32
FreeBSD-openssl-lib-man
FreeBSD-openssl-man
to:
FreeBSD-openssl
FreeBSD-openssl-dbg
FreeBSD-openssl-dbg-lib32
FreeBSD-openssl-dev
FreeBSD-openssl-dev-lib32
FreeBSD-openssl-lib
FreeBSD-openssl-lib32
FreeBSD-openssl-man
While here, move /usr/bin/krb5-config and /usr/bin/compile_et into
the kerberos-dev package.
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D51925
We now build compile_et from krb5/util/compile_et. The compile_et make
target runs compile_et.sh through a preprocessor that does some
substitution on the script, in particular it defines the directory where
compile_et can find et_h.awk and et_c.awk.
We build compile_et as a bootstrap tool since it's used to build krb5.
It also gets installed by installworld, presumably because we did that
with Heimdal Kerberos too and there's some chance that third-party
projects are using it.
There are two problems, both fixed by this patch:
First, we don't actually install those awk scripts anywhere, so
/usr/sbin/compile_et isn't usable on an installed system. Let's simply
install them to /usr/share/et, which is where upstream puts them.
Second, compile_et is a bootstrap tool and gets installed into WORLDTMP
during the bootstrap phase of the build. At that point we preprocess it
to set the directory where it can find those awk scripts. That
directory is currently set with `KRB5_ETDIR?= ${DESTDIR}/usr/share/et`,
but DESTDIR points into the object directory, so this value is bogus.
Since all build-time invocations of compile_et explicitly specify the
script directory with the -d option, let's just update the path to point
to the installed script directory. In particular, avoid fixing DESTDIR
in the script, since we don't do that generally.
PR: 288929
Reviewed by: ivy, cy
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52004
For various reasons, trying to build 32-bit compatibility PCFILES
outside of a directory which is not a library doesn't work. Add a
new krb5/Makefile.pc with the build rule for .pc.in.pc, and use
this to build each pc file along with the library it's associated
with.
This means we automatically get 32-bit pcfiles in /usr/lib32, and
is arguably more correct anyway since if we don't build a library
for some reason, we also won't build its pcfiles.
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D51986
Users of MIT Kerberos expect the MIT pkgconfig files to be installed,
and won't work without them. For example, this breaks anything that
links against libcurl (ftp/curl) when curl is built with base GSSAPI.
Reviewed by: ngie, des, cy
Differential Revision: https://reviews.freebsd.org/D51842
Currently we install /usr/include/gssapi/gssapi.h twice, once in
krb5/include/gssapi and once in krb5/lib/gssapi.
The version in krb5/include/gssapi is wrong: make searches ${.PATH} and
picks crypto/krb5/src/include/gssapi.h to install, but this is the file
which is supposed to be installed in /usr/include/gssapi.h.
The problem was masked by the fact that we install the correct
gssapi/gssapi.h later in krb5/lib/gssapi.
Remove gssapi.h and the unneeded ${.PATH} entry from krb/include/gssapi
and while here, remove the unused GSSAPI_KRB5 include group.
This change does not affect the ultimate result of installworld,
it just avoids installing the same file twice with different content.
PR: 288594
Reviewed by: brooks, des
Differential Revision: https://reviews.freebsd.org/D51840
lib/libgssapi is based on Heimdal. As on Linux systems, the MIT
libgssapi_krb5 replaces it. With both gssapi libraries and header files
installed results in broken buildworld (gssd) and ports that will not
build without modifications to support the MIT gssapi in an alternate
location.
73ed0c7992 removed the MIT GSSAPI headers from /usr/include. Apps using
MIT KRB5 gssapi functions and structures will fail to build without this
patch.
This patch includes a temporary patch to usr.sbin/gssd to allow it
to build with this patch. rmacklem@ has a patch for this and for
kgssapi that uses this patch to resolve kgssapi issues for NFS with
Kerberos.
This patch is an updated version of D51661 to allow it to build following
additional patchs to the tree.
This should have been implmented with 7e35117eb0.
Fixes: 7e35117eb0, 73ed0c7992
Differential Revision: https://reviews.freebsd.org/D51661
Both were installing admin.h, chpass_util_strings.h, and kadm_err.h.
kadm5clnt is ordered first in krb5/lib/Makefile so pick it.
PR: 288594
Pull Request: https://github.com/freebsd/freebsd-src/pull/1801
This trips the gcc build in kadm5/srv/svr_principal.c:
/home/ivy/src/bsd/gcc/crypto/krb5/src/lib/kadm5/srv/svr_principal.c: In function 'apply_keysalt_policy':
/home/ivy/src/bsd/gcc/crypto/krb5/src/lib/kadm5/srv/svr_principal.c:208:14: error: argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [-Werror=alloc-size-larger-than=]
208 | subset = calloc(n_ks_tuple, sizeof(*subset));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://reviews.freebsd.org/D51577
libedit breaks the bootstrap on MacOS and Linux.
Activate libedit only for the regular build not for the bootstrap
tools
While here fix the definition of the dependency chain between
libkrb5ss and libedit (and libtinfow) via src.libnames.mk
Remove a local patch to find the readline compatible header and
find them via proper CFLAGS.
This version of libdb is private to Kerberos and not intended for
external use, so avoid installing manual pages that may conflict
with another version of libdb.
Reviewed by: des, cy
Differential Revision: https://reviews.freebsd.org/D51418
This header is not installed by upstream krb5, and since it's part of
kdb5_util, installing it causes an unwanted krb5-dev package to be
created.
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D51419
Move KDC manpages to kerberos-kdc-man.
Move the generic Kerberos manpages (e.g., kerberos.7) to kerberos-man
instead of kerberos-lib-man. Although they technically describe
behaviour implemented in the libraries, conceptually, they are more
associated with Kerberos in general.
While here, remove some redundant SUFFIXES.
Reviewed by: manu, cy
Differential Revision: https://reviews.freebsd.org/D51515
I am not sure what this file from upstream is supposed to be, but it's
not a manual page. Remove it and add to ObsoleteFiles.
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D51517
I compared the contents of the FreeBSD-kerberos-lib-dev package with
the contents of the security/krb5 port. Based on that, remove all
the headers which are installed by base krb5 but not by the port.
These all appear to be internal headers which are not meant to be
publicly visible.
This removes some headers with unfortunate conflict-prone names like
<internal.h> and <dyn.h>.
Reviewed by: des, cy
Differential Revision: https://reviews.freebsd.org/D51518
Using MIT DSO names breaks the libc ABI, we are forced to use Heimdal
DSO names. This is not optimal but necessary.
Fixes: e447c252d0
Requested by: kib
Cy Schubert