Что-то не так с НЕ подписанием сборки .NET?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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's 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's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

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

Если вы хотите получить ошибку при запуске старого кода, подпишите свои сборки.

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