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