ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Victor B. Wagner" <vitus@altlinux.org>
To: devel@lists.altlinux.org
Subject: Re: [devel] Вопросы новичка
Date: Tue, 5 May 2009 14:36:49 +0400
Message-ID: <20090505103649.GH2101@cryptocom.ru> (raw)
In-Reply-To: <6062a6e60905050243u4642085ap7abe66a302b1d96e@mail.gmail.com>

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 - не шибко интересно).



  reply	other threads:[~2009-05-05 10:36 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-04 15:00 Victor B. Wagner
2009-05-04 15:06 ` Andrey Rahmatullin
2009-05-04 15:22   ` Victor B. Wagner
2009-05-04 15:24     ` Mikhail Gusarov
2009-05-04 15:27       ` Andrey Rahmatullin
2009-05-04 15:27 ` Alexey I. Froloff
2009-05-04 15:51   ` Victor B. Wagner
2009-05-04 16:51     ` Max Ivanov
2009-05-04 17:31     ` Alexey I. Froloff
2009-05-05  8:10       ` Victor B. Wagner
2009-05-05 13:06         ` Alexey I. Froloff
2009-05-05 13:25           ` Victor B. Wagner
2009-05-05 15:06             ` Max Ivanov
2009-05-04 17:44   ` Alexander Bokovoy
2009-05-05  8:39     ` Victor B. Wagner
2009-05-05  9:43       ` Alexander Bokovoy
2009-05-05 10:36         ` Victor B. Wagner [this message]
2009-05-05 11:47           ` Alexander Bokovoy
2009-05-05 12:16             ` Victor B. Wagner
2009-05-05 12:44               ` Alexander Bokovoy
2009-05-05 12:57                 ` Victor B. Wagner
2009-05-05 13:26                   ` Alexander Bokovoy
2009-05-05 14:11                     ` Victor B. Wagner
2009-05-07  6:13                       ` Afanasov Dmitry
2009-05-07 21:26             ` Денис Смирнов
2009-05-08  7:41               ` Victor B. Wagner
2009-05-08 16:38                 ` Денис Смирнов
2009-05-09  5:48                   ` Alexander Bokovoy
2009-05-09  5:50                     ` Andrey Rahmatullin
2009-05-09  6:04                       ` Alexander Bokovoy
2009-05-09  6:06                         ` Andrey Rahmatullin
2009-05-09  6:04                       ` Alexander Bokovoy
2009-05-06 21:26 ` Dmitry V. Levin
2009-05-06 21:35 ` [devel] alt-rpm signature verification Dmitry V. Levin
2009-05-07  7:35   ` Afanasov Dmitry
2009-05-07  8:47     ` Victor B. Wagner
2009-05-07 15:37       ` Dmitry V. Levin
2009-05-07 17:17         ` Evgeny Sinelnikov
2009-05-07 17:21           ` Dmitry V. Levin
2009-05-07 17:22             ` Mikhail Gusarov
2009-05-07 17:31               ` Evgeny Sinelnikov
2009-05-07 18:23                 ` Evgeny Sinelnikov
2009-05-07 15:36     ` Dmitry V. Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090505103649.GH2101@cryptocom.ru \
    --to=vitus@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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