<div dir="ltr"><div dir="ltr">On Fri, Feb 11, 2022 at 10:22 AM Fabian Vogt <<a href="mailto:fabian@ritter-vogt.de">fabian@ritter-vogt.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Moin,<br>
<br>
Am Sonntag, 6. Februar 2022, 21:54:13 CET schrieb Fabian Vogt:<br>
> Am Sonntag, 6. Februar 2022, 19:27:11 CET schrieb Ben Cooksley:<br>
> > On Sun, Feb 6, 2022 at 1:07 PM Fabian Vogt <<a href="mailto:fabian@ritter-vogt.de" target="_blank">fabian@ritter-vogt.de</a>> wrote:<br>
> > > The first URL is used by kfontinst.knsrc from plasma-workspace:<br>
> > > ProvidersUrl=<a href="https://distribute.kde.org/khotnewstuff/fonts-providers.xml" rel="noreferrer" target="_blank">https://distribute.kde.org/khotnewstuff/fonts-providers.xml</a><br>
> > ><br>
> > > The second URL is used by multiple knsrc files in my VM:<br>
> > > aurorae.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > > comic.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > > kwineffect.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > > kwinscripts.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > > kwinswitcher.knsrc:ProvidersUrl=<a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > > wallpaperplugin.knsrc:ProvidersUrl=<br>
> > > <a href="https://download.kde.org/ocs/providers.xml" rel="noreferrer" target="_blank">https://download.kde.org/ocs/providers.xml</a><br>
> > <br>
> > This makes me incredibly sad. We had a push to eliminate all usage of the<br>
> > legacy <a href="http://download.kde.org" rel="noreferrer" target="_blank">download.kde.org</a> endpoint many years ago...<br>
> > I have now resolved the majority of these - if distributions could please<br>
> > pick up those patches that would be appreciated.<br>
> > <br>
> > Please note that I have now terminated the support on the server that was<br>
> > making these legacy endpoints work, so those patches are necessary to<br>
> > restore functionality.<br>
> ...<br>
> It's also possible that the requests aren't actually caused by Discover at all,<br>
> but just something which imitates it in a DDoS attack. In that case we couldn't<br>
> do anything on the client-side anyway. I don't think this is very likely, but<br>
> until the issue was reproduced with disover it's a possibility.<br>
<br>
I think I have a plausible explanation for what could've caused this.<br>
While testing a MR for the notifier, I noticed odd behaviour: It always ran<br>
plasma-discover-update twice!<br>
<a href="https://invent.kde.org/plasma/discover/-/merge_requests/254#note_394584" rel="noreferrer" target="_blank">https://invent.kde.org/plasma/discover/-/merge_requests/254#note_394584</a><br>
<br>
The reason for that is that after the update process finishes, the notifier<br>
realizes that it's idle again and if updates are available, it will immediately<br>
trigger another update after the 15min idle time. Now here's the catch: If the<br>
system has already been idle for >=15min (which is very likely at that point),<br>
the idle timeout will immediately fire! This process repeats unlimited and<br>
without delay, until the system is no longer idle or there aren't updates<br>
available anymore. Here I have plasma-discover-update running approx. every<br>
second, which amounts to ~4 req/s to <a href="http://download.kde.org" rel="noreferrer" target="_blank">download.kde.org</a>.<br>
<br>
This is mostly mitigated by the introduction of the 3h delay between updates<br>
by d607e0c6f9, but not entirely. The check is only effective after the second<br>
iteration, which is what I observed in my testing. (One of the commits in my MR<br>
should address that as well.)<br>
<br>
One of the conditions for running into this bug is that after the automatic<br>
updater ran, there still have to be updates available to trigger the next run.<br>
Initially I thought that this can mostly happen if updates fail to download or<br>
install, this is unfortunately not true. The notifier by default counts all<br>
available updates, but the updater only installs offline updates. So if there<br>
is even a single non-offline update available, the loop continues.<br></blockquote><div><br></div><div>Continues infinitely I assume?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So this probably affected a lot of users who enabled automatic installation of<br>
updates :-/<br></blockquote><div><br></div><div>Do we know if any distributions flipped that switch?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
Fabian<br>
<br></blockquote><div><br></div><div>Regards,</div><div>Ben</div></div></div>