- Allows overriding default from /etc/npf.conf
- Indicate rules file used in output
- Drop check for file presence in script - rely on npf exiting with error
Otherwise in systems without certctl_init=YES, such as systems
installed with sysinst(8) where it's unnecessary because the rehash
has already happened at install time, you'll get spurious warnings.
PR install/57629
XXX pullup-10
This is very limited -- it does not supplant postinstall to rehash
certificates on upgrade; it only runs certctl rehash if
/etc/openssl/certs is an empty directory, as you get in live images
not created with sysinst.
We could also have a more general-purpose way to run postinstall(8)
on first boot of an image, but that has a lot more moving parts to
think about, so let's start with this limited-scope low-risk
approach.
PR install/57629
XXX pullup-10
This way postinstall(8) can refer to the default one when you've done
an upgrade without etcupdate or similar to pull in new config files
from etc.tgz.
Not great -- we should do this systematically for all config files in
/etc, but this one-off hack is less risky for 10.
We no longer block indefinitely -- if nothing else, the hardclock
timer should yield enough samples to unblock /dev/random on all but
the most severely deterministic machines -- so it should be generally
safe for availability to set entropy=wait.
This doesn't guarantee that HWRNG/seed has been provided before you
run ssh-keygen or call getentropy(3) in a user application, but it
does raise the security above netbsd<=9.
PR security/55659
PR lib/56905
XXX pullup-10
Don't test whether a non-blocking read from /dev/random would return
data.
For the sake of availability, /dev/random will unblock based on sources
like timer interrupts, which we can't confidently assert anything about
the actual unpredictability of.
Here, the goal is to highlight systems that have neither obtained
entropy from an HWRNG with a confident entropy assessment, nor been
seeded from a source the operator knows about.
XXX pullup-10
These are not useful unless you also set up /etc/krb5.conf and a
keytab for the host from the Kerberos KDC. But having them enabled
by default means that creating /etc/krb5.conf just to enable use of
Kerberos for _client-side_ single sign-on creates usability issues.
As proposed on tech-security:
https://mail-index.netbsd.org/tech-security/2023/06/16/msg001160.html
The NBUILDJOBS option was deprecated in 2002;
there's no need to keep warning about it,
remove from params / show-params,
and only document as obsolete.
The default is NIST P-256, which:
(a) has plenty of cryptanalytic security,
(b) performs better on essentially all platforms (smaller enough that
even the advantage of the Mersenne prime structure of P-521 can't
compete), and
(c) likely gets more scrutiny on implementations than P-521 since it's
more widespread.
If you want them you can generate them yourself, but in this day and
age (Monday and 2023, specifically) there's no reason to be using DSA
except for compatibility with ancient legacy software.
As there's a functional MKCOMPAT implementation, and
MK32BITLIBS=yes hasn't worked since 2002 (and noone
noticed the latter), remove obsolete MK32BITLIBS code.
Per confirmation from martin@, mrg@, and riastradh@ on ICB.
sparc64 snapshots with MK32BITLIBS=yes has been broken
because of make(1) and sh(1) syntax errors since
my change in revision 1.18 on 2002-12-03, when
snap_md_pre target was deprecated...
Move the rules to snap_md_post and fix the syntax errors.
The cross-build make snapshot snapbecause of the missing
$TOOLDIR/bin/sparc--netbsdelf-gcc due to the invocation
with SPARC32_ENV=MACHINE=sparc MACHINE_ARCH=sparc.
A separate issue to resolve.
(It seems MK32BITLIBS hasn't worked for 20+ years and
noone noticed! Do we need it?)
Turns out there is a regression lurking here: the devcrypto engine
was made dynamic-only (https://github.com/openssl/openssl/pull/7859),
so to maintain that functionality, we need to build dynamic engines.
Will fix the aarch64 build issue and wire things up separately.
- Engines are deprecated in openssl 3.
- We never actually had the .so engines wired up to be built in
openssl 1.1, and judging by the lack of obsolete entries in the set
lists, I don't think we ever had them wired up to be built at all.
- check cmd: run `sshd -t' to check sshd_config file
- reload precmd: run check cmd before reloading so we don't nuke sshd
if there's an error in the sshd_config file
(It is still possible to effectively nuke sshd by changing the
configuration tosomething that won't work on your network, but at
least we avoid making sshd just exit on reload when you make a typo
in a config option.)
XXX pullup-9
XXX pullup-10
mkisofs changes files, then turns around and complains they have been
changed.
This is a self-inflicted wound, so demote the error to a warning.
Reported upstream as <https://codeberg.org/schilytools/schilytools/issues/58>.
Arguably fixes PR toolchain/42166
Request pull-ups to netbsd-{8,9,10}.
XXX What about macppc?
compatdir appears to be for things like /usr/lib that have
/usr/lib/eabi as a subdirectory, so for /usr/lib/openssl it would
mean we have /usr/lib/openssl/eabi as a subdirectory. But that's not
what we have; we have /usr/lib/eabi/openssl.
Let's try using NetBSD.dist.compat.in instead, which appears to be
intended for this purpose, from what I can gather.
remove them as explicit part of all arm64 builds when they're only
(currently) used and consumed by llvm builds.
this fixes gcc builds and i don't think it breaks llvm ones though
i'm still waiting for that test.
abs