Automated usage of Gitlab

[Nicolas Fella]

On 7/3/22 12:45, Ben Cooksley wrote:
> Hi all,
>
> Recent analysis of the logs of our Giltab instance has revealed
> numerous instances of files being directly retrieved from Gitlab
> (using the /raw/ API). Much to my incredible sadness, this has
> included accesses being made by KDE Applications themselves.
>
> As a reminder, automated access to the "raw files" API of Gitlab is
> strictly prohibited and not permitted under any circumstances. The
> only use of it which is allowed is within .gitlab-ci.yml files to
> import job definitions from sysadmin/ci-utilities.
>
> At this time I am tracking:
> - Retrieval of qt/qt/qtbase - .qmake.conf and extra-cmake-modules -
> FindUDev.cmake and COPYING-CMAKE-SCRIPTS from systems operating in
> Microsoft Azure using curl.
>
> - Retrieval of *.colors files from the Breeze repositories,
> originating from KDE CI/CD servers, likely as a consequence of unit
> tests or Craft builds

That looks like
https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/kde/kdemultimedia/kdenlive/kdenlive.py#L116

That's the only usage of raw invent URLs I see in craft-blueprints-kde

>
> - Retrieval of various code examples from various repositories,
> originating from KDE CI/CD servers, likely due to unit tests or Craft
> builds utilising them
>
> - Retrieval by Digikam itself of files from the Digikam code
> repository (see
> https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/onlineversion/onlineversionchecker.cpp)
>
> The last one is particularly upsetting, as this is how we ended up
> with a bad situation with Discover.
>
> Developers - please discuss with Sysadmin before implementing
> functionality in your software that communicates with KDE.org
> infrastructure so we can ensure that the endpoints you are contacting
> are highly scalable.
> Gitlab does not meet this criteria by any definition at all.
>
> If we could please get these corrected that would be appreciated.
>
> Thanks,
> Ben