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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's add configurable timeout how long to wait for FIDO2/PKCS#11
devices to show up. Once the timeout is hit, let's automatically revert
to querying via passphrase.
Fixes: #19739
Before we'd already ask for a PIN just because we know we'll need it
when the token is plugged in. We'd only the try to talk to the device
and notice it actually isn't plugged in. This is quite confusing, as
querying for the PIN suggests we already had a device we are talking to.
Let's hence check if there's actually device before we ask the PIN
question. And if there is none, let's immediately inform the caller, so
that they watch udev and retry once a device has shown up.
udev: use netlink more aggressively
I'm pasting the comment from https://github.com/systemd/systemd/pull/20744#issuecomment-934485287
which is quite informative. The code wasn't changed significantly since then:
atenart commented 6 days ago:
> I ran tests without (93caec7) and with this PR (06735f2) on Fedora, having a few udev rules
> using attributes eligible to be cached and creating 50 veth on 4 CPUs. Although the time spent
> running the test is variable between runs, I generally saw an improvement when using this PR, e.g:
>
> 249-910-g93caec7:
> real 0m3.691s
> user 0m0.022s
> sys 0m1.338s
>
> 249-920-g06735f2:
> real 0m2.950s
> user 0m0.005s
> sys 0m0.399s
>
> On a different system than the one used above, I even saw a 40% improvement; results depend
> on many parameters (distro, udev rules, concurrent daemons accessing sysfs, etc.).
>
> Because it's quite hard to measure the improvement here (as the kernel behave differently between
> the two test cases), I also ran tests using a modified kernel not hitting the trylock logic. There was
> an improvement with this PR as well. (Take this with a grain of salt though, as the kernel was
> modified not using patches approved upstream).
<limits.h> calls this ULLONG_MAX. It's not clear to me where ULONGLONG_MAX
can be found. This seems to be just a mistake.
Fixes: c7ed718720 ('macro: handle overflow in ALIGN_TO() somewhat reasonably')
When they work they finish quickly in under two minutes on slow machines, when
soft lock ups happen in the nested virt machine each test can run for like 5
hours clogging up CI infrastructure. It's best to fail quicker than that when
qemu or kernel are broken.
People should use homectl to enroll tokens into home directories, hence
point them there. Otherwise the auth data for the account and for the
LUKS volume will end up being different.
Let's use the new crypt_token_max() API in systemd-homework too, to cut
iteration of tokens short.
We already use it in cryptenroll/cryptsetup, so let's use it here too.
Using OpenSSL brings in an additional dependency for all users of
libsystemd.so even though it's just one API that makes use of it.
The khash implementation is awkward as it requires context switches and
computation inside the kernel, thus leaving the process.
Remove both from libsystemd.so, and use exclusively the internal hmac fallback.
While this is not optimized, the sd-id128 API is not used in
performance-critical contexts where hardware acceleration would make a
noticeable difference.
Based on the FIPS 198 specification. Not optimized and probably
completely unsafe, to be used only for non-strong-cryptographic
purposes when OpenSSL cannot be used.
So far we ignored if readdir_ensure_type() failed, the .d_type would
then still possibly report DT_UNKNOWN, possibly confusing the caller.
Let's make this safer: if we get an error on readdir_ensure_type() then
report it — except if it is ENOENT which indicates the dirent vanished
by now, which is not a problem and we should just skip to the next
entry.
Let's ask exactly for the one field we actually want to know, i.e.
STATX_TYPE.
(While we are at it, also copy over the inode number, if we have it,
simply to report the most recent info we have)
(Also, see AT_NO_AUTOMOUNT, so that we don't trigger automounts here.
After all, if we want to know the inode type of a dirent here, then
there's not need to trigger the automount, the inode type is not going
to change by that.)
Apparently glibc already has a helper for this. (Not in the man pages
for Linux, but FreeBSD does document these cryptic helpers, and its
exported by glibc. That should be good enough for us.)
This option has coredumpctl look at all journals instead of only the
local ones. This allows coredumpctl to show information about remote
coredumps if the coredumps are made available in /var/lib/systemd/coredump
and the corresponding journals are made available in /var/log/journal.
This is already possible using the --directory option but --all makes it
more user friendly since users don't have to enter the journal directory
anymore as long as it's available under /var/log/journal.
