IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes#21626. (The bug report talks about /run, but the issue is actually with
/tmp.) People use /tmp for various things that fit in memory, e.g. unpacking
packages, and 400k is not much. Let's raise is a bit.
We get warnings for RSA_free(), EC_KEY_free(), EC_KEY_new(), etc. Those
functions are now deprecated and we're supposed to use the new "EVP API" that
is all the rage in openssl 3.0.
With some effort I converted dnssec_rsa_verify_raw() to use the new API. The
code is significantly longer and, if anything, less readable. The EC code is
more complicated and I assume that the EVP API version will be even more
complex. It is possiblet that I'm missing some way to call the new functions in
a better way, but the documentation is abysmal, so it's really hard to figure
out the best way. Of course there are almost no examples, and the ones that are
there are not terribly useful and are also stubs that don't do interesting
things, don't implement error handling, or memory cleanup. I'll submit my
conversion draft as a separate PR. Maybe somebody who knows openssl better
will pick it up and write a proper solution.
For now, let's just use the existing code, but suppress the warnings. The
new version just came out, so it's unlikely that the deprecated functions will
be removed any time soon.
Fixes#21666.
This reverts cd1caf30c0.
I cannot remember why such change was made.
At least, the kernel does not refuse to set IPv4 localhost address with
non-host scope, e.g. global.
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
