Re: Репозиторий

[Victor Wagner <vitus@wagner.pp.ru>]

On Fri, 14 Aug 2015 10:57:07 +0300
Dmitry Belyavsky <beldmit@gmail.com> wrote:

> Привет!
> 
> 2015-08-14 10:48 GMT+03:00 Victor Wagner <vitus@wagner.pp.ru>:
> 
> > On Fri, 14 Aug 2015 08:49:54 +0300
> > Dmitry Belyavsky <beldmit@gmail.com> wrote:
> >
> >
> > >
> > > Ну ок. Для начала можно явно делать так, как ты говоришь.
> > >
> >
> > Попробовал. Оказывается не так всё там просто.
> >
> > Там в toplevel MAkefile Configure пишет уйму полезных переменных,
> > которые бы надо как-то себе втянуть (см переменную BUILDENV в этом
> > самом toplevel Makefile). А include в makefile непереносимый между
> > разными make.
> >
> > Кроме того, для того чтобы оно хоть как-то собиралось потребовалось
> > во всех строчках сгенерированных make depend поменять ../.. на
> > $(TOP). Там полно зависимостей от заголовочных файлов самой OpenSSL.
> >
> > В общем еще надо думать как это собирать. Очевидно одно - если мы
> > как-то переменные, описанные в BUILDENV к себе не втащим, соберется
> > типичное не то. Хотя бы CROSS_COMPILE и CFLAG
> >
> 
> А opensc свой engine как собирает, интересно?

У opensc там честный автоконфовский configure. Что, кстати, тоже вариант
для создания отдельной build system. Но opensc куда в меньшей степени
завязана на кишки openssl, чем мы. 

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

Еще можно попытаться воспользоваться pkgconfig-ом. Благо Openssl
pkgconfig-овские описания генерирует. Но как с этим работать в случае
кросс-компиляции тоже глубоко не понятно --cross-compile-prefix туда не
кладется.


> Кстати, я уже не помню, как правильно обеспечить независимость от
> NID-ов в родной поставке openssl.

Насколько я помню, мы писали во все инициализированные структуры
NID_undef, потом делали OBJ_create со статическими строками и
полученный нид прописывали куда надо уже в рантайме.

На мой взгляд, более правильным будет следующее:

1. Позвать OBJ_txt2nid на dotted-decimal представление OID, если оно
есть, и на short name, если это, скажем nid некоего режима шифрования.
не имеющего своего OID.

2. Если вернуло не NID_undef, использовать (прописать в
инициализированные структуры) именно его.

3. Если вернуло NID_undef, звать OBJ_create, но передавать туда
динамически размещенные копии всех строк. 

4. При выгрузке engine OBJ_cleanup не делать.

Тогда получается, что при первой загрузке engine мы загрузим в object
database все нужные нам OID-ы которых там изначально не было, и там они
и останутся до конца жизни процесса. Если engine выгрузят и загрузят
повторно, она найдет те же NID-ы, которые были созданы первой копией.

Если же часть (произвольная) OID-ов в Object Database была, то мы будем
использовать те NID-ы, которые были.

P.S. Я там написал на гитхабе корневую страницу wiki, прописав ссылки
на все RFC, которые помнил. Надо еще туда дописать ссылки на TLS-ный
драфт и на те документы ТК26, которые в открытом доступе. Желательно,
конечно, чтобы в итоге получился полный набор нормативной документации.

То что там я написал про сборку я потом стал проверять, и получилось что
оно неправильно. А ссылку на README.gost надо будет подправить после
того, как ты его туда зальешь.