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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
With negative numbers we wouldn't account for the minus sign, thus
returning a string with one character too short, triggering buffer
overflows in certain situations.
(cherry picked from commit e3dd9ea8ea)
The Stream Deck products from Elgato are simple key pads
intended to be used as macro pads. They're popular within
the streaming community.
This commit adds all 5 Stream Deck variants available to
the AV production file.
See https://www.elgato.com/en/stream-deck
(cherry picked from commit e982320b44)
This adds support for AV production controller devices, such
as DJ tables, music-oriented key pads, and others.
The USB vendor and product IDs come from Mixxx, Ctlra, and
Ardour.
Fixes#20533
Co-developed-by: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
(cherry picked from commit f2c36c0e24)
Add srpm_build_deps key to the Packit config to specify needed dependencies for SRPM build
and indicate to build SRPM in Copr.
(cherry picked from commit d15e1a29e3)
The event loop is already shutting down, hence no point in using it
anymore, it's not going to run any further iteration.
(cherry picked from commit 47f04c2a69)
If we're consuming an on-disk seed, we usually write out a new one after
consuming it. In that case, we might be at early boot and the randomness
could be rather poor, and the kernel doesn't guarantee that it'll use
the new randomness right away for us. In order to prevent the new
entropy from getting any worse, hash together the old seed and the new
seed, and replace the final bytes of the new seed with the hash output.
This way, entropy strictly increases and never regresses.
(cherry picked from commit da2862ef06)
Since test-resolved-stream brings up a simple DNS server on 127.0.0.1:12345,
only one instance could run at a time, so it would fail when run like
`meson test -C build test-resolved-stream --repeat=1000`.
Similarly, if by chance something is up on port 12345, the test would fail.
To make the test more reliable, run it in an isolated user + network namespace.
If this fails (some distributions disable user namespaces), just run as before.
(cherry picked from commit c76120f1b8)
In commit 2aaf6bb6e9, an issue was fixed where
systemd-resolved could get stuck for multiple seconds waiting for incoming data,
since GnuTLS/OpenSSL can buffer a TLS record, so data could be available, but
no EPOLLIN event would be generated.
To fix this, a somewhat elaborate logic consisting on asking the TLS library
whether it had buffered data, then "faking" an EPOLLIN event was implemented.
However, there is a much simpler solution: Always read as much data as available
(i.e. until we get an event like EAGAIN when trying to read) from the stream
when we get an EPOLLIN event, instead of at most a single packet per event.
This approach does not require asking the TLS library whether it has buffered
data, and the logic is exactly the same for both the TCP and TLS case.
test-resolved-stream is fixed to avoid a latent double free bug.
(cherry picked from commit 839a70c353)
Since when handling a DNS over TLS stream, the TLS library can override the
requested events through dnstls_events for handshake/shutdown purposes,
obtaining the event flags through sd_event_source_get_io_events and checking
for EPOLLIN or EPOLLOUT does not really tell us whether we want to read/write
a packet. Instead, it could just be OpenSSL/GnuTLS doing something else.
To make the logic more robust (and simpler), save the flags that tell us
whether we want to read/write a packet, and check them instead of the IO flags.
(& use uint32_t for the flags like in sd_event_source_set_io_events prototype)
(cherry picked from commit eff107736e)
Previously, the condition in on_stream_io_impl() never hit, as the
read packet is always taken from the stream in the few lines above.
Instead of the dns_stream_complete() under the condition, the stream
is unref()ed in the on_packet callback for LLMNR stream, unlike the
other on_packet callbacks.
That's quite tricky. Also, potentially, the stream may still have
queued packets to write.
This fix the condition, and drops the unref() in the on_packet callback.
C.f. https://github.com/systemd/systemd/pull/22274#issuecomment-1023708449.
Closes#22266.
(cherry picked from commit a5e2a488e8)
Tests DnsStream event handling, both for plain TCP DNS and DNS over TLS.
The DoT test requires the "openssl s_server" command line tool to mock a simple
TLS server. Thus the test's TLS part is skipped if openssl it not available.
The test works for both DNS_OVER_TLS_USE_GNUTLS and DNS_OVER_TLS_USE_OPENSSL.
The DoT case fails due to a bug, which is fixed on the next commit.
(cherry picked from commit 726bcd81b9)
When sending multiple DNS questions to a DNS-over-TLS server (e.g. a question
for A and AAAA records, as is typical) on the same session, the server may
answer to each question in a separate TLS record, but it may also aggregate
multiple answers in a single TLS record.
(Some servers do this very often (e.g. Cloudflare 1.0.0.1), some do it sometimes
(e.g. Google 8.8.8.8) and some seem to never do it (e.g. Quad9 9.9.9.10)).
Both cases should be handled equivalently, as the byte stream is the same, but
when multiple answers came in a single TLS record, usually the first answer was
processed, but the second answer was entirely ignored, which caused a 10s delay
until the resolution timed out and the missing question was retried.
This can be reproduced by configuring one of the offending server and running
`resolvectl query google.com --cache=no` a few times.
To be notified of incoming data, systemd-resolved listens to `EPOLLIN` events
on the underlying socket. However, when DNS-over-TLS is used, the TLS library
(OpenSSL or GnuTLS) may read and buffer the entire TLS record when reading the
first answer, so usually no further `EPOLLIN` events will be generated, and the
second answer will never be processed.
To avoid this, if there's buffered TLS data, generate a "fake" EPOLLIN event.
This is hacky, but it makes this case transparent to the rest of the IO code.
(cherry picked from commit 2aaf6bb6e9)
RANDOM_BLOCK has existed for a long time, but RANDOM_ALLOW_INSECURE was
added more recently, leading to an awkward relationship between the two.
It turns out that only one, RANDOM_BLOCK, is needed.
RANDOM_BLOCK means return cryptographically secure numbers no matter
what. If it's not set, it means try to do that, but if it fails, fall
back to using unseeded randomness.
This part of falling back to unseeded randomness is the intent of
GRND_INSECURE, which is what RANDOM_ALLOW_INSECURE previously aliased.
Rather than having an additional flag for that, it makes more sense to
just use it whenever RANDOM_BLOCK is not set. This saves us the overhead
of having to open up /dev/urandom.
Additionally, when getrandom returns too little data, but not zero data,
we currently fall back to using /dev/urandom if RANDOM_BLOCK is not set.
This doesn't quite make sense, because if getrandom returned seeded data
once, then it will forever after return the same thing as whatever
/dev/urandom does. So in that case, we should just loop again.
Since there's never really a time where /dev/urandom is able to return
some easily but more with difficulty, we can also get rid of
RANDOM_EXTEND_WITH_PSEUDO. Once the RNG is initialized, bytes
should just flow normally.
This also makes RANDOM_MAY_FAIL obsolete, because the only case this ran
was where we'd fall back to /dev/urandom on old kernels and return
GRND_INSECURE bytes on new kernels. So also get rid of that flag.
Finally, since we're always able to use GRND_INSECURE on newer kernels,
and we only fall back to /dev/urandom on older kernels, also only fall
back to using RDRAND on those older kernels. There, the only reason to
have RDRAND is to avoid a kmsg entry about unseeded randomness.
The result of this commit is that we now cascade like this:
- Use getrandom(0) if RANDOM_BLOCK.
- Use getrandom(GRND_INSECURE) if !RANDOM_BLOCK.
- Use /dev/urandom if !RANDOM_BLOCK and no GRND_INSECURE support.
- Use /dev/urandom if no getrandom() support.
- Use RDRAND if we would use /dev/urandom for any of the above reasons
and RANDOM_ALLOW_RDRAND is set.
(cherry picked from commit 31234fbeec)
Previously, even if a link is in unmanaged state, the function may
returns positive value. So, even if all managed links are in the configured
sate but do not satisfy the online criteria, e.g., IPv4 address state,
then wait-online finishes with positive value.
This makes the function always return 0 for unmanaged state. So, at
least one managed link must satisfies the online criteria.
This also adds more comments and debugging logs.
Fixes#22246.
(cherry picked from commit cd7fcda543)
Backward incompatible change to avoid returning 'skipped' if a condition causes
a job activation to be skipped when using StartUnitWithFlags().
Job results are broadcasted, so it is theoretically possible that existing
software could get confused if they see this result.
Replaces https://github.com/systemd/systemd/pull/22369
(cherry picked from commit ee3ae55e75)
In some BIOSes, the "Number of slots or sockets available for Memory
Devices in this array" is incorrectly set to the number of memory array
that's populated.
Work-around this problem by outputting the number of sockets after
having parsed them so that consumers of this data can carry on expecting
an accurate number in this property.
This fixes the number of memory slots advertised for the HP Z600.
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1686
(cherry picked from commit d48bf01636)
The complaint was that the output array was used for two kinds of data, and the
input flag decided whether this extra data should be included. The flag is
removed, and instead the old method is changed to include the data always as
a separate parameter.
This breaks backward compatibility, but the old method is effectively broken
and does not appear to be used yet, at least in open source code, by
searching on codesearch.debian.net and github.com.
Fixes#22404.
Co-authored-by: Luca Boccassi <bluca@debian.org>
(cherry picked from commit 087a799f64)
IIUC, pipefail doesn't matter for a sequence of commands joined with &&, and we
don't have any pipes. And such a failing expression also does not trigger an
exit, so the set +e/set -e were noops.
(cherry picked from commit 13391986b5)
The approach to use '''…'''.split() instead of a list of strings was initially
used when converting from automake because it allowed identical blocks of lines
to be used for both, making the conversion easier.
But over the years we have been using normal lists more and more, especially
when there were just a few filenames listed. This converts the rest.
No functional change.
(cherry picked from commit f1b98127ff)
I think the current behaviour is stupid: 'x-systemd.automount,noauto' should
mean that we create the units, but don't add .mount or .automount to any targets.
Instead, we completely ignore 'noauto'. But let's at least describe the
implementation.
Text suggested by dpartrid in the bug.
Fixes#21040.
(cherry picked from commit 55fabe92e2)
A description of SD_BUS_VTABLE_CAPABILITY is added, and the discussion
on SD_BUS_VTABLE_UNPRIVILEGED in expanded. I think it would be nice
to add longer description of how access is checked (maybe in sd-bus(3)),
but I'm leaving that for later. I think the text that was added here
describes everything, even if tersely.
Fixes#21882.
(cherry picked from commit b4e7d7555e)
docbook would convert the newline to a space before the first argument:
SD_BUS_METHOD_WITH_ARGS( member, args, result, handler)
And we need each item in a separate <para>, otherwise they'll all be in
one line.
(cherry picked from commit 3c080282e9)
Do not print a warning in case we try to load the file system protocol for an
unsupported file system, just return EFI_SUCCESS instead.
(cherry picked from commit 178d598b5f)
The data type off_t can be 64 on 32 bit systems if they have large
file support. Since mmap expects a size_t with 32 bits as second
argument truncation could occur. At worst these huge files could
lead to mmaps smaller than the previous check for small files.
This in turn shouldn't have a lot of impact because mmap allocates
at page size boundaries. This also made the PAGE_ALIGN call in
open_mmap unneeded. In fact it was neither in sync with other mmap
calls nor with its own munmap counterpart in error path.
If such large files are encountered, which is very unlikely in these
code paths, treat them with the same error as if they are too small.
(cherry picked from commit 1a823cdeb9)
