From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Date: Tue, 5 May 2009 15:31:10 +0400 From: "Victor B. Wagner" To: devel@lists.altlinux.org Message-ID: <20090505113110.GJ2101@cryptocom.ru> Mail-Followup-To: devel@lists.altlinux.org References: <921f6bb40905050346n77872b7al1648223cc0eb8fb6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <921f6bb40905050346n77872b7al1648223cc0eb8fb6@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [devel] =?koi8-r?b?9dDBy8/Xy8Egb3BlbnNzbCAod2FzOiD3z9DSz9PZIM7P?= =?koi8-r?b?18ney8Ep?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 11:31:28 -0000 Archived-At: List-Archive: List-Post: 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//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