In this mode, a .meta file is created for each target, capturing
the expanded commands used, any command output, and if filemon(9)
is available, a record of system calls which are of interest.
Not enabled unless USE_META=yes is set when building make.
Also, if FILEMON_H exists, meta.c will be compiled to use filemon(9).
static executables (such as newer versions of /sbin/ldconfig)
require this to work properly. since static executables
also don't have a PT_PHDR entry, use the same heuristic as
linux does to provide a value for AT_PHDR in this case.
Ext2fs doesn't have enough free space (it has only 1KB)
to store this primary loader, but we can put it into
an independent small 'boot' partition as NetBSD/hp300 does
if it's really necessary.
It could be a fun project to add smaller pre-primary loader
that loads ~8KB primary loader for ext2fs, but probably it's unlikely
because there is a functional wheel named GRUB for ext2fs.
with 128 byte and 256 byte inode sizes on QEMU.
Note for netbsd-5, this also requires HEAP_START=0x30000
as applied in rev 1.37, and this might also get another limit
on cdboot as described in PR install/42202.
if EBADF is returned due to a read from a write-only stream, also
set ferror()
found by a selftest of Python-2.6.6, thanks to obache for pointing
out the details
while the loop body is executed -- at least in the EVFILT_PROC / exit
case a race condition exists which can cause this
fixes a panic triggered eg by tests/kernel/kqueue/proc1
-wrong initialization reported in a followup to PR bin/43336
(looks harmless because it applies to zero-initialized memory, so
LIST_INIT() is a no-op)
-wrong loop count in reply misses a hash bucket (PR kern/43827)
(this was introduced by a post-netbsd-5 change, so it isn't related
to the PR above)
by Oliver Gould in
http://www.olix0r.net/PubKeyAccessAuthScheme.txt
This implementation includes an example client and server program, but
is not (yet) hooked into the build.
To quote from Oliver's RFC:
HTTP services are a core Internet technology, yet the Digest
authentication scheme provided by RFC 2617 only describes
authentication by way of shared-secrets (i.e. passwords).
This model has operational drawbacks, as authenticating
services are required to have access to a user's secret (or a
hash thereof), or retrograde technologies, such as cookies,
are employed.
Similarly to SSH's "publickey" authentication method [RFC
4252], the PubKey Access Authentication scheme allows an HTTP
server to authenticate clients using public key credentials.
Like the Digest Access Authentication Scheme [RFC 2617], the
PubKey.v1 scheme is based on a simple challenge-response
paradigm. The PubKey scheme responds to unauthorized clients
with a challenge value; and a valid response contains a
cryptographic signature of client's id, the authentication
realm, and the server's challenge.
The client's secret never leaves the client. The server
verifies the client's signed authorization request with the
client's published public keys.
libpaa(3) uses libnetpgp(3) for its digital signatures, SHA1Init(3)
for digests, and base64 encoding for transmission of data.