Age | Commit message (Collapse) | Author |
|
In our tls13_* files, we use SSL *s for local variables and SSL *ssl
for function arguments. This is odd, but probably the result of finger
memory. We intended to use ssl everywhere. Be that as it may, all local
variables except in two functions ended up being called s, so align the
two outliers with that. As noted by jsing, this is not ideal either as
in tls13_legacy_servername_process() the ssl_ctx is now inconsistent.
Renaming all s to ssl is a substantial amount of unnecessary churn at a
moment that isn't ideal, so we have to live with that.
ok bcook inoguchi jsing
|
|
This is not an issue currently, but avoids future surprises.
Noted by tb@
|
|
ok inoguchi@ tb@
|
|
sleep(3) does not call nanosleep(2) if seconds is zero. This is bad.
As a simplified interface to nanosleep(2), sleep(3) should delegate
all decisions about whether or not to yield the CPU to nanosleep(2).
This patch removes the nanosleep(2) bypass from sleep(3).
This means that this code:
sleep(0);
will block for up to 1 tick, just like the equivalent nanosleep(2) call.
Neither FreeBSD nor NetBSD bypass nanosleep(2) in the zero case, so
this commit brings our sleep(3) closer to theirs in behavior.
As an added bonus, sleep(3) will now *always* appear in a ktrace(1) as
a call to nanosleep(2).
ok millert@
|
|
This trades an array on the stack for a dynamically allocated secret in
tls13_{client,server}_finished_send() but has the benefit of wiping out
an intermediate secret on function exit.
ok jsing
|
|
- setting up asr in single thread mode and then starting threads using asr
would lead to multiple threads sharing the same resolver.
- destruction of a thread that has been using asr would leak data.
Problem originally reported by Alexey Sokolov and Uli Schlachter.
ok kettenis@
|
|
suggested by jsing
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
These are two functions that will help streamlining various functions
in the TLSv1.3 code that do not need to know about the interna of this
struct.
input/ok jsing
|
|
|
|
In tls13_{client,server}_finished_recv() we use verify_data_len, which
makes more sense than hmac_len. Use the same name in
tls13_{client,server}_finished_send(), keeping things consistent between
functions.
ok tb@
|
|
The new verifier builds all chains, starting with the shortest possible
path. It also does not currently return partial chains. Both of these
things conflict with auto chain, where we want to build the longest
possible chain (to include all intermediates, and probably the root
unnecessarily), as well as using an incomplete chain when a trusted chain
is not known.
Depending on software configuration, we can end up building a chain
consisting only of a leaf certificate, rather than a longer chain. This
results in auto chain not including intermediates, which is undesireable.
For now, switch auto chain building to use the legacy verifier.
This should resolve the issues encountered by ajacoutot@ with sendmail.
ok tb@
|
|
Yet another mostly meaningless error value...
Noted by and ok tb@
|
|
When a certificate (namely a root) is specified as both a trusted and
untrusted certificate, the new verifier will find multiple chains - the
first being back to the trusted root certificate and a second via the root
that is untrusted, followed by the trusted root certificate. This situation
can be triggered by a server that (unnecessarily) includes the root
certificate in its certificate list.
While this validates correctly (using the first chain), it means that we
encounter a failure while building the second chain due to the root
certificate already being in the chain. When this occurs we call the verify
callback indicating a bad certificate. Some sensitive software (including
bacula and icinga), treat this single bad chain callback as terminal, even
though we successfully verify the certificate.
Avoid this problem by simply dumping the chain if we encounter a situation
where the certificate is already in the chain and also a trusted root -
we'll have already picked up the trusted root as a shorter path.
Issue with icinga2 initially reported by Theodore Wynnychenko.
Fix tested by sthen@ for both bacula and icinga2.
ok tb@
|
|
fix in libcrypto/asn1/a_time_tm.c r1.16.
Suggested by jsing
|
|
|
|
|
|
order of the struct members for reviewability.
ok jsing
|
|
OK schwarze@, jmc@, deraadt@
|
|
quintuple negation into one with a simple negation.
From miod, ok millert
|
|
comments that they will evaluate their arguments multiple times.
From miod, ok millert
|
|
From miod@, OK tb@
|
|
upcoming update to those, which will see both codebases heading into the
gnu/llvm dumpster.
Feedback from jsg@
ok deraadt@ kettenis@
|
|
* Do not abuse .Bl -tag for lists without bodies, use .Bl -item instead.
* In tagged lists, put bodies into bodies, not into heads.
* Add a few missing macros.
* Drop some useless quoting.
|
|
Follow the previous commit and complete the manual page for consistency;
better readable and tags for free.
OK tb
|
|
httpd(8)'s incorrect tls_close() after closing the underlying socket
led to a leak: tls_close()'s attempt to send out the close_notify won't
work very well over a closed pipe. This resulted in alert_data still
hanging off the TLSv1.3 context's record layer struct. The tls_free()
call should have cleaned this up but failed to do so.
The record layer's phh_data potentially has the same issue, so free it
as well. This diff makes -current httpd(8) run in constant memory over
hundreds of thousands TLS connections with a static site.
ok inoguchi jsing
|
|
gnu/ directory.
|
|
libraries due to dynamic export additions and removals in libc++abi.
Tested by kettenis@, visa@ and myself
ok kettenis@
|
|
|
|
|
|
OK martijn@
|
|
Changing it from ((condition) || function call) to an if() wrapped
in a do/while is easier to read and more stylistically consistent.
The seterr() function no longer needs to return a value.
From miod@, OK tb@
|
|
From miod@, OK tb@
|
|
Also, the temporary array in nonnewline() can be made static const.
From miod@, OK tb@
|
|
before accessing anything in ifa_addr.
ok claudio@
|
|
Manuals like httpd.conf(5) refer to this for valid protocol strings, but
elements inlined into sentences are hard find to spot.
Use a list as already done elsewhere in this manual.
OK jmc on earlier version
Feeback OK tb
|
|
"count" bytes available in an array of char "start" and "end" both point
to.
This is fine, unless "start + count" goes beyond the last element of the
array. In this case, pedantic interpretation of the C standard makes
the comparison of such a pointer against "end" undefined, and optimizers
from hell will happily remove as much code as possible because of this.
An example of this occurs in regcomp.c's bothcases(), which defines
bracket[3], sets "next" to "bracket" and "end" to "bracket + 2". Then it
invokes p_bracket(), which starts with "if (p->next + 5 < p->end)"...
Because bothcases() and p_bracket() are static functions in regcomp.c,
there is a real risk of miscompilation if aggressive inlining happens.
The following diff rewrites the "start + count < end" constructs into
"end - start > count". Assuming "end" and "start" are always pointing in
the array (such as "bracket[3]" above), "end - start" is well-defined
and can be compared without trouble.
As a bonus, MORE2() implies MORE() therefore SEETWO() can be simplified
a bit.
from miod, ok millert
|
|
return value to avoid a redundant strlen() call.
from miod, ok millert
|
|
dealing with it. This code was incomplete anyway.
from miod, ok millert
|
|
from miod, ok millert
|
|
OK martijn@
|
|
OK martijn@
|
|
#398 #404 #405 and other changes #354 #355 #412.
OK deraadt@
|
|
With help/input from jmc@ and kn@.
ok jmc@
|
|
an OOR2 operator. Also includes a regress test for the issue.
From FreeBSD via miod@
|
|
Add a stub for pthread_mutex_destroy() for installers.
ok tb@
|