[Feature] Please provide checksum in order to validate downloads from the website

[iio7]

As the title says. It's impossible to validate a download. You need to provide at least sha1 checksums and some proper way of validation. These checksums cannot reside on the website because if the website gets compromised, so would the checksums.

[CvH]

We currently just offer https://releases.libreelec.tv/LibreELEC-RPi4.arm-10.0.2.img.gz?mirrorlist (https://....?mirrorlist) to view the sha256. Ofc this is not safe against compromising attacks, same goes to github and the website.

ideas welcome :)

[iio7]

I suggest looking through some of the other open source projects to see how they do it, and then find one of the models that best suit your project. It's a must have.

[lrusak]

@CvH we already generate sha256 of the image. We can just copy them over to the mirrors when copying the image?

[chewitt]

@lrusak Hashes on the same server as the images are not trusted as an attacker who compromises the server can post a bad image and matching hashes. So we need to publish them from a different location, i.e. include them in the website blog post. I think we just need to update the JSON update script so they also generate the content needed for the blog post.

[antonlacon]

My understanding of the secure way to do this is:

Someone on team generates gpg keys: gpg --full-generate-key This is a cli driven menu for creating private/public key pairs.

Said member uploads the public portion to a public keyserver, like https://keyserver.ubuntu.com. I believe the ubuntu one is the default for gpg. The key's fingerprint should also be published somewhere on an LE controlled website. The fingerprint is a 40 character hexadecimal string output at the end of key generation or viewed with gpg --fingerprint.

Said member signs the .sha256 file: gpg --detach-sig --armor $FILE.sha256. This generates an .asc file signed by the member's key.

The image, .sha256, and .asc are put on the release server for end users to obtain. End users obtains all three files and should:

Obtain member's public key: gpg --keyserver $KEYSERVER --recv-keys $THE_PUBLISHED_FINGERPRINT

Verify the sha256 checksum's signature: gpg --verify $FILE.asc $FILE

Verify the sha256 checksum: sha256sum --check $FILE.sha256

I'm not excited about implementing this as I believe the number of users that will do this to be exceedingly low.

I believe providing .sha256 files alongside images/tarballs to verify download integrity would be useful to a wider audience. I don't know what the website needs to get the sha256sums listed too. I believe such a list would be as trustworthy as the gpg method as the end user is either trusting the website's published check sums , or they're trusting the key fingerprint.