Runtime: System.Security.Cryptography.Xml.SignedXml-Klasse hinzufügen

Wie von Tratcher erwähnt, ist dies ein Blocker für das Hinzufügen von Unterstützung für WsFederation/ADFS in ASP.NET 5. Wir verwenden ADFS ausgiebig für viele ASP.NET 4-Unternehmensanwendungen. Wir sind sehr daran interessiert, zu ASP.NET 5 zu migrieren und WsFederation zu verwenden.

@rschiefer @Tratcher Nun, es ist... kompliziert.

• ADFS verwendet nicht System.Security.Cryptography.Xml.SignedXml; sondern eine eigene Implementierung.
  
  
  
  • (Das liegt hauptsächlich daran, dass man mentale Spinnweben abstaubt und sich daran erinnert, für Version 1 von ADFS in diesem Team zu sein.)
  
  
• System.IdentityModel verwendet definitiv nicht System.Security.Cryptography.Xml
  
  
  
  • (Das liegt daran, dass ihr Quellcode auf referencesource das sagt :smile:)
  
  
• Die Leute mögen System.Security.Cryptography.Xml.SignedXml nicht wirklich, weil es auf XmlDocument basiert, was zu einigen Leistungsproblemen führt.
  
  
  
  • Die ADFS-Version basierte auf XmlReader, IIRC.
  
  
• Was die Leute wahrscheinlich wollen, ist also CoreFX, um eine neue Implementierung von SignedXml zu erstellen.
• Aber eine neue Version von SignedXml ist nicht mit der alten Version von SignedXml kompatibel
• Einige Leute möchten vielleicht, dass wir auch die alte Version behalten.
• Alles in allem wollen die Leute also wirklich zwei Versionen.
• Außer sie wollen nicht die alte Version.
• Außer wenn sie es tun.

Wir bleiben also mit dem Rätsel:

• Wir können diese Klasse portieren, die niemand wirklich will
• Oder wir können aufhören und ein brandneues Ding entwerfen, das wahrscheinlich niemand verwenden wird, da es mit nichts anderem kompatibel sein kann
• Oder, um den größten Aufwand zu betreiben und trotzdem niemandem zu nützen, tun Sie beides : smile:.

@terrajobst - fyi

Anscheinend war ich heute Morgen ein bisschen ausschweifend. Es tut uns leid :).

Wir haben definitiv festgestellt, dass hier noch viel zu tun ist, aber wir glauben nicht, dass die richtige Antwort darin besteht, den vorhandenen System.Security.Cryptography.Xml-Code weiterzuentwickeln. Stattdessen stellt dies den Punkt in unserem Backlog dar, eine universelle Implementierung für XmlDSig zu entwickeln, die schnell ist und nicht an Legacy-Objektmodelle (zB XmlDocument) gebunden ist.

Diesen Aufwand erwarten wir für .NET Core 1.0 nicht, einfach weil wir uns auf andere Dinge konzentrieren.

Wenn Sie uns jedoch mitteilen, dass Sie von der fehlenden Funktionalität betroffen sind, hilft dies bei der fortlaufenden Priorisierung.

Ich möchte eine ASP.NET Core SAML2-Middleware erstellen, die auf https://github.com/KentorIT/authservices basiert

Ich stimme definitiv zu, dass es eine gute Idee ist, das bestehende nicht zu übertragen. Wäre es möglich, alles basierend auf einer XmlReader-API zu tun? Auf diese Weise können sowohl XDocument als auch XmlDocument unterstützt werden. Es wäre auch schön, eine Implementierung des in System.IdentityModel verwendeten umhüllten Readers bereitzustellen (wenn er verbessert würde, um XML-Dateien mit Leerzeichen zu unterstützen ...)

@AndersAbel XmlReader ist der Ausgangspunkt, ja (es sei denn, die XML-Leute sagen mir, dass es etwas Besseres gibt).

Da XmlReader auf dem die System.IdentityModel-Variante basiert, sollte es machbar sein :).

@bartonjs Die System.IdentityModel-Variante ist jedoch in Bezug auf die Transformationen, die sie verarbeiten kann, ziemlich eingeschränkt. Für SAML2/WS-Fed-Arbeit wäre dies kein Problem, aber als allgemeine API muss berücksichtigt werden, wie mit nicht umhüllten Signaturen und XML mit verschachtelten Signaturen umgegangen wird (z. B. eine signierte Saml-Antwort mit signierten Assertionen). Ich denke auch, dass der System.IdentityModel.EnvelopedSignatureReader die Daten kopiert, wenn er die Validierung durchführt. Da kann man viel Spaß haben. Wenn ich die Zeit hätte, würde ich gerne daran arbeiten.

Ich schätze das weitläufige @bartonjs , das hilft, zu sehen, was hinter den Kulissen vor sich geht.

Aktuell ist mein Unternehmen davon betroffen. Wir haben einen Legacy-Code, den wir auf .NET Core zu portieren versuchen, der signierte XML-Lizenzdateien generiert, und ohne diese Klassen stecken wir fest. Wir sind offen dafür, von XML-Dateien als Basis für die Lizenzen abzuweichen, aber bis jetzt haben wir keine gute Lösung gefunden, die unseren Anforderungen entspricht.

Ich freue mich darauf, dass dies in Zukunft hinzugefügt wird.

Ich kann bestätigen, dass dies (und auch die etwas verwandte XML-Verschlüsselung) für uns relevant ist. Das vorhandene Formular in .NET Framework wäre in Ordnung - hier besteht aus meiner Sicht kein Innovationsbedarf. Copy & Paste-Implementierung wäre sehr willkommen!

Gibt es derzeit einen Workaround?

Würde auch gerne wissen, was @sandersaares gefragt hat. Gibt es jetzt keine eingebaute Möglichkeit, XML in CoreFX zu signieren?

@sandersaares / @af0l : Für .NET Core 1.0 gibt es keine integrierte Implementierung von SignedXml/XmlDSig.

Aufgrund der Kommentare hier (und anderer) werden wir wahrscheinlich nur die alte API übernehmen, aber wir hatten keine Zeit, dies für 1.0 umzusetzen.

Danke @bartonjs , das muss der Grund sein, warum ich unser Projekt nicht dazu bringen konnte, an Core zu arbeiten. :) Es ist auch sehr schade, denn ich würde gerne weitermachen und kann nicht, bis es fertig ist. Wir müssen alle Zahlungen mit signierten XML-Dateien an unsere Steuerbehörde melden, also ist es wirklich ein Showstopper.

Gibt es diesbezüglich Fortschritte? Ich stecke bei der SAML-Token-Validierung fest, die diese Funktion erfordert. Vielen Dank

Ja, würde das auch gerne wissen. Am Ende haben wir die Funktionen extrahiert, die die Signatur benötigen, und sie in eine separate Web-API-Lösung eingefügt...

Sie haben bereits eine Vorstellung davon, welche Version oder Lösung implementiert wird

An dieser Stelle scheint die einfachste Antwort darin zu bestehen, die vorhandene .NET Framework-Implementierung auf .NET Core zu portieren. Wir fassen dies also mit anderen API-Auslassungen zusammen, die das Portieren erschweren.

Möglicherweise relevant für das Thema: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently und https://github.com/sandersaares/ xml-c14n-whitespace-defekt. Mir scheint, dass die .NET Framework-Implementierung von Canonical XML 1.0 falsch ist. Ich hoffe, ich liege falsch, aber wenn ja, könnte dies einige haarige Kompatibilitätsfragen aufwerfen.

@sandersaares Sie haben sich Ihr Beispiel angesehen und müssen beim Lesen der XmlDocument.PreserveWhiteSpace = true festlegen, wenn sie Leerzeichen enthält.

@AndersAbel Danke für den Hinweis! Das ändert die Situation und ermöglicht tatsächlich eine konforme Validierung, wenn ein XML-Schema vorhanden ist. Ohne ein XML-Schema bleibt das Verhalten ungültig (auf eine neue und aufregende Weise). Ich habe das Connect-Problem und das GitHub-Repository entsprechend aktualisiert.

@bartonjs Wenn Sie die vorhandene .NET-Framework-Lösung portieren, beheben Sie bitte den Fehler, der die Überprüfung mehrerer Signaturen verhindert: https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

Zu Ihrer Information, wenn dies in die Implementierungsphase gelangt, habe ich hier eine frisch erstellte Bibliothek mit Tests, die XML-Signaturen (sowohl Signieren als auch Verifizieren) und andere XML-Funktionen in .NET Framework verwendet - könnte nützlich sein, um eine Abhängigkeitsfreiheit zu erhalten -Weltcode zum Ausprobieren der Implementierung gegen: https://github.com/Axinom/cpix

Gibt es einen Zeitplan für die Entwicklung dieser API?

//cc @bartonjs

@henkmollema Nichts Bestimmtes, nein. Für die Version 1.2 arbeiten wir daran, die Lücke zwischen .NET Framework und .NET Core zu schließen. und dieser Aufwand ist der Ursprung von SignedXml.

Ich hatte heute einen Kundenanruf, der SAML2-P-Unterstützung auf ASP.NET Core benötigt (wobei die Implementierung von KentorIT verwendet würde). Dies ist ein blockierendes Problem für Kunden, die zu ASP.NET Core wechseln möchten. Mein Kunde muss vorerst auf Katana bleiben.

Ich sehe, dass der Meilenstein von 1.2 auf Future geändert wurde (von @bartonjs). Kannst du kommentieren oder präzisieren?

Hauptsächlich hat es damit zu tun, wie wir Meilensteine ​​verfolgen. Früher machten wir mehr von "wir hoffen, dass es das schaffen wird", dann haben wir am Ende des Meilensteins alles neu zugewiesen, was nicht getan wurde. Wir versuchen jetzt wirklich zu sagen: "Wenn wir es für diesen Meilenstein markiert haben, sollte es sehr selten sein, dass es neu zugewiesen wird".

Dies ist eine Menge anderer Arbeit für den 1.2-Meilenstein nachgelagert, und es war (für mich jedenfalls) immer ein bisschen mühsam, es für 1.2 zu schaffen. Es steht immer noch ziemlich weit oben auf unserer "What's next"-Liste, wir "verpflichten" uns nur nicht, dass es Teil der Version 1.2 ist (die hauptsächlich Netstandard2.0-Arbeit, Bugfixing und ein paar Infrastrukturprojekte umfasst).

Das Markieren als Zukunft garantiert nicht, dass es nicht Teil der Version 1.2 sein wird, es bedeutet nur (in unserer aktuellen Interpretation von Meilenstein), dass wir die Veröffentlichung nicht dafür halten. Sobald jemand tatsächlich daran arbeitet, kann man besser verstehen, wann es tatsächlich fertig wird, und dann wird es als der Meilenstein markiert, in dem es tatsächlich veröffentlicht wird.

@karelz Wenn Sie etwas hinzufügen (oder korrigieren) möchten, können Sie sich gerne

Wir werden die Arbeit im Zeitrahmen von 1,2 nicht finanzieren können (es gibt einfach zu viele andere Dinge mit größerer Wirkung, um sie fertigzustellen). Aus diesem Grund haben wir es auf den zukünftigen Meilenstein verschoben, um unsere Pläne zu kommunizieren.
Die Anzahl der Anfragen ist uns bekannt, deshalb ist sie in unserem Sicherheitsbereich hoch im Rückstand. Es ist auch eine der am häufigsten gefragten Corefx fehlenden APIs im Allgemeinen (unter DirectoryServices, SerialPort usw.).

cc: @steveharter @danmosemsft @terrajobst

Unsere Antworten haben sich gekreuzt :)
Mehr Kontext zu Milestones finden Sie in unserem Issue Guide .

Der .NET Framework-Code steht als Referenzquelle zur Verfügung. Technisch gesehen kann die Portierung also auch außerhalb des .NET Core-Teams initiiert werden - wenn Leute interessiert sind, uns hier zu helfen.
Aus meinen früheren Chats mit @bartonjs denke ich, dass die wichtigste "Herausforderung" das Erstellen/Portieren von Tests sein wird.

Hey, wie ist die aktuelle Situation bei diesem Problem?

@Jaedson33 was meinst du mit 'Problem'? Wenn Sie meinen, wann es behoben sein wird, sehen Sie sich die Antworten von letzter Woche an.

@karelz Aber ich will nicht warten. Warum reparierst du es jetzt nicht?

@Jaedson33 siehe meine Antwort oben - es erklärt, warum wir es jetzt nicht finanzieren können. Es geht um Prioritäten. Es gibt eine Reihe von Leuten, die jetzt viele Funktionen/APIs wollen, aber wir haben kein unendlich großes Team, also müssen wir Prioritäten setzen.

Wenn Sie es so schnell wie möglich wirklich dringend brauchen, können Sie jederzeit zur Codebasis beitragen. Wir helfen Ihnen gerne mit Anleitungen, Code-Reviews und Feedback.

Okay, also warte ich.

@karelz Wenn die Originaltests noch verfügbar sind, um die Arbeit zu überprüfen, wäre ich bereit, meine Hand zu

(einer meiner Kollegen hat auch einschlägige Erfahrung, also würden wir wahrscheinlich zusammen daran arbeiten)

Ein wesentlicher Teil der Arbeit besteht darin, neue Test-Assets zu erstellen. Die alten Tests sind unzureichend und haben eine schlechte Abdeckung. Wir werden jemanden brauchen, der die Spezifikation überprüft und Tests für jede interessante Anforderung hinzufügt – dort fallen die meisten Kosten an.

Wenn Sie weiterhin interessiert sind, können wir versuchen, den Quellcode aus dem vollständigen .NET Framework unverändert einzufügen. Der nächste Schritt besteht darin, ihn zu erstellen und eine Testabdeckung hinzuzufügen, bevor er als Teil von .NET Core veröffentlicht werden kann. Melde mich bei Interesse...

Ok, ja - wir sind immer noch interessiert :)

@tintoy Ich bin daran interessiert, dir zu helfen, weil ich diesen

@tintoy Ich bin daran interessiert, dir zu helfen, weil ich diesen

Froh das zu hören :)

Also... Wie kann ich helfen?
Obs: Es ist das erste Mal, dass ich GitHub verwende.

Also... Wie kann ich helfen?

Lassen Sie mich zuerst mit meinem Kollegen plaudern und wir entwickeln einen Angriffsplan. @karelz - hineinwaten ? Für den Anfang vermute ich, dass mein Kollege wahrscheinlich in den Standard einsteigen wird, ich werde mir wahrscheinlich überlegen, wohin der Code gehen muss (und was dazu gehört, vorhandene Tests aus anderen Teilen des Frameworks zum Ausführen zu bringen, bevor wir sie erstellen irgendwelche Veränderungen). Klingt das vernünftig?

CC: @anthonylangsworth

Um den Umfang etwas eingeschränkt zu halten, würde ich empfehlen, ohne die Funktionen zu beginnen, die von MS16-035 deaktiviert sind (xpath-Transformation, xslt-Transformation, externe Referenzen). Ich weiß nicht, welchen Raum es für Breaking Changes gibt, aber der aktuelle Fallback-Mechanismus in DefaultGetIdElement kann bei Signatur-Wrap-Angriffen ausgenutzt werden. Ich würde eine sicherere Standardversion bevorzugen.

Es wäre auch gut, wenn die interne API etwas umstrukturiert würde, um den von System.IdentityModel verwendeten EnvelopedSignatureReader zu unterstützen, anstatt zwei separate Implementierungen der XML-Signaturvalidierung zu haben.

Schließlich möchte ich auch, dass ein einzelner Punkt gemäß diesem Fehlerbericht hinzugefügt wird.

@tintoy Ich glaube nicht, dass wir gute Dokumente haben. Ich denke, wir sollten die Quellen hinzufügen und dann können wir die Arbeit parallelisieren - lassen Sie mich mit @bartonjs @steveharter @ianhays synchronisieren.

Ich werde auch versuchen, etwas Zeit zu finden, um zu helfen. Wenn es Fragen zur Spezifikation und ihrer Funktionsweise gibt, schaue ich mir das gerne an - ich habe bereits einige Zeit damit verbracht, die Spezifikation zu überprüfen.

Hat jemand etwas zu der Idee zu sagen, SignedXml und den von System.IdentityModel verwendeten EnvelopedSignatureReader zu konsolidieren?

@AndersAbel

Starten Sie ohne die von MS16-035 deaktivierten Funktionen (xpath-Transformation, xslt-Transformation, externe Referenzen)

Wir sollten mit dem neuesten .NET Framework-Quellcode beginnen, der sicher sein sollte. Wenn Sie Bedenken hinsichtlich der Sicherheit des .NET Framework-Codes haben, teilen Sie uns dies bitte offline mit.

Ich weiß nicht, welchen Raum es für Breaking Changes gibt

Kein Platz, wir sollten mit einer einfachen Portierung von .NET Framework beginnen. Alle weiteren Verbesserungen, Änderungen, Breaking Changes usw. können später berücksichtigt werden. Nicht als Teil der anfänglichen Arbeit. Sonst wird es uns über den Kopf wachsen.

Der aktuelle Fallback-Mechanismus in DefaultGetIdElement kann bei Signatur-Wrapping-Angriffen ausgenutzt werden

Das sollte als separates Problem behandelt werden. @bartonjs kannst du bitte kommentieren?

Es wäre auch gut, wenn die interne API etwas umstrukturiert würde, um den von System.IdentityModel verwendeten EnvelopedSignatureReader zu unterstützen, anstatt zwei separate Implementierungen der XML-Signaturvalidierung zu haben.

Nehmen wir es wieder als nächsten Schritt, nachdem wir einen voll funktionsfähigen Port mit guter Testabdeckung haben.

Schließlich möchte ich auch, dass gemäß diesem Fehlerbericht ein einzelner Punkt hinzugefügt wird.

Bitte reichen Sie es als separate Ausgabe hier auf GitHub ein. Idealerweise, nachdem wir den Code hier portiert haben (dh wenn der Fehler wirklich auf .NET Core anwendbar ist).

Hat jemand etwas zu der Idee zu sagen, SignedXml und den von System.IdentityModel verwendeten EnvelopedSignatureReader zu konsolidieren?

Möchte es nur wiederholen. Wir sollten es als nächsten Schritt behandeln, nach der Portierung.

Der aktuelle Fallback-Mechanismus in DefaultGetIdElement kann bei Signatur-Wrapping-Angriffen ausgenutzt werden

Das sollte als separates Problem behandelt werden. @bartonjs kannst du bitte kommentieren?

@AndersAbel Wenn Sie der Meinung sind, dass ein Sicherheitsproblem besteht, befolgen Sie bitte das Verfahren zur Meldung von Sicherheitslücken unter https://technet.microsoft.com/en-us/security/ff852094.aspx.

Hat jemand etwas zu der Idee zu sagen, SignedXml und den von System.IdentityModel verwendeten EnvelopedSignatureReader zu konsolidieren?.

Es ist wahrscheinlich nicht möglich. SignedXml basiert sehr stark (und Public-API-ally) auf dem Rich-DOM XmlDocument. Die Darstellung von IdentityModel basiert auf XmlReader. Aber sobald das vorhandene Zeug herübergebracht ist, kann es untersucht werden.

Ich werde auch versuchen, etwas Zeit zu finden, um zu helfen. Wenn es Fragen zur Spezifikation und ihrer Funktionsweise gibt, schaue ich mir das gerne an - ich habe bereits einige Zeit damit verbracht, die Spezifikation zu überprüfen.

@AndersAbel -

@bartonjs Ich habe diese Probleme an [email protected] gemeldet , was zu MS16-035 führte. IMO gibt es jedoch noch einige riskante Probleme, die MS nicht beheben wollte (sie würden zu bahnbrechenden Änderungen führen). Ich habe die Details noch nicht veröffentlicht, aber wenn Sie sie privat besprechen möchten, senden Sie mir bitte eine E-Mail.

@karelz Vielen Dank, dass Sie

Starten Sie ohne die von MS16-035 deaktivierten Funktionen (xpath-Transformation, xslt-Transformation, externe Referenzen)

Wir sollten mit dem neuesten .NET Framework-Quellcode beginnen, der sicher sein sollte. Wenn Sie Bedenken hinsichtlich der Sicherheit des .NET Framework-Codes haben, teilen Sie uns dies bitte offline mit.

Der Patch MS16-035 behebt eine Reihe von Problemen in SignedXml. Es ist jedoch möglich, Registrierungsschlüssel zu verwenden, um zum alten, unsicheren Verhalten zurückzukehren. Sollten diese Optionen auch auf .NET Core portiert werden? Mein obiger Vorschlag sollte die Portierung des aktuellen Standardverhaltens von .NET Framework priorisieren und die Teile, die standardmäßig deaktiviert sind, vorerst zurücklassen. Oder meinst du, dass diese Teile auch wichtig sind, um verschoben zu werden? Dann stellt sich die Frage, wie die Konfiguration gehandhabt wird, da .NET Core AFAIK für die Konfiguration nicht auf die Registrierung angewiesen ist (da sie nicht auf allen Plattformen verfügbar ist).

Es ist jedoch möglich, Registrierungsschlüssel zu verwenden, um zum alten, unsicheren Verhalten zurückzukehren. Sollten diese Optionen auch auf .NET Core portiert werden?

Nein. Nur-Registrierungscode wird gelöscht, bevor das Paket zur Verfügung gestellt wird.

Warum erstellen Sie kein Projekt auf GitHub, um das zu implementieren?

Wir haben mit @bartonjs , @steveharter und @ianhays synchronisiert

BEARBEITEN: Der Ausführungsplan wurde in den obersten Posten verschoben.

Klingt gut für mich :)

@karelz , @steveharter Die meisten Registry-Lookups befinden sich in der Utils- Klasse: AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier . Es gibt auch eine Suche in der SignedXml-Klasse, in der die Liste der bekannten Transformationen eingerichtet wird. Ohne die Registrierungskompatibilität glaube ich nicht, dass auf die XmlDsigXPathTransform und XmlDsigXsltTransform zugegriffen werden kann. Sollen sie zusammen mit dem Registry-Compat-Code komplett aus der Quelle entfernt werden?

Das sind die, die ich kenne, ich habe beim Lesen des Codes keine anderen gesehen, aber vielleicht habe ich etwas übersehen.

@AndersAbel Ich habe Karels obigen Kommentar zur Registrierung aktualisiert. Wenn Klassen nicht zugänglich sind, müssen wir verstehen, welche Funktionalität verloren geht. Für diejenigen, die Sie erwähnen, muss CryptoConfig meiner Meinung nach das Name:Objekt- Paar für diese hinzufügen und kann daher spät erstellt werden

Wann denkst du, wird dieser Kurs fertig sein?

Meinst du für Beiträge? @steveharter plant, die erste "Quellen hinzufügen"

Der ursprüngliche Code wurde gerade zusammengeführt.

@steveharter Danke 😃

Danke @steveharter! Ich habe den Ausführungsplan in den obersten Beitrag verschoben, um die Fortschrittsverfolgung zu erleichtern. Wann immer wir Änderungen daran vornehmen, werden wir die Änderungen hier in einer anderen Antwort erwähnen.

Wenn jemand anfangen möchte, daran zu arbeiten, sagen Sie dies bitte, um doppelte Arbeit zu vermeiden. Wir werden Ihnen die Ausgabe gemeinsam zuordnen.

@karelz : @tintoy und ich haben unsere Hände hochgelegt, um damit anzufangen . Gerne, wenn Sie es uns zuweisen.

Wenn jemand anfangen möchte, daran zu arbeiten, sagen Sie dies bitte, um doppelte Arbeit zu vermeiden. Wir werden Ihnen die Ausgabe gemeinsam zuordnen.

Cheers - ich freue mich, einen Anfang machen zu können, um es zu kompilieren :)

@anthonylangsworth - hah, schlag mich!

Hier wird gearbeitet .

@tintoy zugewiesen. Ich werde es auch @anthonylangsworth zuweisen, sobald er den Mitwirkendenstatus für das Repo akzeptiert (GH wird Ihnen ohne diese keine Option als Bevollmächtigter anbieten).

Vielen Dank!

@karelz nur zur Bestätigung - nach dem, was ich von den Richtlinien für Mitwirkende verstehe, soll ich diese Änderungen in master vornehmen?

(meine master natürlich)

Äh, Entschuldigung, lassen Sie es mich noch einmal versuchen - die eventuelle PR gegen Ihre master ?

Ja, das ist richtig. Machen Sie es nur bis zur allerletzten Phase nicht zu einem Teil des vollständigen Corefx-Builds / Testlaufs.

Ich habe ein paar Konstanten gefunden, die anscheinend in eine interne Klasse in src/Common/src/Interop/Windows/Crypt32/Interop.certificates_types.cs verschoben wurden . Dies ist jedoch nicht von System.Security.Cryptography.Xml aus zugänglich. Irgendwelche Gedanken zum besten Ansatz hier?

Welche davon werden benötigt? Alle von ihnen?
Können Sie die Referenzquelle überprüfen, wenn sie in .NET Fx öffentlich ist? (Ich glaube nicht, aber es schadet nicht, es zu überprüfen)
Ich bin ein bisschen überrascht, dass wir spezielle Interops durchführen, anstatt den Rest der Crypto-Bibliothek zu nutzen ... entweder braucht es etwas Besonderes oder es hat historische Gründe ... @steveharter @bartonjs irgendwelche

@tintoy Eines der Dinge, die bei diesem Aufwand getan werden müssen, besteht darin, die direkte Schnittstelle mit CAPI zu entfernen und zur Verwendung der .NET-APIs zu wechseln.

@karelz , @bartonjs - meistens CAPI HRESULT-Konstanten, die an den CryptographicException Konstruktor übergeben werden.

Zum Beispiel:

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

Ich werde mir ansehen, wie anderer Code in corefx mit CryptographicException funktioniert.

Ah, ok - es sieht also so aus, als ob der HRESULT-Konstruktor nicht mehr verwendet wird - nur der, der eine Nachricht entgegennimmt. Ich werde sehen, ob es vorhandene Nachrichtenressourcen gibt, die diesen E_xxx Werten entsprechen.

Was die anderen Probleme angeht, so sieht es für mich so aus, als ob Typen nicht mehr eine einzelne Assembly teilen. X509Utils.DecodeHexString befindet sich beispielsweise in System.Security.Cryptography.X509Certificates aber im vollständigen Framework lebt dies nur in der System.Security Assembly zusammen mit den Klassen, die sie verwenden.

Da alles in mehrere Baugruppen aufgeteilt wurde, was ist Ihr bevorzugter Mechanismus für den Umgang mit normalerweise gemeinsam genutzten Komponenten? Ich könnte einfach eine Kopie der erforderlichen Funktionen aus dem Code in anderen Assemblys erstellen, wenn Sie dies bevorzugen.

Oder ziehen Sie die Quelle mit etwas wie:

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

Im Moment habe ich das CAPI-Problem umgangen, indem ich einfach `Interop.certificates_types.cs in die Assembly kompiliert und von dort auf Konstanten verwiesen habe.

Ich musste auch einige Methoden von X509Utils.cs im vollständigen Framework kopieren (hauptsächlich im Zusammenhang mit Hex-Kodierung / -Dekodierung), da in corefx nichts öffentlich verfügbar ist, das dies tut.

Die einzigen verbleibenden Probleme sind in src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SymmetricKeyWrap.cs (unter anderem Zeile 34), die zu Fehlern führen wie:

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

Im Moment habe ich Fehler unterdrückt. So, jetzt ist alles kompiliert :)

Okay, bis auf das Testprojekt:

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

Das werde ich morgen klären.

@karelz @bartonjs Ich werde eine PR eröffnen, damit wir die Änderungen besprechen können (die Arbeit ist im Grunde genommen soweit ich das

Klingt gut für mich. @steveharter irgendwelche

Frohes neues Jahr =D

Haben Sie eine Ahnung, wann Phase 2 abgeschlossen sein wird?

dotnet/corefx#14662 ist bereits zusammengeführt - das war die Phase 2. Ich werde es im oberen Beitrag als "geprüft" markieren.

Um es klarzustellen: Sobald alle 5 obigen Schritte abgeschlossen sind, muss das AAD-Team seine SAML-Token-Bits ausführen, um ws-gefütterte Unterstützung in ASP.NET Core zu erhalten, und dann müssen die ASP.NET-Teams das ws erstellen -gefütterte Middleware auf dem AAD-Teil. Entspricht das Ihren Erwartungen?

Nein, diese Arbeit hat nichts mit WS-Fed zu tun.
Ich schulde eine Antwort und Erklärung auf https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500

Zu Ihrer Information: Antwort gepostet: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

Wann wird Phase 4 abgeschlossen sein?

Wenn Sie fragen, wann das .NET-Team Zeit hat, sich damit zu befassen – wir wissen es noch nicht. Es ist hoch in unserem Auftragsbestand, aber es gibt einige höhere Prioritäten, die wir zuerst angehen müssen.

Wir sind in der Zwischenzeit offen für Beiträge im Raum aus der Community.

Ich freue mich, weiter daran zu arbeiten, aber ich stecke im Moment irgendwie fest; seit corefx zum neuen Build-Prozess übergegangen ist, wird System.Security.Cryptography.Xml nicht mehr erstellt (also @anthonylangsworth und ich daran

PS. Ich habe ungefähr 20 Minuten damit verbracht, den Build-Prozess zu verfolgen, um herauszufinden, warum er nicht mehr erstellt wird, aber das habe ich noch nicht herausgefunden. Für Hinweise wäre ich dankbar...

@mellinoe @weshaggard Können Sie bitte eine Anleitung für die Migration von SignedXml auf das neue Build-System geben?

😭😭 Ich glaube, ich muss warten 😭😭

@tintoy Wenn Sie mich auf die Branche hinweisen, an der Sie gerade arbeiten, und an welchem ​​Projekt Sie versuchen, zu bauen, kann ich beim Bauen helfen.

@weshaggard es gibt derzeit keine Verzweigung - der Code befindet sich im Master, er ist nur (absichtlich) nicht in den Root-Build eingebunden - src/System.Security.Cryptography.Xml (eingeführt in dotnet/corefx#14628). @steveharter kann zusätzliche Informationen bereitstellen.

@weshaggard @karelz Ich freue mich, einen Branch in unserem Fork zu erstellen und ihn nur dort aufzubauen, um uns zu entsperren; später können wir jederzeit alle Änderungen, die wir vorgenommen haben, herauspicken, sobald es wieder in master . Lassen Sie mich wissen, ob dies Ihr bevorzugter Ansatz ist :)

PR https://github.com/dotnet/corefx/pull/15491 sollte die Projektinfrastruktur zum Laufen bringen. Sobald CI es akzeptiert, können wir es zusammenführen und es sollte Ihre Bemühungen beschleunigen.

Danke - ich habe tintoy /corefx/master überarbeitet und werde in Kürze damit spielen :)

@weshaggard ok, also sowohl src als auch test project build, aber wenn ich eine Projektreferenz aus dem Testprojekt zum Quellprojekt hinzufüge ( <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ), erhalte ich:

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

Ich vermute, ich habe etwas übersehen, wie projektübergreifende Referenzen in corefx funktionieren sollen.

@tintoy Ich bin mir nicht sicher, was dieser Fehler konkret ist, aber wir benötigen im Allgemeinen keine ProjectReferences in unserem neuen Engineering-System. Für den Testbuild erstellen und verweisen wir immer auf das vollständige Targeting-Paket, in diesem Fall in bin\ref\netcoreapp . Die Bibliothek, die in dieses Verzeichnis gelegt wird, ist das, was Sie aus Ihrem ref-Ordner erstellen, der derzeit leer ist. Um loszulegen, müssen Sie also eine Referenz mit der benötigten API-Oberfläche generieren und die Referenz erstellen, dann sieht Ihr Testprojekt automatisch die APIs und kann mit ihnen bauen. Wir haben ein Tool namens genapi, das die Referenz basierend auf einer anderen Bibliothek generieren kann. Lassen Sie mich schnell eine weitere PR einreichen, um das für Sie zu säen.

Ok, jetzt verstehe ich es jetzt; Der Grund, warum ich im Testprojekt keine Typen sehe, ist, dass das Ref-Projekt noch keine Typen hat :-)

@weshaggard Wenn Sie keine Zeit haben, kann ich wahrscheinlich herausfinden, wie das geht; Ich habe erst neulich über dieses Tool gelesen.

Ich habe schnell das Genapi-Tool ausgeführt und diesen Commit https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e gepusht

Prost - das spart mir Zeit, sehr geschätzt.

@weshaggard Erfolg! Danke, hoffentlich können wir jetzt mit dem Schreiben dieser Tests beginnen :)

(tintoy @dd834c63af4fe40faf84bc6a776b474ec9947eb1 , ignorieren

Ja! Machen Sie einen Arbeitstest:

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

Danke für deine Hilfe, @weshaggard!

PS. Ich musste lokal (über .user Datei) den ausführbaren Pfad unter den Testprojekteigenschaften (Registerkarte Debug) überschreiben. War D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe aber nur funktioniert, als ich es in D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe geändert habe.

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

Mein VS beschwert sich nicht über die Schrägstriche. Die Pfadtrennzeichen sind im Allgemeinen mühsam, weil wir versuchen, die Dinge sowohl unter Windows als auch unter Unix zum Laufen zu bringen, sodass wir am Ende eine Reihe gemischter Schrägstriche auf Windows sehen, die im Allgemeinen besser akzeptiert werden als Unix.

Nur aus Neugier, welche Version von VS verwenden Sie? 2015 oder 2017? Vielleicht wurde es 2017 behoben :)

(Ich arbeite heutzutage normalerweise unter OSX oder Linux, daher schätze ich die Bemühungen, die Dinge plattformübergreifend zu gestalten, übrigens total)

Ich verwende VS 2015 unter Windows 10 und habe die Lösung geöffnet und konnte F5 verwenden, um die Tests zu debuggen, und mein Debug-Pfad ist D:\git\corefx\Tools/testdotnetcli\dotnet.exe

Ok, ich muss verrückt werden - jetzt kann ich es auch nicht mehr reproduzieren!

Zuvor beschwerte es sich darüber, dass ich dotnet.exe , aber es begann zu funktionieren, als ich die ausführbare Datei explizit auf einen Pfad mit nur Backslashes gesetzt habe. Ich habe gerade die .csproj.user Datei entfernt und sie funktioniert _immer noch_, also wer weiß :-o

Hey Leute, ich würde gerne mithelfen, Tests zu schreiben. Was kann ich tun, um einen Beitrag zu leisten?

Großartig - ich denke, wir könnten jetzt an dem Punkt sein, an dem wir damit beginnen können :)

Lassen Sie mich bei einem Kollegen nachfragen, ob er seinen ersten Test erfolgreich durchgeführt hat...

cc: @anthonylangsworth

@karelz ,

@anthonylangsworth und ich haben angefangen, Tests zu schreiben ; Ich bin mir bewusst, dass wir keine gemeinsame Einigung darüber erzielt haben, was getestet werden muss, aber wir werden trotzdem beginnen und die Tests dann dorthin übertragen, wo wir uns bereit erklären, die Arbeit zu erledigen.

Und für diejenigen, die sich freiwillig gemeldet haben, um bei den Tests zu helfen (was sehr geschätzt wird), sollten wir in der Lage sein, die vorgeschlagene Arbeit Anfang nächster Woche aufzuteilen :)

In Bezug auf die Testabdeckung und welche Tests wir brauchen - @bartonjs hatte eine starke Meinung dazu (da er die meiste Erfahrung mit dem Typ und seinen Problemen auf unserer Seite hat). Er schlug vor, Tests nach der Spezifikation zu schreiben (ich habe es oben erwähnt ).
Ende nächster Woche kommt er aus dem Urlaub zurück. Wir sollten wahrscheinlich Details und Erwartungen mit ihm besprechen.
Auch @AndersAbel erwähnte früher in der Diskussion das Fachwissen und die potenzielle Hilfe.

cc @steveharter, wenn er zusätzliche Anleitung hat, während @bartonjs OOF ist.

Danke @tintoy @anthonylangsworth für deine Beiträge hier! Wir wissen es sehr zu schätzen!
Und auch vielen Dank an alle anderen, die mitmachen wollen ;-)

cc @ steveharter, wenn er zusätzliche Anleitung hat, während @ bartonjs OOF ist.

Meine Neugier erreichte einen Punkt, der befriedigt werden wollte.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
Ich fühle mich jetzt besser.

😃 Ich wusste gar nicht, dass es so Microsoft-spezifisch ist! Danke für deine lustige Aufklärung 😃

@anthonylangsworth hat damit begonnen, einen groben Testplan in tintoy/corefx#3 zu skizzieren (ich habe seinen Plan in ein Problem kopiert, um es einfacher zu kommentieren), damit wir zumindest etwas zu besprechen haben. Schaut es euch gerne an und gebt Feedback :)

CC: @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (oder irgendjemand, der es betrifft) Welche Richtlinien gelten für die Verwendung von InternalsVisibleToAttribute für Tests? Es gibt viele internal Klassen in diesem Namespace, und es kann schwierig sein, allein über öffentliche Methoden eine ausreichende Testabdeckung zu erreichen. Ich weiß jedoch zu schätzen, dass es andere Überlegungen gibt.

Hmmm, ich weiß es leider nicht - @weshaggard @stephentoub? (Frage in vorheriger Antwort)

Nach allem, was ich von anderem Code in corefx gesehen habe, enthalten die fraglichen Projekte manchmal die relevanten Quelldateien aus anderen Projekten (obwohl ich mir vorstellen kann, dass dies aufgrund von Abhängigkeitsdiagrammen ziemlich schnell kompliziert wird).

Aus dem Speicher verwendet System.Collections.Immutable [InternalsVisibleTo] , falls das hilfreich ist.

Zum Beispiel:

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

Allgemeiner:

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

Sie können meine Gedanken zu InternalsVisibleTo in dieser alten Ausgabe https://github.com/dotnet/corefx/issues/1604 sehen. Meine allgemeine Meinung ist, es nicht zu tun, es sei denn, es besteht ein wirklicher spezifischer Bedarf.

Welche Richtlinien gelten für die Verwendung von InternalsVisibleToAttribute für Tests?

Nein.

Es gibt viele interne Klassen in diesem Namespace, und es kann schwierig sein, eine ausreichende Testabdeckung allein über öffentliche Methoden zu erreichen.

Wenn es sich nicht um einen tiefen Ausnahmepfad handelt, sollte er erreichbar oder gelöscht werden. Wenn es einen kniffligen Testfall braucht, um ihn zu treffen, dann brauchen wir das.

die betreffenden Projekte enthalten manchmal die entsprechenden Quelldateien aus anderen Projekten

Angenommen, Sie meinen "die Testprojekte enthalten die Produktquelle, um Zugriff auf interne Mitglieder zu erhalten": Nein.

[InternalsVisibleTo] und die gemeinsame Nutzung von Quellen sind beides vererbte Strategien. Die Lautstärksten von uns glauben (im Wesentlichen), dass unsere Tests nur repräsentativ für Dinge sein sollten, die in der realen Welt vorkommen könnten. Wenn kein Test möglich ist, einen bestimmten Block zu treffen, warum existiert er dann? Ja, es gibt einige Exception-werfende Blöcke, die nicht getroffen werden können, weil sie ein redundanter Check weiter oben im Stack bereits erwischt hat; aber das kann man sich im Nachhinein anschauen und für OK erklären.

Daher würde ich empfehlen, die Spezifikation hochzuziehen und sicherzustellen, dass es für jedes Feature einen positiven Test gibt (zB jeden Algorithmus, der angeblich unterstützt wird, und Grenzfälle für Min/Max-Werte für Optionen dieser Algorithmen).

Negative Tests wie das Entfernen erforderlicher Elemente (zB 4.1 sagt, dass SignedInfo ein erforderliches Element für Signature ... geben wir eine vernünftige Ausnahme aus, wenn sie fehlt?) sind auch gut.

Canonicalizer-Optionstests wie <foo><!-- hi --></foo> und <foo></foo> (und vielleicht <foo /> ?) sind unter c14n , aber unter c14n-withcomments . (Dies erfordert wahrscheinlich das Signieren in beide Richtungen und dann das Austauschen von Körpern, da der Kanonisierungsalgorithmus signiert werden sollte).

Transformieren Sie Tests. Alle Canonicalizer sind Transformationen. Usw.

Auch Manipulationstests sind gut. Wenn Sie jedoch glauben, dass Sie einen Manipulationstest gefunden haben, der erfolgreich manipuliert wurde, melden Sie ihn hier nicht und übertragen Sie ihn nicht an ein Repro auf github (per E-Mail den Test / den Fall / die Beschreibung an [email protected]).

Okay, ich habe zu viel nachgedacht für den Tag. Jetzt wieder im Urlaub.

Danke @bartonjs für deine Einblicke im Urlaub! Jetzt geh und hab Spaß in der realen Welt ;-)

@karelz @bartonjs (allerdings erst wenn du aus dem Urlaub zurück bist!) @steveharter und alle anderen mit einer Meinung:

@anthonylangsworth hat einige erste Tests als Diskussionsstarter erstellt, und wir würden uns über jedes Feedback freuen, das Sie bisher haben.

Ich sehe, dass Mono einige SignedXml-Tests hat. Diese sollten evaluiert und gegen die xmldigsig spec , die bereits erwähnten Vorschläge von geprüft werden, um zu sehen, was\ob sie

Danke - das schauen wir uns an :)

Danke dafür, @steveharter . Können Sie bitte Links bereitstellen? Diese könnten viele unserer Tests verkürzen. Gibt es urheberrechtliche oder andere Überlegungen, wenn wir diese erweitern oder darauf aufbauen, anstatt sie wörtlich zu kopieren?

@anthonylangsworth Beim Kopieren des Quellcodes von Mono müssen wir den Copyright-Header

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

Danke, @steveharter. Ich habe damit begonnen , die Tests von NUnit nach Xunit umzuwandeln .

Ich habe dies gepostet, aber festgestellt, dass es sich im Repo von @anthonylangsworth befindet :

Hier ist die Magie, die Sie mit den Copyright-Headern machen können, wenn wir Code von Mono abrufen:

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.

Gibt es in diesem Projekt fehlgeschlagene Tests?

@Jaedson33 Wir konvertieren gerade die

@anthonylangsworth Was kann ich tun, um zu helfen?

@Jaedson33 Ich habe diese Frage unter https://github.com/tintoy/corefx/issues/6#issuecomment -280904587 beantwortet. Zusammenfassend haben wir 84 Monotests, die immer noch fehlschlagen (hauptsächlich aufgrund geänderter Standardeinstellungen und .Net-Kernbeschränkungen). Jede Hilfe, um die verbleibenden Tests zum Laufen zu bringen, ist willkommen. Ansonsten arbeite ich sie durch.

@karelz @bartonjs @steveharter Die Klasse System.Security.Cryptography.CryptoConfig gibt an, dass viele XML-Transformationen von CoreFx nicht unterstützt werden (Zeilen 281 bis 303 am Ende von DefaultNameHT ).

Diese entsprechen URIs, die von Klassen im System.Security.Cryptography.Xml Namespace verwendet werden. Als Teil des Hinzufügens von System.Security.Cryptography.Xml zurück in .Net Core gehe ich davon aus, dass wir diese wieder einsetzen sollten. Bitte lassen Sie es mich wissen, wenn ich mich irre.

CC: @tintoy

@anthonylangsworth , einige dieser Transformationen wie XmlDsigC14NTransform sind in Ordnung, aber andere wie XmlDsigXsltTransform gelten als sehr gefährlich. Sie können sie zwar über die Registrierungsschlüssel-Anmeldung im vollständigen .NET Framework aktivieren, ich möchte sie jedoch nicht auf .Net Core unterstützen. Sehen Sie sich KnownCanonicalizationMethods und DefaultSafeTransformMethods an unter https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/Security/Cryptography/Xml/Security/Cryptography/Xml die Transformationen, die wir unterstützen sollten.

Ich hatte nicht bemerkt, dass die Quelle der gefährlichen tatsächlich in den Hafen eindringt. Ich würde dafür stimmen, sie komplett zu entfernen. Es gibt wirklich keinen sicheren Weg, sie zu verwenden.

@morganbr Danke für den

@anthonylangsworth Klingt großartig!

@morganbr @AnthonyDGreen Diese Transformationen (die im MS16-035-Patch deaktiviert wurden) wurden zuvor in diesem Thread besprochen, als die Portierung besprochen wurde. @bartonjs erklärte am 14. Dezember, dass Reg-Compat-Sachen entfernt werden sollten. Siehe auch Kommentar von @steveharter 15. Dezember, dass diese Transformationen wahrscheinlich spät gebunden aktiviert werden können und daher portiert werden sollten.

@steveharter @bartonjs kannst du dich bitte

Auch ohne Registrierungsunterstützung kann CryptoConfig diese Transformationen spät gebunden nach Zeichenfolgennamen oder oid erstellen. Suchen Sie im SignedXml-Code nach 'CryptoConfig', da dieser verwendet wird, um die entsprechende Klasse basierend auf dem XML-Inhalt zu erstellen.

Dies bedeutet, dass die CryptoConfig-Klasse erweitert werden sollte, um diese Transformationen zumindest für die gleichen Typen in netfx sowieso zu unterstützen, und idealerweise auch diese gegen Mono querverweisen. Es sei denn, es gibt einen Grund (der mir nicht bekannt ist), sie nicht einzuschließen und nicht mit CryptoConfig zu verbinden.

FWIW hier ist die Netfx-Version von CryptoConfig (um mit Corefx zu vergleichen): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs ,20d26e036bc718bc

Es gibt eine Liste von "erlaubten Transformationen", die (in .NET Framework) für die Rückwärtskompatibilität durch die Registrierung erweiterbar ist. Für .NET Core ist es nicht erweiterbar, aber hart codiert, um nur die Transformationen ohne Eingabe einzuschließen.

Da Sie ein Dokument nicht mit Transformationen validieren können, die nicht auf der Zulassungsliste stehen, ist es möglicherweise nicht sinnvoll, sie zu portieren. Aber da jemand die Transformationen außerhalb des Kontexts von SignedXml mit werden konnte (nur wollen sie als allgemeinen Zweck zu verwenden Motor - Transformation) vielleicht fein es ist , sie zu haben.

Da wir über das Entfernen eines ganzen Typs sprechen würden, würde dies keine Inkonsistenz mit .NET Framework verursachen ... daher würde ich wahrscheinlich empfehlen, alle Transformationen zu entfernen, die nicht bereits auf der hartcodierten Zulassungsliste enthalten sind. "Entfernen vor dem Veröffentlichen des Pakets" kann später geändert werden. "Veröffentlichen" kann nicht.

@bartonjs hat mich geschlagen. CryptoConfig enthält eine Liste der zulässigen Transformationen. Ich musste diese Klasse ändern, um die Transformationen im neuen Namespace System.Security.Cryptography.Xml zuzulassen. Während einige der zulässigen Transformationen den vollständigen Namen einer .Net-Klasse verwenden, lässt CryptoConfig immer noch nur eine feste Liste zu.

Ich würde es vorziehen, Transformationen mit bekannten Sicherheitsproblemen nicht zu portieren, aber Abwärtskompatibilität ist auch wichtig. Sollten wir diese Entscheidung im Namen des Entwicklers treffen? Ändern wir CryptoConfig , um irgendeine Form der Erweiterung zuzulassen, damit ein Entwickler neue Transformationen hinzufügen kann, wenn er möchte? Wie kommen wir dazu zu einer Entscheidung?

CryptoConfig ist nicht der limitierende Faktor: https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SignedXml3 -cs#L76 L787. (Wenn jedoch CryptoConfig noch werkseitig für die Auflösung verwendet wird, muss jede Transformation an beiden Stellen erfolgen.)

Die Typen, die Algorithmen bereitstellen, die nicht in dieser Liste enthalten sind (die auch keine Kanonisierer sind), haben effektiv keinen Wert.

Eine Erweiterung der sicheren Liste würde eine neue API erfordern und würde daher technisch den Rahmen dieser Bemühungen sprengen.

Ich persönlich würde die Transformationstypen weglassen, die bei der Dokumentüberprüfung nicht verwendet werden können. Sie werden schwer zu testen sein.

Tatsächlich sind sowohl CryptoConfig als auch DefaultSafeTransformMethods relevant. SignatureDescription Erstellung von CryptoConfig daher können Sie unabhängig von den Werten in DefaultSafeTransformMethods keine Transformation verwenden, wenn sie nicht in CryptoConfig . DefaultSafeTransformMethods schränkt diese Liste so ein, dass SignedXml.CheckSignature false zurückgibt, wenn eine Transformation in XML angegeben, aber nicht von DefaultSafeTransformMethods wird.

In der aktuellen Ausführung. CryptoConfig.AddAlgorithm wirft ein PlatformNotSupportedException , sodass Benutzer keine eigenen hinzufügen können. Dies würde den Rahmen dieser Portierungsbemühungen sprengen, aber es könnte sich lohnen, dies in Betracht zu ziehen oder in Zukunft sogar RemoveAlgorithm hinzuzufügen.

Nach meinem vorherigen Kommentar habe ich die Eigenschaft SignedXml.SignatureFormatValidator . Dies ermöglicht einem Benutzer, anzugeben, welche Transformationen und Hash-Algorithmen geeignet sind. Damit kann der Anrufer beispielsweise DefaultSafeTransformMethods überschreiben.

Wie ich schon gefragt habe, wer entscheidet hier? Als "Sicherheitsmann" würde ich es vorziehen, unsichere Optionen auszuschließen. Allerdings verstehe ich das Ausmaß der Inkompatibilitäten in diesem Fall nicht ganz.

@anthonylangsworth diese Diskussion ist Teil der Entscheidungsfindung. Die Entscheidung treffen hier Gebietsexperten mit dem meisten Hintergrund.

Meine Empfehlung: Wenn es fraglich ist, was die richtige Aktion ist, würde ich vorschlagen, den Status Quo beizubehalten - den Code während der Port-Übung (evtl. sogar ohne Testabdeckung) unverändert zu lassen und später, getrennt von der Port-Übung, zu entscheiden.

Okay, ich habe mich intern mit einigen Leuten unterhalten und denke, ich habe das Gerüst eines Plans:

• Lassen Sie die Typen als öffentlich. (Sie sind öffentliche Typen und das Entfernen von Dingen macht die Leute traurig).
• Diese können (noch) nicht in End-to-End-SignedXml-Tests verwendet werden. (In der Tat scheinen negative Tests gut zu sein)
• Sie haben öffentliche Member, die für Unit-Tests ausreichen sollten, also sollten wir das tun.
  
  
  
  • Das gilt auch für den Rest der Transformationstypen.
  
  
• Wenn aus irgendeinem Grund die eingangsakzeptierenden Transformationen nicht funktionieren und alles andere in Ordnung ist, können wir herausfinden, was wir dagegen tun können. (Dies hätte auch auf "wenn sie komplexe Kompilierungsabhängigkeiten hätten, die nicht erfüllt werden können", zugetroffen, aber wir haben diese Hürde bereits überschritten).

Und wenn API oder eine andere Konfiguration dazukommt, damit diese Typen funktionieren, ist das Hinzufügen der aktivierten E2E-Tests einfach.

@tintoy @anthonylangsworth @peterwurzinger wie ist der Status Ihres Testzweigs ? können wir anfangen, es zusammenzuführen? Ich kann Ihre Tests herauspicken und von dort aus weitermachen.

Könnten Sie auch PTAL unter https://github.com/dotnet/corefx/pull/16545 ? Ich habe eines der MSDN-Beispiele aktiviert

Hallo @krwq - Ich glaube, es gibt immer noch einige Tests, die fehlschlagen, aber da sie nicht als Teil des regulären Build-Prozesses ausgeführt werden, können Sie sie möglicherweise trotzdem einschließen.

Lass mich mit @anthonylangsworth chatten und

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

@krwq - hatte ein kurzes Gespräch mit @anthonylangsworth. Er erwähnte (und ich stimme zu), dass es angesichts der Menge an Arbeit, die dort geleistet wurde, vielleicht gut wäre, das, was wir haben, zusammenzuführen, bevor wir weitermachen. Es baut sich auf und die meisten Tests bestehen, aber einige nicht.

Ich vermute, wir müssen gegen dotnet/corefx#16545 rebasieren (was ich tun werde), bevor wir eine PR öffnen (was @anthonylangsworth tun wird).

Wir melden uns, sobald wir dazu bereit sind (hoffentlich nicht mehr lange).

@krwq Um das zu erweitern, was @tintoy gesagt hat, ist zwar noch einiges zu tun, aber es wurde auch viel Arbeit geleistet, um bestehende Tests zu CryptoConfig.cs bereits geändert, um viele der von Ihnen erwähnten Algorithmen zu handhaben. Das wollen wir alle voranbringen. Wir möchten auch nicht die Arbeit des anderen duplizieren oder überschreiben. Daher planen wir, die Änderungen unverändert zusammenzuführen, damit andere auf der von uns geleisteten Arbeit aufbauen, alle unsere Fehler finden und hoffentlich alles früher in den Master aufnehmen können.

@tintoy ist https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests der einzige Zweig, an dem Sie arbeiten?

Ja.

@krwq Nun, es gibt eine PR mit einer guten Menge Zeug von Mono (was auch ein Unterzweig von https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests ist ... ). Wenn Sie an aktuellem Code interessiert sind, sollten Sie dort wahrscheinlich nachsehen. Soweit ich das beurteilen kann, sind ~40/340 Tests fehlgeschlagen.

Guter Fang, @peterwurzinger , ich dachte, das hätten wir schon zusammengelegt!

@peterwurzinger @anthonylangsworth diese PR ist ziemlich nett! Ich habe es tatsächlich verpasst. Wirst du das mit deinem Branch, mit corefx zusammenführen oder soll ich es übernehmen und alle Zusammenführungen/Rebases durchführen? Vermisst es etwas von Mono-Tests oder ist es vollständig? @anthonylangsworth - für die CryptoConfig-Änderungen - ich habe mit @bartonjs darüber gesprochen - wir sollten diese Datei nicht berühren - sie ist schon hässlich genug.

Mein ursprünglicher Plan war es, einige Proben von MSDN zu erhalten und sie alle zum Laufen zu bringen, damit wir früh mit dem Dogfooding beginnen können. Danach werde ich Tests aus Ihrer Branche zusammenführen und korrigieren. Wenn einige Tests fehlschlagen, können wir sie für den Moment einfach deaktivieren und später beheben. Lass uns deine Sachen so schnell wie möglich in corefx/master zusammenführen :smile:

Danke für das Update, @krwq . Wenn Sie können, halten Sie uns bitte auf dem Laufenden. Es hilft zu wissen, worauf wir abzielen.

Hallo = D

Gibt es fehlgeschlagene Tests?

@jaedson33 @anthonylangsworth @tintoy
Hier die aktuelle Liste der (willkürlich) wichtigsten Themen:
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@ Jaedson33 Ja, sie sind derzeit deaktiviert. Oben soll Ihnen eine grobe Vorstellung davon geben, wo wir uns befinden

Hallo, hast du eine Ahnung wann das fehlerfrei sein wird?

@Jaedson33 jede Software hat Fehler :wink: Gibt es bestimmte Dinge, die für Sie nicht funktionieren?

Ganz einfach: In meinem UWP-Projekt funktioniert es einfach nicht 😞

Hallo, ich erhalte diese Fehlermeldung, wenn ich versuche, build.cml auszuführen. Kannst du mir helfen?

Fehler im Befehl:
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
Die Befehlsausführung ist mit Exitcode 1 fehlgeschlagen.
Fehler beim Generieren des Build-Projekts für native Komponenten!
Die Befehlsausführung ist mit Exitcode 1 fehlgeschlagen.

@JaedsonBarbosa Führen Sie Tests über die Eingabeaufforderung des Entwicklers aus? (übrigens ist dies etwas OT) für die UWP - ich werde untersuchen, ob dies für 2.0 relativ billig gemacht werden kann, obwohl keine Versprechungen gemacht werden

Ich mache das über die Developer-Eingabeaufforderung für Visual Studio 2017

@JaedsonBarbosa haben Sie die neuesten Änderungen von github übernommen und versuchen, nach dem Bereinigen Ihres Repositorys zu bauen ( git clean -fdx )? Als Zweites sollten Sie versuchen, die Pfadlänge zu reduzieren (dh Ihr Repository unter C:\corefx abzulegen). Eine andere Sache, die Sie versuchen sollten, ist, den Nuget-Cache zu bereinigen ( %USERPROFILE%\AppData\Local\NuGet und %USERPROFILE%\.nuget )

Wenn dies immer noch passiert, erstellen Sie bitte ein separates Problem mit Informationen:

• dein Betriebssystem
• deine VS-Version
• Genaue Schritte, die du gemacht hast
• vollständiges Protokoll (wenn es groß ist, legen Sie es auf den Kern)

Ich denke, es tritt auf, weil ich denke, dass der Pfad C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj nicht gültig ist.

Betriebssystem: Windows 10
VS: 2017 Gemeinschaft
Ich starte einfach die Entwickler-Eingabeaufforderung für VS 2017 und setze:

cd C:/corefx
build

Jetzt ist der Fehler:

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"="Das System konnte die angegebene Datei nicht finden"

Ich gebe auf, ich kann es mit dem 2017 VS nicht zum Laufen bringen.
Haben Sie eine Vorstellung davon, wann dies als NuGet-Paket heruntergeladen werden kann?

Sie sollten in der Lage sein, die Vorschau von myget.org zu konsumieren.
Offizielles Paket wird Teil der .NET Core 2.0-Welle sein - siehe Beschreibung von Meilenstein 2.0.0 , 10. Mai ist die ZBB (#17619), daher sollte die RTW-Version "kurz" folgen (genaue Daten werden noch nicht öffentlich bekannt gegeben)

@karelz Können Sie mir bitte den Link des Pakets senden, das die System.Security.Cryptography.Xml enthält?

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

So funktioniert Dogfood 2.0: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

@karelz OK, ich möchte das in einer UWP-Klassenbibliothek installieren, aber wenn ich das versuche, erhalte ich diesen Fehler:

Paket System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 nicht kompatibel mit uap10.0 (UAP,Version=v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 da unterstützt ein:

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

Es ist mein aktuelles 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 , wir unterstützen derzeit UAP für diese Bibliothek nicht. Sie müssen warten, bis https://github.com/dotnet/corefx/pull/17969 zusammengeführt und ein neues Paket erstellt wurde.

😧 Ok, ich warte weiter 😭
@ krwq Aber... Was ist UAP10.1???

@krwq Warum führen Sie das PR-Dotnet/corefx#17969 jetzt nicht zusammen?

@JaedsonBarbosa Es wurde gerade zusammengeführt, ich glaube, das Paket sollte morgen früh da sein - wir werden normalerweise nicht zusammengeführt, es sei denn, der PR ist auf dem CI grün - wir haben seit gestern einige OSX CI-Probleme, also ist es ein bisschen veraltet

@krwq Können Sie mir

@JaedsonBarbosa sei gewarnt, dass die Unterstützung von .NET Standard 2.0 in UWP auf dem
In beiden Fällen können bei der Verwendung der Bibliothek in UWP einige Probleme auftreten. Wir sind möglicherweise nicht in der Lage, Ihnen sofort zu helfen. Wir sollten nach dem 10. Mai mehr helfen können. ... nur die Erwartungen festlegen.

@JaedsonBarbosa scheint, als hätten wir 2 Tage lang keine neue Version produziert 😞 Änderungen könnt ihr hier beobachten:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
Immer wenn ein Paket nach dem 4/6 erscheint, sollte es die benötigte Änderung enthalten. Ich werde heute nachsehen, warum es kein Paket gab - es könnte mit Netzwerkproblemen zusammenhängen, die wir mit OSX-Builds haben

BEARBEITEN: Bestätigen - dies hängt mit OSX-Netzwerkproblemen zusammen

@krwq Weißt du jetzt, ob heute die OSX-Netzwerkprobleme gelöst werden?

Es blockiert fast alle unsere PRs, daher hat es hohe Priorität, aber wir haben keine ETA

Okay
Also werde ich weiter warten.

Wann wird Teil 4 fertig sein?

@JaedsonBarbosa Wir haben die wichtigsten Teile bereits getestet und haben sich als funktionierend erwiesen. Beim Testen gibt es keinen einzigen "abgeschlossenen" Punkt - Sie können eine 100%ige Codeabdeckung und Code haben, der nicht funktioniert. Gibt es bestimmte Szenarien, die Sie interessieren?

Nein

@krwq Ich erwarte, dass wir die Dinge für die Bibliothek als erledigt erklären, wenn wir sie als stabil versenden können. Wenn wir das tun, können wir das Kontrollkästchen aktivieren und dieses Problem schließen. Wie weit sind wir denn testweise?

@karelz Ich bin derzeit mit dem Versand zufrieden, da alle wichtigen E2E-Szenarien, die mir einfallen, getestet wurden. Ich möchte die Abdeckung dennoch erhöhen, damit auch weniger beliebte Szenarien (einschließlich Fehlerbehandlung) nachweislich korrekt funktionieren, obwohl ich keine 2.0-Blockierungsprobleme erwarte.

"Fertig" bedeutet für mich, dass niemand mehr die Bibliothek pflegen oder verbessern wird

OK, wenn @bartonjs dem ready-to-ship-state zustimmt, dann lassen Sie uns praktisch sein und dieses Problem schließen.
Wenn wir die Testabdeckung erhöhen möchten (als non-blocking 2.0), sollten wir ein separates Workitem für Future erstellen.

Wenn wir alles von der Liste der Algorithmen und Transformationen und Kanonisierer gestrichen haben, ist es gut für mich.

Daher denke ich, dass dieses Thema endlich geschlossen wird.

Ok, lass uns den Berichterstattungsfortschritt verfolgen mit: https://github.com/dotnet/corefx/issues/16829 - Ich dachte, wir behandeln dies als Hauptproblem

Ja, wir behandeln es als Hauptproblem, aber manchmal müssen Sie Dinge für erledigt erklären, sonst müssten Sie bei jedem größeren Feature-Tracking 1 offenes Problem "mehr tun" - was niemandem wirklich hilft.

Es ist jetzt geschlossen 😢
Also... Wo sollte ich Fragen zu System.Security.Cryptography.Xml stellen?

Ist die obige Antwort von
Wenn Sie größere Fragen haben, reichen Sie eine neue Ausgabe ein. Wenn es sich um eine kleine Klarstellung der vorherigen Antwort handelt, können Sie sie hier behalten. Wenn Sie sich nicht sicher sind, fragen Sie hier und im schlimmsten Fall werden wir Sie bitten, ein neues Problem zu melden ;-)

@krwq Es geht weiter ohne Unterstützung für UWP 😞

@JaedsonBarbosa funktioniert https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 bei dir nicht? Könnten Sie die Schritte von dem, was Sie tun, senden?

@krwq Ich habe gerade diesen Befehl
Installationspaket System.Security.Cryptography.Xml -Version 4.4.0-preview1-25210-01

Das ist der Fehler:

Paket System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 nicht kompatibel mit uap10.0 (UAP,Version=v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 da unterstützt ein:

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

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

Nur zur Erinnerung an das, was ich zuvor gesagt habe: https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
Ich glaube nicht, dass Sie mit dem Paket UWP-Unterstützung erhalten. Das Paket hängt von .NET Standard 2.0 AFAIK ab und UWP bietet noch keine .NET Standard 2.0-Unterstützung – daran werden wir für .NET Core 2.1 arbeiten (einige Bits werden früh erledigt, um größere Teams für die Arbeit daran nach 5 freizugeben). /10, aber es ist nicht voll funktionsfähig).
IMO um UWP-Unterstützung für das Paket zu erhalten, müssen Sie auf 2.1 warten.

@karelz Meinst du also, ich muss warten, bis wann?
Kann ich ein uap10.1-Projekt erstellen?

Ja, ich denke, bis dahin musst du warten.
Es sei denn, Sie sind super motiviert und schaffen es, all diese Geschwindigkeitsschwellen zu überstehen. Wie ich schon sagte, bis 5/10 wird unsere Fähigkeit, Ihnen bei allem UWP zu helfen, sehr begrenzt sein , so dass Sie größtenteils auf sich allein gestellt sind 😦. Hier nur die Erwartungen einstellen ...

Also warte ich, weil ich den corefx-master mit Visual Studio 2017 nicht bauen kann 😞

@karelz @krwq Ich kann die Lösung nicht erstellen, weil ich einen Fehler gebe. Sie können den CMakeError hier sehen:
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
Bitte helft mir 🆘
PS: Es ist auf Portugiesisch, aber Sie können einen Übersetzer verwenden, um das zu lesen 😄

Ich denke, dass gescheitert nicht gut ist:
-- Die C-Compiler-Identifikation lautet MSVC 19.0.24218.2
-- Die CXX-Compiler-Identifikation lautet MSVC 19.0.24218.2
-- Überprüfen Sie, ob der C-Compiler funktioniert: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe
-- Überprüfen Sie, ob der C-Compiler funktioniert: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe -- funktioniert
-- Erkennung von C-Compiler-ABI-Infos
-- C-Compiler-ABI-Informationen erkennen - fertig
-- Überprüfen Sie, ob der CXX-Compiler funktioniert: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe
-- Überprüfen Sie, ob der CXX-Compiler funktioniert: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe -- funktioniert
-- Erkennung von CXX-Compiler-ABI-Informationen
-- Erkennung von CXX-Compiler-ABI-Informationen - fertig
-- Erkennung von CXX-Kompilierungsfunktionen
-- Erkennung von CXX-Kompilierungsfunktionen - fertig
-- Durchführen des Tests COMPILER_HAS_DEPRECATED_ATTR
-- Durchführen des Tests COMPILER_HAS_DEPRECATED_ATTR - fehlgeschlagen
-- Durchführung des Tests COMPILER_HAS_DEPRECATED
-- Durchführen des Tests COMPILER_HAS_DEPRECATED - Erfolg
-- Konfiguration fertig
-- Generieren fertig

Jemand jetzt, was ich tun kann, um es aufzubauen?

@JaedsonBarbosa wie baut man? Regelmäßiger Ablauf ist für mich:

1. Öffnen Sie cmd.exe
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - dies säubert Ihr Repository von allen übrig gebliebenen Dateien (seien Sie vorsichtig, wenn Sie nicht sicher sind, was es tut)
5. build oder ./build.sh wenn Sie kein Windows verwenden

Um native Komponenten zu erstellen, müssen Sie CMake 2.8.12 oder höher installieren

Das hat bei mir immer nur funktioniert.

@Jaedson33 Sie können auch unsere Dokumentation für neue Mitwirkende (verlinkt von der CoreFX-Hauptseite) überprüfen und uns helfen, sie zu verbessern.

Ich verwende CMake 3.8.
@krwq Ich habe getan, was Sie gesagt haben, und ich warte ungefähr 1 Stunde und es wird nur dotnet cli installiert ..., wie viele Stunden muss ich Ihrer Meinung nach warten?

@JaedsonBarbosa es sollte ein paar Minuten dauern, versuchen Sie es neu zu starten - es könnten Verbindungsprobleme sein, wenn es nicht funktioniert,

@krwq Ich erhalte diesen Fehler:

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 Bitte

@karelz Es funktioniert jetzt 😄
Der einzige Gedanke, den ich gemacht habe, um ihn zu erstellen, war, die Dateien von C:\Users\jaeds\Source\Repos\corefx-master nach C:\Users\jaeds\Source zu verschieben.
Ich denke, es sollte in der README stehen

Hallo, jetzt können Sie dieses Paket in einer UWP-App verwenden, hier eine Beispiel-App: https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

@JaedsonBarbosa großartig! Gibt es etwas aus Ihrer Arbeit, das in CoreFX zurückfließen könnte? (dh Dinge, die keine temporären Hacks sind)

@karelz Nun, ich denke, Sie können mein Projekt verwenden, um zu sehen, was Sie in CoreFX vereinfachen (oder entfernen) können 😄

Hallo zusammen, große Mühe bei der Portierung!

Darf ich fragen, warum das Nuget-Paket auf .NET Core 2.0 und nicht auf .NET Standard 2.0 verweist? Wäre das nicht vorzuziehen?

Das hätte getan werden sollen (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

Ich vermute, Sie sehen sich die offizielle Vorschau auf Nuget an
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

und es geht nur um Myget
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

Ja, da habe ich gesucht. Danke, @danmosemsft!

@leopignataro kein Problem, ich ermutige Sie, Bits von "head" auszuprobieren - Sie können sie von der Homepage hier https://github.com/dotnet/cli herunterladen ... Sie können einfach die ZIP- Datei herunterladen, wenn Sie möchten. Lassen Sie es uns wissen, wenn Sie Probleme finden – wir haben nur noch wenig Zeit, um sie vor der Veröffentlichung zu beheben.

Zu Ihrer Information: Hier sind Informationen zu den Zeitleisten: https://github.com/dotnet/corefx/issues/17619#issuecomment -301937346

Da Sie es erwähnen, @danmosemsft , gibt es dieses eine Problem:

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

Ich habe eine Lösung für den Thread vorgeschlagen, aber meine Nachricht wurde möglicherweise in all dem Buzz übersehen.

@leopignataro Fix für was wo? Wenn es für dotnet/corefx#19198 behoben ist, sollte es im Fehler verfolgt werden. Wenn es etwas anderes ist, würde ich es vorziehen, ein separates Problem dafür zu sehen.
Wenn Sie der Meinung sind, dass Ihr Lösungsvorschlag irgendwo übersehen wurde, sprechen Sie ihn in diesem Thread erneut an und bitten Sie um Feedback.

Jetzt bin ich verwirrt. Ich dachte, das NuGet-Paket System.Security.Cryptography.Xml ist für .NET Framework und es ist bereits in Dot Net Core v2 enthalten. Es erkennt diesen Namespace in Dot Net Core v2 nicht. Habe ich das falsch gehört? Vielen Dank.

@fletchsod-developer Das Paket ist hauptsächlich für .NET Core gedacht. Wenn Sie jedoch aus einer auf .NET Standard ausgerichteten Bibliothek darauf verweisen, wird sie mit der .NET Framework-Version in .NET Framework vereinheitlicht und der Code aus dem Paket in .NET Core ausgeführt.

Wir haben nicht vor, SignedXml in die Standardinstallationsumgebung für .NET Core aufzunehmen. Es ist eine Nische genug, dass ein separates Paket auf NuGet das beste Vertriebsmodell zu sein scheint.