Runtime: Adicionar classe System.Security.Cryptography.Xml.SignedXml

Conforme referido por Tratcher, este é um bloqueador para adicionar suporte para WsFederation / ADFS no ASP.NET 5. Usamos ADFS extensivamente para muitos aplicativos ASP.NET 4 empresariais. Estamos muito interessados ​​em migrar para ASP.NET 5 e usar WsFederation.

@rschiefer @Tratcher Bem, é ... complicado.

• O ADFS não usa System.Security.Cryptography.Xml.SignedXml; mas em vez disso, sua própria implementação.
  
  
  
  • (Isso é principalmente por tirar a poeira das teias de aranha mentais e lembrar de estar naquela equipe para a versão 1 do ADFS)
  
  
• System.IdentityModel definitivamente não usa System.Security.Cryptography.Xml
  
  
  
  • (Isso é porque o código-fonte deles na fonte de referência diz: sorria :)
  
  
• As pessoas realmente não gostam de System.Security.Cryptography.Xml.SignedXml porque é baseado em XmlDocument, o que leva a alguns problemas de desempenho.
  
  
  
  • A versão ADFS foi baseada em XmlReader, IIRC.
  
  
• Portanto, provavelmente o que as pessoas querem é que o CoreFX crie uma nova implementação do SignedXml.
• Mas uma nova versão do SignedXml não é compatível com a versão antiga do SignedXml
• Portanto, algumas pessoas podem querer que mantenhamos a versão antiga também.
• Portanto, ao todo, as pessoas realmente querem duas versões.
• Exceto que eles não querem a versão antiga.
• Exceto quando eles fazem.

Então, ficamos com o enigma de:

• Podemos portar aquela classe que ninguém realmente quer
• Ou podemos parar e projetar algo totalmente novo que provavelmente ninguém usará, já que não pode ser compatível com mais nada
• Ou, para se esforçar ao máximo e ainda não beneficiar ninguém, faça as duas coisas: sorria :

@terrajobst - fyi

Aparentemente, eu estava um pouco desconexo esta manhã. Desculpa :).

Definitivamente identificamos que há trabalho a ser feito aqui, mas não achamos que a resposta certa seja apresentar o código System.Security.Cryptography.Xml existente. Em vez disso, isso representa o item em nosso backlog para projetar uma implementação de propósito geral para XmlDSig que seja rápida e não vinculada a modelos de objeto legados (por exemplo, XmlDocument).

Esse esforço não é algo que esperamos fazer para o .NET Core 1.0, simplesmente porque estamos focados em outras coisas.

No entanto, informar-nos que você está sendo afetado pela funcionalidade ausente ajuda na priorização contínua.

Estou pensando em criar um Middleware SAML2 do ASP.NET Core, com base em https://github.com/KentorIT/authservices. Sem uma porta SignedXml, ele não poderá ser executado no framework Core.

Definitivamente, concordo que não continuar com o existente é uma boa ideia. Seria possível fazer qualquer coisa com base em uma API XmlReader? Dessa forma, tanto XDocument quanto XmlDocument podem ser suportados. Fornecer também uma implementação do leitor envelopado usado em System.IdentityModel seria bom (se fosse melhorado para suportar arquivos XML com espaços em branco ...)

@AndersAbel XmlReader é onde eu começaria, sim (a menos que os caras do XML me digam que há algo melhor).

Uma vez que XmlReader em que a variante System.IdentityModel é baseada, deve ser factível :).

@bartonjs A variante System.IdentityModel é bastante limitada em quais transformações ela pode manipular. Para o trabalho do SAML2 / WS-Fed, não seria um problema, mas como uma API geral, deve-se considerar como lidar com assinaturas não envelopadas e xml contendo assinaturas aninhadas (como uma resposta saml assinada contendo asserções assinadas). Também acho que o System.IdentityModel.EnvelopedSignatureReader está copiando os dados ao fazer a validação. Há muita diversão para fazer lá. Se eu tivesse tempo, adoraria trabalhar nisso.

Agradeço a tagarelice @bartonjs , que ajuda a ver o que está acontecendo nos bastidores.

Atualmente minha empresa é impactada por isso. Temos um código legado que estamos tentando transferir para o .NET Core que gera arquivos de licença XML assinados e, sem esse conjunto de classes, ficamos presos. Estamos abertos a divergir dos arquivos XML como base para as licenças, mas até o momento não encontramos uma boa solução que se adapte às nossas necessidades.

Ansioso para ver isso adicionado no futuro.

Posso atestar que isso (e também a criptografia XML ligeiramente relacionada) é relevante para nós. O formulário existente no .NET Framework seria ótimo - não há necessidade de inovação aqui, da minha perspectiva. A implementação de copiar e colar seria muito bem-vinda!

Existe atualmente alguma solução alternativa disponível?

Gostaria de saber o que @sandersaares perguntou também. Não há uma maneira integrada de assinar xml no CoreFX agora?

@sandersaares / @ af0l : Não há, para .NET Core 1.0, qualquer implementação embutida de SignedXml / XmlDSig.

Com base nos comentários aqui (e em outros), provavelmente vamos apenas trazer a API antiga, mas não tivemos tempo de fazer isso acontecer no 1.0.

Obrigado @bartonjs , deve ser esse o motivo pelo qual não consegui fazer nosso projeto funcionar no Core. :) Também é uma grande pena, porque adoraria seguir em frente e não posso até que esteja feito. Temos que relatar todos os pagamentos à nossa autoridade fiscal usando xmls assinados, então é realmente um empecilho.

Algum progresso nisso? Estou preso na validação do token SAML que requer esse recurso. Obrigado

Sim, mentiria saber disso também. Acabamos extraindo os recursos que precisavam da assinatura e os colocamos em uma solução separada de API da web ...

Já tem ideia de qual versão ou solução será implementada

Neste ponto, parece que a resposta mais direta é portar a implementação existente do .NET Framework para o .NET Core. Portanto, estamos combinando isso com outras omissões de API que "dificultam a portabilidade".

Potencialmente relevante para o tópico: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently e https://github.com/sandersaares/ defeito de espaço em branco xml-c14n. Parece-me que a implementação do .NET Framework do Canonical XML 1.0 está incorreta. Espero estar errado, mas se estiver, isso pode introduzir algumas questões de compatibilidade cabeludas.

@sandersaares Olhou sua amostra e você precisa definir XmlDocument.PreserveWhiteSpace = true ao ler o Xml se ele contiver espaços em branco.

@AndersAbel Obrigado pela dica! Isso muda a situação e realmente permite a validação de conformidade se um esquema XML estiver presente. Sem um esquema XML, o comportamento permanece inválido (de uma maneira nova e empolgante). Eu atualizei o problema do Connect e o repositório GitHub de acordo.

@bartonjs Se você transferir a solução .NET Framework existente, corrija o bug que impede a verificação de assinaturas múltiplas: https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

Para sua informação, se isso chegar ao estágio de implementação, então eu tenho uma biblioteca recém-criada aqui, com testes, que faz uso de assinaturas XML (tanto assinar e verificar) e outras funcionalidades XML no .NET Framework - pode ser útil para obter algum real livre de dependência -código mundial para testar a implementação: https://github.com/Axinom/cpix

Existe um cronograma para o desenvolvimento desta API?

// cc @bartonjs

@henkmollema Nada específico, não. Para a versão 1.2, estamos trabalhando para diminuir a lacuna entre o .NET Framework e o .NET Core; e esse esforço é atualmente de onde vem o SignedXml.

Eu estava em uma chamada de cliente hoje que precisa de suporte SAML2-P no ASP.NET Core (que usaria a implementação do KentorIT). Este é um problema de bloqueio para clientes que desejam migrar para o ASP.NET Core. Por enquanto, meu cliente terá que ficar no Katana.

Vejo que o marco foi alterado de 1.2 para Futuro (por @bartonjs). Você pode comentar ou elaborar?

Principalmente tem a ver com a forma como estamos rastreando marcos. Costumávamos fazer mais do tipo "esperamos que aconteça esse", então, no final da etapa, reatribuímos tudo o que não foi feito. Agora estamos realmente tentando dizer "se o marcamos para este marco, deve ser muito raro ele ser reatribuído".

Este é o resultado de muitos outros trabalhos para o marco 1.2, e foi (para mim, de qualquer maneira) sempre um pouco forçado chegar ao 1.2. Ainda está bem no topo da nossa lista de "o que vem a seguir", apenas não estamos 'nos comprometendo' a fazer parte do lançamento 1.2 (que é principalmente trabalho do netstandard2.0, correção de bugs e alguns projetos de infraestrutura).

Marcá-lo como Futuro não garante que ele não fará parte da versão 1.2, apenas significa (usando nossa interpretação atual do marco) que não teremos o lançamento para ele. Uma vez que alguém está realmente trabalhando nisso, há um melhor entendimento de quando realmente será feito e então será marcado como qualquer marco que realmente será lançado.

@karelz Se houver algo que você deseja adicionar (ou corrigir), sinta-se à vontade para intervir.

Não seremos capazes de financiar o trabalho no prazo 1.2 (há muitas outras coisas com maior impacto para terminar). é por isso que mudamos para o marco Futuro, para comunicar nossos planos.
Estamos cientes da quantidade de pedidos, por isso é alto em nossa carteira de pedidos da área de Segurança. É também uma das APIs ausentes do corefx mais solicitadas em geral (entre DirectoryServices, SerialPort, etc.).

cc: @steveharter @danmosemsft @terrajobst

Nossas respostas cruzaram :)
Mais contexto sobre Milestones está em nosso guia de edição .

O código .NET Framework está disponível como fonte de referência . Então, tecnicamente falando, a porta pode ser iniciada mesmo fora da equipe do .NET Core - se alguém estiver interessado em nos ajudar aqui.
De meus bate-papos anteriores com @bartonjs , acho que o principal "desafio" será criar / portar testes.

Ei, qual é a situação real sobre esse problema?

@ Jaedson33 o que você quer dizer com 'problema'? Se você quer dizer quando será consertado - veja as respostas da semana passada.

@karelz Mas eu não quero esperar. Por que você não conserta agora?

@ Jaedson33 veja minha resposta acima - isso explica porque não podemos financiá-lo agora. É uma questão de prioridades. Existe uma fila de pessoas que querem muitos recursos / APIs agora, mas não temos uma equipe de tamanho infinito, então temos que priorizar.

Se você realmente precisar disso o mais rápido possível, você sempre pode contribuir com a base de código, ficaremos felizes em ajudar com orientações, revisões de código e feedback.

Ok, então vou esperar.

@karelz se os testes originais ainda estiverem disponíveis para verificar o trabalho, estou disposto a levantar a mão :)

(um dos meus colegas de trabalho também tem experiência relevante, então provavelmente estaríamos trabalhando nisso juntos)

Parte fundamental do trabalho é realmente criar novos ativos de teste. Os testes antigos são insuficientes e têm cobertura ruim. Precisaremos de alguém para revisar as especificações e adicionar teste para cada requisito interessante - é aí que está a maior parte do custo.

Se você ainda estiver interessado, podemos tentar incluir o código-fonte completo do .NET Framework no estado em que se encontra - a próxima etapa será construí-lo e adicionar cobertura de teste, antes que possa ser lançado como parte do .NET Core. Avise-me se estiver interessado ...

Ok, sim - ainda estamos interessados ​​:)

@tintoy Estou interessado em ajudá-lo porque realmente preciso dessa aula.

@tintoy Estou interessado em ajudá-lo porque realmente preciso dessa aula.

Fico feliz em ouvir isso :)

Então ... Como posso ajudar?
Obs: É a primeira vez que uso o GitHub.

Então ... Como posso ajudar?

Deixe-me primeiro conversar com meu colega de trabalho e vamos bolar um plano de ataque. @karelz - existem orientações ou outros documentos que devemos ler antes de entrar? Para começar, estou supondo que meu colega de trabalho provavelmente irá se aprofundar no padrão, provavelmente vou tentar descobrir onde o código precisa ir (e o que está envolvido em fazer com que os testes existentes de outras partes do framework sejam executados antes de fazermos quaisquer alterações). Isso parece razoável?

CC: @anthonylangsworth

Para manter o escopo um pouco limitado, recomendo começar sem os recursos desabilitados pelo MS16-035 (transformação xpath, transformação xslt, referências externas). Eu não sei que espaço há para alterações significativas, mas o mecanismo de fallback atual em DefaultGetIdElement pode ser explorado em ataques de quebra de assinatura. Eu prefiro uma versão padrão mais segura.

Também seria bom se a API interna fosse reestruturada um pouco para suportar o EnvelopedSignatureReader usado por System.IdentityModel em vez de ter duas implementações separadas de validação de assinatura XML.

Finalmente, também gostaria que um único ponto fosse adicionado de acordo com este relatório de bug .

@tintoy Não acho que temos bons documentos. Acho que devemos adicionar as fontes e então podemos paralelizar o trabalho - deixe-me sincronizar com @bartonjs @steveharter @ianhays.

Vou tentar encontrar algum tempo para ajudar também. Se houver alguma dúvida sobre as especificações e como funciona, ficarei feliz em verificar isso - já passei algum tempo revisando as especificações.

Alguém tem algo a dizer sobre a ideia de consolidar SignedXml e o EnvelopedSignatureReader usado por System.IdentityModel?

@AndersAbel

comece sem os recursos que são desabilitados pelo MS16-035 (transformação xpath, transformação xslt, referências externas)

Devemos começar com o código-fonte do .NET Framework mais recente, que deve ser seguro. Se você tiver alguma dúvida sobre a segurança do código do .NET Framework, informe-nos offline.

Eu não sei que espaço há para mudanças significativas

Não há espaço, devemos começar com uma porta direta do .NET Framework. Quaisquer outras melhorias, alterações, alterações importantes, etc. podem ser consideradas mais tarde. Não como parte do trabalho inicial. Caso contrário, crescerá sobre nossas cabeças.

O mecanismo de fallback atual em DefaultGetIdElement pode ser explorado em ataques de quebra de assinatura

Isso deve ser tratado como um problema separado. @bartonjs você pode comentar?

Também seria bom se a API interna fosse reestruturada um pouco para suportar o EnvelopedSignatureReader usado por System.IdentityModel em vez de ter duas implementações separadas de validação de assinatura XML.

Novamente, vamos dar o próximo passo, depois de termos uma porta totalmente funcional com boa cobertura de teste.

Finalmente, também gostaria que um único ponto fosse adicionado de acordo com este relatório de bug.

Arquive-o como um problema separado aqui, no GitHub. Idealmente, depois de portar o código aqui (ou seja, quando o bug é realmente aplicável ao .NET Core).

Alguém tem algo a dizer sobre a ideia de consolidar SignedXml e o EnvelopedSignatureReader usado por System.IdentityModel?

Só quero reiterar. Devemos tratá-lo como a próxima etapa, a portabilidade de postagem.

O mecanismo de fallback atual em DefaultGetIdElement pode ser explorado em ataques de quebra de assinatura

Isso deve ser tratado como um problema separado. @bartonjs você pode comentar?

@AndersAbel Se você acredita que há um problema de segurança, siga o processo de relatório de vulnerabilidade em https://technet.microsoft.com/en-us/security/ff852094.aspx.

Alguém tem algo a dizer sobre a ideia de consolidar SignedXml e o EnvelopedSignatureReader usado por System.IdentityModel ?.

Provavelmente não é possível. SignedXml é fortemente (e public-API-ally) baseado no rich-DOM XmlDocument. A representação do IdentityModel é baseada em XmlReader. Mas, uma vez que o material existente é trazido, ele pode ser investigado.

Vou tentar encontrar algum tempo para ajudar também. Se houver alguma dúvida sobre as especificações e como funciona, ficarei feliz em verificar isso - já passei algum tempo revisando as especificações.

@AndersAbel -

@bartonjs Relatei esses problemas para [email protected] , que resultou no MS16-035. IMO, existem alguns problemas de risco restantes, que a MS decidiu não corrigir (eles incorreriam em alterações significativas). Ainda não publiquei os detalhes, mas se você quiser discuti-los em particular, envie-me um e-mail.

@karelz Obrigado por esclarecer que não há espaço para alterações significativas. Isso significa que minhas ideias sobre consolidação não são relevantes.

comece sem os recursos que são desabilitados pelo MS16-035 (transformação xpath, transformação xslt, referências externas)

Devemos começar com o código-fonte do .NET Framework mais recente, que deve ser seguro. Se você tiver alguma dúvida sobre a segurança do código do .NET Framework, informe-nos offline.

O patch MS16-035 solucionou vários problemas no SignedXml. No entanto, é possível usar as chaves do registro para reverter para o comportamento antigo e inseguro. Essas opções também devem ser transferidas para o .NET Core? Minha sugestão acima tinha o objetivo de priorizar a portabilidade do comportamento padrão do .NET Framework atual, deixando para trás as partes que estão desativadas por padrão por enquanto. Ou você quer dizer que essas partes também são cruciais para serem movidas? Depois, há a questão de como lidar com a configuração, já que o .NET Core AFAIK não depende do registro para configuração (já que não está disponível em todas as plataformas).

No entanto, é possível usar as chaves do registro para reverter para o comportamento antigo e inseguro. Essas opções também devem ser transferidas para o .NET Core?

Não. O código apenas compatível com o registro será excluído antes que o pacote seja disponibilizado.

Por que você não cria um projeto no GitHub para implementar isso?

Nós sincronizamos com @bartonjs , @steveharter e @ianhays

EDITAR: O plano de execução foi movido para o primeiro posto.

Parece bom para mim :)

@karelz , @steveharter A maioria das pesquisas de registro está localizada na classe Utils : AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier . Também há uma pesquisa na classe SignedXml onde configura a lista de transformações conhecidas. Sem a compatibilidade do registro, não acho que XmlDsigXPathTransform e XmlDsigXsltTransform possam ser acessados. Eles devem ser removidos completamente da fonte junto com o código de compatibilidade do registro?

São aqueles que eu conheço, não vi nenhum outro durante a leitura do código, mas posso ter perdido algo.

@AndersAbel Eu atualizei o comentário do Karel acima sobre o registro. Se houver alguma classe que não esteja acessível, precisamos entender qual funcionalidade está sendo perdida. Para aqueles que você mencionou, acredito que CryptoConfig precisa adicionar o nome: par de

Quando você acha que essa aula estará pronta?

Você quer dizer contribuições? @steveharter planeja enviar o PR inicial de "adicionar fontes" muito em breve (provavelmente hoje).

O código inicial acaba de ser mesclado.

@steveharter Obrigado 😃

Obrigado @steveharter! Mudei o plano de execução para o posto mais acima para facilitar o rastreamento do progresso. Sempre que fizermos alterações, mencionaremos as alterações em outra resposta aqui.

Se alguém quiser começar a trabalhar nisso, diga-o para evitar trabalho duplicado. Iremos atribuir o problema a você.

@karelz : @tintoy e eu levantamos as mãos para começar. Fico feliz por você atribuí-lo a nós.

Se alguém quiser começar a trabalhar nisso, diga-o para evitar trabalho duplicado. Iremos atribuir o problema a você.

Saúde - estou feliz em começar a compilar :)

@anthonylangsworth - hah,

O trabalho está acontecendo aqui .

Atribuído a @tintoy. Irei atribuí-lo também a @anthonylangsworth assim que ele aceitar o status de contribuidor para o repo (o GH não oferecerá a você a opção de cessionário sem ele).

Obrigado!

@karelz apenas para confirmar - pelo que entendi das diretrizes do contribuidor, devo fazer essas alterações em master ?

(meu master obviamente)

Ergh, desculpe, deixe-me tentar novamente - o eventual PR será contra o seu master ?

Sim está certo. Apenas não o torne parte da execução completa de compilação / teste corefx até a última fase.

Encontrei algumas constantes que parecem ter sido movidas para uma classe interna em src / Common / src / Interop / Windows / Crypt32 / Interop.certificates_types.cs . No entanto, isso não está acessível a partir de System.Security.Cryptography.Xml . Alguma ideia da melhor abordagem aqui?

Quais deles são necessários? Todos eles?
Você pode verificar a fonte de referência se eles são públicos no .NET Fx? (Acho que não, mas não custa verificar)
Estou um pouco surpreso que fazemos interoperabilidade especial, em vez de aproveitar o resto da biblioteca Crypto ... ou precisa de algo especial ou é por razões históricas ... @steveharter @bartonjs alguma opinião?

@tintoy Uma das coisas que precisa ser feito neste esforço é remover a interface direta com CAPI, mudando para o uso de APIs .NET.

@karelz , @bartonjs - principalmente constantes CAPI HRESULT passadas para o construtor CryptographicException .

Por exemplo:

src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / KeyInfoX509Data.cs (linha 63)

Vou dar uma olhada em como outro código em corefx funciona com CryptographicException .

Ah, ok - então parece que o construtor HRESULT não é mais usado - apenas aquele que leva uma mensagem. Vou ver se existem recursos de mensagem que correspondem a esses E_xxx valores.

Quanto aos outros problemas, parece-me o resultado de tipos que não compartilham mais um único assembly. Por exemplo, X509Utils.DecodeHexString está em System.Security.Cryptography.X509Certificates mas no framework completo ele reside apenas no assembly System.Security junto com as classes que o utilizam.

Uma vez que tudo foi dividido em vários assemblies, qual é o seu mecanismo preferido para lidar com o que normalmente seriam componentes compartilhados? Eu poderia apenas fazer uma cópia das funções necessárias do código em outros assemblies, se você preferir.

Ou puxe a fonte usando algo como:

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

Por enquanto, resolvi o problema do CAPI simplesmente compilando `Interop.certificates_types.cs no assembly e referenciando constantes a partir daí.

Eu também tive que copiar alguns métodos de X509Utils.cs no framework completo (principalmente para fazer com codificação / decodificação hexadecimal), pois não há nada disponível publicamente no corefx que faça isso.

Os únicos problemas restantes estão em src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / SymmetricKeyWrap.cs (linha 34, entre outros) que resultam em erros como:

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

Por enquanto, suprimi o erro. Então agora tudo compila :)

Ok, bem, exceto para o projeto de teste:

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

Vou resolver isso amanhã.

@karelz @bartonjs Vou abrir um PR para que possamos discutir as mudanças (o trabalho está basicamente feito pelo que eu posso dizer) - você está bem com isso?

Parece bom para mim. @steveharter alguma opinião?

Feliz ano novo = D

Você tem alguma ideia de quando a fase 2 será concluída?

dotnet / corefx # 14662 já está mesclado - essa foi a fase 2. Vou marcá-lo no post superior como 'verificado'.

Só para deixar claro: depois que todas as 5 etapas acima forem concluídas, para obter suporte ws-fed no ASP.NET Core, a equipe AAD precisa fazer seus bits de token SAML e, em seguida, as equipes ASP.NET precisam construir o ws middleware alimentado na peça AAD. Isso corresponde às suas expectativas?

Não, este trabalho não tem nada a ver com WS-Fed.
Devo uma resposta e explicação em https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500

Para sua informação: Resposta postada: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

Então, quando a fase 4 será concluída?

Se você está perguntando quando a equipe .NET terá tempo para fazer isso, ainda não sabemos. É um grande problema em nossa carteira, mas há algumas prioridades mais importantes que temos que resolver primeiro.

Estamos abertos a contribuições no espaço da comunidade entretanto.

Estou feliz em continuar trabalhando nisso, mas estou meio preso no momento; desde que corefx mudou para o novo processo de compilação, System.Security.Cryptography.Xml não compila mais (então @anthonylangsworth e eu estamos impedidos de escrever qualquer teste). Se pudéssemos obter apenas uma indicação rápida do que está envolvido em fazer o projeto (e o projeto de teste) ser compilado, estaremos prontos para prosseguir :)

PS. Passei cerca de 20 minutos rastreando o processo de compilação para descobrir por que ele não compila mais, mas ainda não resolvi isso. Qualquer sugestão seria apreciada ...

@mellinoe @weshaggard você pode fornecer orientação para migrar SignedXml para o novo sistema de compilação?

😭😭 Acho que vou precisar esperar 😭😭

@tintoy se você me indicar o branch em que está trabalhando e em qual projeto está tentando construir, posso ajudar na construção.

@weshaggard atualmente não há um branch - o código está no master, ele apenas não está conectado à construção de root (propositalmente) - src / System.Security.Cryptography.Xml (introduzido em dotnet / corefx # 14628). @steveharter pode fornecer informações adicionais.

@weshaggard @karelz Estou feliz em criar um branch em nosso fork e só obtê-lo construindo lá para nos desbloquear; mais tarde, podemos sempre escolher as alterações que fizemos quando ele está sendo compilado novamente em master . Deixe-me saber se esta é sua abordagem preferida :)

PR https://github.com/dotnet/corefx/pull/15491 deve fazer com que a infraestrutura do projeto funcione. Assim que o CI for aprovado, podemos mesclá-lo e ele deve impulsionar seus esforços.

Obrigado - rebasei tintoy / corefx / master e vou brincar com ele em breve :)

@weshaggard ok, então ambos src e teste de construção de projeto, mas se eu adicionar uma referência de projeto do projeto de teste ao projeto de origem ( <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ), eu obtenho:

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

Acho que perdi algo sobre como as referências entre projetos devem funcionar no corefx.

@tintoy Não tenho certeza de qual é esse erro especificamente, mas geralmente não precisamos de ProjectReferences em nosso novo sistema de engenharia. Para a construção de teste, sempre construímos e referenciamos o pacote de direcionamento completo, neste caso produzido em bin\ref\netcoreapp . A biblioteca que é colocada nesse diretório é a que você constrói a partir da pasta ref, que está vazia no momento. Portanto, para começar, você precisa gerar uma referência com a área de superfície da API necessária e obter a construção de referência, então seu projeto de teste verá automaticamente as APIs e poderá construir com base nelas. Temos uma ferramenta chamada genapi que pode gerar a referência baseada em outra biblioteca. Deixe-me enviar outro RP rapidamente para semear isso para vocês.

Ok, agora entendi; a razão pela qual não vejo tipos no projeto de teste é porque o projeto ref ainda não tem tipos :-)

@weshaggard se você não tiver tempo, provavelmente posso descobrir como fazer isso; Eu estava lendo sobre essa ferramenta outro dia.

Eu rapidamente executei a ferramenta genapi e enviei esse commit https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e. Sinta-se à vontade para pegá-lo ou regenerá-lo você mesmo. Você precisará adicionar ProjectReference's a outros refs para obtê-lo para compilar.

Saúde - isso vai me poupar tempo, muito apreciado.

sucesso de @weshaggard ! Obrigado, espero que possamos começar a escrever esses testes agora :)

(tintoy @ dd834c63af4fe40faf84bc6a776b474ec9947eb1 , apenas ignore a duplicata)

Sim! Faça um teste de trabalho:

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

Obrigado pela ajuda, @weshaggard!

PS. Tive que substituir localmente (via .user file) o caminho do executável nas propriedades do projeto de teste (guia Debug). Era D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe mas só funcionou quando mudei para D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe .

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

Meu VS não reclama das barras. Os separadores de caminho geralmente são uma dor porque estamos tentando fazer as coisas funcionarem tanto no Windows quanto no Unix, então acabamos vendo um monte de barras misturadas no Windows, o que geralmente aceita mais do que o Unix.

Só por curiosidade, qual versão do VS você está usando? 2015 ou 2017? Talvez tenha sido corrigido em 2017 :)

(Normalmente estou no OSX ou Linux atualmente, então agradeço totalmente o esforço para tornar as coisas compatíveis com várias plataformas, BTW)

Estou usando o VS 2015 no Windows 10 e abri a solução e poderia F5 para depurar os testes e meu caminho de depuração é D:\git\corefx\Tools/testdotnetcli\dotnet.exe

Ok, devo estar enlouquecendo - agora também não consigo reproduzir!

Antes, ele reclamava de não conseguir encontrar dotnet.exe , mas começou a funcionar quando eu defini explicitamente o executável para um caminho apenas com barras invertidas. Acabei de remover o arquivo .csproj.user e ele _ainda_ funciona, então quem sabe: -o

Olá pessoal, adoraria ajudar a escrever testes. O que posso fazer para começar a contribuir?

Ótimo - acho que podemos estar no estágio agora em que podemos começar a fazer isso :)

Deixe-me verificar com um colega de trabalho se ele fez seu primeiro teste com sucesso ...

cc: @anthonylangsworth

@karelz ,

@anthonylangsworth e eu começamos a escrever testes ; Estou ciente de que não chegamos a um acordo sobre o que precisa ser testado, mas vamos dar o pontapé inicial de qualquer maneira e, em seguida, transferir os testes para onde concordarmos em fazer o trabalho.

E para aqueles que se ofereceram para ajudar com os testes (o que é muito apreciado), devemos estar em posição de dividir o trabalho sugerido no início da próxima semana :)

Com relação à cobertura de teste e quais testes precisamos - @bartonjs tem uma opinião forte sobre isso (já que ele tem mais experiência com o tipo e seus problemas do nosso lado). Ele sugeriu escrever testes de acordo com as especificações (eu mencionei isso acima ).
Ele estará de volta das férias no final da próxima semana. Provavelmente deveríamos discutir detalhes e expectativas com ele.
Também @AndersAbel mencionou experiência em especificações e ajuda potencial no início da discussão .

cc @steveharter se ele tiver orientação adicional enquanto @bartonjs estiver

Obrigado @tintoy @anthonylangsworth por suas contribuições aqui! Nós realmente apreciamos isso!
E também obrigado a todos os outros que planejam entrar ;-)

cc @ steveharter se ele tiver orientação adicional enquanto @ bartonjs estiver

Minha curiosidade chegou a um ponto que exigia ser satisfeita.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
Eu me sinto melhor agora.

😃 Eu nem sabia que era tão específico da Microsoft! Obrigado pela sua iluminação engraçada 😃

@anthonylangsworth começou a esboçar um plano de teste preliminar em tintoy / corefx # 3 (copiei seu plano em uma edição para torná-lo fácil de comentar), então pelo menos temos algo para discutir. Sinta-se à vontade para dar uma olhada e fornecer feedback :)

CC: @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (ou qualquer pessoa interessada) Qual é a política em relação ao uso de InternalsVisibleToAttribute para testes? Existem várias classes internal nesse namespace e pode ser difícil obter uma cobertura de teste adequada apenas por meio de métodos públicos. No entanto, compreendo que haja outras considerações.

Hmmm, infelizmente, não sei - @weshaggard @stephentoub? (pergunta na resposta anterior)

Pelo que tenho visto de outro código em corefx, os projetos em questão às vezes incluem os arquivos-fonte relevantes de outros projetos (embora eu imagine que isso ficará complicado muito rapidamente devido aos gráficos de dependência).

De memória, System.Collections.Immutable usa [InternalsVisibleTo] , se isso ajudar.

Por exemplo:

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

De forma geral:

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

Você pode ver meus pensamentos sobre InternalsVisibleTo nesta edição antiga https://github.com/dotnet/corefx/issues/1604. Minha opinião geral é não fazer isso a menos que haja uma necessidade específica real de fazê-lo.

Qual é a política de uso de InternalsVisibleToAttribute para testes?

Não.

Existem muitas classes internas dentro desse namespace e obter uma cobertura de teste adequada pode ser difícil apenas por meio de métodos públicos.

Se for algo diferente de um caminho de exceção profunda, ele deve estar acessível ou excluído. Se for necessário um caso de teste complicado para acertá-lo, bem, é disso que precisamos.

os projetos em questão às vezes incluem os arquivos-fonte relevantes de outros projetos

Supondo que você queira dizer "os projetos de teste incluem a origem do produto para obter acesso aos membros internos": Não.

[InternalsVisibleTo] e o compartilhamento de fonte são estratégias herdadas. Os mais vociferantes de nós acreditam (essencialmente) que nossos testes devem ser apenas representativos de coisas que podem ser encontradas no mundo real. Se nenhum teste é possível atingir algum bloco específico, então por que ele existe? Sim, existem alguns blocos que lançam exceções que não podem ser atingidos porque uma verificação redundante no alto da pilha já os detectou; mas isso é algo que pode ser considerado após o fato e declarado OK.

Portanto, eu recomendo puxar as especificações e garantir que haja um teste positivo para cada recurso (por exemplo, cada algoritmo que ele diz que suporta, e casos limite para valores mín. / Máx. Para opções nesses algoritmos).

Testes negativos como a remoção de elementos obrigatórios (por exemplo, 4.1 diz que SignedInfo é um elemento obrigatório para Signature ... emitimos uma exceção razoável se estiver faltando?) Também são bons.

Os testes de opção do canonizador, como <foo><!-- hi --></foo> e <foo></foo> (e talvez <foo /> ?) São iguais em c14n , mas diferentes em c14n-withcomments . (Isso provavelmente requer a assinatura dos dois lados e, em seguida, a troca de corpos, uma vez que o algoritmo de canonização deve ser assinado).

Testes de transformação. Todos os canonicalizadores são transformados. Etc.

Os testes de adulteração também são bons. Mas se você acredita que encontrou um teste de adulteração que falsifica com sucesso, não o reporte aqui ou envie / envie para qualquer representante no github (envie o teste / caso / descrição por e-mail para [email protected]).

Ok, pensei muito durante o dia. De volta às férias agora.

Obrigado @bartonjs por seus insights durante as férias! Agora vá e divirta-se no mundo real ;-)

@karelz @bartonjs (embora apenas quando você voltar das férias!) @steveharter e qualquer outra pessoa com uma opinião:

@anthonylangsworth criou alguns testes iniciais para iniciar a discussão e agradeceríamos qualquer feedback que você possa ter até agora.

Vejo que o Mono tem alguns testes SignedXml. Eles devem ser avaliados e verificados de acordo com a especificação xmldigsig, sugestões que @bartonjs mencionou anteriormente e o código atual para ver se \ se vale a pena portar \ trazer. Envie-me um ping para obter informações de direitos autorais (cabeçalho) se esses testes fizerem sentido.

Obrigado - vamos dar uma olhada nisso :)

Obrigado por isso, @steveharter . Você pode fornecer links, por favor? Isso poderia encurtar muitos de nossos testes. Existem direitos autorais ou outras considerações se expandirmos ou construirmos sobre eles em vez de copiá-los literalmente?

@anthonylangsworth ao copiar o código-fonte do Mono, temos que manter e atualizar o cabeçalho de direitos autorais. Eu sugeriria primeiro fazer apenas uma cópia (com os cabeçalhos certos, ajustes potencialmente menores). Assim que tivermos o código no CoreFX, podemos modificá-lo como desejarmos.

@anthonylangsworth Mono tests - https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.cs

Obrigado, @steveharter. Comecei a converter os testes de NUnit para Xunit .

Eu postei isso, mas percebi que está no repositório de

Aqui está a mágica para fazer com os cabeçalhos de direitos autorais quando puxamos o código do 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.

Há algum teste com falha neste projeto?

@ Jaedson33 No momento, estamos convertendo os testes mono. Ainda não encontrei nenhum teste com falha que indique erros de código, mas ainda temos muitos testes pela frente.

@anthonylangsworth O que posso fazer para ajudar?

@ Jaedson33 Eu respondi a essa pergunta em https://github.com/tintoy/corefx/issues/6#issuecomment -280904587. Para resumir, temos 84 testes mono ainda falhando (principalmente devido a padrões alterados e limitações de núcleo .Net). Qualquer ajuda para fazer os testes restantes funcionarem é apreciada. Caso contrário, estou trabalhando com eles.

@karelz @bartonjs @steveharter A classe System.Security.Cryptography.CryptoConfig afirma que muitas transformações XML não são suportadas no CoreFx (linhas 281 a 303 na parte inferior de DefaultNameHT ).

Eles correspondem aos URIs usados ​​por classes no namespace System.Security.Cryptography.Xml . Como parte da adição de System.Security.Cryptography.Xml volta ao .Net Core, suponho que devemos reinstalá-los. Por favor, deixe-me saber se eu estiver enganado.

CC: @tintoy

@anthonylangsworth , algumas dessas transformações, como XmlDsigC14NTransform são boas, mas outras, como XmlDsigXsltTransform, são consideradas muito perigosas. Embora você possa habilitá-los por meio da opção de chave de registro no .NET Framework completo, prefiro não oferecer suporte a eles no .Net Core. Dê uma olhada em KnownCanonicalizationMethods e DefaultSafeTransformMethods em https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/srecurity.Cryptography.Xml/src/securityCryptography.Xml/csrc/securityCryml as transformações que devemos apoiar.

Eu não tinha percebido que a origem dos perigosos foi incluída na porta. Eu votaria para removê-los inteiramente. Realmente não há maneira segura de usá-los.

@morganbr Obrigado pelo

@anthonylangsworth Parece ótimo!

@morganbr @AnthonyDGreen Essas transformações (que foram desabilitadas no patch MS16-035) foram discutidas anteriormente neste tópico ao discutir a porta. @bartonjs declarou em 14 de dezembro que o material reg-compat deve ser removido. Veja também o comentário de @steveharter de 15 de dezembro de que essas transformações provavelmente podem ser habilitadas para ligação tardia e, portanto, devem ser portadas.

@steveharter @bartonjs pode, por favor,

Mesmo sem suporte de registro, o CryptoConfig pode criar essas transformações vinculadas posteriormente por nome de string ou oid. Procure por 'CryptoConfig' no código SignedXml, pois é usado para criar a classe apropriada com base no conteúdo xml.

Isso significa que a classe CryptoConfig deve ser estendida para oferecer suporte a essas transformações, pelo menos para os mesmos tipos em netfx de qualquer maneira, e idealmente também fazer referência cruzada com Mono. A menos que haja um motivo (do qual não estou ciente) para não incluí-los e não conectá-los ao CryptoConfig.

FWIW aqui está a versão netfx do CryptoConfig (para comparar com o que está no corefx): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs , 20d26e036bc718bc

Há uma lista de "transformações permitidas" que é (no .NET Framework) extensível para compatibilidade com o registro. Para o .NET Core, não é extensível, mas codificado para incluir apenas as transformações sem entrada.

Como você não pode validar um documento usando transformações que não estão na lista de permissões, talvez não faça sentido portá-los. Mas, uma vez que alguém pode estar usando as transformações fora do contexto do SIgnedXml (apenas querendo usá-las como um mecanismo de transformação de propósito geral), talvez seja bom tê-las.

Como estaríamos falando sobre a remoção de um tipo inteiro, isso não criaria uma inconsistência com o .NET Framework ... então, provavelmente, eu recomendaria a remoção de quaisquer transformações que ainda não estejam na lista de permissões embutida no código. "Remova antes de publicar o pacote" pode ser alterado posteriormente. "Publique-os" não pode.

@bartonjs chegou antes de mim. CryptoConfig contém uma lista de transformações permitidas. Tive que modificar essa classe para permitir as transformações no novo namespace, System.Security.Cryptography.Xml . Embora algumas das transformações permitidas usem o nome completo de uma classe .Net, CryptoConfig ainda permite apenas uma lista fixa.

Eu preferiria não transportar transformações que têm problemas de segurança conhecidos, mas a compatibilidade com versões anteriores também é importante. Devemos tomar essa decisão em nome do desenvolvedor? Modificamos CryptoConfig para permitir alguma forma de extensão para que um desenvolvedor possa adicionar novas transformações se desejar? Como podemos tomar uma decisão sobre isso?

CryptoConfig não é o fator limitante: https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography3 --Xml/ L787. (Porém, se CryptoConfig ainda estiver sendo usado como a fábrica para resolução, qualquer transformação precisaria estar em ambos os lugares)

Os tipos que fornecem algoritmos que não estão nessa lista (que também não são canonicalizadores) efetivamente não têm valor.

Permitir a extensão para a lista segura exigiria uma nova API, portanto, está tecnicamente além do escopo deste esforço.

Eu, pessoalmente, deixaria de fora os tipos de transformação que não podem ser usados ​​na verificação de documentos. Eles serão difíceis de testar.

Na verdade, tanto CryptoConfig quanto DefaultSafeTransformMethods são relevantes. SignatureDescription criação de CryptoConfig , portanto, independentemente dos valores em DefaultSafeTransformMethods , você não pode usar uma transformação se ela não for mencionada em CryptoConfig . DefaultSafeTransformMethods restringe essa lista, portanto, se uma transformação for especificada em XML, mas não retornada por DefaultSafeTransformMethods , SignedXml.CheckSignature retornará falso.

Na implementação atual. CryptoConfig.AddAlgorithm lança um PlatformNotSupportedException , então os usuários não podem adicionar os seus próprios. Além do escopo desse esforço de transferência, pode valer a pena olhar para isso ou mesmo adicionar RemoveAlgorithm no futuro.

Após meu comentário anterior, encontrei a propriedade SignedXml.SignatureFormatValidator . Isso permite que um usuário especifique quais transformações e algoritmos de hash são apropriados. O chamador pode usar isso para substituir DefaultSafeTransformMethods , por exemplo.

Como perguntei antes, quem toma a decisão aqui? Como um "cara da segurança", minha preferência seria excluir opções inseguras. No entanto, não compreendo totalmente a extensão das incompatibilidades que isso pode causar.

@anthonylangsworth, esta discussão faz parte da tomada de decisão. Os especialistas da área com mais experiência tomarão a decisão aqui.

Minha recomendação: Se for questionável qual é a ação correta, sugiro manter o status quo - deixe o código como está durante o exercício de porta (potencialmente mesmo sem qualquer cobertura de teste) e decida mais tarde, separadamente do exercício de porta.

Ok, conversei com algumas pessoas internamente e acho que tenho o arcabouço de um plano:

• Deixe os tipos como públicos. (Eles são tipos públicos, e remover coisas deixa as pessoas tristes).
• Eles não podem (ainda) ser usados ​​em testes SignedXml de ponta a ponta. (Na verdade, os testes negativos parecem bons)
• Eles têm membros públicos que devem ser suficientes para o teste de unidade, então devemos fazer isso.
  
  
  
  • E isso vale para o resto dos tipos de transformação também.
  
  
• Se, por algum motivo, as transformações de aceitação de entrada não funcionarem e tudo mais estiver bem, podemos descobrir o que fazer com elas. (Isso também se aplicaria a "se eles tivessem dependências de compilação complexas que não podem ser atendidas", mas já ultrapassamos esse obstáculo).

E se / quando a API ou outra configuração vier para permitir que esses tipos funcionem, adicionar os testes E2E opcionais será fácil.

@tintoy @anthonylangsworth @peterwurzinger qual é o status do seu branch de teste? podemos começar a mesclá-lo? Posso escolher seus testes e continuar a partir daí.

Você também poderia fazer o PTAL em https://github.com/dotnet/corefx/pull/16545 ? Eu habilitei um dos exemplos do MSDN

Olá @krwq - Acredito que ainda haja alguns testes que estão falhando, mas como eles não são executados como parte do processo de compilação regular, você poderá incluí-los de qualquer maneira.

Deixe-me bater um papo com contato com você.

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

@krwq -

Suspeito que precisaremos rebase contra dotnet / corefx # 16545 (o que farei) antes de abrir um PR (o que @anthonylangsworth fará).

Entraremos em contato assim que estivermos prontos para isso (espero que não muito).

@krwq Para expandir o que @tintoy disse, embora ainda haja algum trabalho pela frente, muito trabalho também foi feito para portar os testes existentes e expandi-los. Em particular, eu já alterei CryptoConfig.cs para lidar com muitos dos algoritmos que você mencionou. Todos nós queremos levar isso adiante. Também não queremos duplicar ou sobrescrever o trabalho uns dos outros. Portanto, planejamos mesclar as alterações como estão, para que outros possam construir em cima do trabalho que fizemos, encontrar todos os nossos bugs e, com sorte, colocar tudo no master mais cedo.

@tintoy é https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests o único branch em que você está trabalhando?

Sim.

@krwq Bem, há um PR com uma boa quantidade de material do Mono em (que também é um sub-branch de https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests ... ) Se você estiver interessado em códigos atualizados, provavelmente deve dar uma olhada lá. Pelo que eu posso dizer, existem ~ 40/340 testes falhando.

Muito bem ,

@peterwurzinger @anthonylangsworth este PR é muito bom! Na verdade, senti falta disso. Você irá mesclar isso ao seu branch, para corefx ou você quer que eu pegue e faça todas as fusões / rebases? Perde alguma coisa dos testes Mono ou é um completo? @anthonylangsworth - para as mudanças do CryptoConfig - falei sobre isso com @bartonjs - não deveríamos tocar nesse arquivo - já é feio o suficiente.

Meu plano original era obter algumas amostras do MSDN e fazer com que funcionassem para que pudéssemos começar a fazer dogfood antecipadamente. Depois disso, mesclarei e corrigirei os testes de seu branch. Se alguns testes falharem, podemos simplesmente desativá-los por enquanto e corrigi-los mais tarde. Vamos fundir suas coisas em corefx / master o mais rápido possível: smile:

Obrigado pela atualização, @krwq . Se você puder, mantenha-nos atualizados. Ajuda saber o que pretendemos.

Hi = D

Há algum teste com falha?

@ Jaedson33 @anthonylangsworth @tintoy
Aqui está a lista atual das questões mais 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 sim, eles estão desativados no momento. Acima deve dar uma ideia aproximada de onde estamos

Olá, tem ideia de quando vai ser sem erros?

@ Jaedson33 todo software contém erros: wink: Há alguma coisa em particular que não funciona para você?

É simples: simplesmente não funciona no meu projeto UWP 😞

Olá, estou recebendo este erro quando tento executar build.cml. Pode me ajudar?

Erro no 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
A execução do comando falhou com o código de saída 1.
Falha ao gerar projeto de compilação de componente nativo!
A execução do comando falhou com o código de saída 1.

@JaedsonBarbosa Você está executando testes no prompt de comando do desenvolvedor? (aliás, isso é um pouco OT) para o UWP - estarei investigando se isso pode ser feito de forma razoavelmente barata para 2.0, embora sem promessas

Estou fazendo isso no Prompt de comando do desenvolvedor para Visual Studio 2017

@JaedsonBarbosa você puxou as últimas alterações do github e tentou compilar depois de limpar seu repo ( git clean -fdx )? A segunda coisa a tentar é reduzir o comprimento do caminho (ou seja, coloque seu repo em C: \ corefx). Outra coisa a tentar é limpar o cache do nuget ( %USERPROFILE%\AppData\Local\NuGet e %USERPROFILE%\.nuget )

Se ainda estiver acontecendo, crie um problema separado com as informações:

• seu sistema operacional
• sua versão do VS
• passos exatos que você fez
• log completo (se for grande, coloque-o na essência)

Acho que ocorre porque acho que o caminho C: / corefx / src / Native /../../ bin / obj / Windows_NT.x64.Debug / native \ install.vcxproj não é válido.

SO: Windows 10
VS: Comunidade 2017
Acabei de iniciar o Prompt de comando do desenvolvedor para VS 2017 e colocar:

cd C:/corefx
build

Agora o erro é:

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" = "O sistema não encontrou o arquivo especificado"

Desisto, não consigo fazer funcionar com o VS 2017.
Então, você tem ideia de quando isso pode ser baixado como um pacote NuGet?

Você deve conseguir consumir a visualização de myget.org.
O pacote oficial fará parte da onda do .NET Core 2.0 - consulte a descrição do marco 2.0.0 , 10 de maio é o ZBB (# 17619), portanto, o lançamento RTW deve seguir "logo" depois (as datas exatas ainda não foram divulgadas publicamente)

@karelz Você pode me enviar o link do pacote que contém o System.Security.Cryptography.Xml?

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

Veja como fazer dogfood 2.0: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

@karelz OK, quero instalar isso em uma biblioteca de classes UWP, mas quando tento isso, recebo esse erro:

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 não é compatível com uap10.0 (UAP, Versão = v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 dá suporte a:

• monoandroid10 (MonoAndroid, versão = v1.0)
• monotouch10 (MonoTouch, versão = v1.0)
• netcoreapp2.0 (.NETCoreApp, versão = v2.0)
• uap10.1 (UAP, versão = v10.1)
• xamarinios10 (Xamarin.iOS, Versão = v1.0)
• xamarinmac20 (Xamarin.Mac, versão = v2.0)
• xamarintvos10 (Xamarin.TVOS, Versão = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS, Versão = v1.0)

É meu 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 , atualmente não oferecemos suporte a UAP para essa biblioteca, você precisará esperar até que https://github.com/dotnet/corefx/pull/17969 seja mesclado e um novo pacote seja produzido.

😧 Ok, vou continuar esperando 😭
@krwq Mas ... O que é UAP10.1 ???

@krwq Por que você não mescla o PR dotnet / corefx # 17969 agora?

@JaedsonBarbosa Acabou de ser mesclado, acredito que o pacote deveria estar lá amanhã de manhã - normalmente não mesclamos a menos que o PR esteja verde no CI - temos alguns problemas de CI OSX desde ontem, então ficou um pouco desatualizado

@krwq Você pode me informar quando o pacote NuGet com as alterações puder ser baixado?

@JaedsonBarbosa esteja avisado de que o suporte do .NET Standard 2.0 em UWP é de ponta - não fará parte do .NET Core 2.0 - fará parte da próxima versão, temporariamente chamada de 2.1. Estamos trabalhando em algumas das coisas do 2.1 antes do tempo e em paralelo com o 2.0, para manter a infraestrutura, etc., para que possamos então paralelizar fortemente (após 10 de maio, que é o nosso ZBB para 2.0).
De qualquer forma, você pode encontrar alguns problemas ao usar a biblioteca em UWP. Podemos não estar em posição de ajudá-lo imediatamente. Devemos poder ajudar mais depois de 10 de maio ... apenas estabelecendo as expectativas.

@JaedsonBarbosa parece que não produzimos nenhuma nova versão por 2 dias 😞 Você pode observar as mudanças aqui:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
sempre que um pacote aparecer após 4/6, ele deve ter a mudança de que você precisa. Vou verificar hoje porque não havia pacote - pode estar relacionado a problemas de rede que temos com compilações OSX

EDIT: confirmando - isso está relacionado a problemas de rede OSX

@krwq Sabe agora se hoje os problemas de rede OSX serão resolvidos?

Ele está bloqueando quase todos os nossos PRs, portanto, sua alta prioridade, mas não temos um ETA

Ok 👍
Então, vou continuar esperando.

Quando a parte 4 estará pronta?

@JaedsonBarbosa , temos as partes mais significativas já testadas e comprovadas em funcionamento. Com o teste, não há um único ponto "concluído" - você pode ter 100% de cobertura de código e código que não funciona. Há algum cenário específico no qual você está interessado?

Não 😃

@krwq Espero que declaremos as coisas feitas para a biblioteca, quando estivermos confortáveis ​​em enviá-la como estável. Quando fizermos isso, podemos marcar a caixa e fechar este problema. Então, até onde estamos testando?

@karelz No momento, estou confortável com o envio, já que todos os cenários E2E importantes que eu poderia imaginar foram testados. Eu ainda gostaria de aumentar a cobertura para que cenários menos populares (incluindo tratamento de erros) possam ser provados funcionando corretamente também, embora eu não espere encontrar nenhum problema de bloqueio 2.0.

Para mim, "pronto" significa que ninguém mais manterá ou melhorará a biblioteca

OK, se @bartonjs concorda com ready-to-ship-state, então sejamos práticos e
Se quisermos aumentar a cobertura de teste (como sem bloqueio 2.0), devemos criar um item de trabalho separado para o Futuro.

Se acertamos tudo na lista de algoritmos, transformações e canonicalizadores, por mim tudo bem.

Portanto, acho que esse problema finalmente será encerrado.

Ok, vamos acompanhar o progresso da cobertura com: https://github.com/dotnet/corefx/issues/16829 - Pensei que tratássemos isso como um problema principal

Sim, tratamos isso como um problema principal, mas às vezes você tem que declarar coisas feitas, caso contrário, você teria um problema aberto para cada rastreamento de recurso maior "fazer mais" - o que não está ajudando ninguém de verdade.

Agora está fechado 😢
Então ... Onde devo fazer perguntas sobre o System.Security.Cryptography.Xml?

A resposta de @krwq acima não é suficiente?
Se você tiver perguntas maiores, registre um novo problema. Se for um pequeno esclarecimento da resposta anterior, você pode mantê-lo aqui. Se não tiver certeza, pergunte aqui e, na pior das hipóteses, pediremos que você registre um novo problema ;-)

@krwq Continua sem suporte para UWP 😞

@JaedsonBarbosa https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 não funciona para você? Você poderia enviar as etapas do que está fazendo?

@krwq Acabei de colocar esse comando:
Install-Package System.Security.Cryptography.Xml -Version 4.4.0-preview1-25210-01

Esse é o erro:

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 não é compatível com uap10.0 (UAP, Versão = v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 dá suporte a:

• monoandroid10 (MonoAndroid, versão = v1.0)
• monotouch10 (MonoTouch, versão = v1.0)
• netcoreapp2.0 (.NETCoreApp, versão = v2.0)
• uap10.1 (UAP, versão = v10.1)
• xamarinios10 (Xamarin.iOS, Versão = v1.0)
• xamarinmac20 (Xamarin.Mac, versão = v2.0)
• xamarintvos10 (Xamarin.TVOS, Versão = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS, Versão = v1.0)

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

Apenas um lembrete do que eu disse antes: https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
Não acho que você terá suporte UWP com o pacote. O pacote depende do .NET Standard 2.0 AFAIK e o UWP ainda não tem suporte ao .NET Standard 2.0 - é algo em que trabalharemos para .NET Core 2.1 (alguns bits são feitos no início para desbloquear uma equipe maior para trabalhar nisso pós-5 / 10, mas não é totalmente funcional).
IMO para obter suporte UWP para o pacote, você terá que esperar no 2.1.

@karelz Então você acha que vou precisar esperar até quando?
Posso criar um projeto uap10.1?

Sim, acho que você precisará esperar até então.
A menos que você esteja super motivado e consiga superar todos esses redutores de velocidade. Como eu disse, até 5/10 nossa capacidade de ajudá-lo com qualquer coisa UWP será muito limitada , então você estará principalmente por conta própria 😦. Apenas estabelecendo as expectativas aqui ...

Então, vou esperar porque não consigo construir o corefx-master com o Visual Studio 2017 😞

@karelz @krwq Não consigo construir a solução porque dei um erro, você pode ver o CMakeError aqui:
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
Por favor me ajude 🆘
PS: Está em português, mas você pode usar um tradutor para ler isso 😄

Acho que falhar não é bom:
- A identificação do compilador C é MSVC 19.0.24218.2
- A identificação do compilador CXX é MSVC 19.0.24218.2
- Verifique se o compilador C está funcionando: C: / Arquivos de programas (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
- Verifique se o compilador C está funcionando: C: / Arquivos de programas (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe - funciona
- Detecção de informações ABI do compilador C
- Detecção de informações ABI do compilador C - concluído
- Verifique se o compilador CXX está funcionando: C: / Arquivos de programas (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
- Verifique se o compilador CXX está funcionando: C: / Arquivos de programas (x86) / Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe - funciona
- Detecção de informações ABI do compilador CXX
- Detecção de informações ABI do compilador CXX - concluído
- Detecção de recursos de compilação CXX
- Detecção de recursos de compilação CXX - concluído
- Executando teste COMPILER_HAS_DEPRECATED_ATTR
- Executando teste COMPILER_HAS_DEPRECATED_ATTR - Falha
- Executando teste COMPILER_HAS_DEPRECATED
- Executando teste COMPILER_HAS_DEPRECATED - Sucesso
- Configuração feita
- Geração feita

Alguém agora o que posso fazer para construir?

@JaedsonBarbosa como você constrói? O processo normal para mim é:

1. Abra o cmd.exe
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - isto irá limpar o seu repositório de quaisquer arquivos restantes (tenha cuidado se você não tiver certeza do que faz)
5. build ou ./build.sh se você não estiver usando o Windows

Para construir componentes nativos, você precisa instalar o CMake 2.8.12 ou superior

Isso sempre funcionou para mim.

@ Jaedson33 você também pode verificar e nos ajudar a melhorar nossos documentos de novos colaboradores (link da página principal do CoreFX)

Estou usando o CMake 3.8.
@krwq Eu fiz o que você disse e estou esperando cerca de 1 hora e só falta Instalando o dotnet cli ..., quantas horas você acha que vou precisar esperar?

@JaedsonBarbosa deve demorar alguns minutos, tente reiniciar - podem ser alguns problemas de conexão, se não funcionar, registre um problema separado neste repositório, alguém deve ser capaz de rastrear o que aconteceu

@krwq Recebo este erro:

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 , registre um novo problema conforme sugerido acima. Apenas um lembrete de que talvez não possamos fornecer todo o suporte para solução de problemas antes de 5/10 como gostaríamos.

@karelz Agora está funcionando 😄
A única coisa que fiz para compilar foi mover os arquivos de C: \ Users \ jaeds \ Source \ Repos \ corefx-master para C: \ Users \ jaeds \ Source.
Eu acho que deveria estar no README

Olá, agora você pode usar este pacote em um aplicativo UWP, aqui um aplicativo de amostra: https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

@JaedsonBarbosa ótimo! Há algo em seu trabalho que seria valioso para retornar ao CoreFX? (ou seja, coisas que não são hacks temporários)

@karelz Bem, acho que você pode usar meu projeto para ver o que pode simplificar (ou remover) no CoreFX 😄

Olá a todos, grande esforço em portar isto!

Posso perguntar por que o pacote Nuget está se referindo ao .NET Core 2.0, em vez do .NET Standard 2.0? Não seria o preferido?

Isso deveria ter sido feito (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

Suponho que você esteja vendo a prévia oficial do Nuget
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

e só tem a Myget
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

Sim, era para onde eu estava procurando. Obrigado, @danmosemsft!

@leopignataro não tem problema, eu encorajo você a experimentar os bits do "head" - você pode obtê-los na página inicial aqui https://github.com/dotnet/cli ... você pode apenas baixar o zip se quiser. Informe-nos se encontrar problemas - temos apenas um pouco de tempo para corrigi-los antes do lançamento.

Para sua informação: Aqui estão as informações sobre cronogramas: https://github.com/dotnet/corefx/issues/17619#issuecomment -301937346

Já que você mencionou, @danmosemsft , há um problema:

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

Eu sugeri uma correção no tópico, mas minha mensagem pode ter sido perdida em todo o buzz.

@leopignataro correção para quê e onde? Se for consertado para dotnet / corefx # 19198, então deve ser rastreado no bug. Se for outra coisa, eu preferiria ver um problema separado para isso.
Se você acha que sua sugestão de correção foi esquecida em algum lugar, levante-a novamente nesse tópico e peça feedback.

Estou confuso agora. Eu pensei que o pacote System.Security.Cryptography.Xml NuGet é para .NET Framework e já está incluído no Dot Net Core v2. Ele não está reconhecendo este namespace no Dot Net Core v2. Eu ouvi isso incorretamente? Obrigado.

@ fletchsod-developer O pacote é principalmente para .NET Core. Mas se você fizer referência a ele de uma biblioteca direcionada ao .NET Standard, ele se unificará com a versão do .NET Framework no .NET Framework e executará o código de dentro do pacote no .NET Core.

Não temos planos de colocar SignedXml na experiência de instalação padrão do .NET Core; é nicho o suficiente para que ser um pacote separado no NuGet pareça o melhor modelo de distribuição.