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

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

[Victor B. Wagner]

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

Re: [devel] Упаковка openssl

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

On Tue, May 05, 2009 at 03:31:10PM +0400, Victor B. Wagner wrote:
> 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.

Вряд ли этим исполняемым файлам место среди конфигов и сертификатов.
Очень похоже на legacy.  Пока не тронешь, не узнаешь, что сломается.

> Опять же, пакет ca-certificates ставит свои данные в /usr/share.

Если понадобится для монтирования /usr, то придётся перетаскивать в /lib.

> >    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

Согласен, содержимое /var/lib/ssl/misc/ тянет на %doc.
Если на него никто не завязан, конечно.

> >    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
> пусть прямо там лежит. 

Можно попробовать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Victor B. Wagner]

>    Ну, вот и мне как-то это странным не показалось... Хотя, если оно не
>    нужно, можно и в examples... Давайте уточним... Не означает ли это
>    действие, что, при необходимости, первое что придётся делать - это
>    копировать эти скрипты обратно...

Обратно - точно не придется. В /usr/bin положить - может и полезно
будет, и то вряд ли.

Что сама openssl их никогда не использует, и тем более не ищет в 
$OPENSSLDIR/misc - это могу гарантировать.

>    Они никому не нужны? Не хотелось бы иметь подобный ручной привод...

Из того, что ставится upstream-ом в misc кем-то используется только 
c_rehash. Но он уже ставится в /usr/bin.
Может быть было бы полезным использовать CA.pl/CA.sh (последний в Alt
ставится в misc под именем CA, а куда дели первый - надо в spec
смотреть). 

В силу сугубой интерактивности  скриптов CA их отсутствие вряд ли что сломает.
Поэтому имеет смысл заменить их на скрипт с аналогичной
функциональности, но с нормальной поддержкой русского языка (а то и
русских алгоритмов), который ставить в /usr/bin или /usr/sbin.

Кстати, c_issuer, c_name и c_info тоже будут иметь немаленькие проблемы
с русскими буквами в DN, которые на уровне openssl.cnf не фиксятся
(зато на уровне самого скрипта - да запросто. Правильный -nameopt
добавить и все).

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

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On Thu, May 07, 2009 at 01:25:31PM +0400, Victor B. Wagner wrote:

VBW> Кстати, c_issuer, c_name и c_info тоже будут иметь немаленькие проблемы
VBW> с русскими буквами в DN, которые на уровне openssl.cnf не фиксятся
VBW> (зато на уровне самого скрипта - да запросто. Правильный -nameopt
VBW> добавить и все).

Где-то вообще в рунете такие особенности использования openssl
документированы относительно просто (на уровне HOWTO)?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Victor B. Wagner]

On 2009.05.24 at 03:28:12 +0400, Денис Смирнов wrote:

> On Thu, May 07, 2009 at 01:25:31PM +0400, Victor B. Wagner wrote:
> 
> VBW> Кстати, c_issuer, c_name и c_info тоже будут иметь немаленькие проблемы
> VBW> с русскими буквами в DN, которые на уровне openssl.cnf не фиксятся
> VBW> (зато на уровне самого скрипта - да запросто. Правильный -nameopt
> VBW> добавить и все).
> 
> Где-то вообще в рунете такие особенности использования openssl
> документированы относительно просто (на уровне HOWTO)?

Они и в нормальной-то сети документированы крайне непросто.
Сначала надо прочитать полуторасантиметровой толщины стандарт на ASN.1 и
понять (для чего требуется уметь выполнять в голове хвостовую рекурсию).
И только после этого будет понятно то, что написано в man config
от openssl.

И слава богу, что оно хоть в man документировано. А то в OpenSSL есть
целые блоки API (например trusted certificate store, или OCSP) которые
не документированы ВООБЩЕ. Их можно изучать только посредством RTFS.
(Правда, вот эти два блока я как раз документировал по-русски, когда мы
КриптоПакет 1.0 на сертификацию подавали)

Правда, тут недавно в openssl-user пробегала ссылка на сайт с книгами,
котоыре объясняют ASN.1 без необходимости прибегать к хвостовой
рекурсии. (искать в архиве рассылки по ключевым словам tail recursion).

Вообще, хаутушку для юзера TLS мы уже написали, а вот для администратора
удостоверяющего центра - еще нет.