Какая точка задержки подписания сборки .NET?

Я заметил, что после того, как я использую AssemblyDelaySignAttribute, чтобы указать, что сборка находится в разработке и не нужно подписывать сейчас, мне придется использовать sn -Vr foolib.dll, чтобы зарегистрироваться для надежной проверки имени отключено для этой сборки.

Какой смысл делать этот круг? Почему бы просто не оставить сборку без знака до ее полного завершения? Разве это не беспокоит?

Ответ 1

Несколько причин...

  • Ассембли без сильного имени не могут быть добавлены в GAC
  • В связи С# 1 сборки, не входящие в GAC, не приносят пользы от NGEN
  • Сильные именованные сборки демонстрируют различное поведение, когда речь идет о сборочном зондировании и загрузке с частичными именами.
  • Ассембли без сильного имени не могут ссылаться на сильную именованную сборку

Итак, в организациях, где процесс подписи жестко контролируется, это помогает уметь подделывать его для разработки.

Ответ 2

От AssemblyDelaySignAttribute Class

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

Ответ 3

Это сценарий, который предотвращает задержку подписи:

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

Цель "Подписание задержки" заключается в том, что только разработчики сборки имеют доступ к подписи. Это, теоретически, уменьшает количество людей, которым нужно неявно доверять исходному коду. Предполагается, что разработчики программного обеспечения будут отключать (игнорировать) проверку сильных имен при их создании и отладке.