Щось не так із тим, що НЕ підписати збірку .NET?

Один з моїх колег дуже прагне підписати збори. Він буквально намагається що-небудь підписати. Навіть коли ми використовуємо збірки від Microsoft, які не підписані, він візьме вихідний код, підпише його, а потім попросить інших розробників використовувати замість нього його копію.

Я можу зрозуміти основну ідею підписання асамблеї: щоб якийсь хитрий хакер не скомпрометував певну асамблею. Отже, якщо ми є компанією, що розробляє програмне забезпечення, нам слід підписати нашу збірку перед тим, як випустити якусь бібліотеку .NET для наших клієнтів.

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

Я щось тут пропускаю?

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

Цікавим моментом на підписаних збірках є те, що вони дещо повільніше завантажуються, ніж непідписані збірки, оскільки вони повинні бути перевірені криптографічно.

Для того, щоб підписати асамблею, також слід підписати будь-які збори, від яких вона залежить. Я припускаю, що це сприяє прагненню вашого колеги підписати все - компілятор цього вимагає.

EDIT З моменту написання цієї відповіді ви бачите, що як за, так і проти табору є приблизно рівнозначна підтримка. Тут явно немає правильної відповіді.

Сенс, який змусив це редагування, полягає в тому, що сьогодні ми беремо стільки бібліотек з відкритим кодом від NuGet, і багато з них взагалі не підписані. Якщо ви хочете підписати свою збірку, вам також потрібно буде підписати будь-які залежності. Багато підписаних бібліотек із відкритим кодом мають приватні ключі, які використовуються для підписання загальнодоступних у своїх сховищах джерел.

Як і у всьому, тут є компроміси. З мого досвіду роботи в приватному середовищі, переваги підписання переважно теоретичні (або академічні, як згадує @ user289100 ), якщо ви не стурбовані тим, що державні установи змінюють ваш код, і в такому випадку вам потрібно бути параноїком на стільки рівнів вашої інфраструктури, що підписання могло б здатися невеликим зусиллям. В іншому випадку кількість викликів, які виникають із-за необхідності підписувати все, просто не здається вартим. Однак у вашому оточенні можуть бути інші вимоги, або ви можете бути мазохістом!

Див. Також відповідь Teun D, ​​щоб отримати інформацію щодо проблем, пов’язаних із складанням версій при використанні сильних імен.

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

Якщо підписано, ви можете зробити збіг підпису, але не замінити. На відміну від того, що каже Zippy, буде помилка компіляції під час виконання.

Підписання зборів ніколи не буває надмірним. Це займає 30 секунд. Це все одно, що сказати, що блокування дверей надмірне, якщо ви живете в країні. Якщо ви хочете пограти в азартні ігри зі своїми речами, продовжуйте, залишайте їх відкритими. Щоб звільнити, потрібно лише одне порушення безпеки. Підписання зборів займає лише 30 секунд, і немає жодної справи, щоб цього не зробити. Вплив на продуктивність незначний.

Ще один момент: підписання збірок порушує зворотну сумісність із версіями. Всі ваші посилання починають включати номери версій, а версії з іншими номерами версій вважаються несумісними. Це заважає переходу на новіші версії розподілених збірок.

На мою думку, вам слід збирати кодові підписи лише в тому випадку, якщо ви бачите певний виграш від цього:

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

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

Ваш анекдот про самостійне підписання коду Microsoft здається мені особливо підозрілим. Якщо держава-член не підписала код, можливо, є причина, правда? І підписуючи це, ви берете на себе відповідальність за нього, коли не писали - ще одна можливість для майбутнього вкусити вас.

Інша справа, що стосується підписання асамблеї, полягає в тому, що не можна вводити неправильну замість вашої (також - себе випадково). Наприклад, якщо ви створюєте програму, яка посилається на збірку 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 збори .