.NET: Должны ли исполняемые файлы иметь строгую подпись? А как насчет частных DLL?
Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:
TypeA objA;
. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.
См. Также этот пример:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
4 ответа
На мой взгляд, преимущества подписи строгим именем в этой ситуации заключаются в следующем:
- Предотвращает замену злоумышленником библиотеки DLL на одну, подписанную другим ключом (или не подписанную вообще), без замены EXE ( поскольку EXE содержит ссылку, включающую открытый ключ).
- Предотвращает изменение сборки злоумышленником при сохранении существующего ключа (так как это приведет к сбою проверки подписи). Однако обратите внимание, что в .NET 3.5 SP1 проверка подписи в этой ситуации отключена по умолчанию .
- Может предотвратить запуск приложения с несовместимыми версиями сборок - если DLL была неправильно заменена из-за ошибки развертывания, приложение не сможет загрузить ее, а не попытается использовать (потенциально несовместимую) неправильную версию.
- Избегает предупреждений FxCop.
И недостатки подписи (я полагаю, это то, о чем идет речь в связанной статье):
- Замена DLL на совместимую более новую версию (например, для исправления ошибки) требует замены EXE.
- В версиях .NET <3.5 SP1 сборкам со строгими именами требуется больше времени для загрузки из-за проверки подписи.
- Библиотеки DLL со строгими именами также загружаются дольше, потому что загрузчик выполняет (бесполезный в данной ситуации) поиск GAC перед поиском локально.
Кажется досадным, что выбор - либо строгое именование (и, следовательно, требующее, чтобы ссылки соответствовали точному ключу и точной версии), либо не строгое именование (и не требовало соответствия ни одному из них).Если бы можно было требовать ключ, но не конкретную версию, возможно, можно было бы получить первые 2 преимущества подписи, не получив при этом первого недостатка. Может быть, это возможно, применив строгое имя, а затем решив проблему управления версиями с помощью app.config?
Сильные сборки имен обеспечивают ТОЛЬКО совместимость версий. Это не то же самое, что доверять сборке.
Другими словами, «строгое имя» относится ТОЛЬКО к этому точному двоичному файлу сборки в сочетании с номером версии, используемым во время компиляции.
Если вы GAC эти сборки, то CLR проверит это только один раз. В то время, когда сборка gac'd. Это может привести к улучшению производительности. Однако мой опыт показал, что он минимален.
Сборка со строгим именем может быть заменена сборкой со строгим именем; который поднимает вопрос о том, что строгое именование НЕ является какой-либо функцией безопасности.
Мое личное мнение таково, что уровень боли, связанный с ними, не оправдывает их использование. Боль в том, как они завинчиваются с помощью автоматизированных инструментов тестирования.
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5054496.html
Ответы здесь команды микки-мыши типичны для онлайн-сообщества PHP! Вместо того, чтобы поделиться ответом, они спрашивают, зачем вам это нужно. Не имейте в виду тот факт, что соломонгабия задает действительный вопрос и это довольно нормальная функция, чтобы иметь в стандартных IDE и более профессиональных языках, таких как Java и Objective-C.
Соломонгаби, это самый простой способ получить то, что вам нужно:
$bt = debug_backtrace();
$end = end($bt);
var_dump($end['class']); //or var_dump($end['file']);
Подписывание сборок гарантирует, что сборки не будут изменены после компиляции. И до тех пор, пока вы единственный владелец закрытого ключа, никто не сможет сложить полномочия с вашего ключа.
Конечно, это не абсолютная защита. Хакер может изменять сборки и удалять сигнатуры надежных имен (и ссылки) из всех сборок. Эти сборки также будут работать.
Но в таком случае вы можете сказать, что изменения сделаны не вами.
При подписании сборки все сборки, на которые имеются ссылки, должны быть также подписаны. В противном случае вы получите ошибку компиляции по уважительной причине.
Я думаю, что основное использование для строгого именования сборки состоит в том, чтобы получить ее в GAC.
Я не вижу необходимости сильно называть exe.
только мои 2 песо....