| Age | Commit message (Collapse) | Author |
|---|
|
is pure comedy gold, and now documented as such, sadly this bit of pure
Muppet genius can't really in good consience stay in the tree as is.
Change BIO_dump to always return the number of bytes printed on success
and to stop printing and return -1 on failure if a writing function
fails.
ok tb@, jsing@
|
|
Change 'offset' to mbr_lba_self and 'reloffset'
to mbr_lba_firstembr to make their use more evident.
Adjust a few parameter names to match.
Change 'part[]' to mbr_prt[] to reflect that it is an
array of struct prt.
No functional change.
|
|
|
|
ok krw@, jsg@
|
|
ok hackroom
tested by plenty
|
|
|
|
|
|
and crc32().
No functional change.
|
|
to read.
No functional change.
|
|
to read.
No functional change.
|
|
No functional change.
|
|
|
|
from Jonathan Kollasch in NetBSD
|
|
this also matches arm64 now/again.
|
|
which by implication also affects X509_print(3).
The ASN1_STRING_get0_data(3) manual explitely cautions the reader
that the data is not necessarily NUL-terminated, and the function
X509_alias_set1(3) does not sanitize the data passed into it in
any way either, so we must assume the alias->data field is merely
a byte array and not necessarily a string in the sense of the C
language.
I found this bug while writing manual pages for these functions.
OK tb@
As an aside, note that the function still produces incomplete and
misleading results when the data contains a NUL byte in the middle
and that error handling is consistently absent throughout, even
though the function provides an "int" return value obviously intended
to be 1 for success and 0 for failure, and even though this function
is called by another function that also wants to return 1 for success
and 0 for failure and even does so in many of its code paths, though
not in others. But let's stay focussed. Many things would be nice
to have in the wide wild world, but a buffer overflow must not be
allowed to remain in our backyard.
|
|
|
|
|
|
the saving of the first error case so that the "autochain" craziness from
openssl will work with the new verifier. This should allow the new verification
code to work with a bunch of the autochain using cases in some software.
(and should allow us to stop using the legacy verifier with autochain)
ok tb@
|
|
addition to existing "config address" test that uses an address pool.
|
|
|
|
* compile the edit utility once
* emit a warning during timeout
|
|
From miod@, ok deraadt@
|
|
|
|
ok kettenis@
|
|
|
|
struct.
ok bluhm@
|
|
On the MNT Reform, which uses a i.MX8MQ with 4 GB of memory, this makes
sure that we don't allocate DMA buffers above the 32-bit boundary. As
it turns out the i.MX8MQ's I/O devices are limited to 32-bit addresses.
The i.MX8MP seems to be better in that regard, though at least the USB
controller is still limited. That's a bit harder to fix in a dynamic
fashion, but we'll take care of that as soon as someone shows up with
an i.MX8MP with that much memory.
ok kettenis@
|
|
OK mpi@ tobhe@
|
|
"please commit" schwarze
|
|
|
|
X509_alias_set1(3), X509_alias_get0(3)
|
|
This updates firmware for 3165, 3168, 7265, 8260, 8265, 9260, 9560 devices.
Other devices did not receive firmware updates from Intel.
New firmware images should contain revelant fixes for fragattacks:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html
Running fw_update(1) may be required before rebooting into a new kernel.
sysupgrade(8) will take care of this.
Blocking issues reported during the previous attempt at using these firmware
images have been addressed.
When reporting issues, please enable 'ifconfig iwm0 debug', reproduce the
error once more, and include the full dmesg in your bug report.
|
|
Starting with major version 35 the Linux driver prints the minor version
number in hexadecimal.
|
|
|
|
The SSID should not be inserted into the template itself. The template
just needs an empty SSID information element. Firmware fills in the rest.
Fix the length specification of 2GHz band-specific data in the template.
|
|
This seems to fix a problem where newer 9k firmware versions become
unresponsive after association and eventually raise a fatal error.
|
|
Discrepancies found while investigating an issue related to active scanning.
|
|
Firmware which advertises the BINDING_CDB_SUPPORT capability
needs a remove+add dance when the channel band has changed.
See Linux commit 730a18912bcbde0b94ae7f1b554a9908b3424a22
and Linux commit 91109f42d0ad0c0c282d1fa1257a1548977aa895
|
|
This matches what Linux and FreeBSD do.
According to Linux commit logs using antenna A for single-antenna Tx
on 9k devices is "wrong" (with no further explanation given).
I suspect it only matters if Bluetooth is active, since antenna A has
obviously been working for us. But who knows...
|
|
According to iwlwifi commit messages this fixes an edge case where
9k family devices fail to resume after system suspend.
See Linux commit 8954e1eb2270fa2effffd031b4839253952c76f2
|
|
|
|
Fixes firmware re-loading after an initial attempt to load firmware failed.
|
|
There was no real need to use a separate function for this.
|
|
|
|
|
|
|
|
a botched merge meant i was posting the previously used slot to the
chip to process before posting the current slot.
ok deraadt@
|
|
https://github.com/onetrueawk/awk/issues/121
|
|
and map data read only.
OK deraadt@ mvs@ mpi@
|
|
those options are incompatible with the kernel anymore. Set DYNAMIC_CRC_TABLE
and BUILDFIXED for these bootblocks, to save space on the media
ok tb mlarkin
|
