.NET: строгое именование против Authenticode

Прочитав о строгих именах в .NET вот, например, у меня такой вопрос:

У нас есть сертификат подписи кода Authenticode, которым мы подписываем все наши файлы EXE, DLL и MSI. Преимущество этого состоит в том, что Windows знает, что MSI поступает из надежного источника, а также что при необходимости можно проверить подлинность каждого файла.

В настоящее время мы не используем строгие имена .NET. Я читал, что строгое именование файла по сути означает, что он имеет цифровую подпись с помощью самозаверяющего сертификата. Мое мнение по этому поводу заключается в том, что сертификат Authenticode, подписанный доверенным центром сертификации, намного более ценен, чем самозаверяющий сертификат, подлинность которого никто не может проверить в любом случае, потому что у них нет корневого сертификата (и мы не собираемся распространять его среди конечных пользователей, мы!?).

Вопрос. Есть ли какое-либо значение в сборках со строгим именованием дополнительно, если подписывание Authenticode уже используется?


person Helge Klein    schedule 17.12.2010    source источник


Ответы (1)


Ответ будет зависеть от того, почему вы создали строгое имя - строгое имя предполагается использовать для создания уникального идентификатора для сборки. Например, если вам нужно отправить свою сборку в GAC, тогда строгое имя обязательно. Однако строгое имя на самом деле не предназначено для проверки подлинности издателя - Authenticode служит этой цели. См. Эту статью: http://blogs.msdn.com/b/shawnfa/archive/2005/12/13/authenticode-and-assemblies.aspx.

person VinayC    schedule 17.12.2010
comment
Так что мне нужны строгие имена только для того, чтобы помещать мои сборки в GAC. Мы не помещаем туда свои сборки, поэтому строгие имена не нужны. - person Helge Klein; 17.12.2010
comment
Это не полностью для публикации в GAC - его также можно использовать, чтобы убедиться, что библиотеки DLL, на которые ссылается ваше приложение, соответствуют вашим намерениям, поскольку строгое имя требует, чтобы все библиотеки DLL, на которые есть ссылки, также имели строгие имена. , он предотвращает замену вредоносной библиотеки DLL. Опять же, это не подтверждает, кто его написал, но гарантирует, что все сборки были написаны кем-то с доступом к одному и тому же SNK. - person Basic; 19.12.2010
comment
Чтобы добавить к удивительным ответам @ Basic, одним из примеров является библиотека microsoft dll от nuget, которую вы можете добавить в свой проект. Если вы попытаетесь отредактировать одну из них (декомпилировать + что-то изменить + перекомпилировать, что я пытался сделать раньше) и заменить исходную dll, ваше приложение выйдет из строя из-за несоответствия строгого имени. - person Sal; 02.12.2020