From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 21 Mar 2004 22:44:11 +0200 From: Michael Shigorin To: Dmitry Shubin , community@altlinux.ru Message-ID: <20040321204411.GL21509@osdn.org.ua> Mail-Followup-To: Dmitry Shubin , community@altlinux.ru, security@altlinux.ru, org@altlinux.ru References: <992347776.20040319143021@comita.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3NJww9yp20AXRsxZ" Content-Disposition: inline In-Reply-To: <992347776.20040319143021@comita.spb.ru> User-Agent: Mutt/1.4.1i Cc: security@altlinux.ru, org@altlinux.ru Subject: [Comm] [POLICY] Re: =?koi8-r?b?18/Q0s/TINDPIM/Czs/XzMXOydHNLi4u?= X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2004 20:44:13 -0000 Archived-At: List-Archive: List-Post: --3NJww9yp20AXRsxZ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Здравствуйте. Две части; сперва в осн. организационная, далее -- техн[олог]ическая. Нет, еще дорисовалась бизнес-часть. --- org On Fri, Mar 19, 2004 at 02:30:21PM +0300, Dmitry Shubin wrote: > Мы планируем использовать Alt Linux на серверах взамен > почившего RH, потому стабильность и целостность системы после > апдейта для нас очень критична, в связи с чем возник такой > вопрос - поддерживаются ли security updates всех rpm продуктов > входящих в состав релиза Master 2.2? Хороший вопрос. С одной стороны -- да, поддерживаются и обычно неплохо. Вплоть до выхода в числе первых часов публикации или обнаружения проблемы. Недостатков есть два: - дырка, которая уже заткнута -- обычно не анонсируется как таковая (что было бы бесполезно по сути, но успокаивающе) -- это в смысле "заткнуто два года назад", а не "только что"; - _гарантированного_ времени отклика и _гарантированного_ качества обновлений нет. По последнему пункту -- поймите меня правильно, я участвую в команде, собираю сейчас эти самые apache и mod_ssl -- хотя в продакшне mod_ssl у меня сейчас нет, по каковой причине security@ и не было оперативно додавлено. Я крайне заинтересован в оперативности и качестве этих самых обновлений и как менеджер компании-партнера Альт Линукс, и как (все еще) hostmaster@ ряда систем, на которых по несколькилетнему опыту эти самые обновления прикладываются автоматически. Поэтому с одной стороны -- можно кивать на Debian с его весьма неплохой sec team, но все же негарантированными по времени обновлениями, можно -- на RH с исчезнувшими QA и поддержкой (и QA поддержки) публично доступных версий (просьба не доколупываться к формулировкам, все поняли)... но хочется-то "чтоб работало". Персонально мое мнение -- даже текущая политика (выпуск в т.ч. обновлений с увеличением версии) есть good enough, по крайней мере мне найти свои грабли (не поднявшийся mysql) удалось однажды за где-то три года, и то они были вычислены чуточку заранее из анонса и автомат был продублирован наблюдением. Что не значит, что нечего менять к лучшему. Здесь, полагаю, предложения и пожелания -- принимаются. Желательно -- с пониманием того, что ресурсы более чем реально ограничены и едва ли не единственный (но возможный) способ получить _гарантированные_ по срокам _и_ качеству обновления -- это заключить контракт на поддержку. --- tech > Вы скажете - бери отсюда mod_ssl-2.8.16-alt1.src.rpm Это крайний случай. Да, оно сработает. Но это все равно слишком плохо. > "У нас нет секретных патчей и закрытого тестирования с > подписками о не разглашении: то, что мы сделали сегодня, -- > завтра вы найдёте в сети." - цитата из описания Sisyphus. Это другое. > Но вот вопрос, продукты выложенные в Sisyphus прошли тестирование? Какое-то -- обычно да. Автоматическое (зависимости, библиотеки, неконфликтность с базовой системой) -- обязательно; "человеческое" -- в зависимости от продукта, майнтейнера, активности сообщества пользователей именно этого продукта. Понятное дело, что QA апстрима идет отдельной строкой, и различные проекты по этой части различаются тоже очень сильно. > Как-нибудь отмечаются продукты прошедшие и не прошедшие тестирование? Косвенно -- количеством открытых отчетов в Bugzilla. Автоматическое (см. sisyphus_check из пакета sisyphus, если интересно) -- все, которые попали в "свежий сизиф". Ручное -- скорее в обратном порядке: пакеты (сборки), в которых майнтейнер не вполне уверен, обычно "специальнее" анонсируются в списке рассылки sisyphus@. > Просто не хотелось бы после очередного апдейта словить > неоттестированный не работающий патч, и через неско часов его > патчить заново.. Нет, с апдейтами как раз все довольно неплохо. Вот только не стоит путать с ними Sisyphus. --- biz Если для компании альт приемлем как технологическая платформа практически всем, кроме недостаточной предсказуемости _небольшой_ части обновлений -- может иметь смысл рассмотреть три варианта: - держать на системах, где в силу host policy обновления могут не производиться вообще (крайний случай, малоосмыслен); - содержать в штате специалистов, которые занимаются проблемами безопасности и, в частности, при задержке обновления из официального источника и остроте проблемы способны создать, протестировать и опубликовать в корпоративном репозитории обновлений "фирменный" вариант (боюсь, применимо и в случае Debian -- см. письмо рядом); - подписать контракт, указав в SLA: - требуемый состав пакетной базы, которая поддерживается в обязательном порядке; - сроки, в течение которых становятся доступными проверенные обновления для всех или различных категорий проблем безопасности (e.g. local root, remote code exec, info leak); - срок, в течение которого выпускаются обновления для заданного stable. Есть промежуточный между двумя последними вариант -- содержать специалистов, сотрудничающих с alt sec team -- но это может быть оправданно для ИТ-фирмы и я бы не рекомендовал закладываться на такой вариант "нормальной" компании в силу слишком большого количества звеньев в цепочке. -- Michael Shigorin EMT.Com.UA --3NJww9yp20AXRsxZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAXf6bbsPDprYMm3IRAq/YAKDJmEHMxB424wZbriU1R0oOjYVtIQCfaYcX j3Eh6J2L0LC/WdjlFOobR5s= =OVDa -----END PGP SIGNATURE----- --3NJww9yp20AXRsxZ--