From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Date: Tue, 5 May 2009 18:11:13 +0400 From: "Victor B. Wagner" To: devel@lists.altlinux.org Message-ID: <20090505141113.GB14733@cryptocom.ru> Mail-Followup-To: devel@lists.altlinux.org References: <20090504152716.GD6444@altlinux.org> <6062a6e60905041044pd43de21k572c732eae5bbd2a@mail.gmail.com> <20090505083918.GE2101@cryptocom.ru> <6062a6e60905050243u4642085ap7abe66a302b1d96e@mail.gmail.com> <20090505103649.GH2101@cryptocom.ru> <6062a6e60905050447r365ac6c7kd318102ad453c9f8@mail.gmail.com> <20090505121608.GB11802@cryptocom.ru> <6062a6e60905050544g48d6761bm167589e68b321a97@mail.gmail.com> <20090505125756.GA13858@cryptocom.ru> <6062a6e60905050626t7da74aakb56db74e4763b1a2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6062a6e60905050626t7da74aakb56db74e4763b1a2@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [devel] =?koi8-r?b?98/Q0s/T2SDOz9fJ3svB?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 14:11:30 -0000 Archived-At: List-Archive: List-Post: On 2009.05.05 at 16:26:09 +0300, Alexander Bokovoy wrote: > "Список, сестра!". Возвращаемся к тому же вопросу -- нужен список > задач/сценариев, которые можно приоритезировать и определить > необходимые шаги. Если тебе интересна серверная сторона, составь такой > список для серверной стороны. Лично у меня план действий такой: 1. Запакетировать openssl-1.0. С тем чтобы она максимально соответстовала текущей полиси дистрибутива и перевод приложений на неё был возможно более безболезненным. Собственно, все вопросы которые я здесь задаю, относятся к этому первому пункту. Сейчас, в связи с этим первым пунктом уже возникли вопросы, из которых, возможно выкристаллизуются какие-то следующие пункты. Это - пакет ca-certificates, который надо обвесить какими-то утилитами для поддержки в актуальном (для пользователя) состоянии списка сертификатов, актуализации crl-ей и интероперабельности с другими библиотеками, дабы добро зря не пропадало. - пакет cert-sh-functions, который в данный момент направляет пользователя по кривой дорожке создания небезопасных сертификатов. С реализацией этих пунктов можно пока не торопиться. 2. Взаимодействие с мейнтейнерами тех приложений, которые вот прямо сейчас могут получить расширение функциональности от перехода на openssl-1.0, возможно, с применением каких-то патчей. Расширение функциональности - это не обязательно поддержка новых (российских) крипоалгоритмов. В OpenSSL 1.0 и другие вкусонсти есть, вроде tls-extensions (которые частично бэкпортированы в 0.9.8f и выше) или более полной поддержки CMS. 3. Все остальное, что может способствовать более правильному использованию криптографии в рамках дистрибутива. В том числе и те, выявившиеся в рамках дискуссии выше пункта. Есть одно но - в какой-то, не очень далекий момент времени (порядка пары месяцев) нужно будет зафиксировать бинарники libcrypto и libssl от OpenSSL 1.0. Все изменения, внесенные в них после этого момента будут недоступны для желающих использовать СЕРТИФИЦИРОВАННУЮ российскую криптографию. То есть в принципе, дистрибутив может включать и какие-то более новые обновления и модификации. Но если потом на этот дистрибутив поставить сертифицированный криптографический продукт, сделанный на базе OpenSSL 1.0, он принесет с собой зафиксированные на момент сертификации бинарники. То есть, мы, конечно будем пытаться вывести libcrypto и libssl из числа сертифицированных бинарников, но не факт, что получится.