[devel] ACL in branches

Ср Мар 4 08:41:12 MSK 2009

Здравствуйте,

3 марта 2009 г. 22:08 пользователь Dmitriy M. Maslennikov
<maslennikovdm at gmail.com> написал:
> 3 марта 2009 г. 21:47 пользователь Alexey Tourbin <at at altlinux.ru> написал:
>> Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
>> всё отвалилось.  При том, что вроде бы ничего специфического у них не
>> обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
>> существовала специфическая build-time комбинация потенциально влияющих
>> компонентов; а в момент запуска существует уже иная специфическая
>> runtime комбинация влияющих компонентов?
> Следовательно те компоненты, которые портят работоспособность других
> после обновления не пройдут тестирование. Скажем так, если у меня есть
> работающий apache, а завтра вышло обновление openssl, которое его
> ломает, то вероятность, что за месяц это заметять и повесят баг на
> openssl довольно высока. В этом случае такое плохое обновление не
> должно попасть в стабильный бранч, что всем и надо. Сейчас же в бранч
> попадет, что угодно, лишь бы удовлетворяло довольно слабым (но тем не
> менее весьма полезным) проверкам, лишь бы не поломалась обновляемость.

Ну, я так понимаю, что всё дело в вероятностях... Вероятность того,
что одни и те же исходники будут собраны по разному в разных сборочных
средах есть, и, в частности, зависит от не явных, вычисляемых, опций
сборки. Тем не менее на заданном наборе сборочных сред, вероятность
получения багов определяется именно исходниками... Исходники, как
генетический код, ничего другого всё равно не получится :) Видимо этим
определяется некоторая повторяемость результатов в Gentoo ;)

> А у мне сервера не гарантированно обновлять надо, а надо, чтобы они
> работали. Вот и думай, что лучше - критическая уязвимость в openssl
> или никем не проверенное обновление, которое, спасибо конечно,
> гарантированно произойдет, но вот заработает ли то, что обновилось -
> это дело десятое, ведь математически работоспособность проверить
> нельзя, так и пытаться не стоит по вашем рассуждениям.
>

Кстати, раз уж зашло про стабильность, безопасность, уязвимости и
openssl... Пример, можно сказать, из жизни... В бранче 4.1 сейчас
лежит openssl-0.9.8d... У меня было и сохраняется желание получить в
нём поддержку kerberos. Но его там решено было оставить, как есть, ибо
вдруг его знает... не хочется ведь подставлять всех юзеров бранча... С
другой стороны, если бы лежала новая сборка рядом с бранчем в
отдельном репозитории, то в течении некоторого периода тестирования
можно было бы централизованно выявить возможные проблемы. А так
валяется он у меня такая сборка в RPMS.hasher и толку?

Далее, по мере использования, новой сборки у себя я никак не могу
аргументированно утверждать о том что эта сборка в полной мере
оттестирована, ибо кроме как на своих задачах, я эту сборку нигде не
проверял.

В плане же влияния сброчной среды я могу утверждать, что изменения в
бранче за полгода практически никакого влияния на качество бинарного
результата по вопросу сборки openssl+kerberos не повлияли... Из чего
следует противоположный вывод относительно целесообразности
тестирования отдельных дополнительных репозиториев, в случае
вероятностной оценки, по сравнению с аналитической. Поскольку
аналитика срезает разницу между существенными и не существенными
изменениями сборочной среды, для сборки заданного пакета, в заданный
период времени.

В плане же безопасности, я внёс в новые варианты своей сборки текущие
исправления, в частности CVE-2008-5077 и CVE-2007-4995, но передо мной
возникает ещё одна диллема... Вроде как два варианта (с исправлениями
с kerberos и исправлениями без kerberos) тестировать некогда, а
обновить сборку в бранче всё же стоит...
Вот ссылка на ветку libssl6:
http://git.altlinux.org/people/sin/packages/openssl.git?p=openssl.git;a=shortlog;h=refs/heads/libssl6

>> Вам кажется что если админы протестировали то это уже стопудово
>> как минимум на месяц или два?
> Если они будут тестировать все обновления, то навсегда.
>

Здесь я не согласен, по первых все обновления админами одинаково
оттестированы не будут, поэтому не навсегда... Админы, как тестеры,
вообще не удачный пример...

>> Мне тогда не понятно, что именно Вы хотите протестировать.

Хоть что-то, что по адекватным причинам сдерживает обновление пакета
или набора пакетов в бранчах или сизифе. Например, openssl с
поддержкой kerberos в бранче 4.1

> Что следующая партия пакетов, которая попадет в бранч ничего там не
> ломает, по крайней мере, что экстплуатация этого хозяйства на
> некритических станциях в течение некоторого времени проблем не
> выявила. Все-таки это лучше, чем ничего.
>

Примерно так, только не для любой сборки, а для адекватно, субъективно
критической, которая сейчас сдерживает обновить многие пакеты сразу
как в бранчах, так и сизифе.

>>> Постулат: установка и эксплуатация пакета в течение месяца на 50
>>> рабочих станциях гарантированно выявляет не меньше ошибок, чем все
>>> наши автоматические тесты. Кроме того, сочетание двух методик
>>> (автоматическое и ручное тестирование добровольцами) математически
>>> точно выявляет не меньше ошибок, чем одно только автоматическое
>>> тестирование.
>>
>> Тестируйте вручную, как я Вам сказал.

В одиночку это невозможно... Вы сами не примите результаты такого
тестирования, как достоверные. Можно устраивать для каждой задачи
тестирования отдельные условия, но хотелось бы некой стандартизации,
ибо задача типичная и регулярная... Групповые репозитории мне кажутся
удобным вариантом.

>> Лушче ничего не будет.
> Только один я протестировать все не могу. А тестировать всем
> сообществом не получается: пакеты попадают в основные репозитарии
> сразу после сборки. Сейчас пакеты тестироет только мантейнер у себя.
> Зачастую невнимательно и недолго. Некоторый отстойник для тестирования
> кандидатов на поступление в репозитарий был бы очень уместен. Кроме
> того, как уже писалось в эту рассылку это не портит вашей идеи о
> атомарной операции сборки-выкладывания пакета, если после тестовой
> сборки пакета сохранить его сборочную среду, а перед выкладыванием
> произвести пересборку и убедиться, что она не изменилась за время
> тестирования - иначе пересборка и повторное тестирование.
>

Примерно так... Мне кажется, что дело не столько в несознательности,
сколько в отсутствии инфраструктуры для совместного тестирования...
Одного Сизифа мне кажется, что уже мало... Когда возникает вопрос о
сборке обновления в сизиф, мэйнтейнер может оказать перед диллемой -
либо слать в сизиф полупроверенный вариант, либо пока подождать. В
результате мы можем получить и часто получаем пакеты полурабочие или
пока ещё старые...

-- 
Sin (Sinelnikov Evgeny)