SHA256 verification as printed on website

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.

https://www.ipfire.org/download/ipfire-2.27-core162

this page shows you the sha256sum

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.

2 Likes

Thanks for the confirmation

Any confirmation from developers / moderators

Adolf is a moderator, and I can confirm the SHA256 hash too. :wink:

user@T5600:~/Downloads$ sha256sum ipfire-2.27.x86_64-full-core162.iso 
cd69d102104cad10be6fe3138c5e09004720a87cc4f3a2d28197b23b2e331b4c  ipfire-2.27.x86_64-full-core162.iso
1 Like

Where on the site can I find the list of moderator names?
Paul did not list it in his avatar unfortunately and only joined in 2019

Also, do you find the same

$ nslookup ipfire
Server:         193.135.143.25
Address:        193.135.143.25#53

** server can't find ipfire: NXDOMAIN

and

$ nslookup ipfire.org
Server:         193.135.143.25
Address:        193.135.143.25#53

Non-authoritative answer:
Name:   ipfire.org
Address: 81.3.27.38
Name:   ipfire.org
Address: 2001:678:b28::

$ nslookup 81.3.27.38
38.27.3.81.in-addr.arpa name = fw01.ipfire.org.

Authoritative answers can be found from:

nslookup ipfire.org

Non-authoritative answer:
Name: ipfire.org
Address: 81.3.27.38
Name: ipfire.org
Address: 2001:678:b28::

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.

And what about

$ nslookup 81.3.27.38

https://community.ipfire.org/g/moderators

1 Like

See here

Adolf was faster. :wink:

1 Like

Thank you very much.

Hi,

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. :expressionless: )

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! :slight_smile:

Thanks, and best regards,
Peter Müller

3 Likes

Thank you very much Peter.
Things are getting really strange here around the DC area.

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 :sunglasses: 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.

1 Like

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.

1 Like

A post was split to a new topic: Risks of CPU vulnerabilities