For example, I see "Linux Bleeding Edge Appimage Download" for downloading a user-executable file by HTTP. No HTTPS, no signatures, not even sha1sum. The same for Windows binaries. Reproducible: Always Steps to Reproduce: 1. Go to Krita download site 2. Download Krita 3. Attempt to verity if the downloaded file is corrupted Actual Results: No way to verify if the downloaded file is genuine Expected Results: There is published checksum or there is detached signature file.
If you add .mirrorlist to the end of the url you get all that info: http://files.kde.org/krita/3/linux/devbuilds/krita-3.0-Beta-master-562442e-x86_64.appimage.mirrorlist
Then links to those mirrorlists should be visible on download page, like this: * Linux Bleeding Edge Appimage Download <small>(mirros and checksums)</small> * Linux Bleeding Edge Appimage Download (legacy distros) <small>(mirros and checksums)</small> Also your link to mirrorlist is HTTP (not HTTPS). It means checksums may be also faked. Changing the link to https makes 404.
We do not maintain files.kde.org, so there is nothing we can do about it. The KDE system administrators are moving all sites to https, but they're not done yet.
I've talked to the system administrators. The problem is that files.kde.org is a redirector to mirror services, and that doesn't play well with https. As for the sha1sums, whenever I add them to the release announcements I get confused mails from users asking me what they should do with them...
One more idea: include magnet links. A file downloaded from magnet link (obtained securely, of course) should be secure.