Глобальный КЕШ сборок и отложенное подписание в .NET Framework

В качестве части установки .NET Framework на компьютере создается центральный репозиторий для хранения сборок .NET, который называется глобальным кешем сборок (Global Assembly Cache — GAC). Глобальный кеш сборок содержит централизованную копию самой платформы .NET Framework, и в него также можно помещать и собственные сборки.

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

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

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

• Развертывание XCOPY или ClickOnce больше невозможно; для установки приложения потребуются административные привилегии;

• Для обновления сборок в GAC также нужны административные привилегии;

• Применение GAC может усложнить разработку и тестирование, поскольку механизм загрузки сборок CLR (fusion) всегда отдает предпочтение сборкам GAC перед локальными копиями;

• Поддержка версий и выполнение бок о бок требует некоторого планирования, и какая-то ошибка может нарушить работу других приложений;

В качестве положительной стороны, GAC может улучшить показатели времени запуска для очень крупных сборок, т.к. CLR проверяет подписи сборок в GAC только при их установке туда, а не каждый раз, когда сборка загружается. В процентном отношении это имеет значение, если для сборок генерируются образы в машинном коде с помощью инструмента gltg.ехе с выбором неперекрывающихся базовых адресов.

Отложенное подписание

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

• если произойдет утечка пары ключей, ваши сборки больше не будут защищены от подделки;

• если произойдет утечка подписанной тестовой сборки, злоумышленники ее могут выдавать за реальную сборку.

С другой стороны, сокрытие пар ключей от разработчиков означает невозможность компиляции и тестирования ими сборок с корректными удостоверениями. Отложенное подписание — это система, позволяющая обойти эту проблему.

Сборка с отложенной подписью помечается правильным открытым ключом, но не подписывается посредством секретного ключа. Сборка с отложенной подписью эквивалентна поддельной сборке и обычно отклоняется средой CLR. Однако разработчик инструктирует CLR о необходимости пропускать проверку достоверности сборок с отложенной подписью на данном компьютере, позволяя неподписанным сборкам запускаться. Когда наступает время для окончательного развертывания, обладатель секретного ключа подписывает сборку с помощью действительной пары ключей.

Для отложенного подписания необходим файл, содержащий только открытый ключ. Его можно извлечь из пары ключей, запустив утилиту snc переключателем -р:

sn -k KeyPair.snk

sn -р KeyPair.snk PublicKeyOnly.pk

Файл Key Pair. snk останется защищенным, a PublicKeyOnly. pk можно свободно распространять.

Получить PublicKeyOnly.pk можно также из существующей подписанной сборки, указав переключатель -е:

sn -е YourLibrary.dll PublicKeyOnly .pk

После этого можно осуществить собственно отложенное подписание с применением PublicKeyOnly.pk, запустив компилятор esc с переключателем /delaysign+:

esc /delaysign+ /keyfile: PublicKeyOnly.pk /target:library YourLibrary.es

Среда Visual Studio сделает то же самое, если отметить флажок Delay sign (Отложенное подписание).

На следующем шаге исполняющей среде .NET сообщается, что она должна пропускать проверку удостоверений сборок на компьютерах разработки, выполняющих сборки с отложенным подписанием. Это можно сделать либо на основе сборок, либо на основе открытых ключей, запуская утилиту snc переключателем Vr:

sn -Vr YourLibrary.dll

Среда Visual Studio не выполняет этот шаг автоматически. Проверку достоверности сборок потребуется отключить вручную в командной строке.

В противном случае сборка с отложенной подписью запускаться не будет.

Последний шаг заключается в полном подписании сборки перед развертыванием. Именно на этом этапе пустая подпись заменяется реальной подписью, которая может быть сгенерирована только за счет доступа к секретному ключу. Чтобы сделать это, утилита sn запускается с переключателем R:

sn -R YourLibrary.dll KeyPair.snk

После этого можно восстановить проверку достоверности сборок на машинах разработки:

sn -Vu YourLibrary.dll

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

Автор: BOMBERuss

Егор Юрьевич Андреев

Полезная статья? Поделись ей с друзьями. Им будет интересно)))

Дата последнего изменения: