[devel] Упаковка openssl (was: Вопросы новичка)

[Evgeny Sinelnikov]

4 мая 2009 г. 19:00 пользователь Victor B. Wagner <vitus at altlinux.org>написал:
[...]

> Теперь вопросы по собственно 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. Зачем?
>

Видимо, для следования FHS. Настройки кладутся в /etc, данные - в /var.
Вроде бы логично, может быть стоит уточнить... Сейчас это уже legacy. Его
стоит иметь в виду... ;)

Вообще там всё не так просто:
$ ls /var/lib/ssl/ -l
итого 12
lrwxrwxrwx 1 root root   48 Мар 30 12:56 cert.pem ->
../../../usr/share/ca-certificates/ca-bundle.crt
drwxr-xr-x 2 root root 4096 Мар 30 12:56 certs
drwxr-xr-x 2 root root 4096 Мар 30 12:56 misc
lrwxrwxrwx 1 root root   32 Мар 30 12:56 openssl.cnf ->
../../../etc/openssl/openssl.cnf
drwx------ 2 root root 4096 Мар 27 20:35 private

Но, в целом, идея проста - в /var/lib/ssl/ обычная свалка, как везде... А,
что можно, разложено по полочкам... Насколько это не удобно и что нужно
сделать, чтобы стало удобно давайте подумаем...

Кстати, здесь же стоит отметить, что файл настроек
/etc/openssl/openssl.cnf

Упакован, опять-таки по старому legacy (ибо я не придумал, как должно и
сделал как было), в два пакета libssl7 и libssl6, а ранее и в третьем
libssl4... По счастливому набору обстоятельств файлы идентичны и проблемы
вроде как не видно... Но тут, тоже стоит что-нибудь решить.


>
> 3. Библиотеки libcrypto и libssl помещены в /lib.
>   То есть надо полагать, что в дистрибутиве, близко к базовой системе
>   существуют приложения, которые используют эти библиотеки до
>   монтирования /usr. То что там есть какие-то другие библиотеки,
>   которые зависят от openssl, вопрос, конечно интересный, но меня
>   интересует как зовут тот процесс в который все это хозяйство может
>   быть подгружено до монтирования /usr. А также - читает ли этот
>   процесс конфигурационный файл openssl.cnf (благо тот в /etc, хотя на
>   первый взгляд дотягиваться до него процесс будет через симлинк в
>   /var, но это можно и поправить), и как он отнесется к тому, что в
>   этом файле будут упомянуты engines, лежащие в еще не смонтированном
>   /usr.
>

отсутствие engines определимо и, на этапе загрузки, будет выглядеть как
отсутствие этих дополнений. Не думаю, что здесь могут быть проблемы... Среди
компонент же использующих openssl на ранних этапах загрузки, например, чтобы
списки сетевых пользователей получить, эти дополнения пока вряд ли
понадобятся...


>
> 4. Зачем-то у libcrypto SONAME libcrypto.so.6 (и у libssl - libssl.so.6).
>   Понятно, что любовью к
>   переопределению soname отличается не только alt. Но только в alt
>   ставится файл libssl.so.0.9.8g, на который делается симлинк
>   libssl.so.6. Существует ли где-нибудь внятное описание этой политики
>   именования разделяемых библиотек?
>


Опять-таки некое legacy. Чтобы можно было отличить в установленной системе
so.0.9.8h от so.0.9.8k. А то они у нас оба so.7, а вот, как я сегодня
выяснил, в fedora so.0.9.8k уже so.8... Думаю это проблема, хотя и
потенциальная...

На практике это не позволяет устанавливать пропиетарные сборки для новой
федоры, правда так уже и питон новый требуется... так что это ещё не всё,
что нужно...

Смена soname у них прошла ещё в январе:
* Thu Jan 15 2009 Tomas Mraz <tmraz at redhat.com> 0.9.8j-1
- new upstream version with necessary soname bump (#455753)

Я тогда не увидел особых изменений в ABI, но, видимо, они перестраховались,
а может я что-то пропустил...

Сейчас есть два варианта выхода:
1) добавить симлинк so.8 в новой сборке openssl и сделать из неё libssl8,
оcтавив so.7 в ней же самой
2) сделать новую сборку с libssl8 на основе текущей + compat libssl7
откатить до федориного состояния 0.9.8h

Первый вариант мне кажется более оптимальным.

Да, кстати, стоит подумать какой soname будет у openssl-1.0.0 ...


-- 
Sin (Sinelnikov Evgeny)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090505/8bbbd826/attachment-0001.html>