<br><br><div class="gmail_quote">4 мая 2009 г. 19:00 пользователь Victor B. Wagner <span dir="ltr"><<a href="mailto:vitus@altlinux.org">vitus@altlinux.org</a>></span> написал:<br><div>[...] <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Теперь вопросы по собственно OpenSSL<br>
</blockquote><div><br>Думаю, что некоторые из этих вопросов требуют отдельного рассмотрения....<br> </div><div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
2. У OpenSSL есть такой параметр openssldir . Задается при<br>
конфигурировании и в умолчательной сборке там ищутся<br>
1. Конфигурационный файл<br>
2. Сертификаты доверенных удостоверяющих центров (certification<br>
authority, CA)<br>
3. Подгружаемые модули альтернативных реализаций криптоалгоритмов<br>
(engines).<br>
4. Туда же при инсталляции складвывается ряд скриптов, которым вообще<br>
место где нибудь в /usr/share/doc/openssl/examples.<br>
<br>
В Alt зачем-то openssldir указывает в /var. При этом конфигурационный<br>
файл, как и положено, лежит в /etc, engines посредством более менее<br>
глубокого хака в исходниках перетащены в /usr/lib, каталог<br>
сертификатов пустой, даже при установленном пакете ca-certificates,<br>
а вот скрипты - остались. Исполняемые файлы радостно инсталлируются в<br>
/var. Зачем?<br>
</blockquote><div><br>Видимо, для следования FHS. Настройки кладутся в /etc, данные - в /var. Вроде бы логично, может быть стоит уточнить... Сейчас это уже legacy. Его стоит иметь в виду... ;)<br><br>Вообще там всё не так просто:<br>
$ ls /var/lib/ssl/ -l<br>итого 12<br>lrwxrwxrwx 1 root root 48 Мар 30 12:56 cert.pem -> ../../../usr/share/ca-certificates/ca-bundle.crt<br>drwxr-xr-x 2 root root 4096 Мар 30 12:56 certs<br>drwxr-xr-x 2 root root 4096 Мар 30 12:56 misc<br>
lrwxrwxrwx 1 root root 32 Мар 30 12:56 openssl.cnf -> ../../../etc/openssl/openssl.cnf<br>drwx------ 2 root root 4096 Мар 27 20:35 private<br><br>Но, в целом, идея проста - в /var/lib/ssl/ обычная свалка, как везде... А, что можно, разложено по полочкам... Насколько это не удобно и что нужно сделать, чтобы стало удобно давайте подумаем...<br>
<br>Кстати, здесь же стоит отметить, что файл настроек<br>/etc/openssl/openssl.cnf<br><br>Упакован, опять-таки по старому legacy (ибо я не придумал, как должно и сделал как было), в два пакета libssl7 и libssl6, а ранее и в третьем libssl4... По счастливому набору обстоятельств файлы идентичны и проблемы вроде как не видно... Но тут, тоже стоит что-нибудь решить.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
3. Библиотеки libcrypto и libssl помещены в /lib.<br>
То есть надо полагать, что в дистрибутиве, близко к базовой системе<br>
существуют приложения, которые используют эти библиотеки до<br>
монтирования /usr. То что там есть какие-то другие библиотеки,<br>
которые зависят от openssl, вопрос, конечно интересный, но меня<br>
интересует как зовут тот процесс в который все это хозяйство может<br>
быть подгружено до монтирования /usr. А также - читает ли этот<br>
процесс конфигурационный файл openssl.cnf (благо тот в /etc, хотя на<br>
первый взгляд дотягиваться до него процесс будет через симлинк в<br>
/var, но это можно и поправить), и как он отнесется к тому, что в<br>
этом файле будут упомянуты engines, лежащие в еще не смонтированном<br>
/usr.<br>
</blockquote><div><br>отсутствие engines определимо и, на этапе загрузки, будет выглядеть как отсутствие этих дополнений. Не думаю, что здесь могут быть проблемы... Среди компонент же использующих openssl на ранних этапах загрузки, например, чтобы списки сетевых пользователей получить, эти дополнения пока вряд ли понадобятся...<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
4. Зачем-то у libcrypto SONAME libcrypto.so.6 (и у libssl - libssl.so.6).<br>
Понятно, что любовью к<br>
переопределению soname отличается не только alt. Но только в alt<br>
ставится файл libssl.so.0.9.8g, на который делается симлинк<br>
libssl.so.6. Существует ли где-нибудь внятное описание этой политики<br>
именования разделяемых библиотек?<br>
</blockquote><br><div><br>Опять-таки некое legacy. Чтобы можно было отличить в установленной системе so.0.9.8h от so.0.9.8k. А то они у нас оба so.7, а вот, как я сегодня выяснил, в fedora so.0.9.8k уже so.8... Думаю это проблема, хотя и потенциальная...<br>
<br>На практике это не позволяет устанавливать пропиетарные сборки для новой федоры, правда так уже и питон новый требуется... так что это ещё не всё, что нужно...<br><br>Смена soname у них прошла ещё в январе:<br>* Thu Jan 15 2009 Tomas Mraz <<a href="mailto:tmraz@redhat.com">tmraz@redhat.com</a>> 0.9.8j-1<br>
- new upstream version with necessary soname bump (#455753)<br><br>Я тогда не увидел особых изменений в ABI, но, видимо, они перестраховались, а может я что-то пропустил...<br><br>Сейчас есть два варианта выхода:<br>1) добавить симлинк so.8 в новой сборке openssl и сделать из неё libssl8, оcтавив so.7 в ней же самой<br>
2) сделать новую сборку с libssl8 на основе текущей + compat libssl7 откатить до федориного состояния 0.9.8h<br><br>Первый вариант мне кажется более оптимальным.<br><br>Да, кстати, стоит подумать какой soname будет у openssl-1.0.0 ...<br>
</div></div><br clear="all"><br>-- <br>Sin (Sinelnikov Evgeny)<br>