Runtime: قم بإضافة فئة System.Security.Cryptography.Xml.SignedXml

كما أشار Tratcher ، هذا مانع لإضافة دعم WsFederation / ADFS في ASP.NET 5. نحن نستخدم ADFS على نطاق واسع للعديد من تطبيقات ASP.NET 4 للمؤسسات. نحن مهتمون جدًا بالانتقال إلى ASP.NET 5 واستخدام WsFederation.

تضمين التغريدة

• لا يستخدم ADFS System.Security.Cryptography.Xml.SignedXml ؛ ولكن بدلاً من ذلك تنفيذه.
  
  
  
  • (هذا إلى حد كبير من نفض الغبار عن خيوط العنكبوت العقلية وتذكر العودة إلى هذا الفريق للإصدار 1 من ADFS)
  
  
• لا يستخدم System.IdentityModel بالتأكيد System.Security.Cryptography.Xml
  
  
  
  • (هذا لأن الكود المصدري الخاص بهم على مصدر مرجعي يقول هكذا: ابتسم :)
  
  
• لا يحب الأشخاص حقًا System.Security.Cryptography.Xml.SignedXml لأنه يعتمد على XmlDocument ، مما يؤدي إلى بعض المشكلات المتعلقة بالأداء.
  
  
  
  • اعتمد إصدار ADFS على XmlReader و IIRC.
  
  
• لذلك ، من المحتمل أن ما يريده الناس هو CoreFX لإنشاء تطبيق جديد لـ SignedXml.
• لكن الإصدار الجديد من SignedXml لن يتوافق مع الإصدار القديم من SignedXml
• لذلك قد يرغب بعض الأشخاص في الاحتفاظ بالإصدار القديم أيضًا.
• لذلك بشكل عام ، يريد الناس حقًا نسختين.
• إلا أنهم لا يريدون النسخة القديمة.
• ماعدا عندما يفعلون.

لذا فقد تركنا مع لغز:

• يمكننا نقل تلك الفئة التي لا يريدها أحد حقًا
• أو يمكننا التوقف وتصميم شيء جديد تمامًا لن يستخدمه أحد على الأرجح ، نظرًا لأنه لا يمكن أن يكون متوافقًا مع أي شيء آخر
• أو ، لبذل أقصى جهد وما زلت لا تفيد أحدًا ، افعل كلا الأمرين: ابتسم:.

تضمين التغريدة

من الواضح أنني كنت متوحشًا بعض الشيء هذا الصباح. آسف :).

لقد حددنا بالتأكيد أن هناك عملًا يتعين القيام به هنا ، لكننا لا نعتقد أن الإجابة الصحيحة هي تقديم كود System.Security.Cryptography.Xml الحالي. بدلاً من ذلك ، يمثل هذا العنصر الموجود في الأعمال المتراكمة لدينا لهندسة تنفيذ ذي غرض عام لـ XmlDSig وهو سريع وغير مرتبط بنماذج الكائنات القديمة (مثل XmlDocument).

هذا الجهد ليس شيئًا نتوقع القيام به لـ .NET Core 1.0 ، ببساطة لأننا نركز على أشياء أخرى.

ولكن إخبارنا بأنك متأثر بالوظيفة المفقودة يساعد في تحديد الأولويات المستمر.

إنني أتطلع إلى إنشاء برنامج ASP.NET Core SAML2 Middleware ، استنادًا إلى https://github.com/KentorIT/authservices. بدون منفذ SignedXml ، لن يكون قادرًا على العمل في إطار العمل الأساسي.

أنا أوافق بالتأكيد على أن عدم الاستغناء عن القائمة الحالية فكرة جيدة. هل سيكون من الممكن القيام بأي شيء بناءً على XmlReader API؟ بهذه الطريقة يمكن دعم كل من XDocument و XmlDocument. أيضًا توفير تطبيق للقارئ المغلف المستخدم في System.IdentityModel سيكون جيدًا (إذا تم تحسينه لدعم ملفات XML بمسافات بيضاء ...)

AndersAbel XmlReader هو المكان الذي سأبدأ فيه ، نعم (ما لم يخبرني رجال XML أن هناك شيئًا أفضل).

منذ XmlReader ما يعتمد عليه متغير System.IdentityModel ، يجب أن يكون قابلاً للتنفيذ :).

bartonjs متغير System.IdentityModel محدود للغاية على الرغم من أنه يمكن التعامل مع التحولات. بالنسبة إلى عمل SAML2 / WS-Fed ، لن تكون هناك مشكلة ، ولكن كواجهة برمجة تطبيقات عامة ، يجب النظر في كيفية التعامل مع التوقيعات غير المغلفة و xml التي تحتوي على التوقيعات المتداخلة (مثل استجابة saml الموقعة التي تحتوي على تأكيدات موقعة). أعتقد أيضًا أن System.IdentityModel.EnvelopedSignatureReader ينسخ البيانات عند إجراء التحقق من الصحة. هناك الكثير من المرح للقيام به هناك. إذا كان لدي الوقت لأحب العمل على ذلك.

أقدر التجوالbartonjs ، الذي يساعد على رؤية ما يجري وراء الكواليس.

حاليا تتأثر شركتي بهذا. لدينا بعض التعليمات البرمجية القديمة التي نحاول نقلها إلى .NET Core التي تنشئ ملفات ترخيص XML موقعة وبدون هذه المجموعة من الفئات ، فإننا عالقون. نحن منفتحون على الابتعاد عن ملفات XML كأساس للتراخيص ولكن حتى هذه اللحظة لم نعثر على حل جيد يناسب احتياجاتنا.

نتطلع إلى رؤية هذا يتم إضافته في المستقبل.

أستطيع أن أشهد أن هذا (وأيضًا تشفير XML المرتبط قليلاً) مناسب لنا. سيكون النموذج الموجود في .NET Framework على ما يرام - لا حاجة للابتكار هنا ، من وجهة نظري. تطبيق النسخ واللصق سيكون موضع ترحيب كبير!

هل يوجد حاليا أي حل بديل؟

أود أن أعرف ماذا طلب sandersaares أيضًا. لا توجد طريقة مضمنة لتوقيع xml في CoreFX الآن؟

sandersaares / @ af0l : لا يوجد ، بالنسبة لـ .NET Core 1.0 ، أي تطبيق يحمل في ثناياه عوامل لـ SignedXml / XmlDSig.

استنادًا إلى التعليقات هنا (وغيرها) ، من المحتمل أن نحضر واجهة برمجة التطبيقات القديمة ، ولكن لم يكن لدينا الوقت لتحقيق ذلك لـ 1.0.

شكرًا لك bartonjs ، يجب أن يكون هذا هو السبب في أنني لم أتمكن من تشغيل مشروعنا على Core. :) إنه أيضًا عار كبير ، لأنني أرغب في المضي قدمًا ولا يمكنني ذلك حتى يتم ذلك. يتعين علينا الإبلاغ عن جميع المدفوعات إلى مصلحة الضرائب لدينا باستخدام ملفات xml الموقعة ، لذا فهي أداة عرض بالفعل.

أي تقدم في هذا؟ أنا عالق في التحقق من صحة رمز SAML الذي يتطلب هذه الميزة. شكرا

نعم ، أكذب لمعرفة ذلك أيضًا. انتهى بنا الأمر باستخراج الميزات التي تحتاج إلى التوقيع ووضعها في حل واجهة برمجة تطبيقات ويب منفصل ...

لديك بالفعل فكرة عن الإصدار الذي سيتم تنفيذه أو الحل

في هذه المرحلة ، يبدو أن الإجابة الأكثر وضوحًا هي نقل تطبيق .NET Framework الحالي إلى .NET Core. لذلك نحن نقوم بتجميع هذا مع إغفالات API الأخرى "مما يجعل من الصعب نقلها".

يحتمل أن يكون ذا صلة بالموضوع: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it- بشكل غير متسق و https://github.com/sandersaares/ xml-c14n-whitespace-defect. يبدو لي أن تطبيق .NET Framework الخاص بـ Canonical XML 1.0 غير صحيح. آمل أن أكون مخطئًا ولكن إذا كان الأمر كذلك ، فقد يعرض هذا بعض أسئلة التوافق المشعر.

sandersaares نظرت إلى عينتك وتحتاج إلى تعيين XmlDocument.PreserveWhiteSpace = true عند قراءة Xml إذا كانت تحتوي على مسافة بيضاء.

AndersAbel شكرا للتلميح! يغير هذا الموقف ويمكّن بالفعل من التحقق من صحة المطابقة في حالة وجود مخطط XML. بدون مخطط XML ، يظل السلوك غير صالح (بطريقة جديدة ومثيرة). لقد قمت بتحديث مشكلة الاتصال و GitHub repo وفقًا لذلك.

bartonjs إذا قمت https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

لمعلوماتك إذا وصل هذا إلى مرحلة التنفيذ ، فلدي مكتبة حديثة العهد هنا ، مع الاختبارات ، والتي تستخدم توقيعات XML (كل من التوقيع والتحقق) ووظائف XML الأخرى على .NET Framework - قد يكون مفيدًا للحصول على بعض الواقعية الخالية من التبعية -world code لتجربة التنفيذ مقابل: https://github.com/Axinom/cpix

هل هناك جدول زمني لتطوير واجهة برمجة التطبيقات هذه؟

// cc @ bartonjs

henkmollema لا شيء محدد ، لا. بالنسبة للإصدار 1.2 ، نعمل على تقليص الفجوة بين .NET Framework و .NET Core ؛ وهذا الجهد هو المكان الذي يأتي منه SignedXml حاليًا.

كنت في مكالمة مع أحد العملاء اليوم الذي يحتاج إلى دعم SAML2-P على ASP.NET Core (والذي سيستخدم تطبيق KentorIT). هذه مشكلة تمنع العملاء الذين يرغبون في الانتقال إلى ASP.NET Core. في الوقت الحالي ، سيتعين على زبوني البقاء في كاتانا.

أرى أن المعلم قد تم تغييره من 1.2 إلى Future (بواسطةbartonjs). هل يمكنك التعليق أو التفصيل؟

في الأساس ، يتعلق الأمر فقط بكيفية تتبعنا للمعالم. اعتدنا على القيام بالمزيد من "نأمل أن يصنع هذا" ، ثم في نهاية الحدث الرئيسي ، سنعيد تعيين كل شيء لم يتم إنجازه. نحن نحاول الآن بجد أن نقول "إذا وضعنا علامة عليها لهذا المعلم ، فمن النادر جدًا إعادة تعيينه".

هذا هو الجزء السفلي من الكثير من الأعمال الأخرى الخاصة بالمرحلة 1.2 ، وقد كان دائمًا (بالنسبة لي ، على أي حال) امتدادًا قليلاً لجعله 1.2. لا يزال يحتل مرتبة عالية في قائمة "ما هو التالي" ، فنحن لا "نلتزم" بكونه جزءًا من الإصدار 1.2 (وهو أساسًا netstandard2.0 العمل وإصلاح الأخطاء واثنين من مشاريع البنية التحتية).

إن وضع علامة عليه كمستقبل لا يضمن أنه لن يكون جزءًا من الإصدار 1.2 ، إنه يعني فقط (باستخدام تفسيرنا الحالي للحدث الرئيسي) أننا لن نحتفظ بالإصدار من أجله. بمجرد أن يعمل شخص ما عليها بالفعل ، يكون هناك فهم أفضل للوقت الذي سيتم فيه إنجازه بالفعل ، وبعد ذلك سيتم تمييزه على أنه أي معلم سيتم إصداره بالفعل.

karelz @ إذا كان هناك أي شيء تريد إضافته (أو تصحيحه) ، فلا تتردد في الاتصال به.

لن نتمكن من تمويل العمل في إطار زمني 1.2 (هناك الكثير من الأشياء الأخرى ذات التأثير الأكبر التي يجب إنهاؤها). لهذا السبب قمنا بنقلها إلى المستقبل ، لإيصال خططنا.
نحن على دراية بعدد الطلبات ، ولهذا السبب يتزايد عدد الطلبات المتراكمة لدينا. وهي أيضًا واحدة من أفضل واجهات برمجة التطبيقات (API) المفقودة من corefx بشكل عام (من بين DirectoryServices و SerialPort وما إلى ذلك).

cc: steveharter @ danmosemsftterrajobst

عبرت إجاباتنا :)
المزيد من السياق حول المعالم في دليل المشكلات الخاص بنا.

يتوفر كود .NET Framework كمصدر مرجعي . لذلك من الناحية الفنية ، يمكن بدء تشغيل المنفذ حتى خارج فريق .NET Core - إذا كان الأشخاص مهتمين بمساعدتنا هنا.
من محادثاتي السابقة مع

مرحبًا ، ما هو الوضع الفعلي لهذه المشكلة؟

@ Jaedson33 ماذا تقصد ب "مشكلة"؟ إذا كنت تقصد متى سيتم إصلاحه - فراجع الإجابات من الأسبوع الماضي.

karelz لكني لا أريد الانتظار. لماذا لا تصلحه الآن؟

@ Jaedson33 انظر

إذا كنت في حاجة ماسة إليه حقًا في أسرع وقت ممكن ، فيمكنك دائمًا المساهمة في قاعدة التعليمات البرمجية ، وسنكون سعداء للمساعدة في التوجيه ومراجعات التعليمات البرمجية والتعليقات.

حسنًا ، سأنتظر.

karelz إذا كانت الاختبارات الأصلية لا تزال متاحة للتحقق من العمل ،

(يتمتع أحد زملائي في العمل أيضًا بخبرة ذات صلة ، لذا من المحتمل أن نعمل عليها معًا)

يتمثل الجزء الرئيسي من العمل في إنشاء أصول اختبار جديدة. الاختبارات القديمة غير كافية وذات تغطية ضعيفة. سنحتاج إلى شخص ما لمراجعة المواصفات وإضافة اختبار لكل متطلب مثير للاهتمام - هذا هو المكان الذي توجد فيه معظم التكلفة.

إذا كنت لا تزال مهتمًا ، فيمكننا محاولة إسقاط الكود المصدري من .NET Framework بالكامل كما هو - وستكون الخطوة التالية هي تصميمه وإضافة تغطية اختبارية قبل إصداره كجزء من .NET Core. اسمحوا لي أن أعرف إذا كنت مهتمًا ...

حسنًا ، نعم - ما زلنا مهتمين :)

tintoy أنا مهتم بمساعدتك لأنني أحتاج حقًا إلى هذا الفصل.

tintoy أنا مهتم بمساعدتك لأنني أحتاج حقًا إلى هذا الفصل.

سعيد لسماعها :)

إذن ... كيف يمكنني المساعدة؟
Obs: إنها المرة الأولى التي أستخدم فيها GitHub.

إذن ... كيف يمكنني المساعدة؟

اسمحوا لي أولاً بإجراء محادثة مع زميلي في العمل وسنضع خطة للهجوم. karelz - هل هناك أي إرشادات أو مستندات أخرى يجب أن نقرأها قبل الخوض في الماء؟ بادئ ذي بدء ، أعتقد أن زميلي في العمل سيخوض على الأرجح في المعيار ، وسأبحث على الأرجح عن المكان الذي يجب أن تذهب إليه الشفرة (وما الذي ينطوي عليه تشغيل الاختبارات الحالية من أجزاء أخرى من إطار العمل قبل أن نجعلها أية تغييرات). هل هذا يبدو معقولا؟

CC:anthonylangsworth

للحفاظ على النطاق محدودًا بعض الشيء ، أوصي بالبدء بدون الميزات التي تم تعطيلها بواسطة MS16-035 (تحويل xpath ، تحويل xslt ، المراجع الخارجية). لا أعرف ما هي المساحة المتاحة لكسر التغييرات ، ولكن يمكن استغلال الآلية الاحتياطية الحالية في DefaultGetIdElement في هجمات التفاف التوقيع. أفضل نسخة افتراضية أكثر أمانًا.

سيكون من الجيد أيضًا إعادة هيكلة واجهة برمجة التطبيقات الداخلية قليلاً لدعم EnvelopedSignatureReader الذي يستخدمه System.IdentityModel بدلاً من وجود تطبيقين منفصلين للتحقق من صحة توقيع XML.

أخيرًا ، أود أيضًا إضافة نقطة واحدة وفقًا لتقرير الخطأ هذا .

tintoy لا أعتقد أن لدينا مستندات جيدة. أعتقد أننا يجب أن تضيف المصادر ومن ثم يمكننا أن تتم بشكل مواز العمل - اسمحوا لي مزامنة معbartonjssteveharterianhays.

سأحاول أن أجد بعض الوقت للمساعدة أيضًا. إذا كانت هناك أي أسئلة حول المواصفات وكيف تعمل ، فسيسعدني النظر في ذلك - لقد أمضيت بالفعل بعض الوقت في مراجعة المواصفات.

هل لدى أي شخص ما يقوله حول فكرة دمج SignedXml و EnvelopedSignatureReader الذي يستخدمه System.IdentityModel؟

تضمين التغريدة

ابدأ بدون الميزات التي تم تعطيلها بواسطة MS16-035 (تحويل xpath ، تحويل xslt ، مراجع خارجية)

يجب أن نبدأ بأحدث كود مصدر لـ .NET Framework ، والذي يجب أن يكون آمنًا. إذا كانت لديك أية مخاوف بشأن أمان كود .NET Framework ، فيرجى إخبارنا في وضع عدم الاتصال.

لا أعرف ما هي المساحة المتاحة لكسر التغييرات

لا مجال ، يجب أن نبدأ بمنفذ مباشر من .NET Framework. يمكن النظر لاحقًا في أي تحسينات وتغييرات وتغييرات معطلة وما إلى ذلك. ليس كجزء من العمل الأولي. وإلا فإنه سينمو فوق رؤوسنا.

يمكن استغلال الآلية الاحتياطية الحالية في DefaultGetIdElement في هجمات التفاف التوقيع

يجب التعامل مع ذلك على أنه مشكلة منفصلة. bartonjs هل يمكنك التعليق من فضلك؟

سيكون من الجيد أيضًا إعادة هيكلة واجهة برمجة التطبيقات الداخلية قليلاً لدعم EnvelopedSignatureReader الذي يستخدمه System.IdentityModel بدلاً من وجود تطبيقين منفصلين للتحقق من صحة توقيع XML.

مرة أخرى ، دعنا نأخذها كخطوة تالية ، بعد أن يكون لدينا منفذ يعمل بكامل طاقته مع تغطية اختبار جيدة.

أخيرًا ، أود أيضًا إضافة نقطة واحدة وفقًا لتقرير الخطأ هذا.

يرجى تقديمه كمسألة منفصلة هنا ، على GitHub. من الناحية المثالية ، بعد أن نحصل على الكود هنا (أي عندما يكون الخطأ قابلاً للتطبيق حقًا على NET Core).

هل لدى أي شخص ما يقوله حول فكرة دمج SignedXml و EnvelopedSignatureReader الذي يستخدمه System.IdentityModel؟

فقط أريد أن أكرر. يجب أن نتعامل معها كخطوة تالية ، ما بعد النقل.

يمكن استغلال الآلية الاحتياطية الحالية في DefaultGetIdElement في هجمات التفاف التوقيع

يجب التعامل مع ذلك على أنه مشكلة منفصلة. bartonjs هل يمكنك التعليق من فضلك؟

AndersAbel إذا كنت تعتقد أن هناك مشكلة أمنية ، فالرجاء اتباع عملية الإبلاغ عن الثغرات الأمنية على https://technet.microsoft.com/en-us/security/ff852094.aspx.

هل لدى أي شخص ما يقوله حول فكرة دمج SignedXml و EnvelopedSignatureReader الذي يستخدمه System.IdentityModel ؟.

من المحتمل ألا يكون ذلك ممكنًا. SignedXml هو بشكل كبير (وحليف عام لواجهة برمجة التطبيقات) يعتمد على rich-DOM XmlDocument. يعتمد تمثيل IdentityModel على XmlReader. ولكن بمجرد إحضار الأشياء الموجودة يمكن التحقيق فيها.

سأحاول أن أجد بعض الوقت للمساعدة أيضًا. إذا كانت هناك أي أسئلة حول المواصفات وكيف تعمل ، فسيسعدني النظر في ذلك - لقد أمضيت بالفعل بعض الوقت في مراجعة المواصفات.

AndersAbel - هتاف ، أنا متأكد من أنه يمكننا استخدام المساعدة :)

bartonjs لقد أبلغت عن هذه المشكلات إلى [email protected] ، مما أدى إلى MS16-035. على الرغم من وجود بعض المشكلات المحفوفة بالمخاطر المتبقية في المنظمة البحرية الدولية ، قررت MS عدم إصلاحها (قد تتعرض لتغييرات عاجلة). لم أنشر التفاصيل بعد ، ولكن إذا كنت ترغب في مناقشتها على انفراد ، فيرجى مراسلتي بالبريد الإلكتروني.

karelz شكرًا

ابدأ بدون الميزات التي تم تعطيلها بواسطة MS16-035 (تحويل xpath ، تحويل xslt ، مراجع خارجية)

يجب أن نبدأ بأحدث كود مصدر لـ .NET Framework ، والذي يجب أن يكون آمنًا. إذا كانت لديك أية مخاوف بشأن أمان كود .NET Framework ، فيرجى إخبارنا في وضع عدم الاتصال.

تناول التصحيح MS16-035 عددًا من المشكلات في SignedXml. من الممكن استخدام مفاتيح التسجيل للعودة إلى السلوك القديم غير الآمن. هل يجب أيضًا نقل هذه الخيارات إلى .NET Core؟ كان المقصود من اقتراحي أعلاه إعطاء الأولوية للحصول على سلوك .NET Framework الافتراضي الحالي ، وترك تلك الأجزاء التي تم إلغاء تنشيطها افتراضيًا في الخلف في الوقت الحالي. أو هل تقصد أن هذه الأجزاء ضرورية لنقلها أيضًا؟ ثم هناك سؤال حول كيفية التعامل مع التكوين لأن .NET Core AFAIK لا يعتمد على السجل للتكوين (لأنه غير متوفر على جميع الأنظمة الأساسية).

من الممكن استخدام مفاتيح التسجيل للعودة إلى السلوك القديم غير الآمن. هل يجب أيضًا نقل هذه الخيارات إلى .NET Core؟

لا ، سيتم حذف رمز التسجيل المتوافق فقط قبل إتاحة الحزمة.

لماذا لا تنشئ مشروعًا على GitHub لتنفيذ ذلك؟

قمنا بالمزامنة مع steveharter وianhays

تحرير: انتقلت خطة التنفيذ إلى أعلى مشاركة.

يبدو أمرا جيدا لي :)

karelz ، steveharter تقع معظم عمليات البحث عن السجل في فئة Utils : AllowAmbiguousReferenceTargets ، AllowDetachedSignature ، RequireNCNameIdentifier . هناك أيضًا بحث في فئة SignedXml حيث يقوم XmlDsigXPathTransform و XmlDsigXsltTransform . هل يجب إزالتها تمامًا من المصدر مع رمز التسجيل المتوافق؟

هؤلاء الذين أعرفهم ، لم أر أي شيء آخر أثناء قراءة الكود ، لكن ربما فاتني شيء.

AndersAbel لقد قمت بتحديث تعليق Karel أعلاه بخصوص التسجيل. إذا كانت هناك أي فئات لا يمكن الوصول إليها ، فنحن بحاجة إلى فهم الوظائف التي يتم فقدها. بالنسبة لأولئك الذين ذكرتهم ، أعتقد أن CryptoConfig يحتاج إلى إضافة الاسم: زوج

متى تعتقد أن هذا الفصل سيكون جاهزًا؟

هل تقصد للمساهمات؟ تخطط steveharter لتقديم العلاقات العامة الأولية "إضافة مصادر" قريبًا جدًا (على الأرجح اليوم).

تم دمج الرمز الأولي للتو.

تضمين التغريدة

شكرا @ steveharter! لقد قمت بنقل خطة التنفيذ إلى أعلى مشاركة لتسهيل تتبع التقدم. كلما قمنا بإجراء تغييرات عليه ، سنذكر التغييرات في رد آخر هنا.

إذا أراد أي شخص بدء العمل عليها ، فيرجى ذكر ذلك لتجنب تكرار العمل. سنشاركك في تخصيص المشكلة لك.

karelz : tintoy وأنا أرفع أيدينا للبدء في هذا الأمر. سعيد لأنك تنازلها إلينا.

إذا أراد أي شخص بدء العمل عليها ، فيرجى ذكر ذلك لتجنب تكرار العمل. سنشاركك في تخصيص المشكلة لك.

في صحتك - يسعدني أن أبدأ في تجميعها :)

anthonylangsworth - هاه ،

العمل يحدث هنا .

معين إلىtintoy. سأشارك أيضًا في anthonylangsworth بمجرد قبوله بحالة المساهم في الريبو (لن يعرض عليك GH

شكرا!

@ Karelz فقط للتأكيد - من خلال ما أفهمه من إرشادات المساهمين ، أقوم بإجراء هذه التغييرات في master ؟

(من الواضح أن master )

Ergh ، آسف ، دعني أحاول مرة أخرى - سيكون PR النهائي ضد master ؟

نعم هذا صحيح. فقط لا تجعله جزءًا من بناء / اختبار corefx الكامل حتى المرحلة الأخيرة.

لقد وجدت ثابتين يبدو أنه تم نقلهما إلى فصل دراسي داخلي في System.Security.Cryptography.Xml بالرغم من ذلك. أي أفكار حول أفضل نهج هنا؟

أي منهم مطلوب؟ كلهم؟
هل يمكنك التحقق من مصدر المرجع إذا كانت عامة في .NET Fx؟ (لا أعتقد ذلك ، لكن لا يضر التحقق مرة أخرى)
أنا مندهش قليلاً لأننا نقوم بعمل interop خاص ، بدلاً من الاستفادة من بقية مكتبة Crypto ... إما أنها تحتاج إلى شيء خاص ، أو من أسباب تاريخية ... @ steveharterbartonjs أي أفكار؟

tintoy أحد الأشياء التي يجب القيام بها لأن هذا الجهد هو إزالة التفاعل المباشر مع CAPI ، والتبديل إلى استخدام .NET APIs.

karelz ، bartonjs - تم تمرير ثوابت CAPI HRESULT في الغالب إلى CryptographicException .

على سبيل المثال:

src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / KeyInfoX509Data.cs (السطر 63)

سألقي نظرة على كيفية عمل الكود الآخر في corefx مع CryptographicException .

آه ، حسنًا - يبدو أن مُنشئ HRESULT لم يعد مستخدمًا - فقط الذي يأخذ الرسالة. سأرى ما إذا كانت هناك موارد رسائل حالية تتوافق مع قيم E_xxx .

بالنسبة إلى المشكلات الأخرى ، يبدو لي أنه نتيجة لأنواع لا تشارك تجميعًا واحدًا بعد الآن. على سبيل المثال ، X509Utils.DecodeHexString موجود في System.Security.Cryptography.X509Certificates ولكن في إطار العمل الكامل ، هذا موجود فقط في تجميع System.Security جنبًا إلى جنب مع الفئات التي تستخدمه.

نظرًا لأن كل شيء تم تقسيمه إلى تجميعات متعددة ، فما هي آليتك المفضلة للتعامل مع المكونات التي يمكن مشاركتها عادةً؟ يمكنني فقط عمل نسخة من الوظائف المطلوبة من التعليمات البرمجية في التجميعات الأخرى إذا كان هذا هو ما تفضله.

أو اسحب المصدر باستخدام شيء مثل:

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

في الوقت الحالي ، عملت على حل مشكلة CAPI ببساطة عن طريق تجميع `` Interop.certificates_types.cs في التجميع والإشارة إلى الثوابت من هناك.

اضطررت أيضًا إلى نسخ بعض الطرق من X509Utils.cs في الإطار الكامل (يتعلق بشكل أساسي بتشفير / فك تشفير Hex) حيث لا يوجد شيء متاح للجمهور في corefx يقوم بذلك.

المشكلات الوحيدة المتبقية موجودة في src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / SymmetricKeyWrap.cs (السطر 34 ، من بين أمور أخرى) والتي تؤدي إلى أخطاء مثل:

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

في الوقت الحالي ، قمت بإيقاف الخطأ. حتى الآن كل شيء يجمع :)

حسنًا ، حسنًا باستثناء مشروع الاختبار:

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

سأعمل على ذلك غدا.

karelzbartonjs سأقوم بفتح العلاقات العامة حتى نتمكن من مناقشة التغييرات (يتم العمل بشكل أساسي بقدر ما أستطيع أن أقول) - هل أنت موافق على ذلك؟

يبدو أمرا جيدا لي. steveharter أي أفكار؟

سنة جديدة سعيدة = د

هل لديك أي فكرة عن موعد اكتمال المرحلة الثانية؟

تم دمج dotnet / corefx # 14662 بالفعل - كانت هذه هي المرحلة 2. سأضع علامة عليها في أعلى مشاركة على أنها "محددة".

فقط حتى أكون واضحًا: بمجرد الانتهاء من جميع الخطوات الخمس المذكورة أعلاه ، ثم للحصول على دعم ws-fed في ASP.NET Core ، يحتاج فريق 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

إذن متى ستكتمل المرحلة الرابعة؟

إذا كنت تسأل متى سيكون لدى فريق .NET وقت للوصول إليه - فنحن لا نعرف حتى الآن. إنه يحتل مكانة عالية في الأعمال المتراكمة لدينا ، ولكن هناك بعض الأولويات العليا التي يتعين علينا معالجتها أولاً.

نحن منفتحون على المساهمات في الفضاء من المجتمع في هذه الأثناء.

أنا سعيد لمواصلة العمل على هذا ، لكنني عالق نوعًا ما في الوقت الحالي ؛ منذ انتقال corefx إلى عملية الإنشاء الجديدة ، لم يعد يبني System.Security.Cryptography.Xml (لذلك تم منع أنا و anthonylangsworth من كتابة أي اختبارات). إذا تمكنا من الحصول على مؤشر سريع حول ما ينطوي عليه إنشاء المشروع (واختبار المشروع) ، فسنكون على ما يرام :)

ملاحظة. لقد أمضيت 20 دقيقة أو نحو ذلك في تتبع عملية الإنشاء لمعرفة سبب عدم ظهورها ، ولكن لم يتم تنفيذ ذلك بعد. كل التقدير لكل النصائح...

mellinoeweshaggard هل يمكنك تقديم إرشادات حول ترحيل SignedXml إلى نظام البناء الجديد؟

😭😭 أعتقد أنني سأحتاج إلى الانتظار 😭😭

tintoy إذا إنشاؤه ، فيمكنني المساعدة في الحصول على بنائه .

weshaggard لا يوجد فرع حاليًا - الكود رئيسي ، فقط غير متصل ببناء الجذر (عن قصد) - src / System.Security.Cryptography.Xml (تم تقديمه في dotnet / corefx # 14628). steveharter يمكنه تقديم معلومات إضافية.

weshaggardkarelz يسعدني إنشاء فرع في مفترقنا والحصول عليه فقط للبناء هناك لإلغاء حظرنا ؛ لاحقًا ، يمكننا دائمًا اختيار أي تغييرات قمنا بإجرائها بمجرد إعادة البناء مرة أخرى master . اسمحوا لي أن أعرف ما إذا كان هذا هو النهج المفضل لديك :)

العلاقات العامة https://github.com/dotnet/corefx/pull/15491 يجب أن تعمل على عمل البنية التحتية للمشروع. بمجرد أن يتم تمرير CI لها يمكننا دمجها ويجب أن تقوم بتمهيد جهودك.

شكرًا - لقد أعدت تعيين tintoy / corefx / master وسأقوم باللعب به قريبًا :)

weshaggard ، حسنًا ، لذلك كل من src واختبار إنشاء المشروع ، ولكن إذا أضفت مرجعًا للمشروع من مشروع الاختبار إلى المشروع المصدر ( <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ) ، فسأحصل على:

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

أظن أنني فاتني شيئًا ما حول كيفية عمل المراجع بين المشاريع في corefx؟

tintoy لست متأكدًا من ماهية هذا الخطأ على وجه التحديد ولكننا عمومًا لا نحتاج إلى ProjectReferences في نظامنا الهندسي الجديد. بالنسبة لبناء الاختبار ، نقوم دائمًا ببناء حزمة الاستهداف الكاملة والإشارة إليها ، وفي هذه الحالة يتم إنتاجها bin\ref\netcoreapp . المكتبة التي تم وضعها في هذا الدليل هي ما تقوم بإنشائه من مجلد المرجع الخاص بك وهو فارغ حاليًا. حتى تتمكن من المضي قدمًا ، تحتاج إلى إنشاء مرجع باستخدام مساحة سطح API التي تحتاجها والحصول على مبنى المرجع ، ثم سيرى مشروعك الاختباري واجهات برمجة التطبيقات تلقائيًا ويمكن أن يبني عليها. لدينا أداة تسمى genapi يمكنها إنشاء المرجع بناءً على مكتبة أخرى. اسمحوا لي أن أرسل علاقات عامة أخرى بسرعة لبذر ذلك لكم يا رفاق.

حسنًا ، فهمت الآن ؛ السبب في أنني لا أرى أي أنواع في مشروع الاختبار هو أن مشروع المرجع ليس له أنواع حتى الآن :-)

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 .

د: \ تطوير \ جيثب \ tintoy \ corefx \ أدوات / testdotnetcli / dotnet.exe

لا يشكو My VS من الخطوط المائلة. تعتبر فواصل المسار بشكل عام ألمًا لأننا نحاول جعل الأشياء تعمل على كل من windows و unix ، لذلك ينتهي بنا الأمر برؤية مجموعة من الخطوط المائلة المختلطة على النوافذ والتي تكون عمومًا أكثر قبولًا من يونكس.

بدافع الفضول فقط ، ما هو إصدار VS الذي تستخدمه؟ 2015 أم 2017؟ ربما تم إصلاحه في عام 2017 :)

(عادةً ما أستخدم OSX أو Linux هذه الأيام ، لذلك أقدر تمامًا الجهد المبذول لجعل الأشياء سهلة الاستخدام عبر الأنظمة الأساسية ، راجع للشغل)

أنا أستخدم VS 2015 على Windows 10 وفتحت الحل ويمكن أن F5 لتصحيح الأخطاء ومسار التصحيح الخاص بي هو D:\git\corefx\Tools/testdotnetcli\dotnet.exe

حسنًا ، يجب أن أكون مجنونًا - الآن لا يمكنني إعادة إنتاجها أيضًا!

من قبل ، اشتكت من عدم قدرتها على العثور على dotnet.exe ، لكنها بدأت في العمل عندما قمت بتعيين الملف القابل للتنفيذ صراحةً على مسار به خطوط مائلة عكسية فقط. لقد قمت للتو بإزالة الملف .csproj.user وهو _لا يزال_ يعمل ، فمن يدري: -o

مرحبًا يا شباب ، أود المشاركة في المساعدة في كتابة الاختبارات. ما الذي يمكنني فعله لبدء المساهمة؟

رائع - أعتقد أننا قد نكون في المرحلة الآن حيث يمكننا البدء في فعل ذلك :)

اسمحوا لي أن أتحقق من زميل في العمل لمعرفة ما إذا كان قد أجرى اختباره الأول بنجاح ...

سم مكعب: anthonylangsworth

@ Karelz ،

لقد بدأت أنا و anthonylangsworth في كتابة الاختبارات ؛ أدرك أننا لم نتوصل إلى اتفاق مشترك بشأن ما يجب اختباره ولكننا سنبدأ على أي حال ثم ننتقل الاختبارات إلى أي مكان نتفق فيه على القيام بالعمل.

وبالنسبة لأولئك الذين تطوعوا للمساعدة في الاختبارات (وهو أمر نقدره بشدة) ، يجب أن نكون في وضع يسمح لنا بتقسيم العمل المقترح في وقت مبكر من الأسبوع المقبل :)

فيما يتعلق بتغطية الاختبار وما هي الاختبارات التي نحتاجها - كان لدى bartonjs رأي قوي بشأنها (حيث أنه يتمتع بأكبر قدر من الخبرة في النوع أعلاه ).
وسيعود من الاجازة نهاية الاسبوع المقبل. ربما يجب أن نناقش التفاصيل والتوقعات معه.
كما ذكر AndersAbel خبرة المواصفات والمساعدة المحتملة في وقت سابق من المناقشة .

ccsteveharter إذا كان لديه إرشادات إضافية بينما bartonjs هو OOF.

بفضلtintoyanthonylangsworth لمساهماتكم هنا! نحن نقدر ذلك حقا!
وأيضًا بفضل كل من يخطط للقفز ؛-)

cc @ steveharter إذا كان لديه إرشادات إضافية بينما @ bartonjs هو OOF.

وصل فضولي إلى نقطة تتطلب أن أشبع.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
أشعر بتحسن الان.

😃 لم أكن أعرف حتى أنها خاصة بـ Microsoft! شكرا لتنويرك المضحك 😃

بدأ anthonylangsworth في رسم خطة اختبار تقريبية في tintoy / corefx # 3 (لقد قمت بنسخ خطته في مشكلة لتسهيل التعليق عليها) لذلك لدينا على الأقل شيء نناقشه. لا تتردد في إلقاء نظرة عليها وتقديم التعليقات :)

CC:karelzsteveharterbartonjs

karelzsteveharterbartonjs (أو أي شخص قد تهم) ما هي سياسة حول استخدام InternalsVisibleToAttribute للاختبارات؟ هناك الكثير من فئات internal ضمن مساحة الاسم هذه ، وقد يكون من الصعب الحصول على تغطية اختبار كافية عبر الطرق العامة فقط. ومع ذلك ، أنا أقدر أن هناك اعتبارات أخرى.

هممم، للأسف، أنا لا أعرف -stephentoubweshaggard؟ (السؤال في الرد السابق)

من خلال ما رأيته من تعليمات برمجية أخرى في corefx ، تتضمن المشاريع المعنية أحيانًا ملفات المصدر ذات الصلة من مشاريع أخرى (على الرغم من أنني أتخيل أن هذا سيتعقيد بسرعة كبيرة بسبب الرسوم البيانية التبعية).

من الذاكرة ، يستخدم System.Collections.Immutable [InternalsVisibleTo] ، إذا كان هذا أي مساعدة.

على سبيل المثال:

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

بشكل عام:

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

يمكنك رؤية أفكاري حول InternalsVisibleTo في هذا الإصدار القديم https://github.com/dotnet/corefx/issues/1604. وجهة نظري العامة هي عدم القيام بذلك ما لم تكن هناك حاجة حقيقية محددة للقيام بذلك.

ما هي السياسة المتعلقة باستخدام InternalsVisibleToAttribute للاختبارات؟

لا.

هناك الكثير من الفصول الداخلية داخل مساحة الاسم هذه ، وقد يكون الحصول على تغطية اختبار مناسبة أمرًا صعبًا فقط عبر الطرق العامة.

إذا كان هناك شيء آخر غير مسار الاستثناء العميق ، فيجب أن يكون قابلاً للوصول إليه أو حذفه. إذا تطلب الأمر حالة اختبار صعبة للوصول إليها ، فهذا ما نحتاجه.

تتضمن المشاريع المعنية أحيانًا ملفات المصدر ذات الصلة من مشاريع أخرى

بافتراض أنك تعني "تتضمن المشروعات الاختبارية مصدر المنتج للوصول إلى الأعضاء الداخليين": لا.

[InternalsVisibleTo] ومشاركة المصدر إستراتيجيات موروثة. يعتقد الأكثر صخباً منا (بشكل أساسي) أن اختباراتنا يجب أن تكون ممثلة فقط للأشياء التي يمكن مواجهتها في العالم الحقيقي. إذا لم يكن هناك اختبار ممكن لضرب كتلة معينة فلماذا يوجد؟ نعم ، هناك بعض الكتل التي ترمي الاستثناءات التي لا يمكن ضربها لأن فحصًا زائدًا عن الحاجة أعلى في المكدس اكتشفه بالفعل ؛ ولكن هذا شيء يمكن النظر إليه بعد الحقيقة وإعلانه موافق.

لذلك أوصي بسحب المواصفات والتأكد من وجود اختبار إيجابي لكل ميزة (على سبيل المثال ، كل خوارزمية تقول إنها تدعمها ، وحالات حدية لقيم min / max للخيارات الموجودة في تلك الخوارزميات).

الاختبارات السلبية مثل إزالة العناصر المطلوبة (على سبيل المثال ، 4.1 يقول أن SignedInfo عنصر مطلوب لـ Signature ... هل نصدر استثناءً معقولاً إذا كان مفقودًا؟) هي أيضًا جيدة.

اختبارات خيار Canonicalizer ، مثل <foo><!-- hi --></foo> و <foo></foo> (وربما <foo /> ؟) هي نفسها تحت c14n ، لكنها تختلف عن c14n-withcomments . (ربما يتطلب هذا التوقيع في كلا الاتجاهين ، ثم تبادل العناصر ، حيث يجب توقيع خوارزمية تحديد العنوان الأساسي).

اختبارات التحويل. جميع المتعارف عليها هي تحويلات. إلخ.

اختبارات العبث جيدة أيضًا. ولكن إذا كنت تعتقد أنك وجدت اختبارًا للعبث نجح في العبث ، فلا تبلغ عنه هنا أو تلزمه / تدفعه إلى أي نسخة على github (أرسل الاختبار / الحالة / الوصف بالبريد الإلكتروني إلى [email protected]).

حسنًا ، لقد فكرت كثيرًا في هذا اليوم. العودة في إجازة الآن.

شكرًا bartonjs على

karelzbartonjs (على الرغم من مرة واحدة فقط كنت مرة أخرى من عطلة!)steveharter وأي شخص آخر مع رأي:

أنشأanthonylangsworth بعض الاختبارات الأولية كبداية للمناقشة ، ونحن نقدر أي ملاحظات قد تكون لديك حتى الآن.

أرى أن Mono لديها بعض اختبارات SignedXml. يجب تقييمها وفحصها وفقًا لمواصفات xmldigsig ، والاقتراحات التي ذكرها bartonjs سابقًا ، نقلها \ إحضارها. اتصل بي للحصول على معلومات حقوق النشر (العنوان) إذا كان من المنطقي إحضار هذه الاختبارات.

شكرًا - سنلقي نظرة على ذلك :)

شكرا على ذلك ، steveharter . هل يمكنك توفير روابط ، من فضلك؟ هذه يمكن أن تقطع الكثير من اختباراتنا. هل هناك أي حقوق نشر أو اعتبارات أخرى إذا قمنا بتوسيعها أو البناء عليها بدلاً من نسخها حرفيًا؟

anthonylangsworth عند نسخ شفرة المصدر من Mono ، يتعين علينا الاحتفاظ برأس حقوق النشر وتحديثه. أود أن أقترح أولاً عمل نسخة فقط (مع الرؤوس اليمنى ، وربما تعديلات طفيفة). بمجرد حصولنا على الكود في CoreFX ، يمكننا تعديل الكود كما نرغب.

اختبارات anthonylangsworth Mono - https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.cs

شكراsteveharter. لقد بدأت في تحويل الاختبارات من NUnit إلى Xunit .

لقد نشرت هذا لكنني أدركت أنه موجود في

إليك السحر الذي يجب فعله لرؤوس حقوق الطبع والنشر عندما نسحب رمزًا من 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 اختبارًا أحاديًا لا يزال يفشل (ويرجع ذلك أساسًا إلى الإعدادات الافتراضية المتغيرة والقيود الأساسية الصافية). نقدر أي مساعدة للحصول على عمل الاختبارات المتبقية. وإلا فأنا أعمل من خلالهم.

karelzbartonjssteveharter و الطبقة System.Security.Cryptography.CryptoConfig الدول أن العديد من التحويلات XML غير معتمدة على CoreFx (خطوط 281-303 في أسفل DefaultNameHT ).

تتوافق هذه مع URIs المستخدمة بواسطة الفئات في مساحة الاسم System.Security.Cryptography.Xml . كجزء من إضافة System.Security.Cryptography.Xml مرة أخرى إلى .Net Core ، أفترض أنه يجب علينا إعادة هذه العناصر. واسمحوا لي أن أعرف إذا كنت مخطئا.

CC: @ tintoy

anthonylangsworth ، بعض هذه التحويلات ، مثل XmlDsigC14NTransform جيدة ، لكن البعض الآخر ، مثل XmlDsigXsltTransform يعتبر خطيرًا جدًا. بينما يمكنك تمكينها عبر مفتاح التسجيل في .NET Framework الكامل ، فأنا أفضل عدم دعمها على .Net Core. ألق نظرة على KnownCanonicalizationMethods و DefaultSafeTransformMethods في https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptecurity.Xml/src/Security.Cryptography.Xml/src/Security. التحولات التي يجب أن ندعمها.

لم أكن أدرك بالفعل أن مصدر العناصر الخطرة قد تم إدراجه في الميناء. سأصوت لإزالتها تمامًا. لا توجد طريقة آمنة حقًا لاستخدامها.

@ morganbr شكرا على الرؤساء. بمجرد أن أحصل على تغييرات كود XML لقيمة مفتاح RSA و DSA ، سأراجع قائمة التحويلات المضمنة. من المحتمل أن أنشر قائمة وأطلب منك ومن الآخرين مراجعتها.

anthonylangsworth يبدو رائعا!

morganbrAnthonyDGreen تمت مناقشة هذه التحويلات (التي تم تعطيلها في التصحيح MS16-035) مسبقًا في هذا الموضوع عند مناقشة المنفذ. صرح bartonjs في 14 كانون الأول (ديسمبر) أنه يجب إزالة مواد التسجيل. راجع أيضًا التعليق الذي كتبهsteveharter في 15 كانون الأول (ديسمبر) مفاده أنه من المحتمل أن يتم تمكين هذه التحويلات في وقت متأخر وبالتالي يجب نقلها.

steveharterbartonjs هل يمكنك إرضاء الرنين؟

حتى مع عدم وجود دعم للتسجيل ، يمكن لـ CryptoConfig إنشاء تلك التحويلات المرتبطة مؤخرًا باسم السلسلة أو معرف الكائن. ابحث عن "CryptoConfig" في كود SignedXml حيث يتم استخدامه لإنشاء الفئة المناسبة بناءً على محتوى xml.

هذا يعني أنه يجب توسيع فئة CryptoConfig لدعم هذه التحويلات ، على الأقل لنفس الأنواع في netfx على أي حال ، وكذلك بشكل مثالي أيضًا الإسناد الترافقي لتلك ضد Mono. هذا ما لم يكن هناك سبب (لست على علم به) لعدم تضمينهم وعدم ربطهم بـ CryptoConfig ..

FWIW هنا إصدار netfx من CryptoConfig (للمقارنة مع ما هو موجود في corefx): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs ، 20d26e036bc718bc

توجد قائمة "بالتحويلات المسموح بها" وهي (في .NET Framework) قابلة للتوسيع للتوافق الخلفي. بالنسبة لـ .NET Core ، فهي ليست قابلة للتوسعة ، ولكنها مشفرة بشدة لتضمين فقط التحويلات بدون إدخال.

نظرًا لأنه لا يمكنك التحقق من صحة مستند باستخدام تحويلات غير موجودة في قائمة السماح ، فربما لا يكون من المنطقي نقلها. ولكن نظرًا لأن شخصًا ما يمكن أن يستخدم التحويلات خارج سياق SIgnedXml (يريد فقط استخدامها كمحرك تحويل للأغراض العامة) ، فربما يكون من الجيد الحصول عليها.

نظرًا لأننا نتحدث عن إزالة نوع كامل ، فلن يؤدي ذلك إلى حدوث عدم تناسق مع .NET Framework ... لذلك من المحتمل أن أؤيد إزالة أي تحويلات غير موجودة بالفعل في قائمة السماح المشفرة. يمكن تغيير "الإزالة قبل نشر الحزمة" لاحقًا. لا يمكن "نشرها".

bartonjs يضربني عليه. CryptoConfig على قائمة بالتحويلات المسموح بها. اضطررت إلى تعديل هذه الفئة للسماح بالتحويلات في مساحة الاسم الجديدة ، System.Security.Cryptography.Xml . بينما تستخدم بعض التحويلات المسموح بها الاسم الكامل لفئة .Net ، لا يزال CryptoConfig يسمح فقط بقائمة ثابتة.

أفضل عدم تحويل عمليات التحويل التي تحتوي على مشكلات أمنية معروفة ولكن التوافق مع الإصدارات السابقة مهم أيضًا. هل يجب أن نتخذ هذا القرار نيابة عن المطور؟ هل نقوم بتعديل CryptoConfig للسماح ببعض أشكال الامتداد حتى يتمكن المطور من إضافة تحويلات جديدة إذا اختاروا ذلك؟ كيف نتوصل إلى قرار في هذا؟

CryptoConfig ليس العامل المقيد: https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5e5f35835b7/src/System.Security.Cryptography.Xml/src/Security/Cryptigned/Xml/ L787. (على الرغم من ذلك ، إذا كان CryptoConfig لا يزال يستخدم كمصنع للحل ، فيجب أن يكون أي تحويل في كلا المكانين)

الأنواع التي توفر خوارزميات غير موجودة في تلك القائمة (والتي ليست أيضًا متعارف عليها) ليس لها قيمة بشكل فعال.

قد يتطلب السماح بالتمديد إلى القائمة الآمنة واجهة برمجة تطبيقات جديدة ، لذلك فهو من الناحية الفنية خارج نطاق هذا الجهد.

كنت ، شخصياً ، أتجاهل أنواع التحويل التي لا يمكن استخدامها في التحقق من المستندات. سيكون من الصعب اختبارهم.

في الواقع ، كلا من CryptoConfig و DefaultSafeTransformMethods مناسبان. SignatureDescription في CryptoConfig لذلك ، بغض النظر عن القيم الموجودة في DefaultSafeTransformMethods ، لا يمكنك استخدام تحويل إذا لم يتم ذكره في CryptoConfig . يقيد DefaultSafeTransformMethods هذه القائمة ، لذلك ، إذا تم تحديد تحويل في XML ولكن لم يتم إرجاعه بواسطة DefaultSafeTransformMethods ، فإن SignedXml.CheckSignature يُرجع القيمة false.

في التنفيذ الحالي. يطرح CryptoConfig.AddAlgorithm PlatformNotSupportedException ، لذلك لا يمكن للمستخدمين إضافة ما يخصهم. خارج نطاق جهد النقل هذا ، قد يكون من المفيد النظر إلى هذا أو حتى إضافة RemoveAlgorithm في المستقبل.

بعد تعليقي السابق ، وجدت العقار SignedXml.SignatureFormatValidator . يتيح ذلك للمستخدم تحديد خوارزميات التحويل والتجزئة المناسبة. يمكن للمتصل استخدام هذا لتجاوز DefaultSafeTransformMethods ، على سبيل المثال.

كما سألت من قبل ، من يتخذ القرار هنا؟ بصفتي "رجل أمن" ، فإنني أفضل استبعاد الخيارات غير الآمنة. ومع ذلك ، فأنا لا أفهم تمامًا مدى عدم التوافق الذي يمكن أن يحدث.

anthonylangsworth هذه المناقشة جزء من صنع القرار. سيتخذ خبراء المنطقة الذين يتمتعون بأكبر قدر من الخلفية القرار هنا.

توصيتي: إذا كان الإجراء الصحيح مشكوكًا فيه ، فإنني أقترح الإبقاء على الوضع الراهن - اترك الكود كما هو أثناء تمرين الميناء (ربما حتى بدون أي تغطية اختبارية) وقرر لاحقًا ، بشكل منفصل عن تمرين الميناء.

حسنًا ، لقد تجاذبت أطراف الحديث مع بعض الأشخاص داخليًا وأعتقد أن لدي دعامة من الخطة:

• اترك الأنواع علنية. (إنها أنواع عامة وإزالة الأشياء تجعل الناس حزينين).
• لا يمكن (حتى الآن) استخدامها في اختبارات SignedXml الشاملة. (في الحقيقة ، الاختبارات السلبية تبدو جيدة)
• لديهم أعضاء عامون يجب أن يكونوا كافيين لاختبار الوحدة ، لذلك يجب أن نفعل ذلك.
  
  
  
  • وهذا ينطبق على أنواع التحويل الأخرى أيضًا.
  
  
• إذا لم تنجح تحويلات قبول الإدخال ، لسبب ما ، وكل شيء آخر على ما يرام ، فيمكننا معرفة ما يجب فعله حيالها. (كان من الممكن أن ينطبق هذا أيضًا على "إذا كان لديهم تبعيات تجميع معقدة لا يمكن تلبيتها" ، لكننا تجاوزنا بالفعل هذه العقبة).

وإذا / عندما تأتي واجهة برمجة التطبيقات أو أي تكوين آخر لتمكين هذه الأنواع من العمل ، فإن إضافة اختبارات E2E المختارة ستكون سهلة.

tintoyanthonylangsworthpeterwurzinger ما هو وضع فرع الاختبار الخاصة بك؟ هل يمكننا البدء بدمجه؟ يمكنني اختيار الاختبارات الخاصة بك والاستمرار من هناك.

هل يمكنك أيضًا استخدام PTAL على https://github.com/dotnet/corefx/pull/16545 ؟ لقد قمت بتمكين أحد نماذج MSDN

مرحبًا krwq - أعتقد أنه لا تزال هناك بعض الاختبارات التي فشلت ولكن نظرًا لعدم تشغيلها كجزء من عملية

اسمح لي بإجراء محادثة مع anthonylangsworth والعودة إليك.

ملاحظة. dotnet / corefx # 16545 ->: +1:

krwq - أجرى محادثة سريعة معanthonylangsworth. لقد ذكر (وأنا أوافق) أنه بالنظر إلى حجم العمل الذي تم إنجازه ، ربما يكون من الجيد دمج ما لدينا قبل المضي قدمًا. إنه يبني ، وتجتاز معظم الاختبارات ، لكن القليل منها لا يفعل ذلك.

أظن أننا سنحتاج إلى إعادة تعيين الأساس ضد dotnet / corefx # 16545 (وهو ما سأفعله) قبل فتح العلاقات العامة (وهو ما سيفعلهanthonylangsworth ).

سنعود إليك بمجرد أن نكون مستعدين لذلك (نأمل ألا يمض وقت طويل).

krwq للتوسع في ما قالتهtintoy ، بينما لا يزال هناك بعض العمل الذي يتعين القيام به ، تم أيضًا إنجاز الكثير من العمل في نقل الاختبارات الحالية وتوسيعها. على وجه الخصوص ، لقد قمت بالفعل بتغيير CryptoConfig.cs للتعامل مع العديد من الخوارزميات التي ذكرتها. كلنا نريد المضي قدما في هذا. كما أننا لا نريد تكرار عمل بعضنا البعض أو استبداله. لذلك ، نخطط لدمج التغييرات كما هي حتى يتمكن الآخرون من البناء على العمل الذي أنجزناه ، والعثور على جميع الأخطاء لدينا ، ونأمل أن نبدأ في إتقان كل شيء في وقت أقرب.

tintoy هل https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests هو الفرع الوحيد الذي تعمل عليه؟

نعم.

krwq حسنًا ، هناك علاقات عامة مع كمية جيدة من الأشياء من Mono في (وهو أيضًا فرع فرعي من https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests ... ). إذا كنت مهتمًا برمز محدث ، فمن المحتمل أن تلقي نظرة هناك. بقدر ما أستطيع أن أقول هناك ~ 40/340 اختبارا فاشلة.

التقاط جيد ، @ peterwurzinger ، اعتقدت أننا قد دمجنا هذا بالفعل!

تضمين التغريدة لقد فاتني في الواقع. هل ستقوم بدمج ذلك في الفرع الخاص بك ، إلى corefx أو هل تريد مني استلامه والقيام بجميع عمليات الدمج / إعادة التأسيس؟ هل يفتقد أي شيء من اختبارات Mono أم أنه كامل؟ anthonylangsworth - بالنسبة لتغييرات CryptoConfig - تحدثت عن ذلك مع bartonjs - يجب ألا

كانت خطتي الأصلية هي الحصول على عدد قليل من العينات من MSDN وجعلها تعمل جميعًا حتى نتمكن من بدء تجربة الاستخدام التجريبي المبكر. بعد ذلك ، سأقوم بدمج الاختبارات وإصلاحها من فرعك. إذا فشلت بعض الاختبارات ، فيمكننا ببساطة تعطيلها في الوقت الحالي وإصلاحها لاحقًا. دعنا ندمج أشيائك في corefx / master في أسرع وقت ممكن: ابتسم:

شكرا على التحديث ، krwq . إذا استطعت ، يرجى موافاتنا بآخر المستجدات. يساعد على معرفة ما نهدف إليه.

مرحبًا = د

هل هناك أي اختبارات فاشلة؟

@ Jaedson33anthonylangsworthtintoy
فيما يلي القائمة الحالية لأهم القضايا (بشكل تعسفي):
https://github.com/dotnet/corefx/issues؟q=is٪3Aopen+is٪3Aissue+label٪3ASystem.Security.Cryptography.Xml+label٪3A٪22up+for+grabs٪22

@ Jaedson33 نعم ، هم

مرحبًا ، هل لديك أي فكرة عن موعد حدوث ذلك بدون أي خطأ؟

@ Jaedson33 كل جزء من البرنامج به أخطاء: غمزة: هل هناك أي أشياء معينة لا تعمل من أجلك؟

الأمر بسيط: إنه لا يعمل فقط في مشروع UWP الخاص بي 😞

مرحبًا ، أتلقى هذا الخطأ عندما أحاول تشغيل build.cml. هل يمكنك مساعدتي؟

خطأ في الأمر:
C: \ Users \ jaeds \ Source \ Tools \ msbuild.cmd / nologo / verbosity: Min / 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: إعادة الإنشاء / p: التكوين = تصحيح الأخطاء / p: النظام الأساسي = x64 / p: مجموعة أدوات النظام الأساسي = v141. => O sistema n├úo pode encontrar o arquivo especificado. => O sistema n├úo pode encontrar o arquivo especificado
فشل تنفيذ الأمر مع رمز الخروج 1.
فشل إنشاء مشروع بناء مكون أصلي!
فشل تنفيذ الأمر مع رمز الخروج 1.

JaedsonBarbosa هل تجري اختبارات من موجه أوامر المطور؟ (راجع للشغل ، هذا قليل من الوقت الإضافي) لـ UWP - سأحقق فيما إذا كان يمكن القيام بذلك بسعر رخيص إلى حد ما مقابل 2.0 على الرغم من عدم وجود وعود

أفعل ذلك من موجه أوامر المطور لبرنامج Visual Studio 2017

JaedsonBarbosa هل قمت بسحب أحدث التغييرات من جيثب وحاول البناء بعد تنظيف الريبو الخاص بك ( git clean -fdx )؟ الشيء الثاني الذي يجب تجربته هو تقليل طول المسار (أي ضع الريبو الخاص بك تحت C: \ corefx). شيء آخر يجب تجربته هو تنظيف ذاكرة التخزين المؤقت nuget ( %USERPROFILE%\AppData\Local\NuGet و %USERPROFILE%\.nuget )

إذا استمر حدوث ذلك ، فيرجى إنشاء مشكلة منفصلة بالمعلومات:

• نظام التشغيل الخاص بك
• إصدار VS الخاص بك
• الخطوات التي قمت بها بالضبط
• السجل الكامل (إذا كان كبيرًا ضعها في الجوهر)

أعتقد أنه يحدث لأنني أعتقد أن المسار C: / corefx / src / Native /../../ bin / obj / Windows_NT.x64.Debug / native \ install.vcxproj غير صالح.

نظام التشغيل: Windows 10
VS: مجتمع 2017
لقد بدأت للتو موجه أوامر المطور لـ VS 2017 وأدخلت:

cd C:/corefx
build

الآن الخطأ هو:

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

"O sistema n├úo pode encontrar o arquivo" = "تعذر على النظام العثور على الملف المحدد"

أنا أستسلم ، لا يمكنني أن أجعلها تعمل مع 2017 VS.
فهل لديك أي فكرة عن موعد تنزيلها كحزمة NuGet؟

يجب أن تكون قادرًا على استخدام المعاينة من myget.org.
ستكون الحزمة الرسمية جزءًا من موجة .NET Core 2.0 - راجع وصف المعلم 2.0.0 ، 10 مايو هو ZBB (رقم 17619) ، لذلك يجب أن يتبع إصدار RTW "قريبًا" بعده (لم يتم الكشف عن التواريخ الدقيقة علنًا)

karelz هل يمكنك من فضلك أن ترسل لي رابط الحزمة التي تحتوي على System.Security.Cryptography.Xml؟

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

إليك كيفية التطبيق التجريبي 2.0: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

karelz حسنًا ، أريد تثبيت ذلك في مكتبة صف UWP ، ولكن عندما أحاول أن أحصل على هذا الخطأ:

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 غير متوافق مع com uap10.0 (UAP ، الإصدار = v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 دعم أ:

• monoandroid10 (MonoAndroid ، الإصدار = v1.0)
• monotouch10 (MonoTouch ، الإصدار = v1.0)
• netcoreapp2.0 (.NETCoreApp ، الإصدار = v2.0)
• uap10.1 (UAP ، الإصدار = v10.1)
• xamarinios10 (Xamarin.iOS ، الإصدار = v1.0)
• xamarinmac20 (Xamarin.Mac ، الإصدار = v2.0)
• xamarintvos10 (Xamarin.TVOS ، الإصدار = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS ، الإصدار = v1.0)

إنه مشروعي الفعلي. 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 لماذا لا تدمج العلاقات العامة dotnet / corefx # 17969 الآن؟

JaedsonBarbosa لقد تم دمجها للتو ، أعتقد أن الحزمة يجب أن تكون موجودة صباح الغد - نحن عادة لا ندمج إلا إذا كانت العلاقات العامة خضراء على CI - لقد حصلنا على بعض مشكلات OSX CI منذ أمس لذا فقد أصبحت قديمة بعض الشيء

krwq هل يمكنك إعلامي متى يمكن تنزيل حزمة NuGet مع التغييرات؟

حذر JaedsonBarbosa من أن دعم .NET Standard 2.0 في UWP ينزف - لن يكون جزءًا من .NET Core 2.0 - سيكون جزءًا من الإصدار التالي ، المسمى مؤقتًا 2.1. نحن نعمل على بعض من 2.1 عنصر في وقت مبكر وبالتوازي مع 2.0 ، للوقوف على البنية التحتية ، وما إلى ذلك ، حتى نتمكن بعد ذلك من الموازاة بشكل كبير (بعد 10 مايو وهو ZBB الخاص بنا لـ 2.0).
في كلتا الحالتين ، قد تواجه بعض المشكلات في استخدام المكتبة في UWP. قد لا نكون في وضع يمكننا من مساعدتك على الفور. يجب أن نكون قادرين على تقديم المزيد بعد 10 مايو ... فقط تحديد التوقعات.

JaedsonBarbosa يبدو أننا لم ننتج أي إصدار جديد لمدة يومين 😞 يمكنك ملاحظة التغييرات هنا:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
كلما ظهرت حزمة بعد 4/6 ، يجب أن تحتوي على التغيير الذي تحتاجه. سأتحقق اليوم من سبب عدم وجود حزمة - يمكن أن تكون مرتبطة بمشكلات الشبكات التي نواجهها مع إصدارات OSX

تحرير: تأكيد - يتعلق هذا بقضايا شبكات OSX

krwq هل أنت الآن إذا تم حل مشاكل شبكة OSX اليوم؟

إنه يحظر جميع علاقاتنا العامة تقريبًا ، لذا فإن أولويته القصوى ولكن ليس لدينا ETA

حسنًا 👍
لذلك سأستمر في الانتظار.

متى سيكون الجزء 4 جاهزًا؟

JaedsonBarbosa لدينا أهم الأجزاء التي تم اختبارها بالفعل وأثبتت فعاليتها ، مع الاختبار لا توجد نقطة "منتهية" واحدة - يمكنك الحصول على تغطية رمز بنسبة 100٪ ورمز لا يعمل. هل هناك سيناريوهات معينة تهتم بها؟

لا 😃

krwq أتوقع أننا

karelz أشعر بالراحة في الوقت الحالي في الشحن كما هو الحال حيث يتم اختبار جميع سيناريوهات E2E المهمة التي يمكنني التفكير فيها. ما زلت أرغب في زيادة التغطية بحيث يمكن إثبات أن السيناريوهات الأقل شيوعًا (بما في ذلك معالجة الأخطاء) تعمل بشكل صحيح أيضًا على الرغم من أنني لا أتوقع العثور على أي مشكلات حظر 2.0.

بالنسبة لي ، تعني كلمة "تم" أنه لن يقوم أحد بصيانة المكتبة أو تحسينها بعد الآن

حسنًا ، إذا وافق bartonjs على حالة فلنكن عمليين ونغلق هذه المشكلة.
إذا أردنا زيادة تغطية الاختبار (مثل الإصدار 2.0 غير المحظور) ، فيجب علينا إنشاء عنصر عمل منفصل لـ Future.

إذا قمنا بإخراج كل شيء من قائمة الخوارزميات والتحويلات والمتعارف عليه ، فهذا جيد معي.

لذلك أعتقد أنه سيتم إغلاق هذه القضية في النهاية.

حسنًا ، دعنا نتتبع تقدم التغطية من خلال: https://github.com/dotnet/corefx/issues/16829 - اعتقدت أننا نتعامل مع هذا باعتباره مشكلة رئيسية

نعم ، نتعامل معها على أنها مشكلة رئيسية ، ولكن في بعض الأحيان يتعين عليك الإعلان عن إنجاز الأمور ، وإلا فستواجه مشكلة واحدة مفتوحة لكل ميزة تتبع أكبر "القيام بالمزيد" - وهو ما لا يساعد أي شخص حقًا.

إنه مغلق الآن 😢
إذن ... أين يجب أن أطرح أسئلة حول System.Security.Cryptography.Xml؟

أليست إجابةkrwq أعلاه كافية؟
إذا كانت لديك أسئلة أكبر ، فقم بتقديم مشكلة جديدة. إذا كان توضيحًا بسيطًا للإجابة السابقة ، فيمكنك الاحتفاظ بها هنا. إذا لم تكن متأكدًا ، فاسأل هنا وفي أسوأ الأحوال سنطلب منك تقديم مشكلة جديدة ؛-)

krwq يستمر بدون دعم UWP 😞

JaedsonBarbosa هل https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 لا يعمل من أجلك؟ هل يمكنك إرسال خطوات ما تفعله؟

krwq أضع هذا الأمر للتو:
تثبيت حزمة System.Security.Cryptography.Xml - الإصدار 4.4.0- معاينة1-25210-01

هذا هو الخطأ:

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 غير متوافق مع com uap10.0 (UAP ، الإصدار = v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 دعم أ:

• monoandroid10 (MonoAndroid ، الإصدار = v1.0)
• monotouch10 (MonoTouch ، الإصدار = v1.0)
• netcoreapp2.0 (.NETCoreApp ، الإصدار = v2.0)
• uap10.1 (UAP ، الإصدار = v10.1)
• xamarinios10 (Xamarin.iOS ، الإصدار = v1.0)
• xamarinmac20 (Xamarin.Mac ، الإصدار = v2.0)
• xamarintvos10 (Xamarin.TVOS ، الإصدار = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS ، الإصدار = v1.0)

krwq انظر: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01#targetframeworks

مجرد تذكير بما قلته سابقًا: https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
لا أعتقد أنك ستحصل على دعم UWP مع الحزمة. تعتمد الحزمة على .NET Standard 2.0 AFAIK و UWP لا تحتوي على دعم .NET Standard 2.0 حتى الآن - إنه شيء سنعمل عليه من أجل .NET Core 2.1 (يتم إجراء بعض البتات مبكرًا لإلغاء حظر الفريق الأكبر للعمل عليه بعد 5 / 10 ، لكنها لا تعمل بكامل طاقتها).
IMO للحصول على دعم UWP للحزمة ، سيتعين عليك الانتظار 2.1.

karelz فهل تعتقد أنني سأحتاج إلى الانتظار حتى متى؟
هل يمكنني إنشاء مشروع uap10.1؟

نعم ، أعتقد أنك ستحتاج إلى الانتظار حتى ذلك الحين.
ما لم تكن متحمسًا للغاية ويمكنك تجاوز كل مطبات السرعة هذه. كما قلت ، حتى 5/10 ستكون قدرتنا على مساعدتك في أي شيء UWP محدودة للغاية ، لذلك ستكون في الغالب لوحدك 😦. مجرد وضع التوقعات هنا ...

لذلك سأنتظر لأنني لا أستطيع بناء corefx-master باستخدام Visual Studio 2017 😞

karelzkrwq لا يمكنني بناء الحل لأنني أعطيت خطأ ، يمكنك رؤية خطأ 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
- كشف معلومات ABI مترجم CXX - تم
- الكشف عن ميزات تجميع CXX
- الكشف عن ميزات تجميع CXX - تم
- إجراء اختبار COMPILER_HAS_DEPRECATED_ATTR
- أداء الاختبار COMPILER_HAS_DEPRECATED_ATTR - فشل
- إجراء اختبار COMPILER_HAS_DEPRECATED
- أداء الاختبار COMPILER_HAS_DEPRECATED - النجاح
- تم التهيئة
- تم التوليد

أي شخص الآن ما الذي يمكنني فعله لجعله يبني؟

JaedsonBarbosa كيف تبني؟ العملية المعتادة بالنسبة لي هي:

1. افتح cmd.exe
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - سيؤدي هذا إلى تنظيف مستودعك من أي ملفات متبقية (كن حذرًا إذا لم تكن متأكدًا مما يفعله)
5. build أو ./build.sh إذا كنت تستخدم نظام غير Windows

لبناء مكونات أصلية ، تحتاج إلى تثبيت CMake 2.8.12 أو أعلى

هذا دائما يعمل معي

@ Jaedson33 يمكنك أيضًا التحقق من مستندات المساهمين الجدد ومساعدتنا في تحسينها (مرتبطة من صفحة CoreFX الرئيسية)

أنا أستخدم CMake 3.8.
krwq لقد فعلت ما قلته ، وأنا أنتظر حوالي ساعة وهناك فقط تثبيت dotnet cli ... ، كم ساعة في رأيك سأحتاج إلى الانتظار؟

JaedsonBarbosa يجب أن يستغرق الأمر بضع دقائق ، حاول إعادة التشغيل - قد تكون بعض مشكلات الاتصال ، إذا لم تنجح ، يرجى تقديم مشكلة منفصلة في هذا الريبو ، يجب أن يكون شخص ما قادرًا على تعقب ما حدث

krwq أحصل على هذا الخطأ:

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

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

JaedsonBarbosa ، يرجى تقديم مشكلة جديدة كما هو مقترح أعلاه. فقط للتذكير بأننا قد لا نتمكن من تقديم أكبر قدر من دعم استكشاف الأخطاء وإصلاحها لك قبل 5/10 كما نرغب في ذلك.

karelz تعمل الآن 😄
كان التفكير الوحيد الذي قمت به لجعله يبني هو نقل الملفات من C: \ Users \ jaeds \ Source \ Repos \ corefx-master إلى C: \ Users \ jaeds \ Source.
أعتقد أنه يجب أن يكون في README

مرحبًا ، يمكنك الآن استخدام هذه الحزمة في تطبيق UWP ، وهنا نموذج للتطبيق: https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

تضمين التغريدة هل هناك أي شيء من عملك سيكون ذا قيمة للعودة إلى CoreFX؟ (أي الأشياء التي ليست اختراقات مؤقتة)

karelz حسنًا ، أعتقد أنه يمكنك استخدام مشروعي لمعرفة ما يمكنك تبسيطه (أو إزالته) في CoreFX 😄

مرحبا بالجميع ، جهد كبير في نقل هذا!

هل لي أن أسأل لماذا تشير حزمة Nuget إلى .NET Core 2.0 ، بدلاً من .NET Standard 2.0؟ ألا يكون ذلك مفضلًا؟

كان يجب القيام بذلك (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

أظن أنك تنظر إلى المعاينة الرسمية على Nuget
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

وهو موجود فقط في Myget
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

نعم ، هذا ما كنت أبحث عنه. شكرا لك danmosemsft!

leopignataro لا توجد مشكلة ، أنا أشجعك على تجربة البتات من "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 تبدو أفضل نموذج توزيع.