Проверка строгих имен использует только токен открытого ключа?

Я сделал следующий опыт:

  • Создал консольное приложение и dll
  • Создан ключевой файл строгого имени
  • Извлечен открытый ключ из файла ключей строгого имени
  • Задержка подписания как консольных, так и dll-приложений открытым ключом
  • (1) Консольное приложение успешно вызвало DLL
  • Подписанное консольное приложение с файлом ключа строгого имени (включая закрытый ключ)
  • (2) Консольное приложение успешно вызвало DLL.

Теперь, в (1) я предполагаю, что это правильное поведение, потому что подписи из обоих файлов должны быть одинаковыми, пустыми, но в ситуации (2) публичный токен должен быть таким же, но подписи должны быть разными, в в консольном приложении подпись должна быть заполнена, а в dll пусто, поэтому консольное приложение не должно вызывать dll.

Это наводит меня на мысль, что при проверке строгого имени используется только токен открытого ключа, правда ли это?


person lulas    schedule 08.09.2017    source источник


Ответы (1)


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

Вот почему вам не нужно изменять (перестраивать) ссылку в exe после полной подписи dll.

Однако отложенная подписанная сборка не будет содержать подписи, подтверждающей, что она была подписана закрытым ключом (по уважительной причине: она не была подписана закрытым ключом).

Эта подпись не является частью полного имени, поэтому сборка по-прежнему будет соответствовать полному имени полностью подписанной сборки.

По умолчанию загрузка сборки отклоняется, если она подписана с задержкой. Не потому, что его полное имя не совпадает, а потому, что сборка не проходит проверку подписи.

Если вы использовали sn.exe для отключения проверки подписи, строгое имя dll будет принято без проверки соответствующей подписи. Это будет иметь место независимо от того, полностью ли подписан исполняемый файл, вызывающий dll, или нет.

Если вы не использовали sn.exe для отключения проверки, я бы ожидал, что exe вообще не запустится.

Если вы использовали sn.exe для отключения проверки всех сборок с использованием открытого ключа, я бы ожидал, что exe запустится и вызовет dll без проблем. Это делается с помощью:

sn.exe -Vr *,<publicKeyToken>

Если вы использовали sn.exe для отключения проверки для exe только при оставлении активной проверки для dll, я бы ожидал, что exe запустится, но не удастся вызвать dll. Это делается с помощью:

sn.exe -Vr <dllAssemblyName>,<publicKeyToken>

Чтобы убедиться, что проверка сборки не пропущена, используйте:

sn.exe -Vx

или использовать

sn.exe -Vu <dllAssemblyName>,<publicKeyToken>

для выборочного включения проверки, используя тот же синтаксис, что и с -Vr.

Существует как 32-битный, так и 64-битный sn.exe. Они влияют на 32- и 64-битные процессы соответственно. Я бы рекомендовал всегда запускать команды sn.exe в обоих, чтобы избежать сюрпризов.

person Lars Møllebjerg    schedule 08.09.2017
comment
Проверка не была отключена. Что подтверждается в этой проверке? подпись сборки или название сборки? - person lulas; 08.09.2017
comment
Изменен ответ, чтобы было понятнее, что проверка относится к проверке правильности подписи сборки. Добавлена ​​информация о том, как повторно включить проверку подписи. Я не знаю вашу среду, но, возможно, она была отключена без вашего внимания, например, сценарием сборки и т. Д. По крайней мере, там, где я работаю, некоторые сценарии развертывания разработки сделают это автоматически. - person Lars Møllebjerg; 08.09.2017