Там есть сложности с обратной совместимостью.
Подход, который был выбран для решения этой задачи в rpm.org, не годится.

> Там есть сложности с обратной совместимостью.

В чем они состоят? Я полагал, что добавление не стандартных хэшей (типа Стрибог) вызовет не совместимость, но добавление sha256 нет, так как rpm его уже поддерживает. Сейчас не предлагаю добавлять поддержку Стрибог, а только уйти с md5.

MD5 might be good enough.  You cannot verify the integrity of a system from within that system.  Or you shouldn't put too much faith into such an integrity check.

Suppose an attacker replaced a vital file /usr/bin/foo.  This can be detected via hash(/usr/bin/foo) which is stored in /var/lib/rpmdb, but the attacker can also edit rpmdb.  If rpmdb has been edited, this must be detectable via /usr/bin/gpg - the signatures won't match. But then the attacker has full control over the tool which verifies the signatures.

The whole business of "rpm -V" is about as serious as MD5, in my opinion.

Обращаю внимание, что для RPM есть сторонних библиотек работы с ним, но они уже давно не поддерживают MD5, так что «RPM с MD5» уже давно вне мира «стандартного RPM»

См. например https://github.com/google/rpmpack/blob/60c43da513f7e4e40c8236e75c799886389fcf2b/rpm.go#L423

https://github.com/linux-application-whitelisting/fapolicyd/issues/137

rpm has support sha256 since 2009. SHA1 is considered broken since 2019. И т.д.
В fapolicyd даже sha1 уже нормально не поддерживается, не говоря уже о md5.
Очень хочется увидеть нормально работающий fapolicyd, и соответственно sha256 в нашем rpm-build по-умолчанию.