Runtime: Agregar clase System.Security.Cryptography.Xml.SignedXml

Como lo menciona Tratcher, este es un bloqueador para agregar soporte para WsFederation / ADFS en ASP.NET 5. Usamos ADFS ampliamente para muchas aplicaciones empresariales ASP.NET 4. Estamos muy interesados ​​en migrar a ASP.NET 5 y usar WsFederation.

@rschiefer @Tratcher Bueno, es ... complicado.

• ADFS no usa System.Security.Cryptography.Xml.SignedXml; sino su propia implementación.
  
  
  
  • (Eso se debe en gran parte a desempolvar las telarañas mentales y recordar estar en ese equipo para la versión 1 de ADFS)
  
  
• System.IdentityModel definitivamente no usa System.Security.Cryptography.Xml
  
  
  
  • (Eso es porque su código fuente en la fuente de referencia lo dice: sonríe :)
  
  
• A la gente realmente no le gusta System.Security.Cryptography.Xml.SignedXml porque está basado en XmlDocument, lo que genera algunos problemas de rendimiento.
  
  
  
  • La versión de ADFS se basó en XmlReader, IIRC.
  
  
• Entonces, probablemente lo que la gente quiera es CoreFX para crear una nueva implementación de SignedXml.
• Pero una nueva versión de SignedXml no será compatible con la versión anterior de SignedXml
• Por lo tanto, es posible que algunas personas quieran que también mantengamos la versión anterior.
• Entonces, en general, la gente realmente quiere dos versiones.
• Excepto que no quieren la versión anterior.
• Excepto cuando lo hacen.

Así que nos quedamos con el enigma de:

• Podemos portar esa clase que nadie realmente quiere
• O podemos detenernos y diseñar algo nuevo que probablemente nadie usará, ya que no pueden ser compatibles con ninguna otra cosa.
• O, para hacer el mayor esfuerzo y aún así no beneficiar a nadie, haz ambas cosas: sonríe :

@terrajobst - fyi

Aparentemente estaba un poco distraído esta mañana. Perdón :).

Definitivamente hemos identificado que hay trabajo por hacer aquí, pero no creemos que la respuesta correcta sea presentar el código System.Security.Cryptography.Xml existente. En cambio, esto representa el elemento de nuestro backlog para diseñar una implementación de propósito general para XmlDSig que sea rápida y no esté ligada a modelos de objetos heredados (por ejemplo, XmlDocument).

Ese esfuerzo no es algo que esperamos hacer para .NET Core 1.0, simplemente porque estamos enfocados en otras cosas.

Pero, informarnos que está afectado por la funcionalidad faltante ayuda con la priorización continua.

Estoy pensando en crear un Middleware ASP.NET Core SAML2, basado en https://github.com/KentorIT/authservices. Sin un puerto SignedXml, no podrá ejecutarse en el marco Core.

Definitivamente estoy de acuerdo en que no transferir el existente es una buena idea. ¿Sería posible hacer algo basado en una API de XmlReader? De esa manera, se pueden admitir tanto XDocument como XmlDocument. También sería bueno proporcionar una implementación del lector envuelto utilizado en System.IdentityModel (si se mejorara para admitir archivos XML con espacios en blanco ...)

@AndersAbel XmlReader es donde comenzaría, sí (a menos que los chicos de XML me digan que hay algo mejor).

Dado que XmlReader en qué se basa la variante System.IdentityModel, debería ser factible :).

@bartonjs La variante System.IdentityModel es bastante limitada, sin embargo, en las transformaciones que puede manejar. Para el trabajo de SAML2 / WS-Fed, no sería un problema, pero como API general se debe considerar cómo tratar con firmas no envueltas y XML que contiene firmas anidadas (como una respuesta saml firmada que contiene aserciones firmadas). También creo que System.IdentityModel.EnvelopedSignatureReader está copiando los datos al hacer la validación. Hay mucha diversión por hacer allí. Si tuviera tiempo, me encantaría trabajar en ello.

Aprecio el divagar @bartonjs , ayuda a ver lo que sucede detrás de escena.

Actualmente mi empresa se ve afectada por esto. Tenemos un código heredado que estamos intentando transferir a .NET Core que genera archivos de licencia XML firmados y sin este conjunto de clases estamos atascados. Estamos abiertos a divergir de los archivos XML como base para las licencias, pero hasta el momento no hemos encontrado una buena solución que se ajuste a nuestras necesidades.

Espero ver que esto se agregue en el futuro.

Puedo dar fe de que esto (y también el cifrado XML ligeramente relacionado) es relevante para nosotros. El formulario existente en .NET Framework estaría bien, no hay necesidad de innovación aquí, desde mi perspectiva. ¡La implementación de copiar y pegar sería muy bienvenida!

¿Existe actualmente alguna solución alternativa disponible?

También me gustaría saber qué preguntó

@sandersaares / @ af0l : No hay, para .NET Core 1.0, ninguna implementación incorporada de SignedXml / XmlDSig.

De acuerdo con los comentarios aquí (y otros) probablemente solo traeremos la API anterior, pero no tuvimos tiempo de hacerlo realidad para la versión 1.0.

Gracias @bartonjs , esa debe ser la razón por la que no pude hacer que nuestro proyecto funcionara en Core. :) También es una gran lástima, porque me encantaría seguir adelante y no puedo hasta que esté hecho. Tenemos que informar todos los pagos a nuestra autoridad fiscal utilizando XML firmado, por lo que es realmente sorprendente.

¿Algún progreso en esto? Estoy atascado con la validación del token SAML que requiere esta función. Gracias

Sí, me gustaría saber eso también. Terminamos extrayendo las características que necesitaban la firma y poniéndolas en una solución API web separada ...

Ya tengo idea de qué versión se implementará o solución

En este punto, parece que la respuesta más sencilla es migrar la implementación de .NET Framework existente a .NET Core. Así que estamos agrupando esto con otras omisiones de API que "dificultan la portabilidad".

Potencialmente relevante para el tema: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently y https://github.com/sandersaares/ xml-c14n-defecto de espacio en blanco. Me parece que la implementación de .NET Framework de Canonical XML 1.0 es incorrecta. Espero estar equivocado, pero si es así, esto podría presentar algunas preguntas de compatibilidad complicadas.

@sandersaares Miró su muestra y necesita establecer XmlDocument.PreserveWhiteSpace = true al leer el XML si contiene espacios en blanco.

@AndersAbel ¡ Gracias por la pista! Eso cambia la situación y realmente permite la validación conforme si hay un esquema XML presente. Sin un esquema XML, el comportamiento sigue siendo inválido (de una manera nueva y emocionante). He actualizado el problema de Connect y el repositorio de GitHub en consecuencia.

@bartonjs Si https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

Para su información, si esto llega a la etapa de implementación, entonces tengo una biblioteca recién acuñada aquí, con pruebas, que hace uso de firmas XML (tanto para firmar como para verificar) y otras funciones XML en .NET Framework; podría ser útil para obtener algo real sin dependencias. -código mundial para probar la implementación: https://github.com/Axinom/cpix

¿Existe un cronograma para el desarrollo de esta API?

// cc @bartonjs

@henkmollema Nada específico, no. Para la versión 1.2, estamos trabajando para reducir la brecha entre .NET Framework y .NET Core; y ese esfuerzo es actualmente de donde proviene SignedXml.

Hoy estaba en una llamada de cliente que necesita compatibilidad con SAML2-P en ASP.NET Core (que usaría la implementación de KentorIT). Este es un problema de bloqueo para los clientes que desean migrar a ASP.NET Core. Por ahora, mi cliente tendrá que permanecer en Katana.

Veo que el hito se cambió de 1.2 a Future (por @bartonjs). ¿Puedes comentar o dar más detalles?

Principalmente, solo tiene que ver con cómo estamos rastreando los hitos. Solíamos hacer más de "esperamos que haga este", luego, al final del hito, reasignábamos todo lo que no se había hecho. Ahora nos esforzamos mucho en decir "si lo marcamos para este hito, debería ser muy raro que se reasigne".

Esto es posterior a muchos otros trabajos para el hito 1.2, y fue (para mí, de todos modos) siempre un poco exagerado para llegar a 1.2. Todavía está bastante arriba en nuestra lista de "lo que sigue", simplemente no nos "comprometemos" a que sea parte de la versión 1.2 (que es principalmente trabajo netstandard2.0, corrección de errores y un par de proyectos de infraestructura).

Marcarlo como Futuro no garantiza que no será parte de la versión 1.2, solo significa (usando nuestra interpretación actual de hito) que no retendremos el lanzamiento para él. Una vez que alguien está realmente trabajando en él, entonces hay una mejor comprensión de cuándo se terminará realmente, y luego se marcará como el hito en el que realmente se lanzará.

@karelz Si hay algo que quieras agregar (o corregir), siéntete bienvenido a participar.

No podremos financiar el trabajo en un período de tiempo de 1.2 (hay muchas otras cosas con mayor impacto para terminar). por eso lo trasladamos a Future milestone, para comunicar nuestros planes.
Somos conscientes de la cantidad de solicitudes, por eso es alta en nuestra área de seguridad. También es una de las API faltantes de corefx más solicitadas en general (entre DirectoryServices, SerialPort, etc.).

cc: @steveharter @danmosemsft @terrajobst

Nuestras respuestas se cruzaron :)
Más contexto sobre Milestones está en nuestra guía de problemas .

El código de .NET Framework está disponible como fuente de referencia . Entonces, técnicamente hablando, el puerto se puede iniciar incluso fuera del equipo de .NET Core, si la gente está interesada en ayudarnos aquí.
De mis charlas anteriores con @bartonjs , creo que el "desafío" clave será crear / transferir pruebas.

Oye, ¿cuál es la situación real sobre ese problema?

@ Jaedson33 ¿Qué quieres decir con "problema"? Si se refiere a cuándo se solucionará, consulte las respuestas de la semana pasada.

@karelz Pero no quiero esperar. ¿Por qué no lo arreglas ahora?

@ Jaedson33 vea mi respuesta anterior: explica por qué no podemos financiarlo ahora. Se trata de prioridades. Hay una línea de personas que quieren muchas funciones / API ahora, pero no tenemos un equipo de tamaño infinito, por lo que tenemos que priorizar.

Si lo necesita con urgencia lo antes posible, siempre puede contribuir a la base del código, estaremos encantados de ayudarle con orientación, revisiones de código y comentarios.

Ok, esperaré.

@karelz si las pruebas originales todavía están disponibles para verificar el trabajo, estaría dispuesto a levantar la mano :)

(uno de mis compañeros de trabajo también tiene experiencia relevante, por lo que probablemente estaríamos trabajando juntos en ello)

En realidad, una parte clave del trabajo es crear nuevos activos de prueba. Las pruebas antiguas son insuficientes y tienen poca cobertura. Necesitaremos que alguien revise las especificaciones y agregue pruebas para cada requisito interesante; ahí es donde está la mayor parte del costo.

Si aún está interesado, podemos intentar colocar el código fuente de .NET Framework completo tal como está; el siguiente paso será construirlo y agregar cobertura de prueba, antes de que pueda lanzarse como parte de .NET Core. Hazme saber si estas interesado ...

Ok, sí, todavía estamos interesados ​​:)

@tintoy Estoy interesado en ayudarte porque realmente necesito esa clase.

@tintoy Estoy interesado en ayudarte porque realmente necesito esa clase.

Alegra oírlo :)

Entonces ... ¿Cómo puedo ayudar?
Obs: Es la primera vez que uso GitHub.

Entonces ... ¿Cómo puedo ayudar?

Primero, permítame hablar con mi compañero de trabajo y elaboraremos un plan de ataque. @karelz : ¿existen pautas u otros documentos que debamos leer antes de entrar? Para empezar, supongo que mi compañero de trabajo probablemente se adentrará en el estándar, probablemente veré dónde debe ir el código (y qué implica hacer que las pruebas existentes de otras partes del marco se ejecuten antes de hacer algún cambio). ¿Suena razonable?

CC: @anthonylangsworth

Para mantener el alcance un poco limitado, recomendaría comenzar sin las funciones que están deshabilitadas por MS16-035 (transformación xpath, transformación xslt, referencias externas). No sé qué espacio hay para romper los cambios, pero el mecanismo de reserva actual en DefaultGetIdElement se puede aprovechar en los ataques de envoltura de firmas. Preferiría una versión predeterminada más segura.

También sería bueno si la API interna se reestructurara un poco para admitir el EnvelopedSignatureReader utilizado por System.IdentityModel en lugar de tener dos implementaciones separadas de validación de firma XML.

Finalmente, también me gustaría que se agregara un solo punto según este informe de error .

@tintoy No creo que tengamos buenos documentos. Creo que deberíamos agregar las fuentes y luego podemos paralelizar el trabajo; permítanme sincronizar con @bartonjs @steveharter @ianhays.

Intentaré encontrar algo de tiempo para ayudar también. Si hay alguna pregunta sobre la especificación y cómo funciona, estaré feliz de investigarla; ya he pasado algún tiempo revisando la especificación.

¿Alguien tiene algo que decir sobre la idea de consolidar SignedXml y EnvelopedSignatureReader utilizado por System.IdentityModel?

@AndersAbel

comenzar sin las funciones que están deshabilitadas por MS16-035 (transformación xpath, transformación xslt, referencias externas)

Deberíamos empezar con el último código fuente de .NET Framework, que debería ser seguro. Si tiene alguna inquietud acerca de la seguridad del código de .NET Framework, háganoslo saber sin conexión.

No se que espacio hay para romper cambios

No hay espacio, deberíamos comenzar con un puerto sencillo de .NET Framework. Cualquier mejora adicional, cambio, cambios importantes, etc. se puede considerar más adelante. No como parte del trabajo inicial. De lo contrario, crecerá sobre nuestras cabezas.

El mecanismo de reserva actual en DefaultGetIdElement se puede explotar en ataques de envoltura de firmas

Eso debería tratarse como un problema separado. @bartonjs , ¿puedes comentar?

También sería bueno si la API interna se reestructurara un poco para admitir el EnvelopedSignatureReader utilizado por System.IdentityModel en lugar de tener dos implementaciones separadas de validación de firma XML.

Nuevamente, tomémoslo como el siguiente paso, después de que tengamos un puerto completamente funcional con una buena cobertura de prueba.

Finalmente, también me gustaría que se agregara un solo punto según este informe de error.

Preséntelo como un problema separado aquí, en GitHub. Idealmente, después de que tengamos el código aquí portado (es decir, cuando el error sea realmente aplicable a .NET Core).

¿Alguien tiene algo que decir sobre la idea de consolidar SignedXml y EnvelopedSignatureReader utilizado por System.IdentityModel?

Solo quiero reiterar. Deberíamos tratarlo como el siguiente paso, la portabilidad posterior.

El mecanismo de reserva actual en DefaultGetIdElement se puede explotar en ataques de envoltura de firmas

Eso debería tratarse como un problema separado. @bartonjs , ¿puedes comentar?

@AndersAbel Si cree que existe un problema de seguridad, siga el proceso de informe de vulnerabilidades en https://technet.microsoft.com/en-us/security/ff852094.aspx.

¿Alguien tiene algo que decir sobre la idea de consolidar SignedXml y EnvelopedSignatureReader utilizado por System.IdentityModel ?.

Probablemente no sea posible. SignedXml se basa en gran medida (y aliado de la API pública) en el XmlDocument rich-DOM. La representación de IdentityModel se basa en XmlReader. Pero, una vez que se trae el material existente, se puede investigar.

Intentaré encontrar algo de tiempo para ayudar también. Si hay alguna pregunta sobre la especificación y cómo funciona, estaré feliz de investigarla; ya he pasado algún tiempo revisando la especificación.

@AndersAbel -

@bartonjs He informado esos problemas a [email protected] , lo que resultó en MS16-035. Sin embargo, en mi opinión, quedan algunos problemas riesgosos que MS decidió no solucionar (incurrirían en cambios importantes). Aún no he publicado los detalles, pero si desea discutirlos en privado, envíeme un correo electrónico.

@karelz Gracias por aclarar que no hay lugar para cambios importantes. Eso significa que mis ideas sobre la consolidación no son relevantes.

comenzar sin las funciones que están deshabilitadas por MS16-035 (transformación xpath, transformación xslt, referencias externas)

Deberíamos empezar con el último código fuente de .NET Framework, que debería ser seguro. Si tiene alguna inquietud acerca de la seguridad del código de .NET Framework, háganoslo saber sin conexión.

El parche MS16-035 solucionó una serie de problemas en SignedXml. Sin embargo, es posible utilizar claves de registro para volver al antiguo comportamiento inseguro. ¿Deben esas opciones también ser portadas a .NET Core? Mi sugerencia anterior estaba destinada a priorizar la transferencia del comportamiento predeterminado actual de .NET Framework, dejando atrás las partes que están desactivadas de forma predeterminada por ahora. ¿O quiere decir que esas partes también son cruciales para ser movidas? Luego está la pregunta de cómo manejar la configuración, ya que .NET Core AFAIK no depende del registro para la configuración (ya que no está disponible en todas las plataformas).

Sin embargo, es posible utilizar claves de registro para volver al antiguo comportamiento inseguro. ¿Deben esas opciones también ser portadas a .NET Core?

No. El código de solo compatibilidad de registro se eliminará antes de que el paquete esté disponible.

¿Por qué no crea un proyecto en GitHub para implementar eso?

Sincronizamos con @steveharter y @ianhays

EDITAR: El plan de ejecución se movió a la parte superior de la publicación.

Suena bien para mí :)

@karelz , @steveharter La mayoría de las búsquedas de registro se encuentran en la clase Utils : AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier . También hay una búsqueda en la clase SignedXml donde configura la lista de transformaciones conocidas. Sin la compatibilidad del registro, no creo que se pueda acceder a XmlDsigXPathTransform y XmlDsigXsltTransform . ¿Deberían eliminarse por completo de la fuente junto con el código de compatibilidad del registro?

Esos son los que conozco, no he visto ningún otro mientras leía el código, pero es posible que me haya perdido algo.

@AndersAbel Actualicé el comentario de Karel anterior sobre el registro. Si hay clases a las que no se puede acceder, debemos comprender qué funcionalidad se está perdiendo. Para los que mencionas, creo que CryptoConfig debe agregar el nombre: par de

¿Cuándo crees que estará lista esta clase?

¿Te refieres a las contribuciones? @steveharter planea enviar el PR inicial de "agregar fuentes" muy pronto (probablemente hoy).

El código inicial acaba de fusionarse.

@steveharter Gracias 😃

¡Gracias @steveharter! Moví el plan de ejecución a la publicación más alta para facilitar el seguimiento del progreso. Siempre que le hagamos cambios, mencionaremos los cambios en otra respuesta aquí.

Si alguien quiere empezar a trabajar en él, dígalo para evitar duplicar el trabajo. Le asignaremos conjuntamente el problema.

@karelz : @tintoy y yo levantamos las manos para empezar con esto. Feliz de que nos lo asignes.

Si alguien quiere empezar a trabajar en él, dígalo para evitar duplicar el trabajo. Le asignaremos conjuntamente el problema.

Saludos - Estoy feliz de comenzar a compilar :)

@anthonylangsworth - ¡

El trabajo está sucediendo aquí .

Asignado a @tintoy. Lo asignaré también a

¡Gracias!

@karelz solo para confirmar, por lo que entiendo de las pautas para contribuyentes, debo hacer estos cambios en master ?

(mi master obviamente)

Ergh, lo siento, déjame intentarlo de nuevo, ¿el eventual PR contra tu master ?

Sí, eso es correcto. Simplemente no lo haga parte de la ejecución de prueba / compilación completa de corefx hasta la última fase.

Encontré un par de constantes que parecen haberse movido a una clase interna en src / Common / src / Interop / Windows / Crypt32 / Interop.certificates_types.cs . Sin embargo, esto no es accesible desde System.Security.Cryptography.Xml . ¿Alguna idea sobre el mejor enfoque aquí?

¿Cuáles de ellos son necesarios? ¿Todos ellos?
¿Puede verificar la fuente de referencia si son públicas en .NET Fx? (No lo creo, pero no está de más comprobarlo)
Estoy un poco sorprendido de que hagamos una interoperabilidad especial, en lugar de aprovechar el resto de la biblioteca Crypto ... o necesita algo especial, o es por razones históricas ... @steveharter @bartonjs ¿ Alguna idea?

@tintoy Una de las cosas que hay que hacer en este esfuerzo es eliminar la interfaz directa con CAPI y pasar al uso de las API .NET.

@karelz , @bartonjs : la mayoría de las constantes CAPI HRESULT se pasan al constructor CryptographicException .

Por ejemplo:

src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / KeyInfoX509Data.cs (línea 63)

Echaré un vistazo a cómo funciona otro código en corefx con CryptographicException .

Ah, está bien, entonces parece que el constructor HRESULT ya no se usa, solo el que toma un mensaje. Veré si hay recursos de mensajes existentes que se correspondan con esos valores E_xxx .

En cuanto a los otros problemas, me parece que es el resultado de que los tipos ya no comparten un solo ensamblado. Por ejemplo, X509Utils.DecodeHexString está en System.Security.Cryptography.X509Certificates pero en el marco completo esto solo vive en el ensamblaje System.Security junto con las clases que lo usan.

Dado que todo se ha dividido en múltiples ensamblajes, ¿cuál es su mecanismo preferido para lidiar con lo que normalmente serían componentes compartidos? Podría simplemente hacer una copia de las funciones requeridas del código en otros ensamblados si eso es lo que prefiere.

O extraiga la fuente usando algo como:

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

Por ahora, he solucionado el problema de CAPI simplemente compilando `Interop.certificates_types.cs en el ensamblaje y haciendo referencia a las constantes desde allí.

También tuve que copiar algunos métodos de X509Utils.cs en el marco completo (principalmente relacionado con la codificación / decodificación hexadecimal) ya que no hay nada disponible públicamente en corefx que haga esto.

Los únicos problemas restantes están en src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / SymmetricKeyWrap.cs (línea 34, entre otros) que resultan en errores como:

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

Por ahora, he suprimido el error. Así que ahora todo se compila :)

Ok, bueno, excepto por el proyecto de prueba:

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

Lo resolveré mañana.

@karelz @bartonjs Voy a abrir un PR para que podamos discutir los cambios (el trabajo básicamente está hecho, por lo que puedo decir). ¿Estás de acuerdo con eso?

Suena bien para mí. @steveharter ¿ alguna idea?

Feliz año nuevo = D

¿Tiene alguna idea de cuándo se completará la fase 2?

dotnet / corefx # 14662 ya está combinado, esa fue la fase 2. Lo marcaré en la publicación superior como 'marcado'.

Para que quede claro: una vez que se completen los 5 pasos anteriores, para obtener soporte de ws en ASP.NET Core, el equipo de AAD debe hacer sus bits de token SAML, luego los equipos de ASP.NET deben construir el ws middleware alimentado en la pieza AAD. ¿Eso coincide con tus expectativas?

No, este trabajo no tiene nada que ver con WS-Fed.
Debo una respuesta y una explicación en https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500

FYI: Respuesta publicada: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

Entonces, ¿cuándo se completará la fase 4?

Si está preguntando cuándo el equipo de .NET tendrá tiempo para hacerlo, aún no lo sabemos. Es una parte importante de nuestra cartera de pedidos, pero hay un par de prioridades más importantes que debemos abordar primero.

Mientras tanto, estamos abiertos a las contribuciones de la comunidad en el espacio.

Estoy feliz de seguir trabajando en esto, pero estoy un poco estancado en este momento; desde que corefx se trasladó al nuevo proceso de compilación, System.Security.Cryptography.Xml ya no se compila (por lo que

PD. Pasé unos 20 minutos rastreando el proceso de compilación para averiguar por qué ya no se compila, pero aún no lo he resuelto. Cualquier indicador sería apreciada...

@mellinoe @weshaggard , ¿puede proporcionar una guía para migrar SignedXml al nuevo sistema de compilación?

😭😭 Creo que tendré que esperar 😭😭

@tintoy, si me

@weshaggard actualmente no hay una rama: el código está en el maestro, simplemente no está conectado a la compilación raíz (a propósito) - src / System.Security.Cryptography.Xml (introducido en dotnet / corefx # 14628). @steveharter puede proporcionar información adicional.

@weshaggard @karelz Estoy feliz de crear una rama en nuestra bifurcación y solo construirla allí para desbloquearnos; más tarde, siempre podemos seleccionar cualquier cambio que hayamos realizado una vez que se vuelva a generar en master . Avísame si este es tu enfoque preferido :)

PR https://github.com/dotnet/corefx/pull/15491 debería hacer que la infraestructura del proyecto funcione. Una vez que CI lo apruebe, podemos fusionarlo y debería impulsar sus esfuerzos.

Gracias, he cambiado la base de jugaré con él en breve :)

@weshaggard ok, así que tanto src como el proyecto de prueba se <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ), obtengo:

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 ==========

Supongo que me he perdido algo sobre cómo las referencias entre proyectos deben funcionar en corefx.

@tintoy No estoy seguro de cuál es ese error específicamente, pero generalmente no necesitamos ProjectReferences en nuestro nuevo sistema de ingeniería. Para la compilación de prueba, siempre construimos y hacemos referencia al paquete de orientación completo, en este caso producido en bin\ref\netcoreapp . La biblioteca que se coloca en ese directorio es lo que crea desde su carpeta de referencia que actualmente está vacía. Entonces, para comenzar, necesita generar una referencia con el área de superficie de la API que necesita y obtener la construcción de la referencia, luego su proyecto de prueba verá automáticamente las API y podrá construir contra ellas. Tenemos una herramienta llamada genapi que puede generar la referencia basada en otra biblioteca. Permítanme enviar otro PR rápidamente para sembrar eso para ustedes.

Ok, ahora lo entiendo; la razón por la que no veo tipos en el proyecto de prueba es porque el proyecto de referencia aún no tiene tipos :-)

@weshaggard, si no tienes tiempo, probablemente pueda averiguar cómo hacerlo; Estaba leyendo sobre esa herramienta el otro día.

Rápidamente ejecuté la herramienta genapi y presioné ese compromiso https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e. Siéntase libre de tomarlo o regenerarlo usted mismo. Deberá agregar ProjectReference a otras referencias para que se compile.

Saludos, eso me ahorrará tiempo, muy apreciado.

@weshaggard éxito! Gracias, espero que podamos empezar a escribir esas pruebas ahora :)

(tintoy @ dd834c63af4fe40faf84bc6a776b474ec9947eb1 , simplemente ignore el duplicado)

¡Sí! Hágase una prueba de funcionamiento:

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

¡Gracias por tu ayuda, @weshaggard!

PD. Tuve que anular localmente (a través del archivo .user ) la ruta ejecutable en las propiedades del proyecto de prueba (pestaña Depurar). Era D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe pero solo funcionó cuando lo cambié a D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe .

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

Mi VS no se queja de las barras. Los separadores de ruta son generalmente una molestia porque estamos tratando de hacer que las cosas funcionen tanto en Windows como en Unix, por lo que terminamos viendo un montón de barras inclinadas mixtas en Windows, lo que generalmente es más aceptable que en Unix.

Solo por curiosidad, ¿qué versión de VS estás usando? 2015 o 2017? Quizás se haya solucionado en 2017 :)

(Por lo general, estoy en OSX o Linux en estos días, por lo que aprecio totalmente el esfuerzo por hacer que las cosas sean compatibles con la multiplataforma, por cierto)

Estoy usando VS 2015 en Windows 10 y abrí la solución y pude F5 para depurar las pruebas y mi ruta de depuración es D:\git\corefx\Tools/testdotnetcli\dotnet.exe

Ok, debo estar volviéndome loco, ¡ahora tampoco puedo reproducirlo!

Antes, se quejaba de no poder encontrar dotnet.exe , pero comenzó a funcionar cuando configuré explícitamente el ejecutable en una ruta con solo barras invertidas. Acabo de eliminar el archivo .csproj.user y _todavía_ funciona, así que quién sabe: -o

Hola chicos, me encantaría participar en la redacción de pruebas. ¿Qué puedo hacer para empezar a contribuir?

Genial, creo que ahora podríamos estar en la etapa en la que podemos comenzar a hacer eso :)

Permítame consultar con un compañero de trabajo para ver si ha realizado con éxito su primera prueba ...

cc: @anthonylangsworth

@karelz ,

@anthonylangsworth y yo comenzamos a escribir pruebas ; Soy consciente de que no hemos llegado a un acuerdo común sobre lo que se debe probar, pero vamos a comenzar de todos modos y luego trasladar las pruebas a donde acordamos hacer el trabajo.

Y para aquellos que se han ofrecido como voluntarios para ayudar con las pruebas (lo cual es muy apreciado), deberíamos estar en condiciones de dividir el trabajo sugerido a principios de la próxima semana :)

Con respecto a la cobertura de las pruebas y qué pruebas necesitamos, @bartonjs tenía una opinión sólida al respecto (ya que tiene la mayor experiencia con el tipo y sus problemas de nuestro lado). Sugirió escribir pruebas según la especificación (lo mencioné anteriormente ).
Regresará de vacaciones a fines de la próxima semana. Probablemente deberíamos discutir los detalles y expectativas con él.
También @AndersAbel mencionó la experiencia en especificaciones y la ayuda potencial al principio de la discusión .

cc @steveharter si tiene orientación adicional mientras @bartonjs está fuera de servicio.

¡Gracias @tintoy @anthonylangsworth por sus contribuciones aquí! ¡Nosotros realmente lo apreciamos!
Y también gracias a todos los que planean participar ;-)

cc @ steveharter si tiene orientación adicional mientras @ bartonjs está fuera de servicio.

Mi curiosidad llegó a un punto que exigía ser satisfecha.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
Me siento mejor ahora.

😃 ¡Ni siquiera sabía que es tan específico de Microsoft! Gracias por tu divertida iluminación 😃

@anthonylangsworth ha comenzado a esbozar un plan de prueba aproximado en tintoy / corefx # 3 (he copiado su plan en un número para facilitar el comentario), así que al menos tenemos algo que discutir. No dudes en echarle un vistazo y darnos tu opinión :)

CC: @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (o cualquier persona a quien le concierna) ¿Cuál es la política sobre el uso de InternalsVisibleToAttribute para las pruebas? Hay muchas clases internal dentro de ese espacio de nombres y obtener una cobertura de prueba adecuada puede ser difícil solo a través de métodos públicos. Sin embargo, agradezco que haya otras consideraciones.

Hmmm, lamentablemente, no lo sé, ¿ @weshaggard @stephentoub? (pregunta en respuesta anterior)

Por lo que he visto de otro código en corefx, los proyectos en cuestión a veces incluyen los archivos fuente relevantes de otros proyectos (aunque imagino que esto se complicará bastante rápido debido a los gráficos de dependencia).

Desde la memoria, System.Collections.Immutable usa [InternalsVisibleTo] , si eso es de alguna ayuda.

Por ejemplo:

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

Más generalmente:

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

Puede ver mis pensamientos sobre InternalsVisibleTo en este número anterior https://github.com/dotnet/corefx/issues/1604. Mi opinión general es no hacerlo a menos que exista una necesidad específica real de hacerlo.

¿Cuál es la política sobre el uso de InternalsVisibleToAttribute para las pruebas?

No.

Hay muchas clases internas dentro de ese espacio de nombres y obtener una cobertura de prueba adecuada puede ser difícil solo a través de métodos públicos.

Si se trata de algo que no sea una ruta de excepción profunda, debería ser accesible o eliminarse. Si se necesita un caso de prueba complicado para acertar, bueno, eso es lo que necesitamos.

Los proyectos en cuestión a veces incluyen los archivos fuente relevantes de otros proyectos.

Suponiendo que te refieres a "los proyectos de prueba incluyen la fuente del producto para obtener acceso a los miembros internos": No.

[InternalsVisibleTo] y el intercambio de fuentes son estrategias heredadas. Los más vociferantes de nosotros creemos (esencialmente) que nuestras pruebas solo deberían ser representativas de cosas que podrían encontrarse en el mundo real. Si no es posible realizar una prueba para alcanzar un bloque en particular, ¿por qué existe? Sí, hay algunos bloques que lanzan excepciones que no se pueden golpear porque un cheque redundante más alto en la pila ya lo atrapó; pero eso es algo que se puede mirar a posteriori y declarar que está bien.

Por lo tanto, recomendaría aumentar la especificación y asegurarse de que haya una prueba positiva para cada característica (por ejemplo, cada algoritmo que dice que admite y casos límite para valores mínimos / máximos para las opciones de esos algoritmos).

Las pruebas negativas como eliminar elementos requeridos (por ejemplo, 4.1 dice que SignedInfo es un elemento requerido para Signature ... ¿emitimos una excepción razonable si falta?) También son buenas.

Las pruebas de opciones de Canonicalizer, como <foo><!-- hi --></foo> y <foo></foo> (y tal vez <foo /> ?) Son iguales en c14n , pero diferentes en c14n-withcomments . (Esto probablemente requiera firmar en ambos sentidos, luego intercambiar cuerpos, ya que el algoritmo de canonicalización debe estar firmado).

Transformar pruebas. Todos los canonicalizadores son transformados. Etc.

Las pruebas de manipulación también son buenas. Pero si cree que encontró una prueba de manipulación que manipula con éxito, no la informe aquí ni la envíe / envíe a ninguna reproducción en github (envíe la prueba / caso / descripción por correo electrónico a [email protected]).

Está bien, he pensado demasiado por hoy. De vuelta de vacaciones ahora.

¡Gracias @bartonjs por sus ideas durante sus vacaciones! Ahora ve y diviértete en el mundo real ;-)

@karelz @bartonjs (¡aunque solo una vez que regreses de las vacaciones!) @steveharter y cualquier otra persona con una opinión:

@anthonylangsworth ha creado algunas pruebas iniciales para iniciar la discusión, y agradeceríamos cualquier comentario que pueda tener hasta ahora.

Veo que Mono tiene algunas pruebas SignedXml. Estos deben ser evaluados y examinados según la especificación xmldigsig, las sugerencias que @bartonjs mencionó anteriormente y el código actual para ver qué \ si vale la pena portar \ traer. Envíeme un ping para obtener información de derechos de autor (encabezado) si tiene sentido traer estas pruebas.

Gracias, echaremos un vistazo a eso :)

Gracias por eso, @steveharter . ¿Puede proporcionar enlaces, por favor? Estos podrían acortar muchas de nuestras pruebas. ¿Existe algún derecho de autor u otras consideraciones si ampliamos o construimos sobre estos en lugar de copiarlos textualmente?

@anthonylangsworth al copiar el código fuente de Mono, tenemos que mantener y actualizar el encabezado de derechos de autor. Sugeriría hacer primero solo una copia (con los encabezados correctos, ajustes potencialmente menores). Una vez que tenemos el código en CoreFX, podemos modificar el código como queramos.

Pruebas mono https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.cs

Gracias, @steveharter. Comencé a convertir las pruebas de NUnit a Xunit .

Publiqué esto, pero me di cuenta de que está en el @anthonylangsworth :

Aquí está la magia que se puede hacer con los encabezados de derechos de autor cuando extraemos código de 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.

¿Hay pruebas fallidas en este proyecto?

@ Jaedson33 Actualmente estamos convirtiendo las pruebas mono. Todavía no he encontrado ninguna prueba fallida que indique errores de código, pero todavía tenemos muchas pruebas por hacer.

@anthonylangsworth ¿Qué puedo hacer para ayudar?

@ Jaedson33 He respondido esa pregunta en https://github.com/tintoy/corefx/issues/6#issuecomment -280904587. Para resumir, tenemos 84 pruebas mono que aún fallan (principalmente debido a cambios predeterminados y limitaciones del núcleo .Net). Se agradece cualquier ayuda para que las pruebas restantes funcionen. De lo contrario, estoy trabajando con ellos.

@karelz @bartonjs @steveharter La clase System.Security.Cryptography.CryptoConfig indica que muchas transformaciones XML no son compatibles con CoreFx (líneas 281 a 303 al final de DefaultNameHT ).

Estos corresponden a los URI utilizados por las clases en el espacio System.Security.Cryptography.Xml nombres System.Security.Cryptography.Xml nuevamente en .Net Core, supongo que deberíamos restablecerlos. Por favor, avíseme si me equivoco.

CC: @tintoy

@anthonylangsworth , algunas de esas transformaciones, como XmlDsigC14NTransform, están bien, pero otras, como XmlDsigXsltTransform, se consideran muy peligrosas. Si bien puede habilitarlos a través de la opción de clave de registro en el .NET Framework completo, prefiero no admitirlos en .Net Core. Eche un vistazo a KnownCanonicalizationMethods y DefaultSafeTransformMethods en https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/System. las transformaciones que debemos apoyar.

No me había dado cuenta de que la fuente de los peligrosos se incluyó en el puerto. Votaría a favor de eliminarlos por completo. Realmente no hay una forma segura de usarlos.

@morganbr Gracias por el

@anthonylangsworth ¡ Suena genial!

@morganbr @AnthonyDGreen Esas transformaciones (que se deshabilitaron en el parche MS16-035) se han discutido anteriormente en este hilo cuando se habla del puerto. @bartonjs declaró el 14 de diciembre que las cosas de reg-compat deberían eliminarse. Vea también el comentario de @steveharter el 15 de diciembre de que esas transformaciones probablemente se puedan habilitar en un enlace tardío y, por lo tanto, deberían portarse.

@steveharter @bartonjs, ¿puedes participar?

Incluso sin soporte de registro, CryptoConfig puede crear esas transformaciones enlazadas tardíamente por nombre de cadena u oid. Busque 'CryptoConfig' en el código SignedXml, ya que se usa para crear la clase apropiada basada en el contenido xml.

Esto significa que la clase CryptoConfig debe extenderse para admitir estas transformaciones, al menos para los mismos tipos en netfx de todos modos, e idealmente también hacer una referencia cruzada con las de Mono. Eso es a menos que haya una razón (que no conozco) para no incluirlos y no conectarlos a CryptoConfig ..

FWIW aquí está la versión netfx de CryptoConfig (para comparar con lo que hay en corefx): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs , 20d26e036bc718bc

Hay una lista de "transformaciones permitidas" que es (en .NET Framework) extensible en el registro para compatibilidad con versiones anteriores. Para .NET Core no es extensible, pero está codificado para incluir solo las transformaciones sin entrada.

Dado que no puede validar un documento utilizando transformaciones que no están en la lista de permitidos, tal vez no tenga sentido portarlas. Pero dado que alguien podría estar usando las transformaciones fuera del contexto de SIgnedXml (solo queriendo usarlas como un motor de transformación de propósito general), tal vez esté bien tenerlas.

Dado que estaríamos hablando de eliminar un tipo completo, no crearía una inconsistencia con .NET Framework ... por lo que probablemente abogaría por eliminar cualquier transformación que no esté ya en la lista de permitidos codificada. "Eliminar antes de publicar el paquete" se puede cambiar más tarde. "Publicarlos" no puede.

@bartonjs se me adelantó. CryptoConfig contiene una lista de transformaciones permitidas. Tuve que modificar esa clase para permitir las transformaciones en el nuevo espacio de nombres, System.Security.Cryptography.Xml . Si bien algunas de las transformaciones permitidas usan el nombre completo de una clase .Net, CryptoConfig todavía solo permite una lista fija.

Preferiría no portar transformaciones que tengan problemas de seguridad conocidos, pero la compatibilidad con versiones anteriores también es importante. ¿Deberíamos tomar esta decisión en nombre del desarrollador? ¿Modificamos CryptoConfig para permitir algún tipo de extensión para que un desarrollador pueda agregar nuevas transformaciones si así lo desea? ¿Cómo llegamos a una decisión al respecto?

CryptoConfig no es el factor limitante: https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/CryptographyX3 --Xml/Signed L787. (Sin embargo, si CryptoConfig todavía se usa como fábrica para la resolución, cualquier transformación debería estar en ambos lugares)

Los tipos que proporcionan algoritmos que no están en esa lista (que no son también canonicalizadores) efectivamente no tienen valor.

Permitir la extensión a la lista segura requeriría una nueva API, por lo que técnicamente está fuera del alcance de este esfuerzo.

Personalmente, dejaría de lado los tipos de transformación que no se pueden usar en la verificación de documentos. Van a ser difíciles de probar.

En realidad, tanto CryptoConfig como DefaultSafeTransformMethods son relevantes. SignatureDescription creación de CryptoConfig por lo que, independientemente de los valores en DefaultSafeTransformMethods , no puede usar una transformación si no se menciona en CryptoConfig . DefaultSafeTransformMethods restringe esa lista, por lo que, si se especifica una transformación en XML pero no la devuelve DefaultSafeTransformMethods , SignedXml.CheckSignature devuelve falso.

En la implementación actual. CryptoConfig.AddAlgorithm arroja un PlatformNotSupportedException , por lo que los usuarios no pueden agregar el suyo. Más allá del alcance de este esfuerzo de portabilidad, pero puede valer la pena mirar esto o incluso agregar RemoveAlgorithm en el futuro.

Después de mi comentario anterior, encontré la propiedad SignedXml.SignatureFormatValidator . Esto permite al usuario especificar qué transformaciones y algoritmos hash son apropiados. La persona que llama puede usar esto para anular DefaultSafeTransformMethods , por ejemplo.

Como pregunté antes, ¿quién toma la decisión aquí? Como "tipo de seguridad", mi preferencia sería excluir las opciones inseguras. Sin embargo, no entiendo completamente el alcance de las incompatibilidades que esto podría ocasionar.

@anthonylangsworth esta discusión es parte de la toma de decisiones. Los expertos del área con más experiencia tomarán la decisión aquí.

Mi recomendación: si es cuestionable cuál es la acción correcta, sugeriría mantener el statu quo: dejar el código como está durante el ejercicio del puerto (potencialmente incluso sin cobertura de prueba) y decidir más tarde, por separado del ejercicio del puerto.

De acuerdo, charlé con algunas personas internamente y creo que tengo el andamio de un plan:

• Deje los tipos como públicos. (Son del tipo público, y quitar cosas entristece a la gente).
• Estos no se pueden (todavía) usar en pruebas SignedXml de un extremo a otro. (De hecho, las pruebas negativas parecen buenas)
• Tienen miembros públicos que deberían ser suficientes para las pruebas unitarias, así que deberíamos hacerlo.
  
  
  
  • Y eso también se aplica al resto de los tipos de transformación.
  
  
• Si, por alguna razón, las transformaciones de aceptación de entrada no funcionan y todo lo demás está bien, podemos averiguar qué hacer al respecto. (Esto también se habría aplicado a "si tuvieran dependencias de compilación complejas que no se pueden cumplir", pero ya hemos superado ese obstáculo).

Y si / cuando aparece la API u otra configuración para permitir que estos tipos funcionen, agregar las pruebas E2E elegidas será fácil.

@tintoy @anthonylangsworth @peterwurzinger ¿cuál es el estado de su rama de prueba? ¿Podemos empezar a fusionarlo? Puedo seleccionar tus pruebas y seguir adelante desde allí.

¿Podría también PTAL en https://github.com/dotnet/corefx/pull/16545 ? He habilitado una de las muestras de MSDN

Hola @krwq : creo que todavía hay algunas pruebas que fallan, pero como no se ejecutan como parte del proceso de compilación regular, es posible que pueda incluirlas de todos modos.

Déjame charlar con @anthonylangsworth y me contacto contigo.

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

@krwq : tuve una conversación rápida con @anthonylangsworth. Mencionó (y estoy de acuerdo) que dada la cantidad de trabajo que se ha realizado allí, quizás sería bueno fusionar lo que tenemos antes de seguir adelante. Se construye y la mayoría de las pruebas pasan, pero algunas no.

Sospecho que necesitaremos rebase contra dotnet / corefx # 16545 (lo que haré) antes de abrir un PR (lo que hará @anthonylangsworth ).

Nos comunicaremos con usted tan pronto como estemos listos para esto (con suerte, no mucho).

@krwq Para ampliar lo que dijo @tintoy , si bien todavía queda trabajo por hacer, también se ha realizado mucho trabajo para adaptar las pruebas existentes y expandirlas. En particular, ya he cambiado CryptoConfig.cs para manejar muchos de los algoritmos que mencionas. Todos queremos hacer avanzar esto. Tampoco queremos duplicar o sobrescribir el trabajo de los demás. Por lo tanto, planeamos fusionar los cambios tal cual para que otros puedan construir sobre el trabajo que hemos hecho, encontrar todos nuestros errores y, con suerte, tener todo en master antes.

@tintoy ¿ es https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests la única rama en la que está trabajando?

Sí.

@krwq Bueno, hay un PR con una buena cantidad de cosas de Mono en (que también es una sub-rama de https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests ... ). Si está interesado en un código actualizado, probablemente debería echarle un vistazo. Por lo que puedo decir, hay ~ 40/340 pruebas que fallan.

Buen partido, @peterwurzinger , ¡pensé que ya lo habíamos fusionado!

@peterwurzinger @anthonylangsworth ¡ este PR es bastante bueno! De hecho, me lo he perdido. ¿Lo fusionarás con tu rama, con corefx o quieres que lo recoja y haga todas las fusiones / rebases? ¿Falta algo de las pruebas Mono o es completo? @anthonylangsworth - para los cambios de CryptoConfig - hablé de eso con @bartonjs - no deberíamos tocar ese archivo - ya es bastante feo.

Mi plan original era obtener algunas muestras de MSDN y hacer que todas funcionen para que podamos comenzar con la prueba interna temprana. Después de eso, fusionaré y corregiré las pruebas de su rama. Si algunas pruebas fallan, simplemente podemos desactivarlas por ahora y corregirlas más tarde. Combinemos sus cosas en corefx / master lo antes posible: smile:

Gracias por la actualización, @krwq . Si puede, manténganos actualizados. Ayuda saber a qué apuntamos.

Hola = D

¿Hay pruebas fallidas?

@ Jaedson33 @anthonylangsworth @tintoy
Aquí está la lista actual de los problemas más importantes (arbitrariamente):
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@ Jaedson33 sí, actualmente están deshabilitados. Lo anterior debería darte una idea aproximada de dónde estamos

Hola, ¿tienes alguna idea de cuándo será sin ningún error?

@ Jaedson33 cada pieza de software tiene errores: wink: ¿Hay alguna cosa en particular que no funcione para usted?

Es simple: simplemente no funciona en mi proyecto de UWP 😞

Hola, recibo este error cuando intento ejecutar build.cml. ¿Me puedes ayudar?

Error en el comando:
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
La ejecución del comando falló con el código de salida 1.
¡No se pudo generar el proyecto de compilación de componentes nativos!
La ejecución del comando falló con el código de salida 1.

@JaedsonBarbosa ¿Está ejecutando pruebas desde el símbolo del sistema del desarrollador? (por cierto, esto es un poco extra) para la UWP: investigaré si esto se puede hacer bastante barato para 2.0, aunque no hay promesas

Lo estoy haciendo desde el símbolo del sistema para desarrolladores de Visual Studio 2017

@JaedsonBarbosa, ¿ha extraído los últimos cambios de github y ha intentado compilar después de limpiar su repositorio ( git clean -fdx )? Lo segundo que debe intentar es reducir la longitud de la ruta (es decir, coloque su repositorio en C: \ corefx). Otra cosa que puede intentar es limpiar la caché de nuget ( %USERPROFILE%\AppData\Local\NuGet y %USERPROFILE%\.nuget )

Si sigue sucediendo, cree un problema por separado con la información:

• tu sistema operativo
• tu versión VS
• pasos exactos que hiciste
• registro completo (si es grande, póngalo en la esencia)

Creo que ocurre porque creo que la ruta C: / corefx / src / Native /../../ bin / obj / Windows_NT.x64.Debug / native \ install.vcxproj no es válida.

SO: Windows 10
VS: 2017 Comunidad
Acabo de iniciar el símbolo del sistema del desarrollador para VS 2017 y pongo:

cd C:/corefx
build

Ahora el error es:

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" = "El sistema no pudo encontrar el archivo especificado"

Me rindo, no puedo hacer que funcione con el 2017 VS.
Entonces, ¿tiene alguna idea de cuándo se puede descargar esto como un paquete NuGet?

Debería poder consumir la vista previa de myget.org.
El paquete oficial será parte de la ola de .NET Core 2.0: consulte la descripción del hito 2.0.0 , el 10 de mayo es el ZBB (# 17619), por lo que la versión RTW debería seguir "poco" después (las fechas exactas aún no se han divulgado públicamente)

@karelz ¿Puede enviarme el enlace del paquete que contiene System.Security.Cryptography.Xml?

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

Aquí se explica cómo hacer la prueba interna 2.0: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

@karelz OK, quiero instalar eso en una biblioteca de clases de UWP, pero cuando lo intento,

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 no es compatible con uap10.0 (UAP, Versión = v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 dá soporte a:

• monoandroid10 (MonoAndroid, Versión = v1.0)
• monotouch10 (MonoTouch, Versión = v1.0)
• netcoreapp2.0 (.NETCoreApp, Versión = v2.0)
• uap10.1 (UAP, Versión = v10.1)
• xamarinios10 (Xamarin.iOS, versión = v1.0)
• xamarinmac20 (Xamarin.Mac, versión = v2.0)
• xamarintvos10 (Xamarin.TVOS, versión = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS, Versión = v1.0)

Es mi project.json real:

{
  "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 , actualmente no https://github.com/dotnet/corefx/pull/17969 se fusione y se produzca un nuevo paquete.

😧 Ok, seguiré esperando 😭
@krwq Pero ... ¿Qué es UAP10.1 ???

@krwq ¿Por qué no fusiona el PR dotnet / corefx # 17969 ahora?

@JaedsonBarbosa Se acaba de fusionar, creo que el paquete debería estar allí mañana por la mañana; por lo general, no nos fusionamos a menos que el PR sea verde en el CI; tenemos algunos problemas de CI de OSX desde ayer, por lo que se volvió un poco obsoleto

@krwq ¿Puede informarme cuándo se puede descargar el paquete NuGet con los cambios?

Se advierte a compatibilidad con .NET Standard 2.0 en UWP es de vanguardia; no será parte de .NET Core 2.0; será parte de la próxima versión, temporalmente nombrada como 2.1. Estamos trabajando en algunas de las cosas 2.1 con anticipación y en paralelo con 2.0, para hacer frente a la infraestructura, etc., para que luego podamos paralelizar en gran medida (después del 10 de mayo, que es nuestro ZBB para 2.0).
De cualquier manera, puede encontrar algunos problemas al usar la biblioteca en UWP. Es posible que no estemos en posición de ayudarlo de inmediato. Deberíamos poder ayudar más después del 10 de mayo ... simplemente estableciendo las expectativas.

@JaedsonBarbosa parece que no
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
cada vez que aparece un paquete después del 4/6, debería tener el cambio que necesita. Verificaré hoy por qué no había ningún paquete: podría estar relacionado con problemas de red que tenemos con las compilaciones de OSX.

EDITAR: confirmando: esto está relacionado con problemas de red de OSX

@krwq ¿

Está bloqueando casi todas nuestras relaciones públicas, por lo que es una alta prioridad, pero no tenemos una hora estimada de llegada.

OK 👍
Así que seguiré esperando.

¿Cuándo estará lista la parte 4?

@JaedsonBarbosa tenemos las partes más importantes ya probadas y probadas en funcionamiento. Con las pruebas no hay un único punto "terminado": puede tener una cobertura de código del 100% y un código que no funciona. ¿Hay algún escenario en particular que le interese?

No 😃

@krwq Espero que declaremos las cosas hechas para la biblioteca, cuando nos

@karelz Actualmente me siento cómodo con el envío tal como estoy, ya que todos los escenarios E2E importantes que se me ocurren están probados. Todavía me gustaría aumentar la cobertura para que se pueda probar que los escenarios menos populares (incluido el manejo de errores) también funcionan correctamente, aunque no espero encontrar ningún problema de bloqueo 2.0.

Para mí, "hecho" significa que ya nadie mantendrá ni mejorará la biblioteca

De acuerdo, si @bartonjs está de acuerdo con el estado listo para enviar, seamos prácticos y cerremos este problema.
Si queremos aumentar la cobertura de la prueba (como 2.0 sin bloqueo), deberíamos crear un elemento de trabajo separado para Future.

Si hemos sacado todo lo que está en la lista de algoritmos, transformaciones y canonicalizadores, me parece bien.

Así que creo que este tema finalmente se cerrará.

Ok, hagamos un seguimiento del progreso de la cobertura con: https://github.com/dotnet/corefx/issues/16829 - Pensé que tratamos esto como un problema principal

Sí, lo tratamos como un problema principal, pero a veces tienes que declarar que las cosas están hechas, de lo contrario, tendrías un problema abierto por cada función más grande de seguimiento "hacer más", lo que realmente no ayuda a nadie.

Ahora está cerrado 😢
Entonces ... ¿Dónde debo hacer preguntas sobre System.Security.Cryptography.Xml?

¿No es suficiente la respuesta de @krwq arriba?
Si tiene preguntas más importantes, presente un nuevo número. Si es una pequeña aclaración de la respuesta anterior, puede guardarla aquí. Si no está seguro, pregunte aquí y en el peor de los casos le pediremos que presente un nuevo problema ;-)

@krwq Continúa sin soporte para UWP 😞

@JaedsonBarbosa, ¿ https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 no funciona para usted? ¿Podrías enviar los pasos de lo que estás haciendo?

@krwq acabo de poner ese comando:
Paquete de instalación System.Security.Cryptography.Xml -Version 4.4.0-preview1-25210-01

Ese es el error:

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 no es compatible con uap10.0 (UAP, Versión = v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 dá soporte a:

• monoandroid10 (MonoAndroid, Versión = v1.0)
• monotouch10 (MonoTouch, Versión = v1.0)
• netcoreapp2.0 (.NETCoreApp, Versión = v2.0)
• uap10.1 (UAP, Versión = v10.1)
• xamarinios10 (Xamarin.iOS, versión = v1.0)
• xamarinmac20 (Xamarin.Mac, versión = v2.0)
• xamarintvos10 (Xamarin.TVOS, versión = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS, Versión = v1.0)

@krwq Ver eso: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01#targetframeworks

Solo un recordatorio de lo que dije antes: https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
No creo que obtenga soporte para UWP con el paquete. El paquete depende de .NET Standard 2.0 AFAIK y UWP aún no tiene soporte para .NET Standard 2.0; es algo en lo que trabajaremos para .NET Core 2.1 (algunos bits se realizan antes para desbloquear un equipo más grande para trabajar en él post 5 / 10, pero no es completamente funcional).
En mi opinión, para obtener soporte de UWP para el paquete, tendrá que esperar en 2.1.

@karelz Entonces, ¿crees que tendré que esperar hasta cuándo?
¿Puedo crear un proyecto uap10.1?

Sí, creo que tendrás que esperar hasta entonces.
A menos que esté súper motivado y pueda superar todos estos obstáculos. Como dije, hasta el 5/10, nuestra capacidad para ayudarlo con cualquier cosa de UWP será muy limitada , por lo que estará mayormente solo 😦. Solo estableciendo las expectativas aquí ...

Así que esperaré porque no puedo compilar corefx-master con Visual Studio 2017 😞

@karelz @krwq No puedo construir la solución porque doy un error, puedes ver el CMakeError aquí:
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
Por favor, dame una ayuda 🆘
PD: Está en portugués, pero puedes usar un traductor para leer eso 😄

Creo que fallar no es bueno:
- La identificación del compilador de C es MSVC 19.0.24218.2
- La identificación del compilador CXX es MSVC 19.0.24218.2
- Compruebe si el compilador de C funciona: C: / Archivos de programa (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
- Verifique que el compilador de C funcione: C: / Archivos de programa (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe - funciona
- Detectando información ABI del compilador C
- Detectando información ABI del compilador C - hecho
- Compruebe si el compilador CXX funciona: C: / Archivos de programa (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
- Compruebe si el compilador CXX funciona: C: / Archivos de programa (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe - funciona
- Detectando información ABI del compilador CXX
- Detectando información ABI del compilador CXX - hecho
- Detección de funciones de compilación de CXX
- Detectando funciones de compilación de CXX - hecho
- Realización de la prueba COMPILER_HAS_DEPRECATED_ATTR
- Realización de la prueba COMPILER_HAS_DEPRECATED_ATTR - Falló
- Realización de prueba COMPILER_HAS_DEPRECATED
- Realizando prueba COMPILER_HAS_DEPRECATED - Correcto
- Configuración hecha
- Generando hecho

Alguien ahora, ¿qué puedo hacer para que se construya?

@JaedsonBarbosa ¿cómo se construye? El proceso regular para mí es:

1. Abra cmd.exe
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx : esto limpiará su repositorio de los archivos sobrantes (tenga cuidado si no está seguro de lo que hace)
5. build o ./build.sh si no usa Windows

Para crear componentes nativos, debe instalar CMake 2.8.12 o superior

Esto siempre me ha funcionado.

@ Jaedson33 también puede consultar y ayudarnos a mejorar nuestros documentos para nuevos colaboradores (enlazados desde la página principal de CoreFX)

Estoy usando CMake 3.8.
@krwq Hice lo que dijiste, y estoy esperando aproximadamente 1 hora y solo está Instalando dotnet cli ..., ¿cuántas horas crees que tendré que esperar?

@JaedsonBarbosa , debería tomar unos minutos, intente reiniciar; podría haber algunos problemas de conexión, si no funciona, presente un problema por separado en este repositorio, alguien debería poder rastrear lo que sucedió

@krwq me sale este error:

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 , presente un nuevo problema como se sugirió anteriormente. Solo un recordatorio de que es posible que no podamos brindarle tanto soporte para la resolución de problemas antes del 5/10 como nos gustaría.

@karelz Ahora está funcionando 😄
Lo único que hice para construirlo fue mover los archivos de C: \ Users \ jaeds \ Source \ Repos \ corefx-master a C: \ Users \ jaeds \ Source.
Creo que debería estar en el archivo README.

Hola, ahora puedes usar este paquete en una aplicación para UWP, aquí una aplicación de muestra: https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

@JaedsonBarbosa ¡genial! ¿Hay algo de su trabajo que sea valioso para regresar a CoreFX? (es decir, cosas que no son hacks temporales)

@karelz Bueno, creo que puedes usar mi proyecto para ver qué puedes simplificar (o eliminar) en CoreFX 😄

Hola a todos, ¡gran esfuerzo para portar esto!

¿Puedo preguntar por qué el paquete Nuget hace referencia a .NET Core 2.0, en lugar de .NET Standard 2.0? ¿No sería eso lo preferido?

Eso debería haberse hecho (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

Supongo que estás viendo la vista previa oficial en Nuget.
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

y solo llega a Myget
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

Sí, eso es lo que estaba buscando. ¡Gracias, @danmosemsft!

@leopignataro no hay problema, te animo a que pruebes bits de "head" - puedes conseguirlos desde la página de inicio aquí https://github.com/dotnet/cli ... puedes descargar el zip si quieres. Háganos saber si encuentra problemas; solo nos queda un poco de tiempo para solucionarlos antes del lanzamiento.

FYI: Aquí hay información sobre las líneas de tiempo: https://github.com/dotnet/corefx/issues/17619#issuecomment -301937346

Como lo mencionas, @danmosemsft , hay un problema:

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

He sugerido una solución en el hilo, pero es posible que mi mensaje se haya perdido en todos los rumores.

@leopignataro arreglar para que donde? Si se corrige para dotnet / corefx # 19198, entonces debería ser rastreado en el error. Si se trata de otra cosa, preferiría ver un tema aparte.
Si cree que su sugerencia de corrección se pasó por alto en algún lugar, vuelva a plantearla en ese hilo y solicite comentarios.

Estoy confundido ahora. Pensé que el paquete System.Security.Cryptography.Xml NuGet es para .NET Framework y ya está incluido en Dot Net Core v2. No reconoce este espacio de nombres en Dot Net Core v2. ¿Escuché esto incorrectamente? Gracias.

@ fletchsod-developer El paquete es principalmente para .NET Core. Pero si lo hace referencia desde una biblioteca dirigida a .NET Standard, se unificará con la versión de .NET Framework en .NET Framework y ejecutará el código desde el paquete en .NET Core.

No tenemos planes de poner SignedXml en la experiencia de instalación predeterminada para .NET Core; es lo suficientemente nicho como para que ser un paquete separado en NuGet parezca el mejor modelo de distribución.