| Age | Commit message (Collapse) | Author |
|---|
|
All the EC_POINT_* API has a fast path for the point at infinity. So we're
not gaining more than a few cycles by making this terrible mess even more
terrible than it already is by avoding calls ot it (it's also incorrect as
it is since we don't know that the point is no longer at infinity when it
is unset). Simplify and add a comment explaining what this mess is doing.
ok jsing
|
|
OK tb@
|
|
OK tb@
|
|
to return the ibufs generated by the previous two functions.
Error out if the hdrsz argument in msgbuf_new_reader is 0 or too big.
Also check that the rbuf is allocated in ibuf_read and msgbuf_read.
If not return EINVAL.
Implement the imsg API using these functions and introduce
imsgbuf_set_maxsize() to alter the maximum message size and
imsgbuf_allow_fdpass() to allow fd passing (which is now off by default).
Also cleanup the internals a bit and make imsgbuf_init() return int.
OK tb@
|
|
This does not yet fix the imsgbuf_init() function which can now error.
OK tb@
|
|
msgbuf_write
OK tb@
|
|
OK tb@
|
|
OK tb@
|
|
Remove the getdtablecount code from imsgbuf_read() and instead
move the getdtablecount code into ldapd.
Handle EMSGSIZE (the error returned when there are not enough
free file descriptor slots) inside imsgbuf_read() by retrying
the read to receive the data but without fd.
A caller expecting an fd should check the return value of
imsg_get_fd.
OK tb@
|
|
Handle EAGAIN by a simple return 1 (same for the fd check).
This way the caller will poll again and then retry later.
OK tb@
|
|
of messages ready for transmission. Returns 0 if nothing is pending.
OK tb@
|
|
to imsgbuf_init, imsgbuf_clear, imsgbuf_read, imsgbuf_write and imsgbuf_flush.
This separates the imsgbuf API from the per-imsg API.
OK tb@
|
|
Return 0 on success or when a temporary error happened (EAGAIN, ENOBUFS).
Return -1 on error and set errno otherwise.
Kill the old 0 return for EOF. This is not how write operations work.
OK tb@
|
|
This is just a thin wrapper around msgbuf_write() but it makes the API
more consistent.
OK tb@
|
|
OK tb@
|
|
imsg_free() will close the unclaimed fds at the end.
OK tb@
|
|
ibufs already close forgotten fds on free so now imsg_free behaves the
same way.
OK tb@
|
|
For imsgs we want to be able to use ibufs even for empty messages and stash
the fd into those ibufs. For that adjust the ibuf code to allow that.
This adds an internal IBUF_FD_MARK_ON_STACK define that is now used
for on stack ibufs instead of setting max to 0.
OK tb@
|
|
user and the function is simple enough.
OK tb@
|
|
OK tb@
|
|
The current behavior of "auto", which implies running at full speed when
on AC power, does not fit all the hardware and use cases. For some people
it results in more power consumption, more heat, more noise, etc.
Extend the semantics of hw.perfpolicy and provide two buttons to
specify the desired behavior:
sysctl hw.perfpolicy=<policy while on ac>[,<policy while on battery>]
Keep the default behavior of "high,auto". People can opt for "auto,auto"
or simply "auto" instead.
No objection from deraadt@, input and ok sobrado@ sthen@
|
|
|
|
|
|
Use better variable names (cf. https://jmilne.org/math/tips.html#4) and
avoid the weird style of assigning to r (what does r stand for anyway?)
and short circuiting subsequent tests using if (r || ...). Also, do not
reuse the variables for order and cofactor that were previously used for
the curve coefficients.
ok jsing
|
|
The only caller passes in num = 1 and is itself called in a path that
ensures that the multiplier of the generator is != NULL. Consequently
we don't need to deal with an array of points and an array of scalars
so rename them accordingly.
In addition, the change implies that numblocks and num_scalar are now
always 1, so inline this information and take a first step towards
disentangling this gordian knot.
ok jsing
|
|
This provides a SHA-256 assembly implementation for amd64, which uses
the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This
provides a 3-5x performance gain on some Intel CPUs and many AMD CPUs.
ok tb@
|
|
Now that we have replacement SHA-256 and SHA-512 assembly implementations
for amd64, sha512-x86_64.pl can go the way of the dodo.
|
|
Replace the perlasm generated SHA-512 assembly with a more readable
version and the same C wrapper introduced for SHA-256. As for SHA-256,
on a modern CPU the performance is largely the same.
ok tb@
|
|
This also provides a crypto_cpu_caps_amd64 variable that can be checked
for CRYPTO_CPU_CAPS_AMD64_SHA.
ok tb@
|
|
Missing sizes spotted by guenther@
|
|
|
|
|
|
|
|
(Many examples in this directory are really bad. This is no exception.)
|
|
|
|
As most other objects, EC_KEYs can be as sparsely and invalidly populated
as imagination permits and the competent designers of EC_KEY_copy() chose
to just copy over what's available (yeah, what kind of copy is that?) and
leave in place what happens to be there. In particular, if the dest EC key
was used with a different group and has a private key, but the source key
doesn't, the dest private key remains intact, as invalid, incompatible and
unusable as it may be. Fix this by clearing said private key.
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"A return statement with an expression shall not appear in a function
whose return type is void."
ok deraadt miod
|
|
A certificate must have a subject, so X509_get_subject_name() cannot
return NULL on a correctly parsed certificate, even if the subject is
empty (which is allowed). So if X509_get_subject_name() returns NULL,
error instead of silently ignoring it in tls_check_common_name().
This is currently no issue. Where it matters, the match against the
common name will fail later, so we fail closed anyway.
ok jsing
|
|
Relevant for OpenBSD are security fix #915, other changes #905 #902
#904 #317 #918 #914. Major library bump is necessary as new error
constant has been added to a public header file. CVE-2024-50602
OK matthieu@ tb@ deraadt@
|
|
and purge the superseded information from the algorithm-independent
page EVP_PKEY_new(3).
|
|
stand a chance of using the API correctly.
Admittedly, having so much text below EXAMPLES is somewhat unusual.
While all that information is required to use the function correctly,
strictly speaking, it is not part of the specification of what
EVP_PKEY_new_CMAC_key(3) does, so it woundn't really belong
in the DESCRIPTION.
Now, designing an API function in such a way that using it correctly
requires lots of information about *other* functions and such that
all that additional information does not belong into the manual pages
of those other functions (both because that would cause distractions
in various other manual pages and because it would scatter required
information around lots of different pages) is certainly not stellar
API design. But we can't help that because these APIs were all
originally designed by OpenSSL.
Significant feedback and OK tb@.
|
