if /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed exists
install that instead of /usr/lib/systemd/boot/efi/systemd-bootx64.efi
the idea is that SecureBoot tooling can create the efi.signed file
whenever /usr/lib/systemd/boot/efi/systemd-bootx64.efi from the package
is updated.
Previously, mangle_filename would write the null terminator, but
then wouldn't increment the pointer. Thus, the pad4 call that comes
immediately after mangle_filename would trample over the null
terminator that mangle_filename wrote. Since the padding is all
0s, this happened to work for the filenames it was tested for
However, in some cases, this would cause the pointer to be a different
position than predicted. Basically, the predicted size would be one
byte bigger than the actual size (the missing null terminator). Usually,
this disappeared into the alignment padding at the end of the buffer,
but if the buffer was already unexpectedly aligned (b/c it was a byte
shorter than expected), this would cause assertion failures.
Also, the c_namesize field in the cpio header was incorrect. It
didn't include the null terminator, as required by the spec.
The previous approach, to strip "$MACHINE_ID/$KERNEL_VERSION" from the
end, is pretty bad and encourages this for users, which makes them
inflexible to this being modified locally
Without any markup, the sentence could be quite confusing:
g user 55
g user 56
→
"Two or more conflicting lines for user configured"
It also wasn't clear which line is ignored.
Inspired by https://github.com/systemd/systemd/pull/21156.
CodeQL was complaining that the local variable obscurs the global
one. It is indeed a bit confusing when reading this… Let's rename
the variable to avoid confusing the reader.
Confer https://github.com/systemd/systemd/pull/19006#issuecomment-800234022:
On some systems it's the admin's explicit choice not to to have the
machine ID leak into the ESP
On some systems the machine ID is transient, generated at every boot,
and hence should not be written to the ESP
Follow-up for pull request #21170.
I hoped that we would drop libgcrypt fully and drop all references to the
library in meson, but this doesn't seem feasible (because of the use in
sd-journal). But let's remove it here, all the resolved code has been switched
to work either of the two libraries.
Previously the MMapCache* was optionally NULL, which open would
handle by creating a new MMapCache* for the occasion.
This produced some slightly circuitous refcount-handling code in
the function, as well as arguably creating opportunities for
weirdness where an MMapCache* was intended to be supplied but
happened to be NULL, which this magic would then paper over.
In any case, this was basically only being utilized by tests,
apparently just to avoid having to create an MMapCache. So
update the relevant tests to supply an MMapCache and make
journal_file_open() treat a NULL MMapCache* as fatal w/assert.
This gets rid of the manual MMapCache ref/unref goop in
journal_file_{open,close}(), in favor of just letting the
JournalFile.cache_fd MMapFileDescriptor carry the baton.
Preparatory commit; before JournalFile can stop hanging onto its
copy of MMapCache, all these users need to find another way.
Most of the time these callers already have the MMapCache onhand,
so it's no big deal for them to just supply it.
journal_file_rotate() in particular needed to change, and it
seemed wise to not use the mmap_cache_fd_cache() accessor on
f->cache_fd, instead requiring the caller supply the cache to
use. This was done with an eye towards a potential future where
the journal_file_archive() isolates the cache_fd to a private
cache, which the newly rotated-to file wouldn't be allowed to
use. It's no biggie for the existing callers to just provide the
appropriate surviving cache.
Basically the mmap_cache_fd_cache() accessor was added just for
journal-verify.c's (ab)use of the mmap-cache. Which, if the
ugly singleton MMapCache assumption ever goes away, can be
cleaned up to simply use a separate MMapCache for those search
arrays.
Preparatory commit; callers manually ref/unref MMapCaches
alongside MMapFileDescriptor add/frees, when the latter should be
sufficient.
A subsequent commit will drop some of those manual MMapCache
reference hoop-jumping, leaving the lifecycle bound to
MMapFileDescriptors.
Yu Watanabe
Дамјан Георгиевски
Daan De Meyer
Adrian Vovk
Luca Boccassi
Frantisek Sumsal
наб
Zbigniew Jędrzejewski-Szmek
Vito Caputo
James Hilliard