Я создаю стартовый комплект, который устанавливает скомпилированные сборки из проекта с открытым исходным кодом в GAC, чтобы упростить ссылку на сборки в шаблоне. Поскольку они идут в GAC, они должны быть подписаны.Нужно ли мне защищать свой ключевой файл с сильным именем для проекта с открытым исходным кодом?
Нужно ли мне защищать и защищать ключевой файл паролем, или это нормально оставить его открытым и включить файл в исходный элемент управления?
Strong подписи имя имеет несколько целей (хотя не для реальной защиты от несанкционированного доступа с помощью программы, как это распространенное заблуждение) - в вашем случае использование сильного ключа для однозначной идентификации (и проверки) конкретную версию конкретную сборку, которая требуется GAC. Другое использование, которое предотвращает спуфинг с помощью других сборок, в этом случае не кажется необходимым (исправьте меня, если я ошибаюсь). По этой причине я считаю, что вполне приемлемо оставить ключ открытым (не защищенным паролем) и включить файл в исходный элемент управления. Насколько я вижу, вы не будете останавливать все, что вы не хотите, защищая пароль паролем. (Однако, если вы могли бы предоставить более подробные сведения о контексте безопасности, мне, возможно, придется пересмотреть это представление.)
Кроме того, см. this MSDN article для подробного обсуждения того, как правильно использовать сильное подписание имен в целом.
Я бы сказал, что включает в себя ключ «развития» в управлении источником, чтобы упростить создание здания и избежать принуждения людей к созданию и использованию собственного ключа. Ключ в управлении исходным кодом бессмысленен для безопасности, поскольку каждый может подписаться вместе с ним. Если люди хотят подписать свою сборку своего проекта с открытым исходным кодом, они могут заменить свой ключ, которым они могут управлять любым способом.
Вы также можете предоставить сборку для загрузки, подписанную защищенным ключом (которую вы никому не даете), но для людей, желающих использовать эти двоичные файлы, им нужно будет доверять вам. Вы заслуживаете доверия? :)
Не могли бы вы рассказать об этом неправильном представлении о защите от несанкционированного доступа к сборке? Мне это кажется неправильным (см. Http://stackoverflow.com/questions/369248/can-strong-naming-an-assembly-be-used-to-verify-the-assembly-author/369477#369477), но может, я что-то упустил? Тем не менее, при сильном имени, очевидно, невозможно проверить полномочия (для которых необходим механизм сертификата, такой как Authenticode). –
@divo: Что не так, точно? Проблема с сильным подписанием ключа заключается в том, что вы не можете проверить источник открытого ключа, чтобы он мог быть регенерирован другим автором и по-прежнему согласен с assmebly (который затем может быть изменен). Если вы считаете, что связанный ответ не согласуется с моим (я уверен, что это не так), попробуйте перечитать его внимательно (в сочетании с ответом Мехрдада, что тоже хорошо). Здесь есть несколько тонкостей, которые отнюдь не легко понять. – Noldorin