Что-то не так, НЕ подписывая сборку .NET?

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

Я могу понять основную идею подписания сборки: обеспечить, чтобы какая-то конкретная сборка не была скомпрометирована каким-то изворотливым хакером. Поэтому, если мы являемся компанией по разработке программного обеспечения, мы должны подписать нашу сборку, прежде чем выпускать .NET-библиотеку для наших клиентов.

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

Я что-то пропустил?

ОТВЕТЫ

Ответ 1

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

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

Чтобы подписать сборку, любые сборки, от которых она зависит, также должны быть подписаны. Я предполагаю, что это способствует желанию вашего коллеги подписать все - компилятор требует этого.

РЕДАКТИРОВАТЬ. После написания этого ответа вы можете видеть, что и pro, и против лагеря имеют примерно эквивалентную поддержку. Здесь явно нет правильного ответа.

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

Как и во всем, должны быть сделаны компромиссы. По моему опыту работы в частной среде преимущества подписания в основном теоретические (или академические, как @user289100), если вы не обеспокоены тем, что правительственные агентства изменяют ваши код, в этом случае вам нужно быть параноидальным в отношении стольких уровней вашей инфраструктуры, что подписание может показаться небольшим усилием. В противном случае количество проблем, которые каскадируют из-за того, что нужно подписывать все, просто не похоже на это. Однако у вашей среды могут быть разные требования, или вы можете быть мазохистом!

См. также Ответ Teun D для получения информации о проблемах, связанных с сборками версий, при использовании сильных имен.

Ответ 2

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

Если вы подписаны, вы можете сделать соответствие подписи, но не заменить. Вопреки тому, что говорит Зиппи, будет допущена ошибка выполнения во время выполнения.

Подписание сборок никогда не будет излишним. Это займет 30 секунд. Мне нравится говорить, что запереть ваши двери слишком много, если вы живете в стране. Если вы хотите играть в азартные игры со своими вещами, продолжайте, оставьте его открытым. Для увольнения требуется только одно нарушение безопасности. Это займет всего 30 секунд, чтобы подписать сборку, и нет никакого делового случая. Воздействие производительности не имеет значения.

Ответ 3

Еще одна точка: подписание ваших сборок нарушает обратную совместимость версий. Ваши ссылки на все начинают включать номера версий и версии с другими номерами версий, считаются несовместимыми. Это препятствует обновлению до более новых версий распределенных сборок.

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

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

Ответ 4

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

Ваш анекдот о самоподписывании кода Microsoft кажется особенно подозрительным для меня. Если MS не подписала код, возможно, причина, верно? И, подписывая это, вы берете на себя ответственность за это, когда вы его не пишете, - еще одна возможность на будущее укусить вас.

Ответ 5

Еще одна вещь, связанная с подписанием сборки, заключается в том, что вы не можете вводить неверный вместо своего (также - себя случайно). В примере, если вы создаете программу, которая ссылается на сборку Foo.dll, версия 1.0, кто-то может создать сборку с той же версией и заменить вашу, когда вы подписываете свою библиотеку, это будет невозможно (на по крайней мере, я не думаю, что это легко возможно).

Ответ 6

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

Ответ 7

Я согласен, кажется, что это пустая трата. Это действительно необходимо для обеспечения того, чтобы файл был тем, чем вы его считаете (и не был подделан). Но если вы доверяете ограничениям собственной сетевой безопасности и веб-сервера, то подписание ваших веб-сборок кажется излишним.

Но, может быть, мой малый бизнес говорит. Если вы говорите о критически важном веб-сайте онлайн-банкинга, тогда выходите.

Ответ 8

Подумайте об этом, если вы собираетесь отправить что-то и/или на самом деле иметь повод сделать это. В любом другом случае это просто хлопот. Я бы попросил вашего товарища по работе, что он на самом деле выходит из этого.

Я столкнулся с подписанной сборкой-itis раньше, и это боль в задней части, особенно когда вы рассматриваете количество людей, которые мало что знают о подписании сборок, для чего это и как это сделать. Это просто еще одна вещь, о которой вам не придется беспокоиться, если это абсолютно необходимо.

Ответ 9

Вам нужно подписать сборку, когда она используется в развертывании-из-за ClickOnce XBAP.

Кроме того, все ссылочные сборки также должны быть подписаны.

Ответ 10

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

System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Мы обнаружили, что Visual Studio иногда ошибается, а запускает старый код.

Если вам нужна ошибка, если вы используете старый код, подпишите свои сборки.

Если вы пишете пакет nuget, , пожалуйста, подпишите свои сборки. Неподготовленные сборки неудобны для нас, кто хочет убедиться, что мы используем последнюю версию нашего кода. Я не могу исправить Visual Studio. Все, что я могу сделать, это обнаружить, что Visual Studio ошибается. Поэтому, пожалуйста, подпишите свои сборки nuget.