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


94

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

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

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

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


1
Здесь стоит отметить некоторую путаницу: «цифровые подписи» (которые имеют целью безопасность) и «сборки со строгими именами», которые являются исправлением dll-ада и помогают GAC связать библиотеки. Использование того или другого аналогично, и о обоих можно говорить с точки зрения подписания сборки. Кажется, что одни плакаты думают об одном, а другие думают о другом или о обоих.
объединить

Ответы:


49

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

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

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


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

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

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

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


17
Согласен, теперь для него это как пристрастие к
крэку

3
Еще один момент, на который следует обратить внимание: если вы хотите использовать эту сборку в разных приложениях, подписание является обязательным (например, GAC).
rajesh pillai 01

60

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

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

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


11
Если хакер может изменить dll, он также может изменить приложение, вызывающее dll.
ZippyV

12
Это правильный Zippy, но без ключа для подписи приложения им будет сложно заставить приложение работать в среде, где разрешено запускать только подписанную версию исходного приложения, что будет иметь место в нескольких случаях. среды, в которой я работал. Вы скучаете по лесу за деревьями: отказ от подписания сборки несет в себе ненужный риск безопасности, на предотвращение которого уходит 30 секунд, и нет никаких бизнес-кейсов или реальных случаев, которые я когда-либо видел, чтобы не подписать собрание.
user289100 01

39

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

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

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

9

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

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


2
на самом деле я не уверен, почему, но Microsoft определенно не подписывала Enterprise Library 3.1
oscarkuo

1
Почему для совместного использования сборки между процессами требуется, чтобы сборка находилась в GAC?
Dirk Vollmar

4
Дело не в том, что вы не можете совместно использовать ссылки среды выполнения на одну и ту же библиотеку .dll, дело в том, что только сборки со строгими именами (т.е. подписанные) могут попасть в GAC, а сборки помещаются в GAC, чтобы к ним можно было делиться.
Дэн Дэвис Брэкетт,

4

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


4

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


2
Для веб-приложения хакеру также придется изменить файл web.config.
Tangurena

3
Если хакер может удалить сигнатуры из сборки, web.config тоже не остановит их.
ZippyV

4
Тем, кто проголосовал против, рекомендуется прочитать ianpicknell.blogspot.com/2010/02/… и аналогичные статьи, ссылки на которые есть на этой странице .
Константин

1
Текущее: да и нет. Я пробовал, но по умолчанию Windows НЕ проверяет подпись («строгое имя»). Возможно, для удобства пользователя :-) Указанные ссылки показывают, что нужно добавить в App.config для принудительной проверки подписи. Кроме того, в отличие от статьи, проверка подписи действительно работает и обнаруживает любое вмешательство, будь то версия с номером версии или контент.
Роланд

3

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

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


2

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

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



1

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

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 .


Обновление: волна использования неподписанных сборок побеждает;) Мы решаем проблему выше по-другому: создаем и тестируем на сервере CI, начиная с пустого или «чистого» каталога ed. Возможно, у нас есть сценарий локально на наших машинах разработчиков, но это редко или не имеет большого практического влияния.
Клей Ленхарт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.