Статус: Сотрудник
Группы: Участники
Зарегистрирован: 20.02.2017(UTC)
Сообщений: 216
Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 62 раз в 58 постах
|
Автор: Андрей Врагов  Автор: Артём Макаров Автор: Андрей Врагов Коллеги из КриптоПро,
можете поподробнее просветить, для чего при установке CoreFx также копировать сборки NetStandard? Я так думал, что вы пропатчили сам CoreFx нашей криптографией, а по сему достаточно добавить только ссылки на сборки System.Security.Cryptography.Pkcs и System.Security.Cryptography.Xml. В чем смысл добавления сборок NetStandard причем не из самого CoreFx? Вызвано особенностью инфраструктуры исходного проекта. Сборки Xml и Pkcs явно не зависят от сборок криптографии из рантйма, а зависят от нетстандарта, который является "прослойкой". Т.е. если сборка xml желает воспользоваться криптографией она использует нужные классы из нетстандарта, который вызывает из уже из самого рантайма. Так как мы изменили рантайм, добавив в него гостовые классы, про которые родной стандарт не знает - пришлось модифицировать и стандарт, дабы Xml и Pkcs могли ими пользоваться. Сам код стандарта представляет из себя лишь "переброску" классов из рантайма, никокй дополнительной логики, кроме инфраструктурной, там нет. Сам проект стандарта содержит api классов и указание на сборки с реализациями этого api (т.е. ссылка на рантайм). Артем, а можно более детально? Насколько я понимаю в глубинах .Net, каждый проект имеет несколько типов зависимостей. Первый тип - зависимость от фреймворка, создается автоматически при указании типа проекта. Например, собственно Net Core - выполняет базовые вещи, Asp Net Core - поддержка Web проектов, WindowsDesktop - поддержка UI для десктопных проектов и т.п. Каждый фреймворк содержит необходимый набор сборок. Кстати, мне непонятно, почему стандартно сборки System.Security.Cryptography.Pkcs и System.Security.Cryptography.Xml входят во фреймворк Asp Net Core, а не в базовый Net Core. Не по этой ли причине по вашей инструкции их необходимо добавлять в файле проекта? Вторая зависимость это бинарные пакеты (nuget), которые де факто являются расширением функционала фреймворков. Третья - это отдельные сборки. В нашем случае мы как раз таким образом указываем сборки Pkcs и Xml. Четвертая - это другие проекты, включенные в solution. Первый вопрос, в какой последовательности .Net осуществляет поиск сборок, с требуемыми классами? Поясню. Если, например, проект зависит от фреймворка Asp Net Core, а также в файле проекта отдельно прописаны сборки Pkcs и Xml, то откуда данные сборки будут браться для помещения в папку bin при компиляции проекта? Второй вопрос. В моем тестовом приложении есть такой код: Код:
var signerCert = SelectCertificate();
var ci = new ContentInfo(new Oid(NativeConstants.szOID_PKCS_7_DATA), raw);
var cms = new SignedCms(ci);
var attr = new CryptographicAttributeObject(new Oid(NativeConstants.szOID_ENROLLMENT_NAME_VALUE_PAIR));
var asn = new AsnEncodedData(TemplateEncoder.Encode(attrNVCertTemplate.pwszValue));
attr.Values.Add(asn);
if (signerCert != null)
{
var digestAlgorithm = new Oid(SelectDigestAlgorithmByCertificate(signerCert));
var signer = new CmsSigner() { IncludeOption = X509IncludeOption.EndCertOnly, Certificate = signerCert, DigestAlgorithm = digestAlgorithm };
signer.SignedAttributes.Add(attr);
cms.ComputeSignature(signer, true);
var cms2 = new SignedCms(new ContentInfo(new Oid(NativeConstants.szOID_PKCS_7_DATA), cms.Encode()));
cms2.ComputeSignature(signer, true);
Проект настроен по образу и подобию с вашим тестовым проектом из CoreFx. Ошибка вылетает при вызове метода ComputeSignature. Что где посмотреть? Может я что-то пропустил? Причем сначала все работало, но потом что-то случилось. Поэтому и пытаюсь понять детали в организации ваших патчей и прочего. Pkcs и Xml сборки распространяются ms отдельно, в качестве nuget пакетов, зависят от рантайма, как я писал выше, через стандарт. Поэтому их приходится указывать отдельно от указания пакета с рантаймом. Классы и сборки форка рантайма от обычных сборок никак не отличаются. В проект они добавляются просто как ещё один нугет пакет (тот самый, который указывается в csproj, Microsoft.Private.CoreFx.NETCoreApp), с указанием, что в случае конфликтов используйте те, что указаны в данном нугет пакете (что делается указанием PackageConflictPreferredPackages). Т.е. фактически вы говорите компилятору - вот тебе ещё один пакет, в котором реализованы все классы из рантайма и бери их пожалуйста именно оттуда, а не из исходного рантайма. Никакой дополнительной логики поверх этого нет. Также строго зависим от конкретной версии рантайма, ибо при несовпадении версий дотнет любит всё равно подкладывать сборки из исходного рантайма. Поэтому просим устанавливать именно указанные версии sdk и рантаймов. Поиск сборок при исполнении тоже не обладает какими либо особенностями, выполняется обычный поиск сборок. Повторюсь - наш форк это просто пакет со сборками. Отредактировано пользователем 29 сентября 2022 г. 13:41:27(UTC)
| Причина: Не указана |
|
