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

[Alexander Bokovoy <ab@altlinux.org>]

2009/5/7 Victor B. Wagner <vitus@altlinux.org>:
>> Чем он кому-то не угодил ?
>
> Требования, предьявляемые к сертифицированным средствам
> криптографической защиты вступают в прямое противоречие с по крайней
> мере с духом (L)GPL.
>
> Не уверен, что не вступают в противоречие и с буквой v3. Я не юрист, а
> тут нужно в юридическом крючкотворстве разбираться.
>
> (L)GPL требует предоставить пользователю свободу модифицировать софт.
> А сертифицирующие органы сертифицируют определенный бинарник, и любой
> секьюрити фикс или пересборка под более новый дистрибутив требует
> пересертификации.
LGPL требует, чтобы пользователь мог заменить LGPL компоненту
закрытого решения без необходимости пересобирать это решение заново.
Сертифицированная версия LGPL компоненты формально такому
удовлетворяет, поскольку само понятие сертификата вынесено за пределы
LGPL, а потому никаким образом не фигурирует в требованиях лицензии.
То, что при этом пользователь может потерять (другой) сертификат -- не
проблема LGPL.

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

> Мы, конечно, можем предоставить ради удовлетворения буквы LGPL исходники
> наших модификаций. Но то, что пользователи из них соберут,
> сертифицированным уже не будет (собственно поэтому нам абсолютно не
> жалко эти модификации  раздавать). А по-моему GPLv3 подобные выкрутасы
> явно змпрещает.
Запрещено несколько другое -- невозможность эксплуатации замененного
кода на оригинальном программно-аппаратном комплексе. Требования
государственной сертификации не имеют отношения к условиям, в которых
осуществляется право пользователя на модификацию кода и запуск его в
оригинальных условиях. Проблемы взаимодействия частно-собственнических
лицензионных соглашений и государственной тайны/законов страны
использования не имеют никакого отношения к коду. Гостайной, например,
можно вообще все что угодно закрыть и что?

> Далее, (L)GPL требует предоставить пользователю свободу дальнейшего
> распространения софта. А для сертифицированных криптосредств существует
> поэкземплярный учет.
Насколько я понимаю, неотъемлемой частью такого сертифицированного
криптосредства является материальная сущность "бумажка",
распространение которой ограничено ее уникальным контролируемым
происхождением без возможности признания подделки за легитимную копию.
Соответственно, свободное распространение кода возможно, а свойства
сертифицированности -- нет. Но это не имеет никакого отношения к LGPL,
как я уже указал выше.

> В случае с OpenSSL с её BSD-like лицензией я по крайней мере уверен, что
> распространяя сертифицированные бинарники, собранные из доступных
> сообществу исходников, мы ничего не нарушаем.
>
> В случае LGPL я как-то не очень в этом уверен.
IANAL и все такое, но если учесть, что nss сертифицирована под тройной
лицензией, включая LGPL, и при этом также сертифицирована по
стандартам США, как и openssl, это по крайней мере показывает, что на
западном рынке проблема не существует в том виде, в котором ты ее
формулируешь.
-- 
/ Alexander Bokovoy