Почему используют SHA-1, а не SHA-256 или 512?

2. Дать пользователю убедиться, что файл не был изменен злоумышленниками.

И часто у вас злоумышленники так меняют файл, что md5 совпадает?

Не путай хэш и подпись. MD5 для проверки целостности за глаза. Если смогли подменить файл на вредоносный, то и всякие *.md5 тоже подменят и страницу на сайте подправят. А вот подпись файла подделать сложнее будет. Потому кладут к файлу обычно *.asc для проверки.

У них и спрашивай. Недавно качал OpenBSD, там SHA-256. Твои сайты видать 30 лет скрипты не обновляли.

Хеши для разных задач. MD5 и SHA-1 хорошо для проверить, что файл скачался не побитым и соответствует тому, что на сайте. Если тебе нужны гарантии, уже нужна подпись и криптография.

Отправь им security request, чтобы поменяли алгоритмы на более надёжные и добавили подписи. Тогда можно суммы держать в текстовом файле *.DIGEST, и его же подписывать криптографической подписью. Подпись гарантирует, что DIGEST не скомпроментирован, а несколько надёжных хэш-алгоритмов гарантируют, что проверяемый файл (программа, архив) — не повреждён и не подменён.

Внезапно, MD5, SHA1, SHA256 - это всё криптографические хеш-функции (просто первые две сейчас уже ненадёжные)

Чтобы просто проверить «что файл скачался не побитым» есть, скажем, CRC

то и всякие *.md5 тоже подменят и страницу на сайте подправят

Бывает, хэшсуммы кладут на сайте по https, а скачивание с разных зеркал
Например, при скачивании vlc на его сайте можно посмотреть SHA-256, а ссылка на экзешник ведёт на mirror.yandex.ru

CRC разные бывают, FYI. И покажи мне *nix-утилиту, которая их считает. А md5sum/sha1sum везде есть.

Еще это актуально для старых версий, которые с официального сайта убрали.

И покажи мне *nix-утилиту, которая их считает.

dev-perl/Archive-Zip-1.640.0 (/usr/bin/crc32)

они много процессора жрут, если чё. а md5 всё же лучше crc32 (т.е. это придётся немло ресурсов потратить чтобы сфабриковать, проще подменить хэши на нужные), кроме того файлы в любом случае через gpg верифицируются. вот в венде бинарники ворованными ключами верифицируют все заинтересованные, например, так себе защита. От опенсорса и бесплатного ПО разве что.

zlib по-моему считает, значит кто угодно может посчитать — ключевая библиотека в любой системе. из готового можешь взять однострочник на питоне.

кстати вот это везде есть, даже в кедах https://i.imgur.com/1jWGAKr.png

Ну с авторами vlc я водку не пил, так что путей попадания файлов на mirror.yandex.ru от них я не знаю. Если какая синхронизация, то возвращаемся к исходной задаче, если вручную заливают, то могут быть варианты.

В любом случае подпись файла надёжнее контрольной суммы будет для поиска подмены. По крайней мере я считаю, что увести закрытый ключ для подписи сложнее, чем ломануть сайт.

подпись файла надёжнее контрольной суммы будет для поиска подмены

Обычно подписывают не сам файл, а .DIGEST, в котором (криптографически стойкие) контрольные суммы.
Если сайт, где лежит хэш, открыт по https, то хозяин сайта уже удостоверен (та-дам!) цифровой подписью, его веб-серверу нужен сертификат с закрытым ключом

Внезапно, но cksum.

Дырявый сайт с https это как дырявый сайт без https, только с https.

Дырявый сайт, дырявый openssl, дырявый gpg это реализация

Хеши нужны именно для проверки небитости файла.

Если кто-то получил доступ к сайту, что мешает также заменить и хеш суммы?

Для проверки подлинности используют gpg, кладут рядом сигнатуру

Например:

https://www.kernel.org/pub/linux/bluetooth

Если кто-то получил доступ к сайту, что мешает также заменить и хеш суммы?

Хеши размещены на сайте, а файл лежит на зеркалах

Вот еще пример кубунта
https://kubuntu.org/alternative-downloads/
Сайт страничка, где есть хэш-суммы, открывается по https, а образы надо качать по http или с левых зеркал