* Re: [devel] Упаковка openssl (was: Вопросы новичка) @ 2009-05-05 11:31 ` Victor B. Wagner 2009-05-06 21:44 ` [devel] Упаковка openssl Dmitry V. Levin 0 siblings, 2 replies; 5+ messages in thread From: Victor B. Wagner @ 2009-05-05 11:31 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [devel] Упаковка openssl 2009-05-05 11:31 ` [devel] Упаковка openssl (was: Вопросы новичка) Victor B. Wagner @ 2009-05-06 21:44 ` Dmitry V. Levin 1 sibling, 0 replies; 5+ messages in thread From: Dmitry V. Levin @ 2009-05-06 21:44 UTC (permalink / raw) To: ALT Devel discussion list [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <cc557aab0905050442l49089e29w6ef0c96e96365290@mail.gmail.com>]
[parent not found: <921f6bb40905050447k2d5b8e15k71201958a4aec54a@mail.gmail.com>]
* Re: [devel] Упаковка openssl (was: Вопросы новичка) @ 2009-05-07 9:25 ` Victor B. Wagner 2009-05-23 23:28 ` Денис Смирнов 0 siblings, 1 reply; 5+ messages in thread From: Victor B. Wagner @ 2009-05-07 9:25 UTC (permalink / raw) To: devel > Ну, вот и мне как-то это странным не показалось... Хотя, если оно не > нужно, можно и в 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 добавить и все). ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [devel] Упаковка openssl (was: Вопросы новичка) 2009-05-07 9:25 ` [devel] Упаковка openssl (was: Вопросы новичка) Victor B. Wagner @ 2009-05-23 23:28 ` Денис Смирнов 2009-05-25 7:11 ` Victor B. Wagner 0 siblings, 1 reply; 5+ messages in thread From: Денис Смирнов @ 2009-05-23 23:28 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [devel] Упаковка openssl (was: Вопросы новичка) 2009-05-23 23:28 ` Денис Смирнов @ 2009-05-25 7:11 ` Victor B. Wagner 0 siblings, 0 replies; 5+ messages in thread From: Victor B. Wagner @ 2009-05-25 7:11 UTC (permalink / raw) To: devel 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 мы уже написали, а вот для администратора удостоверяющего центра - еще нет. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-25 7:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-05-05 11:31 ` [devel] Упаковка openssl (was: Вопросы новичка) Victor B. Wagner 2009-05-06 21:44 ` [devel] Упаковка openssl Dmitry V. Levin 2009-05-07 9:25 ` [devel] Упаковка openssl (was: Вопросы новичка) Victor B. Wagner 2009-05-23 23:28 ` Денис Смирнов 2009-05-25 7:11 ` Victor B. Wagner
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git