Runtime: System.Security.Cryptography.Xml.SignedXml 클래스 추가

Tratcher에서 참조한 대로 이것은 ASP.NET 5에서 WsFederation/ADFS에 대한 지원을 추가하기 위한 차단기입니다. 우리는 많은 엔터프라이즈 ASP.NET 4 응용 프로그램에 대해 ADFS를 광범위하게 사용합니다. 우리는 ASP.NET 5로 마이그레이션하고 WsFederation을 사용하는 데 매우 관심이 있습니다.

@rschiefer @Tratcher 글쎄요... 복잡합니다.

• ADFS는 System.Security.Cryptography.Xml.SignedXml을 사용하지 않습니다. 대신 자체 구현.
  
  
  
  • (그것은 주로 정신적 거미줄을 털어내고 ADFS 버전 1을 위해 그 팀에 있었던 것을 기억하는 것에서 비롯됩니다)
  
  
• System.IdentityModel은 확실히 System.Security.Cryptography.Xml을 사용하지 않습니다.
  
  
  
  • (참고 소스의 소스 코드가 그렇게 말했기 때문입니다. 스마일:)
  
  
• 사람들은 System.Security.Cryptography.Xml.SignedXml을 좋아하지 않습니다. 왜냐하면 XmlDocument를 기반으로 하기 때문에 성능 문제가 발생하기 때문입니다.
  
  
  
  • ADFS 버전은 XmlReader, IIRC를 기반으로 했습니다.
  
  
• 따라서 사람들이 원하는 것은 CoreFX가 SignedXml의 새로운 구현을 만드는 것입니다.
• 그러나 새 버전의 SignedXml은 이전 버전의 SignedXml과 호환되지 않습니다.
• 그래서 어떤 사람들은 우리가 이전 버전을 유지하기를 원할 수도 있습니다.
• 결국 사람들은 두 가지 버전을 원합니다.
• 그들이 이전 버전을 원하지 않는다는 것을 제외하고.
• 그들이 할 때를 제외하고.

따라서 다음과 같은 수수께끼가 남습니다.

• 아무도 원하지 않는 클래스를 이식할 수 있습니다.
• 또는 다른 것과 호환될 수 없기 때문에 아무도 사용하지 않을 완전히 새로운 것을 중지하고 디자인할 수 있습니다.
• 또는 가장 많은 노력을 기울이고 여전히 누구에게도 도움이 되지 않으려면 두 가지 모두를 수행 하십시오.

@terrajobst - 참고로

분명히 나는 ​​오늘 아침에 약간 게을렀다. 죄송합니다 :).

우리는 여기서 해야 할 일이 있다는 것을 확실히 확인했지만, 우리는 정답이 기존 System.Security.Cryptography.Xml 코드를 앞으로 가져오는 것이라고 생각하지 않습니다. 대신, 이것은 빠르고 레거시 개체 모델(예: XmlDocument)에 연결되지 않은 XmlDSig에 대한 범용 구현을 엔지니어링하기 위한 백로그의 항목을 나타냅니다.

그 노력은 .NET Core 1.0에 대해 수행할 것으로 기대하는 것이 아닙니다. 단순히 다른 일에 집중하기 때문입니다.

그러나 누락된 기능으로 인해 영향을 받았음을 알려주시면 지속적인 우선 순위 지정에 도움이 됩니다.

https://github.com/KentorIT/authservices를 기반으로 ASP.NET Core SAML2 미들웨어를 만들려고

나는 기존 것을 이월하지 않는 것이 좋은 생각이라는 데 확실히 동의합니다. XmlReader API를 기반으로 무엇이든 할 수 있습니까? 그렇게 하면 XDocument와 XmlDocument를 모두 지원할 수 있습니다. 또한 System.IdentityModel에서 사용되는 엔벨로프 판독기의 구현을 제공하는 것이 좋을 것입니다(공백이 있는 XML 파일을 지원하도록 개선된다면...)

@AndersAbel XmlReader가 내가 시작할 곳입니다(XML 사용자가 더 나은 것이 있다고 말하지 않는 한).

XmlReader는 System.IdentityModel 변형의 기반이 되므로 수행할 수 있어야 합니다. :).

@bartonjs System.IdentityModel 변형은 처리할 수 있는 변환이 매우 제한적입니다. SAML2/WS-Fed 작업의 경우 문제가 되지 않지만 일반적인 API로서 중첩된 서명이 포함된 xml 및 비-엔벨로프 서명(예: 서명된 주장을 포함하는 서명된 saml 응답)을 처리하는 방법을 고려해야 합니다. 또한 유효성 검사를 수행할 때 System.IdentityModel.EnvelopedSignatureReader가 데이터를 복사하고 있다고 생각합니다. 거기에 할 수있는 많은 재미가 있습니다. 시간이 있다면 작업하고 싶습니다.

나는 뒤에서 무슨 일이 일어나고 있는지 보는 데 도움이 되는 @bartonjs 의 횡설수설에 감사드립니다.

현재 우리 회사는 이것의 영향을 받고 있습니다. 서명된 XML 라이선스 파일을 생성하는 .NET Core로 이식하려는 일부 레거시 코드가 있으며 이 클래스 집합이 없으면 멈춥니다. 우리는 라이선스의 기반으로 XML 파일을 다양화할 수 있지만 현재로서는 우리의 요구에 맞는 좋은 솔루션을 찾지 못했습니다.

앞으로 이 기능이 추가되기를 기대합니다.

나는 이것이 (그리고 약간 관련된 XML 암호화도) 우리와 관련이 있음을 증명할 수 있습니다. .NET Framework의 기존 형식은 괜찮을 것입니다. 제 관점에서는 여기에 혁신이 필요하지 않습니다. 복사 및 붙여넣기 구현을 매우 환영합니다!

현재 사용 가능한 해결 방법이 있습니까?

@sandersaares도 질문한 내용을 알고 싶습니다. 지금 CoreFX에서 xml에 서명하는 방법이 내장되어 있지 않습니까?

@sandersaares / @af0l : .NET Core 1.0의 경우 SignedXml/XmlDSig의 내장 구현이 없습니다.

여기(및 기타)의 의견을 기반으로 우리는 아마도 이전 API를 가져올 것입니다. 그러나 1.0에서 이를 실현할 시간이 없었습니다.

@bartonjs에게 감사드립니다. 이것이 제가 Core에서 우리 프로젝트를 작동시키지 못한 이유일 것입니다. :) 또한 앞으로 나아가고 싶지만 완료될 때까지 할 수 없기 때문에 매우 부끄럽습니다. 서명된 xml을 사용하여 세무 당국에 모든 지불을 보고해야 합니다.

이에 대한 진전이 있습니까? 이 기능이 필요한 SAML 토큰 유효성 검사가 막혔습니다. 감사 해요

예, 그것도 알고 거짓말을 할 것입니다. 결국 서명이 필요한 기능을 추출하여 별도의 웹 API 솔루션에 넣었습니다...

구현될 버전 또는 솔루션에 대한 아이디어가 이미 있습니다.

이 시점에서 가장 간단한 대답은 기존 .NET Framework 구현을 .NET Core로 이식하는 것입니다. 그래서 우리는 이것을 다른 "포팅하기 어렵게 만드는" API 생략과 함께 버킷팅하고 있습니다.

주제와 관련이 있을 수 있음: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently 및 https://github.com/sandersaares/ xml-c14n-공백-결함. Canonical XML 1.0의 .NET Framework 구현이 잘못된 것 같습니다. 내가 틀렸으면 좋겠지만, 그렇다면 이것은 몇 가지 털이 많은 호환성 질문을 소개할 수 있습니다.

@sandersaares 샘플을 보고 공백이 포함된 경우 Xml을 읽을 때 XmlDocument.PreserveWhiteSpace = true 를 설정해야 합니다.

@AndersAbel 힌트 주셔서 감사합니다! 이는 상황을 변경하고 실제로 XML 스키마가 있는 경우 일치하는 유효성 검사를 가능하게 합니다. XML 스키마가 없으면 동작이 유효하지 않은 상태로 유지됩니다(새롭고 흥미로운 방식으로). 그에 따라 Connect 문제와 GitHub 리포지토리를 업데이트했습니다.

@bartonjs 기존 .NET 프레임워크 솔루션을 포팅하는 경우 다중 서명 확인을 방해하는 버그를 수정하십시오: https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

참고로 이것이 구현 단계에 도달하면 .NET Framework에서 XML 서명(서명 및 확인 모두) 및 기타 XML 기능을 사용하는 테스트와 함께 새로 만든 라이브러리가 있습니다. 종속성이 없는 실제를 얻는 데 유용할 수 있습니다. - 구현을 시도하는 세계 코드: https://github.com/Axinom/cpix

이 API의 개발 일정이 있습니까?

//cc @bartonjs

@henkmollema 특별한 것은 없습니다. 1.2 릴리스의 경우 .NET Framework와 .NET Core 간의 격차를 줄이기 위해 노력하고 있습니다. 그리고 그 노력은 현재 SignedXml의 출처입니다.

저는 오늘 ASP.NET Core(KentorIT의 구현을 사용함)에서 SAML2-P 지원이 필요한 고객과 통화했습니다. 이것은 ASP.NET Core로 이동하려는 고객의 차단 문제입니다. 지금은 고객이 Katana에 머물러야 합니다.

이정표가 1.2에서 Future(@bartonjs에 의해)로 변경된 것을 봅니다. 의견을 제시하거나 자세히 설명할 수 있습니까?

주로 이정표를 추적하는 방법과 관련이 있습니다. 우리는 "이것이 되기를 바랍니다"라는 말을 더 많이 하다가 이정표가 끝나면 완료되지 않은 모든 것을 다시 할당했습니다. 우리는 이제 "이 이정표에 표시한 경우 재할당되는 경우는 매우 드물 것입니다"라고 말하기 위해 열심히 노력하고 있습니다.

이것은 1.2 이정표에 대한 다른 많은 작업의 다운스트림이며 (어쨌든 나에게) 1.2로 만드는 것은 항상 약간의 스트레칭이었습니다. 그것은 여전히 ​​우리의 "차기작" 목록에서 꽤 높은 순위에 있으며, 1.2 릴리스(주로 netstandard2.0 작업, 버그 수정 및 몇 가지 인프라 프로젝트)의 일부가 되기를 '약속'하지 않습니다.

그것을 미래로 표시한다고 해서 그것이 1.2 릴리스의 일부 가 되지 않을 것이라는 보장

@karelz 추가(또는 수정)하고 싶은 것이 있으면 언제든지 환영합니다.

우리는 1.2시간 안에 작업 자금을 조달할 수 없을 것입니다(마무리하기에는 영향력이 더 큰 다른 것들이 너무 많습니다). 그렇기 때문에 우리의 계획을 전달하기 위해 이를 Future 마일스톤으로 옮겼습니다.
우리는 질문의 수를 알고 있기 때문에 보안 영역 백로그에서 높습니다. 또한 일반적으로 (DirectoryServices, SerialPort 등) corefx에서 누락된 API가 가장 많이 요청되는 항목 중 하나입니다.

참조: @steveharter @danmosemsft @terrajobst

우리의 대답은 교차했습니다 :)
Milestones에 대한 자세한 내용은 문제 가이드 에 있습니다.

.NET Framework 코드는 참조 소스 로 사용할 수 있습니다. 따라서 기술적으로 말하면 .NET Core 팀 외부에서도 포트를 시작할 수 있습니다. 여기에서 도움을 원하는 사람들이 있는 경우입니다.
@bartonjs 와의 이전 채팅에서 저는 "도전"의 핵심이 테스트 생성/포팅이 될 것이라고 생각합니다.

이 문제에 대한 실제 상황은 어떻습니까?

@ Jaedson33 '문제'가 무엇을 의미합니까? 언제 수정될 것인지를 의미하는 경우 -- 지난 주 답변을 참조하십시오.

@karelz 하지만 기다리고 싶지 않습니다. 왜 지금 수정하지 않습니까?

@Jaedson33 위의 내 답장을 참조하십시오. 지금 자금을 조달할 수 없는 이유를 설명합니다. 우선순위에 관한 것입니다. 지금은 많은 기능/API를 원하는 사람들이 줄지어 있는데, 우리는 무한한 규모의 팀이 없기 때문에 우선순위를 두어야 합니다.

정말 빨리 필요한 경우 언제든지 코드 기반에 기여할 수 있습니다. 안내, 코드 검토 및 피드백을 기꺼이 도와드리겠습니다.

알겠습니다. 기다리겠습니다.

@karelz 작업을 확인하기 위해 원래 테스트를 사용할 수 있다면 기꺼이 손을 내밀겠습니다. :)

(내 동료 중 한 명도 관련 경험이 있으므로 함께 작업할 것입니다.)

작업의 핵심 부분은 실제로 새로운 테스트 자산을 만드는 것입니다. 오래된 테스트는 불충분하고 커버리지가 좋지 않습니다. 사양을 검토하고 모든 흥미로운 요구 사항에 대한 테스트를 추가할 사람이 필요합니다. 비용의 대부분이 여기에 있습니다.

여전히 관심이 있는 경우 전체 .NET Framework에서 소스 코드를 있는 그대로 드롭할 수 있습니다. 다음 단계는 .NET Core의 일부로 릴리스되기 전에 빌드하고 테스트 범위를 추가하는 것입니다. 관심있으시면 알려주세요...

알겠습니다. 여전히 관심이 있습니다. :)

@tintoy 저는 그 수업이 정말 필요하기 때문에 여러분을 돕고 싶습니다.

@tintoy 저는 그 수업이 정말 필요하기 때문에 여러분을 돕고 싶습니다.

그것을 듣고 기뻐 :)

그래서... 어떻게 도와드릴까요?
Obs: GitHub를 처음 사용합니다.

그래서... 어떻게 도와드릴까요?

먼저 동료와 이야기를 나누고 공격 계획을 세워보겠습니다. @karelz - 들어가기 전에 읽어야 할 지침이나 다른 문서가 있습니까? 우선, 내 동료가 표준에 뛰어들 것이라고 생각하고 코드가 어디로 가야 하는지(그리고 우리가 만들기 전에 프레임워크의 다른 부분에서 기존 테스트를 실행하는 것과 관련된 작업을 살펴볼 것입니다. 모든 변경 사항). 합리적으로 들리나요?

CC: @anthonylangsworth

범위를 약간 제한적으로 유지하려면 MS16-035에서 비활성화된 기능(xpath 변환, xslt 변환, 외부 참조) 없이 시작하는 것이 좋습니다. 변경 사항을 위반할 여지가 있는지 모르겠지만 DefaultGetIdElement의 현재 폴백 메커니즘은 서명 래핑 공격에서 악용될 수 있습니다. 더 안전한 기본 버전을 선호합니다.

XML 서명 유효성 검사의 두 가지 개별 구현을 사용하는 대신 System.IdentityModel에서 사용하는 EnvelopedSignatureReader를 지원하도록 내부 API를 약간 재구성하는 것도 좋을 것입니다.

마지막으로 이 버그 보고서에 따라 단일 점을 추가하고 싶습니다.

@tintoy 좋은 문서가 없다고 생각합니다. 소스를 추가해야 작업을 병렬화할 수 있다고 생각합니다. @bartonjs @steveharter @ianhays와 동기화하겠습니다.

저도 도움이 되는 시간을 갖도록 노력하겠습니다. 사양과 작동 방식에 대한 질문이 있으면 기꺼이 검토하겠습니다. 이미 사양을 검토하는 데 시간을 보냈습니다.

SignedXml과 System.IdentityModel에서 사용하는 EnvelopedSignatureReader를 통합하는 아이디어에 대해 말할 사람이 있습니까?

@AndersAbel

MS16-035(xpath 변환, xslt 변환, 외부 참조)에 의해 비활성화된 기능 없이 시작

안전해야 하는 최신 .NET Framework 소스 코드로 시작해야 합니다. .NET Framework 코드 보안에 대해 우려 사항이 있는 경우 오프라인으로 알려주십시오.

변경 사항을 위반할 여지가 있는지 모르겠습니다.

공간이 없습니다. .NET Framework에서 간단한 포트로 시작해야 합니다. 추가 개선 사항, 변경 사항, 주요 변경 사항 등은 나중에 고려할 수 있습니다. 초기 작업의 일부가 아닙니다. 그렇지 않으면 그것은 우리 머리 위로 자랄 것입니다.

DefaultGetIdElement의 현재 폴백 메커니즘은 서명 래핑 공격에서 악용될 수 있습니다.

그것은 별개의 문제로 취급되어야 합니다. @bartonjs 의견을

XML 서명 유효성 검사의 두 가지 개별 구현을 사용하는 대신 System.IdentityModel에서 사용하는 EnvelopedSignatureReader를 지원하도록 내부 API를 약간 재구성하는 것도 좋을 것입니다.

다시 말하지만, 테스트 범위가 좋은 완전한 기능의 포트를 확보한 후 다음 단계로 진행해 보겠습니다.

마지막으로 이 버그 보고서에 따라 단일 점을 추가하고 싶습니다.

GitHub에 별도의 문제로 제출하세요. 이상적으로는 여기에 코드를 이식한 후(즉, 버그가 .NET Core에 실제로 적용 가능한 경우).

SignedXml과 System.IdentityModel에서 사용하는 EnvelopedSignatureReader를 통합하는 아이디어에 대해 말할 사람이 있습니까?

다시 한 번 말씀드리고 싶습니다. 포팅 후 다음 단계로 처리해야 합니다.

DefaultGetIdElement의 현재 폴백 메커니즘은 서명 래핑 공격에서 악용될 수 있습니다.

그것은 별개의 문제로 취급되어야 합니다. @bartonjs 의견을

@AndersAbel 보안 문제가 있다고 생각되면 https://technet.microsoft.com/en-us/security/ff852094.aspx 에서 취약점 보고 프로세스를 따르십시오

System.IdentityModel에서 사용하는 SignedXml과 EnvelopedSignatureReader를 통합하는 아이디어에 대해 말할 사람이 있습니까?

불가능할 것 같습니다. SignedXml은 풍부한 DOM XmlDocument를 기반으로 하는 매우 강력하고(공개 API와) 관련되어 있습니다. IdentityModel의 표현은 XmlReader를 기반으로 합니다. 그러나 기존 물건을 가져오면 조사할 수 있습니다.

저도 도움이 되는 시간을 갖도록 노력하겠습니다. 사양과 작동 방식에 대한 질문이 있으면 기꺼이 검토하겠습니다. 이미 사양을 검토하는 데 시간을 보냈습니다.

@AndersAbel - 건배, 우리가 도움을 사용할 수 있다고 확신합니다 :)

@bartonjs 저는 이러한 문제를 [email protected]에 보고

@karelz 변경 사항을 깨뜨릴 여지가 없다는 점을 정리

MS16-035(xpath 변환, xslt 변환, 외부 참조)에 의해 비활성화된 기능 없이 시작

안전해야 하는 최신 .NET Framework 소스 코드로 시작해야 합니다. .NET Framework 코드 보안에 대해 우려 사항이 있는 경우 오프라인으로 알려주십시오.

MS16-035 패치는 SignedXml의 여러 문제를 해결했습니다. 하지만 레지스트리 키를 사용하여 안전하지 않은 이전 동작으로 되돌릴 수 있습니다. 이러한 옵션을 .NET Core에도 이식해야 합니까? 위의 제 제안은 현재 기본 .NET Framework 동작을 이식하는 데 우선 순위를 두고 현재 기본적으로 비활성화된 부분을 남겨두는 것입니다. 아니면 그 부분들도 옮겨야 하는 중요한 부분이라는 말씀이신가요? 그런 다음 .NET Core AFAIK가 구성을 위해 레지스트리에 의존하지 않으므로 구성을 처리하는 방법에 대한 질문이 있습니다(모든 플랫폼에서 사용할 수 있는 것은 아니므로).

하지만 레지스트리 키를 사용하여 안전하지 않은 이전 동작으로 되돌릴 수 있습니다. 이러한 옵션을 .NET Core에도 이식해야 합니까?

아니요. 레지스트리 호환 전용 코드는 패키지를 사용할 수 있게 되기 전에 삭제됩니다.

그것을 구현하기 위해 GitHub에서 프로젝트를 만들지 않는 이유는 무엇입니까?

@bartonjs , @steveharter 및 @ianhays와 동기화했습니다.

편집: 실행 계획이 맨 위 게시물로 이동했습니다.

나에게 좋은 소리 :)

@karelz , @steveharter 대부분의 레지스트리 조회는 Utils 클래스에 있습니다: AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier . 알려진 변환 목록을 설정하는 SignedXml 클래스 에도 조회가 있습니다. 레지스트리 호환성이 없으면 XmlDsigXPathTransform 및 XmlDsigXsltTransform 액세스할 수 없다고 생각합니다. 레지스트리 호환 코드와 함께 소스에서 완전히 제거해야 합니까?

그것이 내가 아는 것입니다. 코드를 읽는 동안 다른 것을 본 적이 없지만 뭔가를 놓쳤을 수 있습니다.

@AndersAbel 레지스트리와 관련하여 위의 Karel의 의견을 업데이트했습니다. 액세스할 수 없는 클래스가 있는 경우 손실되는 기능을 이해해야 합니다. 당신이 언급한 것들에 대해 CryptoConfig는 이름:객체 쌍을 추가해야 하므로 늦게 바인딩할 수 있다고 생각합니다

이 수업이 언제 준비될 것 같습니까?

기여를 의미합니까? @steveharter 는 초기 "소스 추가" PR을 곧(아마도 오늘) 제출할 계획입니다.

초기 코드가 방금 병합되었습니다.

@steveharter 감사합니다 😃

@steveharter 감사합니다! 더 쉽게 진행 상황을 추적할 수 있도록 실행 계획을 최상위 게시물로 옮겼습니다. 우리가 그것을 변경할 때마다 우리는 여기에 다른 답장에서 변경 사항을 언급할 것입니다.

누군가 작업을 시작하고 싶다면 중복 작업을 피하기 위해 그렇게 말하십시오. 우리는 당신에게 문제를 공동 할당합니다.

@karelz : @tintoy 와 저는 이것을 시작하기 위해 손을

누군가 작업을 시작하고 싶다면 중복 작업을 피하기 위해 그렇게 말하십시오. 우리는 당신에게 문제를 공동 할당합니다.

건배 - 컴파일을 시작하게 되어 기쁩니다 :)

@anthonylangworth - 하, 저를 이겨주세요!

여기에서 작업이 진행 중입니다.

@tintoy에 할당되었습니다. @anthonylangsworth 가 저도 이를 공동 할당할 것입니다(GH는 그것 없이는 양수인 옵션을 제공하지 않습니다).

감사 해요!

@karelz 확인을 위해 - 기여자 지침에 대해 이해한 바에 따르면 master 에서 이러한 변경을 수행할 예정 입니까?

(내 master 분명히)

어, 죄송합니다. 다시 시도하겠습니다. 결국 PR은 master 에 반대되는 것입니까?

네, 맞습니다. 마지막 단계까지 전체 corefx 빌드/테스트 실행의 일부로 만들지 마십시오.

src/Common/src/Interop/Windows/Crypt32/Interop.certificates_types.cs 의 내부 클래스로 이동된 것으로 보이는 몇 가지 상수를 찾았습니다. 하지만 System.Security.Cryptography.Xml 에서는 액세스할 수 없습니다. 여기에서 가장 좋은 방법에 대한 생각이 있습니까?

그 중 어떤 것이 필요합니까? 그들 모두?
.NET Fx에서 공개된 경우 참조 소스를 확인할 수 있습니까? (그렇지 않다고 생각하지만 두 번 확인하는 것이 나쁠 것은 없습니다)
나는 우리가 Crypto 라이브러리의 나머지 부분을 활용하는 대신 특별한 상호 운용성을 수행한다는 사실에 약간 놀랐습니다 ... 특별한 것이 필요하거나 역사적인 이유에서 ... @steveharter @bartonjs 어떤 생각이 있습니까?

@tintoy 이러한 노력으로 수행해야 할 작업 중 하나는 CAPI와의 직접 인터페이스를 제거하고 .NET API 사용으로 전환하는 것입니다.

@karelz , @bartonjs - 주로 CryptographicException 생성자에 전달되는 CAPI HRESULT 상수입니다.

예를 들어:

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

corefx의 다른 코드가 CryptographicException 와 어떻게 작동하는지 살펴보겠습니다.

아, 알겠습니다. HRESULT 생성자가 더 이상 사용되지 않는 것처럼 보입니다. 단지 메시지를 받는 생성자일 뿐입니다. 해당 E_xxx 값에 해당하는 기존 메시지 리소스가 있는지 확인하겠습니다.

다른 문제에 관해서는 유형이 더 이상 단일 어셈블리를 공유하지 않는 결과처럼 보입니다. 예를 들어 X509Utils.DecodeHexString 는 System.Security.Cryptography.X509Certificates 있지만 전체 프레임워크에서는 이를 사용하는 클래스와 함께 System.Security 어셈블리에 있습니다.

모든 것이 여러 어셈블리로 나뉩니다. 일반적으로 공유되는 구성 요소를 처리하기 위해 선호하는 메커니즘은 무엇입니까? 원하는 경우 다른 어셈블리의 코드에서 필요한 기능의 복사본을 만들 수 있습니다.

또는 다음과 같은 것을 사용하여 소스를 가져옵니다.

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

지금은 단순히 `Interop.certificates_types.cs를 어셈블리로 컴파일하고 거기에서 상수를 참조하여 CAPI 문제를 해결했습니다.

또한 이 작업을 수행하는 corefx에서 공개적으로 사용할 수 있는 것이 없기 때문에 전체 프레임워크(주로 16진수 인코딩/디코딩과 관련됨)에서 X509Utils.cs의 일부 메서드를 복사해야 했습니다.

남아 있는 유일한 문제는 src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SymmetricKeyWrap.cs(특히 34행)에 있으며 다음과 같은 오류가 발생합니다.

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

지금은 오류를 억제했습니다. 이제 모든 것이 컴파일됩니다. :)

좋습니다. 테스트 프로젝트를 제외하고는 다음과 같습니다.

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

내일 해결하겠습니다.

@karelz @bartonjs 변경 사항에 대해 논의할 수 있도록 PR을 열

나에게 좋은 소리. @steveharter 어떤 생각이 있습니까?

새해 복 많이 받으세요 =D

2단계가 언제 완료될지 알 수 있나요?

dotnet/corefx#14662가 이미 병합되었습니다. 2단계였습니다. 맨 위 게시물에 'checked'로 표시하겠습니다.

위의 5단계가 모두 완료되면 ASP.NET Core에서 ws-fed 지원을 받으려면 AAD 팀이 SAML 토큰 비트를 수행해야 하고 ASP.NET 팀은 ws를 빌드해야 합니다. -AAD 조각에 미들웨어를 공급했습니다. 당신의 기대와 일치합니까?

아니요, 이 작업은 WS-Fed와 아무 관련이 없습니다.
https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500에 대한 회신 및 설명이 필요합니다.

참고: 답변 게시됨: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

그렇다면 4단계는 언제 완료될까요?

.NET 팀이 언제 시간을 낼 수 있는지 묻는다면 우리는 아직 모릅니다. 그것은 우리의 백로그에서 높지만 먼저 해결해야 할 몇 가지 더 높은 우선 순위가 있습니다.

그 동안 우리는 커뮤니티에서 공간에 기여하는 데 열려 있습니다.

이 작업을 계속하게 되어 기쁩니다. 하지만 지금은 막막합니다. corefx가 새 빌드 프로세스로 이동했기 때문에 System.Security.Cryptography.Xml 는 더 이상 빌드되지 않습니다(그래서 @anthonylangsworth 와 저는 테스트 작성이 차단되었습니다). 프로젝트(및 테스트 프로젝트)를 빌드하는 데 관련된 사항에 대한 간단한 포인터를 얻을 수만 있다면 바로 진행할 수 있습니다. :)

추신. 빌드 프로세스를 20분 정도 추적하여 더 이상 빌드되지 않는 이유를 알아냈지만 아직 해결하지 못했습니다. 어떤 포인터라도 감사하겠습니다 ...

@mellinoe @weshaggard SignedXml을 새 빌드 시스템으로 마이그레이션하기 위한 지침을 제공해 주시겠습니까?

😭😭 기다려야 할 것 같아요 😭😭

@tintoy 현재 작업 중인 지점과 구축하려는 프로젝트를 알려주시면 구축하는 데 도움을 드릴 수 있습니다.

@weshaggard 현재 분기가 없습니다. 코드가 마스터에 있고 루트 빌드(의도적으로)에 연결되어 있지 않습니다. - src/System.Security.Cryptography.Xml(dotnet/corefx#14628에 도입됨). @steveharter 가 추가 정보를 제공할 수 있습니다.

@weshaggard @karelz 우리 포크에 분기를 만들고 우리를 차단 해제하기 위해 거기에 구축하게 해서 기쁩니다. 나중에 master 에서 다시 빌드되면 변경한 사항을 언제든지 체리픽할 수 있습니다. 이것이 선호하는 접근 방식인지 알려주십시오. :)

PR https://github.com/dotnet/corefx/pull/15491 에서 프로젝트 인프라가 작동해야 합니다. CI가 통과하면 병합할 수 있으며 노력을 부트스트랩해야 합니다.

감사합니다 - 나는 tintoy/corefx/master를 리베이스

@weshaggard ok, 그래서 src와 테스트 프로젝트가 모두 빌드되지만 테스트 프로젝트의 프로젝트 참조를 소스 프로젝트( <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> )에 추가하면 다음을 얻습니다.

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

프로젝트 간 참조가 corefx에서 작동하는 방식에 대해 뭔가를 놓친 것 같습니까?

@tintoy 그 오류가 구체적으로 무엇인지 확실하지 않지만 일반적으로 새로운 엔지니어링 시스템에서 ProjectReferences가 필요하지 않습니다. 테스트 빌드의 경우 항상 전체 타겟팅 팩을 빌드하고 참조합니다. 이 경우 bin\ref\netcoreapp 에서 생성됩니다. 해당 디렉토리에 있는 라이브러리는 현재 비어 있는 ref 폴더에서 빌드한 것입니다. 따라서 스스로 진행하려면 필요한 API 노출 영역으로 ref를 생성하고 ref 빌드를 가져와야 합니다. 그러면 테스트 프로젝트에서 자동으로 API를 확인하고 이에 대해 빌드할 수 있습니다. 다른 라이브러리를 기반으로 ref를 생성할 수 있는 genapi라는 도구가 있습니다. 다른 PR을 신속하게 제출하여 여러분을 위해 시드하도록 하겠습니다.

알겠습니다. 이제 알겠습니다. 테스트 프로젝트에 유형이 표시되지 않는 이유는 ref 프로젝트에 아직 유형이 없기 때문입니다 :-)

@weshaggard 시간이

나는 빠르게 genapi 도구를 실행하고 해당 커밋을 푸시했습니다 . https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e. 자유롭게 가져오거나 직접 재생성하십시오. 컴파일하려면 ProjectReference를 다른 참조에 추가해야 합니다.

건배 - 시간을 절약할 수 있습니다. 감사합니다.

@weshaggard 성공! 감사합니다. 이제 테스트를 작성할 수 있기를 바랍니다. :)

(tintoy @dd834c63af4fe40faf84bc6a776b474ec9947eb1 , 중복은 무시하세요)

네! 작동 테스트:

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

도와주셔서 감사합니다, @weshaggard!

추신. 테스트 프로젝트 속성(디버그 탭)에서 실행 경로를 로컬로 재정의해야 했습니다( .user 파일을 통해). D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe 이었지만 D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe 변경했을 때만 작동했습니다.

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

내 VS는 슬래시에 대해 불평하지 않습니다. 경로 구분자는 일반적으로 창과 유닉스 모두에서 작동하도록 하려고 하기 때문에 고통스럽습니다. 따라서 일반적으로 유닉스보다 더 수용적인 창에서 많은 혼합 슬래시를 보게 됩니다.

궁금해서 어떤 버전의 VS를 사용하고 있습니까? 2015년인가 2017년인가? 아마도 2017년에 수정되었을 것입니다 :)

(저는 요즘 OSX나 Linux를 주로 사용하기 때문에 크로스 플랫폼 친화적으로 만들려는 노력에 전적으로 감사드립니다. BTW)

Windows 10에서 VS 2015를 사용하고 있으며 솔루션을 열었으며 F5 키를 눌러 테스트를 디버그할 수 있으며 디버그 경로는 D:\git\corefx\Tools/testdotnetcli\dotnet.exe

좋아, 미쳐버릴 것 같아 - 이제 나도 재현할 수 없어!

이전에는 dotnet.exe 를 찾을 수 없다고 불평했지만 백슬래시만 있는 경로로 실행 파일을 명시적으로 설정하면 작동하기 시작했습니다. 방금 .csproj.user 파일을 제거했는데 _여전히_ 작동하므로 누가 알겠습니까 :-o

여러분, 테스트 작성에 참여하고 싶습니다. 기부를 시작하려면 어떻게 해야 하나요?

좋습니다. 이제 시작할 수 있는 단계에 있다고 생각합니다. :)

동료에게 첫 번째 테스트를 성공적으로 수행했는지 확인하겠습니다...

참조: @anthonylangsworth

@karelz ,

@anthonylangsworth 와 저는 테스트 작성 을

그리고 테스트를 돕기 위해 자원한 사람들(매우 감사합니다)을 위해 다음 주 초에 제안된 작업을 나눌 수 있는 위치에 있어야 합니다. :)

테스트 커버리지와 우리가 필요로 하는 테스트와 관련하여 - @bartonjs 는 위에서 언급했습니다).
그는 다음 주 말에 휴가를 마치고 돌아올 것입니다. 우리는 아마도 그와 세부 사항 및 기대치를 논의해야 할 것입니다.
또한 @AndersAbel 은 토론 초반에 사양 전문 지식과 잠재적인 도움을 언급했습니다.

@bartonjs가 OOF 동안 그는 추가 지침이있는 경우 @steveharter CC.

여기에 기여해 주신 @tintoy @anthonylangworth 에게 감사드립니다! 정말 감사합니다!
그리고 참여를 계획하고 있는 다른 모든 분들께도 감사드립니다 ;-)

@ bartonjs 가 OOF인 동안 추가 지침이 있는 경우 cc @ steveharter .

나의 호기심은 만족을 요구하는 지경에 이르렀다.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
이제 기분이 좋아졌습니다.

😃 이렇게 Microsoft 전용인지도 몰랐습니다! 재미있는 깨달음 감사합니다 😃

@anthonylangsworth 는 tintoy/corefx#3에서 대략적인 테스트 계획을 스케치하기 시작했습니다. (나는 그의 계획을 이슈에 복사해 댓글을 쉽게 달 수 있도록 했습니다.) 그래서 최소한 논의할 것이 있습니다. 자유롭게 살펴보고 피드백을 제공하세요. :)

CC: @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (또는 우려할 수 있는 모든 사람) 테스트에 InternalsVisibleToAttribute 를 사용하는 것에 대한 정책은 무엇입니까? 해당 네임스페이스 내에 많은 internal 클래스가 있으며 적절한 테스트 적용 범위를 얻는 것은 공개 메서드를 통해서만 진행하기 어려울 수 있습니다. 그러나 다른 고려 사항이 있음에 감사합니다.

흠, 슬프게도 잘 모르겠습니다 - @weshaggard @stephentoub? (이전 답변의 질문)

corefx의 다른 코드에서 본 것으로부터 문제의 프로젝트에는 다른 프로젝트의 관련 소스 파일이 포함되는 경우가 있습니다.

메모리에서 System.Collections.Immutable 는 [InternalsVisibleTo] 를 사용합니다. 도움이 되는 경우입니다.

예를 들어:

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

더 일반적으로:

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

이 오래된 문제 https://github.com/dotnet/corefx/issues/1604 에서 InternalsVisibleTo에 대한 내 생각을 볼 수 있습니다

테스트에 InternalsVisibleToAttribute를 사용하는 것과 관련된 정책은 무엇입니까?

아니요.

해당 네임스페이스 내에 많은 내부 클래스가 있으며 적절한 테스트 적용 범위를 확보하는 것은 공개 메서드를 통해서만 진행하기 어려울 수 있습니다.

깊은 예외 경로가 아닌 경우 도달하거나 삭제해야 합니다. 까다로운 테스트 케이스가 필요하다면 그것이 바로 우리가 필요로 하는 것입니다.

문제의 프로젝트에는 때때로 다른 프로젝트의 관련 소스 파일이 포함됩니다.

"테스트 프로젝트에 내부 구성원에 대한 액세스 권한을 얻기 위한 제품 소스가 포함되어 있음"을 의미한다고 가정하면: 아니요.

[InternalsVisibleTo] 및 소스 공유는 모두 상속된 전략입니다. 우리 중 가장 목소리가 큰 사람들은 (본질적으로) 우리의 테스트가 현실 세계에서 마주할 수 있는 것들만을 대표해야 한다고 믿습니다. 특정 블록에 대한 테스트가 불가능하다면 왜 존재합니까? 예, 스택의 더 높은 중복 검사가 이미 포착했기 때문에 적중할 수 없는 예외 발생 블록이 있습니다. 그러나 그것은 사실을 확인하고 OK라고 선언할 수 있는 것입니다.

따라서 사양 을 확인하고 모든 기능에 대해 긍정적인 테스트가 있는지 확인하는 것이 좋습니다(예: 지원하는 모든 알고리즘, 해당 알고리즘의 옵션에 대한 최소/최대 값의 경계 사례).

필수 요소를 제거하는 것과 같은 부정적인 테스트(예: SignedInfo 가 Signature 대한 필수 요소라고 4.1에 나와 있습니다 ... 누락된 경우 합리적인 예외를 내보내나요?)도 좋습니다.

<foo><!-- hi --></foo> 및 <foo></foo> (아마도 <foo /> ?)와 같은 Canonicalizer 옵션 테스트는 c14n 에서 동일하지만 c14n-withcomments 에서는 다릅니다. (정규화 알고리즘에 서명해야 하므로 두 가지 방식으로 서명한 다음 본문을 교환해야 할 수 있습니다.)

테스트를 변환합니다. 모든 canonicalizer는 변환입니다. 등.

탬퍼 테스트도 좋습니다. 그러나 성공적으로 변조하는 변조 테스트를 발견했다고 생각되면 여기에 보고하거나 github의 모든 담당자에게 커밋/푸시하지 마십시오([email protected]으로 test/case/description을 이메일로 보내기).

좋아, 나는 하루 동안 너무 많이 생각했다. 이제 휴가로 돌아갑니다.

휴가 중에 통찰력을 제공한 @bartonjs 에게 감사드립니다! 이제 현실 세계에서 즐거운 시간을 보내십시오 ;-)

@karelz @bartonjs (비록 휴가에서 돌아온 후에야 !)

@anthonylangsworth 는 토론을 시작하기 위해 몇 가지 초기 테스트 를 만들었 으며 지금까지

Mono에 SignedXml 테스트가 있다는 것을 알았습니다. 이것들은 xmldigsig 사양, @bartonjs가 앞서 언급한 제안, 현재 코드에 대해 평가하고 심사하여 이식할 가치가 있는지 확인해야 합니다. 이러한 테스트가 의미가 있는 경우 저작권(헤더) 정보에 대해 저에게 핑을 보내주십시오.

감사합니다. 살펴보겠습니다. :)

감사합니다, @steveharter . 링크를 제공할 수 있습니까? 이것들은 우리의 많은 테스트를 단축시킬 수 있습니다. 이를 그대로 복사하는 대신 확장하거나 구축하는 경우 저작권 또는 기타 고려 사항이 있습니까?

Mono에서 소스 코드를 복사할 때 @anthonylangsworth , 우리는 저작권 헤더를 유지하고 업데이트해야 합니다. 먼저 복사(올바른 헤더, 잠재적으로 약간의 조정 포함)만 수행하는 것이 좋습니다. CoreFX에 코드가 있으면 원하는 대로 코드를 수정할 수 있습니다.

@anthonylangsworth 모노 테스트 - https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.cs

감사합니다, @steveharter. 테스트를 NUnit에서 Xunit으로 변환 하기 시작했습니다.

나는 이것을 게시했지만 @anthonylangsworth 의 저장소에 있다는 것을 깨달았습니다.

Mono에서 코드를 가져올 때 저작권 헤더에 할 수 있는 마법은 다음과 같습니다.

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

이 프로젝트에 실패한 테스트가 있습니까?

@Jaedson33 현재 모노 테스트를 변환 중입니다. 아직 코드 오류를 나타내는 실패한 테스트를 찾지 못했지만 아직 수행해야 할 테스트가 많이 있습니다.

@anthonylangsworth 무엇을 도와드릴까요?

@ Jaedson33 https://github.com/tintoy/corefx/issues/6#issuecomment -280904587 에서 해당 질문에 답변했습니다. 요약하자면, 84개의 모노 테스트가 여전히 실패하고 있습니다(주로 변경된 기본값 및 .Net 핵심 제한으로 인해). 나머지 테스트가 작동하도록 도와주시면 감사하겠습니다. 그렇지 않으면 나는 그들을 통해 일하고 있습니다.

@karelz @bartonjs @steveharter System.Security.Cryptography.CryptoConfig 클래스 는 CoreFx 에서 많은 XML 변환이 지원되지 않는다고 명시합니다( DefaultNameHT 하단의 281~303행).

System.Security.Cryptography.Xml 네임스페이스의 클래스에서 사용하는 URI에 해당합니다. System.Security.Cryptography.Xml 를 .Net Core에 다시 추가하는 과정에서 이를 복원해야 한다고 가정합니다. 내가 틀렸다면 알려주세요.

CC: @tintoy

@anthonylangsworth , XmlDsigC14NTransform과 같은 일부 변환은 괜찮지만 XmlDsigXsltTransform과 같은 다른 변환은 매우 위험한 것으로 간주됩니다. 전체 .NET Framework에서 레지스트리 키 옵트인을 통해 활성화할 수 있지만 .Net Core에서는 지원하지 않는 것이 좋습니다. ForLedXml은 https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/ 에서 KnownCanonicalizationMethods 및 DefaultSafeTransformMethods를 살펴보십시오. 지원해야 하는 변환입니다.

나는 위험한 것들의 근원이 실제로 항구에 포함되었다는 것을 깨닫지 못했습니다. 나는 그것들을 완전히 제거하는 데 투표할 것입니다. 안전한 사용 방법은 없습니다.

@morganbr 알려 주셔서 감사합니다. RSA 및 DSA 키 값 XML 코드 변경이 완료되면 포함된 변환 목록을 검토하겠습니다. 나는 아마도 목록을 게시하고 당신과 다른 사람들에게 그것을 검토하도록 요청할 것입니다.

@anthonylangsworth 잘

@morganbr @AnthonyDGreen 이러한 변환(MS16-035 패치에서 비활성화됨)은 이전에 포트에 대해 논의할 때 이 스레드에서 논의되었습니다. @bartonjs 는 12월 14일에 reg-compat 항목을 제거해야 한다고 말했습니다. @steveharter 12월 15일 댓글도 참조하세요. 이러한 변환은 아마도 늦게 바인딩될 수 있으므로 이식되어야 합니다.

@steveharter @bartonjs 차임벨을

레지스트리 지원이 없더라도 CryptoConfig는 문자열 이름 또는 oid로 후기 바인딩된 변환을 생성할 수 있습니다. xml 내용을 기반으로 적절한 클래스를 만드는 데 사용되는 SignedXml 코드에서 'CryptoConfig'를 검색합니다.

이것은 적어도 netfx의 동일한 유형에 대해 이러한 변환을 지원하도록 CryptoConfig 클래스를 확장해야 하며 이상적으로는 Mono에 대해 상호 참조해야 함을 의미합니다. 그것은 그들을 포함하지 않고 CryptoConfig에 연결하지 않는 이유(내가 알지 못하는)가 없는 한입니다.

FWIW는 (corefx에 있는 것과 비교하기 위해) CryptoConfig의 netfx 버전입니다. https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs ,20d26e036bc718bc

.NET Framework에서 역호환을 위해 레지스트리 확장 가능한 "허용된 변환" 목록이 있습니다. .NET Core의 경우 확장할 수 없지만 입력 없는 변환만 포함하도록 하드 코딩되었습니다.

허용 목록에 없는 변환을 사용하여 문서의 유효성을 검사할 수 없기 때문에 변환을 이식하는 것이 합리적이지 않을 수 있습니다. 그러나 누군가 가 SIgnedXml의 컨텍스트 외부에서 변환을 사용할 수 있기 때문에(단지 범용 변환 엔진으로 사용하려는) 변환을 갖는 것이 좋을 수도 있습니다.

전체 유형을 제거하는 것에 대해 이야기할 것이기 때문에 .NET Framework와 불일치가 발생하지 않을 것입니다... 따라서 하드 코딩된 허용 목록에 없는 변환을 제거하는 것이 좋습니다. "패키지를 게시하기 전에 제거"는 나중에 변경할 수 있습니다. "게시"할 수 없습니다.

@bartonjs 가 저를 이겼습니다. CryptoConfig 에는 허용된 변환 목록이 포함되어 있습니다. 새 네임스페이스 System.Security.Cryptography.Xml 에서 변환을 허용하도록 해당 클래스를 수정해야 했습니다. 일부 허용된 변환은 .Net 클래스의 전체 이름을 사용하지만 CryptoConfig 여전히 고정 목록만 허용합니다.

알려진 보안 문제가 있는 변환을 이식하지 않는 것을 선호하지만 이전 버전과의 호환성도 중요합니다. 개발자를 대신하여 이 결정을 내려야 합니까? 개발자가 원하는 경우 새 변환을 추가할 수 있도록 일부 형식의 확장을 허용하도록 CryptoConfig 를 수정합니까? 이에 대한 결정을 내리는 방법은 무엇입니까?

CryptoConfig는 제한 요인이되지 않습니다 : https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SignedXml.cs#L763 - L787. (그러나 CryptoConfig가 여전히 해결을 위한 공장으로 사용되는 경우 변환이 두 위치 모두에 있어야 합니다.)

해당 목록에 없는 알고리즘을 제공하는 유형(표준화자도 아님)은 사실상 가치가 없습니다.

안전 목록에 대한 확장을 허용하려면 새로운 API가 필요하므로 기술적으로 이 노력의 범위를 벗어납니다.

저는 개인적으로 문서 검증에 사용할 수 없는 변환 유형을 생략하고 싶습니다. 그들은 테스트하기 어려울 것입니다.

실제로 CryptoConfig 및 DefaultSafeTransformMethods 모두 관련이 있습니다. SignatureDescription 생성은 CryptoConfig 지므로 DefaultSafeTransformMethods 의 값에 관계없이 CryptoConfig 언급되어 있지 않으면 변환을 사용할 수 없습니다. DefaultSafeTransformMethods 해당 목록을 제한하므로 변환이 XML에 지정되었지만 DefaultSafeTransformMethods 에서 반환되지 않은 경우 SignedXml.CheckSignature 는 false를 반환합니다.

현재 구현에서. CryptoConfig.AddAlgorithm 는 PlatformNotSupportedException 하므로 사용자는 자신의 것을 추가할 수 없습니다. 이 포팅 노력의 범위를 넘어서지만 이것을 살펴보거나 미래에 RemoveAlgorithm 를 추가할 가치가 있습니다.

이전 댓글 이후에 SignedXml.SignatureFormatValidator 속성을 찾았습니다. 이를 통해 사용자는 적절한 변환 및 해시 알고리즘을 지정할 수 있습니다. 호출자는 이를 사용하여 예를 들어 DefaultSafeTransformMethods 를 재정의할 수 있습니다.

내가 전에 물었듯이 여기서 누가 결정을 내립니까? "보안 전문가"로서 저는 안전하지 않은 옵션을 제외하는 것을 선호합니다. 그러나 이것이 발생할 수 있는 비호환성의 정도를 완전히 이해하지 못합니다.

@anthonylangsworth 이 토론은 의사 결정의 일부입니다. 가장 많은 배경지식을 가진 지역 전문가들이 여기에서 결정을 내릴 것입니다.

내 권장 사항: 올바른 조치가 무엇인지 의심스러운 경우 현재 상태를 유지하는 것이 좋습니다. 포트 연습 동안 코드를 그대로 두고(테스트 적용 범위 없이도 가능) 포트 연습과 별도로 나중에 결정합니다.

좋아, 그래서 내부적으로 몇몇 사람들과 이야기를 나눴고 계획의 비계가 있다고 생각합니다.

• 유형을 공개로 둡니다. (공개형이고, 제거하면 사람들이 슬퍼집니다.)
• 종단 간 SignedXml 테스트에서는 (아직) 사용할 수 없습니다. (사실, 음성 테스트는 좋은 것 같습니다)
• 그들은 단위 테스트에 충분해야 하는 공개 멤버가 있으므로 그렇게 해야 합니다.
  
  
  
  • 이는 나머지 변환 유형에도 적용됩니다.
  
  
• 어떤 이유로 입력을 수락하는 변환이 작동하지 않고 다른 모든 것이 정상이면 이에 대해 무엇을 해야 하는지 알아낼 수 있습니다. (이는 "충족할 수 없는 복잡한 컴파일 종속성이 있는 경우"에도 적용되지만 우리는 이미 그 장애물을 넘어섰습니다.)

그리고 이러한 유형이 작동할 수 있도록 API 또는 기타 구성이 제공되면 옵트인 E2E 테스트를 쉽게 추가할 수 있습니다.

@tintoy @anthonylangsworth @peterwurzinger 테스트 브랜치의 상태는 어떻습니까? 병합을 시작할 수 있습니까? 나는 당신의 테스트를 체리 선택하고 거기에서 계속 갈 수 있습니다.

https://github.com/dotnet/corefx/pull/16545 에서 PTAL도 가능합니까? MSDN 샘플 중 하나를 활성화했습니다.

안녕하세요 @krwq - 아직 실패하는 테스트가 있다고 생각하지만 일반 빌드 프로세스의 일부로 실행되지 않기 때문에 어쨌든 포함할 수 있습니다.

@anthonylangsworth 와 채팅하고 다시 연락드리겠습니다.

추신. dotnet/corefx#16545 -> :+1:

@krwq -

PR( @anthonylangsworth 에서 수행)을 열기 전에 dotnet/corefx#16545(내가 수행할 것)에 대해 리베이스해야 한다고 생각합니다.

이에 대한 준비가 되는 대로 연락드리겠습니다(길지 않기를 바랍니다).

@krwq @tintoy가 말한 것을 확장하기 위해 아직 해야 할 일이 많지만 기존 테스트를 이식하고 확장하는 작업도 많이 했습니다. 특히 언급한 많은 알고리즘을 처리하기 위해 이미 CryptoConfig.cs 을 변경했습니다. 우리 모두는 이것을 앞으로 나아가기를 원합니다. 또한 서로의 작업을 복제하거나 덮어쓰고 싶지 않습니다. 따라서 우리는 변경 사항을 그대로 병합하여 다른 사람들이 우리가 수행한 작업 위에 빌드하고 모든 버그를 찾고 모든 것을 더 빨리 마스터할 수 있도록 할 계획입니다.

@tintoy 는 https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests 작업 중인 유일한 분기입니까?

네.

잘 @krwq하는이 PR은 또한 https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests에서 하위 지점입니다 모노에서 물건의 좋은 금액 (와 ... ). 최신 코드에 관심이 있다면 그곳을 살펴봐야 할 것입니다. 내가 말할 수있는 한 ~ 40/340 테스트가 실패했습니다.

좋은 캐치, @peterwurzinger , 나는 우리가 이미 그것을 병합했다고 생각했습니다!

@peterwurzinger @anthonylangsworth 이 PR은 꽤 좋습니다! 나는 사실 그것을 놓쳤다. 그것을 당신의 브랜치, corefx에 병합하시겠습니까, 아니면 제가 선택하여 모든 병합/리베이스를 수행하기를 원하십니까? Mono 테스트에서 누락된 것이 있습니까 아니면 완전한가요? @anthonylangsworth - CryptoConfig 변경 사항에 대해 - @bartonjs 와 했습니다. - 우리는 해당 파일을 건드리지 않아야 합니다. 이미 충분히 추악합니다.

내 원래 계획은 MSDN에서 샘플을 몇 개 가져와서 모두 작동하도록 하여 조기 개밥을 시작할 수 있도록 하는 것이었습니다. 그 후에 나는 당신의 지점에서 테스트를 병합하고 수정할 것입니다. 일부 테스트가 실패하면 지금은 비활성화하고 나중에 수정할 수 있습니다. 최대한 빨리 corefx/master에 병합해 봅시다 :smile:

@krwq 업데이트 감사합니다. 가능하시면 최신 정보를 알려주세요. 우리가 목표로 하는 것을 아는 것이 도움이 됩니다.

안녕하세요 = D

실패한 테스트가 있습니까?

@Jaedson33 @anthonylangsworth @tintoy
다음은 (임의로) 가장 중요한 문제의 현재 목록입니다.
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@ Jaedson33 예, 현재 비활성화되어 있습니다. 위는 우리가 어디에 있는지 대략적인 아이디어를 제공해야합니다.

안녕하세요, 언제 오류가 없는지 알 수 있습니까?

@Jaedson33 모든 소프트웨어에는 오류가 있습니다 :wink: 작동하지 않는 특정 항목이 있습니까?

간단합니다: 내 UWP 프로젝트에서는 작동하지 않습니다 😞

안녕하세요, build.cml을 실행하려고 할 때 이 오류가 발생합니다. 도와주세요?

명령 오류:
C:\Users\jaeds\Source\Tools\msbuild.cmd /nologo /verbosity:minimal /clp:Summary /maxcpucount /nodeReuse:false /l:BinClashLogger,Tools\net46\Microsoft.DotNet.Build.Tasks.dll;LogFile =binclash.log /p:ConfigurationGroup=디버그 /p:BuildPackages=false /flp:v=normal /flp2:warningsonly;logfile=msbuild.wrn /flp3:errorsonly;logfile=msbuild.err C:/Users/jaeds/Source /Repos/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj /t:rebuild /p:Configuration=Debug /p:Platform=x64 /p:PlatformToolset =v141. => O sistema n├úo pode encontrar o arquivo especificado
종료 코드 1과 함께 명령 실행에 실패했습니다.
기본 구성 요소 빌드 프로젝트를 생성하지 못했습니다!
종료 코드 1과 함께 명령 실행에 실패했습니다.

@JaedsonBarbosa 개발자 명령 프롬프트에서 테스트를 실행하고 있습니까? (btw 이것은 약간 OT입니다) UWP의 경우 - 약속은 없지만 2.0에 대해 상당히 저렴하게 수행할 수 있는지 조사할 것입니다.

Visual Studio 2017용 개발자 명령 프롬프트에서 수행하고 있습니다.

@JaedsonBarbosa github에서 최신 변경 사항을 가져오고 repo( git clean -fdx )를 정리한 후 빌드해 보셨습니까 ? 두 번째로 시도해야 할 것은 경로 길이를 줄이는 것입니다(즉, 저장소를 C:\corefx 아래에 두십시오). 또 다른 시도는 너겟 캐시( %USERPROFILE%\AppData\Local\NuGet 및 %USERPROFILE%\.nuget )를 정리하는 것입니다.

그래도 문제가 계속 발생하면 정보와 함께 별도의 문제를 만드세요.

• 당신의 OS
• 당신의 VS 버전
• 당신이 한 정확한 단계
• 전체 로그(큰 경우 요점에 표시)

나는 C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj 경로가 유효하지 않다고 생각하기 때문에 발생한다고 생각합니다.

운영 체제: 윈도우 10
VS: 2017 커뮤니티
VS 2017용 개발자 명령 프롬프트를 시작하고 다음을 입력합니다.

cd C:/corefx
build

이제 오류는 다음과 같습니다.

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

"O sistema n├úo pode encontrar o arquivo"="시스템이 지정된 파일을 찾을 수 없습니다"

포기합니다. 2017 VS에서는 작동하지 않습니다.
이것이 언제 NuGet 패키지로 다운로드될 수 있는지 알고 있습니까?

myget.org에서 미리보기를 사용할 수 있어야 합니다.
공식 패키지는 .NET Core 2.0 웨이브의 일부가 됩니다. 마일스톤 2.0.0 설명을 참조하세요. 5월 10일은 ZBB(#17619)이므로 RTW 릴리스는 "곧" 뒤에 따라야 합니다(정확한 날짜는 아직 공개되지 않음).

@karelz System.Security.Cryptography.Xml이 포함된 패키지의 링크를 보내주시겠습니까?

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

dogfood 2.0 방법은 다음과 같습니다. https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

@karelz 좋아, UWP 클래스 라이브러리에 설치하고 싶지만 시도할 때 해당 오류가 발생합니다.

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

• monoandroid10 (모노안드로이드, 버전=v1.0)
• monotouch10 (모노터치, 버전=v1.0)
• netcoreapp2.0(.NETCoreApp, 버전=v2.0)
• uap10.1(UAP, 버전=v10.1)
• xamarinios10(Xamarin.iOS, 버전=v1.0)
• xamarinmac20(Xamarin.Mac, 버전=v2.0)
• xamarintvos10(Xamarin.TVOS, 버전=v1.0)
• xamarinwatchos10(Xamarin.WatchOS, 버전=v1.0)

내 실제 project.json입니다.

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

@JaedsonBarbosa , 우리는 현재 해당 라이브러리에 대해 UAP를 지원하지 않습니다. https://github.com/dotnet/corefx/pull/17969 가 병합되고 새 패키지가 생성될 때까지 기다려야 합니다.

😧 알았어 계속 기다릴게 😭
@krwq 근데... UAP10.1이 뭔가요???

@krwq 왜 지금 PR dotnet/corefx#17969를 병합하지 않습니까?

@JaedsonBarbosa 방금 병합되었습니다. 패키지가 내일 아침에 있어야 한다고 생각합니다. PR이 CI에서 녹색이 아닌 경우 일반적으로 병합하지 않습니다. 어제 이후로 OSX CI 문제가 발생하여 조금 오래되었습니다.

@krwq 변경 사항이 포함된 NuGet 패키지를 언제 다운로드할 수 있는지 알려

@JaedsonBarbosa 는 UWP의 .NET Standard 2.0 지원이 최첨단이라는 점에
어느 쪽이든 UWP에서 라이브러리를 사용하는 데 몇 가지 문제가 발생할 수 있습니다. 바로 도와드릴 수 있는 위치가 아닐 수도 있습니다. 5월 10일 이후에 더 많은 도움을 드릴 수 있을 것입니다. ... 단지 기대치를 설정하는 것뿐입니다.

@JaedsonBarbosa 는 2일 동안 새 버전을 생성하지 않은 것 같습니다 😞 여기에서 변경 사항을 확인할 수 있습니다.
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
4/6 이후에 패키지가 나타날 때마다 필요한 변경 사항이 있어야 합니다. 오늘 패키지가 없는 이유를 확인하겠습니다. OSX 빌드와 관련된 네트워킹 문제와 관련이 있을 수 있습니다.

편집: 확인 중 - 이것은 OSX 네트워킹 문제와 관련이 있습니다.

@krwq 오늘 OSX 네트워크 문제가 해결된다면 지금 하시겠습니까?

거의 모든 PR을 차단하므로 우선 순위가 높지만 ETA가 없습니다.

좋아요 👍
그래서 계속 기다리겠습니다.

파트 4는 언제 준비되나요?

@JaedsonBarbosa 우리는 이미 가장 중요한 부분을 테스트하고 작동하는 것으로 입증했습니다. 테스트에는 단일 "완료" 지점이 없습니다. 100% 코드 적용 범위와 작동하지 않는 코드가 있을 수 있습니다. 관심 있는 특정 시나리오가 있습니까?

아니 😃

@krwq 라이브러리를 안정적으로 배송할 수 있을 때 라이브러리에 대해 완료된 작업을 선언할 것으로 기대합니다. 그렇게 하면 상자를 선택하고 이 문제를 닫을 수 있습니다. 그렇다면 우리는 얼마나 테스트 현명합니까?

@karelz 나는 현재 내가 생각할 수 있는 모든 중요한 E2E 시나리오를 테스트했기 때문에 그대로 편안하게 배송하고 있습니다. 2.0 차단 문제를 찾을 것으로 기대하지 않지만 덜 인기 있는 시나리오(오류 처리 포함)도 올바르게 작동하는 것으로 입증될 수 있도록 여전히 적용 범위를 늘리고 싶습니다.

나에게 "완료"는 아무도 더 이상 라이브러리를 유지 관리하거나 개선하지 않는다는 것을 의미합니다.

좋습니다. @bartonjs 가 배송 준비 상태에 동의하면 실용적이고 이 문제를 종료하겠습니다.
테스트 커버리지를 늘리려면(비차단 2.0으로) Future에 대해 별도의 작업 항목을 만들어야 합니다.

알고리즘, 변환 및 정규화 목록에서 모든 것을 적중했다면 나에게 도움이 됩니다.

그래서 나는 이 문제가 마침내 종결될 것이라고 생각한다.

좋습니다. 다음을 통해 적용 범위 진행 상황을 추적해 보겠습니다. https://github.com/dotnet/corefx/issues/16829 - 저는 이것을 마스터 문제로 취급한다고 생각했습니다.

예, 우리는 그것을 마스터 문제로 취급하지만 때로는 작업을 완료했다고 선언해야 합니다. 그렇지 않으면 "더 많은 작업"을 추적하는 모든 더 큰 기능에 대해 1개의 미해결 문제가 발생합니다. 이는 진정으로 누구에게도 도움이 되지 않습니다.

지금은 문을 닫았습니다 😢
그래서... System.Security.Cryptography.Xml에 대한 질문은 어디에 해야 합니까?

위의 @krwq 의 답변으로 충분하지 않습니까?
더 큰 질문이 있는 경우 새 문제를 제출하세요. 이전 답변에 대한 작은 설명이라면 여기에 보관할 수 있습니다. 확실하지 않은 경우 여기에서 문의하고 최악의 경우 새 문제를 제출하도록 요청할 것입니다 ;-)

@krwq UWP 지원 없이 계속됩니다 😞

@JaedsonBarbosa 는 https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 이 작동하지 않습니까? 당신이하고있는 일의 단계를 보낼 수 있습니까?

@krwq 방금 그 명령을 넣었습니다.
설치 패키지 System.Security.Cryptography.Xml - 버전 4.4.0-preview1-25210-01

그것은 오류입니다:

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

• monoandroid10 (모노안드로이드, 버전=v1.0)
• monotouch10 (모노터치, 버전=v1.0)
• netcoreapp2.0(.NETCoreApp, 버전=v2.0)
• uap10.1(UAP, 버전=v10.1)
• xamarinios10(Xamarin.iOS, 버전=v1.0)
• xamarinmac20(Xamarin.Mac, 버전=v2.0)
• xamarintvos10(Xamarin.TVOS, 버전=v1.0)
• xamarinwatchos10(Xamarin.WatchOS, 버전=v1.0)

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

내가 이전에 말한 것을 상기시켜줍니다: https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
패키지와 함께 UWP 지원을 받을 수 없다고 생각합니다. 패키지는 .NET Standard 2.0 AFAIK에 의존하고 UWP는 아직 .NET Standard 2.0을 지원하지 않습니다. 이것은 우리가 .NET Core 2.1을 위해 작업할 것입니다(일부 비트는 5 이후에 작업할 더 큰 팀의 차단을 해제하기 위해 일찍 완료되었습니다. /10(완전히 작동하지는 않음).
패키지에 대한 UWP 지원을 얻으려면 IMO 2.1에서 기다려야 합니다.

@karelz 그럼 언제까지 기다려야 할 것
uap10.1 프로젝트를 생성할 수 있습니까?

예, 그때까지 기다려야 한다고 생각합니다.
당신이 과도하게 동기를 부여받고 이 모든 과속 방지턱을 통과할 수 없다면. 내가 말했듯이, 5/10까지 UWP를 도와줄 수 있는 우리의 능력은 매우 제한적 이므로 대부분 혼자가 될 것입니다 😦. 여기에 기대치를 설정하면 ...

Visual Studio 2017로 corefx-master를 빌드할 수 없기 때문에 기다리겠습니다 😞

@karelz @krwq 오류가 발생하여 솔루션을 빌드할 수 없습니다. 여기에서 CMakeError를 볼 수 있습니다.
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
도와주세요 🆘
추신: 포르투갈어로 되어 있지만 번역기를 사용하여 읽을 수 있습니다 😄

실패한 것은 좋지 않다고 생각합니다.
-- C 컴파일러 식별은 MSVC 19.0.24218.2입니다.
-- CXX 컴파일러 식별은 MSVC 19.0.24218.2입니다.
-- 작동하는 C 컴파일러 확인: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe
-- 작동하는 C 컴파일러 확인: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe -- 작동
-- C 컴파일러 ABI 정보 감지
-- C 컴파일러 ABI 정보 감지 - 완료
-- 작동하는 CXX 컴파일러 확인: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe
-- 작동하는 CXX 컴파일러 확인: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe -- 작동
-- CXX 컴파일러 ABI 정보 감지
-- CXX 컴파일러 ABI 정보 감지 - 완료
-- CXX 컴파일 기능 감지
-- CXX 컴파일 기능 감지 - 완료
-- COMPILER_HAS_DEPRECATED_ATTR 테스트 수행
-- COMPILER_HAS_DEPRECATED_ATTR 테스트 수행 - 실패
-- COMPILER_HAS_DEPRECATED 테스트 수행
-- COMPILER_HAS_DEPRECATED 테스트 수행 - 성공
-- 구성 완료
-- 생성 완료

누구든지 이제 그것을 구축하기 위해 무엇을 할 수 있습니까?

@JaedsonBarbosa 어떻게

1. cmd.exe를 엽니다.
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - 남은 파일의 저장소를 정리합니다(무엇을 하는지 잘 모르는 경우 주의하십시오)
5. Windows가 아닌 경우 build 또는 ./build.sh

기본 구성 요소를 빌드하려면 CMake 2.8.12 이상을 설치해야 합니다.

이것은 항상 나를 위해 일했습니다.

@Jaedson33 또한 새로운 기여자 문서를 확인하고 개선하는 데 도움을 줄 수 있습니다(CoreFX 메인 페이지에서 링크됨)

CMake 3.8을 사용하고 있습니다.
@krwq 말씀하신대로 하고 1시간정도

@JaedsonBarbosa 몇 분 정도 걸릴 것입니다. 다시 시작해 보세요. 일부 연결 문제일 수 있습니다. 작동하지 않으면 이 리포지토리에 별도의 문제를 제출하세요. 누군가 무슨 일이 일어났는지 추적할 수 있어야 합니다.

@krwq 이 오류가 발생합니다.

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

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

@JaedsonBarbosa 위에서 제안한 대로 새 문제를

@karelz 이제 작동 중입니다 😄
빌드하기 위해 내가 한 유일한 생각은 파일을 C:\Users\jaeds\Source\Repos\corefx-master에서 C:\Users\jaeds\Source로 옮기는 것뿐이었습니다.
README에 있어야 한다고 생각합니다.

안녕하세요, 이제 샘플 앱인 UWP 앱에서 이 패키지를 사용할 수 있습니다. https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

@JaedsonBarbosa 대단해! CoreFX로 되돌아가는 데 가치가 있는 작업이 있습니까? (즉, 일시적인 해킹이 아닌 것)

@karelz 글쎄, 내 프로젝트를 사용하여 CoreFX에서 무엇을 단순화(또는 제거)할 수 있는지 확인할 수 있다고 생각합니다 😄

안녕하세요 여러분, 이것을 이식하는 데 많은 노력을 기울이고 있습니다!

Nuget 패키지가 .NET Standard 2.0 대신 .NET Core 2.0을 참조하는 이유를 여쭤봐도 될까요? 그게 바람직하지 않을까요?

했어야 했다 (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

Nuget의 공식 미리 보기를 보고 있는 것 같습니다.
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

Myget에만 있습니다.
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

네, 제가 찾고 있었던 것입니다. @danmosemsft 감사합니다!

@leopignataro 문제 없습니다. "head"에서 비트를 시도하는 것이 좋습니다. https://github.com/dotnet/cli 의 홈페이지에서 다운로드할 수 있습니다. 원하는 경우 zip을 다운로드할 수 있습니다. 문제를 발견하면 알려주십시오. 출시 전에 문제를 해결할 수 있는 시간이 얼마 남지 않았습니다.

참고: 타임라인에 대한 정보는 다음과 같습니다. https://github.com/dotnet/corefx/issues/17619#issuecomment -301937346

@danmosemsft 님이 언급

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

스레드에 대한 수정 사항을 제안했지만 모든 소문에서 내 메시지가 누락되었을 수 있습니다.

@leopignataro 무엇을 위해 수정합니까? dotnet/corefx#19198에 대한 수정 사항인 경우 버그에서 추적해야 합니다. 다른 문제라면 별도의 문제를 보는 것이 좋습니다.
수정 제안이 어딘가에서 간과되었다고 생각되면 해당 스레드에서 다시 제기하고 피드백을 요청하십시오.

나는 지금 혼란스럽다. System.Security.Cryptography.Xml NuGet 패키지는 .NET Framework용이며 이미 Dot Net Core v2에 포함되어 있다고 생각했습니다. Dot Net Core v2에서 이 네임스페이스를 인식하지 못합니다. 제가 잘못 들은 건가요? 감사 해요.

@fletchsod-developer 패키지는 주로 .NET Core용입니다. 그러나 .NET Standard를 대상으로 하는 라이브러리에서 참조하는 경우 .NET Framework의 .NET Framework 버전과 통합되고 .NET Core의 패키지 내에서 코드를 실행합니다.

SignedXml을 .NET Core의 기본 설치 환경에 넣을 계획은 없습니다. NuGet에서 별도의 패키지가 되는 것이 최고의 배포 모델로 보일 정도로 틈새 시장입니다.