Can someone please verify that the Checksum for the latest ipfire is
SHA256: cd69d102104cad10be6fe3138c5e09004720a87cc4f3a2d28197b23b2e331b4c
I would prefer if a moderator or developer checks thanks.
I am just asking as I had a nasty experience with a “parallelized” download website (DNS switched) recently faking checksum and giving me a malicious DISTRO so I have to check by alternate ways that the SHA256 that is printed for ipfire publicly is actually from IPFIRE and not from a man in the middle site.
Luckily I always install sandboxed and am careful to check before commissioning so there was no harm.
I dont want it from a page as the page can easily be redirected to a parallel website here. I want confirmation in text on the forum.
Please read my original post to understand.
I have a copy of Core Update 162 that I downloaded on 5th January from the IPFire website. That has the sha256 hash that you have listed. I just confirmed that hash now.
Where did you find that info, cannot find confirmation of that anywhere on ipfire.org or avatars.
Please understand it is nothing personal it just looks suspicious.
if I may comment on this one from the projects’ infrastructure perspective (maintaining the mail parts of it, but I think I can speak for web-based services as well):
This is exactly why ipfire.org is DNSSEC-signed, and why we rolled out DNSSEC to the masses years ago. While I understand most SOHO setups implicitly rely on their ISP to validate DNSSEC signatures, if you do so yourselves (either by using IPFire or any other DNSSEC-validating resolver), you can at least be sure you got the right IP address from the DNS.
That does not rule out BGP hijacking or similar attacks, but these would require an adversary to be capable of issuing X.509 certificates your browser trusts - which is possible unless you validate DANE, but requires skills one normally finds at the upper end of organised cyber crime or intelligence agencies.
(ipfire.org’s certificate can be validated using DANE, but I am unaware of any common web browser doing this. )
Downloading the ISO, you will get redirected to one of our mirrors, which we are thankful for their services, but don’t have to trust them. If the SHA256 does not match, kindly report back to us and try another mirror (I am unaware of such an incident ever happened).
Also, I can confirm cd69d102104cad10be6fe3138c5e09004720a87cc4f3a2d28197b23b2e331b4c is the correct SHA256 checksum for Core Update 163’s x86_64 ISO file. Enjoy it!
I am not a mod and not even an expert here but you I think you have the right mindset of not relying on checksums.
checksum just tells you that the file didn’t get corrupted during download
SHA256 is a hash so it should be safe, to trust www.ipfire.org while in https mode.
Although it might be another story if the cert is issued by Lets Encrypt and exprires every 3 months.
Some vendors Sign their packages but you would need get their key before you need to rely on it.
Trish, it is a good point.
You can only rely on what you can verify, and not what is presented to you as trusted. You can trust absolutely nothing. Not even trust itself. Then verification is an infinite depth spiral. Only you decide when it is enough, which in itself is a flawed method.
The old American saying. “In God we Trust … Everything else we check twice” rings particularly true.
I do not trust an image and a checksum presented to me. I do not trust a DNS server to dish me up an IP. I use hard checked IP addresses to download, I use several paths of downloading the same images and checksums and compare etc etc.
If I download e.g. firewall images I have the checksums verified as printed by individuals I know and on a usergroup. Usergroups are not so easy to parallelize.
And then I get impatient and careless occasionally and happen to download a tampered-with distro. You eventually lose never mind all your best practices and intentions.
It becomes clear that for every security feature you install or use there is very quickly a workaround. We are now at the stage that probably only a millionth of a percent of users do have the will and the means (as in technical ability) to protect themselves. It is not a good situation. I actually think 2022 is a huge turning point in security. It is going to go down quite a few notches, but unfortunately most wont notice.