Runtime: Добавить класс System.Security.Cryptography.Xml.SignedXml

Как указывает Tratcher, это средство блокировки для добавления поддержки WsFederation / ADFS в ASP.NET 5. Мы широко используем ADFS для многих корпоративных приложений ASP.NET 4. Мы очень заинтересованы в переходе на ASP.NET 5 и использовании WsFederation.

@rschiefer @Tratcher Ну, это ... сложно.

• ADFS не использует System.Security.Cryptography.Xml.SignedXml; но вместо этого его собственная реализация.
  
  
  
  • (Это в основном из-за того, что вы стирали пыль с мысленной паутины и вспомнили о том, что снова участвовали в этой команде над версией 1 ADFS)
  
  
• System.IdentityModel определенно не использует System.Security.Cryptography.Xml
  
  
  
  • (Это потому, что их исходный код в справочнике говорит так: smile :)
  
  
• Людям не очень нравится System.Security.Cryptography.Xml.SignedXml, потому что он основан на XmlDocument, что приводит к некоторым проблемам с производительностью.
  
  
  
  • Версия ADFS была основана на XmlReader, IIRC.
  
  
• Итак, вероятно, люди хотят, чтобы CoreFX создал новую реализацию SignedXml.
• Но новая версия SignedXml несовместима со старой версией SignedXml.
• Так что некоторые люди могут захотеть, чтобы мы сохранили и старую версию.
• В общем, людям действительно нужны две версии.
• Только им не нужна старая версия.
• За исключением тех случаев, когда они это делают.

Итак, мы остаемся перед загадкой:

• Мы можем портировать тот класс, который никому не нужен
• Или мы можем остановиться и разработать совершенно новую вещь, которую, вероятно, никто не будет использовать, поскольку они не могут быть совместимы ни с чем другим.
• Или, чтобы приложить максимум усилий и при этом никому не принести пользу, сделайте и то, и другое: smile:.

@terrajobst - fyi

Видимо, сегодня утром я немного возился. Извиняюсь :).

Мы определенно определили, что здесь есть над чем поработать, но мы не думаем, что правильный ответ - продвигать существующий код System.Security.Cryptography.Xml. Вместо этого он представляет собой элемент в нашем бэклоге для разработки универсальной реализации XmlDSig, которая работает быстро и не привязана к устаревшим объектным моделям (например, XmlDocument).

Это не то, чего мы ожидаем от .NET Core 1.0, просто потому, что мы сосредоточены на других вещах.

Но если вы сообщите нам о том, что на вас повлияла недостающая функциональность, это поможет в постоянной расстановке приоритетов.

Я собираюсь создать ПО промежуточного слоя SAML2 ASP.NET Core на основе https://github.com/KentorIT/authservices. Без порта SignedXml он не сможет работать на платформе Core.

Я определенно согласен с тем, что не переносить существующий - хорошая идея. Можно ли что-нибудь сделать на основе API XmlReader? Таким образом могут поддерживаться как XDocument, так и XmlDocument. Также было бы неплохо предоставить реализацию охваченного читателя, используемого в System.IdentityModel (если бы он был улучшен для поддержки файлов XML с пробелами ...)

Да, я бы начал с

Поскольку XmlReader, на котором основан вариант System.IdentityModel, это должно быть выполнимо :).

@bartonjs Вариант System.IdentityModel весьма ограничен в том, какие преобразования он может обрабатывать. Для работы SAML2 / WS-Fed это не будет проблемой, но в качестве общего API необходимо рассмотреть, как работать с подписями без оболочки и XML, содержащим вложенные подписи (например, подписанный ответ saml, содержащий подписанные утверждения). Также я думаю, что System.IdentityModel.EnvelopedSignatureReader копирует данные при выполнении проверки. Там есть много интересного. Если бы у меня было время, я бы с удовольствием поработал над этим.

Я ценю бессвязный @bartonjs , который помогает увидеть, что происходит за кулисами.

В настоящее время это влияет на мою компанию. У нас есть устаревший код, который мы пытаемся перенести на .NET Core, который генерирует подписанные файлы лицензий XML, и без этого набора классов мы застряли. Мы открыты для отклонения от XML-файлов в качестве основы для лицензий, но на данный момент мы не нашли хорошего решения, которое бы соответствовало нашим потребностям.

С нетерпением жду, когда это будет добавлено в будущем.

Я могу засвидетельствовать, что это (а также немного связанное с ним XML-шифрование) актуально для нас. Существующая форма в .NET Framework вполне подойдет - с моей точки зрения, здесь нет необходимости в инновациях. Реализация копирования и вставки будет очень кстати!

Есть ли в настоящее время какое-либо обходное решение?

Хотел бы также знать, о чем спрашивал @sandersaares . В CoreFX сейчас нет встроенного способа подписи xml?

@sandersaares / @ af0l : для .NET Core 1.0 нет встроенной реализации SignedXml / XmlDSig.

Основываясь на комментариях здесь (и других), мы, вероятно, просто перенесем старый API, но у нас не было времени сделать это для 1.0.

Спасибо @bartonjs , наверное, по этой причине я не смог заставить наш проект работать на Core. :) Это также большой позор, потому что я бы хотел двигаться вперед и не могу, пока это не будет сделано. Мы должны сообщать обо всех платежах в наш налоговый орган, используя подписанные XML-файлы, так что это действительно препятствие.

Есть ли в этом прогресс? Я застрял с проверкой токена SAML, для которой требуется эта функция. Спасибо

Да, я бы тоже хотел это знать. В итоге мы извлекли функции, требующие подписи, и поместили их в отдельное решение веб-API ...

Уже есть представление о том, какая версия будет реализована или решение

На данный момент кажется, что наиболее простой ответ - перенести существующую реализацию .NET Framework на .NET Core. Так что мы объединяем это с другими упущениями API, которые "затрудняют перенос".

Потенциально актуально для темы: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently и https://github.com/sandersaares/ xml-c14n-пробел-дефект. Мне кажется, что реализация Canonical XML 1.0 в .NET Framework неверна. Надеюсь, я ошибаюсь, но если это так, это может вызвать некоторые опасные вопросы о совместимости.

@sandersaares Посмотрел ваш образец, и вам нужно установить XmlDocument.PreserveWhiteSpace = true при чтении Xml, если он содержит пробелы.

@AndersAbel Спасибо за подсказку! Это меняет ситуацию и фактически позволяет проводить соответствующую проверку, если присутствует XML-схема. Без схемы XML поведение остается недействительным (новым и интересным способом). Я обновил проблему подключения и репозиторий GitHub соответственно.

@bartonjs Если вы https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

К вашему сведению, если это дойдет до стадии реализации, то у меня здесь есть недавно отчеканенная библиотека с тестами, в которой используются подписи XML (как подписывать, так и проверять) и другие функции XML в .NET Framework - может быть полезно получить некоторую реальную реальность без зависимостей. -world код для опробования реализации: https://github.com/Axinom/cpix

Есть ли график разработки этого API?

// cc @bartonjs

@henkmollema Ничего конкретного, нет. В выпуске 1.2 мы работаем над сокращением разрыва между .NET Framework и .NET Core; и эта работа в настоящее время является источником SignedXml.

Сегодня я звонил клиенту, которому нужна поддержка SAML2-P в ASP.NET Core (который будет использовать реализацию KentorIT). Это блокирующая проблема для клиентов, которые хотят перейти на ASP.NET Core. На данный момент моему клиенту придется оставаться на Katana.

Я вижу, что этап был изменен с 1.2 на Future (@bartonjs). Вы можете прокомментировать или уточнить?

В основном это просто связано с тем, как мы отслеживаем вехи. Раньше мы делали больше «мы надеемся, что это сделает это», а затем в конце этапа мы переназначили все, что не было сделано. Сейчас мы очень стараемся сказать: «Если мы отметим его для этой вехи, переназначение должно быть очень редким».

Это следует из множества других работ по достижению вехи 1.2, и (в любом случае для меня) всегда было непросто сделать это для 1.2. Это все еще довольно высоко в нашем списке «что дальше», мы просто не «обязуемся», чтобы он был частью выпуска 1.2 (который в основном связан с работой над netstandard2.0, исправлением ошибок и парой инфраструктурных проектов).

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

@karelz Если есть что-то, что вы хотите добавить (или исправить), пожалуйста, присоединяйтесь к нам.

Мы не сможем профинансировать работу в 1,2 таймфрейма (слишком много других вещей, которые нужно завершить). поэтому мы переместили его в раздел «Будущее», чтобы сообщить о наших планах.
Мы знаем о количестве запросов, поэтому оно велико в нашей очереди в области безопасности. Это также один из наиболее часто запрашиваемых API-интерфейсов corefx (среди DirectoryServices, SerialPort и т. Д.).

Копия: @steveharter @danmosemsft @terrajobst

Наши ответы пересеклись :)
Дополнительную информацию о вехах можно найти в нашем справочнике .

Код .NET Framework доступен в качестве справочного источника . Таким образом, технически портирование может быть инициировано даже вне команды .NET Core - если люди заинтересованы в этом нам помочь.
Судя по моим предыдущим @bartonjs, я думаю, что ключевой «проблемой» будет создание / перенос тестов.

Эй, а какова реальная ситуация с этой проблемой?

@ Jaedson33, что вы имеете в виду под

@karelz Но я не хочу ждать. Почему ты не исправляешь это сейчас?

@ Jaedson33 см. Мой ответ выше - он объясняет, почему мы не можем финансировать его сейчас. Речь идет о приоритетах. Сейчас есть очередь людей, которым нужно много функций / API, но у нас нет бесконечной команды, поэтому мы должны расставить приоритеты.

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

Хорошо, я подожду.

@karelz, если исходные тесты все еще доступны для проверки работы, я был бы готов поднять руку :)

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

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

Если вам все еще интересно, мы можем попытаться оставить исходный код из полной .NET Framework как есть - следующим шагом будет его сборка и добавление тестового покрытия, прежде чем его можно будет выпустить как часть .NET Core. Сообщите мне, если вам интересно ...

Хорошо, да - нам все еще интересно :)

@tintoy Мне интересно помочь вам, потому что мне действительно нужен этот класс.

@tintoy Мне интересно помочь вам, потому что мне действительно нужен этот класс.

Рад это слышать :)

Итак ... Чем я могу помочь?
Obs: Я впервые использую GitHub.

Итак ... Чем я могу помочь?

Позвольте мне сначала поговорить с моим коллегой, и мы разработаем план атаки. @karelz - есть ли какие-нибудь рекомендации или другие документы, которые мы должны прочитать, прежде чем углубляться в них? Для начала, я предполагаю, что мой коллега, вероятно, перейдет к стандарту, я, вероятно, посмотрю, куда должен идти код (и что нужно для запуска существующих тестов из других частей фреймворка, прежде чем мы сделаем любые изменения). Звучит разумно?

CC: @anthonylangsworth

Чтобы немного ограничить объем, я бы рекомендовал начать без функций, которые отключены MS16-035 (преобразование xpath, преобразование xslt, внешние ссылки). Я не знаю, где есть место для взлома изменений, но текущий резервный механизм в DefaultGetIdElement может быть использован в атаках с переносом сигнатур. Я бы предпочел более безопасную версию по умолчанию.

Также было бы хорошо, если бы внутренний API был немного реструктурирован для поддержки EnvelopedSignatureReader, используемого System.IdentityModel, вместо двух отдельных реализаций проверки подписи XML.

Наконец, я также хотел бы добавить одну точку в соответствии с этим отчетом об ошибке .

@tintoy Не думаю, что у нас есть хорошие документы. Я думаю, мы должны добавить исходники, и тогда мы сможем распараллелить работу - позвольте мне синхронизировать с @bartonjs @steveharter @ianhays.

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

Кто-нибудь может что-нибудь сказать об идее объединения SignedXml и EnvelopedSignatureReader, используемых System.IdentityModel?

@AndersAbel

начать без функций, которые отключены MS16-035 (преобразование xpath, преобразование xslt, внешние ссылки)

Мы должны начать с последнего исходного кода .NET Framework, который должен быть безопасным. Если у вас есть какие-либо вопросы о безопасности кода .NET Framework, сообщите нам об этом в автономном режиме.

Я не знаю, где есть место для внесения изменений

Нет места, мы должны начать с простого переноса из .NET Framework. Любые дальнейшие улучшения, изменения, критические изменения и т. Д. Могут быть рассмотрены позже. Не в рамках первоначальной работы. Иначе он вырастет над нашими головами.

текущий резервный механизм в DefaultGetIdElement может быть использован в атаках с переносом сигнатур

Это следует рассматривать как отдельную проблему. @bartonjs не могли бы вы прокомментировать?

Также было бы хорошо, если бы внутренний API был немного реструктурирован для поддержки EnvelopedSignatureReader, используемого System.IdentityModel, вместо двух отдельных реализаций проверки подписи XML.

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

Наконец, я также хотел бы добавить одну точку в соответствии с этим отчетом об ошибке.

Пожалуйста, отправьте это как отдельную проблему здесь, на GitHub. В идеале после того, как код будет перенесен (т.е. когда ошибка действительно применима к .NET Core).

Кто-нибудь может что-нибудь сказать об идее объединения SignedXml и EnvelopedSignatureReader, используемых System.IdentityModel?

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

текущий резервный механизм в DefaultGetIdElement может быть использован в атаках с переносом сигнатур

Это следует рассматривать как отдельную проблему. @bartonjs не могли бы вы прокомментировать?

@AndersAbel Если вы считаете, что существует проблема с безопасностью, следуйте процедуре сообщения об уязвимостях на странице https://technet.microsoft.com/en-us/security/ff852094.aspx.

Кто-нибудь может что-нибудь сказать об идее объединения SignedXml и EnvelopedSignatureReader, используемых System.IdentityModel?

Вероятно, это невозможно. SignedXml в значительной степени (и является союзником общедоступного API) основан на XmlDocument с расширенной DOM. Представление IdentityModel основано на XmlReader. Но как только существующий материал будет доставлен, его можно будет исследовать.

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

@AndersAbel - ура, я уверен, что нам

@bartonjs Я сообщил об этих проблемах по адресу [email protected] , что привело к появлению MS16-035. ИМО, есть некоторые оставшиеся рискованные проблемы, которые MS решила не исправлять (они повлекут за собой критические изменения). Я еще не публиковал подробности, но если вы хотите обсудить их в частном порядке, напишите мне.

@karelz Спасибо, что прояснили, что нет места для критических изменений. Это означает, что мои представления о консолидации не актуальны.

начать без функций, которые отключены MS16-035 (преобразование xpath, преобразование xslt, внешние ссылки)

Мы должны начать с последнего исходного кода .NET Framework, который должен быть безопасным. Если у вас есть какие-либо вопросы о безопасности кода .NET Framework, сообщите нам об этом в автономном режиме.

Патч MS16-035 устраняет ряд проблем в SignedXml. Однако можно использовать ключи реестра, чтобы вернуться к старому, небезопасному поведению. Следует ли перенести эти параметры на .NET Core? Мое предложение, приведенное выше, было направлено на то, чтобы сделать приоритетным перенос текущего поведения .NET Framework по умолчанию, оставив на данный момент те части, которые по умолчанию отключены. Или вы имеете в виду, что эти части тоже необходимо переместить? Тогда возникает вопрос, как обрабатывать конфигурацию, поскольку .NET Core AFAIK не полагается на реестр для настройки (поскольку он доступен не на всех платформах).

Однако можно использовать ключи реестра, чтобы вернуться к старому, небезопасному поведению. Следует ли перенести эти параметры на .NET Core?

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

Почему вы не создаете проект на GitHub, чтобы реализовать это?

Мы синхронизировались с @bartonjs , @steveharter и @ianhays

РЕДАКТИРОВАТЬ: план выполнения перемещен в самый верхний пост.

Звучит неплохо :)

@karelz , @steveharter Большинство запросов в реестре находится в классе Utils : AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier . Также есть поиск в классе SignedXml, где он XmlDsigXPathTransform и XmlDsigXsltTransform . Следует ли их полностью удалить из источника вместе с кодом, совместимым с реестром?

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

@AndersAbel Я имя: объект для них и, таким образом, можно создать с поздним связыванием

Как вы думаете, когда этот урок будет готов?

Вы имеете в виду взносы? @steveharter планирует очень скоро (скорее всего, сегодня) отправить первоначальный PR "добавить источники".

Исходный код только что был объединен.

@steveharter Спасибо 😃

Спасибо @steveharter! Я переместил план выполнения в самый верхний пост, чтобы упростить отслеживание прогресса. Всякий раз, когда мы вносим в него изменения, мы будем упоминать об изменениях в другом ответе здесь.

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

@karelz : мы с @tintoy подняли руки, чтобы приступить к этому. Рад, что вы поручили его нам.

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

Ура - я рад начать компиляцию :)

@anthonylangsworth - хах,

Работа происходит здесь .

Присвоен @tintoy. Я назначу его также

Спасибо!

@karelz просто для подтверждения - master ?

(очевидно, мой master )

Э-э, извините, позвольте мне попробовать еще раз - возможный пиар против вашего master ?

Да все верно. Только не делайте это частью полной сборки / тестирования corefx до самого последнего этапа.

Я нашел пару констант, которые, похоже, были перемещены во внутренний класс в src / Common / src / Interop / Windows / Crypt32 / Interop.certificates_types.cs . Однако это недоступно из System.Security.Cryptography.Xml . Есть мысли о лучшем подходе здесь?

Какие из них нужны? Все они?
Можете ли вы проверить источник ссылок, если они общедоступны в .NET Fx? (Не думаю, но перепроверить не помешает)
Я немного удивлен, что мы делаем специальное взаимодействие, вместо того, чтобы использовать остальную часть библиотеки Crypto ... либо для этого нужно что-то особенное, либо это связано с историческими причинами ... @steveharter @bartonjs есть какие-то мысли?

@tintoy Одна из вещей, которую необходимо сделать, - это удалить прямое взаимодействие с CAPI, переключившись на использование .NET API.

@karelz , @bartonjs - в основном константы CAPI HRESULT передаются конструктору CryptographicException .

Например:

src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / KeyInfoX509Data.cs (строка 63)

Я посмотрю, как другой код в corefx работает с CryptographicException .

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

Что касается других проблем, мне кажется, что это результат того, что типы больше не используют одну сборку. Например, X509Utils.DecodeHexString находится в System.Security.Cryptography.X509Certificates но в полной структуре он просто живет в сборке System.Security вместе с классами, которые его используют.

Поскольку все разбито на несколько сборок, каков ваш предпочтительный механизм работы с тем, что обычно является общими компонентами? Я мог бы просто скопировать требуемые функции из кода в других сборках, если вы так предпочитаете.

Или вставьте источник, используя что-то вроде:

<Compile Include="$(CommonPath)\Interop\Windows\Crypt32\Interop.certificates_types.cs">
    <Link>Interop\Windows\Crypt32\Interop.certificates_types.cs</Link>
</Compile>

На данный момент я работал над проблемой CAPI, просто скомпилировав Interop.certificates_types.cs в сборку и ссылаясь на константы оттуда.

Мне также пришлось скопировать некоторые методы из X509Utils.cs в полной структуре (в основном, для кодирования / декодирования Hex), поскольку в corefx нет ничего общедоступного, что бы это делало.

Единственные оставшиеся проблемы находятся в src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / SymmetricKeyWrap.cs (строка 34, среди прочего), что приводит к таким ошибкам, как:

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

На данный момент я подавил ошибку. Итак, теперь все компилируется :)

Хорошо, кроме тестового проекта:

corefx\Tools\PackageLibs.targets(34,5): error : Could not locate compile assets for any of the frameworks .NETStandard,Version=v1.7
corefx\Tools\PackageLibs.targets(34,5): error : Could not locate runtime assets for any of the frameworks .NETCoreApp,Version=v1.1

Я займусь этим завтра.

@karelz @bartonjs Я собираюсь открыть PR, чтобы мы могли обсудить изменения (работа в основном сделана, насколько я могу судить) - вас это устраивает?

Звучит неплохо. @steveharter есть мысли?

С Новым годом = D

Вы знаете, когда будет завершена вторая фаза?

dotnet / corefx # 14662 уже объединен - ​​это был этап 2. Я отмечу его в верхнем посте как «проверено».

Я так понимаю: после выполнения всех 5 шагов, описанных выше, для получения поддержки ws-fed в ASP.NET Core команде AAD необходимо выполнить свои биты токена SAML, а затем командам ASP.NET необходимо создать ws -fed промежуточное ПО на части AAD. Это соответствует вашим ожиданиям?

Нет, эта работа не имеет ничего общего с WS-Fed.
Я должен ответить и объяснить на https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500

К вашему сведению: ответ опубликован: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

Итак, когда будет завершена фаза 4?

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

А пока мы открыты для участия в пространстве от сообщества.

Я счастлив продолжать работать над этим, но на данный момент я как бы застрял; так как corefx перешел на новый процесс сборки, System.Security.Cryptography.Xml больше не строит (поэтому нам с @anthonylangsworth запрещено писать какие-либо тесты). Если бы мы могли получить лишь краткий указатель на то, что нужно для создания проекта (и тестового проекта), нам было бы хорошо :)

PS. Я потратил около 20 минут, отслеживая процесс сборки, чтобы понять, почему он больше не строится, но еще не решил. Любые указатели будут оценены ...

@mellinoe @weshaggard не могли бы вы дать руководство по миграции SignedXml в новую систему сборки?

😭😭 Думаю, мне нужно подождать 😭😭

@tintoy, если вы

@weshaggard в настоящее время нет ветки - код находится в мастере, он просто не подключен к корневой сборке (специально) - src / System.Security.Cryptography.Xml (введен в dotnet / corefx # 14628). @steveharter может предоставить дополнительную информацию.

@weshaggard @karelz Я счастлив создать ветку в нашей вилке и строить ее там только для того, чтобы разблокировать нас; позже мы всегда можем выбрать любые изменения, которые мы внесли, когда он снова будет построен в master . Дайте мне знать, если это ваш предпочтительный подход :)

PR https://github.com/dotnet/corefx/pull/15491 должен заставить инфраструктуру проекта заработать. Как только CI пройдет проверку, мы сможем объединить его, и он должен ускорить ваши усилия.

Спасибо - я перебазировал tintoy / corefx / master и скоро

@weshaggard хорошо, так что и src, и тестовый проект построены, но если я добавлю ссылку на проект из тестового проекта в исходный проект ( <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ), я получу:

1>------ Build started: Project: System.Security.Cryptography.Xml, Configuration: Debug Any CPU ------
1>  D:\Development\github\tintoy\corefx\src\System.Security.Cryptography.Xml\src\System.Security.Cryptography.Xml.csproj ConfigurationErrorMessage: Could not find a value for TargetGroup from Configuration 'Debug'.
1>  System.Security.Cryptography.Xml -> D:\Development\github\tintoy\corefx\bin\AnyOS.AnyCPU.Debug\System.Security.Cryptography.Xml\netcoreapp\System.Security.Cryptography.Xml.dll
2>------ Build started: Project: System.Security.Cryptography.Xml.Tests, Configuration: Debug Any CPU ------
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018: The "FindBestConfiguration" task failed unexpectedly.
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018: System.ArgumentException: Property 'ConfigurationGroup' value 'Debug' occured at unexpected position in configuration 'Debug'
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.DotNet.Build.Tasks.ConfigurationFactory.ParseConfiguration(String configurationString, Boolean permitUnknownValues) in D:\Development\github\tintoy\corefx\src\Tools\CoreFx.Tools\Configuration\ConfigurationFactory.cs:line 219
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.DotNet.Build.Tasks.FindBestConfiguration.Execute() in D:\Development\github\tintoy\corefx\src\Tools\CoreFx.Tools\FindBestConfiguration.cs:line 34
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

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

@tintoy Я не уверен, что конкретно это за ошибка, но обычно нам не нужны ProjectReferences в нашей новой инженерной системе. Для тестовой сборки мы всегда создаем и ссылаемся на полный пакет таргетинга, в данном случае созданный в bin\ref\netcoreapp . Библиотека, которая помещается в этот каталог, - это то, что вы создаете из своей папки ref, которая в настоящее время пуста. Итак, чтобы начать работу, вам нужно сгенерировать ссылку с нужной областью API и получить сборку ссылки, тогда ваш тестовый проект автоматически увидит API и сможет строить на основе них. У нас есть инструмент под названием genapi, который может генерировать ссылку на основе другой библиотеки. Позвольте мне быстро отправить еще один PR, чтобы посеять это для вас, ребята.

Хорошо, теперь я понял; причина, по которой я не вижу типов в тестовом проекте, заключается в том, что в проекте ref еще нет типов :-)

@weshaggard, если у вас нет времени, я, наверное, смогу решить, как это сделать; Я как раз читал об этом инструменте на днях.

Я быстро запустил инструмент genapi и нажал на коммит https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e. Не стесняйтесь принимать это или восстанавливать самостоятельно. Вам нужно будет добавить ProjectReference к другим ссылкам, чтобы он скомпилировался.

Ура - это сэкономит мне время, очень признателен.

@weshaggard успеха! Спасибо, надеюсь, мы сможем приступить к написанию этих тестов сейчас :)

(tintoy @ dd834c63af4fe40faf84bc6a776b474ec9947eb1 , просто игнорируйте дубликат)

Ага! Пройдите рабочий тест:

https://github.com/tintoy/corefx/commit/24864b3d25e665b6305f116890328527db07f1e1

Спасибо за помощь, @weshaggard!

PS. Мне пришлось локально переопределить (через файл .user ) путь к исполняемому файлу в свойствах тестового проекта (вкладка «Отладка»). Был D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe но работал только тогда, когда я изменил его на D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe .

D: \ Development \ github \ tintoy \ corefx \ Tools / testdotnetcli / dotnet.exe

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

Просто из любопытства, какую версию VS вы используете? 2015 или 2017? Возможно, это исправили в 2017 году :)

(В наши дни я обычно использую OSX или Linux, поэтому я полностью ценю усилия, направленные на кроссплатформенность, BTW)

Я использую VS 2015 в Windows 10 и открываю решение и могу F5 для отладки тестов, и мой путь отладки - D:\git\corefx\Tools/testdotnetcli\dotnet.exe

Хорошо, я, должно быть, схожу с ума - теперь я тоже не могу это воспроизвести!

Раньше он жаловался, что не может найти dotnet.exe , но он начал работать, когда я явно установил для исполняемого файла путь только с обратной косой чертой. Я только что удалил файл .csproj.user и он _по-прежнему_ работает, так что кто знает: -o

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

Отлично - я думаю, что сейчас мы можем быть на той стадии, когда мы можем начать это делать :)

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

Копия: @anthonylangsworth

@karelz ,

@anthonylangsworth и я начали писать тесты ; Я знаю, что мы не достигли общей договоренности о том, что нужно тестировать, но мы все равно начнем, а затем перенесем тесты туда, где мы согласны выполнять работу.

А для тех, кто вызвался помочь с тестами (что очень ценно), мы должны иметь возможность разделить предложенную работу в начале следующей недели :)

Относительно тестового покрытия и того, какие тесты нам нужны - @bartonjs имел твердое мнение по этому выше ).
Он вернется из отпуска в конце следующей недели. Вероятно, нам следует обсудить с ним детали и ожидания.
Также @AndersAbel упомянул экспертизу спецификаций и потенциальную помощь ранее в обсуждении .

cc @steveharter, если у него есть дополнительные указания, а @bartonjs - OOF.

Спасибо @tintoy @anthonylangsworth за ваш вклад! Мы действительно это ценим!
А также спасибо всем, кто планирует прыгнуть ;-)

cc @ steveharter, если у него есть дополнительные указания, а @ bartonjs - OOF.

Мое любопытство достигло точки, требующей удовлетворения.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
Я чувствую себя лучше сейчас.

😃 Я даже не знал, что это настолько специфично для Microsoft! Спасибо за забавное просветление 😃

@anthonylangsworth начал набрасывать примерный план тестирования в tintoy / corefx # 3 (я скопировал его план в выпуск, чтобы было легко комментировать), так что нам, по крайней мере, есть что обсудить. Не стесняйтесь просматривать его и оставлять отзывы :)

CC: @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (или кто-нибудь, кого это может заинтересовать) Какова политика использования InternalsVisibleToAttribute для тестов? В этом пространстве имен много классов internal , и получить адекватное тестовое покрытие может быть сложно только с помощью общедоступных методов. Однако я понимаю, что есть и другие соображения.

Хммм, к сожалению, я не знаю - @weshaggard @stephentoub? (вопрос в предыдущем ответе)

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

По памяти System.Collections.Immutable использует [InternalsVisibleTo] , если это поможет.

Например:

https://github.com/dotnet/corefx/blob/master/src/System.Collections.Immutable/src/Properties/InternalsVisibleTo.cs

В более общем смысле:

https://github.com/dotnet/corefx/search?utf8=%E2%9C%93&q=%22assembly%3A+InternalsVisibleTo%22

Вы можете увидеть мои мысли о InternalsVisibleTo в этом старом выпуске https://github.com/dotnet/corefx/issues/1604. Мое общее мнение - не делать этого, если в этом нет реальной конкретной необходимости.

Какова политика использования InternalsVisibleToAttribute для тестов?

Нет.

В этом пространстве имен есть много внутренних классов, и получить адекватное тестовое покрытие может быть сложно только с помощью общедоступных методов.

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

рассматриваемые проекты иногда включают соответствующие исходные файлы из других проектов

Предположим, вы имеете в виду «тестовые проекты включают источник продукта для доступа к внутренним участникам»: Нет.

[InternalsVisibleTo] и совместное использование исходного кода являются унаследованными стратегиями. Самые громогласные из нас считают (по сути), что наши тесты должны отражать только те вещи, с которыми можно встретиться в реальном мире. Если никакой тест не может поразить какой-то конкретный блок, тогда почему он существует? Да, есть некоторые блоки, генерирующие исключение, которые не могут быть задействованы, потому что избыточная проверка выше в стеке уже уловила их; но это то, что можно посмотреть постфактум и объявить ОК.

Поэтому я бы рекомендовал открыть спецификацию и убедиться, что существует положительный тест для каждой функции (например, для каждого алгоритма, который, по его словам, он поддерживает, и граничных случаев для минимальных / максимальных значений для параметров этих алгоритмов).

Также хороши отрицательные тесты, такие как удаление обязательных элементов (например, 4.1 говорит, что SignedInfo является обязательным элементом для Signature ... генерируем ли мы разумное исключение, если оно отсутствует?).

Тесты опций Canonicalizer, такие как <foo><!-- hi --></foo> и <foo></foo> (и, возможно, <foo /> ?), Одинаковы в c14n , но отличаются в c14n-withcomments . (Для этого, вероятно, потребуется подписать в обоих направлениях, а затем поменять местами тела, поскольку алгоритм канонизации должен быть подписан).

Преобразование тестов. Все каноникализаторы - это преобразования. И т.п.

Тампер-тесты тоже хороши. Но если вы считаете, что нашли тест на вмешательство, который успешно подделывает, не сообщайте об этом здесь и не фиксируйте / не отправляйте его в любое воспроизведение на github (отправьте тест / случай / описание по электронной почте [email protected]).

Ладно, сегодня я слишком много думал. Снова в отпуске.

Спасибо @bartonjs за ваши идеи во время отпуска! А теперь иди и повеселись в реальном мире ;-)

@karelz @bartonjs (правда, только после того, как вы вернетесь из отпуска!) @steveharter и все, кто высказывает свое мнение:

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

Я вижу, что у Mono есть несколько тестов SignedXml. Они должны быть оценены и проверены на соответствие спецификации xmldigsig, предложениям, упомянутым ранее @bartonjs , и текущему коду, чтобы увидеть, что \ стоит ли их

Спасибо - посмотрим :)

Спасибо за это, @steveharter . Не могли бы вы дать ссылки? Это могло бы сократить большую часть нашего тестирования. Есть ли какие-либо вопросы авторского права или другие соображения, если мы расширяем или опираемся на них вместо того, чтобы копировать их дословно?

@anthonylangsworth при копировании исходного кода из Mono мы должны сохранить и обновить заголовок авторских прав. Я бы посоветовал сначала сделать просто копию (с правильными заголовками, возможно, с небольшими изменениями). Когда у нас есть код в CoreFX, мы можем изменить его по своему желанию.

@anthonylangsworth Моно тесты - https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.

Спасибо, @steveharter. Я начал переводить тесты с NUnit на Xunit .

Я разместил это, но понял, что это в репозитории @anthonylangsworth :

Вот волшебство, которое нужно сделать с заголовками авторских прав, когда мы извлекаем код из Mono:

1. Keep the existing copyright headers in place
    ○ Note: If you are porting just portions of the file over, you still need to bring over all the existing copyright headers.
2. Add the following copyright headers – NOTE this is missing the middle line of the ‘regular’ CoreFx copyright headers:
             // Licensed to the .NET Foundation under one or more agreements.
             // See the LICENSE file in the project root for more information.

Есть ли в этом проекте какие-нибудь неудачные тесты?

@ Jaedson33 В настоящее время мы конвертируем моно-тесты. Я еще не нашел ни одного неудачного теста, который указывает на ошибки кода, но нам еще предстоит пройти много тестов.

@anthonylangsworth Чем я могу помочь?

@ Jaedson33 Я ответил на этот вопрос на странице https://github.com/tintoy/corefx/issues/6#issuecomment -280904587. Подводя итог, у нас есть 84 монотеста, которые все еще не проходят (в основном из-за изменения настроек по умолчанию и ограничений ядра .NET). Приветствуется любая помощь, чтобы заставить оставшиеся тесты работать. В противном случае прорабатываю их.

@karelz @bartonjs @steveharter В классе System.Security.Cryptography.CryptoConfig указано, что многие преобразования XML не поддерживаются в CoreFx (строки с 281 по 303 внизу DefaultNameHT ).

Они соответствуют URI, используемым классами в пространстве имен System.Security.Cryptography.Xml . Я полагаю, что в рамках добавления System.Security.Cryptography.Xml обратно в .Net Core мы должны их восстановить. Пожалуйста, дайте мне знать, если я ошибаюсь.

CC: @tintoy

@anthonylangsworth , некоторые из этих преобразований, такие как XmlDsigC14NTransform, подходят, но другие, такие как XmlDsigXsltTransform, считаются очень опасными. Хотя вы можете включить их с помощью ключа реестра в полной .NET Framework, я бы предпочел не поддерживать их в .Net Core. Взгляните на KnownCanonicalizationMethods и DefaultSafeTransformMethods на https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryprtography/xmlCryptograf/ преобразования, которые мы должны поддерживать.

Я не осознавал, что источник опасных на самом деле попал в порт. Я бы проголосовал за их полное удаление. На самом деле нет безопасного способа использовать их.

@morganbr Спасибо за внимание. После того, как я внесу изменения в XML-код значения ключа RSA и DSA, я просмотрю список включенных преобразований. Скорее всего, я опубликую список и попрошу вас и других просмотреть его.

@anthonylangsworth Звучит здорово!

@morganbr @AnthonyDGreen Эти преобразования (которые были отключены в патче MS16-035) уже обсуждались ранее в этом потоке при обсуждении порта. 14 декабря @bartonjs заявил, что @steveharter от 15 декабря о том, что эти преобразования, вероятно, могут быть включены с поздним связыванием и, следовательно, должны быть перенесены.

@steveharter @bartonjs не могли бы вы

Даже без поддержки реестра CryptoConfig может создавать эти преобразования с поздним связыванием по имени строки или oid. Найдите «CryptoConfig» в коде SignedXml, поскольку он используется для создания соответствующего класса на основе содержимого xml.

Это означает, что класс CryptoConfig должен быть расширен для поддержки этих преобразований, по крайней мере, для тех же типов в netfx в любом случае, и в идеале также перекрестные ссылки на них с Mono. Если нет причины (о которой я не знаю) не включать их и не подключать к CryptoConfig ..

FWIW - это версия CryptoConfig для netfx (для сравнения с corefx): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs , 20d26e036bc718bc

Есть список «разрешенных преобразований», который (в .NET Framework) расширяется реестром для обратной совместимости. Для .NET Core он не расширяемый, но жестко запрограммирован для включения только преобразований без ввода.

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

Поскольку мы говорим об удалении целого типа, это не приведет к несогласованности с .NET Framework ... поэтому я, вероятно, рекомендую удалить любые преобразования, которых еще нет в жестко запрограммированном списке разрешений. «Удалить перед публикацией пакета» можно изменить позже. «Опубликовать их» нельзя.

@bartonjs меня опередил. CryptoConfig содержит список разрешенных преобразований. Мне пришлось изменить этот класс, чтобы разрешить преобразования в новом пространстве имен System.Security.Cryptography.Xml . Хотя некоторые из разрешенных преобразований используют полное имя класса .Net, CryptoConfig прежнему разрешает только фиксированный список.

Я бы предпочел не переносить преобразования, которые имеют известные проблемы с безопасностью, но обратная совместимость также важна. Следует ли нам принимать это решение от имени разработчика? Модифицируем ли мы CryptoConfig чтобы разрешить некоторую форму расширения, чтобы разработчик мог добавлять новые преобразования, если они захотят? Как мы принимаем решение по этому поводу?

CryptoConfig не является ограничивающим фактором: https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security.Cryptography.Xml/src/System/SecurityX63/Cryptography/Cryptography/Cryptography/Cryptography.Xml/src/System/SecurityX63/Cryptography/Crypc/System/SecurityX63/Cryptography.Xml/src/System/SecurityX63/Cryptography. L787. (Хотя, если CryptoConfig все еще используется в качестве фабрики для разрешения, тогда любое преобразование должно быть в обоих местах)

Типы, обеспечивающие алгоритмы, отсутствующие в этом списке (которые также не являются каноникализаторами), фактически не имеют значения.

Для разрешения расширения безопасного списка потребуется новый API, поэтому технически это выходит за рамки этих усилий.

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

На самом деле релевантны и CryptoConfig и DefaultSafeTransformMethods . SignatureDescription создание выполняется в CryptoConfig поэтому, независимо от значений в DefaultSafeTransformMethods , вы не можете использовать преобразование, если оно не упомянуто в CryptoConfig . DefaultSafeTransformMethods ограничивает этот список, поэтому, если преобразование указано в XML, но не возвращается DefaultSafeTransformMethods , SignedXml.CheckSignature возвращает false.

В текущей реализации. CryptoConfig.AddAlgorithm выдает PlatformNotSupportedException , поэтому пользователи не могут добавлять свои собственные. Это выходит за рамки этих усилий по переносу, но, возможно, стоит посмотреть на это или даже добавить RemoveAlgorithm в будущем.

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

Как я уже спрашивал, кто здесь принимает решение? Как "охранник" я предпочитаю исключить небезопасные варианты. Однако я не совсем понимаю, насколько это может быть несовместимо.

@anthonylangsworth это обсуждение является частью принятия решения. Здесь решение примут региональные эксперты с самым большим опытом.

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

Хорошо, я побеседовал с некоторыми людьми внутри компании и думаю, что у меня есть опора для плана:

• Оставьте типы общедоступными. (Они общедоступные, и удаление вещей огорчает людей).
• Их нельзя (пока) использовать в сквозных тестах SignedXml. (На самом деле отрицательные тесты кажутся хорошими)
• У них есть открытые члены, которых должно быть достаточно для модульного тестирования, так что мы должны это сделать.
  
  
  
  • То же самое и с остальными типами преобразований.
  
  
• Если по какой-то причине преобразования, принимающие ввод, не работают, а все остальное в порядке, мы можем выяснить, что с ними делать. (Это также относилось бы к «если бы у них были сложные зависимости компиляции, которые невозможно удовлетворить», но мы уже преодолели это препятствие).

И если / когда появится API или другая конфигурация, позволяющая этим типам работать, добавить включенные тесты E2E будет легко.

@tintoy @anthonylangsworth @peterwurzinger каков статус вашей тестовой ветки? мы можем начать слияние? Я могу выбрать ваши тесты и продолжать дальше.

Не могли бы вы также PTAL на https://github.com/dotnet/corefx/pull/16545 ? Я включил один из образцов MSDN

Привет, @krwq. Я считаю, что некоторые тесты все еще не работают, но, поскольку они не выполняются как часть обычного процесса сборки, вы все равно можете их включить.

Позвольте мне поговорить с @anthonylangsworth и вернуться к вам.

PS. dotnet / corefx # 16545 ->: +1:

@krwq - быстро побеседовал с @anthonylangsworth. Он упомянул (и я согласен), что, учитывая объем проделанной работы, возможно, было бы хорошо объединить то, что у нас есть, прежде чем идти дальше. Он строится, и большинство тестов проходят, но некоторые - нет.

Я подозреваю, что нам нужно будет выполнить перебазировку на dotnet / corefx # 16545 (что я и сделаю), прежде чем открывать PR (что сделает @anthonylangsworth ).

Мы свяжемся с вами, как только будем к этому готовы (надеюсь, ненадолго).

@krwq Чтобы расширить то, что сказал @tintoy , хотя еще предстоит проделать некоторую работу, также была проделана большая работа по переносу существующих тестов и их расширению. В частности, я уже изменил CryptoConfig.cs для обработки многих упомянутых вами алгоритмов. Мы все хотим двигаться вперед. Мы также не хотим дублировать или перезаписывать работу друг друга. Поэтому мы планируем объединить изменения как есть, чтобы другие могли развить проделанную нами работу, найти все наши ошибки и, надеюсь, быстрее довести все до совершенства.

@tintoy - это https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests единственная ветка, над которой вы работаете?

Ага.

@krwq Ну, есть PR с большим количеством материала от Mono в (который также является дочерней веткой https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests ... ). Если вас интересует актуальный код, вам, вероятно, стоит взглянуть на него. Насколько я могу судить, около 40/340 тестов не проходят.

Хороший улов, @peterwurzinger , я думал, мы уже объединили его!

@peterwurzinger @anthonylangsworth, этот PR довольно хорош! Я на самом деле пропустил это. Будете ли вы объединять это со своей веткой, с corefx или хотите, чтобы я подобрал его и выполнил все слияния / ребазы? Пропускает ли что-нибудь из тестов Mono или это полный? @anthonylangsworth - для изменений CryptoConfig - я говорил об этом с @bartonjs - мы не должны трогать этот файл - он уже достаточно уродлив.

Мой первоначальный план состоял в том, чтобы получить несколько образцов из MSDN и заставить их все работать, чтобы мы могли начать раннюю проверку. После этого я буду объединять и исправлять тесты из вашей ветки. Если некоторые тесты не проходят, мы можем просто отключить их на данный момент и исправить позже. Давайте как можно скорее объединим ваши данные в corefx / master: smile:

Спасибо за обновление, @krwq . Если можете, держите нас в курсе. Это помогает понять, к чему мы стремимся.

Привет = D

Есть ли какие-нибудь неудачные тесты?

@ Jaedson33 @anthonylangsworth @tintoy
Вот текущий список (произвольно) наиболее важных вопросов:
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@ Jaedson33 да, в настоящее время они отключены. Это должно дать вам общее представление о том, где мы находимся.

Привет, ты хоть представляешь, когда это будет без ошибок?

@ Jaedson33: в каждой программе есть ошибки: wink: Есть ли какие-то конкретные вещи, которые у вас не работают?

Все просто: это просто не работает в моем проекте UWP 😞

Привет, я получаю эту ошибку, когда пытаюсь запустить build.cml. Вы можете мне помочь?

Ошибка в команде:
C: \ Users \ jaeds \ Source \ Tools \ msbuild.cmd / nologo / verbosity: minimal / clp: Summary / maxcpucount / nodeReuse: false /l:BinClashLogger,Tools\net46\Microsoft.DotNet.Build.Tasks.dll;LogFile = binclash.log / p: ConfigurationGroup = Debug / p: BuildPackages = false / flp: v = normal /flp2:warningsonly;logfile=msbuild.wrn /flp3:errorsonly;logfile=msbuild.err C: / Users / jaeds / Source /Repos/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj / t: rebuild / p: Configuration = Debug / p: Platform = x64 / p: PlatformToolset = v141. => O sistema não pode encontrar o arquivo especificado
Ошибка выполнения команды с кодом выхода 1.
Не удалось создать проект сборки собственных компонентов!
Ошибка выполнения команды с кодом выхода 1.

@JaedsonBarbosa Вы запускаете тесты из командной строки разработчика? (кстати, это немного OT) для UWP - я буду исследовать, можно ли это сделать довольно дешево для 2.0, хотя никаких обещаний

Я делаю это из командной строки разработчика для Visual Studio 2017

@JaedsonBarbosa вы git clean -fdx )? Второе, что нужно попробовать, - это уменьшить длину пути (т.е. поместить свое репо в папку C: \ corefx). Еще одна вещь, которую стоит попробовать, - очистить кеш nuget ( %USERPROFILE%\AppData\Local\NuGet и %USERPROFILE%\.nuget )

Если все еще происходит, создайте отдельную проблему с информацией:

• ваша ОС
• ваша версия VS
• точные шаги, которые вы сделали
• полный журнал (если большой, то изложите суть)

Я думаю, это происходит потому, что я считаю путь C: / corefx / src / Native /../../ bin / obj / Windows_NT.x64.Debug / native \ install.vcxproj недействительным.

ОС: Windows 10
VS: 2017 Сообщество
Я просто запускаю командную строку разработчика для VS 2017 и помещаю:

cd C:/corefx
build

Теперь ошибка:

Error in the command: C:\Users\jaeds\Source\Tools\msbuild.cmd /nologo /verbosity:minimal /clp:Summary /maxcpucount /nodeReuse:false /l:BinClashLogger,Tools\net46\Microsoft.DotNet.Build.Tasks.dll;LogFile=binclash.log /p:ConfigurationGroup=Debug /p:BuildPackages=false  /flp:v=normal  /flp2:warningsonly;logfile=msbuild.wrn  /flp3:errorsonly;logfile=msbuild.err  C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj /t:rebuild /p:Configuration=Debug /p:Platform=x64 /p:PlatformToolset=v141. => O sistema não pode encontrar o arquivo especificado
Command execution failed with exit code 1.
Failed to generate native component build project!

"O sistema n├úo pode encontrar o arquivo" = "Системе не удалось найти указанный файл"

Я сдаюсь, я не могу заставить его работать с 2017 VS.
Вы знаете, когда это можно будет загрузить как пакет NuGet?

Вы должны иметь возможность использовать предварительный просмотр с myget.org.
Официальный пакет будет частью волны .NET Core 2.0 - см. Описание вехи 2.0.0 , 10 мая - ZBB (# 17619), поэтому релиз RTW должен последовать «вскоре» после него (точные даты пока не разглашаются)

@karelz Не могли бы вы прислать мне ссылку на пакет, содержащий System.Security.Cryptography.Xml?

https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml

Вот как тестировать 2.0: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

@karelz Хорошо, я хочу установить это в библиотеке классов UWP, но когда я пытаюсь это сделать, я получаю эту ошибку:

Не указано System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 без совместимости с uap10.0 (UAP, Version = v10.0). О пакоте System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 для поддержки:

• monoandroid10 (MonoAndroid, Версия = v1.0)
• monotouch10 (MonoTouch, версия = v1.0)
• netcoreapp2.0 (.NETCoreApp, Версия = v2.0)
• uap10.1 (UAP, Версия = v10.1)
• xamarinios10 (Xamarin.iOS, версия = v1.0)
• xamarinmac20 (Xamarin.Mac, версия = v2.0)
• xamarintvos10 (Xamarin.TVOS, версия = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS, версия = v1.0)

Это мой настоящий project.json:

{
  "dependencies": {
    "Microsoft.NETCore.UniversalWindowsPlatform": "5.3.1"
  },
  "frameworks": {
    "uap10.0": {}
  },
  "runtimes": {
    "win10-arm": {},
    "win10-arm-aot": {},
    "win10-x86": {},
    "win10-x86-aot": {},
    "win10-x64": {},
    "win10-x64-aot": {}
  }
}

@JaedsonBarbosa , в настоящее время мы не поддерживаем UAP для этой библиотеки, вам нужно подождать, пока https://github.com/dotnet/corefx/pull/17969 не будет объединен и будет создан новый пакет.

😧 Хорошо, я буду ждать
@krwq Но ... Что такое UAP10.1 ???

@krwq Почему вы не объединяете PR dotnet / corefx # 17969 сейчас?

@JaedsonBarbosa Он только что был объединен, я считаю, что пакет должен быть там завтра утром - мы обычно не объединяемся, если PR не горит зеленым на CI - у нас есть некоторые проблемы с OSX CI со вчерашнего дня, поэтому он немного устарел

@krwq Не могли бы вы сообщить мне, когда можно будет загрузить пакет NuGet с изменениями?

@JaedsonBarbosa предупреждаем, что поддержка .NET Standard 2.0 в UWP является передовой - она ​​не будет частью .NET Core 2.0 - она ​​будет частью следующей версии, временно названной как 2.1. Мы работаем над кое-чем из 2.1 заранее и параллельно с 2.0, чтобы создать инфраструктуру и т. Д., Чтобы затем мы могли сильно распараллелить (после 10 мая, что является нашим ZBB для 2.0).
В любом случае вы можете столкнуться с некоторыми проблемами при использовании библиотеки в UWP. Возможно, мы не сможем вам помочь сразу. После 10 мая мы сможем больше помогать ... просто устанавливаем ожидания.

@JaedsonBarbosa похоже, что мы не выпускали новую версию в течение 2 дней 😞 Вы можете увидеть изменения здесь:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
всякий раз, когда пакет появляется после 4/6, он должен иметь нужные вам изменения. Я проверю сегодня, почему не было пакета - это может быть связано с проблемами сети, которые у нас есть со сборками OSX.

РЕДАКТИРОВАТЬ: подтверждение - это связано с проблемами сети OSX

@krwq А теперь, если сегодня проблемы с сетью OSX будут решены?

Он блокирует почти все наши PR, поэтому его высокий приоритет, но у нас нет ETA

ОК 👍
Так что я буду ждать.

Когда часть 4 будет готова?

@JaedsonBarbosa у нас есть наиболее важные части, уже протестированные и доказавшие свою работоспособность. С тестированием нет единой «законченной» точки - вы можете иметь 100% покрытие кода и код, который не работает. Есть ли какие-то конкретные сценарии, которые вас интересуют?

Нет 😃

@krwq Я ожидаю, что мы объявим о том, что сделано для библиотеки, когда нам будет удобно выпускать ее как стабильную. Когда мы это сделаем, мы сможем установить флажок и закрыть эту проблему. Итак, как далеко мы продвинулись с точки зрения тестирования?

@karelz В настоящее время мне комфортно с доставкой, так как все важные сценарии E2E, которые я мог придумать, проверены. Я по-прежнему хотел бы расширить охват, чтобы можно было проверить правильность работы менее популярных сценариев (включая обработку ошибок), хотя я не ожидаю обнаружения каких-либо проблем с блокировкой 2.0.

Для меня «готово» означает, что никто больше не будет поддерживать или улучшать библиотеку.

Хорошо, если @bartonjs согласен с состоянием готовности к отправке, давайте будем практичными и закроем этот вопрос.
Если мы хотим увеличить охват тестированием (как неблокирующая версия 2.0), мы должны создать отдельный рабочий элемент для Future.

Если мы выполнили все из списка алгоритмов, преобразований и каноникализаторов, меня устраивает.

Так что я думаю, что этот вопрос наконец-то будет закрыт.

Хорошо, давайте отслеживать прогресс покрытия с помощью: https://github.com/dotnet/corefx/issues/16829 - я думал, что мы рассматриваем это как основную проблему

Да, мы рассматриваем это как основную проблему, но иногда вам нужно объявлять о том, что все сделано, иначе у вас будет одна открытая проблема для каждой более крупной функции, отслеживающей «делать больше», что на самом деле никому не помогает.

Сейчас он закрыт 😢
Итак ... Где мне задать вопросы о System.Security.Cryptography.Xml?

Разве ответ @krwq выше недостаточно?
Если у вас есть вопросы посерьезнее, напишите новый выпуск. Если это небольшое уточнение предыдущего ответа, вы можете оставить его здесь. Если не уверены, спросите здесь, и в худшем случае мы попросим вас отправить новый выпуск ;-)

@krwq Продолжение без поддержки UWP 😞

@JaedsonBarbosa https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 вам не подходит ? Не могли бы вы прислать шаги того, что вы делаете?

@krwq Я просто ввел эту команду:
Установочный пакет System.Security.Cryptography.Xml -Version 4.4.0-preview1-25210-01

Это ошибка:

Не используйте System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 без совместимости с uap10.0 (UAP, Version = v10.0). О пакоте System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 для поддержки:

• monoandroid10 (MonoAndroid, Версия = v1.0)
• monotouch10 (MonoTouch, версия = v1.0)
• netcoreapp2.0 (.NETCoreApp, Версия = v2.0)
• uap10.1 (UAP, Версия = v10.1)
• xamarinios10 (Xamarin.iOS, версия = v1.0)
• xamarinmac20 (Xamarin.Mac, версия = v2.0)
• xamarintvos10 (Xamarin.TVOS, версия = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS, версия = v1.0)

@krwq Смотрите: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01#targetframeworks

Напоминаю, что я сказал ранее: https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
Я не думаю, что вы получите поддержку UWP вместе с пакетом. Пакет зависит от .NET Standard 2.0 AFAIK, а UWP еще не поддерживает .NET Standard 2.0 - это то, над чем мы будем работать для .NET Core 2.1 (некоторые биты сделаны раньше, чтобы разблокировать более крупную команду для работы над ним после 5 / 10, но он не полностью функционален).
ИМО, чтобы получить поддержку UWP для пакета, вам придется подождать до версии 2.1.

@karelz Так ты думаешь, мне нужно будет подождать, когда?
Могу ли я создать проект uap10.1?

Да, я думаю, вам нужно подождать до тех пор.
Если только вы не сверхмотивированы и не сможете преодолеть все эти лежачие полицейские. Как я уже сказал, до 5/10 наша способность помочь вам с чем-либо UWP будет очень ограничена , поэтому вы будете в основном одни 😦. Просто устанавливаю здесь ожидания ...

Так что я подожду, потому что не могу собрать corefx-master с Visual Studio 2017 😞

@karelz @krwq Я не могу создать решение, потому что выдает ошибку, здесь вы можете увидеть CMakeError:
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
Пожалуйста, помогите мне 🆘
PS: Это на португальском языке, но вы можете использовать переводчик, чтобы прочитать это 😄

Я думаю, что это не хорошо:
- Идентификатор компилятора C - MSVC 19.0.24218.2.
- Идентификатор компилятора CXX - MSVC 19.0.24218.2.
- Проверка работоспособности компилятора C: C: / Program Files (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
- Проверить работоспособность компилятора C: C: / Program Files (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe - работает
- Обнаружение информации ABI компилятора C
- Обнаружение информации ABI компилятора C - выполнено
- Проверка работоспособности компилятора CXX: C: / Program Files (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
- Проверить работоспособность компилятора CXX: C: / Program Files (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe - работает
- Обнаружение информации ABI компилятора CXX
- Обнаружение информации ABI компилятора CXX - выполнено
- Обнаружение функций компиляции CXX
- Обнаружение функций компиляции CXX - выполнено
- Выполнение теста COMPILER_HAS_DEPRECATED_ATTR
- Выполнение теста COMPILER_HAS_DEPRECATED_ATTR - Ошибка
- Выполнение теста COMPILER_HAS_DEPRECATED
- Выполнение теста COMPILER_HAS_DEPRECATED - Успех
- Настройка выполнена
- Генерация сделана

Кто-нибудь, что я могу сделать, чтобы он построился?

@JaedsonBarbosa, как вы строите? Регулярный процесс для меня:

1. Откройте cmd.exe
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - это очистит ваш репозиторий от всех оставшихся файлов (будьте осторожны, если не знаете, что он делает)
5. build или ./build.sh если вы используете не Windows

Для сборки собственных компонентов вам необходимо установить CMake 2.8.12 или выше.

У меня это всегда работало.

@ Jaedson33, вы также можете проверить и помочь нам улучшить наши документы для новых участников (ссылки на главной странице CoreFX)

Я использую CMake 3.8.
@krwq Я сделал то, что вы сказали, и я жду около 1 часа, а там просто установка dotnet cli ..., как вы думаете, сколько часов мне нужно подождать?

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

@krwq Я получаю эту ошибку:

C:\Users\jaeds\Source\Repos\corefx>call "C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\dotnet.exe" restore "C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\\tool-runtime\project.csproj" --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json --source https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json --source https://api.nuget.org/v3/index.json  
C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\\tool-runtime\project.csproj --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json --source https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json --source https://api.nuget.org/v3/index.json
  Restoring packages for C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj...
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.diagnostics.debug/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.runtime/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.text.encoding/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.runtime/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.text.encoding/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\sdk\2.0.0-preview1-005724\NuGet.targets(97,5): error : Failed to retrieve information about 'System.Text.Encoding' from remote source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.text.encoding/index.json'. [C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj]
C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\sdk\2.0.0-preview1-005724\NuGet.targets(97,5): error :   An error occurred while sending the request. [C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj]
C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\sdk\2.0.0-preview1-005724\NuGet.targets(97,5): error :   A conexÆo com o servidor foi interrompida de modo anormal [C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj]

C:\Users\jaeds\Source\Repos\corefx>set RESTORE_ERROR_LEVEL=1 
ERROR: An error occured when running: '"C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\dotnet.exe" restore "C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\\tool-runtime\project.csproj"'. Please check above for more details.

@JaedsonBarbosa, пожалуйста, отправьте новую проблему, как было предложено выше. Напоминаем, что мы не сможем предоставить вам столько поддержки по устранению неполадок до 5/10, сколько хотелось бы.

@karelz Теперь работает 😄
Единственное, что я сделал для его сборки, это переместил файлы из C: \ Users \ jaeds \ Source \ Repos \ corefx-master в C: \ Users \ jaeds \ Source.
Думаю, это должно быть в README

Привет, теперь вы можете использовать этот пакет в приложении UWP, вот пример приложения: https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

@JaedsonBarbosa отлично! Есть ли что-нибудь из вашей работы, что было бы полезно вернуть в CoreFX? (т.е. вещи, которые не являются временными взломами)

@karelz Ну, я думаю, вы можете использовать мой проект, чтобы увидеть, что вы можете упростить (или удалить) в CoreFX 😄

Всем привет, большие усилия по портированию этого!

Могу я спросить, почему пакет Nuget ссылается на .NET Core 2.0, а не на .NET Standard 2.0? Разве это не было бы предпочтительнее?

Это должно было быть сделано (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

Я предполагаю, что вы смотрите официальный превью на Nuget
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

и это досталось только Myget
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

Да, это я и искал. Спасибо, @danmosemsft!

@leopignataro без проблем, я рекомендую вам попробовать кусочки из "головы" - вы можете получить их с домашней страницы здесь https://github.com/dotnet/cli ... вы можете просто загрузить zip, если хотите. Сообщите нам, если вы обнаружите проблемы - у нас осталось совсем немного времени, чтобы исправить их до выпуска.

К вашему сведению: вот информация о временных рамках: https://github.com/dotnet/corefx/issues/17619#issuecomment -301937346

Поскольку вы упомянули об этом, @danmosemsft , есть одна проблема:

https://github.com/dotnet/corefx/issues/19198

Я предложил исправить эту тему, но мое сообщение могло быть пропущено во всех обновлениях.

@leopignataro исправить для чего где? Если это исправление для dotnet / corefx # 19198, то это должно быть отслежено в ошибке. Если это что-то еще, я бы предпочел увидеть для него отдельную проблему.
Если вы думаете, что ваше предложение по исправлению было где-то упущено, снова поднимите его в этой теме и попросите оставить отзыв.

Теперь я смущен. Я думал, что пакет NuGet System.Security.Cryptography.Xml предназначен для .NET Framework и уже включен в Dot Net Core v2. Это пространство имен не распознается в Dot Net Core v2. Я неправильно это слышал? Спасибо.

@ fletchsod-developer Пакет предназначен в основном для .NET Core. Но если вы ссылаетесь на него из библиотеки, ориентированной на .NET Standard, он будет унифицирован с версией .NET Framework на .NET Framework и запускать код из пакета на .NET Core.

У нас нет никаких планов по включению SignedXml в стандартную установку .NET Core; это достаточно ниша, чтобы быть отдельным пакетом в NuGet, кажется, лучшей моделью распространения.