Подписание XML с SHA256 работает, когда это не должно
Это странный вопрос, но я постараюсь.
Я начал свой проект с использованием целевой платформы как 4.5.2, и требовалось подписать файл XML с использованием алгоритма SHA1. Я использовал пример на этой странице MSDN, и он работал нормально:
SignedXml.CheckSignature Method (X509Certificate2, Boolean) -> Раздел примеров
https://msdn.microsoft.com/en-us/library/ms148731(v=vs.110).aspx
После этого требование изменилось на алгоритм SHA256. Я использовал код на этих страницах, чтобы адаптировать этот оригинальный код, и он работал нормально, к тому времени я использовал 4.6 в качестве целевой платформы:
Использование SHA256 с классом SignedXml
https://blogs.msdn.microsoft.com/winsdk/2015/11/14/using-sha256-with-the-signedxml-class/.net Framework 4.6.2 добавляет поддержку для подписи XML-документов с использованием RSA-SHA256
https://www.stum.de/2016/05/19/net-framework-4-6-2-adds-support-to-sign-xml-documents-using-rsa-sha256/
Затем я обнаружил, что версия 4.6.2 платформы добавила полную поддержку SHA256, и что вызов CryptoConfig.AddAlgorithm() больше не был необходим. Я изменил проект до версии 4.6.2, внес необходимые изменения, прокомментировал вызов CryptoConfig.AddAlgorithm(), и он работал просто отлично.
Но теперь у нас есть другое изменение требований: мы хотим, чтобы наше программное обеспечение работало под Windows XP (да, у нас все еще есть пользователи), и последняя версия фреймворка для работы с XP (SP3) - v4.0. Итак, мне нужно было проверить, будет ли подписание XML-файла с SHA256 работать в рамках 4.0.
Я изменил целевой фреймворк на v4.0 тогда и начал изменения. Класс RSAPKCS1SHA256SignatureDescription, который я использовал в вызове CryptoConfig.AddAlgorithm(), доступен только начиная с фреймворка 4.5, поэтому мне пришлось бы написать свою собственную версию, как я видел на некоторых веб-страницах.
Но теперь странная вещь. Я держал комментарий CryptoConfig.AddAlgorithm(), чтобы посмотреть, что произойдет, чтобы я мог написать собственный класс, но он просто работал!
Я думал, что CryptoConfig.AddAlgorithm() зарегистрировал алгоритм где-то в проекте или на моей машине. Я исследовал это, но ничего не нашел. Так что я попробовал на другой машине, и это тоже сработало, но эта машина, вероятно, выполняла предыдущий код раньше, так что он мог также зарегистрировать алгоритм. Я попробовал другую машину, ту, в которой я не был уверен, но тоже работал там.
Итак, я пошел на машину, которая никогда не видела проект, и в то время я скомпилировал его и развернул исполняемый файл (я выполнял проект VS на других машинах). Я удалил все платформы.NET после 4.0 на этом компьютере и попытался запустить приложение. И... это все еще работает! Он подписывает XML с использованием SHA256 и работает нормально. Все эти машины работают под управлением Windows 10.
У кого-то есть идеи, что происходит?
2 ответа
Версия, на которую вы нацеливаетесь, и версия, на которой вы работаете, не совпадают. Любая цель 4.0-4.7 запускается во время выполнения 4.7. Поскольку добавление поддержки было нерушимым, это не было сделано с возвратом целевой версии.
Поскольку в WinXP не будет версии 4.6.2, вам нужно добавить обработчик самостоятельно. Ориентация на любую среду, имеющуюся в XP, ограничит вас доступным API, хотя, как вы видели, среда выполнения может вести себя по-разному, поэтому вам действительно следует протестировать на вашей целевой ОС.
После комментариев Мартина Бодьюса и ответа bartonjs я провел некоторое исследование и узнал кое-что о.NET Framework. В прошлом я действительно покупал маркетинг Microsoft о параллельной функции.NET, но я всегда думал, что каждая версия фреймворка будет жить вместе на одной машине. Сегодня я узнал, что это не совсем так.
Во-первых, CLR и фреймворк - это разные вещи, которые не обязательно идут вместе. Common Language Runtime (CLR) является критически важной частью структуры, чтобы определить, будет ли сосуществование рядом или нет. На сегодняшний день существует только 4 версии CLR: 1.0, 1.1, 2.0 и 4:
Common Language Runtime (CLR) - версии Common Language Runtime
https://docs.microsoft.com/en-us/dotnet/standard/clr
Все версии фреймворка, использующие одну и ту же версию CLR, будут заменой предыдущей версии на месте. Итак, если у вас есть только Framework 2.0 на компьютере, у вас есть CLR 2.0 и Framework 2.0. Если вы устанавливаете Framework 3.5 на эту машину, у вас все еще будет CLR 2.0, но Framework 2.0 будет заменен версией 3.5. После этого, если вы устанавливаете Framework 4.0, у вас есть CLR 2.0 и CLR 4 и Framework 3.5 и Framework 4.0. Если вы устанавливаете Framework 4.5 на тот же компьютер, у вас все еще будет CLR 4, но теперь Framework 4.0 заменен версией 4.5.
Вот почему, по крайней мере, на моем компьютере у меня есть только папки v2.0 и v4.0 по пути C:\Windows\assembly. Я заметил, что во время выполнения.NET DLL загружаются с этого пути. Тем не менее, я не уверен, какова цель "C:\Windows\Microsoft.NET\Framework".
Но это не ответило на вопрос, который я задал bartonjs: если новая версия платформы исчезает из предыдущих версий, которые используют тот же CLR с этого компьютера, как Visual Studio знает, какие классы, методы, свойства и т. Д. Допустимы для этого конкретные целевые рамки, выбранные для проекта?
Итак, я нашел эту прекрасную статью Скотта Хансельмана:
Управление версиями.NET и многоцелевой таргетинг.NET 4.5 - это обновление на месте до.NET 4.0
https://www.hanselman.com/blog/NETVersioningAndMultiTargetingNET45IsAnInplaceUpgradeToNET40.aspx
И ответ таков: в каталоге "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework" находится архив всех версий, прошедших через компьютер, и Visual Studio использует их! (почему бы не собрать все эти вещи в одном месте и по-настоящему сосуществовать?)
После всех этих ответов я лучше понял, что происходит (кстати, я обнаружил, что на этой последней машине была установлена платформа 4.7, потому что я удалил все, но собирался установить Visual Studio Community 2017 на нее и отменил чтобы выполнить мои тесты, но установщик Visual Studio уже был установлен, и этот, вероятно, поместил последнюю платформу на компьютер), и это не было неожиданностью, когда он действительно потерпел неудачу, когда я запустил приложение под Windows XP SP3. Но теперь я точно знаю, что делать.