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: Mon, 4 May 2009 19:00:25 +0400 From: "Victor B. Wagner" To: devel@lists.altlinux.org Message-ID: <20090504150025.GA1100@cryptocom.ru> Mail-Followup-To: devel@lists.altlinux.org MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.13 (2006-08-11) Subject: [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: Mon, 04 May 2009 15:00:35 -0000 Archived-At: List-Archive: List-Post: Я тут недавно, хотя, наверное многие из присуствующих меня знают давно. Присоединиться к разработке Alt я собрался с одной конкретной целью - сделать так, чтобы в дистрибутиве из коробки работала российская криптография, а переход на использование сертифицированной российской криптографии был бы совершенно безболезненен для пользователя/админа. Поэтому первая задача, которую я перед собой ставлю - сборка OpenSSL 1.0 beta последняя. В связи с этим у меня возник ряд вопросов по поводу того, почему OpenSSL запакетирван в Alt так, как это сделано. Первый вопрос вообще глобального плана и к OpenSSL отношения не имеет: 1. Почему в Alt у rpm нет ключа --import. У всех rpm-based дистрибутивов есть, а у Alt нет. Решать эту задачу - импортировать ключ стороннего репозитория в кейринг RPM предлагается посредством 1. посмотреть значение макроса %_gpg_path 2. Ручками запустить gpg --import выставив ему этот путь в качестве GPG_PATH Судя по спектру дистрибутивов в которых rpm умеет --import, эту фунциональность в Alt специально отрывали. Зачем? Теперь вопросы по собственно OpenSSL 2. У OpenSSL есть такой параметр openssldir . Задается при конфигурировании и в умолчательной сборке там ищутся 1. Конфигурационный файл 2. Сертификаты доверенных удостоверяющих центров (certification authority, CA) 3. Подгружаемые модули альтернативных реализаций криптоалгоритмов (engines). 4. Туда же при инсталляции складвывается ряд скриптов, которым вообще место где нибудь в /usr/share/doc/openssl/examples. В Alt зачем-то openssldir указывает в /var. При этом конфигурационный файл, как и положено, лежит в /etc, engines посредством более менее глубокого хака в исходниках перетащены в /usr/lib, каталог сертификатов пустой, даже при установленном пакете ca-certificates, а вот скрипты - остались. Исполняемые файлы радостно инсталлируются в /var. Зачем? 3. Библиотеки libcrypto и libssl помещены в /lib. То есть надо полагать, что в дистрибутиве, близко к базовой системе существуют приложения, которые используют эти библиотеки до монтирования /usr. То что там есть какие-то другие библиотеки, которые зависят от openssl, вопрос, конечно интересный, но меня интересует как зовут тот процесс в который все это хозяйство может быть подгружено до монтирования /usr. А также - читает ли этот процесс конфигурационный файл openssl.cnf (благо тот в /etc, хотя на первый взгляд дотягиваться до него процесс будет через симлинк в /var, но это можно и поправить), и как он отнесется к тому, что в этом файле будут упомянуты engines, лежащие в еще не смонтированном /usr. 4. Зачем-то у libcrypto SONAME libcrypto.so.6 (и у libssl - libssl.so.6). Понятно, что любовью к переопределению soname отличается не только alt. Но только в alt ставится файл libssl.so.0.9.8g, на который делается симлинк libssl.so.6. Существует ли где-нибудь внятное описание этой политики именования разделяемых библиотек? 5. Почему в пакете ca-certificates используется один большой файл с катенированными сертификатами? OpenSSL умеет работать как с таким файлом (загружая его в память целиком), так и с директорией где каждый сертификат и CRL лежит в отдельном файлике, кэшируя в памяти только те сертификаты, которые понадобились при выстраивании цепочки доверия. По этому вопросу интересно также мнение людей поддерживающих более другие криптобиблиотеки - libnss, libgcrypt - как эти библиотеки доступаются к trusted CA store (потому что очевидно, что пакет ca-certificates должен удовлетоврять потребности всех трех библиотек). Во всяком случае лично мне, когда потребовалось втащить сертификат альтовского удостоверяющего центра в свою мозиллу на более другом дистрибутиве, пришлось лезть текстовым редактором в этот самый ca-bundle.pem, искать там нужный сертификат, выгрызать его в отдельный файл и импортировать. Были бы отдельные файлики, да с интуитивно понятными названиями было бы проще. Аналога дебиановского update-cacertificates я тоже что-то не увидел. --- ----- End forwarded message -----