| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
| |
ok patrick@
|
| |
|
|
|
|
| |
Reported by bentley@; ok bentley@ jca@
|
|
|
|
| |
ok markus@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To integrate the new X.509 verifier, X509_verify_cert() was refactored.
The code building chains in the legacy verifier was split into a
separate function. The first bug is that its return value was treated
as a Boolean although it wasn't. Second, the return alone is not enough
to decide whether to carry on the validation or not.
Slightly rearrange things to restore the behavior of the legacy verifier
prior to this refactoring.
Issue found and test case provided by Anton Borowka and jan.
ok jan jsing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DTLS protocol version numbers are the 1's compliment of human readable TLS
version numbers, which means that newer versions decrease in value and
there is no direct mapping between TLS protocol version numbers and DTLS
protocol version numbers.
Rather than having to deal with this internally, only use TLS versions
internally and map between DTLS and TLS protocol versions when necessary.
Rename functions and variables to use 'tls_version' when they contain a
TLS version (and never a DTLS version).
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
|
|
| |
In x509_verify_ctx_set_xsc_chain(), an ENOMEM case is currently passing
the last certificate and depth (which is no longer actually depth) to
x509_verify_cert_error(). Given we've hit an ENOMEM situation, neither
of these are useful so remove both.
ok tb@
|
|
|
|
|
|
|
|
|
|
| |
write 8 bytes at the time by using a uint64_t pointer. For an
allocation a max of 4 such uint64_t's are written spread over the
allocation. For pages sized and larger, the first page is junked in
such a way.
- Delayed free of a small chunk checks the corresponiding way.
- Pages ending up in the cache are validated upon unmapping or re-use.
In snaps for a while
|
|
|
|
|
|
| |
a monster.
okay sthen@
|
|
|
|
|
|
| |
This also fixes two NULL ptr derefs in later code path.
OK patick@, krw@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the first cut of this diff was made with coccinelle using this spatch:
@rule@
type caddr_t;
expression m, off, len, cp;
@@
-m_copydata(m, off, len, (caddr_t)cp)
+m_copydata(m, off, len, cp)
i had fix it's opinionated idea of formatting by hand though, so
i'm not sure it was worth it.
ok deraadt@ bluhm@
|
|
|
|
|
|
|
| |
i'm not a fan of having to cast to caddr_t when we have modern
inventions like void *s we can take advantage of.
ok claudio@ mvs@ bluhm@
|
|
|
|
|
|
| |
apart from the semantic differences between bridge(4) and veb(4),
the only missing bits in veb(4) is the transparent ipsec interception
support, and spanning tree.
|
|
|
|
| |
OK deraadt
|
| |
|
| |
|
|
|
|
| |
match change to config-dump output.
|
|
|
|
|
| |
From Moritz Schmitt
ok patrick@
|
| |
|
|
|
|
| |
with jmc
|
|
|
|
|
|
|
|
|
| |
replace poll+kevent with kevent only.
lockfile to block starting of 2nd instance.
remove state file, and recognize '# resolvd: ' lines as state
handle DNS proposal withdraws better
Still a work in progress.
tested and looked at by semarie, benno, florian, dlg
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
able to send answers back to the correct client in case two are
connecting at the same time. We also need to pass the pid around to
the resolver process so that it can hand it back to us.
Debugged by deraadt and dlg who noticed that answers would always
arrive on the first control connection.
deraadt@ points out that tracking the pid is not the best choice in
case one process wants to hold open two connections but at least this
brings us in line with all the other privsep daemons with control
tools. If we change this we should change it in all daemons.
|
|
|
|
| |
prodding deraadt
|
|
|
|
|
|
| |
num_untrusted, but unfortunately it's public...
ok jsing tobhe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As should be obvious from the name and the comment in x509_vfy.h
int last_untrusted; /* index of last untrusted cert */
last_untrusted actually counts the number of untrusted certs at the
bottom of the chain.
Unfortunately, an earlier fix introducing x509_verify_set_xsc_chain()
assumed that last_untrusted actually meant the index of the last
untrusted cert in the chain, resulting in an off-by-one, which in turn
led to x509_vfy_check_chain_extension() skipping the check for the
EXFLAG_CRITICAL flag.
A second bug in x509_verify_set_xsc_chain() assumed that it is always
called with a trusted root, which is not necessarily the case anymore.
Address this with a temporary fix which will have to be revisited once
we will allow chains with more than one trusted cert.
Reported with a test case by tobhe.
ok jsing tobhe
|
|
|
|
| |
No functional change but a bit more obvious and shrinks upcoming diff.
|
|
|
|
| |
obtained cur_time to initialize a missing lease->epoch.
|
|
|
|
|
| |
leases. It can't be NULL, and is unconditionally dereferenced a few lines
later anyway.
|
| |
|
|
|
|
|
|
| |
for future attempts at making it more IPv6-like.
ok florian@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend kqueue's filterops interface with new callbacks so that it
becomes easier to use with fine-grained locking. The new interface
delegates the serialization of kn_event access to event sources. Now
kqueue uses filterops callbacks to read or write kn_event. This hides
event sources' locking patterns from kqueue, and allows clean
implementation of atomic read-and-clear for EV_CLEAR, for instance.
There are so many existing filterops instances that converting all of
them in one go is tricky. This patch adds a wrapper mechanism that
kqueue uses when the new callbacks are missing.
The new filterops interface has been influenced by XNU's kqueue.
OK mpi@ semarie@
|
|
|
|
|
|
|
|
| |
ago. Sorry for the delay.
- Make sure we don't deref NULL ptr in skipwhite()
- Only deref vendp if not NULL
- Strings must be at least 2 chars for terminating NUL character
|
|
|
|
| |
sent to tech@ many moons ago. Sorry for the delay.
|
| |
|
|
|
|
| |
no objections mvs@
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
another bridge feature i'm not convinced people actually use.
ok jmatthew@ claudio@
|
| |
|
|
|
|
| |
ok mpi@
|