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.
The default is to execute the script (iscsid_volumes=YES), so if you have
any volumes defined, you should also start iscsid (iscsid=YES) to avoid
error messages.
riastradh