Check signature of local SHA256.sig
We do this by improving the consistency of what we download vs the
file we trust for checksums and filenames.
This has the side effect of no longer writing and leaving an
unexpected SHA256 file with -F but does leave an invalid SHA256.sig
after error to be able to do diagnostics, as requested by sthen@.
While here, also tidy global variable setup for clarity.
Initially noticed by Acts1631 <acts1631kjv () proton ! me>
With much help and OK from dgl@
Correct botched size check in dtls1_preprocess_fragment().
Check message length against max, rather than fragment offset and length.
Due to a various questionable code, this allows for a crafted messsage
to be sent that results in a 21MB allocation, which then promptly results
in an error. Providing that the SSL context is cleared or freed, the
allocation then freed, meaning that this has minimal impact. A similar
fix was landed in OpenSSL in 48c054fec35, although this checks against
dtls1_max_handshake_message_len() rather than max.
Thanks to Abdullah Al Ishtiaq for flagging this.
ok kenjiro@ tb@
Work around smtiic(4) misbehavior to fix RTC setting & reboots
For some reason this i2c chip starts to misbehave after a few
hours/days, and when that happens setting the RTC or halting/rebooting
becomes impossible. Waiting a bit after enabling the device appears to
reliably fix this and alleviates the pain of handling remote machines
such as the riscv64.p ports cluster. There is probably a better fix but
I'm not sure which one exactly.
ok kettenis@
Reduce size of DTLS queues for unprocessed records and application data.
DTLS currently buffers records that contain handshake messages and alerts,
which are in the next epoch and cannot yet be processsed. This is done by
saving the entire buffer that is 16KB in size, regardless of the actual
bytes sent on the wire. With a queue limit of 100 it is possible to send a
small number of bytes on the wire and have the server allocate 1.6MB -
reducing the limit to 16 reduces the allocation to 256KB. This queue will
soon be removed entirely.
DTLS also currently buffers record content from application data where the
handshake has not yet finished. This only buffers the actual content
received on the wire and does not suffer from the same problem, however
reduce the queue size to further limit memory consumption.
ok kenjiro@ tb@
Introduce in-kernel 'shmid_ds_kern' structure where `shm_nattch' has the
type of uint64_t. The original 'shmid_ds' used to deliver data to the
userland, so API/ABI is not broken. The delivered `shm_nattch' value is
clamped with SHRT_MAX.
ok deraadt
devel/libuv: use getexecpath(3) to implement uv_exepath()
uv_exepath() is now implemented as a thin wrapper around getexecpath(3),
which does not fully conform to the behavior of uv_exepath() on other
systems. This difference is accounted for in a separate patch adjusting
the failing test cases for OpenBSD.
Related discussion upstream:
https://github.com/libuv/libuv/issues/5269
ok sthen@
Import rtrd(8), an easy-to-use RPKI-To-Router protocol implementation
The rtrd(8) program is intended as a scalable distribution layer to
deliver data produced by rpki-client(8) to clients such as bgpd(8)
in multi-node/multi-vendor IXP and ISP deployments. A single rtrd(8)
instance can concurrently serve many BGP routers and route servers.
Many thanks to Ralph Covelli from Hurricane Electric for creating rtrd!
OK deraadt@ claudio@
devel/rebar3: Fix build and tests with erlang/29
I was hoping for a new release that addresses this problem, but that might
not happen before 8.0.
Since the build failures are only due to deprecation warnings that are
turned fatal by build configuration, disabling that setting is an easy fix.
There is a remaining test failure documented here:
https://github.com/erlang/rebar3/issues/3004
