The pkcs7_new() function currently uses the hash algorithm from the X509
certificate's signature, but the content signature may use a different
hash algorithm. This adds a parameter to allow specifying what hash
algorithm the content signature generation used.
The pkcs7_new() function currently uses the hash algorithm from the X509
certificate's signature, but the content signature may use a different hash
algorithm. This adds a parameter to allow specifying what hash algorithm the
content signature generation used.
It was added in 1a40a3393e for autotools,
sadly with no explanation, and forward-ported to meson in
5c23128dab. Things seems to work fine without
it now so drop it.
Tested with clang-20.1.5-1.fc43.x86_64.
- config.h is not necessary when generating lists, hence drop it.
- linux/audit.h and libaudit.h are included by missing_audit.h,
hence not necessary to include them explicitly.
The header uses __THROW, which is defined in features.h, to make the
header self-consistent.
Note, src/basic/include/sys/mount.h also uses __THROW, and includes
features.h.
This does not change anything, as poll.h is a one-line wrapper of sys/poll.h.
Note that man pages e.g. poll(2) indicate to include poll.h rather than sys/poll.h.
So, let's use poll.h.
_PATH_WTMPX is a kind of internal definition in glibc, and
WTMPX_FILE should be an exposed definition. Both are same,
let's use WTMPX_FILE.
Note, for utmp, we use UTMPX_FILE, rather than _PATH_UTMPX.
Let's use consistent macros.
It provides several important constants, especially _PATH_BSHELL, which
is used in PID1, executor, and run. The header has been included
indirectly through e.g. libmount.h, mntent.h, utmpx.h, and so on.
Let's explicitly include it in forward.h, as libmount.h and friends that
includes paths.h are irrelevant to _PATH_BSHELL, and we may easily fail
to build when code is touched.
The header is not heavy, hence should not hurt anything.
Necessary for crypto_random_bytes(), which is used in the branch that
HAVE_CRYPT_GENSALT_RA is false. Unfortunately, our CIs tested only the
other branch.
These method calls all already have polkit hookup, hence actually allow
them to go through on all levels.
This is mostly playing catchup with a variety of calls added over the
years.
Not sure why the test failed, but maybe the test environment is too
slow? Even this does not fix the failure, by enabling debugging logs,
this hopefully provides more useful information for debugging.
For issue #37685.
This introduce bus_error_is_connection(), and use it where applicable.
Then, this makes connection errors in acquiring invocation ID by
systemd-run handled gracefully, like we already do other places.
Fixes#37675.
Device ID uses device directory name as is, hence may contain '!', but
sd_device_new_from_subsystem_sysname() expects that the input is sysname.
So, we need to replace '!' with '/'.
Follow-up for 1393c5a2a4.
Fixes#37711.
verity-sig partitions are not kernel concepts, hence dm-verity won't
link them for us from the slaves/ subdir in sysfs. Hence let's instead
look up the partition via udev's database.
Hence: when we search for the data+verity+verity-sig partitions then
search for the first two as usual, but search for the latter by looking
up the udev props on the first two, and then following the paths
provided therein.
Fixes: #34835
This extends the dissect_image builtin to actually add device node
references to the device nodes where the associated data is placed, if
we can find it.
This is kept very generic, and independent from the roothash properties
and suchlike, since it makes sense to make it possible to set these
properties also independently of the dissect-image builtin.
The device path is a /dev/disk/by-diskseq/ symlink, so that we have
stable reference that are not subject to dev_t reuses.
And rework partition_designator_is_verity_sig() to be based on
partition_verity_sig_to_data(), so that we don't have to maintain two
lists of verity sig partition types.
While the `port_vlan_id` field was already present in the
`sd_lldp_neighbor`, it wasn't currently parsed from the LLDP packet.
Added support for that as well as a small parsing test.
Closes#28354.
