Bug 40635

Summary: Move from md5 to strong hash for apt
Product: Sisyphus Reporter: Vitaly Chikunov <vt>
Component: aptAssignee: placeholder <placeholder>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: major    
Priority: P5 CC: aen, alexey.tourbin, boyarsh, danil, glebfm, imz, ldv, mike, placeholder, rider
Version: unstable   
Hardware: x86_64   
OS: Linux   
Bug Depends on:    
Bug Blocks: 40561, 46625, 40646, 40647    

Description Vitaly Chikunov 2021-08-02 16:55:19 MSK
Необходима поддержка актуальных хешей в apt.
Это хеши, используемые в файлах base/release и pkglist.*.
Comment 1 Michael Shigorin 2021-08-03 13:29:04 MSK
А кому и зачем именно необходима?
Насколько понимаю, md5 там не как криптографический стойкий, а "на всякий".
Потому как важное сверху подписано.
Нет?
Comment 2 alexey.tourbin 2021-08-03 13:53:07 MSK
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.
Comment 3 Michael Shigorin 2021-08-03 14:47:14 MSK
Лёш, спасибо за разъяснение (хотя лучше бы человеческим языком).
Comment 4 Gleb F-Malinovskiy 2021-08-04 00:50:39 MSK
Не знаю какие тут нужны подробности.

Главное -- сейчас apt во всех местах, где он проверяет хеш, просто сравнивает строки, а придётся, видимо, разумным образом сравнивать наборы хешей, которые окажутся доступны на той или иной ситуации.  После решения этой задачи добавление новых хешей (если вдруг такое понадобится) скорее всего станет не такой уж сложной задачей.
Понадобится поддержка новых хешей в apt-repo-tools, а он в качестве реализации md5 исользует библиотеку libapt, думаю, что будет проще всего так делать и дальше, т.е. этот интерфейс в libapt понадобится раньше всего.
Comment 5 AEN 2021-08-04 01:28:36 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #4)
> Не знаю какие тут нужны подробности.
> 
> Главное -- сейчас apt во всех местах, где он проверяет хеш, просто
> сравнивает строки, а придётся, видимо, разумным образом сравнивать наборы
> хешей, которые окажутся доступны на той или иной ситуации.  После решения
> этой задачи добавление новых хешей (если вдруг такое понадобится) скорее
> всего станет не такой уж сложной задачей.
> Понадобится поддержка новых хешей в apt-repo-tools, а он в качестве
> реализации md5 исользует библиотеку libapt, думаю, что будет проще всего так
> делать и дальше, т.е. этот интерфейс в libapt понадобится раньше всего.


Какие задачи (конкретно) надо решить строго до релиза p10?
Comment 6 Anton Farygin 2021-09-29 15:18:52 MSK
А зачем Severity так задрали ?

На мой взляд не соответствует policy.
https://www.altlinux.org/Bug_Severity_Policy
Comment 7 Dmitry V. Levin 2021-09-30 19:56:57 MSK
(In reply to Anton Farygin from comment #6)
> А зачем Severity так задрали ?

Важно не то, какой тут severity, а то, что это является необходимым условием для выпуска релизов на p10.  По этой причиние оно блокирует #40561.
Comment 8 Anton Farygin 2021-09-30 20:16:56 MSK
тогда предлагаю выровнять в соответствии с policy.

Блокер для #40651 - это про другое.
Comment 9 Anton Farygin 2021-10-26 15:55:42 MSK
Добавлю, что md5 ещё используется в новой структуре базы данных для packages.altlinux.org для ускорения загрузки пакетов в базу (мы читаем хеши md5 из индексов apt и пишем их в базу).

Нам тоже понадобится внести изменения, и хотелось бы заранее понимать какие.

И что будет с совместимостью со старыми индексами.
Comment 10 Anton Farygin 2021-10-26 20:29:53 MSK
а чем плоха наравне с  уже существующим нестойким md5 проверка криптографически-стойкой подписи gpg у пакета ?
Comment 11 Dmitry V. Levin 2021-11-18 21:30:21 MSK
Кто забыл закрыть баг?
Comment 12 Dmitry V. Levin 2021-11-18 21:36:53 MSK
(In reply to Anton Farygin from comment #10)
> а чем плоха наравне с  уже существующим нестойким md5 проверка
> криптографически-стойкой подписи gpg у пакета ?

Ответ на этот вопрос был сформулирован в этой же баге, см. comment #2.
Comment 13 Anton Farygin 2021-11-19 08:18:47 MSK
(Ответ для 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.
Comment 14 Vitaly Chikunov 2021-11-19 18:31:29 MSK
(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.
Comment 15 Gleb F-Malinovskiy 2023-06-22 14:11:42 MSK
(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@).
[...]