If it was not requested to use a tpm2 signature file when enrolling, do
not fallback to the default /run/systemd/tpm2-pcr-signature.json as it
likely will be unrelated if it exists.
Fixes https://github.com/systemd/systemd/issues/25435
- Whether we should return an absolute path or not is irrelevant
to whether CHASE_AT_RESOLVE_IN_ROOT is set. We should only return
an absolute path if we are provided one and the directory file
descriptor is AT_FDCWD
- When the directory file descriptor is AT_FDCWD, we should always
resolve symlinks against "/". Currently, if the directory file
descriptor is AT_FDCWD and CHASE_AT_RESOLVE_IN_ROOT is set, we
resolve symlinks against the current working directory which is
almost always not going to be what the caller wants.
- Currently, if we provide an absolute path with a positive directory
file descriptor without CHASE_AT_RESOLVE_IN_ROOT SET, we interpret
the path relative to "/" instead of the given directory file descriptor.
Let's make sure that when we're given a positive directory file
descriptor, we always resolve the given path relative to it.
`github.event.issue.pull_request` is an object, not a boolean.
This is the root cause of why the step that is supposed to remove labels
is always skipped. Having this condition in place is not necessary since
the workflow is run on the `pull_request_target` event.
When displaying log data we deal with two kind of timestamps: the one we
use for display (typically the source timestamp if available), and the
one we use internally (typically the reception timestamp of journald).
The user-facing output modes generally use the display timestamp, the
ones intended for further processing (i.e. json + export outputs) do
not, and directly query the timestamps of the entry, ignoring the
source. This gets a bit confusing, since it's not always clear why we
use which timestamp where. Let's address that by renaming the generic
"ts" parameter/variable to "display_ts" to emphasize that the stored
timestamp are "corrected" timestamps for display only.
No real code change, just some renaming.
Previously, we reported:
nx.example.org: resolve call failed: 'nx.example.org' not found
But the call did succeed, and in fact all communication with the upstream
servers was successful, and we got an authoritative negative answer.
So instead of saying that the call fail, just say that the host doesn't exist:
nx.example.org: Name 'nx.example.org' not found
I wanted to keep the prefix of "<name>: ", to keep the output uniform. But
it'd look a bit strange to say "<name>: <name> not found", so I added "Name "
to make the output more readable. (Another option would be to not display
the error string received from resolved, but that seems risky: even if right
now resolved uses just one message format, it could start doing something else
in the future, so it's better to display the error as received.)
Fixes#26233.
This result is identical after cpp is done, so we don't save anything
by not having the usual macros. And with the usual macros it's easier to
grep and code-crossreferencing works better.
This effectively reverts commit ff86c92e30,
and re-apply 49f3ee7e74.
The change was dropped due to the process name was not correctly logged,
but the issue was fixed by dd15e4cb57.
Let's set the child process name again.
Our logging uses program_invocation_short_name. Without this patch,
logs from forked client may become broken; spuriously truncated or
the short invocation name is not completely shown in the log.
This will warn if fake flexible arrays are re-introduced. I'm not using
-Werror=… because we may still get warnings when compiling against old kernel
headers. We can crank this up to error later.
-fstrict-flex-arrays means that the compiler doesn't have to assume that any
trailing array is a flex array. I.e. unless the array is declared without a
specified size, only indices in the declared range are valid.
-Warray-bounds turns on the warnings about out-of-bounds array accesses.
-Warray-bounds=2 does some more warnings, with higher false positive rate. But
it doesn't seem to yield any false positives in our codebase, so enable it.
clang supports -Warray-bounds, but not -Warray-bounds=2.
gcc supports both.
gcc-13 supports -fstrict-flex-arrays.
See https://people.kernel.org/kees/bounded-flexible-arrays-in-c for a long
discussion of use in the kernel.
I tried to use DECLARE_FLEX_ARRAY like the kernel does, but it does not work
for anonymous structs (they cannot be declared inline), so an open-coded
version is used.
[2/3] Compiling C object systemd-repart.p/src_partition_repart.c.o
../src/partition/repart.c: In function ‘context_open_copy_block_paths’:
../src/partition/repart.c:5194:41: warning: ‘devno’ may be used uninitialized [-Wmaybe-uninitialized]
5194 | source_fd = r = device_open_from_devnum(S_IFBLK, devno, O_RDONLY|O_CLOEXEC|O_NONBLOCK, &opened);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/partition/repart.c:5188:31: note: ‘devno’ was declared here
5188 | dev_t devno;
| ^~~~~
This is with gcc-13.0.1-0.2.fc38.x86_64, -O2. I'm pretty sure the code
is correct. I also tried adding some asserts where errno is used for the return
value, but that didn't help. I think resolve_copy_blocks_auto() is just too long
for gcc to understand.
The kernel was updated to not use fake flex arrays with zero size.
Updating should allow -fstrict-flex-arrays to be used.
Headers pulled from kernel-headers-6.2.0-0.rc6.git0.1.fc38.x86_64.
Note that this is not a straighforward copy: our files have local modifications
(listed in README) that need to be preserved.
(The one case that is left unchanged is '< <(subcommand)'.)
This way, the style with no gap was already dominant. This way, the reader
immediately knows that ' < ' is a comparison operator and ' << ' is a shift.
In a few cases, replace custom EOF replacement by just EOF. There is no point
in using someting like "_EOL" unless "EOF" appears in the text.
