40635 2021-08-02 16:55:19 +0300 Move from md5 to strong hash for apt 2023-06-22 14:11:42 +0300 1 1 4 Development Sisyphus apt unstable x86_64 Linux CLOSED FIXED P5 major --- 40561 46625 40646 40647 1 vt placeholder aen alexey.tourbin boyarsh danil glebfm imz ldv mike placeholder rider vt qa-sisyphus oldest_to_newest 201154 0 vt 2021-08-02 16:55:19 +0300 Необходима поддержка актуальных хешей в apt. Это хеши, используемые в файлах base/release и pkglist.*. 201179 1 mike 2021-08-03 13:29:04 +0300 А кому и зачем именно необходима? Насколько понимаю, md5 там не как криптографический стойкий, а "на всякий". Потому как важное сверху подписано. Нет? 201180 2 alexey.tourbin 2021-08-03 13:53:07 +0300 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. 201183 3 mike 2021-08-03 14:47:14 +0300 Лёш, спасибо за разъяснение (хотя лучше бы человеческим языком). 201196 4 glebfm 2021-08-04 00:50:39 +0300 Не знаю какие тут нужны подробности. Главное -- сейчас apt во всех местах, где он проверяет хеш, просто сравнивает строки, а придётся, видимо, разумным образом сравнивать наборы хешей, которые окажутся доступны на той или иной ситуации. После решения этой задачи добавление новых хешей (если вдруг такое понадобится) скорее всего станет не такой уж сложной задачей. Понадобится поддержка новых хешей в apt-repo-tools, а он в качестве реализации md5 исользует библиотеку libapt, думаю, что будет проще всего так делать и дальше, т.е. этот интерфейс в libapt понадобится раньше всего. 201198 5 aen 2021-08-04 01:28:36 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #4) > Не знаю какие тут нужны подробности. > > Главное -- сейчас apt во всех местах, где он проверяет хеш, просто > сравнивает строки, а придётся, видимо, разумным образом сравнивать наборы > хешей, которые окажутся доступны на той или иной ситуации. После решения > этой задачи добавление новых хешей (если вдруг такое понадобится) скорее > всего станет не такой уж сложной задачей. > Понадобится поддержка новых хешей в apt-repo-tools, а он в качестве > реализации md5 исользует библиотеку libapt, думаю, что будет проще всего так > делать и дальше, т.е. этот интерфейс в libapt понадобится раньше всего. Какие задачи (конкретно) надо решить строго до релиза p10? 203345 6 rider 2021-09-29 15:18:52 +0300 А зачем Severity так задрали ? На мой взляд не соответствует policy. https://www.altlinux.org/Bug_Severity_Policy 203406 7 ldv 2021-09-30 19:56:57 +0300 (In reply to Anton Farygin from comment #6) > А зачем Severity так задрали ? Важно не то, какой тут severity, а то, что это является необходимым условием для выпуска релизов на p10. По этой причиние оно блокирует #40561. 203407 8 rider 2021-09-30 20:16:56 +0300 тогда предлагаю выровнять в соответствии с policy. Блокер для #40651 - это про другое. 204148 9 rider 2021-10-26 15:55:42 +0300 Добавлю, что md5 ещё используется в новой структуре базы данных для packages.altlinux.org для ускорения загрузки пакетов в базу (мы читаем хеши md5 из индексов apt и пишем их в базу). Нам тоже понадобится внести изменения, и хотелось бы заранее понимать какие. И что будет с совместимостью со старыми индексами. 204158 10 rider 2021-10-26 20:29:53 +0300 а чем плоха наравне с уже существующим нестойким md5 проверка криптографически-стойкой подписи gpg у пакета ? 205032 11 ldv 2021-11-18 21:30:21 +0300 Кто забыл закрыть баг? 205033 12 ldv 2021-11-18 21:36:53 +0300 (In reply to Anton Farygin from comment #10) > а чем плоха наравне с уже существующим нестойким md5 проверка > криптографически-стойкой подписи gpg у пакета ? Ответ на этот вопрос был сформулирован в этой же баге, см. comment #2. 205044 13 rider 2021-11-19 08:18:47 +0300 (Ответ для 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. 205112 14 vt 2021-11-19 18:31:29 +0300 (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. 228221 15 glebfm 2023-06-22 14:11:42 +0300 (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@). [...]