On Fri, Feb 11, 2022 at 10:22 AM Fabian Vogt <[email protected]> wrote:
> 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 <[email protected]> > 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. > Continues infinitely I assume? > > So this probably affected a lot of users who enabled automatic > installation of > updates :-/ > Do we know if any distributions flipped that switch? > > Cheers, > Fabian > > Regards, Ben
