| Age | Commit message (Collapse) | Author |
|---|
|
OK tb@
|
|
RPKI Manifests enable Relying Parties (RPs) to detect replay attacks,
unauthorized in-flight modification, or deletion of signed objects. RPs
can accomplish these security functions by comparing (what is expected
to be) a monotonically increasing counter (the 'manifestNumber') - to
determine what the latest Manifest is; a list of filenames - in order to
establish whether the complete set of files was fetched; and a list of
SHA256 message digests to ascertain whether the content's of said files
are exactly the same as the CA intended them to be.
Over time, two schools of thought arose. One philosophy is that the
highest numbered cryptographically valid Manifest represents the express
intent of the CA, so if manifest-listed files are missing, someone
upstream messed up and gets to enjoy the broken pieces. After all, RFC
9286 section 5.2 puts the onus firmly on the repository operator to
publish in a consistent manner. Here, "consistent" means that newly
issued manifests - in the same RRDP delta - are bundled together with
all new or changed ROAs, and that remote RSYNC repositories are
atomically updated (for example, using symlink pivots).
To overcome various types of inconsistent, transient, or intermediate
states of the remote publication point - previous versions of rpki-client
did construct the full CARepository state using a mix of objects from both
its local validated cache and the RRDP/RSYNC staging directories
(which contain purported new versions of the objects).
However, another take on RFC 9286 section 6.6's "use cached versions of
the objects" is that 'the objects' not only refers to the listed
subordinate products (such as ROAs/Certificates/ASPAs), but also to
Manifests themselves. The philosophy being that lower numbered
cryptographically valid Manifests with a complete & untampered set of
files are to be preferred over a higher numbered cryptographically valid
Manifests accompanied by incomplete sets of files. Consequently -
potentially - producing more stable VRP outputs, at the expense of being
magnanimous towards sloppy CAs and repository operators.
Going forward, rpki-client logs errors when inconsistent publications
are encountered, but also proceeds to use older cryptographically valid
Manifests (from previous successful fetches) in order to construct
the tree.
With and OK tb@, and also thanks to Ties de Kock from RIPE NCC.
|
|
to reply; ok florian@
|
|
If the first header starts with a space but still contains a colon
character, it is added to the body mail effectively appending it to the
Received header due to the folding rules.
Issue reported by Crystal Kolipe
ok millert@, giovanni@
|
|
|
|
ok millert@
|
|
since AF_UNSPEC is zero.
|
|
DSN is implicitly enabled when using `listen on sock' but it's not for
the implicit socket, avoid this incoherence by enabling it on the
implicit socket too.
Report and diff by Tassilo Philipp (tphilipp at potion-studios dot com)
ok millert@
|
|
We should not forward Content-Length if the body is not also forwarded.
|
|
are smaller.
bug report and ok kn@
|
|
This augments the grammar for tables and filter listing so that a
newline is allowed after a comma. i.e. these now works as expected:
table foo {
"one",
"two"
}
listen on socket filter {
"foo",
"bar"
}
based on a diff from tim@
ok millert@, tim@
|
|
Wait until we have a complete line before parsing the Content-Length,
Transfer-Encoding and Host headers. This prevents potential request
smuggling attacks. Filtering already happens after header line
continuation has been performed. Reported by Ben Kallus.
OK claudio@
|
|
point for people looking for packing-list details.
small tweak by tb@ for readability
okay tb@, jca@
|
|
1) reject headers with embedded NULs
2) reject headers with invalid characters in the name
3) reject Transfer-Encoding with values other than "chunked"
4) reject chunk values containing non-hex characters
5) reject Content-Length values of "+0" or "-0"
6) reject requests without a ' ' and headers without a ':'
Reported by Ben Kallus, OK bluhm@
|
|
Avoids a crash when no default domain is set.
from hshoexer
ok deraadt who had the same diff
|
|
|
|
|
|
|
|
|
|
do it
|
|
|
|
|
|
|
|
|
|
|
|
Picked 100 bytes as a minimum, to accommodate future signature schemes
(such as the smaller P-256) and small files like empty CRLs.
With and OK claudio@ tb@
|
|
|
|
When syncing against remote repositories, the modtimes of the
remote directories is irrelevant. In the RRDP protocol the directory
modtimes aren't signalled either. This should save some IOPS.
OK tb@
|
|
|
|
"option option-108 00:00:07:08;" is unwieldy and error prone.
OK denis, kn, deraadt
|
|
|
|
specific value isn't used anymore, and is just used to generate an
argument for snmpd_metrics.
OK tb@
|
|
OK tb@
|
|
OK tb@
|
|
|
|
data left inside sm_data. If there's an incomplete packet left in the
buffer it will be called from snmpe_tryparse, if there's a complete
packet left we can end up with new events from the tcp socket, which the
tcp subsystem isn't prepared to handle.
OK tb@
|
|
OK tb@
|
|
Without this, openssl throws an error when creating a second req for
the same subject which leads to ikectl deleting the old cert without
creating a new one.
Reported by Ryan Kavanagh in openiked-portable here:
https://github.com/openiked/openiked-portable/issues/125
discussed with tb@
ok patrick@
|
|
to varbindlen, since its only use is to print the varbindlist via
appl_pdu_log() and both are further properly initialized in
appl_request_upstream_resolve().
This fixes a cosmetic off by one for getbulk requests.
OK tb@
|
|
APPL_VBSTATE_MUSTFILL state, else snmpd won't like use once we reach
EOMV of our view of the world.
OK tb@
|
|
ok claudio
|
|
RFC 6487 section 5 requires AKI and CRL Number and no other numbers to be
present in a CRL. We only checked for AKI and ignored other extensions.
Pointed out by Haya Schulmann et al
ok claudio
|
|
ok claudio
|
|
diff from Philipp (philipp+openbsd [at] bureaucracy [dot] de), thanks!
ok sthen@
|
|
and vice-versa; ok tb@
|
|
OK claudio@ miod@
|
|
While not verbose the status line is built as we go, so save errors from
signify until after we've finished the status line. This should exit and print
the error immediately, since this happens when fetching the SHA256.sig and
fw_update exits early in that case.
|
|
OpenBSD::PackageInfo::lock_db will send messages to STDERR if we ended up
waiting for a lock, if that happens, it stomped over the "fw_update:" prefix on
the status line so tidy up and print it out again.
|
|
Trap STDERR to post-process it looking for 404 errors to handle them differently.
The fetch method now also returns different error codes for errors that can
continue on. Currently only 404 is special and everything else should cause
fw_update to exit early without trying all the files.
Exit early if the SHA256.sig gets a 404 because that is required to figure out
what valid firmware are.
|
|
Mostly some setup for the future, by separating out the filehandles we use for
the status and errors more specifically, we can trap the things we know about
without hiding surprises.
|
