a lot of mirrors use http or ftp, so the signing chain is going to break. it's better if it breaks from the authoritive neon website to files.kde than from files.kde to some random mirror.

this is precisely why we encourage gpg signature verifiction of the ISO.

I have a CS degree, has used Kubuntu since 6.06 and I don't know how to verify it. 
Likely 99% of the downloads will not be verified with this approach. 
At least you need to write how to perform the verification - that will help the people who is aware of security issues.

Web sites need to make it easy to be secure.
Torrents could give you both check-summing and capacity.
Linking directly with https works fine: https://files.kde.org/neon/images/neon-useredition/current/
probably the mirror part doesn't work.

https access to files.kde goes right into the webserver without first running through the load balancing mirrorbrain. supposedly because the mirrors largely don't do https. I'd absolutely like this to change, but this is a fairly large undertaking to get all mirror providers to add https support. I very much encourage you to get in touch with the kde sysadmins if you wish to get the ball rolling on that one. but until such time we simply can't use https, given the size of ISOs would pretty much kill the server in question.

torrents don't help much either since they only verify file integrity, not their authoritativeness. if one were to gain access to neon.kde.org one could easily hand out poisoned torrent links instead of the real ones.

the way this is meant to work from a gpg perspective is: you as a person have (to be able) to verify that an ISO was signed by the neon team as being a neon ISO.
the way you would go about this is to obtaining the ISO signing key and using gpg to verify that the .sig file matches the .iso file. at this point you know that the ISO is intact (basically a checksum check). 
to establish the authority of the key (and transitively of the ISO) you'd:
- check the keys that have signed the key are trustworthy (ideally by being able to stretch a trust chain from your own key to the signing key, e.g. know someone who knows someone who knows a neon dev). this is largely implicit but that is kind of the point of a web of trust
- you check that the key id of the signing key you have downloaded is the one shown on the neon website

the three measures combined (verify & trustworthyness & shown on website) allow you to verify the authority and integrity of the ISO. this is pretty much the only approach that guarantees nigh absolute security of the file.
- files.kde gets hacked and .iso spoofed -> .sig doesn't verify anymore
- files.kde gets hacked and both .iso and .sig get spoofed -> different signing key from website
- files.kde and neon.kde get hacked -> you are now dealing with a key which is neither signed by neon developers nor anyone else who should be in your web of trust so this key should look suspicious

anyway. long story short. we can't use https and its inferior to gpg signatures anyway.
that said, I appreciate that we have a lack of documentation there.

I am CCing documentation superstar Valorie to have a look. I think it would make sense to have a general purpose gpg signature verification guide on userbase somewhere. We also sign Plasma release tarballs nowadays and are expected to do the same for frameworks and applications at some point, so being able to link users to a useful quick guide on gpg verify would be very good.

GPG is great, but it's not a replacement for https.
if neon.kde.org got hacked then one would change both the link to the iso and the signing key (which the 1% use). Possibly you would only serve these files to the visitors that you are interested in (definitely not people with a kde login).
In the end, the authoritativeness of the torrent file is just as good because it really depends on what neon.kde.org tells the visitor.

Here is documentation for how to verify the iso (It's quite long): http://www.howtogeek.com/246332/how-to-verify-a-downloaded-linux-iso-file-wasnt-tampered-with/

> In the end, the authoritativeness of the torrent file is just as good because it really depends on what neon.kde.org tells the visitor.

Clearly you need to read up more on how gpg verification works and what a web of trust is. Additionally, you could read my comment #3 and notice that I outline 3 checks necessary to establish authoritativeness,  but the website you link to only describes 2 that put together only form a glorified checksum test.

I shall repeat myself here. If you want https coverage, get in touch with the kde sysadmins to discuss how to get the entire mirror network to https.
If you want a torrent, equally get in touch with kde sysadmins to figure out if they even wanted to host an original seed and ask them to figure how they want that to happen. If they do then we'll gladly accept code to produce and seed torrents.

thanks harald