Due to protection against attack vectors like automated spam and upload
bots, we do not support upload feature over ghns.

You are saying, that the web based upload is more secure against attack vectors and that knewstuff upload shpuld be rewritten using the web interface ?

Uploading files through an api is requested by an GSOC project related to finance applications, please add related support.

Due to the lack of response to this request, the KDE store was excluded from use as a data store for a recently launched GSOC project in the area of data provisioning for financial applications.

Upload support has been removed with the merge request https://invent.kde.org/office/alkimia/-/merge_requests/11 from alkimia. If the situation changes later, this link will make it easier to add the functionality again.

If you have any idea how we could implement this in a good way for Alkimia
(and other), we would like to get this in.

Due to protection against attack vectors like automated spam and upload bots, we do not support the upload function via ghns.

Since there is an upload function via the webfrontend, according to this logic this must be more secure and a new implementation of uploading via the webfrontend must be better ? I think not necessarily, see for example https://www.heise.de/news/Mehrere-Linux-Appstores-Pling-Store-App-via-Cross-Site-Scripting-angreifbar-6115405.html

After all, there are countless internet applications, like telegram, facebook and many others, that support secure uploading via a client or an app, why can't GHNS do that ?

I'm not a security researcher, so I can't make a qualitative statement here, but thinking about the issue, a few questions come to mind:

Is it because of the server API which was not implemented securely, the store itself which has security holes or the knewstuff library ? Does the server api and/or the knewstuff library not contain measures against spam and upload bots ? Or is it other libraries used by knewstuff ?

I think that a security audit of the involved components could help to detect potential security holes and get hints for a secure implementation.

Updating is different than uploading. Sorry, but I misunderstood the title.
First step for uploading would be to securely connect (via kaccounts or
webaccount), then we could gain experience with rating and comments as
first step to see how it goes.

As can be seen from the source code (see https://github.com/KDE/knewstuff/blob/6788cf4fb24242398abb4578f6337a4d162b5893/src/uploaddialog.cpp#L720), updating a KDE storage item, which in fact means uploading files, uses the same frontend of KNewstuff as for uploading a new item .