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

["Victor B. Wagner" <vitus@altlinux.org>]

On 2009.05.05 at 14:46:26 +0400, Evgeny Sinelnikov wrote:

>    4 мая 2009 г. 19:00 пользователь Victor B. Wagner <[1]vitus@altlinux.org>
>    написал:
>    [...]
>       В Alt зачем-то openssldir указывает в /var. При этом конфигурационный
>       файл, как и положено, лежит в /etc, engines посредством более менее
>       глубокого хака в исходниках перетащены в /usr/lib, каталог
>       сертификатов пустой, даже при установленном пакете ca-certificates,
>       а вот скрипты - остались. Исполняемые файлы радостно инсталлируются в
>       /var. Зачем?
> 
>    Видимо, для следования FHS. Настройки кладутся в /etc, данные - в /var.

По-моему, FHS ни разу не одобряет исполняемых файлов в /var.
Опять же, пакет ca-certificates ставит свои данные в /usr/share.


>    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

Вот это самое misc, оно на самом деле такое bin. И в var ему не место.
Хотя по хорошему счету ему место в /usr/share/doc/<something>/examples

>    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/ обычная свалка, как везде... А,

Похоже, что наиболее правильным с точки зрения FHS будет держать
openssldir в /etc Раз уж engines оттуда совсем оторвали.

Каталоги private и сerts сделать линками в /var/lib/ssl, а openssl.cnf
пусть прямо там лежит. 

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

А вот теперь начнется. Потому что в файл openssl.cnf прописываются
подключенные engines. У старого openssl gost engine нету, а у нового -
есть.

Кстати, да. Каталог хешированных сертификатов между openssl 0.9.x и
openssl 1.0 несовместим. Они там алгоритм хэширования поменяли.
Так что, видимо, openssldir для 0.9.8 и 1.0 придется разносить.


 
>    отсутствие engines определимо и, на этапе загрузки, будет выглядеть как

Между "определимо" и "аккуратно обрабатывается конкретным приложением"
есть некоторая разница.

Впрочем функция OPENSSL_config вообще void и ничего вышележащему
приложению не рассказывает. Так что по идее приложению, которое честно
инициализирует  OpenSSL последовательностью 
OPENSSL_config(NULL)
SSL_library_init()
SSL_load_error_strings()
ничего не грозит.

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

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

Честно сказать не в курсе. После 0.9.8f от перехода на которую мы
отказались с в связи с большим объемом работы и сосредоточили все усилия
на 1.0 (тогда 0.9.9) я за веткой 0.9.8 не особенно следил.

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

Предлагаю 10. Тогда и заодно и сразу будет видно, что это 1.0.
Может, конечно, мы и промахнемся и когда fedora решит переходить на 1.0
они туда поставят 9. Но очевидно, что уже не 8.

Или можно оставить как в upstream - 1.0.0