https://bugs.kde.org/show_bug.cgi?id=364594
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |valorie.zimmer...@gmail.com
--- Comment #3 from Harald Sitter <sit...@kde.org> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
