This happens when doing `build.sh install=/'. The message is less
confusing and it makes postinstall's job simpler for detecting when
it's installing to / rather than somewhere else.
It has come to my attention that sysinst does not, in fact, run
postinstall(8) post-install -- only post-upgrade.
Perhaps we should change this so that postinstall serves the purpose
it says on the box -- make postinstall mandatory for new
installations.
XXX pullup-10
Otherwise, the default kuserok logic to look at ~targetuser/.k5login
would be blocked by the security measure to thwart NetBSD-SA2023-005.
(There are other ways, e.g. setting SYSTEM-K5LOGIN in /etc/krb5.conf
so the file is /etc/k5login.d/user instead of ~user/.k5login, but
that's not the default configuration and there are plenty of
deployments that rely on ~user/.k5login today.)
I reviewed libkrb5 for homedir access checks. There are three:
1. krb5_config_parse_file_multi, called only by:
- verify_krb5_conf -- not relevant
- krb5_config_parse_file -- not used here as far as I can tell,
only by libhdb ldap logic and test code in heimdal
- krb5_set_config_files -- used here only via krb5_init_context,
which is done at this point
2. plugin_get_hosts in krbhst.c, used to look up hosts for KDC I/O,
which shouldn't be happening at this point, so this is almost
certainly unreachable; also it only appears to control whether
some old plugin API can be used, long after we have read the krb5
config controlling which plugins are available, so this is
probably harmless
3. krb5_kuserok, which is the one we want to allow
Note: This will have to be updated again in the next Heimdal update,
which eliminates the global homedir access flag in favour of making
the default per-context homedir access flag conditional on !issuid.
XXX pullup-10
XXX pullup-9
XXX pullup-8
This way, update builds track shlib major bumps correctly.
For example, suppose you had built Heimdal's libkrb5.so.27 and
libgssapi.so.11 linked against it, and then you updated past the recent
shlib major bump raising them to libkrb5.so.28 and libgssapi.so.12.
Without this change, the build will make the following sequence of
targets (interleaved with some others):
1. make dependall in libkrb5
2. make dependall in libgssapi
3. make install in libkrb5
4. make install in libgssapi
The existing .WAIT tags in SUBDIR ensure that (1) happens before (2)
and (3) happens before (4). Unfortunately, this sequence is wrong,
because it will produce the following effect:
1. make dependall in libkrb5 builds libkrb5.so.28
2. make dependall in libgssapi builds libgssapi.so.12, linked against
libkrb5.so.27
3. make install in libkrb5 installs libkrb5.so.28
4. make install in libgssapi installs libgssapi.so.12
Why the out-of-date libkrb5.so.27 in step (2)? Because we just pass
-L${DESTDIR}/usr/lib -lkrb5 to the linker (or the equivalent with
--sysroot and implied -L/usr/lib), and ${DESTDIR}/usr/lib still has
only libkrb5.so.27 by the time of step (2), not libkrb5.so.28.
Now any applications that link against libkrb5.so _and_ libgssapi.so
will get libkrb5.so.28 and libgssapi.so.12 -- but transitively, via
libgssapi.so.12, they will also get libkrb5.so.27, which is a recipe
for disaster.
Splicing the Heimdal library subdirectories into lib/Makefile, as
this does, ensures that we run make dependall _and_ make install in
libkrb5 _before_ make dependall in libgssapi, giving the following
correct sequence:
1. make dependall in libkrb5 builds libkrb5.so.28
2. make install in libkrb5 installs libkrb5.so.28
3. make dependall in libgssapi builds libgssapi.so.12, linked against
libkrb5.so.28
4. make install in libgssapi installs libgssapi.so.12
Note that LIBDPLIBS isn't enough here, as implemented. LIBDPLIBS
ensures that the incremental build will remake libgssapi.so. But it
doesn't ensure that the new libkrb5.so.28 is available before then,
so it doesn't prevent this problem.
We use the same mechanism for crypto/external/bsd/openssl/lib
already; this just extends it to other external library collections.
As an alternative, in principle perhaps we could teach LIBDPLIBS to
ensure that libkrb5.so comes out of the libkrb5 objdir, and not out
of ${DESTDIR}/usr/lib. But that requires some work to make happen,
and make it reliable, whereas this approach we've already confirmed
works without other adverse consequences (besides leaving
grody-looking mechanism lying around) for the libcrypto major bump
already. We need to get this pulled up to the branch so all the
other major bumps it required are handled correctly by update builds.
XXX pullup-10
When manually configured /etc/openssl/certs is detected, just
uncomment the `#manual' line in the default certs.conf rather than
writing a new one. That way, you can switch to certctl-managed and
still get the default path by just deleting /etc/openssl/certs and
re-commenting the `manual' line.
And make them bind to the CPU as a side effect, instead of requiring
the caller to have already done so.
This lets us eliminate the assertions so we can use them in ddb even
when things are going haywire and we just want to get diagnostics.
XXX kernel revbump -- struct cpu_info change
Kernel should build now with all pci drm drivers stripped out but
DRM_LEGACY still enabled. (Might not be very useful, but it'll
build. Maybe we should also have DRM_LEGACY_PCI so those drivers can
be modloaded later.)
While here, write it atomically: write to .tmp first, then rename
when done; this way applications never see a partially-written bundle
at /etc/openssl/certs/ca-certificates.crt.
there's a clearly initialised memory region that is claimed as
being maybe uninitialised, and this test-build version of it
triggers it while the normal build doesn't.
on 32-bit platforms, an expression claims the input can exceed 2G,
more than malloc() can take. i'm pretty sure that the maximum is
actually quite a lot less (seems to be max 255*12 plus <100.)
Avoid a kernel hang reported by Brook Milligan in PR port-arm/57598.
Patch suggested by RVP, seems correct to several of us. (If this
introduces a regression with some board, sorry, mea culpa. But in
that case we should still be carrying this, just conditionalized.)
riastradh