| Commit message (Collapse) | Author | Files | Lines |
|
The branch explicitly checks that all of these ret_ variables are NULL,
so they will never be used.
Follow-up for 83e9b584dba1352493d8d2337bfe20d923d5163b
CID#1533239
CID#1533240
CID#1533241
|
|
Follow-up for 43ead5e3d611e7d3a2e723f5a3cdbf1f8686cea0
|
|
/sys/power/resume is always populated by the initrd, while
/sys/power/resume_offset might have been populated by
the kernel itself. Therefore, if the user is using an initrd
that doesn't include resume hook, the hibernation would fail,
which is expected. However, it was hard to track down the real
problem, since the previous log message suggested that resume=
is not set through kernel cmdline.
|
|
|
|
add_export_unix_socket() generally logs about errors, but we forgot one
case.
|
|
Prompted by https://github.com/systemd/systemd/pull/30974/commits/61e44e01325eca50e88fc9cd400ee340081e9134
|
|
Fixes a bug introduced by afdf6c3b6040ef43b05428b834f0f302c8ce9a1b.
|
|
|
|
It's a bit sloppy to return -ENOMEM rather than the actual error we
already returned in the first place (even though it's always going to be
ENOMEM)
|
|
|
|
|
|
This is supposed to be a nicer, faster replacement for the often seen
pattern strv_extend_strv(l, STRV_MAKE(…), false)
|
|
It's entirely identical to strv_push_prepend() hence drop the duplicate
definition.
|
|
Let's use memmove() to move the string contents, rather than manual
loops.
Fix the overflow extension.
Prefer reallocarray() over malloc()
|
|
|
|
|
|
--output= is documented to only affect journal output in *-status.
Let's use --json= and -j standard options for list-* instead.
|
|
At the same time, 8b6c039a1ac73da006bfe9d5735515bba12ef3c4 is reverted, i.e.
session state is removed from the output. It was added to workaround #26744,
and doesn't really make too much sense after the issue is properly fixed.
|
|
As per https://github.com/systemd/systemd/pull/30884#discussion_r1448938737
|
|
no-pager-255 was added in #29184, which I reviewed and agreed.
However, as #30887 came up, I reconsidered it a bit, and now
I actually think that this should be removed.
We add new tools that refer to these standard options. During
the process, some options are also promoted to be standard ones.
I think a more sane practice is to generally keep old tools in
the loop, rather than overloading the standard-options with versions.
|
|
possibly retry
The commit e3acb4d24c68291376b11bea5787112978e2775f changed how we format a
TPM2B_PUBLIC object from an openssl PEM RSA key if it used the TPM-defined
"default" RSA exponent, to instead set the TPM2B_PUBLIC RSA exponent to the
special-case value of 0. This broke backwards compatibility with
previously-sealed data. The previous commit fixed our code to no longer use the
"special case" exponent value of 0, while this commit adds a fallback check for
any sealed data that used the exponent value of 0. Now unsealing should work
for sealed data that used either method (either 0 or the actual value).
|
|
For compat with older Python versions, since datetime.UTC is an alias
introduced in Python 3.11.
|
|
|
|
Check the calculated TPM2B_PUBLIC key "name" to verify our PEM->TPM2B_PUBLIC
function remains consistent with previous code. This is important as the
TPM2B_PUBLIC "name" is used in the Authorize policy and so any change to a key
"name" would break unsealing for previously-sealed objects (see bug #30546).
Note that the tpm2_tpm2b_public_from_openssl_pkey() function results in a
TPM2B_PUBLIC with the same "name" as using the tpm2-tools program
tpm2_loadexternal, at least as of tpm2-tools version 5.6.18, with the test keys
from TEST(tpm2b_public_from_openssl_pkey) in src/test/test-tpm2.
|
|
The tpm2 test currently verifies PEM->TPM2B_PUBLIC conversion for an RSA key
with the default exponent (0x10001); this adds verification for an RSA key with
a non-default exponent.
|
|
PEM->TPM2B_PUBLIC conversion
The openssl default value for an RSA key exponent value is 0x10001, and the TPM
specification defines a exponent value of 0 as representing this value. The
systemd code that converted an RSA PEM public key to a TPM2B_PUBLIC object
previously used the exponent value directly, but commit
e3acb4d24c68291376b11bea5787112978e2775f changed the conversion to use the
special case exponent value of 0 for any RSA key with an exponent value of
0x10001.
Because the entire TPM2B_PUBLIC object is used to calculate its "name", this
difference in exponent value (0x10001 vs 0) introduced a change in the key
"name". Since the Authorize policy uses the key "name" directly in its policy
session hash value, this change resulted in new systemd code being unable to
properly unseal any data (e.g. a LUKS volume) that was previously sealed.
This reverts the code to no longer override an RSA exponent value of 0x10001
with the special case value of 0.
Fixes a bug introduced by commit e3acb4d24c68291376b11bea5787112978e2775f.
Fixes: #30546
|
|
|
|
As CAN devices do not support IP address, hence the state never goes to
higher than 'carrier'.
Prompted by https://github.com/linux-can/can-utils/issues/68#issuecomment-1327987724.
|
|
- fix memleak in parser,
- fix missing return in parser on failure,
- drop unnecessary temporary argument in command line argument parser,
- use recently introduced macros and helper functions.
|
|
- introduce link_required_operstate_for_online() helper function,
- use recently introduced macros and helper functions,
- unconditionally serialize the minimum and maximum of required
operational state.
|
|
|
|
- rename 'out' -> 'ret',
- introduce LINK_OPERSTATE_RANGE_INVALID,
- constify LINK_OPERSTATE_RANGE_DEFAULT,
- drop spurious const specifier for allocated string,
- etc,.
|
|
|
|
Currently translated at 32.1% (73 of 227 strings)
Co-authored-by: A S Alam <aalam@users.noreply.translate.fedoraproject.org>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/master/pa/
Translation: systemd/main
|
|
|
|
|
|
|
|
This 3-digit decimal escape style is useful when presenting DNS RR
information in zone-file presentation format.
|
|
|
|
|
|
Now that we can selectively suppress only sensitive fields in JSON
objects we can reenable debug logging for incoming messages, which was
removed in 2e3414660cb0c6a024661638d0b237d88b5a7cbc.
This makes Varlink fully debuggable again: we'll see both incoming and
outgoing messages, only the sensitive fields are suppressed.
See: #30578
|
|
Previously, the flag would completely refuse formatting a JSON object if
any field of it was marked sensitive. With this change we'll simply
replace the subobject with the string "<sensitive data>", and show
everything else.
This is tremendously useful when debugging, since it means that we can
again trace varlink calls through the stack: we can show all the message
metadata and just suppress the actually sensitive parameters.
The ability to debug this matters, and we should not hide more
information that we can get away with, to keep things debuggable and
maintainable.
|
|
Let's export this function, so that we can use it elsewhere. Also, while
at it, let's cache the result in a flag. This is only safe if the result
is positive, since we allow the flag to be enabled at any time down thre
tree somewhere, which we need to look at. (We never allow it to be
turned off however)
|
|
So far the varlink logic honoured the "sensitive" flag of output
messages. Let's add something similar for input messages. Since we don't
really know incoming messages, the flag simply controls whether the
"parmaeters" field of all incoming messages should be marked as
sensitive.
Then, turn this on in the credentials logic and in homed, since both
deal with credentials.
|
|
The kernel uses different logics to find or distinguish IPv4 and IPv6 routes.
Let's follow the same way that the kernel uses.
See comments in the code for more details.
|
|
|
|
Follow-up for cd4dd90b99ac5617431ce4f0ca1e9089197c85fd
|
|
actually queued
No effective functionality is changed in this commit.
Refactoring and preparation for later commits.
|
|
processing it
To prevent the request freed in req->process().
This also makes a request that is not requested by a link detached on failure.
Otherwise, the request may periodically processed and failed forever.
|
|
already do in get_user_creds()
let's onour the PREFER_NSS flag also in get_group_creds() the same
way we honour it in get_user_creds().
Simply to remove surprises.
|