[devel] Вопросы новичка

[devel] Вопросы новичка

[Victor B. Wagner]

Я тут недавно, хотя, наверное многие из присуствующих меня знают давно.
Присоединиться к разработке Alt я собрался с одной конкретной целью -
сделать так, чтобы в дистрибутиве из коробки работала российская
криптография, а переход на использование сертифицированной российской
криптографии был бы совершенно безболезненен для пользователя/админа.

Поэтому первая задача, которую я перед собой ставлю - сборка OpenSSL 1.0
beta последняя.

В связи с этим у меня возник ряд вопросов по поводу того, почему OpenSSL
запакетирван в Alt так, как это сделано.

Первый вопрос вообще глобального плана и к OpenSSL отношения не имеет:

1. Почему в Alt у rpm нет ключа --import. У всех rpm-based дистрибутивов
есть, а у Alt нет. Решать эту задачу - импортировать ключ стороннего
репозитория в кейринг RPM предлагается посредством
   1. посмотреть значение макроса %_gpg_path
   2. Ручками запустить gpg --import выставив ему этот путь в качестве
   GPG_PATH
 
Судя по спектру дистрибутивов в которых rpm умеет --import, эту
фунциональность в Alt специально отрывали. Зачем?

Теперь вопросы по собственно OpenSSL

2. У OpenSSL есть такой параметр openssldir . Задается при
конфигурировании и в умолчательной сборке там ищутся 
   1. Конфигурационный файл
   2. Сертификаты доверенных удостоверяющих центров (certification
   authority, CA)
   3. Подгружаемые модули альтернативных реализаций криптоалгоритмов
   (engines).
   4. Туда же при инсталляции складвывается ряд скриптов, которым вообще
   место где нибудь в /usr/share/doc/openssl/examples.

  В Alt зачем-то openssldir указывает в /var. При этом конфигурационный
  файл, как и положено, лежит в /etc, engines посредством более менее
  глубокого хака в исходниках перетащены в /usr/lib, каталог
  сертификатов пустой, даже при установленном пакете ca-certificates,
  а вот скрипты - остались. Исполняемые файлы радостно инсталлируются в
  /var. Зачем?

3. Библиотеки libcrypto и libssl помещены в /lib.
   То есть надо полагать, что в дистрибутиве, близко к базовой системе
   существуют приложения, которые используют эти библиотеки до
   монтирования /usr. То что там есть какие-то другие библиотеки,
   которые зависят от openssl, вопрос, конечно интересный, но меня
   интересует как зовут тот процесс в который все это хозяйство может
   быть подгружено до монтирования /usr. А также - читает ли этот
   процесс конфигурационный файл openssl.cnf (благо тот в /etc, хотя на
   первый взгляд дотягиваться до него процесс будет через симлинк в
   /var, но это можно и поправить), и как он отнесется к тому, что в
   этом файле будут упомянуты engines, лежащие в еще не смонтированном
   /usr.

4. Зачем-то у libcrypto SONAME libcrypto.so.6 (и у libssl - libssl.so.6).
   Понятно, что любовью к
   переопределению soname отличается не только alt. Но только в alt
   ставится файл libssl.so.0.9.8g, на который делается симлинк
   libssl.so.6. Существует ли где-нибудь внятное описание этой политики
   именования разделяемых библиотек?

5. Почему в пакете ca-certificates используется один большой файл с
   катенированными сертификатами? 
   OpenSSL умеет работать как с таким файлом (загружая его в память
   целиком), так и с директорией где каждый сертификат и CRL лежит в
   отдельном файлике, кэшируя в памяти только те сертификаты, которые
   понадобились при выстраивании цепочки доверия.

   По этому вопросу интересно также
   мнение людей поддерживающих более другие криптобиблиотеки  - libnss,
   libgcrypt - как эти библиотеки доступаются к trusted CA store (потому
   что очевидно, что пакет ca-certificates должен удовлетоврять
   потребности всех трех библиотек).

   Во всяком случае лично мне, когда потребовалось втащить сертификат
   альтовского удостоверяющего центра в свою мозиллу на более другом
   дистрибутиве, пришлось лезть текстовым редактором в этот самый
   ca-bundle.pem, искать там нужный сертификат, выгрызать его в
   отдельный файл и импортировать. Были бы отдельные файлики, да с
   интуитивно понятными названиями было бы проще.

   Аналога дебиановского update-cacertificates я тоже что-то не увидел.

---
		
			





----- End forwarded message -----

Re: [devel] Вопросы новичка

[Andrey Rahmatullin]

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

On Mon, May 04, 2009 at 07:00:25PM +0400, Victor B. Wagner wrote:
> 1. Почему в Alt у rpm нет ключа --import. У всех rpm-based дистрибутивов
> есть, а у Alt нет. 
rpm из прошлого века.

> Судя по спектру дистрибутивов в которых rpm умеет --import, эту
> фунциональность в Alt специально отрывали.
Нет, просто у нас он 4.0.4, а не 4.6.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Набрел тут на вот такой документ, может нам тоже что-то подобное
> оформить?
> http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced
Только не надо при этом на меня так смотреть. :)
		-- ldv in devel@

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

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.04 at 21:06:20 +0600, Andrey Rahmatullin wrote:

> On Mon, May 04, 2009 at 07:00:25PM +0400, Victor B. Wagner wrote:
> > 1. Почему в Alt у rpm нет ключа --import. У всех rpm-based дистрибутивов
> > есть, а у Alt нет. 
> rpm из прошлого века.
> 
> > Судя по спектру дистрибутивов в которых rpm умеет --import, эту
> > фунциональность в Alt специально отрывали.
> Нет, просто у нас он 4.0.4, а не 4.6.

Ну, в SLES 9 он 4.1.1, а --import есть.
Более древних rpm-based у меня вроде под рукой нету.

Вообще 4.6 по-моему ни в одном приличном дистрибутиве еще нет.

В Debian Lenny, SLES 10, Mandriva 2008, RHEL 5 - у всех 4.4

Всякие Fedora Core и OpenSUSE за приличные дистрибутивы я не считаю. Это
вроде сизифа. Полигоны для разработчиков, а не дистрибутивы.

Вот свежевышедших SLES 11 и Mandriva 2009 я еще не смотрел.

Re: [devel] Вопросы новичка

[Mikhail Gusarov]

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


Twas brillig at 19:22:51 04.05.2009 UTC+04 when vitus@altlinux.org did gyre and gimble:

 VBW> Ну, в SLES 9 он 4.1.1, а --import есть.

4.0 - это оооочень старое. А 4.0.4-alt96.16 - это оооочень запатченное
старое :)

-- 

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

Re: [devel] Вопросы новичка

[Alexey I. Froloff]

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

* Victor B. Wagner <vitus@> [090504 19:01]:
> По этому вопросу интересно также мнение людей поддерживающих
> более другие криптобиблиотеки  - libnss,
Раскалённой кочергой вкомпилено в либу.  Централизованного
хранилища сертификатов не существует.

> libgcrypt - как эти библиотеки доступаются к trusted CA store
У libgcrypt нет такого понятия как "trust" вообще.  Это только
алгоритмы шифрования.

> (потому что очевидно, что пакет ca-certificates должен
> удовлетоврять потребности всех трех библиотек).
Неочевидно.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Вопросы новичка

[Andrey Rahmatullin]

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

On Mon, May 04, 2009 at 10:24:20PM +0700, Mikhail Gusarov wrote:
>  VBW> Ну, в SLES 9 он 4.1.1, а --import есть.
> 4.0 - это оооочень старое. А 4.0.4-alt96.16 - это оооочень запатченное
> старое :)
Что интересно, в CHANGES --import впервые упоминается в 4.1 (это не
значит, что его не было в 4.0.4, правда).


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Мы всем будем рады и без докладов, но c докладами будет
> интереснее.  Естественно, члены team освобождаются от
> регистрационных взносов.
Ищу спонсора.  Цена вопроса $200.  Интим не предлагать.
		-- at in devel@

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

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.04 at 19:27:16 +0400, Alexey I. Froloff wrote:

> * Victor B. Wagner <vitus@> [090504 19:01]:
> > По этому вопросу интересно также мнение людей поддерживающих
> > более другие криптобиблиотеки  - libnss,
> Раскалённой кочергой вкомпилено в либу.  Централизованного
> хранилища сертификатов не существует.

Существует как минимум диалоговое окно в Mozilla Firefox, которое
позволяет импортировать сертификаты доверенных УЦ.

Следовательно,  API библиотеки позволяет каким-то образом втаскивать
новые сертификаты в это хранилище.

Если, конечно, мейнтейнеров софта на базе этой библиотеки не интересует
синхронизация набора доверенных сертификатов с набором, используемым
другими библиотеками, то это - ответ на мой вопрос. 

> > libgcrypt - как эти библиотеки доступаются к trusted CA store
> У libgcrypt нет такого понятия как "trust" вообще.  Это только
> алгоритмы шифрования.

Он есть у gnutls. Я употребил название gcrypt, поскольку сходу не
вспомнил правильное название той библиотеки, которая в этой системе
поддерживает набор вещей, более высокоуровневый, чем собственно
алгоритмы шифрования, но общий для TLS и S/MIME. Вообще в gnutls я из
трех основных opensource криптобиблиотек копался меньше всего.

> 
> > (потому что очевидно, что пакет ca-certificates должен
> > удовлетоврять потребности всех трех библиотек).
> Неочевидно.

То есть, вы считаете что неочевидно, что wget на конкретной системе 
должен доверять ровно тем
же УЦ, что и Firefox, а mutt - тем же, что и Thunderbird?

Серверный софт вроде apache и postgresql, у которого ДЕЙСТВИТЕЛЬНО могут
быть более другие требования по уровню доверия, сам о себе позаботится
посредством отказа от использования умолчательного хранилища
сертификатов, и явного прописывания в конфигах тех сертификатов, которым
они согласны доверять.

А пакет ca-certificates предназначен для клиентского софта. 
Соответственно, весь этот софт независимо от используемой
криптобиблиотеки по хорошему счету должен использовать именно этот набор
сертификатов. Вернее, тот, в который этот набор превратил пользователь,
добавив туда руками то, чему лично он доверяет.

Re: [devel] Вопросы новичка

[Max Ivanov]

> Он есть у gnutls. Я употребил название gcrypt, поскольку сходу не
> вспомнил правильное название той библиотеки, которая в этой системе
> поддерживает набор вещей, более высокоуровневый, чем собственно
> алгоритмы шифрования, но общий для TLS и S/MIME. Вообще в gnutls я из
> трех основных opensource криптобиблиотек копался меньше всего.

gnutls кстати не умеет понимать каталог с сертификатами, только всю
пачку склееную в 1 файл

Re: [devel] Вопросы новичка

[Alexey I. Froloff]

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

* Victor B. Wagner <vitus@> [090504 19:53]:
> > > По этому вопросу интересно также мнение людей поддерживающих
> > > более другие криптобиблиотеки  - libnss,
> > Раскалённой кочергой вкомпилено в либу.  Централизованного
> > хранилища сертификатов не существует.
> Существует как минимум диалоговое окно в Mozilla Firefox, которое
> позволяет импортировать сертификаты доверенных УЦ.
В какое-то место, которое известно только Mozilla Firefox и
только для конкретного пользователя.

Поддержку централизованного хранилища trusted CA, по словам
мантейнера Mozilla&Co, ещё только делают.

> > > libgcrypt - как эти библиотеки доступаются к trusted CA store
> > У libgcrypt нет такого понятия как "trust" вообще.  Это только
> > алгоритмы шифрования.
> Он есть у gnutls.
Trusted CA туда загружаются из клиентской программы.  Т.е. опять
никакого system-wide хранилища на уровне libgnutls.

> А пакет ca-certificates предназначен для клиентского софта. 
> Соответственно, весь этот софт независимо от используемой
> криптобиблиотеки по хорошему счету должен использовать именно этот набор
> сертификатов. Вернее, тот, в который этот набор превратил пользователь,
> добавив туда руками то, чему лично он доверяет.
Пакет ca-certificates предоставляет хранилище trusted CA для тех
библиотек, которые в состоянии им пользоваться.  На данный момент
это только openssl.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/4 Alexey I. Froloff <raorn@altlinux.org>:
> * Victor B. Wagner <vitus@> [090504 19:01]:
>> По этому вопросу интересно также мнение людей поддерживающих
>> более другие криптобиблиотеки  - libnss,
> Раскалённой кочергой вкомпилено в либу.  Централизованного
> хранилища сертификатов не существует.
Существует ряд проектов по созданию такого централизованного хранилища
в рамках Федоры и OpenSUSE, Maemo.

http://en.opensuse.org/SharedCertStore
http://fedoraproject.org/wiki/FedoraCryptoConsolidation
http://fedoraproject.org/wiki/CryptoConsolidationEval
http://fedoraproject.org/wiki/CryptoConsolidationScorecard
http://maemo.org/api_refs/4.1/libcst-1.7.16/modules.html

Тема довольно неплохо изучена. Очень прошу пройтись по этим ссылкам,
прежде чем делать выводы.
-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.04 at 21:31:48 +0400, Alexey I. Froloff wrote:

> Пакет ca-certificates предоставляет хранилище trusted CA для тех
> библиотек, которые в состоянии им пользоваться.  На данный момент
> это только openssl.

То есть на данный момент при модификации пакета openssl можно заодно и с
ca-certificates делать все, что угодно? Никто не окажется несправедливо
обиженным?

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.04 at 20:44:11 +0300, Alexander Bokovoy wrote:

> Существует ряд проектов по созданию такого централизованного хранилища
> в рамках Федоры и OpenSUSE, Maemo.
> 
> http://en.opensuse.org/SharedCertStore
> http://fedoraproject.org/wiki/FedoraCryptoConsolidation
> http://fedoraproject.org/wiki/CryptoConsolidationEval
> http://fedoraproject.org/wiki/CryptoConsolidationScorecard
> http://maemo.org/api_refs/4.1/libcst-1.7.16/modules.html
> 
> Тема довольно неплохо изучена. Очень прошу пройтись по этим ссылкам,
> прежде чем делать выводы.

Тут дело какое - мы в России.  Дистрибутив ориентирован преимущественно
на российский рынок. Поэтому волнует в первую очередь не сертификация FIPS,
а сертификация в ФСБ, а также совместимость с сертифицированными
решениями, которые продавливаются на рынок интернет-банкинга и тому
подобных областей применения всей мощью административного ресурса
правительства РФ.

Федора и Сусе делают ставку на libnss. Сертифицированных решений с
российскими алгоритмами на базе libnss пока не существует. Не существует
даже работающих, хотя и не сертифицированных.

Мы в свое время несколько раз начинали переговоры и с Novell и с Mozilla
Foundation на предмет встраивания российских алгоритмов в libnss/Mozilla
Suite, но пока что это все кончилось ничем. То есть на уровне
менеджмента какой-то энтузиазм был, но до уровня контактов между
разработчиками дело не доходило.

Другие российские криптографические фирмы (например Топ-Кросс) что-то с
мозиллой делали, но даже коммерческих (закрытых) решений готовых к
употреблению на рынке пока нет.

Поэтому я оцениваю сроки появления поддержки российской криптографии в
libnss не менее чем в два года. Плюс еще не менее года на сертификацию
появившегося решения.

А решение на базе OpenSSL уже сертифицировано (пока на базе патченной
0.9.8). В OpenSSL 1.0 beta уже имеется работающее решение upstream.
И сроки на сертификацию этого решения мы оцениваем куда более оптимистично
(поскольку сертификаторы эту codebase уже видели)

Поэтому, подозреваю, что допинать какой-нибудь браузер на базе webkit
до корректной работы с https и подписью web-форм с использованием
OpenSSL будет намного быстрее, чем добиваться работы российской
криптографии в Mozilla.

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/5 Victor B. Wagner <vitus@altlinux.org>:
> On 2009.05.04 at 20:44:11 +0300, Alexander Bokovoy wrote:
>
>> Существует ряд проектов по созданию такого централизованного хранилища
>> в рамках Федоры и OpenSUSE, Maemo.
>>
>> http://en.opensuse.org/SharedCertStore
>> http://fedoraproject.org/wiki/FedoraCryptoConsolidation
>> http://fedoraproject.org/wiki/CryptoConsolidationEval
>> http://fedoraproject.org/wiki/CryptoConsolidationScorecard
>> http://maemo.org/api_refs/4.1/libcst-1.7.16/modules.html
>>
>> Тема довольно неплохо изучена. Очень прошу пройтись по этим ссылкам,
>> прежде чем делать выводы.
>
> Тут дело какое - мы в России.  Дистрибутив ориентирован преимущественно
> на российский рынок. Поэтому волнует в первую очередь не сертификация FIPS,
> а сертификация в ФСБ, а также совместимость с сертифицированными
> решениями, которые продавливаются на рынок интернет-банкинга и тому
> подобных областей применения всей мощью административного ресурса
> правительства РФ.
>
> Федора и Сусе делают ставку на libnss. Сертифицированных решений с
> российскими алгоритмами на базе libnss пока не существует. Не существует
> даже работающих, хотя и не сертифицированных.
Витус, ты упустил главное. Я не веду речь о переходе на libnss
_вообще_. Я хочу, чтобы те, кто заинтересован в этой теме, обратили
внимание на уже пройденные грабли по централизации обработки
сертификатов. Грабли эти довольно хорошо задокументированы, особенно в
Fedora, для целого ряда приложений.

Политика меня слабо интересует. Техническая возможность сделать единую
базу сертификатов для всех разрозненных библиотек существует, хотя бы
в рамках криптографических алгоритмов, которые они все поддерживают.
Это приемлемое решение, если все библиотеки будут "смотреть" в одну и
ту же базу. Будут ли все они поддерживать специфичные для территории
алгоритмы -- это другой разговор, который и технически, и проектно
хотелось бы отделить от централизации сертификатов.

Почему в Maemo для стандартных алгоритмов с тремя библиотеками такую
систему удалось сделать, а в ALT нельзя? Потенциально российская
криптография в Maemo 6 будет поддерживаться на основании вашей работы
с апстримом, насколько это будет реально работать к моменту выхода
платформы через год-полтора, не знаю. Но если ALT к тому моменту будет
на том же месте, где и сейчас, даже для поддерживаемых всеми 3DES,
AES, etc -- печально.
-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.05 at 12:43:19 +0300, Alexander Bokovoy wrote:

> > Федора и Сусе делают ставку на libnss. Сертифицированных решений с
> > российскими алгоритмами на базе libnss пока не существует. Не существует
> > даже работающих, хотя и не сертифицированных.
> Витус, ты упустил главное. Я не веду речь о переходе на libnss
> _вообще_. Я хочу, чтобы те, кто заинтересован в этой теме, обратили
> внимание на уже пройденные грабли по централизации обработки
> сертификатов. Грабли эти довольно хорошо задокументированы, особенно в
> Fedora, для целого ряда приложений.

В данном случае я обращаю внимание на то, что путь, который выбран
Fedora и Suse, у нас не очень приемлем. "хорошо задокументированных
граблей по вышепоскипанным ссылкам не заметил". Там перечислены ну
настолько общие места, которые даже в наших методичках для пользователей
CSP и то разжеваны подробнее. Ну то есть понятно, что среди авторов и
мейнтейнеров приложений криптографический ликбез нужно проводить с нуля.
Но все же.

В Maemo - интереснее.

Но вот думать о создании единой политики использования ключевой
инфраструктуры в пределах дистрибутива - надо.

При этом сразу же задумываться над тем, что такое системное хранилище,
что такое пользовательское хранилище, и что должны делать по этому
поводу демоны. 

На данный момент мы имеем следующую картину

у libnss есть пользовательское хранилище, но нет системного.
У OpenSSL есть "умолчательное", т.е. необязательное к использованию
общесистемное, но нет стандартизованного пользовательского. Кстати можно
попробовать в upstream эту идею пропихнуть. 

У  gnutls это вообще отдано на откуп приложениям.


> Политика меня слабо интересует. Техническая возможность сделать единую

В рамках планов по развитию Alt политика интересует только в том смысле,
что если ты ей не занимаешься, она займется тобой. Вот внедрит пяток
крупнейших банков России интернет-банкинг на базе российских алгоритмов,
и если у пользователей Alt не будет возможности с этим работать родными
средствами, будет неприятно. 

Мы бы в общем-то и рады пропихивать нашим клиентам, покупающим у нас
серверные решения, решения переносимые, с которыми можно работать и из
свободного софта. Но пока с этим как-то плохо.

> базу сертификатов для всех разрозненных библиотек существует, хотя бы

Я бы постарался избегать термина "база". К сожалению, прочитав слово
"база" многие разработчики начинают думать об SQL. SQL, даже в
инкарнации SQLite здесь не место. Не те объемы, не те критерии поиска.
А держать по крайней мере хранилище, используемое в WPA, потребуется на
корневой FS. 

Оно нам надо - libsqlite в /lib?

Поэтому я бы предложил использовать термин "хранилище". Чтобы не
вызывать ненужных ассоциаций.

Вообще, на мой взгляд, правильно стандартизировать формат хранилища и
его расположение в файловой системе. Но ни в коем случае не
стандартизировать код для доступа к этому хранилищу. Во всяком случае на
начальном этапе

Формат должен быть такой, чтобы код для доступа умещался в экран.

После того как появятся 4-5 разновидностей этого когда, написанного
разными людьми, под разные приложения и библиотеки, на разных языках,
можно будет посравнивать их и подумать о стандартизации.

> в рамках криптографических алгоритмов, которые они все поддерживают.
> Это приемлемое решение, если все библиотеки будут "смотреть" в одну и

Тут требуется обеспечить возможность игнорирования не понимаемых
алгоритмов. Чтобы использование национальных алгоритмов не было
равнозначным отказу от стандартного хранилища.

Собственно поэтому я начал активно лезть в alt только после появления 
OpenSSL 1.0beta. На данном этапе возможно успешное сосуществование
неподдерживающего национальные алгоритмы софта и поддерживающего над 
общим ABI новой версии OpenSSL. В старой версии, когда ABI версии
поддерживающей ГОСТ и "родной" был несовместим, с этим было сложнее.

> Почему в Maemo для стандартных алгоритмов с тремя библиотеками такую
> систему удалось сделать, а в ALT нельзя? Потенциально российская

Вообще-то  Maemo не многопользовательская система и не особенно
рассчитана на поддержку интернет-серверов, у которых совершенно свои
требования к тому, кому доверять, а кому нет. Поэтому там задача проще.


> криптография в Maemo 6 будет поддерживаться на основании вашей работы
> с апстримом, насколько это будет реально работать к моменту выхода

Если приложение умеет читать openssl.cnf, то как правило, российский TLS 
и PKCS#7 в соответствии с RFC 4490 
в нем работают совершенно прозрачно для пользователя и администратора -
только ключи и заявки на сертификат надо немножко по-другому
генерировать. Если не умеет, то нужен однострочный патч, чтобы
научилось. Вообще-то в документации к OpenSSL читать этот конфиг
настоятельно рекомендуют начиная с версии 0.9.7.

Вопрос "насколько оно будет работать", надо ставить только в отношении
приложений, которые реализуют собственные криптопротоколы - ssh (для
которого пока нет даже драфта на использование российских алгоритмов, не
говоря уж о реализации), openvpn (для которой есть патч).

Из приложений, которые используют обычный tls, единственное на сей
момент найденное приложение, которому требуется нетривиальный патч - это
Apache (насколько понимаю, в случае Maemo - не шибко интересно).

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/5 Victor B. Wagner <vitus@altlinux.org>:
> В данном случае я обращаю внимание на то, что путь, который выбран
> Fedora и Suse, у нас не очень приемлем. "хорошо задокументированных
> граблей по вышепоскипанным ссылкам не заметил". Там перечислены ну
> настолько общие места, которые даже в наших методичках для пользователей
> CSP и то разжеваны подробнее. Ну то есть понятно, что среди авторов и
> мейнтейнеров приложений криптографический ликбез нужно проводить с нуля.
> Но все же.
http://fedoraproject.org/wiki/CryptoConsolidationScorecard имеет
практический смысл, поскольку позволяет оценить объем требуемых
изменений пакетной базы,  а также оценить последствия таких изменений
или их неисполнения. Всю эту работу пришлось бы делать самостоятельно.

> В Maemo - интереснее.
>
> Но вот думать о создании единой политики использования ключевой
> инфраструктуры в пределах дистрибутива - надо.
>
> При этом сразу же задумываться над тем, что такое системное хранилище,
> что такое пользовательское хранилище, и что должны делать по этому
> поводу демоны.
Именно. Об этом я и говорю, разделяя задачи поддержки ГОСТ и
централизации хранения сертификатов.

> На данный момент мы имеем следующую картину
>
> у libnss есть пользовательское хранилище, но нет системного.
> У OpenSSL есть "умолчательное", т.е. необязательное к использованию
> общесистемное, но нет стандартизованного пользовательского. Кстати можно
> попробовать в upstream эту идею пропихнуть.
>
> У  gnutls это вообще отдано на откуп приложениям.
То есть, на самом деле можно реализовать некоторое подмножество
"централизованного" взгляда, для которого будет предложен типовой код
взаимодействия для некоторых библиотек и рекомендации по его
использованию в приложениях.

>> базу сертификатов для всех разрозненных библиотек существует, хотя бы
>
> Я бы постарался избегать термина "база". К сожалению, прочитав слово
> "база" многие разработчики начинают думать об SQL. SQL, даже в
> инкарнации SQLite здесь не место. Не те объемы, не те критерии поиска.
> А держать по крайней мере хранилище, используемое в WPA, потребуется на
> корневой FS.
>
> Оно нам надо - libsqlite в /lib?
Я не говорю о sql. Термин "база" выше не связан с конкретной
реализацией этой концепции. Хотя я и понимаю, откуда растут ноги у
твоей реакции на "база":
https://wiki.mozilla.org/NSS:Roadmap#SQLite-Based_Shareable_Certificate_and_Key_Databases

> Вообще, на мой взгляд, правильно стандартизировать формат хранилища и
> его расположение в файловой системе. Но ни в коем случае не
> стандартизировать код для доступа к этому хранилищу. Во всяком случае на
> начальном этапе
>
> Формат должен быть такой, чтобы код для доступа умещался в экран.
Это нефункциональное требование.

> Тут требуется обеспечить возможность игнорирования не понимаемых
> алгоритмов. Чтобы использование национальных алгоритмов не было
> равнозначным отказу от стандартного хранилища.
Да.

>> Почему в Maemo для стандартных алгоритмов с тремя библиотеками такую
>> систему удалось сделать, а в ALT нельзя? Потенциально российская
>
> Вообще-то  Maemo не многопользовательская система и не особенно
> рассчитана на поддержку интернет-серверов, у которых совершенно свои
> требования к тому, кому доверять, а кому нет. Поэтому там задача проще.
Я бы вот так и отделил задачи -- клиентскую и серверную сторону.
Требования у них разные, подходы тоже. Проще задача или нет -- дело
десятое, важнее описать требования и конфигурации, в рамках которых
будет выполнена централизация.

> Из приложений, которые используют обычный tls, единственное на сей
> момент найденное приложение, которому требуется нетривиальный патч - это
> Apache (насколько понимаю, в случае Maemo - не шибко интересно).
Поэтому я и отделяю централизацию и поддержку российской криптографии.
Первое полезно всем пользователям ALT, второе имеет смысл для
некоторого специфического круга бизнесов и лиц внутри РФ. ALT
используется не только в РФ.

-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.05 at 14:47:33 +0300, Alexander Bokovoy wrote:

> http://fedoraproject.org/wiki/CryptoConsolidationScorecard имеет
> практический смысл, поскольку позволяет оценить объем требуемых
> изменений пакетной базы,  а также оценить последствия таких изменений
> или их неисполнения. Всю эту работу пришлось бы делать самостоятельно.
 
Неужели пакетная база Alt настолько близка к пакетной базе федоры?
Если бы речь шла об ASP то было бы понятно. Alt, насколько я понимаю,
гораздо сильнее отличается.

> То есть, на самом деле можно реализовать некоторое подмножество
> "централизованного" взгляда, для которого будет предложен типовой код
> взаимодействия для некоторых библиотек и рекомендации по его
> использованию в приложениях.
 
> Я не говорю о sql. Термин "база" выше не связан с конкретной

Но слышащий - слышит. В основном я о типичных ассоциациях, которые 
бывают у разработчиков.

> > Вообще, на мой взгляд, правильно стандартизировать формат хранилища и
> > его расположение в файловой системе. Но ни в коем случае не
> > стандартизировать код для доступа к этому хранилищу. Во всяком случае на
> > начальном этапе
> >
> > Формат должен быть такой, чтобы код для доступа умещался в экран.
> Это нефункциональное требование.

Функциональное требование "код должен быть удобным для security аудита".


> > Вообще-то  Maemo не многопользовательская система и не особенно
> > рассчитана на поддержку интернет-серверов, у которых совершенно свои
> > требования к тому, кому доверять, а кому нет. Поэтому там задача проще.
> Я бы вот так и отделил задачи -- клиентскую и серверную сторону.

Вот так отделить очень непросто. Например, postfix - с одной стороны 
сервер протокола SMTP, с другой - клиент протокола LDAP или даже
PostgreSQL/MySQL.

> > Из приложений, которые используют обычный tls, единственное на сей
> > момент найденное приложение, которому требуется нетривиальный патч - это
> > Apache (насколько понимаю, в случае Maemo - не шибко интересно).
> Поэтому я и отделяю централизацию и поддержку российской криптографии.

Вообще говоря, надо говорить не о "поддержке российской криптографии", а
о "поддержке возможностей современной OpenSSL". Мы старательно делали
поддержку российской криптографии так, чтобы она ничего специфического
не требовала.

Тот патч для Apache, о котором идет речь, обеспечивает поддержку
не только российских алгоритмов, но и ECDSA. 

Чтение приложениями конфига OpenSSL обеспечивает подгрузку не только
engine, обеспечивающей реализацию российских алгоритмов, но и любой
другой engine, обеспечивающей работу с каким-нибудь eToken-ом.

> Первое полезно всем пользователям ALT, второе имеет смысл для
> некоторого специфического круга бизнесов и лиц внутри РФ. ALT
> используется не только в РФ.

Отказ от замшелого RSA, который скоро будет можно ломать на N800,
или хотя бы наличие работспособных альтернатив ему (ECDSA, например),
полезен не только российским пользователям.

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/5 Victor B. Wagner <vitus@altlinux.org>:
> On 2009.05.05 at 14:47:33 +0300, Alexander Bokovoy wrote:
>
>> http://fedoraproject.org/wiki/CryptoConsolidationScorecard имеет
>> практический смысл, поскольку позволяет оценить объем требуемых
>> изменений пакетной базы,  а также оценить последствия таких изменений
>> или их неисполнения. Всю эту работу пришлось бы делать самостоятельно.
>
> Неужели пакетная база Alt настолько близка к пакетной базе федоры?
> Если бы речь шла об ASP то было бы понятно. Alt, насколько я понимаю,
> гораздо сильнее отличается.
У меня сильное сомнение, что у нас какие-то другие программы, чем
указанные в том списке. Может быть старее, может быть свежее, но явно
не с другими реализациями криптографической части, например, в GNOME
или bind. С этой точки зрения приведенный выше список является
актуальным для ALT.

>> > Формат должен быть такой, чтобы код для доступа умещался в экран.
>> Это нефункциональное требование.
>
> Функциональное требование "код должен быть удобным для security аудита".
Это очень хрупкое требование. Мой опыт работы с сертификаторами
показывает, что у них несколько иные взгляды на "удобство кода", чем у
разработчиков и специалистов в вопросах безопасности. Слово "удобный"
вообще с моей точки зрения неприменимо в области безопасности.

Впрочем, мы отклоняемся от темы.

>> > Вообще-то  Maemo не многопользовательская система и не особенно
>> > рассчитана на поддержку интернет-серверов, у которых совершенно свои
>> > требования к тому, кому доверять, а кому нет. Поэтому там задача проще.
>> Я бы вот так и отделил задачи -- клиентскую и серверную сторону.
>
> Вот так отделить очень непросто. Например, postfix - с одной стороны
> сервер протокола SMTP, с другой - клиент протокола LDAP или даже
> PostgreSQL/MySQL.
Давай хотя бы по линии десктоп/сервер проведем разделение. Для явных
десктопных приложений, для явных серверов. Типичный ноутбук типичного
частного налогоплательщика, например. На примере Финляндии: необходима
работа карт-ридера, взаимодействие с libcryptoki от государственного
поставщика, интеграция в браузер, чтобы при входе на государственные
сайты сертификат из карты использовался для авторизации и
идентификации личности. ALT сейчас с этим справляется. Однако
использовать s/mime на основе этого сертификата в разных почтовых
программах не получается без дополнительной и различающейся настройки
каждой из них (работает пока только в Thunderbird).

Приведенное выше -- лишь пример. Типовые сценарии, реализация каждого
из них после приоритезации, шаг за шагом.

>> > Из приложений, которые используют обычный tls, единственное на сей
>> > момент найденное приложение, которому требуется нетривиальный патч - это
>> > Apache (насколько понимаю, в случае Maemo - не шибко интересно).
>> Поэтому я и отделяю централизацию и поддержку российской криптографии.
>
> Вообще говоря, надо говорить не о "поддержке российской криптографии", а
> о "поддержке возможностей современной OpenSSL". Мы старательно делали
> поддержку российской криптографии так, чтобы она ничего специфического
> не требовала.
И это хорошо. Но, например, белорусская криптография сейчас в
GNU/Linux вообще не поддерживается, ни свободными, ни проприетарными
средствами.

Давай сконцентрируемся на выделении таких типовых сценариев, которые
полезны нам как пользователям этой пакетной базы. Оценим их сложность
и важность в реализации, затем посмотрим как и в каком порядке делать.
А то сегодня мы сломаем одно, завтра другое, а потом окажется, что все
это не так уж и нужно.
-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.05 at 15:44:17 +0300, Alexander Bokovoy wrote:

> У меня сильное сомнение, что у нас какие-то другие программы, чем
> указанные в том списке. Может быть старее, может быть свежее, но явно
> не с другими реализациями криптографической части, например, в GNOME

Может и с другими. Очень много какой свободный софт может на выбор
использовать пару, а то и все три криптографических библиотеки.
Соответственно, если в Fedora какой-нибудь libxmlsec собирают с libnss, 
совершенно не обязательно, что и в Alt его надо собирать так же, а не с
OpenSSL.  Я больше скажу, некоторый свободный софт вообще Microsoft 
CryptoApi 2.0 умеет, естественно при сборке на платформе, где этот
CryptoApi присутствует.

> > Функциональное требование "код должен быть удобным для security аудита".
> Это очень хрупкое требование. Мой опыт работы с сертификаторами
> показывает, что у них несколько иные взгляды на "удобство кода", чем у

В данном случае я не про аудит со стороны сертификаторов, а про
разработку и поддержку самого дистрибутива его community.
Есть Security Theater (в который чаще всего выливается сертификация),
а есть настоящая Security. Я про последнюю.

> разработчиков и специалистов в вопросах безопасности. Слово "удобный"
> вообще с моей точки зрения неприменимо в области безопасности.
 
> Впрочем, мы отклоняемся от темы.

Это, впрочем тоже очень важная тема - соотношение security и usability.
Практика показывает, что когда security начинает мешать usability,
большая часть пользователей, то есть все за спиной которых не стоит
грозный начальник первого отдела, отключают эту security нахрен.

> > Вот так отделить очень непросто. Например, postfix - с одной стороны
> > сервер протокола SMTP, с другой - клиент протокола LDAP или даже
> > PostgreSQL/MySQL.
> Давай хотя бы по линии десктоп/сервер проведем разделение. Для явных
> десктопных приложений, для явных серверов. Типичный ноутбук типичного

Лично я скорее за то, что бы в первую голову делать серверную часть,
а десктопные применения - по остаточному принципу. Может быть, если бы у
меня был в загашнике приличный браузер, использующий OpenSSL, я бы имел
другую точку зрения.

> И это хорошо. Но, например, белорусская криптография сейчас в
> GNU/Linux вообще не поддерживается, ни свободными, ни проприетарными
> средствами.

Стандарт опубликован? Сядь и напиши engine для openssl. Советами
всячески помогу. Заодно будет дополнительный аргумент в переговорах с
core team по поводу необходимости динамической подгрузки tls
ciphersuites. Японцы в этом плане моих надежд не оправдали. У них,
похоже, нет шифрсьютов на базе национального алгоритма подписи.

> А то сегодня мы сломаем одно, завтра другое, а потом окажется, что все
> это не так уж и нужно.

Так вот - речь идет о том, чтобы перепрыгивать пропасть мелкими шажками, 
НИЧЕГО в процессе не ломая. Принять сейчас необходимый минимум
архитектурных решений, обеспечивающих плавный переход от существующей
ситуации к желаемой, без регрессии на каком бы то ни было этапе.

Re: [devel] Вопросы новичка

[Alexey I. Froloff]

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

* Victor B. Wagner <vitus@> [090505 12:13]:
> > Пакет ca-certificates предоставляет хранилище trusted CA для тех
> > библиотек, которые в состоянии им пользоваться.  На данный момент
> > это только openssl.
> То есть на данный момент при модификации пакета openssl можно заодно и с
> ca-certificates делать все, что угодно? Никто не окажется несправедливо
> обиженным?
Скажем, так, мне бы не хотелось видеть cert-sh-functions вусмерть
разломанным.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.05 at 17:06:22 +0400, Alexey I. Froloff wrote:

> * Victor B. Wagner <vitus@> [090505 12:13]:
> > > Пакет ca-certificates предоставляет хранилище trusted CA для тех
> > > библиотек, которые в состоянии им пользоваться.  На данный момент
> > > это только openssl.
> > То есть на данный момент при модификации пакета openssl можно заодно и с
> > ca-certificates делать все, что угодно? Никто не окажется несправедливо
> > обиженным?
> Скажем, так, мне бы не хотелось видеть cert-sh-functions вусмерть
> разломанным.

Понятно. Вот один кандидат на должность того, кого надо не сломать.

Хотя в логике работы этого пакета надо бы поразбираться.

Во-первых, как я погляжу, он, если ему не указать более другого
конфигурационного файла OpenSSL, генерирует какой-то безумно древний
формат сертификата. Стандартного по X509v3 расширения
extendedKeyUsage = serverAuth не кладет, а вместо этого кладет
nsCertType, про который все уже давно забыли, что такое бывает.

Во-вторых, самоподписанные сертификаты - зло.  Они создают иллюзию
безопасности, не обеспечивая реальной защиты от MitM
Ни в коем случае нельзя генерировать самоподписанные сертификаты со
сроком действия год. Неделю - еще куда ни шло, месяц - ну, еще можно
перетерпеть. 

Понятно, что чтобы поднять и протестировать работоспособность сервиса
они годятся. Но нужно назойливо напоминать администратору, чтобы как
только так сразу, заменил самоподписанный сертификат на нормальный.
Пусть выписанный собственным УЦ, но с отдельным сертификатом УЦ,
с прописанным crlDistributionPoints и т.д.

Может быть имеет смысл включить в дистрибутив микро-УЦ, который бы
позволял на ходу генерировать нормальные сертификаты, и в случае если
этот пакет установлен и сконфигурирован, автоматически переключать
cert-sh-functions на использование этого УЦ.

Правда тут есть такая тонкость - postinst скрипты в Alt принципиально
неинтерактивные. А полноценный УЦ без хотя бы парольной защиты
секретного ключа, а лучше ключа на на каком-нибудь аппаратном токене -
не бывает.

Ну и в DN стоило бы писать побольше полезной информации.
Заявка, сгенерированная пакетом cert-sh-functions в существующем виде, 
не будет принята большинством УЦ по причине отсутствия в DN поля
emailAddress.

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/5 Victor B. Wagner <vitus@altlinux.org>:
> Лично я скорее за то, что бы в первую голову делать серверную часть,
> а десктопные применения - по остаточному принципу. Может быть, если бы у
> меня был в загашнике приличный браузер, использующий OpenSSL, я бы имел
> другую точку зрения.
Для того, чтобы что-то делать, нужно список задач составить и хотя бы
немного формализовать (оторвать от личных реалий). К этому я и
стараюсь подвести весь этот разговор. "Первая голова" или "вторая" --
это уже расстановка приоритетов, но ведь еще нет списка того, чему
приоритеты назначать.

>> И это хорошо. Но, например, белорусская криптография сейчас в
>> GNU/Linux вообще не поддерживается, ни свободными, ни проприетарными
>> средствами.
>
> Стандарт опубликован? Сядь и напиши engine для openssl. Советами
> всячески помогу. Заодно будет дополнительный аргумент в переговорах с
> core team по поводу необходимости динамической подгрузки tls
> ciphersuites. Японцы в этом плане моих надежд не оправдали. У них,
> похоже, нет шифрсьютов на базе национального алгоритма подписи.
Стандарт опубликован госстандартом. То есть, купить его можно в
БелГИСС, а вот насчет сделать публичным документацию из него,
сомневаюсь.

СТБ 1176.2-99 -- это вариант подписи Шнорра, свободные реализации
которой есть, например, на Perl: Crypt::Schnorr::AuthSign. Допустимые
значения параметров в СТБ 1176.2-99 описаны, см. тут:
http://kunegin.narod.ru/ref8/ecp/stb.htm, но их можно спокойно взять
из купленного СТБ.

http://www.nbrb.by/Legislation/GovernDocs/pdf/ElectronicSigning.pdf
содержит требования к реализации со стороны действующих законов. Эти
требования нормальные, не мешают кроссплатформенным реализациям.

СТБ 1176.1-99 описывает хэш-функцию, тоже скорее всего реализованную.
Найти в интернете не удалось, надо смотреть СТБ и книгу Харина: Харин
Ю. С., Берник В. И., Матвеев Г. В., Агиевич С. В. Математические и
компьютерные основы криптологии. -- Мн.: Новое знание, 2003. -- 320 с.

http://www.nbrb.by/Legislation/GovernDocs/pdf/PublicKeyCardFormat.pdf
описывает в приложениях А и Б вид карточки депонированного публичного
ключа. В приложении Б можно видеть как это будет для наших граждан.


Да и сам http://www.nbrb.by/Legislation/GovernDocs/
содержит руководящие документы, в которых даже описаны алгоритмы и
отличия этих алгоритмов от СТБ-шных для банковских сред (вплоть до
параметров и констант). Руководящие документы позволяют реализовать
все нужные алгоритмы для использования в банковской среде.

Я пытался поднять эту тему для студентов БГУ, однако довести до конца
не удалось. "Невидимая рука" мягко остановила создание свободной
конкуренции единственной сертифицированной конторе в РБ. :)

>> А то сегодня мы сломаем одно, завтра другое, а потом окажется, что все
>> это не так уж и нужно.
>
> Так вот - речь идет о том, чтобы перепрыгивать пропасть мелкими шажками,
> НИЧЕГО в процессе не ломая. Принять сейчас необходимый минимум
> архитектурных решений, обеспечивающих плавный переход от существующей
> ситуации к желаемой, без регрессии на каком бы то ни было этапе.
"Список, сестра!". Возвращаемся к тому же вопросу -- нужен список
задач/сценариев, которые можно приоритезировать и определить
необходимые шаги. Если тебе интересна серверная сторона, составь такой
список для серверной стороны.


-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.05 at 16:26:09 +0300, Alexander Bokovoy wrote:

> "Список, сестра!". Возвращаемся к тому же вопросу -- нужен список
> задач/сценариев, которые можно приоритезировать и определить
> необходимые шаги. Если тебе интересна серверная сторона, составь такой
> список для серверной стороны.

Лично у меня план действий такой:

1. Запакетировать openssl-1.0. С тем чтобы она максимально
соответстовала текущей полиси дистрибутива и перевод приложений на неё
был возможно более безболезненным. 

Собственно, все вопросы которые я здесь задаю, относятся к этому первому
пункту.

Сейчас, в связи с этим первым пунктом уже возникли вопросы, из которых,
возможно выкристаллизуются какие-то следующие пункты. Это 

- пакет ca-certificates, который надо обвесить какими-то утилитами для
поддержки в актуальном (для пользователя) состоянии списка сертификатов,
актуализации crl-ей и интероперабельности с другими библиотеками, дабы
добро зря не пропадало.
- пакет cert-sh-functions, который в данный момент направляет
пользователя по кривой дорожке создания небезопасных сертификатов.

С реализацией этих пунктов можно пока не торопиться.

2. Взаимодействие с мейнтейнерами тех приложений, которые вот прямо
сейчас могут получить расширение функциональности от перехода на
openssl-1.0, возможно, с применением каких-то патчей. Расширение
функциональности - это не обязательно поддержка новых (российских)
крипоалгоритмов. В OpenSSL 1.0 и другие вкусонсти есть, вроде
tls-extensions (которые частично бэкпортированы в 0.9.8f и выше) или
более полной поддержки CMS.

3. Все остальное, что может способствовать более правильному
использованию криптографии в рамках дистрибутива. В том числе и те,
выявившиеся в рамках дискуссии выше пункта.

Есть одно но - в какой-то, не очень далекий момент времени (порядка пары
месяцев) нужно будет
зафиксировать бинарники libcrypto и libssl от OpenSSL 1.0. 
Все изменения, внесенные в них после этого момента будут недоступны для
желающих использовать СЕРТИФИЦИРОВАННУЮ российскую криптографию. 

То есть в принципе, дистрибутив может включать и какие-то более новые
обновления и модификации. Но если потом на этот дистрибутив поставить
сертифицированный криптографический продукт, сделанный на базе OpenSSL
1.0, он принесет с собой зафиксированные на момент сертификации
бинарники.

То есть, мы, конечно будем пытаться вывести libcrypto и libssl из числа
сертифицированных бинарников, но не факт, что получится. 

Re: [devel] Вопросы новичка

[Max Ivanov]

> Во-первых, как я погляжу, он, если ему не указать более другого
> конфигурационного файла OpenSSL, генерирует какой-то безумно древний
> формат сертификата. Стандартного по X509v3 расширения
> extendedKeyUsage = serverAuth не кладет, а вместо этого кладет
> nsCertType, про который все уже давно забыли, что такое бывает.

> Пусть выписанный собственным УЦ, но с отдельным сертификатом УЦ,
> с прописанным crlDistributionPoints и т.д.

> Может быть имеет смысл включить в дистрибутив микро-УЦ, который бы
> позволял на ходу генерировать нормальные сертификаты, и в случае если
> этот пакет установлен и сконфигурирован, автоматически переключать
> cert-sh-functions на использование этого УЦ.

Есть такая штука tinyCA, очень удобная в админстве. Я так понимаю, что
ей можно скормить openssl.cnf и он начнет генерировать правильные
сертификаты, с правильным extendedKeyUsage и без дремучего nsCertType.
Вопрос только в том, где взять такой отшлифованный конфиг?

Re: [devel] Вопросы новичка

[Dmitry V. Levin]

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

On Mon, May 04, 2009 at 07:00:25PM +0400, Victor B. Wagner wrote:
> Я тут недавно, хотя, наверное многие из присуствующих меня знают давно.
> Присоединиться к разработке Alt я собрался с одной конкретной целью -
> сделать так, чтобы в дистрибутиве из коробки работала российская
> криптография, а переход на использование сертифицированной российской
> криптографии был бы совершенно безболезненен для пользователя/админа.
> 
> Поэтому первая задача, которую я перед собой ставлю - сборка OpenSSL 1.0
> beta последняя.

В какие сроки, если это уже понятно?

> В связи с этим у меня возник ряд вопросов по поводу того, почему OpenSSL
> запакетирван в Alt так, как это сделано.

У меня простая просьба, к сожалению, уже на будущее: не объединять ряд
вопросов в одном письме.  Иначе вероятность ответа снижается.


-- 
ldv

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

Re: [devel] alt-rpm signature verification

[Dmitry V. Levin]

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

On Mon, May 04, 2009 at 07:00:25PM +0400, Victor B. Wagner wrote:
> 1. Почему в Alt у rpm нет ключа --import.
> У всех rpm-based дистрибутивов есть, а у Alt нет.

У нас rpm был, как теперь говорят, форкнут, ещё тогда, когда у rpm не было
этого механизма.  И, если честно, мне этот механизм тогда показался неудобным.

> Решать эту задачу - импортировать ключ стороннего
> репозитория в кейринг RPM предлагается посредством
>    1. посмотреть значение макроса %_gpg_path

По умолчанию этот макрос не определён.

>    2. Ручками запустить gpg --import выставив ему этот путь в качестве
>    GPG_PATH

Да, этот вариант работает.


-- 
ldv

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

Re: [devel] Вопросы новичка

[Afanasov Dmitry]

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

On Tue, May 05, 2009 at 06:11:13PM +0400, Victor B. Wagner wrote:
> On 2009.05.05 at 16:26:09 +0300, Alexander Bokovoy wrote:
> > "Список, сестра!". 
> Лично у меня план действий такой:
> 
> 1. Запакетировать openssl-1.0. С тем чтобы она максимально
> соответстовала текущей полиси дистрибутива и перевод приложений на неё
> был возможно более безболезненным. 
мне как админу от сертификатов хотелось бы:
1. иметь "машинный" сертификат, которым автоматом бы подписывались все
остальные сервисные. подписать этот сертификат чем-нибудь другим, как я
помнимаю, можно и позже.

2. иметь возможность подставлять свои параметры в автогенерируемые
сертификаты: organization там, organizationUnit, ссылку на crl.

все пакеты, что используют ssl, при установке генерируют сертификаты.
как сделать эту генерацию интерактивной при установке пакета я не
представляю - rpm и все такое. но пусть хотя бы берут мои данные, а не
какой-нибудь cat << EOF | openssl req. и ещё и подпишутся напоследок
"машинным CA" :)

subject'ом таким сертификатам можно проставлять имя сервиса. ftp - для
ftp, mail - для MTA, etс. мыло - одно на всех мыло админа. suport@, или
личное.

> 2. Взаимодействие с мейнтейнерами
если что нужно сделать в gnutls - предлагайте. к сожалению, "как это
тикает" я не разобрался, но будет задача - будем думать :)


а в общем и целом, работающее россиская криптография - это было бы
здорово. опять таки как админ я всеми руками, временем и git.alt'ом за :) 
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] alt-rpm signature verification

[Afanasov Dmitry]

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

On Thu, May 07, 2009 at 01:35:14AM +0400, Dmitry V. Levin wrote:
> On Mon, May 04, 2009 at 07:00:25PM +0400, Victor B. Wagner wrote:
> > Решать эту задачу - импортировать ключ стороннего
> > репозитория в кейринг RPM предлагается посредством
> >    1. посмотреть значение макроса %_gpg_path
> 
> По умолчанию этот макрос не определён.
нашёл тут случайно - зато определен %_internal_gpg_path

получается команда GPG_PATH=`rpm --eval %_internal_gpg_path` gpg --import [files]
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] alt-rpm signature verification

[Victor B. Wagner]

On 2009.05.07 at 11:35:26 +0400, Afanasov Dmitry wrote:

> On Thu, May 07, 2009 at 01:35:14AM +0400, Dmitry V. Levin wrote:
> > On Mon, May 04, 2009 at 07:00:25PM +0400, Victor B. Wagner wrote:
> > > Решать эту задачу - импортировать ключ стороннего
> > > репозитория в кейринг RPM предлагается посредством
> > >    1. посмотреть значение макроса %_gpg_path
> > 
> > По умолчанию этот макрос не определён.
> нашёл тут случайно - зато определен %_internal_gpg_path
> 
> получается команда GPG_PATH=`rpm --eval %_internal_gpg_path` gpg --import [files]

Так может добавить в дистрибутив скриптик apt-key, 
который будет выглядеть примерно так

#!/bin/sh
GPG_PATH=`rpm --eval %_internal_gpg_path`
export GPG_PATH
command=$1
shift;
case "$command" in
add)
	gpg --import "$@"
	;;
del)
	gpg --delete-key "$1"
	;;
list)
	gpg --list-keys
	;;
*)
	echo "Usage apt-key add file|apt-key del keyid|apt-key list" 1>&2
	exit 1
	;;
esac

(на самом деле, конечно, внимательно почитать дебиановский apt-key,
там обойдены некоторые грабли, на которые могут наступить пользователи
вышеприведенного скрипта, да и функциональности чуточку побольше).

Тогда будет как-то проще использовать сторонние репозитории софта.

Re: [devel] alt-rpm signature verification

[Dmitry V. Levin]

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

On Thu, May 07, 2009 at 11:35:26AM +0400, Afanasov Dmitry wrote:
> On Thu, May 07, 2009 at 01:35:14AM +0400, Dmitry V. Levin wrote:
> > On Mon, May 04, 2009 at 07:00:25PM +0400, Victor B. Wagner wrote:
> > > Решать эту задачу - импортировать ключ стороннего
> > > репозитория в кейринг RPM предлагается посредством
> > >    1. посмотреть значение макроса %_gpg_path
> > 
> > По умолчанию этот макрос не определён.
> нашёл тут случайно - зато определен %_internal_gpg_path

Он на то и internal, чтобы его никто не трогал.

> получается команда GPG_PATH=`rpm --eval %_internal_gpg_path` gpg --import [files]

Файлы пакета alt-gpgkeys находятся в каталоге /usr/lib/alt-gpgkeys и не
должны меняться извне.


-- 
ldv

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

Re: [devel] alt-rpm signature verification

[Dmitry V. Levin]

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

On Thu, May 07, 2009 at 12:47:05PM +0400, Victor B. Wagner wrote:
[...]
> Так может добавить в дистрибутив скриптик apt-key, 
> который будет выглядеть примерно так
[...]
> (на самом деле, конечно, внимательно почитать дебиановский apt-key,
> там обойдены некоторые грабли, на которые могут наступить пользователи
> вышеприведенного скрипта, да и функциональности чуточку побольше).
> 
> Тогда будет как-то проще использовать сторонние репозитории софта.

Кто-то хочет этим заняться? ;)


-- 
ldv

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

Re: [devel] alt-rpm signature verification

[Evgeny Sinelnikov]

7 мая 2009 г. 19:37 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
>
> On Thu, May 07, 2009 at 12:47:05PM +0400, Victor B. Wagner wrote:
> [...]
> > Так может добавить в дистрибутив скриптик apt-key,
> > который будет выглядеть примерно так
> [...]
> > (на самом деле, конечно, внимательно почитать дебиановский apt-key,
> > там обойдены некоторые грабли, на которые могут наступить пользователи
> > вышеприведенного скрипта, да и функциональности чуточку побольше).
> >
> > Тогда будет как-то проще использовать сторонние репозитории софта.
>
> Кто-то хочет этим заняться? ;)
>

Я думаю, что для реализации дополнительного хранилища ключей,
достаточно, по аналогии с %_internal_gpg_path, добавить в rpm
обработку %_common_gpg_path, который стоит сложить, где это
принято...Например, в /usr/lib/common-gpgkeys. Тогда и результаты
работы, выше приведённого apt-key, не будут затёрты очередным
обновлением alt-gpgkeys. Кроме того, команду gpg --import [files] тоже
можно научить, по умолчанию обращаться в %_common_gpg_path.

Патчи на rpm принимаются? ;)

--
Sin (Sinelnikov Evgeny)

Re: [devel] alt-rpm signature verification

[Dmitry V. Levin]

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

On Thu, May 07, 2009 at 09:17:07PM +0400, Evgeny Sinelnikov wrote:
> 7 мая 2009 г. 19:37 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> > On Thu, May 07, 2009 at 12:47:05PM +0400, Victor B. Wagner wrote:
> > [...]
> > > Так может добавить в дистрибутив скриптик apt-key,
> > > который будет выглядеть примерно так
> > [...]
> > > (на самом деле, конечно, внимательно почитать дебиановский apt-key,
> > > там обойдены некоторые грабли, на которые могут наступить пользователи
> > > вышеприведенного скрипта, да и функциональности чуточку побольше).
> > >
> > > Тогда будет как-то проще использовать сторонние репозитории софта.
> >
> > Кто-то хочет этим заняться? ;)
> 
> Я думаю, что для реализации дополнительного хранилища ключей,

А зачем?  По какой причине не годится основное хранилище ключей?


-- 
ldv

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

Re: [devel] alt-rpm signature verification

[Mikhail Gusarov]

Twas brillig at 21:21:28 07.05.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:

 DVL> А зачем?  По какой причине не годится основное хранилище ключей?

Это alt-gpgkeys или какое-то другое?

-- 

Re: [devel] alt-rpm signature verification

[Evgeny Sinelnikov]

7 мая 2009 г. 21:22 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
>
> Twas brillig at 21:21:28 07.05.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:
>
>  DVL> А зачем?  По какой причине не годится основное хранилище ключей?
>
> Это alt-gpgkeys или какое-то другое?
>

Видимо, имеется в виду %_gpg_path. Но ответ тут прост. Дополнительное
нужно, чтобы не отрубалось "основное" из хомячка...
    /* Now run GPG */
    {
        const char *gpg_path = rpmExpand( "%{?_internal_gpg_path}", NULL );
        const char *gpg_home = ( gpg_path && *gpg_path ) ? gpg_path : 0;
        rpmVerifySignatureReturn res = gpg_home ?
                do_verifyGPGSignature( gpg_home, sigfile, datafile,
result ) : RPMSIG_NOKEY;
        gpg_path = _free( gpg_path );

        if ( RPMSIG_NOKEY == res )
        {
            gpg_path = rpmExpand( "%{?_gpg_path}", NULL );
            gpg_home = ( gpg_path && *gpg_path ) ? gpg_path : 0;
            res = do_verifyGPGSignature( gpg_home, sigfile, datafile, result );
            gpg_path = _free( gpg_path );
        }

        unlink(sigfile);
        return res;
    }

Если что-то задать путь "основного" иным, чем в хомячке, то, по
понятным причинам, перестаёт работать, например, rpm --addsign.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] alt-rpm signature verification

[Evgeny Sinelnikov]

7 мая 2009 г. 21:31 пользователь Evgeny Sinelnikov <sin@altlinux.ru> написал:
[...]
> Если что-то задать путь "основного" иным, чем в хомячке, то, по
> понятным причинам, перестаёт работать, например, rpm --addsign.
>

Да, в простейшем варианте хватило бы примерно такого патча:
--- signature.c 2009-05-07 22:13:02 +0400
+++ signature.c.new     2009-05-07 22:11:50 +0400
@@ -814,6 +814,8 @@
            gpg_path = rpmExpand( "%{?_gpg_path}", NULL );
            gpg_home = ( gpg_path && *gpg_path ) ? gpg_path : 0;
            res = do_verifyGPGSignature( gpg_home, sigfile, datafile, result );
+          if ( gpg_home && RPMSIG_NOKEY == res )
+              res = do_verifyGPGSignature( 0, sigfile, datafile, result );
            gpg_path = _free( gpg_path );
        }

Но этот вариант использования "основного" хранилища не очень удобен
при работе нескольких пользователей... Получается, что добавление
общих ключей, если это нужно, а именно это нужно при работе со
сторонними репозиториями, является не системной настройкой. доступной
всем, а частной настройкой отдельных пользователей... Тех, кто задал
себе нужный %_gpg_path.

Хотелось бы иметь локальный, не обновляемый из вне, аналог
alt-gpgkeys. Думаю, что common-gpgkeys, по названию, подходит :)

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Вопросы новичка

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

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

On Tue, May 05, 2009 at 02:47:33PM +0300, Alexander Bokovoy wrote:

>> Из приложений, которые используют обычный tls, единственное на сей
>> момент найденное приложение, которому требуется нетривиальный патч - это
>> Apache (насколько понимаю, в случае Maemo - не шибко интересно).
AB> Поэтому я и отделяю централизацию и поддержку российской криптографии.
AB> Первое полезно всем пользователям ALT, второе имеет смысл для
AB> некоторого специфического круга бизнесов и лиц внутри РФ. ALT
AB> используется не только в РФ.

Среди этого некоторого специфического круга лиц сейчас пользователи
клиент-банков для юрлиц. Все клиент-банки с которыми я сталкивался
используют те или иные средства для реализации российских
криптоалгоритмов.

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

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

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

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.08 at 01:26:35 +0400, Денис Смирнов wrote:

> Среди этого некоторого специфического круга лиц сейчас пользователи
> клиент-банков для юрлиц. Все клиент-банки с которыми я сталкивался
> используют те или иные средства для реализации российских
> криптоалгоритмов.

К сожалению, появление в Alt хоть какой-то реализации российской
криптографии, даже вкупе с поддержкой RFC4490 и русской TLS, не означает автоматической возможности работы с любым клиент-банком только средствами 
софта включенного в дистрибутив.

Возможно, конечно, в ближайшие лет несколько клиент-банки начнут
делаться на Web-технологиях. Мы, во всяком случае приложим все усилия
чтобы оно было именно так. Но опять-таки lynx и wget для этого будет
недостаточно. Нужен будет браузер с полноценной по нынешним временам
реализацией javascript и поддержкой российской криптографии в объекте
window.crypto.

К сожалению, все мои эксперименты на эту тему с webkit-based браузерами
пока что привели к убеждению, что там и с RSA-то все плохо.

Re: [devel] Вопросы новичка

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

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

On Fri, May 08, 2009 at 11:41:57AM +0400, Victor B. Wagner wrote:

VBW> К сожалению, появление в Alt хоть какой-то реализации российской
VBW> криптографии, даже вкупе с поддержкой RFC4490 и русской TLS, не означает автоматической возможности работы с любым клиент-банком только средствами 
VBW> софта включенного в дистрибутив.

Разумеется, однако появление такого решения может быть поводом для
разработчиков клиент-банков делать хоть какую-то совместимость.

В настоящий момент нормально работает под Linux, например, клиент-банк
Ibank (от БИФИТ). Но во-первых i586-only, а во-вторых собственно сборка
выполняется самим банком, и далеко не каждый банк выкладывает
линукс-версию (которая отличается от виндовой только тем что приложены
криптобиблиотеки в виде shared objects, видимо через JNI подгружаемых).

VBW> Возможно, конечно, в ближайшие лет несколько клиент-банки начнут
VBW> делаться на Web-технологиях. Мы, во всяком случае приложим все усилия
VBW> чтобы оно было именно так. Но опять-таки lynx и wget для этого будет
VBW> недостаточно. Нужен будет браузер с полноценной по нынешним временам
VBW> реализацией javascript и поддержкой российской криптографии в объекте
VBW> window.crypto.
VBW> К сожалению, все мои эксперименты на эту тему с webkit-based браузерами
VBW> пока что привели к убеждению, что там и с RSA-то все плохо.

Грустно это. Я так понимаю сейчас webkit хоть и заметно отстает от
mozilla-based, но можно ожидать в скором времени что он будет успешно
отвоевывать рынок у огнелиса?

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

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

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

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/8 Денис Смирнов <mithraen@altlinux.ru>:
> On Fri, May 08, 2009 at 11:41:57AM +0400, Victor B. Wagner wrote:
>
> VBW> К сожалению, появление в Alt хоть какой-то реализации российской
> VBW> криптографии, даже вкупе с поддержкой RFC4490 и русской TLS, не означает автоматической возможности работы с любым клиент-банком только средствами
> VBW> софта включенного в дистрибутив.
>
> Разумеется, однако появление такого решения может быть поводом для
> разработчиков клиент-банков делать хоть какую-то совместимость.
>
> В настоящий момент нормально работает под Linux, например, клиент-банк
> Ibank (от БИФИТ). Но во-первых i586-only, а во-вторых собственно сборка
> выполняется самим банком, и далеко не каждый банк выкладывает
> линукс-версию (которая отличается от виндовой только тем что приложены
> криптобиблиотеки в виде shared objects, видимо через JNI подгружаемых).
Меня вот поражает, почему западные банки могут делать и использовать
клиент-банки, в которых от клиента не требуется практически ничего,
кроме стандартного HTTPS/SSL и бумажной книжки с кодами, а российские
банки так работать еще не научились.

Допустим, в эту SSL-TLS обертку будут взяты не RSA, а ГОСТированные
алгоритмы, неужели все равно нужно городить огород из Java или других
технологий там, где можно обойтись традиционными кодовыми таблицами?
Подавляющее большинство банков в скандинавских странах работают именно
так, с кодовыми таблицами, значения из которых вводят пользователи и
не заморачиваются с типом операционной системы, все поддерживается
автоматом.

/me отвлекся от технической темы.
-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Andrey Rahmatullin]

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

On Sat, May 09, 2009 at 08:48:08AM +0300, Alexander Bokovoy wrote:
> Меня вот поражает, почему западные банки могут делать и использовать
> клиент-банки, в которых от клиента не требуется практически ничего,
> кроме стандартного HTTPS/SSL и бумажной книжки с кодами, а российские
> банки так работать еще не научились.
https://demo.bank24.ru/

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

В ALT Linux сделано так, чтобы по ошибке "под рутом в иксах работать было
нельзя. И правильно сделано."  
		-- ldv in community@

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

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/9 Andrey Rahmatullin <wrar@altlinux.ru>:
> On Sat, May 09, 2009 at 08:48:08AM +0300, Alexander Bokovoy wrote:
>> Меня вот поражает, почему западные банки могут делать и использовать
>> клиент-банки, в которых от клиента не требуется практически ничего,
>> кроме стандартного HTTPS/SSL и бумажной книжки с кодами, а российские
>> банки так работать еще не научились.
> https://demo.bank24.ru/
Там используется one-time pad?
http://users.telenet.be/d.rijmenants/en/onetimepad.htm
-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/9 Andrey Rahmatullin <wrar@altlinux.ru>:
> On Sat, May 09, 2009 at 08:48:08AM +0300, Alexander Bokovoy wrote:
>> Меня вот поражает, почему западные банки могут делать и использовать
>> клиент-банки, в которых от клиента не требуется практически ничего,
>> кроме стандартного HTTPS/SSL и бумажной книжки с кодами, а российские
>> банки так работать еще не научились.
> https://demo.bank24.ru/
Там используется one-time pad?
http://users.telenet.be/d.rijmenants/en/onetimepad.htm

-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Andrey Rahmatullin]

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

On Sat, May 09, 2009 at 09:04:12AM +0300, Alexander Bokovoy wrote:
> > https://demo.bank24.ru/
> Там используется one-time pad?
> http://users.telenet.be/d.rijmenants/en/onetimepad.htm
Да, карточки с циферками.
Но это только для физиков. Для юриков бифитовская Java.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Если root не видит разницы между url, именем файла и именем
пакета -- он или пьян в дым, или эквивалентен.
		-- mike in devel@

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