I've just been terribly disappointed by Arch and Manjaro: their official websites still use SHA-1 checksums and pgp signatures for integrity checks on their official images.
An algorithm that has been now broken for quite a while: https://sha-mbles.github.io/

Kinda disappointing for an OS that aims to be at the bleeding edge of performance and security.

Okay but can you tell me how is this relevant in the cintext of checking package integrity?

In case you're wondering what the issue is: it is now relatively easy to introduce malicious changes into the images and then ensure that the checksum matches. Same for the GPG signature.

@yellow-dog integrity as in "the file broke during download": sure, it's enough.
Integrity as in "nobody tampered with this or spoofed the source": no guarantees.

PGP isn't broken and hashes alone were never good enough to verify the integrity.

I stand corrected, their pgp signatures actually use SHA-256. I guess I can (partially) retract my disappointment.

@sbiewald pgp itself isn't broken, but pgp signatures made using SHA-1 are. Check the link I posted.

Well yeah, but its arch. You can go ahead an just put a virus in the aur, nobody is stopping you. Putting malicious code up and tampering with the checksum can only be done by the developer who doesnt even need to do that, they can just package their rmrf code into a binary and upload it with the correct checksum.

@yellow-dog the aur has nothing to do with this, because it's up to the user to decide if they want to get a package from there or not.

I'm talking about the base installation image.
I could include some code that curls all your secret keys to my server when you generate them, or breaks your kernel's PRNG, or even just a keylogger, and you might never find out.

Goddamn, at least it's not MD5.

But yes, they should just switch to SHA-256 or better.

@kescherRant Arch still lists MD5 as well 😂

@endor I am curious, where do you see the hash algorithm _of the signature_ is SHA1?

@sbiewald I mistakenly assumed that it was SHA-1 due to the short length of the signature files.

Turns out they just didn't ascii-armor their sigs (hence the shorter files), but gpg --list-packets shows "digest algo 8", which corresponds to SHA-256 according to https://tools.ietf.org/html/...