Необходима поддержка актуальных хешей в apt. Это хеши, используемые в файлах base/release и pkglist.*.
А кому и зачем именно необходима? Насколько понимаю, md5 там не как криптографический стойкий, а "на всякий". Потому как важное сверху подписано. Нет?
Mike, if you want the top-level signature in the release file to cover the whole repo reliably, the references must be cryptographically strong. E.g. the release file references pkglist. If the reference is cryptographically strong, you don't need a separate GPG signature for pkglist. The validity of the original signature in the release file gets "transferred" to pkglist. But if the reference in the release file is MD5, you can modify pkglist in a way that preserves its MD5. The situation can be described as "strong signature transferred via weak reference". After you've followed such a reference, you no longer have the guarantee provided by the signature.
Лёш, спасибо за разъяснение (хотя лучше бы человеческим языком).
Не знаю какие тут нужны подробности. Главное -- сейчас apt во всех местах, где он проверяет хеш, просто сравнивает строки, а придётся, видимо, разумным образом сравнивать наборы хешей, которые окажутся доступны на той или иной ситуации. После решения этой задачи добавление новых хешей (если вдруг такое понадобится) скорее всего станет не такой уж сложной задачей. Понадобится поддержка новых хешей в apt-repo-tools, а он в качестве реализации md5 исользует библиотеку libapt, думаю, что будет проще всего так делать и дальше, т.е. этот интерфейс в libapt понадобится раньше всего.
(Ответ для Gleb F-Malinovskiy на комментарий #4) > Не знаю какие тут нужны подробности. > > Главное -- сейчас apt во всех местах, где он проверяет хеш, просто > сравнивает строки, а придётся, видимо, разумным образом сравнивать наборы > хешей, которые окажутся доступны на той или иной ситуации. После решения > этой задачи добавление новых хешей (если вдруг такое понадобится) скорее > всего станет не такой уж сложной задачей. > Понадобится поддержка новых хешей в apt-repo-tools, а он в качестве > реализации md5 исользует библиотеку libapt, думаю, что будет проще всего так > делать и дальше, т.е. этот интерфейс в libapt понадобится раньше всего. Какие задачи (конкретно) надо решить строго до релиза p10?
А зачем Severity так задрали ? На мой взляд не соответствует policy. https://www.altlinux.org/Bug_Severity_Policy
(In reply to Anton Farygin from comment #6) > А зачем Severity так задрали ? Важно не то, какой тут severity, а то, что это является необходимым условием для выпуска релизов на p10. По этой причиние оно блокирует #40561.
тогда предлагаю выровнять в соответствии с policy. Блокер для #40651 - это про другое.
Добавлю, что md5 ещё используется в новой структуре базы данных для packages.altlinux.org для ускорения загрузки пакетов в базу (мы читаем хеши md5 из индексов apt и пишем их в базу). Нам тоже понадобится внести изменения, и хотелось бы заранее понимать какие. И что будет с совместимостью со старыми индексами.
а чем плоха наравне с уже существующим нестойким md5 проверка криптографически-стойкой подписи gpg у пакета ?
Кто забыл закрыть баг?
(In reply to Anton Farygin from comment #10) > а чем плоха наравне с уже существующим нестойким md5 проверка > криптографически-стойкой подписи gpg у пакета ? Ответ на этот вопрос был сформулирован в этой же баге, см. comment #2.
(Ответ для Dmitry V. Levin на комментарий #12) > (In reply to Anton Farygin from comment #10) > > а чем плоха наравне с уже существующим нестойким md5 проверка > > криптографически-стойкой подписи gpg у пакета ? > > Ответ на этот вопрос был сформулирован в этой же баге, см. comment #2. Нет, это было про pkglist'ы и с ними как раз всё понятно Я же говорю про gpg подпись пакета (header + payload), которая тоже вполне себе хеш, криптографически стойкий. Впрочем, сейчас это обсуждать уже бесмысленно - везде где надо добавлен blake2b и скоро у нас будет возможность вот тут: https://beta.packages.altlinux.org/ru/sisyphus/srpms/kernel-image-drm-tip/rpms/17137739051416841711 Вместо md5 показать blake2b для всех пакетов из архива. А вот если бы вы помимо blake2b добавили в хеши какой-то packageID, который можно было бы легко подсчитать из rpmdb установленной системы - это было бы очень полезно. SHA1HEADER для этого не подходит, т.к. он не покрывает gpg подпись пакета и payload. А blake2b естественно не считается из rpmheader. Но это уже другой FR.
(In reply to Anton Farygin from comment #13) > Я же говорю про gpg подпись пакета (header + payload), которая тоже вполне себе хеш, криптографически стойкий. Это было исправлено для Сизифа 23 августа 2021, пакеты, подписанные до этого момента, остались DSA/SHA1, после RSA/SHA512. > А вот если бы вы помимо blake2b добавили в хеши какой-то packageID, который > можно было бы легко подсчитать из rpmdb установленной системы - это было бы s/подсчитать/прочитать/ ? > очень полезно. SHA1HEADER для этого не подходит, т.к. он не покрывает gpg > подпись пакета и payload. А blake2b естественно не считается из rpmheader.
(In reply to Dmitry V. Levin from comment #11) > Кто забыл закрыть баг? Похоже на то. * Fri Oct 29 2021 Ivan Zakharyaschev <imz@altlinux.org> 0.5.15lorg2-alt73 [...] - Added blake2b hash support (thx glebfm@). [...]
