Metalink4 с Стрибог хэшом

http://www.git.stargrave.org/?p=meta4ra.git;a=commitdiff;h=1efa4b2c0439a7f041a619d99e9b18c6a4045979
http://www.git.stargrave.org/?p=meta4ra.git;a=commitdiff;h=2d4783856dffafc91b9aa007c3dd922dea12599b
http://www.git.stargrave.org/?p=godlighty.git;a=commitdiff;h=60823f21a618760fa82ac72ac6c6c4e2974d4e4d
На сайтах для своего софта, в разделе скачивания, я публикую ссылку на
сам tarball, OpenPGP подпись над ним и SHA256 хэш. Позже я стал ещё
добавлять .meta4 файлы (542f9611780a28a67ebd52210bbdcb9845c2890c,
2374b93f88e7a3222c0e91999306b259bd9e276c), которые содержат и хэши
(SHA256 с SHA512) и ссылки на доступность по другим URL-ам. Эти же
.meta4 файлы я стал прикладывать к письмам оповещениям о новых релизах.
Сегодня задался вопросом: а зачем я дублирую значение хэша (и то, только
одного из) вне .meta4, раз он всё равно и в письмах и на сайте есть?
Кроме того, на сайтах PyGOST и GoGOST я ещё писал Стрибог-256 хэш. Что
мешает его добавить в этот же .meta4? Ну кроме того, что формально нет
RFC на это. А если Стрибог добавлен в meta4ra утилиту генерирования
.meta4 файлов, то автоматом Стрибог появится и во всех остальных местах,
остальных проектах. Собственно, вот и добавил его поддержку в meta4ra, в
godlighty web-сервер (чтобы в HTTP заголовке Стрибог хэш отдавал), а
также убрал хэши на страницах скачивания tarball-а, ибо излишне.

Вот правда моя pure-Go реализация Стрибога очень не быстрая. Пришлось и
распараллеливание расчёта Стрибог-256 и -512 сделать и убедить себя что
я никуда не спешу.

А ещё содержимое файла в meta4ra передаётся теперь через stdin, что
автоматом позволяет красивый прогресс хэширования через pv отображать
(c1fbe2c15a0e2c6475ca508b04c91e8ca9ce8e6a).