| Age | Commit message (Collapse) | Author |
|---|
|
Suggested by Erico Nogueira <ericonr@disroot.org>,
help from and ok jmc@, schwarze@
|
|
This changes RETGUARD_SETUP(ffs) to RETGUARD_SETUP(ffs, %r11, %r12)
and RETGUARD_CHECK(ffs) to RETGUARD_CHECK(ffs, %r11, %r12)
to show that r11 and r12 are in use between setup and check, and to
pick registers other than r11 and r12 in some kernel functions.
ok mortimer@ deraadt@
|
|
This happens if name->der_len == 0. Since we already have a length
check, we can malloc and memcpy inside the conditional. This also
makes the code easier to read.
agreement from millert
ok jsing
|
|
|
|
* Avoid lots of short non-standard .Sh sections.
* Describe server and raw descriptors separately.
* Move examples to the EXAMPLES section.
* Mention that "default" is used even when *not* specified.
tweak and OK ratchov@
|
|
* Use .Fn rather than .Dv for macros taking arguments.
* Actually say what SIO_LE_NATIVE means.
* Add closely related APIs to SEE ALSO.
* Add missing HISTORY and AUTHORS sections.
OK ratchov@
|
|
|
|
|
|
Introduce new AUDIO{PLAY,REC}DEVICE environment variables that
override AUDIODEVICE in cases play-only and rec-only mode is
requested. This allows using different devices for playback and
recording in programs requesting twice the default device (one in
play-only mode and one in rec-only mode).
Based on diffs from Peter J Philipp, semarie, and solene
ok solene, sthen
|
|
x509_verify_chain_new() allocates a few members of a certificate chain:
an empty stack of certificates, a list of errors encountered while
validating the chain, and a list of name constraints. The function to
copy a chain would allocate a new chain using x509_verify_chain_new()
and then clobber its members by copies of the old chain. Fix this by
replacing x509_verify_chain_new() with calloc().
Found by review while investigating the report by Hanno Zysik who
found the same leak using valgrind. This is a cleaner version of
my initial fix from jsing.
ok jsing
|
|
The legacy validator would only call x509_vfy_check_policy() once at
the very end after cobbling together a chain. Therefore it didn't
matter that X509_policy_check() always allocates a new tree on top of
the one that might have been passed in. This is in stark contrast to
other, similar APIs in this code base. The new validator calls this
function several times over while building its chains. This adds up
to a sizable leak in the new validator.
Reported with a reproducer by Hanno Zysik on github, who also bisected
this to the commit enabling the new validator.
Narrowed down to x509_vfy_check_policy() by jsing.
We simultaenously came up with a functionally identical fix.
ok jsing
|
|
|
|
a few lines after.
stylistic nit from jsing
|
|
|
|
|
|
|
|
This implements the key material exporter for TLSv1.3, as defined in
RFC8446 section 7.5.
Issue reported by nmathewson on github.
ok inoguchi@ tb@
|
|
ok beck@ tb@
|
|
This was inadvertently removed in r1.19.
Spotted by tb@
ok beck@ tb@
|
|
in order to be compatible with the openssl error craziness in the legacy
verifier case.
This will fix a regress problem noticed by znc
ok tb@
|
|
Adjust variable declaration in disklabel to match.
ok millert@ deraadt@
|
|
-width ".Dv BOB" -> -width "BOB"
although they are not errors, they are misleading and probably should
not get pasted around
|
|
or pseudo terminals (visa);
ok mpi visa
|
|
With the old verifier, the verify callback can always return 1 instructing
the verifier to simply continue regardless of a certificate verification
failure (e.g. the certificate is expired or revoked). This would result
in a chain being built, however the first error encountered would be
persisted, which allows the caller to build the chain, have the
verification process succeed, yet upon inspecting the error code note
that the chain is not valid for some reason.
Mimic this behaviour by keeping track of certificate errors while building
chains - when we finish verification, find the certificate error closest
to the leaf certificate and expose that via the X509_STORE_CTX. There are
various corner cases that we also have to handle, like the fact that we
keep an certificate error until we find the issuer, at which point we have
to clear it.
Issue reported by Ilya Shipitcin due to failing haproxy regression tests.
With much discussion and input from beck@ and tb@!
ok beck@ tb@
|
|
Apparently OpenLDAP relies on this craziness to provide intermediates,
rather than specifying the chain directly like a normal TLS server would.
Issue noted by sthen@ and Bernard Spil, who both also tested this diff.
ok tb@
|
|
This allows us to remove a check and will make future changes simpler. Use
suitable names for tls1_generate_key_block() arguments while here.
ok inoguchi@ tb@
|
|
wincrypt is deprecated and no longer works with newer Windows environments,
such as in Windows Store apps.
|
|
FP_ILOGBNAN which isn't the case for the amd64 and i386 assembly versions.
Drop these in favour of C implementations. Als reimplement ilogbl(3)
by providing separate ld80 and ld128 implementations that replace the
existing implementation which may hit an infinite loop when built for
quad-precision long double.
ok patrick@, gkoehler@
|
|
FP_ILOGBNAN which isn't the case for the amd64 and i386 assembly versions.
Drop these in favour of C implementations. Als reimplement ilogbl(3)
by providing separate ld80 and ld128 implementations that replace the
existing implementation which may hit an infinite loop when built for
quad-precision long double.
ok patrick@, gkoehler@
|
|
ok deraadt@
|
|
|
|
|
|
The TLSv1.3 code that drives a BIO currently checks BIO_should_read()
after BIO_write() and BIO_should_write() after BIO_read(), which was
modelled on SSL_get_error(). However, there are certain cases where
this can confuse the caller - primarily where the same BIO is being
used for both read and write and the caller is manipulating the retry
flags. SSL_get_error() tends avoids this issue by relying on another
layer of state tracking.
Unfortunately haproxy hits this situation - it has its own BIO_METHOD,
the same BIO is used for both read and write and it manipulates the
retry flags - resulting in it stalling.
Issued noted by Thorsten Lockert <tholo@tzecmaun.org>
ok beck@ tb@
|
|
If we fail to find a parent certificate from either the supplied roots or
intermediates and we have a X509_STORE_CTX, call its get_issuer() callback
to see if it can supply a suitable certificate. This makes things like
certificates by directory (aka by_dir) work correctly.
Issue noted by Uwe Werler <uwe@werler.is>
ok beck@ tb@
|
|
|
|
NaN and 0 arguments using FP_ILOGB0 and FP_ILOGBNAN.
|
|
Largely considered attack surface nowadays. The benefit provided by %n
is completely overshadowed by the risk.
New uses of %n don't seem to be entering the C ecosystem, as static
tools flag them. And everyone points fingers at those people....
The list of programs (and libraries) which use %n is therefore finite
and shrinking. Most of the %n use comes out of the GNU ecosystem.
jca@ has convinced gnulib to fix their code (so we need to wait for
software including gnulib to make new releases).
A few libraries have moved ahead of us and become more strict. Some n
longer permit %n (for instance, andriod bionic). Others log the occurance.
Some log and abort if the output location is W|X (MacOS).
Our base tree is clean. The ports tree contains a handful during
build time, and unknown count (more) during runtime.
We would like to abort programs on any occurance of %n. Or we could
be like MacOS, aborting for W|X pages (but would need a system call
which can check that condition, and that introduces addressspace
knowledge we don't want attackers to know, and may be a poor tradeoff).
For now, we can syslog, to increase awareness, and involve more people
in the greater community to remove %n uses.
[If %n is at the end, use the *printf return value. If it occurs in
the middle, split the printf calls into multiples]
Hopefully one day, we can just abort() when %n happens. Help us get
there?
ok jca, plus naddy for ports team
|
|
be more clear what to use when a normal unsigned is desired.
This is in conformance with RFC 2578/SMIv2.
Ride yesterday's bump
OK tb@
|
|
|
|
overlook this. This change prevens indices larger then INT32_MAX, but this
shouldn't happen in the current code (relayd) anyway. In all other cases
the bytes would've been passed on to SNMP anyway, so there's no effective
difference there.
Probably no ABI-change, but we can ride yesterday's bump anyway.
OK tb@
|
|
Add retguard to some, but not all, asm functions in libc. Edit SYS.h
in libc to remove the PREFIX macros and add SYSENTRY (more like
aarch64 and powerpc64), so we can insert RETGUARD_SETUP after
SYSENTRY. Some .S files in this commit don't get retguard, but do
stop using the old prefix macros.
Tested by deraadt@, who put this diff in a macppc snap.
|
|
OK tb@ and kn@
|
|
|
|
|
|
ok martijn
|
|
ok martijn
|
|
Requested by and OK deraadt@
|
|
uninitialized and clang doesn't trip over this.
Pointed out by and OK stsp@
|
|
Suggested by and discussed with beck
|
|
context. This is what is returned in SSL_get_verify_result().
Spotted and initial diff from jeremy; discussed with jsing
ok beck
|
