Include hash sum locations of AppImages - and popularize if good idea

Hi. AppImages are great. There are many community maintained sites which host AppImages. However, user has to trust the distributor and the distribution infrastructure of such community sites. Serious security incidents can happen; [How one man could have hacked every Mac developer (73% of them, anyway)](https://nakedsecurity.sophos.com/2018/08/10/how-one-man-could-have-hacked-every-mac-developer-73-of-them-anyway/).

One of good states of the AppImage ecosystem would be that every open-source and closed-source software author offers AppImage on their site behind valid SSL certificate. However, infrastructure for high bandwidth site or CDN of software releases could be not feasible to maintain for smaller producers.

I propose an alternative system and a convention which could be used as a base layer for integrity verification in the AppImage ecosystem. It is easy to implement so involved parties can use it without problems.

**Software authors and community**
1. Software authors publish cryptographic hashsum of AppImage files on their website behind valid SSL certificate
2. _Community AppImage scrapers_, _community distributors_ and _community package maintainers_ and other community members and community systems distribute AppImage files **with** URLs (locations) to cryptographic hashsums provided by software authors

**Software users**
Then users can verify integrity and authenticity of any AppImage file at their machines:
1. Check if hashsum of AppImage file is the same as the hashsum found at provided URL
2. Check if provided URL belongs to software authors

Verification on the user side can be done manually or semi-automatically:

**Manual verification**
1. User verify that the URL belongs to software authors by SSL certificate or by general knowledge of the site (ex. firefox.org/releases/appimage-hashes.txt)
2. User visits the URL with the hash (ex. firefox.org/releases/appimage-hashes.txt)
3. User runs `sha512sum someprogram.appimage` and compares the output hash with the hash at the URL (ex. firefox.org/releases/appimage-hashes.txt)
4. If hashes match, file integrity and authenticity are verified

**Semi-automatic verification (just one user action required)**
1. User uses some trusted AppImage package manager or some audited version of AppImage package manager
2. Package manager downloads untrusted AppImage files (ex. from HTTP non-SSL websites / repos / github) with their hashsums (ex. firefox.org/releases/appimage-hashes.txt) and downloads the actual hashes (only HTTPS with valid SSL certificate)
3. Package manager displays the URL to the user (ex. firefox.org/releases/appimage-hashes.txt)
4. User confirms the authenticity of the URL by typing `y`
5. Package manager tests `sha512sum(someprogram.appimage) == downloaded_hashsum_of_someprogram`
6. If hashes match, file integrity and authenticity are verified

**Proposal of a standard of AppImage hashsums file (draft)**
```
# comments starts with #, each line contains one record consisting of version of the record (currently v1)
# v1 expects five words separated by one space and wrapped in double quotes (") if word contain space:
#record_format_version file_name package_version hash_function hash_of_file
# package_version format is not defined, recommended format is semver (x.y.z) https://semver.org/
# processing party is responsible for detection and handling of package_version format (no list of formats in v1)
# file must include just one package (ex. firefox and firefox-esr must have two files)
# file should have extension .txt
# examples:
v1 appimage_filename_whatever.appimage ver3.6 sha512 32cc3e9b2a03d4e4a4875c427f723b7873d991334b3ef92118fd8e75e4f22d8d01b885276e55f8f3e61c6db2f3644f21ed52a7f73485176c92c123ed5c9ccf07
v1 program_v4.5.6_no_extension v6.0.1-dev sha256 c032d47970e81adad5e0eb6dd6351465a7afa8e388df1524ae79aff3406a21e4
v1 "program with spaces" 4.2.8 sha256 9bda22014bdfb1bc8ccec988e77f281c6f5bdfa4a0b3fb90a77f353cfc67f241
v1 "program with spaces" "5.6.9 dev" sha256 2bd1a722fab45ae34f90485dafc0ea2c0f0326fc74a9180523efc9a6127482a5
```
More precise specification of the format can be found here where I wrote about the idea in wider context https://github.com/srevinsaju/zap/issues/66

To make this practical, it needs support from both software authors (producers) and the AppImage community.