Что: 3a1f5e5f8e1280737b635fd50e3a30e501963a7f Когда: 2024-03-09 12:46:00+03:00 ------------------------------------------------------------------------ Темы: go ------------------------------------------------------------------------ Доработки meta4ra http://www.meta4ra.stargrave.org/ Я стал что-то типа .meta4 fanboy-ем. В системе сборки BASS (прежде это называлось zwoki, 7e1dbd0539c7ea5c6bd5e8831abeea4796da693e, а теперь Build Automation Simple System) всё качается через Metalink4 файлы. Ибо и контрольные суммы и несколько ссылок и подписи удобно лежат в одном файле. В пакетах я хранил только BLAKE3 контрольную сумму. Но для РФ зачастую любой хэш отличный от Стрибога -- будет как-бы несуществующим. Использовать его вместо BLAKE3 -- слишком медленно. Снова получается, что нужно хранить несколько хэшей для файлов внутри пакетов. Есть у меня места, где нужны хэши, но пофиг какие -- просто например для сравнения файлов между собой. Был hardcode b3sum, но, опять же, в той же Astra Linux, из коробки этой утилиты нет, а дополнительные зависимости это всегда когнитивная нагрузка на человека. b3sum можно собрать в пределах системы сборки и установить этот пакет. Но проблема курицы и яйца: для создания пакета, уже нужен b3sum хэш, а чтобы его получить -- надо собрать пакет. Такое уже было с ZStandard сжатием, но там я просто для некоторых пакетов форсировал использование "gzip"-а. libarchive-based bsdtar автоматически может понимать какой декомпрессор надо запускать. Вот такое же хотелось бы и для хэшей. meta4ra-check утилита на самом деле уже так и делает: находит первый общий хэш и его и проверяет. Нет b3sum -- будет fallback до чего-то другого имеющегося. Когда появится после установки пакета -- будет использован в приоритете. Пришлось в meta4ra-check добавить -stdin опцию, чтобы можно было данные единичного файла проверять через stdin. Добавил -all-hashes опцию, которая форсирует проверку всех хэшей .meta4 файла, просто чтобы убедиться что всё в нём корректно рассчитано и не бито. Добавил meta4ra-hash утилиту, которая через stdin/stdout считает первый хэш указанный в -hashes -- как-раз тот самый случай, когда нужен любой хэш, желательно более приоритетный. meta4ra использовала внешние утилиты для расчёта хэшей. Сама Go программа использовалась только для работы с XML и распараллеленным запуском команд хэшей. Список команд задаётся через -hashes, где через запятую перечисляются "name:cmdline" пары, указывающие название хэша (которое будет в XML) и командную строку для запуска. Точнее прежде был запуск только единичной команды, а теперь это строчка передающаяся в "/bin/sh -e -c", поэтому можно использовать и конвейеры. Но на разных ОС доступны разные команды. Заставлять человека тщательно формировать довольно длинную строчку описывающую что надо запускать -- геморройно. Написал поэтому meta4ra-hashes-detect утилитку, которая просто перебирает hard-coded известные (мне) команды для расчёта того или иного хэша, проверяя их работу напротив hard-coded хэша от "hello world". Теперь можно любую команду запускать типа: meta4ra-check -hashes "`meta4ra-hashes-detect`" ... Когда-то сам meta4ra считал хэши. Но реализации в Go не всегда удовлетворительно быстрые. Поэтому я и стал использовать внешние команды. Однако, если на скорость пофиг и хочется хоть как-то посчитать, например при создании установочных пакетов? А потом уже использовать появившуюся быструю b3sum/Skein/Стрибог/whatever? Решил поэтому вернуть возможность использования, так называемых, builtin хэшей, но компилируя их опционально. Если просто собрать meta4ra "go build"-ом, то будут использованы только родные библиотеки, где только sha256/sha512. Если указать "tags thirdparty", то будет использована масса дополнительных библиотек для кучи остальных хэшей. vendor-ized tarball все их содержит. Для использования builtin реализации надо указать "builtin" в качестве cmdline строчки. Ради Python пакетов, которые теперь на PyPI по умолчанию хэшируются BLAKE2b, добавил BLAKE2b. Всё же он очень распространён. А BLAKE2s только внутри протоколах, как правило, используется. Его не стал. Однако, PyPI использует не просто BLAKE2b, а BLAKE2b-256, хэш которого не просто обрезанный полный 512-бит. Поэтому добавил ещё и BLAKE2b-256. Оказалось, что b2sum утилита также входит и в GNU Coreutils (но это не та, что официально поставляется авторами BLAKE2, но "-l" аргумент работает одинаково у них обеих). BLAKE2b-256 на PyPI встречается в URL-е для скачивания пакета. Убрал Skein-256, смысла в котором и нет. Авторы Skein рекомендуют ориентироваться на Skein-512. Ну и github.com/dchest/skein библиотека только его и поддерживает (реализации dchest-а доверяю). Ну и Skein-512 на 64-бит системах ощутимо быстрее работает. Добавил XXH3-128 (dffa894abeab4eaec509b95af9d23b51e4e0f844). Ну just-for-fun. С другой стороны, для проверки целостности его 128-бит значение вполне себе годно, если модель угроз не включает в себя злоумышленника, а только ошибки канала связи. Go реализация XXH3 тоже очень быстра. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%94%D0%BE%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8%20meta4ra%20%283a1f5e5f8e1280737b635fd50e3a30e501963a7f%29 ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0