Runtime: System.Security.Cryptography.Xml.SignedXml क्लास जोड़ें

जैसा कि Tratcher द्वारा संदर्भित किया गया है, यह ASP.NET 5 में WsFederation/ADFS के लिए समर्थन जोड़ने के लिए एक अवरोधक है। हम कई एंटरप्राइज़ ASP.NET 4 अनुप्रयोगों के लिए ADFS का व्यापक रूप से उपयोग करते हैं। हम ASP.NET 5 में माइग्रेट करने और WsFederation का उपयोग करने में बहुत रुचि रखते हैं।

@rschiefer @Tratcher ठीक है, यह ... जटिल है।

• ADFS System.Security.Cryptography.Xml.SignedXml का उपयोग नहीं करता है; बल्कि इसके अपने कार्यान्वयन।
  
  
  
  • (यह काफी हद तक मानसिक जालों को धूल चटाने और ADFS के संस्करण 1 के लिए उस टीम में वापस आने को याद रखने से है)
  
  
• System.IdentityModel निश्चित रूप से System.Security.Cryptography.Xml . का उपयोग नहीं करता है
  
  
  
  • (वह 'cuz संदर्भ स्रोत पर उनका स्रोत कोड ऐसा कहता है: मुस्कान :)
  
  
• लोग वास्तव में System.Security.Cryptography.Xml.SignedXml को पसंद नहीं करते हैं क्योंकि यह XmlDocument पर आधारित है, जो कुछ perf मुद्दों की ओर जाता है।
  
  
  
  • ADFS संस्करण XmlReader, IIRC पर आधारित था।
  
  
• इसलिए, संभव है कि लोग जो चाहते हैं, वह है CoreFX, SignedXml का एक नया कार्यान्वयन बनाना।
• लेकिन SignedXml का नया संस्करण SignedXml के पुराने संस्करण के साथ संगत नहीं होगा
• तो कुछ लोग चाहते हैं कि हम पुराने संस्करण को भी रखें।
• तो कुल मिलाकर, लोग वास्तव में दो संस्करण चाहते हैं।
• सिवाय वे पुराने संस्करण को नहीं चाहते हैं।
• सिवाय जब वे करते हैं।

तो हम की पहेली के साथ छोड़ दिया गया है:

• हम उस वर्ग को पोर्ट कर सकते हैं जो वास्तव में कोई नहीं चाहता
• या, हम एक नई चीज़ को रोक सकते हैं और डिज़ाइन कर सकते हैं जिसका शायद कोई उपयोग नहीं करेगा, क्योंकि वे किसी और चीज़ के साथ संगत नहीं हो सकते हैं
• या, सबसे अधिक प्रयास करने के लिए और फिर भी किसी को लाभ न करने के लिए, दोनों करें: मुस्कान:।

@terrajobst -

जाहिरा तौर पर मैं आज सुबह थोड़ा उतावला था। माफ़ करना :)।

हमने निश्चित रूप से पहचान लिया है कि यहां काम करना है, लेकिन हमें नहीं लगता कि मौजूदा सिस्टम.सिक्योरिटी.क्रिप्टोग्राफी.एक्सएमएल कोड को आगे लाना सही उत्तर है। इसके बजाय, यह XmlDSig के लिए एक सामान्य-उद्देश्य कार्यान्वयन इंजीनियर के लिए हमारे बैकलॉग पर आइटम का प्रतिनिधित्व करता है जो तेज़ है और लीगेसी ऑब्जेक्ट मॉडल (जैसे XmlDocument) से बंधा नहीं है।

यह प्रयास कुछ ऐसा नहीं है जिसकी हम .NET Core 1.0 के लिए अपेक्षा कर रहे हैं, केवल इसलिए कि हम अन्य चीजों पर ध्यान केंद्रित कर रहे हैं।

लेकिन, हमें यह बताना कि आप अनुपलब्ध कार्यक्षमता से प्रभावित हैं, चल रही प्राथमिकता में मदद करता है।

मैं https://github.com/KentorIT/authservices पर आधारित ASP.NET Core SAML2 मिडलवेयर बनाने पर विचार कर रहा हूं

मैं निश्चित रूप से इस बात से सहमत हूं कि मौजूदा को नहीं लेना एक अच्छा विचार है। क्या XmlReader API के आधार पर कुछ भी करना संभव होगा? इस तरह XDocument और XmlDocument दोनों का समर्थन किया जा सकता है। System.IdentityModel में उपयोग किए गए लिफाफा पाठक का कार्यान्वयन भी प्रदान करना अच्छा होगा (यदि इसे व्हाइटस्पेस के साथ एक्सएमएल फाइलों का समर्थन करने के लिए सुधार किया गया था ...)

@AndersAbel XmlReader वह जगह है जहाँ मैं शुरू करूँगा, हाँ (जब तक कि XML लोग मुझे नहीं बताते कि कुछ बेहतर है)।

XmlReader के बाद से System.IdentityModel संस्करण किस पर आधारित है, यह करने योग्य होना चाहिए :)।

@bartonjs The System.IdentityModel वैरिएंट काफी सीमित है, हालांकि यह किस रूपांतर में संभाल सकता है। SAML2/WS-Fed कार्य के लिए यह कोई समस्या नहीं होगी, लेकिन एक सामान्य API के रूप में इस पर विचार किया जाना चाहिए कि गैर-लिफ़ाफ़े वाले हस्ताक्षरों और नेस्टेड हस्ताक्षर वाले xml से कैसे निपटें (जैसे हस्ताक्षरित दावा युक्त एक हस्ताक्षरित नमूना प्रतिक्रिया)। साथ ही मुझे लगता है कि System.IdentityModel.EnvelopedSignatureReader सत्यापन करते समय डेटा की प्रतिलिपि बना रहा है। वहां करने में बहुत मजा आता है। अगर मेरे पास समय होता तो मैं इस पर काम करना पसंद करता।

मैं जुआ @bartonjs की सराहना करता

वर्तमान में मेरी कंपनी इससे प्रभावित है। हमारे पास कुछ लीगेसी कोड है जिसे हम .NET कोर पर पोर्ट करने का प्रयास कर रहे हैं जो हस्ताक्षरित XML लाइसेंस फ़ाइलें उत्पन्न करता है और कक्षाओं के इस सेट के बिना हम फंस गए हैं। हम लाइसेंस के आधार के रूप में एक्सएमएल फाइलों से अलग होने के लिए खुले हैं लेकिन इस समय हमें एक अच्छा समाधान नहीं मिला है जो हमारी आवश्यकताओं के अनुरूप हो।

भविष्य में इसे और जोड़ते हुए देखने की उम्मीद है।

मैं प्रमाणित कर सकता हूं कि यह (और थोड़ा संबंधित एक्सएमएल एन्क्रिप्शन भी) हमारे लिए प्रासंगिक है। .NET फ्रेमवर्क में मौजूदा फॉर्म ठीक रहेगा - मेरे दृष्टिकोण से, यहां नवाचार की कोई आवश्यकता नहीं है। कॉपी और पेस्ट कार्यान्वयन का बहुत स्वागत होगा!

क्या वर्तमान में कोई समाधान उपलब्ध है?

जानना चाहेंगे कि @sandersaares ने भी क्या पूछा। अब CoreFX में xml पर हस्ताक्षर करने का कोई अंतर्निहित तरीका नहीं है?

@sandersaares / @ af0l : .NET Core 1.0 के लिए, SignedXml/XmlDSig का कोई अंतर्निहित कार्यान्वयन नहीं है।

यहां टिप्पणियों के आधार पर (और अन्य) हम शायद पुराने एपीआई को लाएंगे, लेकिन हमारे पास 1.0 के लिए ऐसा करने का समय नहीं था।

धन्यवाद @bartonjs , यही कारण है कि मैं कोर पर काम करने के लिए हमारी परियोजना नहीं प्राप्त कर सका। :) यह भी एक बड़ी शर्म की बात है, क्योंकि मुझे आगे बढ़ना अच्छा लगेगा और जब तक यह पूरा नहीं हो जाता। हमें हस्ताक्षरित एक्सएमएल का उपयोग करके सभी भुगतानों को हमारे कर प्राधिकरण को रिपोर्ट करना होगा, इसलिए यह वास्तव में एक शोस्टॉपर है।

इस पर कोई प्रगति? मैं एसएएमएल टोकन सत्यापन के साथ फंस गया हूं जिसके लिए इस सुविधा की आवश्यकता है। धन्यवाद

हाँ, यह भी जानकर अच्छा लगेगा। हमने हस्ताक्षर की आवश्यकता वाली सुविधाओं को निकालने और उन्हें एक अलग वेब एपीआई समाधान में डालने का काम समाप्त कर दिया ...

पहले से ही विचार है कि कौन सा संस्करण लागू किया जाएगा या समाधान

इस बिंदु पर ऐसा लगता है कि सबसे सीधा उत्तर मौजूदा .NET फ्रेमवर्क कार्यान्वयन को .NET कोर में पोर्ट करना है। इसलिए हम इसे अन्य "इसे पोर्ट करना कठिन बना रहे हैं" एपीआई चूक के साथ जोड़ रहे हैं।

विषय के लिए संभावित रूप से प्रासंगिक: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently और https://github.com/sandersaares/ xml-c14n-व्हाट्सएप-दोष। मुझे ऐसा प्रतीत होता है कि कैननिकल एक्सएमएल 1.0 का .NET फ्रेमवर्क कार्यान्वयन गलत है। मुझे आशा है कि मैं गलत हूं लेकिन यदि ऐसा है, तो यह कुछ बालों वाली संगतता प्रश्न पेश कर सकता है।

@sandersaares ने आपके नमूने को देखा और एक्सएमएल पढ़ते समय आपको XmlDocument.PreserveWhiteSpace = true सेट करने की आवश्यकता है यदि इसमें व्हाइटस्पेस है।

@AndersAbel संकेत के लिए धन्यवाद! यह स्थिति को बदल देता है और वास्तव में एक एक्सएमएल स्कीमा मौजूद होने पर पुष्टिकरण को सक्षम बनाता है। एक्सएमएल स्कीमा के बिना, व्यवहार अमान्य रहता है (नए और रोमांचक तरीके से)। मैंने तदनुसार कनेक्ट समस्या और गिटहब रेपो अपडेट किया है।

@bartonjs यदि आप मौजूदा .NET फ्रेमवर्क समाधान को पोर्ट करते हैं, तो कृपया उस बग को ठीक करें जो एकाधिक हस्ताक्षरों के सत्यापन को रोकता है: https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

एफवाईआई अगर यह कार्यान्वयन चरण में आता है तो मेरे पास परीक्षण के साथ यहां एक ताजा खनन पुस्तकालय है, जो एक्सएमएल हस्ताक्षर (दोनों हस्ताक्षर और सत्यापन) और अन्य एक्सएमएल कार्यक्षमता का उपयोग करता है। नेट फ्रेमवर्क - कुछ निर्भरता मुक्त वास्तविक प्राप्त करने के लिए उपयोगी हो सकता है -वर्ल्ड कोड इसके खिलाफ कार्यान्वयन का प्रयास करने के लिए: https://github.com/Axinom/cpix

क्या इस एपीआई के विकास के लिए कोई समयरेखा है?

//cc @bartonjs

@henkmollema कुछ खास नहीं, नहीं। 1.2 रिलीज़ के लिए हम .NET Framework और .NET Core के बीच के अंतर को कम करने के लिए काम कर रहे हैं; और वह प्रयास वर्तमान में है जहां से SignedXml आ रहा है।

मैं आज एक ग्राहक कॉल पर था जिसे ASP.NET कोर पर SAML2-P समर्थन की आवश्यकता है (जो KentorIT के कार्यान्वयन का उपयोग करेगा)। यह उन ग्राहकों के लिए एक अवरुद्ध समस्या है जो ASP.NET Core में जाना चाहते हैं। अभी के लिए मेरे ग्राहक को कटाना पर ही रहना होगा।

मैं देख रहा हूं कि मील का पत्थर 1.2 से फ्यूचर (@bartonjs द्वारा) में बदल दिया गया था। क्या आप टिप्पणी या विस्तृत कर सकते हैं?

मुख्य रूप से यह सिर्फ इस बात से संबंधित है कि हम मील के पत्थर को कैसे ट्रैक कर रहे हैं। हम "हमें उम्मीद है कि यह इसे एक बना देगा" के अधिक करते थे, फिर मील के पत्थर के अंत में हम वह सब कुछ फिर से असाइन करेंगे जो नहीं किया गया था। अब हम यह कहने के लिए वास्तव में कठिन प्रयास कर रहे हैं कि "यदि हमने इसे इस मील के पत्थर के लिए चिह्नित किया है तो इसे पुन: असाइन करने के लिए यह बहुत दुर्लभ होना चाहिए"।

यह १.२ मील के पत्थर के लिए बहुत से अन्य कार्यों से नीचे की ओर है, और यह (मेरे लिए, वैसे भी) हमेशा १.२ के लिए इसे बनाने के लिए थोड़ा सा खिंचाव था। यह अभी भी हमारी "आगे क्या है" सूची में काफी ऊपर है, हम इसे 1.2 रिलीज का हिस्सा होने के लिए 'प्रतिबद्ध' नहीं कर रहे हैं (जो मुख्य रूप से नेटस्टैंडर्ड 2.0 काम, बगफिक्सिंग और कुछ बुनियादी ढांचा परियोजनाएं हैं)।

इसे फ्यूचर के रूप में चिह्नित करना इस बात की गारंटी नहीं देता कि यह 1.2 रिलीज का हिस्सा नहीं होगा , इसका सीधा सा मतलब है (मील का पत्थर की हमारी वर्तमान व्याख्या का उपयोग करके) कि हम इसके लिए रिलीज नहीं रखेंगे। एक बार जब कोई वास्तव में इस पर काम कर रहा होता है, तो इस बात की बेहतर समझ होती है कि यह वास्तव में कब किया जाएगा, और फिर इसे वास्तव में जो भी मील का पत्थर जारी किया जाएगा, उसके रूप में चिह्नित किया जाएगा।

@karelz अगर कुछ भी आप जोड़ना चाहते हैं (या सही) तो झंकार करने के लिए आपका स्वागत है।

हम 1.2 समय सीमा में काम के लिए फंड नहीं दे पाएंगे (अभी बहुत अधिक अन्य चीजें हैं जिनका प्रभाव अधिक है)। इसलिए हमने अपनी योजनाओं को संप्रेषित करने के लिए इसे फ्यूचर माइलस्टोन में स्थानांतरित कर दिया।
हम पूछने की संख्या से अवगत हैं, इसलिए यह हमारे सुरक्षा क्षेत्र के बैकलॉग में अधिक है। यह सामान्य रूप से शीर्ष पूछे जाने वाले corefx लापता API में से एक है (DirectoryServices, SerialPort, आदि के बीच)।

cc: @steveharter @danmosemsft @terrajobst

हमारे जवाब पार हो गए :)
माइलस्टोन्स पर अधिक संदर्भ हमारे इश्यू गाइड में है ।

.NET Framework कोड संदर्भ स्रोत के रूप में उपलब्ध है। इसलिए तकनीकी रूप से पोर्ट को .NET कोर टीम के बाहर भी शुरू किया जा सकता है - अगर लोग यहां हमारी मदद करने के इच्छुक हैं।
@bartonjs के साथ मेरी पिछली चैट से मुझे लगता है कि कुंजी "चुनौती" परीक्षण बनाना/पोर्ट करना होगा।

अरे, उस समस्या के बारे में वास्तविक स्थिति क्या है?

@ जैडसन 33 'समस्या' से

@karelz लेकिन मैं इंतजार नहीं करना चाहता। आप इसे अभी ठीक क्यों नहीं करते?

@ Jaedson33 ऊपर मेरा उत्तर देखें - यह बताता है कि हम इसे अभी निधि क्यों नहीं दे सकते। यह प्राथमिकताओं के बारे में है। ऐसे लोगों की एक कतार है जो अभी कई सुविधाएँ/API चाहते हैं, लेकिन हमारे पास अनंत-आकार की टीम नहीं है, इसलिए हमें प्राथमिकता देनी होगी।

यदि आपको ASAP की वास्तव में बुरी तरह से आवश्यकता है, तो आप हमेशा कोड आधार में योगदान कर सकते हैं, हमें मार्गदर्शन, कोड समीक्षा और प्रतिक्रिया के साथ मदद करने में खुशी होगी।

ठीक है, तो मैं इंतज़ार करूँगा।

@karelz अगर काम को सत्यापित करने के लिए मूल परीक्षण अभी भी उपलब्ध हैं, तो मैं अपना हाथ ऊपर रखने को तैयार हूं :)

(मेरे एक सहकर्मी के पास भी प्रासंगिक अनुभव है इसलिए हम शायद इस पर एक साथ काम करेंगे)

कार्य का मुख्य भाग वास्तव में नई परीक्षण संपत्तियां बनाना है। पुराने परीक्षण अपर्याप्त हैं और खराब कवरेज है। हमें विशिष्टता की समीक्षा करने और प्रत्येक दिलचस्प आवश्यकता के लिए परीक्षण जोड़ने के लिए किसी की आवश्यकता होगी - यही वह जगह है जहां अधिकांश लागत है।

यदि आप अभी भी रुचि रखते हैं, तो हम पूर्ण .NET फ्रेमवर्क से स्रोत कोड को इस रूप में छोड़ने का प्रयास कर सकते हैं - अगला चरण इसे .NET कोर के हिस्से के रूप में जारी करने से पहले इसे निर्मित करना और परीक्षण कवरेज जोड़ना होगा। मुझे बताएं कि क्या आप रुचि रखते हैं ...

ठीक है, हाँ - हम अभी भी रुचि रखते हैं :)

@tintoy मुझे आपकी मदद करने में दिलचस्पी है क्योंकि मुझे वास्तव में उस वर्ग की आवश्यकता है।

@tintoy मुझे आपकी मदद करने में दिलचस्पी है क्योंकि मुझे वास्तव में उस वर्ग की आवश्यकता है।

सुन के अच्छा लगा :)

तो... मैं कैसे मदद कर सकता हूँ?
अवलोकन: यह पहली बार है जब मैं गिटहब का उपयोग कर रहा हूं।

तो... मैं कैसे मदद कर सकता हूँ?

मुझे पहले अपने सहकर्मी से बात करने दो और हम हमले की योजना लेकर आएंगे। @karelz - क्या कोई दिशानिर्देश या अन्य दस्तावेज़ हैं जिन्हें हमें पढ़ने से पहले पढ़ना चाहिए? शुरू करने के लिए, मुझे लगता है कि मेरा सहकर्मी शायद मानक में उतर जाएगा, मैं शायद काम कर रहा हूं जहां कोड को जाने की जरूरत है (और ढांचे के अन्य हिस्सों से मौजूदा परीक्षण प्राप्त करने में क्या शामिल है इससे पहले कि हम करें कोई बदलाव)। क्या यह उचित लगता है?

सीसी: @ एंथनीलैंग्सवर्थ

दायरे को थोड़ा सीमित रखने के लिए मैं MS16-035 (xpath ट्रांसफ़ॉर्म, xslt ट्रांसफ़ॉर्म, बाहरी संदर्भ) द्वारा अक्षम की गई सुविधाओं के बिना शुरू करने की सलाह दूंगा। मुझे नहीं पता कि परिवर्तनों को तोड़ने के लिए कौन सी जगह है, लेकिन DefaultGetIdElement में वर्तमान फ़ॉलबैक तंत्र का उपयोग हस्ताक्षर रैपिंग हमलों में किया जा सकता है। मैं एक अधिक सुरक्षित डिफ़ॉल्ट संस्करण पसंद करूंगा।

यह भी अच्छा होगा यदि आंतरिक एपीआई को एक्सएमएल हस्ताक्षर सत्यापन के दो अलग-अलग कार्यान्वयन के बजाय System.IdentityModel द्वारा उपयोग किए गए लिफाफा हस्ताक्षर रीडर का समर्थन करने के लिए थोड़ा सा पुनर्गठन किया गया था।

अंत में मैं इस बग रिपोर्ट के अनुसार एक एकल बिंदु भी जोड़ना चाहूंगा।

@tintoy मुझे नहीं लगता कि हमारे पास अच्छे दस्तावेज़ हैं। मुझे लगता है कि हमें स्रोतों को जोड़ना चाहिए और फिर हम काम को समानांतर कर सकते हैं - मुझे @bartonjs @steveharter @ianhays के साथ सिंक करने दें।

मैं भी मदद करने के लिए कुछ समय निकालने की कोशिश करूंगा। यदि कल्पना पर कोई प्रश्न हैं और यह कैसे काम करता है, तो मुझे इस पर गौर करने में खुशी होगी - मैंने पहले ही कल्पना की समीक्षा करने में कुछ समय बिताया है।

क्या किसी के पास System.IdentityModel द्वारा उपयोग किए गए SignedXml और EnvelopedSignatureReader को समेकित करने के विचार के बारे में कुछ कहना है?

@AndersAbel

MS16-035 द्वारा अक्षम की गई सुविधाओं के बिना प्रारंभ करें (xpath ट्रांसफ़ॉर्म, xslt ट्रांसफ़ॉर्म, बाहरी संदर्भ)

हमें नवीनतम .NET Framework स्रोत कोड से शुरू करना चाहिए, जो सुरक्षित होना चाहिए। यदि आपको .NET Framework कोड सुरक्षा के बारे में कोई चिंता है, तो कृपया हमें ऑफ़लाइन बताएं।

मुझे नहीं पता कि परिवर्तन तोड़ने के लिए क्या जगह है

कोई जगह नहीं, हमें .NET फ्रेमवर्क से सीधे पोर्ट से शुरुआत करनी चाहिए। कोई और सुधार, परिवर्तन, ब्रेकिंग परिवर्तन आदि पर बाद में विचार किया जा सकता है। प्रारंभिक कार्य के हिस्से के रूप में नहीं। नहीं तो यह हमारे सिर पर चढ़ जाएगा।

DefaultGetIdElement में वर्तमान फ़ॉलबैक तंत्र का उपयोग हस्ताक्षर रैपिंग हमलों में किया जा सकता है

इसे अलग समस्या के रूप में माना जाना चाहिए। @bartonjs क्या आप कृपया टिप्पणी कर सकते हैं?

यह भी अच्छा होगा यदि आंतरिक एपीआई को एक्सएमएल हस्ताक्षर सत्यापन के दो अलग-अलग कार्यान्वयन के बजाय System.IdentityModel द्वारा उपयोग किए गए लिफाफा हस्ताक्षर रीडर का समर्थन करने के लिए थोड़ा सा पुनर्गठन किया गया था।

फिर से, आइए इसे अगले चरण के रूप में लेते हैं, जब हमारे पास अच्छे परीक्षण कवरेज के साथ पूरी तरह कार्यात्मक पोर्ट है।

अंत में मैं इस बग रिपोर्ट के अनुसार एक एकल बिंदु भी जोड़ना चाहूंगा।

कृपया इसे गिटहब पर अलग मुद्दे के रूप में यहां दर्ज करें। आदर्श रूप से हमारे पास कोड यहां पोर्ट किए जाने के बाद (यानी जब बग वास्तव में .NET कोर पर लागू होता है)।

क्या किसी के पास System.IdentityModel द्वारा उपयोग किए गए SignedXml और EnvelopedSignatureReader को समेकित करने के विचार के बारे में कुछ कहना है?

बस दोहराना चाहते हैं। पोर्टिंग के बाद हमें इसे अगला कदम मानना ​​चाहिए।

DefaultGetIdElement में वर्तमान फ़ॉलबैक तंत्र का उपयोग हस्ताक्षर रैपिंग हमलों में किया जा सकता है

इसे अलग समस्या के रूप में माना जाना चाहिए। @bartonjs क्या आप कृपया टिप्पणी कर सकते हैं?

@AndersAbel यदि आपको लगता है कि कोई सुरक्षा चिंता है, तो कृपया https://technet.microsoft.com/en-us/security/ff852094.aspx पर भेद्यता रिपोर्टिंग प्रक्रिया का पालन

क्या किसी के पास System.IdentityModel द्वारा उपयोग किए गए SignedXml और EnvelopedSignatureReader को समेकित करने के विचार के बारे में कुछ कहना है?

यह संभव नहीं है। रिच-डोम XmlDocument के आधार पर SignedXml बहुत भारी (और सार्वजनिक-एपीआई-सहयोगी) है। IdentityModel का प्रतिनिधित्व XmlReader पर आधारित है। लेकिन, एक बार मौजूदा सामान लाने के बाद इसकी जांच की जा सकती है।

मैं भी मदद करने के लिए कुछ समय निकालने की कोशिश करूंगा। यदि कल्पना पर कोई प्रश्न हैं और यह कैसे काम करता है, तो मुझे इस पर गौर करने में खुशी होगी - मैंने पहले ही कल्पना की समीक्षा करने में कुछ समय बिताया है।

@AndersAbel - चीयर्स, मुझे यकीन है कि हम मदद का उपयोग कर सकते हैं :)

@bartonjs मैंने उन मुद्दों की रिपोर्ट [email protected] पर की है , जिसके परिणामस्वरूप MS16-035 हुआ। आईएमओ कुछ शेष जोखिम भरे मुद्दे हैं, हालांकि एमएस ने ठीक नहीं करने का फैसला किया (वे ब्रेकिंग परिवर्तन करेंगे)। मैंने अभी तक विवरण प्रकाशित नहीं किया है, लेकिन यदि आप उन पर निजी तौर पर चर्चा करना चाहते हैं, तो कृपया मुझे मेल करें।

@karelz साफ़ करने के लिए धन्यवाद कि परिवर्तनों को तोड़ने के लिए कोई जगह नहीं है। इसका मतलब है कि समेकन के बारे में मेरे विचार प्रासंगिक नहीं हैं।

MS16-035 द्वारा अक्षम की गई सुविधाओं के बिना प्रारंभ करें (xpath ट्रांसफ़ॉर्म, xslt ट्रांसफ़ॉर्म, बाहरी संदर्भ)

हमें नवीनतम .NET Framework स्रोत कोड से शुरू करना चाहिए, जो सुरक्षित होना चाहिए। यदि आपको .NET Framework कोड सुरक्षा के बारे में कोई चिंता है, तो कृपया हमें ऑफ़लाइन बताएं।

MS16-035 पैच ने SignedXml में कई समस्याओं का समाधान किया। हालांकि पुराने, असुरक्षित व्यवहार पर वापस जाने के लिए रजिस्ट्री कुंजियों का उपयोग करना संभव है। क्या उन विकल्पों को भी .NET Core में पोर्ट किया जाना चाहिए? ऊपर मेरा सुझाव वर्तमान डिफ़ॉल्ट .NET Framework व्यवहार को पोर्ट करने को प्राथमिकता देने के लिए था, उन हिस्सों को छोड़कर जो अभी के लिए डिफ़ॉल्ट रूप से निष्क्रिय हैं। या क्या आपका मतलब यह है कि उन हिस्सों को भी स्थानांतरित करने के लिए महत्वपूर्ण हैं? फिर सवाल है कि कॉन्फ़िगरेशन को कैसे संभालना है क्योंकि .NET कोर AFAIK कॉन्फ़िगरेशन के लिए रजिस्ट्री पर निर्भर नहीं है (क्योंकि यह सभी प्लेटफॉर्म पर उपलब्ध नहीं है)।

हालांकि पुराने, असुरक्षित व्यवहार पर वापस जाने के लिए रजिस्ट्री कुंजियों का उपयोग करना संभव है। क्या उन विकल्पों को भी .NET Core में पोर्ट किया जाना चाहिए?

नहीं। पैकेज उपलब्ध कराए जाने से पहले केवल रजिस्ट्री-संगत-कोड हटा दिया जाएगा।

आप इसे लागू करने के लिए GitHub पर कोई प्रोजेक्ट क्यों नहीं बनाते?

हमने @bartonjs , @steveharter और @ianhays . के साथ समन्वय किया

संपादित करें: निष्पादन योजना सबसे शीर्ष पद पर चली गई।

मुझे अच्छा लगता है :)

@karelz , @steveharter अधिकांश रजिस्ट्री लुकअप Utils वर्ग में स्थित हैं: AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier । SignedXml क्लास में एक लुकअप भी है जहां यह ज्ञात ट्रांसफॉर्म की सूची सेट करता है। रजिस्ट्री संगतता के बिना मुझे नहीं लगता कि XmlDsigXPathTransform और XmlDsigXsltTransform तक पहुँचा जा सकता है। क्या उन्हें रजिस्ट्री-संगत कोड के साथ स्रोत से पूरी तरह हटा दिया जाना चाहिए?

यही वह है जिसके बारे में मैं जानता हूं, मैंने कोड पढ़ते समय किसी अन्य को नहीं देखा है, लेकिन हो सकता है कि मैंने कुछ याद किया हो।

@AndersAbel मैंने रजिस्ट्री के संबंध में कारेल की टिप्पणी को अद्यतन किया। यदि ऐसी कोई कक्षाएं हैं जो पहुंच योग्य नहीं हैं तो हमें यह समझने की जरूरत है कि कौन सी कार्यक्षमता खो रही है। जिन लोगों का आप उल्लेख करते हैं, मेरा मानना ​​​​है कि क्रिप्टोकॉन्फिग को नाम जोड़ने की जरूरत है ऑब्जेक्ट जोड़ी और इस प्रकार देर से बनाई जा सकती है

आपको क्या लगता है कि यह क्लास कब तैयार होगी?

क्या आपका मतलब योगदान के लिए है? @steveharter ने बहुत जल्द प्रारंभिक "स्रोत जोड़ें" पीआर जमा करने की योजना बनाई है (आज सबसे अधिक संभावना है)।

प्रारंभिक कोड अभी विलय कर दिया गया है।

@steveharter धन्यवाद

धन्यवाद @steveharter! मैंने आसान प्रगति ट्रैकिंग के लिए निष्पादन योजना को सबसे शीर्ष पद पर स्थानांतरित कर दिया है। जब भी हम इसमें बदलाव करेंगे, हम यहां एक अन्य उत्तर में परिवर्तनों का उल्लेख करेंगे।

अगर कोई इस पर काम करना शुरू करना चाहता है, तो कृपया ऐसा कहें ताकि दोहराए गए काम से बचा जा सके। हम आपको इस मुद्दे को सह-असाइन करेंगे।

@karelz : @tintoy और मैंने इसे शुरू करने के लिए अपना हाथ ऊपर कर दिया। आपको इसे हमें सौंपने के लिए खुशी है।

अगर कोई इस पर काम करना शुरू करना चाहता है, तो कृपया ऐसा कहें ताकि दोहराए गए काम से बचा जा सके। हम आपको इस मुद्दे को सह-असाइन करेंगे।

चीयर्स - मुझे इसे संकलित करने के लिए शुरुआत करने में खुशी हो रही है :)

@anthonylangsworth - हा, मुझे मारो!

यहां काम हो रहा है ।

@tintoy को सौंपा गया। एक बार जब वह रेपो में योगदानकर्ता का दर्जा स्वीकार कर लेता है, तो मैं इसे @anthonylangsworth को भी सह-असाइन कर दूंगा (जीएच आपको इसके बिना असाइनी विकल्प के रूप में पेश नहीं करेगा)।

धन्यवाद!

@karelz सिर्फ पुष्टि करने के लिए - जो मैं योगदानकर्ता दिशानिर्देशों के बारे में समझता हूं, मैं इन परिवर्तनों को master में करना चाहता हूं?

(मेरा master स्पष्ट रूप से)

एर्घ, क्षमा करें, मुझे फिर से प्रयास करने दें - अंतिम पीआर आपके master विरुद्ध होगा?

हाँ य़ह सही हैं। बस इसे अंतिम चरण तक पूर्ण कोरएफएक्स बिल्ड/टेस्ट रन का हिस्सा न बनाएं।

मुझे कुछ स्थिरांक मिले हैं जो लगता है कि src/Common/src/Interop/Windows/Crypt32/Interop.certificates_types.cs में एक आंतरिक वर्ग में ले जाया गया है। हालांकि यह System.Security.Cryptography.Xml नहीं है। यहां सर्वोत्तम दृष्टिकोण पर कोई विचार?

उनमें से किसकी जरूरत है? उन सभी को?
क्या आप संदर्भ स्रोत की जांच कर सकते हैं यदि वे .NET Fx में सार्वजनिक हैं? (मुझे ऐसा नहीं लगता, लेकिन दोबारा जांच करने में कोई दिक्कत नहीं है)
मैं थोड़ा हैरान हूं कि हम बाकी क्रिप्टो लाइब्रेरी का लाभ उठाने के बजाय विशेष इंटरऑप करते हैं ... या तो इसे कुछ खास चाहिए, या यह ऐतिहासिक कारणों से है ... @steveharter @bartonjs कोई विचार?

@tintoy इस प्रयास के रूप में जिन चीजों को करने की आवश्यकता है उनमें से एक CAPI के साथ प्रत्यक्ष इंटरफेसिंग को हटा रहा है, .NET API का उपयोग करने के लिए स्विच कर रहा है।

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

अभी के लिए मैंने केवल `Interop.certificates_types.cs को असेंबली में संकलित करके और वहां से स्थिरांक को संदर्भित करके CAPI मुद्दे के आसपास काम किया है।

मुझे X509Utils.cs से कुछ विधियों को पूर्ण ढांचे में कॉपी करना पड़ा (मुख्य रूप से हेक्स एन्कोडिंग/डिकोडिंग के साथ करने के लिए) क्योंकि ऐसा करने के लिए 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

मैं इसे कल ठीक कर दूंगा।

@karelz @bartonjs मैं एक पीआर खोलने जा रहा हूं ताकि हम परिवर्तनों पर चर्चा कर सकें (जहां तक ​​​​मैं बता सकता हूं, मूल रूप से काम किया जाता है) - क्या आप इसके साथ ठीक हैं?

मुझे अच्छा लगता है। @steveharter कोई विचार?

नया साल मुबारक हो = डी

क्या आपके पास कोई विचार है कि चरण 2 कब पूरा होगा?

dotnet/corefx#14662 पहले ही मर्ज हो चुका है - वह चरण 2 था। मैं इसे शीर्ष पोस्ट में 'चेक' के रूप में चिह्नित करूंगा।

बस इतना ही मैं स्पष्ट हूं: एक बार उपरोक्त सभी 5 चरणों को पूरा करने के बाद, ASP.NET कोर में ws-fed समर्थन प्राप्त करने के लिए, AAD टीम को अपने SAML टोकन बिट्स करने की आवश्यकता होती है, फिर ASP.NET टीमों को ws बनाने की आवश्यकता होती है। -फेड मिडलवेयर एएडी पीस पर। क्या यह आपकी अपेक्षाओं से मेल खाता है?

नहीं, इस काम का WS-Fed से कोई लेना-देना नहीं है।
मुझे https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500 पर उत्तर और स्पष्टीकरण देना है

FYI करें: उत्तर पोस्ट किया गया: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

तो चरण 4 कब पूरा होगा?

यदि आप पूछ रहे हैं कि .NET टीम के पास इसे प्राप्त करने का समय कब होगा -- हमें अभी तक पता नहीं है। यह हमारे बैकलॉग पर अधिक है, लेकिन कुछ उच्च प्राथमिकताएं हैं जिनसे हमें पहले निपटना होगा।

हम इस बीच समुदाय से अंतरिक्ष में योगदान के लिए खुले हैं।

मुझे इस पर काम करना जारी रखने में खुशी हो रही है, लेकिन मैं इस समय थोड़ा फंस गया हूं; चूंकि corefx नई निर्माण प्रक्रिया में चला गया है, System.Security.Cryptography.Xml अब नहीं बनता है (इसलिए @anthonylangsworth और मुझे कोई भी परीक्षण लिखने से रोक दिया गया है)। अगर हम परियोजना (और परीक्षण परियोजना) के निर्माण में शामिल होने के बारे में एक त्वरित सूचक प्राप्त कर सकते हैं, तो हमें जाना अच्छा होगा :)

पुनश्च. मैंने निर्माण प्रक्रिया के माध्यम से 20 मिनट या उससे अधिक समय बिताया है ताकि यह पता लगाया जा सके कि यह अब क्यों नहीं बनता है, लेकिन अभी तक काम नहीं किया है। कोई भी संकेतक प्रशंसनीय होंगे...

@mellinoe @weshaggard क्या आप SignedXml को नए बिल्ड सिस्टम में माइग्रेट करने के लिए मार्गदर्शन प्रदान कर सकते हैं?

मुझे लगता है कि मुझे इंतजार करना होगा

@tintoy यदि आप मुझे उस शाखा में इंगित करते हैं जिस पर आप वर्तमान में काम कर रहे हैं और आप किस परियोजना को बनाने की कोशिश कर रहे हैं तो मैं भवन प्राप्त करने में मदद कर सकता हूं।

@weshaggard वर्तमान में एक शाखा नहीं है - कोड मास्टर में है, यह सिर्फ रूट बिल्ड (उद्देश्य पर) में नहीं जुड़ा है - src/System.Security.Cryptography.Xml (डॉटनेट/कोरएफएक्स # 14628) में पेश किया गया। @steveharter अतिरिक्त जानकारी प्रदान कर सकता है।

@weshaggard @karelz मुझे हमारे कांटे में एक शाखा बनाने में खुशी हो रही है और केवल हमें अनब्लॉक करने के लिए इसे वहां बनाना है; बाद में, master में इसके फिर से बनने के बाद हम अपने द्वारा किए गए किसी भी परिवर्तन को हमेशा चुन सकते हैं। मुझे बताएं कि क्या यह आपका पसंदीदा तरीका है :)

पीआर https://github.com/dotnet/corefx/pull/15491 को प्रोजेक्ट इंफ्रास्ट्रक्चर काम करना चाहिए। एक बार जब सीआई इसके लिए पास हो जाता है तो हम इसे मर्ज कर सकते हैं और इसे आपके प्रयासों को बूटस्ट्रैप करना चाहिए।

धन्यवाद - मैंने टिंटॉय/कोरएफएक्स/मास्टर को रिबेस किया है और जल्द ही इसके साथ एक नाटक होगा :)

@weshaggard ठीक है, इसलिए दोनों src और test प्रोजेक्ट बिल्ड करते हैं, लेकिन अगर मैं टेस्ट प्रोजेक्ट से सोर्स प्रोजेक्ट ( <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 ==========

मुझे लगता है कि कोरएफएक्स में काम करने के लिए इंटर-प्रोजेक्ट संदर्भ कैसे काम करते हैं, इस बारे में मुझे कुछ याद आया है?

@tintoy मुझे यकीन नहीं है कि वह त्रुटि विशेष रूप से क्या है लेकिन हमें आम तौर पर हमारे नए इंजीनियरिंग सिस्टम में ProjectReferences की आवश्यकता नहीं होती है। परीक्षण निर्माण के लिए हम हमेशा पूर्ण लक्ष्यीकरण पैक का निर्माण और संदर्भ देते हैं, इस मामले में bin\ref\netcoreapp में उत्पादित। उस निर्देशिका में रखी गई लाइब्रेरी वह है जो आप अपने रेफ फ़ोल्डर से बनाते हैं जो वर्तमान में खाली है। तो अपने आप को जाने के लिए आपको एपीआई सतह क्षेत्र के साथ एक रेफरी उत्पन्न करने और रेफ बिल्डिंग प्राप्त करने की आवश्यकता है, फिर आपकी परीक्षण परियोजना स्वचालित रूप से एपीआई देखेगी और उनके खिलाफ निर्माण कर सकती है। हमारे पास जेनापी नामक एक उपकरण है जो किसी अन्य पुस्तकालय के आधार पर रेफरी उत्पन्न कर सकता है। मुझे आप लोगों के लिए एक और पीआर जल्दी से जमा करने दें।

ठीक है, अब मैं समझ गया; परीक्षण प्रोजेक्ट में मुझे कोई प्रकार नहीं दिखाई देने का कारण यह है कि रेफ प्रोजेक्ट में अभी तक कोई प्रकार नहीं है :-)

@weshaggard यदि आपके पास समय नहीं है, तो शायद मैं यह पता लगा सकता हूं कि यह कैसे करना है; मैं उस उपकरण के बारे में दूसरे दिन ही पढ़ रहा था।

मैंने जल्दी से genapi टूल चलाया और उस कमिट को आगे बढ़ाया https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e। इसे लेने के लिए स्वतंत्र महसूस करें या इसे स्वयं पुन: उत्पन्न करें। इसे संकलित करने के लिए आपको प्रोजेक्ट रेफरेंस को अन्य रेफरी में जोड़ना होगा।

चीयर्स - इससे मेरा समय बचेगा, बहुत सराहना की।

@weshaggard सफलता! धन्यवाद, उम्मीद है कि अब हम उन परीक्षणों को लिखना शुरू कर सकते हैं :)

(टिंटॉय @ dd834c63af4fe40faf84bc6a776b474ec9947eb1 , बस डुप्लिकेट को अनदेखा करें)

हां! एक कार्य परीक्षण करें:

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

आपकी मदद के लिए धन्यवाद, @weshaggard!

पुनश्च. मुझे परीक्षण परियोजना गुणों (डीबग टैब) के तहत निष्पादन योग्य पथ ( .user फ़ाइल के माध्यम से) स्थानीय रूप से ओवरराइड करना पड़ा। D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe लेकिन केवल तभी काम किया जब मैंने इसे D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe बदल दिया।

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

मेरा वीएस स्लैश के बारे में शिकायत नहीं करता है। पथ विभाजक आम तौर पर एक दर्द होते हैं क्योंकि हम चीजों को विंडोज़ और यूनिक्स दोनों पर काम करने की कोशिश कर रहे हैं, इसलिए हम विंडोज़ पर मिश्रित स्लैश का एक गुच्छा देखते हैं जो आम तौर पर यूनिक्स की तुलना में अधिक स्वीकार्य है।

जिज्ञासा से बाहर, आप वीएस के किस संस्करण का उपयोग कर रहे हैं? 2015 या 2017? शायद यह 2017 में तय किया गया है :)

(मैं आमतौर पर इन दिनों ओएसएक्स या लिनक्स पर हूं, इसलिए मैं चीजों को क्रॉस-प्लेटफ़ॉर्म अनुकूल बनाने के प्रयास की पूरी तरह से सराहना करता हूं, बीटीडब्लू)

मैं विंडोज 10 पर वीएस 2015 का उपयोग कर रहा हूं और समाधान खोला और परीक्षणों को डीबग करने के लिए F5 कर सकता हूं और मेरा डीबग पथ D:\git\corefx\Tools/testdotnetcli\dotnet.exe

ठीक है, मैं पागल हो रहा होगा - अब मैं इसे पुन: पेश नहीं कर सकता!

इससे पहले, इसने dotnet.exe को खोजने में सक्षम नहीं होने के बारे में शिकायत की, लेकिन यह तब काम करना शुरू कर दिया जब मैंने निष्पादन योग्य को केवल बैकस्लैश वाले पथ पर सेट किया। मैंने अभी-अभी .csproj.user फ़ाइल हटाई है और यह _still_ काम करती है, तो कौन जानता है :-o

नमस्कार दोस्तों, मुझे परीक्षण लिखने में मदद करने में शामिल होना अच्छा लगेगा। योगदान शुरू करने के लिए मैं क्या कर सकता हूं?

बढ़िया - मुझे लगता है कि हम उस स्तर पर हो सकते हैं जहां हम ऐसा करना शुरू कर सकते हैं :)

यह देखने के लिए कि क्या उसने अपना पहला परीक्षण सफलतापूर्वक पूरा किया है, मुझे किसी सहकर्मी से जांच करने दें...

cc: @anthonylangsworth

@करेल्ज़ ,

@anthonylangsworth और मैंने परीक्षण लिखना शुरू कर दिया है ; मुझे पता है कि हम परीक्षण करने की आवश्यकता पर आम सहमति पर नहीं पहुंचे हैं, लेकिन हम किसी भी तरह से शुरू करने जा रहे हैं और फिर जहां भी हम काम करने के लिए सहमत हैं वहां परीक्षण पोर्ट कर देंगे।

और उन लोगों के लिए जिन्होंने स्वेच्छा से परीक्षणों में मदद की है (जिसकी अत्यधिक सराहना की जाती है), हमें अगले सप्ताह की शुरुआत में सुझाए गए कार्य को विभाजित करने की स्थिति में होना चाहिए :)

परीक्षण कवरेज के संबंध में और हमें किन परीक्षणों की आवश्यकता है - @bartonjs की इस पर मजबूत राय थी (क्योंकि उन्हें हमारे पक्ष में प्रकार और इसकी परेशानियों के साथ सबसे अधिक विशेषज्ञता है)। उन्होंने कल्पना द्वारा परीक्षण लिखने का सुझाव दिया (मैंने इसका उल्लेख ऊपर किया है )।
वह अगले सप्ताह के अंत में छुट्टी से वापस आएंगे। हमें शायद उसके साथ विवरण और अपेक्षाओं पर चर्चा करनी चाहिए।
इसके अलावा @AndersAbel ने चर्चा में पहले विशेष विशेषज्ञता और संभावित मदद का उल्लेख किया

cc @steveharter अगर उसके पास अतिरिक्त मार्गदर्शन है जबकि @bartonjs OOF है।

धन्यवाद @tintoy @anthonylangsworth यहां आपके योगदान के लिए! हम वास्तव में इसकी बहुत सराहना करते हैं!
और उन सभी के लिए भी धन्यवाद जो कूदने की योजना बना रहे हैं ;-)

cc @ steveharter अगर उसके पास अतिरिक्त मार्गदर्शन है जबकि @ bartonjs OOF है।

मेरी जिज्ञासा उस बिंदु पर पहुंच गई जिसने संतुष्ट होने की मांग की।
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
मैं अब बेहतर महसूस कर रहा हूं।

😃 मुझे यह भी नहीं पता था कि यह इतना Microsoft विशिष्ट है! आपके मजेदार ज्ञानवर्धन के लिए धन्यवाद

@anthonylangsworth ने टिंटॉय/कोरएफएक्स # 3 में एक कठिन परीक्षण योजना तैयार करना शुरू कर दिया है (मैंने टिप्पणी करना आसान बनाने के लिए उसकी योजना को एक मुद्दे में कॉपी किया है) इसलिए हमारे पास कम से कम चर्चा करने के लिए कुछ है। बेझिझक इसे देखें और प्रतिक्रिया दें :)

सीसी: @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (या कोई भी इससे चिंतित हो सकता है) परीक्षणों के लिए InternalsVisibleToAttribute का उपयोग करने के बारे में नीति क्या है? उस नाम स्थान में बहुत सारे internal वर्ग हैं और पर्याप्त परीक्षण कवरेज प्राप्त करना पूरी तरह से सार्वजनिक तरीकों से मुश्किल हो सकता है। हालांकि, मैं सराहना करता हूं कि अन्य विचार भी हैं।

हम्म , दुख की बात है, मुझे नहीं पता -

मैंने कोरएफएक्स में अन्य कोड के बारे में जो देखा है, उससे संबंधित परियोजनाओं में कभी-कभी अन्य परियोजनाओं से प्रासंगिक स्रोत फाइलें शामिल होती हैं (हालांकि मुझे लगता है कि यह निर्भरता ग्राफ के कारण बहुत जल्दी जटिल हो जाएगा)।

स्मृति से, System.Collections.Immutable [InternalsVisibleTo] का उपयोग करता है, अगर यह कोई मदद है।

उदाहरण के लिए:

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

आम तौर पर अधिक:

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

आप इस पुराने अंक https://github.com/dotnet/corefx/issues/1604 में InternalsVisibleTo पर मेरे विचार देख सकते हैं

परीक्षण के लिए InternalsVisibleToAttribute का उपयोग करने के बारे में नीति क्या है?

नहीं।

उस नाम स्थान के भीतर बहुत सारे आंतरिक वर्ग हैं और पर्याप्त परीक्षण कवरेज प्राप्त करना केवल सार्वजनिक तरीकों से कठिन हो सकता है।

यदि यह एक गहरे अपवाद पथ के अलावा कुछ और है तो इसे पहुंच योग्य या हटा दिया जाना चाहिए। अगर इसे हिट करने के लिए एक मुश्किल परीक्षण केस लेता है, तो ठीक यही हमें चाहिए।

विचाराधीन परियोजनाओं में कभी-कभी अन्य परियोजनाओं से संबंधित स्रोत फ़ाइलें शामिल होती हैं

मान लें कि आपका मतलब है "परीक्षण परियोजनाओं में आंतरिक सदस्यों तक पहुंच प्राप्त करने के लिए उत्पाद स्रोत शामिल है": नहीं।

[InternalsVisibleTo] और स्रोत साझाकरण दोनों विरासत में मिली रणनीतियां हैं। हम में से सबसे मुखर (अनिवार्य रूप से) मानते हैं कि हमारे परीक्षण केवल उन चीजों का प्रतिनिधि होना चाहिए जिनका वास्तविक दुनिया में सामना किया जा सकता है। यदि किसी विशेष ब्लॉक को हिट करने के लिए कोई परीक्षण संभव नहीं है तो यह क्यों मौजूद है? हां, कुछ अपवाद-फेंकने वाले ब्लॉक हैं जिन्हें हिट नहीं किया जा सकता है क्योंकि स्टैक में एक अनावश्यक चेक पहले ही इसे पकड़ चुका है; लेकिन यह कुछ ऐसा है जिसे इस तथ्य के बाद देखा जा सकता है और ठीक घोषित किया जा सकता है।

तो मैं कल्पना को खींचने और यह सुनिश्चित करने

आवश्यक तत्वों को हटाने की तरह नकारात्मक परीक्षण (जैसे 4.1 का कहना है कि SignedInfo के लिए एक आवश्यक तत्व है Signature ... अगर यह कमी है हम एक उचित अपवाद फेंकना करते हैं?) भी अच्छे हैं।

Canonicalizer विकल्प परीक्षण, जैसे <foo><!-- hi --></foo> और <foo></foo> (और शायद <foo /> ?) c14n तहत समान हैं, लेकिन c14n-withcomments तहत अलग हैं। (इसके लिए संभवतः दोनों तरीकों पर हस्ताक्षर करने की आवश्यकता है, फिर निकायों की अदला-बदली, क्योंकि विहित एल्गोरिथ्म पर हस्ताक्षर किए जाने चाहिए)।

परीक्षण रूपांतरण। सभी कैनोनिकलाइज़र ट्रांसफॉर्म हैं। आदि।

छेड़छाड़ परीक्षण भी अच्छे हैं। लेकिन अगर आपको लगता है कि आपको एक छेड़छाड़ परीक्षण मिला है जो सफलतापूर्वक छेड़छाड़ करता है, तो इसे यहां रिपोर्ट न करें या इसे जीथब पर किसी भी रेपो को न दें (परीक्षण/केस/विवरण को सुरक्षित @microsoft.com पर ईमेल करें)।

ठीक है, मैंने उस दिन के लिए बहुत सोचा है। अब वापस छुट्टी पर।

छुट्टी पर रहते हुए आपकी अंतर्दृष्टि के लिए धन्यवाद @bartonjs ! अब जाओ और असली दुनिया में कुछ मजा करो ;-)

@karelz @bartonjs (हालाँकि केवल एक बार जब आप छुट्टी से वापस आ जाते हैं!) @steveharter और कोई और एक राय के साथ:

@anthonylangsworth ने चर्चा-शुरुआत के रूप में कुछ प्रारंभिक परीक्षण किए हैं , और हम अब तक आपके पास किसी भी प्रतिक्रिया की सराहना करेंगे।

मैं देखता हूं कि मोनो में कुछ SignedXml परीक्षण हैं। इनका मूल्यांकन किया जाना चाहिए और xmldigsig spec के खिलाफ जांच की जानी चाहिए, सुझाव है कि @bartonjs पहले उल्लेख किया गया है, और वर्तमान कोड यह देखने के लिए कि क्या वे पोर्ट करने के लिए उपयुक्त हैं। कॉपीराइट (हेडर) जानकारी के लिए मुझे पिंग करें यदि इन परीक्षणों को लाने के लिए समझ में आता है।

धन्यवाद - हम उस पर एक नज़र डालेंगे :)

इसके लिए धन्यवाद, @steveharter । क्या आप कृपया लिंक प्रदान कर सकते हैं? ये हमारे बहुत से परीक्षण को छोटा कर सकते हैं। क्या कोई कॉपीराइट या अन्य विचार हैं यदि हम उन्हें शब्दशः कॉपी करने के बजाय उनका विस्तार या निर्माण करते हैं?

@anthonylangsworth मोनो से सोर्स कोड कॉपी करते समय, हमें कॉपीराइट हेडर रखना और अपडेट करना होगा। मैं सुझाव दूंगा कि पहले केवल एक प्रति करें (दाएं शीर्षलेखों के साथ, संभावित रूप से मामूली बदलाव)। एक बार हमारे पास CoreFX में कोड हो जाने के बाद, हम अपनी इच्छानुसार कोड को संशोधित कर सकते हैं।

@anthonylangsworth मोनो परीक्षण - https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.cs

धन्यवाद, @steveharter। मैंने परीक्षणों को NUnit से Xunit में परिवर्तित करना शुरू कर दिया है।

मैंने इसे पोस्ट किया लेकिन महसूस किया कि यह @anthonylangsworth के रेपो में है:

जब हम मोनो से कोड खींचते हैं, तो कॉपीराइट हेडर के लिए यह जादू है:

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.

क्या इस परियोजना में कोई असफल परीक्षण हैं?

@ जैडसन ३३ हम वर्तमान में मोनो परीक्षणों को परिवर्तित कर रहे हैं। मुझे अभी तक कोई असफल परीक्षण नहीं मिला है जो कोड त्रुटियों को इंगित करता है लेकिन हमारे पास अभी भी कई परीक्षण हैं।

@anthonylangsworth मैं मदद के लिए क्या कर सकता हूं?

@ Jaedson33 मैंने उस प्रश्न का उत्तर https://github.com/tintoy/corefx/issues/6#issuecomment -280904587 पर दिया है। संक्षेप में, हमारे पास 84 मोनो परीक्षण अभी भी विफल हो रहे हैं (मुख्य रूप से बदली हुई चूक और .नेट कोर सीमाओं के कारण)। शेष परीक्षणों को काम करने में कोई मदद की सराहना की जाती है। अन्यथा, मैं उनके माध्यम से काम कर रहा हूं।

@karelz @bartonjs @steveharter The System.Security.Cryptography.CryptoConfig वर्ग बताता है कि CoreFx पर कई XML रूपांतरण समर्थित नहीं हैं ( DefaultNameHT के निचले भाग में 281 से 303 पंक्तियाँ)।

ये System.Security.Cryptography.Xml नेमस्पेस में कक्षाओं द्वारा उपयोग किए जाने वाले यूआरआई के अनुरूप हैं। System.Security.Cryptography.Xml को .Net Core में वापस जोड़ने के हिस्से के रूप में, मुझे लगता है कि हमें इन्हें बहाल करना चाहिए। कृपया मुझे बताएं कि क्या मुझसे गलती हुई है।

सीसी: @tintoy

@anthonylangsworth , उनमें से कुछ परिवर्तन, जैसे XmlDsigC14NTransform ठीक हैं, लेकिन अन्य, जैसे XmlDsigXsltTransform को बहुत खतरनाक माना जाता है। जबकि आप उन्हें पूर्ण .NET फ्रेमवर्क में रजिस्ट्री कुंजी ऑप्ट-इन के माध्यम से सक्षम कर सकते हैं, मैं इसके बजाय .Net Core पर उनका समर्थन नहीं करूंगा। https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Src/System/Security/SignedXml/SignedXml के लिए ज्ञात कैननिकलाइज़ेशन विधियों और DefaultSafeTransformMethods पर एक नज़र डालें। जिन परिवर्तनों का हमें समर्थन करना चाहिए।

मुझे नहीं पता था कि खतरनाक लोगों का स्रोत वास्तव में बंदरगाह में शामिल हो गया था। मैं उन्हें पूरी तरह से हटाने के लिए वोट दूंगा। वास्तव में उनका उपयोग करने का कोई सुरक्षित तरीका नहीं है।

@morganbr सिर

@anthonylangsworth बहुत अच्छा लगता है!

@morganbr @AnthonyDGreen वे परिवर्तन (जो MS16-035 पैच में अक्षम किए गए थे) पोर्ट पर चर्चा करते समय इस थ्रेड में पहले चर्चा की गई है। @bartonjs ने 14 दिसंबर को कहा कि reg-compat सामग्री को हटा दिया जाना चाहिए। 15 दिसंबर को @steveharter द्वारा टिप्पणी भी देखें कि उन परिवर्तनों को शायद देर से बाध्य किया जा सकता है और इस प्रकार पोर्ट किया जाना चाहिए।

@steveharter @bartonjs क्या आप कृपया

यहां तक ​​​​कि रजिस्ट्री समर्थन के बिना, क्रिप्टोकॉन्फिग उन ट्रांसफ़ॉर्म को स्ट्रिंग नाम या ओआईडी द्वारा लेट-बाउंड बना सकता है। SignedXml कोड में 'CryptoConfig' खोजें क्योंकि इसका उपयोग xml सामग्री के आधार पर उपयुक्त वर्ग बनाने के लिए किया जाता है।

इसका मतलब है कि इन परिवर्तनों का समर्थन करने के लिए क्रिप्टोकॉन्फिग क्लास को बढ़ाया जाना चाहिए, कम से कम उसी प्रकार के लिए netfx में, और आदर्श रूप से मोनो के खिलाफ क्रॉस-रेफरेंस भी। यह तब तक है जब तक कोई कारण नहीं है (जिसके बारे में मुझे जानकारी नहीं है) उन्हें शामिल न करें और उन्हें क्रिप्टोकॉन्फिग से न जोड़ें।

FWIW यहाँ CryptoConfig का netfx संस्करण है (इसकी तुलना corefx में क्या है): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs ,20d26e036bc718bc

"अनुमत परिवर्तन" की एक सूची है जो (.NET फ्रेमवर्क में) रजिस्ट्री-बैक-कंपैट के लिए एक्स्टेंसिबल है। .NET कोर के लिए यह एक्स्टेंसिबल नहीं है, लेकिन केवल नो-इनपुट ट्रांसफॉर्म को शामिल करने के लिए हार्ड कोड किया गया है।

चूंकि आप किसी दस्तावेज़ को ट्रांसफ़ॉर्म का उपयोग करके मान्य नहीं कर सकते हैं जो अनुमति-सूची में नहीं है, हो सकता है कि उन्हें पोर्ट करने का कोई मतलब न हो। लेकिन चूंकि कोई SignedXml के संदर्भ के बाहर ट्रांसफॉर्म का उपयोग कर सकता है (केवल उन्हें सामान्य उद्देश्य ट्रांसफॉर्म इंजन के रूप में उपयोग करना चाहता है) शायद उन्हें रखना ठीक है।

चूंकि हम एक पूरे प्रकार को हटाने के बारे में बात कर रहे हैं, यह .NET Framework के साथ असंगतता पैदा नहीं करेगा ... इसलिए शायद मैं हार्ड-कोडेड अनुमति सूची पर पहले से मौजूद किसी भी ट्रांसफॉर्म को हटाने का समर्थन नहीं करता। "पैकेज प्रकाशित करने से पहले निकालें" को बाद में बदला जा सकता है। "उन्हें प्रकाशित करें" नहीं कर सकता।

@bartonjs ने मुझे इसके लिए हराया। CryptoConfig में अनुमत रूपांतरणों की एक सूची है। मुझे उस वर्ग को नए नामस्थान में परिवर्तन की अनुमति देने के लिए संशोधित करना पड़ा, System.Security.Cryptography.Xml । जबकि कुछ अनुमत रूपांतरण .Net वर्ग के पूर्ण नाम का उपयोग करते हैं, CryptoConfig अभी भी केवल एक निश्चित सूची की अनुमति देता है।

मैं उन परिवर्तनों को पोर्ट नहीं करना पसंद करूंगा जिनके पास सुरक्षा संबंधी समस्याएं हैं, लेकिन पश्च संगतता भी महत्वपूर्ण है। क्या हमें यह निर्णय डेवलपर की ओर से करना चाहिए? क्या हम किसी प्रकार के विस्तार की अनुमति देने के लिए CryptoConfig को संशोधित करते हैं ताकि कोई डेवलपर यदि चाहें तो नए परिवर्तन जोड़ सकता है? हम इस पर किसी निर्णय पर कैसे पहुँचते हैं?

क्रिप्टोकॉन्फिग सीमित कारक नहीं है: https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SignedXml। एल७८७. (हालांकि, यदि क्रिप्टोकॉन्फिग को अभी भी संकल्प के लिए कारखाने के रूप में उपयोग किया जा रहा है तो किसी भी परिवर्तन को दोनों जगहों पर होना चाहिए)

एल्गोरिदम प्रदान करने वाले प्रकार उस सूची में नहीं हैं (जो कि कैनोनिकलाइज़र भी नहीं हैं) प्रभावी रूप से कोई मूल्य नहीं है।

सुरक्षित सूची में विस्तार की अनुमति के लिए नए एपीआई की आवश्यकता होगी, इसलिए तकनीकी रूप से इस प्रयास के दायरे से बाहर है।

मैं व्यक्तिगत रूप से उन रूपांतरण प्रकारों को छोड़ दूंगा जिनका उपयोग दस्तावेज़ सत्यापन में नहीं किया जा सकता है। उनका परीक्षण करना कठिन होगा।

दरअसल, CryptoConfig और DefaultSafeTransformMethods दोनों ही प्रासंगिक हैं। SignatureDescription निर्माण में किया जाता है CryptoConfig में मानों पर ध्यान दिए बिना, इसलिए DefaultSafeTransformMethods , आप एक को बदलने अगर यह में उल्लेख नहीं है का उपयोग नहीं कर सकते हैं CryptoConfig । DefaultSafeTransformMethods उस सूची को प्रतिबंधित करता है, इसलिए यदि एक परिवर्तन एक्सएमएल में निर्दिष्ट है लेकिन DefaultSafeTransformMethods द्वारा वापस नहीं किया गया है, तो SignedXml.CheckSignature झूठी वापसी करता है।

वर्तमान कार्यान्वयन में। CryptoConfig.AddAlgorithm एक PlatformNotSupportedException CryptoConfig.AddAlgorithm फेंकता है, इसलिए उपयोगकर्ता अपना खुद का नहीं जोड़ सकते हैं। इस पोर्टिंग प्रयास के दायरे से परे लेकिन यह देखने लायक हो सकता है या भविष्य में RemoveAlgorithm भी जोड़ सकता है।

मेरी पिछली टिप्पणी के बाद, मुझे संपत्ति मिली SignedXml.SignatureFormatValidator । यह उपयोगकर्ता को यह निर्दिष्ट करने की अनुमति देता है कि कौन से परिवर्तन और हैश एल्गोरिदम उपयुक्त हैं। उदाहरण के लिए, कॉलर इसका उपयोग DefaultSafeTransformMethods को ओवरराइड करने के लिए कर सकता है।

जैसा कि मैंने पहले पूछा, यहाँ निर्णय कौन करता है? एक "सुरक्षा आदमी" के रूप में, मेरी प्राथमिकता असुरक्षित विकल्पों को बाहर करना होगा। हालाँकि, मैं पूरी तरह से यह नहीं समझता कि यह किस हद तक असंगति का मामला हो सकता है।

@anthonylangsworth यह चर्चा निर्णय लेने का हिस्सा है। सबसे अधिक पृष्ठभूमि वाले क्षेत्र विशेषज्ञ यहां निर्णय लेंगे।

मेरी सिफारिश: यदि यह संदेहास्पद है कि सही कार्रवाई क्या है, तो मैं यथास्थिति बनाए रखने का सुझाव दूंगा - पोर्ट अभ्यास के दौरान कोड को छोड़ दें (संभावित रूप से बिना किसी परीक्षण कवरेज के भी) और बाद में निर्णय लें, पोर्ट अभ्यास से अलग।

ठीक है, इसलिए मैंने कुछ लोगों के साथ आंतरिक रूप से बातचीत की और मुझे लगता है कि मेरे पास एक योजना का आधार है:

• प्रकारों को सार्वजनिक के रूप में छोड़ दें। (वे सार्वजनिक प्रकार के हैं, और चीजों को हटाने से लोग दुखी होते हैं)।
• इनका उपयोग (अभी तक) एंड-टू-एंड SignedXml परीक्षणों में नहीं किया जा सकता है। (वास्तव में, नकारात्मक परीक्षण अच्छे लगते हैं)
• उनके पास सार्वजनिक सदस्य हैं जो इकाई परीक्षण के लिए पर्याप्त होना चाहिए, इसलिए हमें ऐसा करना चाहिए।
  
  
  
  • और वह बाकी ट्रांसफॉर्म प्रकारों के लिए भी जाता है।
  
  
• अगर, किसी कारण से, इनपुट-स्वीकार करने वाले ट्रांसफ़ॉर्म काम नहीं करते हैं, और बाकी सब ठीक है, तो हम यह पता लगा सकते हैं कि उनके बारे में क्या करना है। (यह "यदि उनके पास जटिल संकलन निर्भरताएं थीं जिन्हें पूरा नहीं किया जा सकता" पर भी लागू होता, लेकिन हम पहले से ही उस बाधा को पार कर चुके हैं)।

और अगर/जब एपीआई या अन्य कॉन्फ़िगरेशन इन प्रकारों को काम करने में सक्षम बनाता है, तो ऑप्ट-इन E2E परीक्षणों को जोड़ना आसान होगा।

@tintoy @anthonylangsworth @peterwurzinger आपकी परीक्षण शाखा की स्थिति क्या है? क्या हम इसे मर्ज करना शुरू कर सकते हैं? मैं चेरी आपके परीक्षण चुन सकता हूं और वहां से आगे बढ़ सकता हूं।

क्या आप https://github.com/dotnet/corefx/pull/16545 पर भी PTAL कर सकते हैं? मैंने 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 ठीक है, मोनो से अच्छी मात्रा में सामान के साथ एक पीआर है (जो https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests से उप-शाखा भी है ... ) यदि आप अप-टू-डेट कोड में रुचि रखते हैं, तो आपको शायद वहां एक नज़र डालनी चाहिए। जहाँ तक मैं बता सकता हूँ ~ ४०/३४० परीक्षण विफल हो रहे हैं।

अच्छा कैच, @peterwurzinger , मुझे लगा कि हम पहले ही उसे मर्ज कर देंगे!

@peterwurzinger @anthonylangsworth यह पीआर बहुत अच्छा है! मैंने वास्तव में इसे याद किया है। क्या आप इसे अपनी शाखा में, कोरएफएक्स में विलय कर रहे हैं या क्या आप चाहते हैं कि मैं इसे उठाऊं और सभी विलय/रिबेस करूं? क्या इसमें मोनो परीक्षणों से कुछ छूट जाता है या यह पूर्ण है? @anthonylangsworth - CryptoConfig परिवर्तनों के लिए - मैंने इसके बारे में @bartonjs के साथ बात की - हमें उस फ़ाइल को नहीं छूना चाहिए - यह पहले से ही काफी बदसूरत है।

मेरी मूल योजना एमएसडीएन से कुछ नमूने प्राप्त करने और उन सभी को काम करने की थी ताकि हम जल्दी कुत्ते के भोजन शुरू कर सकें। उसके बाद मैं आपकी शाखा से परीक्षणों का विलय और निर्धारण करूँगा। यदि आपको कुछ परीक्षण विफल हो जाते हैं तो हम उन्हें अभी के लिए अक्षम कर सकते हैं और बाद में उन्हें ठीक कर सकते हैं। आइए अपनी सामग्री को कोरएफएक्स/मास्टर ASAP में मर्ज करें: मुस्कान:

अपडेट के लिए धन्यवाद, @krwq । यदि आप कर सकते हैं, तो कृपया हमें अप टू डेट रखें। यह जानने में मदद करता है कि हमारा लक्ष्य क्या है।

हाय = डी

क्या कोई असफल परीक्षण हैं?

@Jaedson33 @anthonylangsworth @tintoy
यहाँ (मनमाने ढंग से) सबसे महत्वपूर्ण मुद्दों की वर्तमान सूची है:
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@ Jaedson33 हाँ, वे वर्तमान में अक्षम हैं। ऊपर आपको एक मोटा विचार देना चाहिए कि हम कहाँ हैं

नमस्ते, क्या आपके पास कोई विचार है कि यह बिना किसी त्रुटि के कब होगा?

@ Jaedson33 सॉफ्टवेयर के हर टुकड़े में त्रुटियां हैं: पलक: क्या कोई विशेष चीजें हैं जो आपके लिए काम नहीं करती हैं?

यह आसान है: यह मेरे यूडब्ल्यूपी प्रोजेक्ट में काम नहीं करता है

नमस्ते, जब मैं build.cml चलाने का प्रयास करता हूं तो मुझे यह त्रुटि मिल रही है। क्या आप मेरी मदद कर सकते हैं?

आदेश में त्रुटि:
C:\Users\jaeds\Source\Tools\msbuild.cmd /nologo /verbosity:minimal /clp:Summary /maxcpucount /nodeReuse:false /l:BinClashLogger,Tools\net46\Microsoft.DotNet.Build.Tasks.dll;LogFile =binclash.log /p:ConfigurationGroup=डीबग /p:BuildPackages=false /flp:v=सामान्य /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. => ओ सिस्टेमा नो पॉड एनकॉन्टरर या आर्किवो एस्पेसिफिकैडो
निकास कोड 1 के साथ कमांड निष्पादन विफल रहा।
मूल घटक निर्माण परियोजना उत्पन्न करने में विफल!
निकास कोड 1 के साथ कमांड निष्पादन विफल रहा।

@JaedsonBarbosa क्या आप डेवलपर कमांड प्रॉम्प्ट से परीक्षण चला रहे हैं? (बीटीडब्ल्यू यह थोड़ा ओटी है) यूडब्ल्यूपी के लिए - मैं जांच करूँगा कि क्या यह 2.0 के लिए काफी सस्ता किया जा सकता है, हालांकि कोई वादा नहीं है

मैं विजुअल स्टूडियो 2017 के लिए डेवलपर कमांड प्रॉम्प्ट से ऐसा कर रहा हूं

@JaedsonBarbosa क्या आपने git clean -fdx ) को साफ करने के बाद निर्माण करने का प्रयास किया है? कोशिश करने की दूसरी बात पथ की लंबाई को कम करना है (यानी अपना रेपो C:\corefx के अंतर्गत रखें)। कोशिश करने की एक और चीज है नगेट कैश को साफ करना ( %USERPROFILE%\AppData\Local\NuGet और %USERPROFILE%\.nuget )

यदि अभी भी हो रहा है तो कृपया जानकारी के साथ एक अलग मुद्दा बनाएं:

• आपका ओएस
• आपका वीएस संस्करण
• सटीक कदम आपने किया
• पूर्ण लॉग (यदि बड़ा है तो इसे जिस्ट पर रखें)

मुझे लगता है कि ऐसा इसलिए होता है क्योंकि मुझे लगता है कि पथ C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj मान्य नहीं है।

ओएस: विंडोज 10
वी.एस.: २०१७ समुदाय
मैं अभी वीएस 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!

"ओ सिस्टेमा नो पॉड एनकॉन्टर ओ आर्किवो"="सिस्टम निर्दिष्ट फाइल नहीं ढूंढ सका"

मैं हार मानता हूं, मैं इसे 2017 वीएस के साथ काम नहीं कर सकता।
तो क्या आपको पता है कि इसे 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 ठीक है, मैं इसे यूडब्ल्यूपी कक्षा पुस्तकालय में स्थापित करना चाहता हूं, लेकिन जब मैं कोशिश करता हूं कि मुझे वह त्रुटि मिलती है:

ओ पैकोटे सिस्टम.सिक्योरिटी.क्रिप्टोग्राफी.एक्सएमएल 4.4.0-पूर्वावलोकन1-25205-01 कोई भी कॉम्पेटिबल कॉम यूएपी10.0 (यूएपी, वर्जन=v10.0) नहीं है। हे पैकोटे सिस्टम। सुरक्षा। क्रिप्टोग्राफी। एक्सएमएल
४.४.०-पूर्वावलोकन१-२५२०५-०१ का समर्थन करें:

• monoandroid10 (मोनोएंड्रॉयड,संस्करण=v1.0)
• मोनोटच 10 (मोनो टच, संस्करण = v1.0)
• netcoreapp2.0 (.NETCoreApp,संस्करण=v2.0)
• uap10.1 (यूएपी, संस्करण = v10.1)
• xamarinios10 (Xamarin.iOS, संस्करण = v1.0)
• xamarinmac20 (Xamarin.Mac,Version=v2.0)
• xamarinvos10 (Xamarin.TVOS, संस्करण = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS,Version=v1.0)

यह मेरा वास्तविक प्रोजेक्ट है।जेसन:

{
  "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 , हम वर्तमान में उस पुस्तकालय के लिए यूएपी का समर्थन नहीं करते हैं, आपको तब तक इंतजार करना होगा जब तक https://github.com/dotnet/corefx/pull/17969 विलय नहीं हो जाता और नया पैकेज तैयार नहीं हो जाता।

ठीक है, मैं इंतज़ार करना जारी रखूँगा
@krwq लेकिन...

@krwq अब आप PR dotnet/corefx#17969 को मर्ज क्यों नहीं करते?

@JaedsonBarbosa यह अभी विलय हो गया है, मेरा मानना ​​​​है कि पैकेज कल सुबह होना चाहिए - हम आम तौर पर तब तक विलय नहीं करते जब तक कि पीआर सीआई पर हरा न हो - हमें कल से कुछ ओएसएक्स सीआई मुद्दे मिले, इसलिए यह थोड़ा सा पुराना हो गया

@krwq क्या आप मुझे

@JaedsonBarbosa को चेतावनी दी
किसी भी तरह से, आपको UWP में लाइब्रेरी का उपयोग करने में कुछ समस्याएँ आ सकती हैं। हो सकता है कि हम आपकी तुरंत मदद करने की स्थिति में न हों। हमें 10 मई के बाद और अधिक मदद करने में सक्षम होना चाहिए। ... बस अपेक्षाएं निर्धारित करना।

@JaedsonBarbosa ऐसा लगता है कि हमने 2 दिनों के लिए कोई नया संस्करण नहीं बनाया है आप यहां परिवर्तन देख सकते हैं:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
जब भी कोई पैकेज 4/6 के बाद प्रकट होता है तो उसमें वह परिवर्तन होना चाहिए जिसकी आपको आवश्यकता है। मैं आज जांच करूंगा कि कोई पैकेज क्यों नहीं था - यह नेटवर्किंग मुद्दों से संबंधित हो सकता है जो हमारे पास OSX बिल्ड के साथ है

संपादित करें: पुष्टि करना - यह OSX नेटवर्किंग मुद्दों से संबंधित है

@krwq क्या अब आप ओएसएक्स नेटवर्क के मुद्दों को आज हल कर देंगे?

यह हमारे लगभग सभी पीआर को अवरुद्ध कर रहा है इसलिए इसकी उच्च प्राथमिकता है लेकिन हमारे पास ईटीए नहीं है

ठीक है
तो मैं इंतजार करता रहूंगा।

भाग 4 कब तैयार होगा?

@JaedsonBarbosa हमारे पास पहले से ही परीक्षण किए गए और काम करने वाले सबसे महत्वपूर्ण हिस्से हैं, परीक्षण के साथ कोई भी "समाप्त" बिंदु नहीं है - आपके पास 100% कोड कवरेज और कोड हो सकता है जो काम नहीं करता है। क्या कोई विशेष परिदृश्य है जिसमें आप रुचि रखते हैं?

नहीं

@krwq मुझे उम्मीद है कि हम पुस्तकालय के लिए किए गए कामों की घोषणा करेंगे, जब हम इसे स्थिर रूप से शिपिंग करने में सहज होंगे। जब हम ऐसा करते हैं, तो हम बॉक्स को चेक कर सकते हैं और इस मुद्दे को बंद कर सकते हैं। तो हम परीक्षण के लिहाज से कितनी दूर हैं?

@karelz मैं वर्तमान में आरामदायक शिपिंग कर रहा हूं क्योंकि सभी महत्वपूर्ण E2E परिदृश्यों के बारे में मैं सोच सकता हूं कि परीक्षण किया गया है। मैं अभी भी कवरेज बढ़ाना चाहता हूं ताकि कम लोकप्रिय परिदृश्य (त्रुटि प्रबंधन सहित) सही ढंग से काम कर रहे साबित हो सकें, हालांकि मुझे 2.0 अवरुद्ध मुद्दों को खोजने की उम्मीद नहीं है।

मेरे लिए "किया" का अर्थ है कि अब कोई भी पुस्तकालय का रखरखाव या सुधार नहीं करेगा

ठीक है, अगर @bartonjs रेडी-टू-शिप-स्टेट से सहमत हैं, तो आइए व्यावहारिक
यदि हम परीक्षण कवरेज बढ़ाना चाहते हैं (गैर-अवरुद्ध 2.0 के रूप में), तो हमें भविष्य के लिए अलग कार्य आइटम बनाना चाहिए।

अगर हमने एल्गोरिदम और ट्रांसफ़ॉर्म और कैनोनिकलाइज़र की सूची से सब कुछ हटा दिया है, तो यह मेरे लिए अच्छा है।

इसलिए मुझे लगता है कि यह मुद्दा आखिरकार बंद हो जाएगा।

ठीक है, आइए इसके साथ कवरेज की प्रगति को ट्रैक करें: https://github.com/dotnet/corefx/issues/16829 - मैंने सोचा कि हम इसे एक मास्टर मुद्दे के रूप में देखते हैं

हां, हम इसे मास्टर इश्यू के रूप में देखते हैं, लेकिन कभी-कभी आपको किए गए कामों को घोषित करना पड़ता है, अन्यथा आपके पास "और करें" पर नज़र रखने वाली हर बड़ी सुविधा के लिए 1 खुला मुद्दा होगा - जो वास्तव में किसी की मदद नहीं कर रहा है।

यह अब बंद हो गया है
तो... मैं System.Security.Cryptography.Xml के बारे में प्रश्न कहाँ पूछूँ?

क्या @krwq का उत्तर पर्याप्त नहीं है?
यदि आपके कोई बड़े प्रश्न हैं, तो एक नया मुद्दा दर्ज करें। यदि यह पिछले उत्तर का छोटा स्पष्टीकरण है, तो आप इसे यहां रख सकते हैं। यदि सुनिश्चित नहीं है, तो यहां पूछें और सबसे खराब स्थिति में हम आपको एक नया मुद्दा दर्ज करने के लिए कहेंगे ;-)

@krwq यह UWP के समर्थन के बिना जारी है

@JaedsonBarbosa https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 आपके लिए काम नहीं करता है? क्या आप जो कर रहे हैं उसके चरण भेज सकते हैं?

@krwq मैंने अभी वह आदेश दिया है:
इंस्टाल-पैकेज सिस्टम.सिक्योरिटी.क्रिप्टोग्राफी.एक्सएमएल-वर्जन 4.4.0-पूर्वावलोकन1-25210-01

वह त्रुटि है:

ओ पैकोटे सिस्टम.सिक्योरिटी.क्रिप्टोग्राफी.एक्सएमएल 4.4.0-पूर्वावलोकन1-25210-01 कोई भी कॉम्पेटिबल कॉम यूएपी10.0 (यूएपी, वर्जन=v10.0) नहीं है। हे पैकोटे सिस्टम। सुरक्षा। क्रिप्टोग्राफी। एक्सएमएल
४.४.०-पूर्वावलोकन१-२५२१०-०१ का समर्थन करें:

• monoandroid10 (मोनोएंड्रॉयड,संस्करण=v1.0)
• मोनोटच 10 (मोनो टच, संस्करण = v1.0)
• netcoreapp2.0 (.NETCoreApp,संस्करण=v2.0)
• uap10.1 (यूएपी, संस्करण = v10.1)
• xamarinios10 (Xamarin.iOS, संस्करण = v1.0)
• xamarinmac20 (Xamarin.Mac,Version=v2.0)
• xamarinvos10 (Xamarin.TVOS, संस्करण = v1.0)
• xamarinwatchos10 (Xamarin.WatchOS,Version=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
मुझे नहीं लगता कि आपको पैकेज के साथ यूडब्ल्यूपी का समर्थन मिलेगा। पैकेज .NET मानक 2.0 AFAIK पर निर्भर करता है और UWP के पास अभी तक .NET मानक 2.0 समर्थन नहीं है - यह कुछ ऐसा है जिस पर हम .NET Core 2.1 के लिए काम करेंगे (कुछ बिट्स को 5 के बाद इस पर काम करने के लिए बड़ी टीम को अनब्लॉक करने के लिए जल्दी किया जाता है। /10, लेकिन यह पूरी तरह कार्यात्मक नहीं है)।
आईएमओ को पैकेज के लिए यूडब्ल्यूपी समर्थन प्राप्त करने के लिए आपको 2.1.0 पर इंतजार करना होगा।

@karelz तो क्या आपको लगता है कि मुझे कब तक इंतजार करना होगा?
क्या मैं uap10.1 प्रोजेक्ट बना सकता हूं?

हां, मुझे लगता है कि आपको तब तक इंतजार करना होगा।
जब तक आप अति-प्रेरित न हों और इन सभी गति बाधाओं के माध्यम से इसे बना सकें। जैसा कि मैंने कहा, 5/10 तक यूडब्ल्यूपी के साथ आपकी मदद करने की हमारी क्षमता बहुत सीमित होगी, इसलिए आप ज्यादातर अपने दम पर होंगे। बस यहां उम्मीदें स्थापित कर रहे हैं ...

इसलिए मैं इंतजार करूंगा क्योंकि मैं विजुअल स्टूडियो 2017 के साथ कोरएफएक्स-मास्टर नहीं बना सकता

@karelz @krwq मैं समाधान नहीं बना सकता क्योंकि मैं एक त्रुटि देता हूं, आप यहां CMakeError देख सकते हैं:
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
कृपया मेरी मदद करें
पुनश्च: यह पुर्तगाली में है, लेकिन आप इसे पढ़ने के लिए अनुवादक का उपयोग कर सकते हैं

मुझे लगता है कि असफल होना अच्छा नहीं है:
--सी संकलक पहचान MSVC 19.0.24218.2 . है
-- CXX कंपाइलर की पहचान MSVC 19.0.24218.2 . है
- काम कर रहे सी कंपाइलर की जांच करें: सी:/प्रोग्राम फाइल्स (x86)/माइक्रोसॉफ्ट विजुअल स्टूडियो/साझा/14.0/वीसी/बिन/amd64/cl.exe
- काम कर रहे सी कंपाइलर की जांच करें: सी:/प्रोग्राम फाइल्स (x86)/माइक्रोसॉफ्ट विजुअल स्टूडियो/साझा/14.0/वीसी/बिन/amd64/cl.exe - काम करता है
- सी कंपाइलर एबीआई जानकारी का पता लगाना
- सी कंपाइलर एबीआई जानकारी का पता लगाना - किया गया
-- काम कर रहे CXX कंपाइलर के लिए जाँच करें: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe
-- काम कर रहे CXX कंपाइलर के लिए जाँच करें: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe -- काम करता है
- CXX कंपाइलर ABI जानकारी का पता लगाना
- CXX कंपाइलर ABI जानकारी का पता लगाना - किया गया
- CXX संकलन सुविधाओं का पता लगाना
- CXX संकलन सुविधाओं का पता लगाना - किया गया
-- परीक्षण करना COMPILER_HAS_DEPRECATED_ATTR
-- परीक्षण करना COMPILER_HAS_DEPRECATED_ATTR - विफल
-- परीक्षण कर रहा है COMPILER_HAS_DEPRECATED
-- परीक्षण COMPILER_HAS_DEPRECATED निष्पादित करना - सफल
-- विन्यास हो गया
-- जनरेट कर रहा है

कोई भी अब मैं इसे बनाने के लिए क्या कर सकता हूं?

@JaedsonBarbosa आप कैसे निर्माण करते हैं? मेरे लिए नियमित प्रक्रिया है:

1. cmd.exe खोलें
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - यह किसी भी बचे हुए फाइलों के आपके भंडार को साफ कर देगा (सावधान रहें यदि आप सुनिश्चित नहीं हैं कि यह क्या करता है)
5. build या ./build.sh अगर आप गैर-खिड़कियों पर हैं

देशी घटकों के निर्माण के लिए आपको सीएमके 2.8.12 या उच्चतर स्थापित करने की आवश्यकता है

यह हमेशा मेरे लिए काम किया है।

@ Jaedson33 आप हमारे नए-योगदानकर्ता डॉक्स (CoreFX मुख्य पृष्ठ से जुड़े हुए) को बेहतर बनाने में हमारी मदद कर सकते हैं।

मैं सीएमके 3.8 का उपयोग कर रहा हूँ।
@krwq मैंने वही किया जो आपने कहा था, और मैं लगभग 1 घंटे इंतजार कर रहा हूं और बस

@JaedsonBarbosa में कुछ मिनट लग सकते हैं, पुनः आरंभ करने का प्रयास करें - यह कुछ कनेक्शन समस्याएँ हो सकती हैं, यदि काम नहीं करता है तो कृपया इस रेपो में एक अलग समस्या दर्ज करें, किसी को यह पता लगाने में सक्षम होना चाहिए कि क्या हुआ है

@krwq मुझे यह त्रुटि मिलती है:

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

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

@JaedsonBarbosa कृपया ऊपर बताए अनुसार एक नया मुद्दा दर्ज करें। बस एक अनुस्मारक कि हम 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 मानक 2.0 के बजाय .NET Core 2.0 का संदर्भ क्यों दे रहा है? क्या इसे प्राथमिकता नहीं दी जाएगी?

यह किया जाना चाहिए था (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

मुझे लगता है कि आप Nuget . पर आधिकारिक पूर्वावलोकन देख रहे हैं
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

और यह केवल Myget . के पास है
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

हाँ, मैं वही देख रहा था। धन्यवाद, @danmosemsft!

@leopignataro कोई समस्या नहीं है, मैं आपको "सिर" से बिट्स आज़माने के लिए प्रोत्साहित करता हूं - आप उन्हें यहां होमपेज से प्राप्त कर सकते हैं https://github.com/dotnet/cli ... आप चाहें तो बस ज़िप डाउनलोड कर सकते हैं। अगर आपको समस्याएं मिलती हैं तो हमें बताएं -- रिलीज से पहले उन्हें ठीक करने के लिए हमारे पास कुछ ही समय बचा है।

FYI करें: यहां समय-सारिणी के बारे में जानकारी दी गई है: 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 फ्रेमवर्क के लिए है और यह पहले से ही डॉट नेट कोर v2 में शामिल है। यह डॉट नेट कोर v2 में इस नाम स्थान को नहीं पहचान रहा है। क्या मैंने यह गलत सुना? धन्यवाद।

@fletchsod-डेवलपर पैकेज मुख्य रूप से .NET कोर के लिए है। लेकिन अगर आप इसे .NET मानक को लक्षित करने वाले पुस्तकालय से संदर्भित करते हैं तो यह .NET फ्रेमवर्क पर .NET फ्रेमवर्क संस्करण के साथ एकीकृत हो जाएगा, और .NET कोर पर पैकेज के भीतर से कोड चलाएगा।

हमारे पास SignedXml को .NET कोर के लिए डिफ़ॉल्ट इंस्टॉल अनुभव में डालने की कोई योजना नहीं है; यह पर्याप्त है कि NuGet पर एक अलग पैकेज होने के नाते सबसे अच्छा वितरण मॉडल लगता है।