Runtime: Tambahkan kelas System.Security.Cryptography.Xml.SignedXml

Seperti yang dirujuk oleh Tratcher, ini adalah pemblokir untuk menambahkan dukungan untuk WsFederation/ADFS di ASP.NET 5. Kami menggunakan ADFS secara ekstensif untuk banyak aplikasi ASP.NET 4 perusahaan. Kami sangat tertarik untuk bermigrasi ke ASP.NET 5 dan menggunakan WsFederation.

@rschiefer @Tratcher Yah, itu... rumit.

• ADFS tidak menggunakan System.Security.Cryptography.Xml.SignedXml; melainkan implementasinya sendiri.
  
  
  
  • (Itu sebagian besar dari membersihkan jaring laba-laba mental dan mengingat kembali berada di tim itu untuk versi 1 ADFS)
  
  
• System.IdentityModel jelas tidak menggunakan System.Security.Cryptography.Xml
  
  
  
  • (Itu karena kode sumber mereka di sumber referensi mengatakan demikian: senyum :)
  
  
• Orang tidak terlalu menyukai System.Security.Cryptography.Xml.SignedXml karena didasarkan pada XmlDocument, yang menyebabkan beberapa masalah kinerja.
  
  
  
  • Versi ADFS didasarkan pada XmlReader, IIRC.
  
  
• Jadi, kemungkinan yang diinginkan orang adalah CoreFX membuat implementasi baru dari SignedXml.
• Tetapi versi baru dari SignedXml tidak akan kompatibel dengan versi lama dari SignedXml
• Jadi beberapa orang mungkin ingin kita tetap menggunakan versi lama juga.
• Jadi secara keseluruhan, orang sangat menginginkan dua versi.
• Kecuali mereka tidak menginginkan versi lama.
• Kecuali ketika mereka melakukannya.

Jadi kita dibiarkan dengan teka-teki:

• Kami dapat mem-porting kelas yang tidak diinginkan oleh siapa pun
• Atau, kita bisa berhenti dan merancang sesuatu yang benar-benar baru yang mungkin tidak akan digunakan oleh siapa pun, karena tidak kompatibel dengan yang lain.
• Atau, untuk berusaha semaksimal mungkin dan tetap tidak menguntungkan siapa pun, lakukan keduanya : smile:.

@terrajobst - fyi

Rupanya pagi ini saya agak cerewet. Maaf :).

Kami telah mengidentifikasi dengan pasti bahwa ada pekerjaan yang harus dilakukan di sini, tetapi kami tidak berpikir bahwa jawaban yang tepat adalah menampilkan kode System.Security.Cryptography.Xml yang ada. Sebaliknya, ini mewakili item pada backlog kami untuk merancang implementasi tujuan umum untuk XmlDSig yang cepat dan tidak terikat pada model objek lama (misalnya XmlDocument).

Upaya itu bukanlah sesuatu yang kami harapkan untuk dilakukan untuk .NET Core 1.0, hanya karena kami fokus pada hal lain.

Namun, memberi tahu kami bahwa Anda terpengaruh oleh fungsi yang hilang akan membantu dengan prioritas berkelanjutan.

Saya sedang mencari untuk membuat Middleware ASP.NET Core SAML2, berdasarkan https://github.com/KentorIT/authservices. Tanpa port SignedXml itu tidak akan dapat berjalan pada kerangka kerja Core.

Saya benar-benar setuju bahwa tidak membawa yang sudah ada adalah ide yang bagus. Apakah mungkin melakukan sesuatu berdasarkan XmlReader API? Dengan begitu XDocument dan XmlDocument dapat didukung. Juga menyediakan implementasi pembaca terbungkus yang digunakan dalam System.IdentityModel akan lebih baik (jika ditingkatkan untuk mendukung file XML dengan spasi...)

@AndersAbel XmlReader adalah tempat saya memulai, ya (kecuali orang-orang XML memberi tahu saya ada sesuatu yang lebih baik).

Karena XmlReader berbasis pada varian System.IdentityModel, itu harus bisa dilakukan :).

@bartonjs Varian System.IdentityModel cukup terbatas meskipun dalam transformasi apa yang dapat ditanganinya. Untuk pekerjaan SAML2/WS-Fed, itu tidak akan menjadi masalah, tetapi sebagai API umum, itu harus dipertimbangkan bagaimana menangani tanda tangan yang tidak terbungkus dan xml yang berisi tanda tangan bersarang (seperti respons saml yang ditandatangani yang berisi pernyataan yang ditandatangani). Saya juga berpikir bahwa System.IdentityModel.EnvelopedSignatureReader menyalin data saat melakukan validasi. Ada banyak kesenangan yang bisa dilakukan di sana. Jika saya punya waktu saya ingin sekali mengerjakannya.

Saya menghargai @bartonjs yang bertele-tele, membantu melihat apa yang terjadi di balik layar.

Saat ini perusahaan saya terkena dampaknya. Kami memiliki beberapa kode lama yang kami coba porting ke .NET Core yang menghasilkan file lisensi XML yang ditandatangani dan tanpa kumpulan kelas ini, kami macet. Kami terbuka untuk menyimpang dari file XML sebagai dasar untuk lisensi tetapi pada saat ini kami belum menemukan solusi yang baik yang sesuai dengan kebutuhan kami.

Menantikan untuk melihat ini ditambahkan di masa mendatang.

Saya dapat membuktikan bahwa ini (dan juga Enkripsi XML yang sedikit terkait) relevan bagi kami. Bentuk yang ada di .NET Framework akan baik-baik saja - tidak perlu inovasi di sini, dari sudut pandang saya. Implementasi salin & tempel akan sangat disambut!

Apakah saat ini ada solusi yang tersedia?

Ingin tahu apa yang ditanyakan @sandersaares juga. Tidak ada cara bawaan untuk menandatangani xml di CoreFX sekarang?

@sandersaares / @af0l : Tidak ada, untuk .NET Core 1.0, implementasi bawaan SignedXml/XmlDSig.

Berdasarkan komentar di sini (dan lainnya) kami mungkin hanya akan membawa API lama, tetapi kami tidak punya waktu untuk mewujudkannya untuk 1.0.

Terima kasih @bartonjs , itu pasti alasan saya tidak bisa membuat proyek kami bekerja di Core. :) Ini juga sangat disayangkan, karena saya ingin terus maju dan tidak bisa sampai selesai. Kami harus melaporkan semua pembayaran ke otoritas pajak kami menggunakan xml yang ditandatangani, jadi ini benar-benar penghalang.

Ada kemajuan dalam hal ini? Saya terjebak dengan validasi token SAML yang memerlukan fitur ini. Terima kasih

Yeah, akan suka tahu itu juga. Kami akhirnya mengekstrak fitur yang membutuhkan tanda tangan dan memasukkannya ke dalam solusi API web terpisah...

Sudah punya ide versi mana yang akan diimplementasikan atau solusinya

Pada titik ini tampaknya jawaban yang paling mudah adalah mem-port implementasi .NET Framework yang ada ke .NET Core. Jadi kami menggabungkan ini dengan penghilangan API "membuat sulit untuk porting" lainnya.

Berpotensi relevan dengan topik: https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently dan https://github.com/sandersaares/ xml-c14n-whitespace-cacat. Tampaknya bagi saya bahwa implementasi .NET Framework dari Canonical XML 1.0 tidak benar. Saya harap saya salah tetapi jika demikian, ini mungkin memperkenalkan beberapa pertanyaan kompatibilitas berbulu.

@sandersaares Melihat sampel Anda dan Anda perlu mengatur XmlDocument.PreserveWhiteSpace = true saat membaca Xml jika berisi spasi.

@AndersAbel Terima kasih atas petunjuknya! Itu mengubah situasi dan benar-benar memungkinkan validasi yang sesuai jika Skema XML hadir. Tanpa Skema XML, perilaku tetap tidak valid (dengan cara baru dan menarik). Saya telah memperbarui masalah Connect dan repo GitHub yang sesuai.

@bartonjs Jika Anda https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

FYI jika ini sampai ke tahap implementasi maka saya memiliki perpustakaan yang baru dicetak di sini, dengan tes, yang menggunakan tanda tangan XML (baik menandatangani dan memverifikasi) dan fungsionalitas XML lainnya di .NET Framework - mungkin berguna untuk mendapatkan beberapa nyata bebas ketergantungan -kode dunia untuk mencoba implementasi terhadap: https://github.com/Axinom/cpix

Apakah ada timeline untuk pengembangan API ini?

//cc @bartonjs

@henkmollema Tidak ada yang spesifik, tidak. Untuk rilis 1.2 kami sedang berupaya untuk memperkecil jarak antara .NET Framework dan .NET Core; dan upaya itu saat ini adalah asal dari SignedXml.

Saya sedang melakukan panggilan pelanggan hari ini yang membutuhkan dukungan SAML2-P di ASP.NET Core (yang akan menggunakan implementasi KentorIT). Ini adalah masalah pemblokiran bagi pelanggan yang ingin pindah ke ASP.NET Core. Untuk saat ini pelanggan saya harus tetap menggunakan Katana.

Saya melihat tonggak sejarah diubah dari 1,2 menjadi Masa Depan (oleh @bartonjs). Bisakah Anda berkomentar atau menguraikan?

Terutama itu hanya berkaitan dengan bagaimana kami melacak tonggak sejarah. Kami dulu melakukan lebih banyak "kami berharap ini akan berhasil", lalu di akhir pencapaian kami akan menetapkan ulang semua yang belum selesai. Kami sekarang berusaha sangat keras untuk mengatakan "jika kami menandainya untuk tonggak sejarah ini, itu akan sangat jarang untuk ditugaskan kembali".

Ini adalah hilir dari banyak pekerjaan lain untuk tonggak 1,2, dan itu (bagi saya, bagaimanapun) selalu sedikit peregangan untuk membuatnya untuk 1,2. Itu masih cukup tinggi di daftar "apa selanjutnya" kami, kami hanya tidak 'berkomitmen' untuk menjadi bagian dari rilis 1.2 (yang terutama merupakan pekerjaan netstandard2.0, perbaikan bug, dan beberapa proyek infrastruktur).

Menandainya sebagai Masa Depan tidak menjamin bahwa itu tidak akan menjadi bagian dari rilis 1.2, itu hanya berarti (menggunakan interpretasi kami saat ini tentang tonggak sejarah) bahwa kami tidak akan menahan rilis untuk itu. Setelah seseorang benar-benar mengerjakannya, maka ada pemahaman yang lebih baik tentang kapan itu akan benar-benar selesai, dan kemudian itu akan ditandai sebagai tonggak sejarah apa pun yang sebenarnya akan dirilis.

@karelz Jika ada yang ingin Anda tambahkan (atau koreksi) silakan bergabung.

Kami tidak akan dapat mendanai pekerjaan dalam jangka waktu 1,2 (terlalu banyak hal lain dengan dampak yang lebih tinggi untuk diselesaikan). itulah mengapa kami memindahkannya ke tonggak masa depan, untuk mengomunikasikan rencana kami.
Kami mengetahui jumlah permintaan, itulah sebabnya tingginya backlog area Keamanan kami. Ini juga merupakan salah satu API corefx yang paling banyak ditanyakan secara umum (di antara DirectoryServices, SerialPort, dll.).

cc: @steveharter @danmosemsft @terrajobst

Jawaban kami menyeberang :)
Lebih banyak konteks tentang Milestones ada di panduan masalah kami.

Kode .NET Framework tersedia sebagai sumber referensi . Jadi secara teknis port dapat dimulai bahkan di luar tim .NET Core - jika orang tertarik untuk membantu kami di sini.
Dari obrolan saya sebelumnya dengan @bartonjs, saya pikir "tantangan" kuncinya adalah membuat/memindahkan tes.

Hei, bagaimana situasi sebenarnya tentang masalah itu?

@Jaedson33 apa yang Anda maksud dengan 'masalah'? Jika maksud Anda kapan akan diperbaiki -- lihat jawaban dari minggu lalu.

@karelz Tapi saya tidak mau menunggu. Mengapa Anda tidak memperbaikinya sekarang?

@Jaedson33 lihat balasan saya di atas - ini menjelaskan mengapa kami tidak dapat mendanainya sekarang. Ini tentang prioritas. Ada sederet orang yang menginginkan banyak fitur/API sekarang, tetapi kami tidak memiliki tim dengan ukuran tak terbatas, jadi kami harus memprioritaskan.

Jika Anda sangat membutuhkannya ASAP, Anda selalu dapat berkontribusi pada basis kode, kami akan dengan senang hati membantu dengan panduan, ulasan kode, dan umpan balik.

Oke, jadi saya akan menunggu.

@karelz jika tes asli masih tersedia untuk memverifikasi pekerjaan, saya bersedia mengangkat tangan :)

(salah satu rekan kerja saya juga memiliki pengalaman yang relevan sehingga kami mungkin akan mengerjakannya bersama)

Bagian penting dari pekerjaan ini sebenarnya adalah membuat aset pengujian baru. Tes lama tidak mencukupi dan memiliki cakupan yang buruk. Kami akan membutuhkan seseorang untuk meninjau spesifikasi dan menambahkan tes untuk setiap persyaratan yang menarik -- di situlah sebagian besar biayanya.

Jika Anda masih tertarik, kami dapat mencoba memasukkan kode sumber dari .NET Framework lengkap apa adanya - langkah selanjutnya adalah membuatnya dibangun dan menambahkan cakupan pengujian, sebelum dapat dirilis sebagai bagian dari .NET Core. Beritahu saya jika Anda tertarik ...

Oke, ya - kami masih tertarik :)

@tintoy saya tertarik untuk membantu anda karena saya sangat membutuhkan kelas tersebut.

@tintoy saya tertarik untuk membantu anda karena saya sangat membutuhkan kelas tersebut.

Senang mendengarnya :)

Jadi... Bagaimana saya bisa membantu?
Obs: Ini pertama kalinya saya menggunakan GitHub.

Jadi... Bagaimana saya bisa membantu?

Biarkan saya mengobrol dulu dengan rekan kerja saya dan kami akan membuat rencana serangan. @karelz - apakah ada pedoman atau dokumen lain yang harus kita baca sebelum masuk? Untuk memulainya, saya kira rekan kerja saya mungkin akan mengikuti standar, saya mungkin akan mencari tahu ke mana kode harus pergi (dan apa yang terlibat dalam menjalankan tes yang ada dari bagian lain dari kerangka kerja sebelum kita membuat setiap perubahan). Apakah itu terdengar masuk akal?

CC: @anthonylangsworth

Untuk menjaga ruang lingkup sedikit terbatas, saya sarankan untuk memulai tanpa fitur yang dinonaktifkan oleh MS16-035 (transformasi xpath, transformasi xslt, referensi eksternal). Saya tidak tahu ruang apa yang ada untuk mengubah perubahan, tetapi mekanisme mundur saat ini di DefaultGetIdElement dapat dieksploitasi dalam serangan pembungkusan tanda tangan. Saya lebih suka versi default yang lebih aman.

Akan lebih baik jika API internal direstrukturisasi sedikit untuk mendukung EnvelopedSignatureReader yang digunakan oleh System.IdentityModel daripada memiliki dua implementasi terpisah dari validasi XML Signature.

Akhirnya saya juga ingin satu titik ditambahkan sesuai laporan bug ini .

@tintoy Saya tidak berpikir kami memiliki dokumen yang bagus. Saya pikir kita harus menambahkan sumber dan kemudian kita dapat memparalelkan pekerjaan - biarkan saya menyinkronkan dengan @bartonjs @steveharter @ianhays.

Saya akan mencoba mencari waktu untuk membantu juga. Jika ada pertanyaan tentang spesifikasi dan cara kerjanya, saya akan dengan senang hati memeriksanya - saya telah meluangkan waktu untuk meninjau spesifikasi.

Adakah yang ingin mengatakan sesuatu tentang ide untuk mengkonsolidasikan SignedXml dan EnvelopedSignatureReader yang digunakan oleh System.IdentityModel?

@AndersAbel

mulai tanpa fitur yang dinonaktifkan oleh MS16-035 (transformasi xpath, transformasi xslt, referensi eksternal)

Kita harus mulai dengan kode sumber .NET Framework terbaru, yang seharusnya aman. Jika Anda memiliki kekhawatiran tentang keamanan kode .NET Framework, beri tahu kami secara offline.

Saya tidak tahu ruang apa yang ada untuk melanggar perubahan

Tidak ada ruang, kita harus mulai dengan port langsung dari .NET Framework. Setiap perbaikan lebih lanjut, perubahan, perubahan melanggar, dll dapat dipertimbangkan nanti. Bukan sebagai bagian dari pekerjaan awal. Kalau tidak, itu akan tumbuh di atas kepala kita.

mekanisme fallback saat ini di DefaultGetIdElement dapat dieksploitasi dalam serangan pembungkus tanda tangan

Itu harus diperlakukan sebagai masalah terpisah. @bartonjs bisa tolong beri komentar?

Akan lebih baik jika API internal direstrukturisasi sedikit untuk mendukung EnvelopedSignatureReader yang digunakan oleh System.IdentityModel daripada memiliki dua implementasi terpisah dari validasi XML Signature.

Sekali lagi, mari kita ambil sebagai langkah selanjutnya, setelah kita memiliki port yang berfungsi penuh dengan cakupan pengujian yang baik.

Akhirnya saya juga ingin satu titik ditambahkan sesuai laporan bug ini.

Harap ajukan sebagai masalah terpisah di sini, di GitHub. Idealnya setelah kami memiliki kode di sini porting (yaitu ketika bug benar-benar berlaku untuk .NET Core).

Adakah yang ingin mengatakan sesuatu tentang ide untuk mengkonsolidasikan SignedXml dan EnvelopedSignatureReader yang digunakan oleh System.IdentityModel?

Hanya ingin mengulangi. Kita harus memperlakukannya sebagai langkah selanjutnya, post porting.

mekanisme fallback saat ini di DefaultGetIdElement dapat dieksploitasi dalam serangan pembungkus tanda tangan

Itu harus diperlakukan sebagai masalah terpisah. @bartonjs bisa tolong beri komentar?

@AndersAbel Jika Anda yakin ada masalah keamanan, ikuti proses pelaporan kerentanan di https://technet.microsoft.com/en-us/security/ff852094.aspx.

Adakah yang punya sesuatu untuk dikatakan tentang ide untuk mengkonsolidasikan SignedXml dan EnvelopedSignatureReader yang digunakan oleh System.IdentityModel?.

Ini mungkin tidak mungkin. SignedXml sangat banyak (dan sekutu API-publik) berdasarkan XmlDocument kaya-DOM. Representasi IdentityModel didasarkan pada XmlReader. Tapi, begitu barang-barang yang ada dibawa itu bisa diselidiki.

Saya akan mencoba mencari waktu untuk membantu juga. Jika ada pertanyaan tentang spesifikasi dan cara kerjanya, saya akan dengan senang hati memeriksanya - saya telah meluangkan waktu untuk meninjau spesifikasi.

@AndersAbel - tepuk tangan, saya yakin kita bisa menggunakan bantuan :)

@bartonjs Saya telah melaporkan masalah tersebut ke [email protected] , yang menghasilkan MS16-035. IMO ada beberapa masalah berisiko yang tersisa, yang diputuskan MS untuk tidak diperbaiki (mereka akan menimbulkan perubahan yang melanggar). Saya belum mempublikasikan detailnya, tetapi jika Anda ingin mendiskusikannya secara pribadi, silakan kirim email kepada saya.

@karelz Terima kasih telah

mulai tanpa fitur yang dinonaktifkan oleh MS16-035 (transformasi xpath, transformasi xslt, referensi eksternal)

Kita harus mulai dengan kode sumber .NET Framework terbaru, yang seharusnya aman. Jika Anda memiliki kekhawatiran tentang keamanan kode .NET Framework, beri tahu kami secara offline.

Patch MS16-035 mengatasi sejumlah masalah di SignedXml. Meskipun demikian, dimungkinkan untuk menggunakan kunci registri untuk kembali ke perilaku lama yang tidak aman. Haruskah opsi-opsi itu juga di-porting ke .NET Core? Saran saya di atas dimaksudkan untuk memprioritaskan mendapatkan perilaku .NET Framework default saat ini yang di-porting, meninggalkan bagian-bagian yang dinonaktifkan secara default di belakang untuk saat ini. Atau maksud Anda bahwa bagian-bagian itu penting untuk dipindahkan juga? Lalu ada pertanyaan bagaimana menangani konfigurasi karena .NET Core AFAIK tidak bergantung pada registri untuk konfigurasi (karena tidak tersedia di semua platform).

Meskipun demikian, dimungkinkan untuk menggunakan kunci registri untuk kembali ke perilaku lama yang tidak aman. Haruskah opsi-opsi itu juga di-porting ke .NET Core?

Tidak. Kode khusus-registri akan dihapus sebelum paket tersedia.

Mengapa Anda tidak membuat proyek di GitHub untuk mengimplementasikannya?

Kami menyinkronkan dengan @bartonjs , @steveharter dan @ianhays

EDIT: Rencana eksekusi dipindahkan ke pos paling atas.

Terdengar bagus untukku :)

@karelz , @steveharter Sebagian besar pencarian registri terletak di kelas Utils : AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier . Ada juga pencarian di kelas SignedXml di mana ia mengatur daftar transformasi yang diketahui. Tanpa kompatibilitas registry saya rasa XmlDsigXPathTransform dan XmlDsigXsltTransform dapat diakses. Haruskah mereka dihapus sepenuhnya dari sumbernya bersama dengan kode registry-compat?

Itu yang saya ketahui, saya belum melihat yang lain saat membaca kode, tetapi saya mungkin melewatkan sesuatu.

@AndersAbel Saya memperbarui komentar Karel di atas tentang registri. Jika ada kelas yang tidak dapat diakses, kita perlu memahami fungsionalitas apa yang hilang. Untuk yang Anda sebutkan, saya yakin CryptoConfig perlu menambahkan nama: pasangan

Menurut Anda kapan kelas ini akan siap?

Apakah yang Anda maksud: untuk kontribusi @steveharter berencana untuk mengirimkan PR "tambahkan sumber" awal segera (kemungkinan besar hari ini).

Kode awal baru saja digabungkan.

@steveharter Terima kasih

Terima kasih @steveharter! Saya telah memindahkan rencana eksekusi ke pos paling atas untuk pelacakan kemajuan yang lebih mudah. Setiap kali kami melakukan perubahan, kami akan menyebutkan perubahan itu di balasan lain di sini.

Jika ada yang ingin mulai mengerjakannya, harap katakan demikian untuk menghindari pekerjaan duplikat. Kami akan menugaskan masalah ini kepada Anda.

@karelz : @tintoy dan saya angkat tangan untuk memulai ini. Senang bagi Anda untuk menugaskannya kepada kami.

Jika ada yang ingin mulai mengerjakannya, harap katakan demikian untuk menghindari pekerjaan duplikat. Kami akan menugaskan masalah ini kepada Anda.

Cheers - Saya senang untuk memulai kompilasi :)

@anthonylangsworth - hah, kalahkan aku!

Pekerjaan sedang terjadi di sini .

Ditugaskan ke @tintoy. Saya akan menugaskannya juga ke @anthonylangsworth begitu dia menerima status kontributor ke repo (GH tidak akan menawarkan Anda sebagai opsi penerima hak tanpa itu).

Terima kasih!

@karelz hanya untuk mengonfirmasi - dari apa yang saya pahami tentang pedoman kontributor, saya membuat perubahan ini di master ?

( master jelas)

Ergh, maaf, izinkan saya mencoba lagi - PR akhirnya bertentangan dengan master ?

Ya itu betul. Hanya saja, jangan menjadikannya bagian dari corefx build/test run hingga fase terakhir.

Saya telah menemukan beberapa konstanta yang tampaknya telah dipindahkan ke kelas internal di src/Common/src/Interop/Windows/Crypt32/Interop.certificates_types.cs . Ini tidak dapat diakses dari System.Security.Cryptography.Xml sekalipun. Adakah pemikiran tentang pendekatan terbaik di sini?

Manakah dari mereka yang dibutuhkan? Mereka semua?
Dapatkah Anda memeriksa sumber referensi jika mereka publik di .NET Fx? (Saya rasa tidak, tetapi tidak ada salahnya untuk memeriksa ulang)
Saya agak terkejut bahwa kami melakukan interop khusus, alih-alih memanfaatkan sisa perpustakaan Crypto ... entah itu membutuhkan sesuatu yang istimewa, atau karena alasan historis ... @steveharter @bartonjs ada pemikiran?

@tintoy Salah satu hal yang perlu dilakukan sebagai upaya ini adalah menghapus antarmuka langsung dengan CAPI, beralih menggunakan .NET API.

@karelz , @bartonjs - kebanyakan konstanta CAPI HRESULT diteruskan ke konstruktor CryptographicException .

Sebagai contoh:

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

Saya akan melihat bagaimana kode lain di corefx bekerja dengan CryptographicException .

Ah, ok - jadi sepertinya konstruktor HRESULT sudah tidak digunakan lagi - hanya konstruktor yang menerima pesan. Saya akan melihat apakah ada sumber pesan yang sesuai dengan nilai E_xxx .

Adapun masalah lainnya, bagi saya sepertinya hasil dari tipe yang tidak lagi berbagi satu Majelis. Misalnya, X509Utils.DecodeHexString ada di System.Security.Cryptography.X509Certificates tetapi dalam kerangka kerja lengkap ini hanya tinggal di Majelis System.Security bersama dengan kelas yang menggunakannya.

Karena semuanya telah dipecah menjadi beberapa rakitan, apa mekanisme pilihan Anda untuk menangani komponen apa yang biasanya dibagikan? Saya bisa membuat salinan fungsi yang diperlukan dari kode di majelis lain jika itu yang Anda inginkan.

Atau tarik sumbernya menggunakan sesuatu seperti:

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

Untuk saat ini saya telah mengatasi masalah CAPI dengan hanya mengkompilasi `Interop.certificates_types.cs ke dalam Majelis dan mereferensikan konstanta dari sana.

Saya juga harus menyalin beberapa metode dari X509Utils.cs dalam kerangka kerja lengkap (terutama yang berkaitan dengan Hex encoding/decoding) karena tidak ada yang tersedia untuk umum di corefx yang melakukan ini.

Satu-satunya masalah yang tersisa ada di src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SymmetricKeyWrap.cs (baris 34, antara lain) yang mengakibatkan kesalahan seperti:

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

Untuk saat ini, saya telah menekan kesalahan. Jadi sekarang semuanya dikompilasi :)

Oke, kecuali untuk proyek uji:

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

Aku akan menyelesaikannya besok.

@karelz @bartonjs Saya akan membuka PR sehingga kita dapat mendiskusikan perubahan (pekerjaan pada dasarnya dilakukan sejauh yang saya tahu) - apakah Anda setuju dengan itu?

Terdengar bagus untukku. @steveharter ada pendapat?

Selamat tahun baru =D

Apakah Anda tahu kapan fase 2 akan selesai?

dotnet/corefx#14662 sudah digabung - itu adalah fase 2. Saya akan menandainya di posting teratas sebagai 'dicentang'.

Supaya saya jelas: setelah semua 5 langkah di atas selesai, maka untuk mendapatkan dukungan ws-fed di ASP.NET Core, tim AAD perlu melakukan bit token SAML mereka, kemudian tim ASP.NET perlu membangun ws -makan middleware pada bagian AAD. Apakah itu sesuai dengan harapan Anda?

Tidak, pekerjaan ini tidak ada hubungannya dengan WS-Fed.
Saya berutang balasan dan penjelasan di https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500

FYI: Balas diposting: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

Jadi kapan tahap 4 akan selesai?

Jika Anda bertanya kapan tim .NET punya waktu untuk melakukannya -- kami belum tahu. Ini adalah jaminan simpanan kami yang tinggi, tetapi ada beberapa prioritas yang lebih tinggi yang harus kami tangani terlebih dahulu.

Kami terbuka untuk kontribusi dalam ruang dari komunitas sementara itu.

Saya senang untuk terus mengerjakan ini, tetapi saya agak terjebak saat ini; sejak corefx pindah ke proses build baru, System.Security.Cryptography.Xml tidak lagi dibuat (jadi @anthonylangsworth dan saya diblokir untuk menulis tes apa pun). Jika kita bisa mendapatkan petunjuk singkat tentang apa yang terlibat dalam membuat proyek (dan menguji proyek) untuk dibangun, kita akan baik-baik saja :)

PS. Saya telah menghabiskan sekitar 20 menit menelusuri proses pembuatan untuk mencari tahu mengapa itu tidak lagi dibangun, tetapi belum berhasil. Setiap petunjuk akan dihargai...

@mellinoe @weshaggard dapatkah Anda memberikan panduan untuk memigrasi SignedXml ke sistem build baru?

Saya pikir saya harus menunggu

@tintoy jika Anda mengarahkan saya ke cabang yang sedang Anda kerjakan dan proyek mana yang Anda coba bangun, saya dapat membantu membangun.

@weshaggard saat ini tidak ada cabang - kodenya ada di master, hanya saja tidak terhubung ke root build (sengaja) - src/System.Security.Cryptography.Xml (diperkenalkan di dotnet/corefx#14628). @steveharter dapat memberikan info tambahan.

@weshaggard @karelz Saya senang membuat cabang di garpu kami dan hanya membuatnya membangun di sana untuk membuka blokir kami; nanti, kita selalu dapat memilih setiap perubahan yang telah kita buat setelah itu dibangun kembali di master . Beri tahu saya jika ini adalah pendekatan pilihan Anda :)

PR https://github.com/dotnet/corefx/pull/15491 harus membuat infrastruktur proyek berfungsi. Setelah CI lolos, kami dapat menggabungkannya dan itu akan mem-bootstrap upaya Anda.

Terima kasih - Saya telah mengubah basis tintoy/corefx/master dan akan segera memainkannya :)

@weshaggard ok, jadi src dan proyek uji build, tetapi jika saya menambahkan referensi proyek dari proyek uji ke proyek sumber ( <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ), saya mendapatkan:

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

Saya kira saya melewatkan sesuatu tentang bagaimana referensi antar proyek dimaksudkan untuk bekerja di corefx?

@tintoy Saya tidak yakin apa kesalahan itu secara khusus tetapi kami biasanya tidak memerlukan ProjectReferences dalam sistem teknik baru kami. Untuk build uji, kami selalu membuat dan mereferensikan paket penargetan lengkap, dalam hal ini diproduksi di bin\ref\netcoreapp . Pustaka yang dimasukkan ke direktori itu adalah apa yang Anda buat dari folder ref Anda yang saat ini kosong. Jadi untuk memulai, Anda perlu membuat referensi dengan area permukaan API yang Anda butuhkan dan mendapatkan bangunan referensi, kemudian proyek pengujian Anda akan secara otomatis melihat API dan dapat membangunnya. Kami memiliki alat yang disebut genapi yang dapat menghasilkan referensi berdasarkan perpustakaan lain. Biarkan saya mengirimkan PR lain dengan cepat untuk benih itu untuk kalian.

Ok, sekarang saya mengerti sekarang; alasan saya tidak melihat tipe dalam proyek uji adalah karena proyek ref belum memiliki tipe :-)

@weshaggard jika Anda tidak punya waktu, saya mungkin bisa mencari cara untuk melakukannya; Saya baru saja membaca tentang alat itu tempo hari.

Saya dengan cepat menjalankan alat genapi dan mendorong komit itu https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e. Jangan ragu untuk mengambilnya atau membuatnya sendiri. Anda perlu menambahkan ProjectReference ke referensi lain agar dapat dikompilasi.

Cheers - itu akan menghemat waktu saya, sangat dihargai.

@weshaggard sukses! Terima kasih, semoga kami bisa mulai menulis tes itu sekarang :)

(tintoy @dd834c63af4fe40faf84bc6a776b474ec9947eb1 , abaikan saja duplikatnya)

Ya! Memiliki tes kerja:

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

Terima kasih atas bantuan Anda, @weshaggard!

PS. Saya harus mengganti secara lokal (melalui file .user ) jalur yang dapat dieksekusi di bawah properti proyek pengujian (tab Debug). Adalah D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe tetapi hanya berfungsi ketika saya mengubahnya menjadi D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe .

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

VS saya tidak mengeluh tentang garis miring. Pemisah jalur umumnya menyebalkan karena kami mencoba membuat semuanya berfungsi di windows dan unix, jadi kami akhirnya melihat banyak garis miring campuran di windows yang umumnya lebih menerima daripada unix.

Hanya ingin tahu, versi VS mana yang Anda gunakan? 2015 atau 2017? Mungkin sudah diperbaiki pada 2017 :)

(Saya biasanya menggunakan OSX atau Linux akhir-akhir ini, jadi saya sangat menghargai upaya untuk membuat segala sesuatunya ramah lintas platform, BTW)

Saya menggunakan VS 2015 pada Windows 10 dan membuka solusinya dan dapatkah F5 men-debug tes dan jalur debug saya adalah D:\git\corefx\Tools/testdotnetcli\dotnet.exe

Oke, saya pasti sudah gila - sekarang saya juga tidak bisa mereproduksinya!

Sebelumnya, ia mengeluh karena tidak dapat menemukan dotnet.exe , tetapi mulai berfungsi ketika saya secara eksplisit mengatur executable ke jalur dengan garis miring terbalik saja. Saya baru saja menghapus file .csproj.user dan _still_ berfungsi, jadi siapa tahu :-o

Hai teman-teman, saya ingin terlibat dalam membantu menulis tes. Apa yang dapat saya lakukan untuk mulai berkontribusi?

Hebat - Saya pikir kita mungkin berada di tahap sekarang di mana kita bisa mulai melakukan itu :)

Biarkan saya memeriksa dengan rekan kerja untuk melihat apakah dia berhasil menjalankan tes pertamanya...

cc: @anthonylangsworth

@karelz ,

@anthonylangsworth dan saya sudah mulai menulis tes ; Saya sadar bahwa kami belum mencapai kesepakatan bersama tentang apa yang perlu diuji, tetapi kami akan tetap memulai dan kemudian mengirimkan pengujian ke mana pun kami setuju untuk melakukan pekerjaan itu.

Dan bagi mereka yang secara sukarela membantu tes (yang sangat dihargai), kita harus dapat membagi pekerjaan yang disarankan awal minggu depan :)

Mengenai cakupan tes dan tes mana yang kami butuhkan - @bartonjs memiliki pendapat yang kuat tentang itu (karena ia memiliki keahlian paling banyak dengan jenis dan masalahnya di pihak kami). Dia menyarankan untuk menulis tes dengan spesifikasi (saya sebutkan di atas ).
Dia akan kembali dari liburan pada akhir minggu depan. Kita mungkin harus mendiskusikan detail & harapan dengannya.
Juga @AndersAbel menyebutkan keahlian khusus dan bantuan potensial di awal diskusi .

cc @steveharter jika dia memiliki panduan tambahan sementara @bartonjs adalah OOF.

Terima kasih @tintoy @anthonylangsworth atas kontribusi Anda di sini! Kami sangat menghargainya!
Dan juga terima kasih kepada semua orang yang berencana untuk terjun ;-)

cc @ steveharter jika dia memiliki panduan tambahan sementara @ bartonjs adalah OOF.

Keingintahuan saya mencapai titik yang menuntut untuk dipuaskan.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
Saya merasa lebih baik sekarang.

Saya bahkan tidak tahu itu sangat spesifik untuk Microsoft! Terima kasih atas pencerahannya yang lucu

@anthonylangsworth telah mulai membuat sketsa rencana pengujian kasar di tintoy/corefx#3 (Saya telah menyalin rencananya ke dalam sebuah masalah untuk memudahkan komentar) jadi kami setidaknya memiliki sesuatu untuk didiskusikan. Jangan ragu untuk melihat-lihat dan memberikan umpan balik :)

CC: @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (atau siapa pun yang berkepentingan) Apa kebijakan seputar penggunaan InternalsVisibleToAttribute untuk tes? Ada banyak kelas internal dalam namespace itu dan mendapatkan cakupan pengujian yang memadai mungkin sulit dilakukan hanya melalui metode publik. Namun, saya menghargai ada pertimbangan lain.

Hmmm, sayangnya, saya tidak tahu - @weshaggard @stephentoub? (pertanyaan di reply sebelumnya)

Dari apa yang saya lihat dari kode lain di corefx, proyek yang dimaksud terkadang menyertakan file sumber yang relevan dari proyek lain (walaupun saya membayangkan ini akan menjadi rumit dengan cepat karena grafik ketergantungan).

Dari memori, System.Collections.Immutable menggunakan [InternalsVisibleTo] , jika itu bisa membantu.

Sebagai contoh:

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

Lebih umum:

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

Anda dapat melihat pemikiran saya tentang InternalsVisibleTo dalam edisi lama ini https://github.com/dotnet/corefx/issues/1604. Pendapat umum saya adalah tidak melakukannya kecuali ada kebutuhan khusus yang nyata untuk melakukannya.

Apa kebijakan seputar penggunaan InternalsVisibleToAttribute untuk pengujian?

Tidak.

Ada banyak kelas internal dalam namespace itu dan mendapatkan cakupan pengujian yang memadai mungkin sulit dilakukan hanya melalui metode publik.

Jika itu adalah sesuatu selain jalur pengecualian yang dalam, itu harus dapat dijangkau, atau dihapus. Jika dibutuhkan kasus uji yang rumit untuk mencapainya, ya, itulah yang kita butuhkan.

proyek yang dimaksud terkadang menyertakan file sumber yang relevan dari proyek lain

Dengan asumsi maksud Anda "proyek uji menyertakan sumber produk untuk mendapatkan akses ke anggota internal": Tidak.

[InternalsVisibleTo] dan berbagi sumber keduanya merupakan strategi yang diwariskan. Sebagian besar dari kita percaya (pada dasarnya) bahwa tes kita seharusnya hanya mewakili hal-hal yang dapat ditemui di dunia nyata. Jika tidak ada tes yang mungkin untuk mengenai beberapa blok tertentu lalu mengapa itu ada? Ya, ada beberapa blok pelempar pengecualian yang tidak dapat dipukul karena pemeriksaan berlebihan yang lebih tinggi di tumpukan sudah menangkapnya; tapi itu adalah sesuatu yang bisa dilihat setelah fakta dan dinyatakan OK.

Jadi saya akan merekomendasikan menarik spesifikasi dan memastikan bahwa ada tes positif untuk setiap fitur (misalnya setiap algoritme yang dikatakan mendukungnya, dan kasus batas untuk nilai min/maks untuk opsi pada algoritme tersebut).

Tes negatif seperti menghapus elemen yang diperlukan (misalnya 4.1 mengatakan bahwa SignedInfo adalah elemen yang diperlukan untuk Signature ... apakah kita mengeluarkan pengecualian yang masuk akal jika tidak ada?) juga bagus.

Tes opsi Canonicalizer, seperti <foo><!-- hi --></foo> dan <foo></foo> (dan mungkin <foo /> ?) sama di bawah c14n , tetapi berbeda di bawah c14n-withcomments . (Ini mungkin memerlukan penandatanganan dua arah, lalu bertukar badan, karena algoritme kanonikalisasi harus ditandatangani).

Mengubah tes. Semua canonicalizers adalah transformasi. Dll.

Tes tamper juga bagus. Tetapi jika Anda yakin telah menemukan tes tamper yang berhasil merusak, jangan laporkan di sini atau komit/dorong ke repro apa pun di github (kirim email tes/kasus/deskripsi ke [email protected]).

Oke, aku sudah terlalu banyak berpikir untuk hari ini. Kembali berlibur sekarang.

Terima kasih @bartonjs atas wawasan Anda saat berlibur! Sekarang pergi dan bersenang-senanglah di dunia nyata ;-)

@karelz @bartonjs (walaupun hanya sekali Anda kembali dari liburan!) @steveharter dan siapa pun yang memiliki pendapat:

@anthonylangsworth telah membuat beberapa tes awal sebagai

Saya melihat bahwa Mono memiliki beberapa tes SignedXml. Ini harus dievaluasi dan diperiksa terhadap xmldigsig spec , saran yang @bartonjs sebutkan sebelumnya, dan kode saat ini untuk melihat apa\jika mereka layak untuk

Terima kasih - kami akan melihatnya :)

Terima kasih untuk itu, @steveharter . Bisakah Anda memberikan tautan, tolong? Ini bisa memotong banyak pengujian kami. Apakah ada hak cipta atau pertimbangan lain jika kami memperluas atau membangunnya daripada menyalinnya kata demi kata?

@anthonylangsworth ketika menyalin kode sumber dari Mono, kita harus menjaga & memperbarui header hak cipta. Saya akan menyarankan untuk pertama-tama melakukan salinan saja (dengan tajuk yang tepat, berpotensi tweak kecil). Setelah kami memiliki kode di CoreFX, kami dapat memodifikasi kode sesuai keinginan.

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

Terima kasih, @steveharter. Saya sudah mulai mengonversi tes dari NUnit ke Xunit .

Saya memposting ini tetapi menyadari itu ada di repo @anthonylangsworth :

Inilah keajaiban yang harus dilakukan pada header hak cipta saat kita menarik kode dari 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.

Apakah ada tes yang gagal dalam proyek ini?

@Jaedson33 Kami sedang mengonversi tes mono. Saya belum menemukan tes gagal yang menunjukkan kesalahan kode tetapi kami masih memiliki banyak tes untuk dilakukan.

@anthonylangsworth Apa yang bisa saya bantu?

@Jaedson33 Saya telah menjawab pertanyaan itu di https://github.com/tintoy/corefx/issues/6#issuecomment -280904587 . Untuk meringkas, kami memiliki 84 tes mono yang masih gagal (terutama karena perubahan default dan batasan inti .Net). Bantuan apa pun untuk membuat tes yang tersisa berfungsi sangat dihargai. Jika tidak, saya sedang mengerjakannya.

@karelz @bartonjs @steveharter Kelas System.Security.Cryptography.CryptoConfig menyatakan bahwa banyak transformasi XML tidak didukung pada CoreFx (baris 281 hingga 303 di bagian bawah DefaultNameHT ).

Ini sesuai dengan URI yang digunakan oleh kelas di ruang nama System.Security.Cryptography.Xml . Sebagai bagian dari menambahkan System.Security.Cryptography.Xml kembali ke .Net Core, saya berasumsi kita harus mengembalikan ini. Tolong beri tahu saya jika saya salah.

CC: @tintoy

@anthonylangsworth , beberapa dari transformasi itu, seperti XmlDsigC14NTranform baik-baik saja, tetapi yang lain, seperti XmlDsigXsltTransform dianggap sangat berbahaya. Meskipun Anda dapat mengaktifkannya melalui keikutsertaan kunci registri di .NET Framework penuh, saya lebih suka tidak mendukungnya di .Net Core. Lihat KnownCanonicalizationMethods dan DefaultSafeTransformMethods di https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security transformasi yang harus kita dukung.

Saya tidak menyadari sumber yang berbahaya benar-benar dimasukkan ke dalam pelabuhan. Saya akan memilih untuk menghapusnya sepenuhnya. Benar-benar tidak ada cara yang aman untuk menggunakannya.

@morganbr Terima kasih atas perhatiannya. Setelah saya menyelesaikan perubahan kode XML nilai kunci RSA dan DSA, saya akan meninjau daftar transformasi yang disertakan. Saya kemungkinan akan menerbitkan daftar dan meminta Anda dan orang lain untuk meninjaunya.

@anthonylangsworth Kedengarannya bagus!

@morganbr @AnthonyDGreen Mereka transformasi (yang dinonaktifkan dalam MS16-035 patch yang) telah dibahas sebelumnya di thread ini ketika membahas pelabuhan. @bartonjs menyatakan pada 14 Desember bahwa hal-hal reg-compat harus dihapus. Lihat juga komentar oleh @steveharter 15 Desember bahwa transformasi itu mungkin dapat diaktifkan terlambat dan karenanya harus di-porting.

@steveharter @bartonjs bisa tolong

Bahkan tanpa dukungan registri, CryptoConfig dapat membuat transformasi yang terikat akhir dengan nama string atau oid. Cari 'CryptoConfig' dalam kode SignedXml seperti yang digunakan untuk membuat kelas yang sesuai berdasarkan konten xml.

Ini berarti kelas CryptoConfig harus diperluas untuk mendukung transformasi ini, setidaknya untuk tipe yang sama di netfx, dan idealnya juga referensi silang dengan Mono. Itu kecuali ada alasan (yang saya tidak sadari) untuk tidak memasukkannya dan tidak menghubungkannya ke CryptoConfig..

FWIW inilah CryptoConfig versi netfx (untuk membandingkan dengan apa yang ada di corefx): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs ,20d26e036bc718bc

Ada daftar "transformasi yang diizinkan" yang (dalam .NET Framework) dapat diperpanjang registri untuk back-compat. Untuk .NET Core itu tidak dapat diperluas, tetapi dikodekan dengan keras untuk hanya menyertakan transformasi tanpa input.

Karena Anda tidak dapat memvalidasi dokumen menggunakan transformasi yang tidak ada dalam daftar yang diizinkan, mungkin tidak masuk akal untuk mem-porting-nya. Tetapi karena seseorang dapat menggunakan transformasi di luar konteks SIgnedXml (hanya ingin menggunakannya sebagai mesin transformasi tujuan umum), mungkin tidak masalah untuk memilikinya.

Karena kita akan berbicara tentang menghapus seluruh jenis, itu tidak akan membuat inkonsistensi dengan .NET Framework... jadi saya mungkin menganjurkan untuk menghapus semua transformasi yang belum ada dalam daftar izin hard-coded. "Hapus sebelum menerbitkan paket" dapat diubah nanti. "Publikasikan mereka" tidak bisa.

@bartonjs mengalahkan saya untuk itu. CryptoConfig berisi daftar transformasi yang diizinkan. Saya harus memodifikasi kelas itu untuk memungkinkan transformasi di namespace baru, System.Security.Cryptography.Xml . Sementara beberapa transformasi yang diizinkan menggunakan nama lengkap kelas .Net, CryptoConfig masih hanya mengizinkan daftar tetap.

Saya lebih suka untuk tidak melakukan transformasi port yang memiliki masalah keamanan yang diketahui tetapi kompatibilitas ke belakang juga penting. Haruskah kita membuat keputusan ini atas nama pengembang? Apakah kita memodifikasi CryptoConfig untuk mengizinkan beberapa bentuk ekstensi sehingga pengembang dapat menambahkan transformasi baru jika mereka mau? Bagaimana kita mencapai keputusan tentang ini?

CryptoConfig bukan faktor pembatas: https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SignedXml. L787. (Meskipun, jika CryptoConfig masih digunakan sebagai pabrik untuk resolusi, maka transformasi apa pun perlu dilakukan di kedua tempat tersebut)

Jenis yang menyediakan algoritme yang tidak ada dalam daftar itu (yang juga bukan kanonikalisasi) secara efektif tidak memiliki nilai.

Mengizinkan ekstensi ke daftar aman akan membutuhkan API baru, jadi secara teknis di luar cakupan upaya ini.

Saya secara pribadi akan mengabaikan jenis transformasi yang tidak dapat digunakan dalam verifikasi dokumen. Mereka akan sulit untuk diuji.

Sebenarnya, CryptoConfig dan DefaultSafeTransformMethods keduanya relevan. SignatureDescription pembuatan dilakukan di CryptoConfig jadi, terlepas dari nilai dalam DefaultSafeTransformMethods , Anda tidak dapat menggunakan transformasi jika tidak disebutkan dalam CryptoConfig . DefaultSafeTransformMethods membatasi daftar itu jadi, jika transformasi ditentukan dalam XML tetapi tidak dikembalikan oleh DefaultSafeTransformMethods , SignedXml.CheckSignature mengembalikan false.

Dalam implementasi saat ini. CryptoConfig.AddAlgorithm melempar PlatformNotSupportedException , sehingga pengguna tidak dapat menambahkan milik mereka sendiri. Di luar cakupan upaya porting ini, tetapi mungkin ada baiknya melihat ini atau bahkan menambahkan RemoveAlgorithm di masa mendatang.

Setelah komentar saya sebelumnya, saya menemukan properti SignedXml.SignatureFormatValidator . Ini memungkinkan pengguna untuk menentukan transformasi dan algoritma hash apa yang sesuai. Penelepon dapat menggunakan ini untuk mengganti DefaultSafeTransformMethods , misalnya.

Seperti yang saya tanyakan sebelumnya, siapa yang membuat keputusan di sini? Sebagai "pria keamanan", preferensi saya adalah mengecualikan opsi yang tidak aman. Namun, saya tidak sepenuhnya memahami sejauh mana ketidakcocokan ini dapat terjadi.

@anthonylangsworth diskusi ini adalah bagian dari pengambilan keputusan. Pakar area dengan latar belakang paling banyak akan membuat keputusan di sini.

Rekomendasi saya: Jika dipertanyakan tindakan apa yang tepat, saya akan menyarankan untuk mempertahankan status quo - biarkan kode apa adanya selama latihan port (bahkan mungkin tanpa cakupan pengujian) dan putuskan nanti, secara terpisah dari latihan port.

Oke, jadi saya mengobrol dengan beberapa orang secara internal dan saya pikir saya memiliki perancah rencana:

• Biarkan jenisnya sebagai publik. (Mereka tipe publik, dan menghapus hal-hal membuat orang sedih).
• Ini tidak dapat (belum) digunakan dalam pengujian SignedXml ujung ke ujung. (Faktanya, tes negatif tampak bagus)
• Mereka memang memiliki anggota publik yang seharusnya cukup untuk pengujian unit, jadi kita harus melakukannya.
  
  
  
  • Dan itu juga berlaku untuk jenis transformasi lainnya.
  
  
• Jika, karena alasan tertentu, transformasi penerimaan input tidak berfungsi, dan yang lainnya baik-baik saja, kita dapat mencari tahu apa yang harus dilakukan untuk mengatasinya. (Ini juga akan diterapkan pada "jika mereka memiliki dependensi kompilasi kompleks yang tidak dapat dipenuhi", tetapi kami sudah melewati rintangan itu).

Dan jika/ketika API atau konfigurasi lain muncul untuk mengaktifkan jenis ini agar berfungsi, menambahkan tes E2E yang diikutsertakan akan menjadi mudah.

@tintoy @anthonylangsworth @peterwurzinger apa status cabang uji Anda? bisakah kita mulai menggabungkannya? Saya dapat memilih tes Anda dan melanjutkan dari sana.

Bisakah Anda juga PTAL di https://github.com/dotnet/corefx/pull/16545 ? Saya telah mengaktifkan salah satu sampel MSDN

Hai @krwq - Saya yakin masih ada beberapa tes yang gagal tetapi karena tidak dijalankan sebagai bagian dari proses pembuatan reguler, Anda mungkin tetap dapat memasukkannya.

Biarkan saya mengobrol dengan @anthonylangsworth dan menghubungi Anda kembali.

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

@krwq - ngobrol sebentar dengan @anthonylangsworth. Dia menyebutkan (dan saya setuju) bahwa mengingat jumlah pekerjaan yang telah dilakukan di sana, mungkin ada baiknya untuk menggabungkan apa yang kita miliki sebelum melangkah lebih jauh. Itu membangun, dan sebagian besar tes lulus, tetapi beberapa tidak.

Saya menduga kita perlu melakukan rebase terhadap dotnet/corefx#16545 (yang akan saya lakukan) sebelum membuka PR (yang akan dilakukan @anthonylangsworth ).

Kami akan menghubungi Anda segera setelah kami siap untuk ini (semoga tidak lama).

@krwq Untuk memperluas apa yang @tintoy katakan, sementara masih ada beberapa pekerjaan yang harus dilakukan, banyak pekerjaan juga telah dilakukan untuk mem-porting tes yang ada dan mengembangkannya. Secara khusus, saya telah mengubah CryptoConfig.cs untuk menangani banyak algoritme yang Anda sebutkan. Kita semua ingin memajukan ini. Kami juga tidak ingin menduplikasi atau menimpa karya satu sama lain. Oleh karena itu, kami berencana untuk menggabungkan perubahan sebagaimana adanya sehingga orang lain dapat membangun di atas pekerjaan yang telah kami lakukan, menemukan semua bug kami dan, mudah-mudahan, mendapatkan semuanya menjadi master lebih cepat.

@tintoy adalah https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests satu-satunya cabang yang sedang Anda kerjakan?

Ya.

@krwq Nah, ada PR dengan jumlah barang yang bagus dari Mono di (yang juga merupakan sub-cabang dari https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests ... ). Jika Anda tertarik dengan kode terbaru, Anda mungkin harus melihatnya di sana. Sejauh yang saya tahu ada ~ 40/340 tes gagal.

Tangkapan yang bagus, @peterwurzinger , saya pikir kami sudah menggabungkan yang itu!

@peterwurzinger @anthonylangsworth PR ini cukup bagus! Saya sebenarnya telah melewatkannya. Apakah Anda akan menggabungkannya ke cabang Anda, ke corefx atau Anda ingin saya mengambilnya dan melakukan semua penggabungan/rebase? Apakah itu melewatkan sesuatu dari tes Mono atau sudah lengkap? @anthonylangsworth - untuk perubahan CryptoConfig - saya membicarakannya dengan @bartonjs - kita seharusnya tidak menyentuh file itu - itu sudah cukup jelek.

Rencana awal saya adalah mendapatkan beberapa sampel dari MSDN dan membuat semuanya berfungsi sehingga kami dapat memulai dogfooding lebih awal. Setelah itu saya akan menggabungkan dan memperbaiki tes dari cabang Anda. Jika Anda mendapatkan beberapa tes yang gagal, kami dapat menonaktifkannya untuk saat ini dan memperbaikinya nanti. Mari gabungkan barang-barang Anda ke corefx/master secepatnya :smile:

Terima kasih atas pembaruannya, @krwq . Jika Anda bisa, tolong beri kami informasi terbaru. Ini membantu untuk mengetahui apa yang kita tuju.

Hai = D

Apakah ada tes yang gagal?

@Jaedson33 @anthonylangsworth @tintoy
Berikut adalah daftar (secara sewenang-wenang) masalah yang paling penting saat ini:
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@Jaedson33 ya, mereka saat ini dinonaktifkan. Di atas seharusnya memberi Anda gambaran kasar di mana kita berada

Hai, apakah Anda tahu kapan ini akan tanpa kesalahan?

@Jaedson33 setiap bagian dari perangkat lunak memiliki kesalahan :wink: Apakah ada hal-hal tertentu yang tidak bekerja untuk Anda?

Sederhana saja: Itu tidak berfungsi di proyek UWP saya

Hai, saya mendapatkan kesalahan ini ketika saya mencoba menjalankan build.cml. Bisakah kamu membantuku?

Kesalahan dalam perintah:
C:\Users\jaeds\Source\Tools\msbuild.cmd /nologo /verbosity:minimal /clp:Summary /maxcpucount /nodeReuse:false /l:BinClashLogger,Tools\net46\Microsoft.DotNet.Build.Tasks.dll;LogFile =binclash.log /p:ConfigurationGroup=Debug /p:BuildPackages=false /flp:v=normal /flp2:warningsonly;logfile=msbuild.wrn /flp3:errorsonly;logfile=msbuild.err C:/Users/jaeds/Source /Repos/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj /t:rebuild /p:Configuration=Debug /p:Platform=x64 /p:PlatformToolset =v141. => O sistem não pode encontrar o arquivo especificado
Eksekusi perintah gagal dengan kode keluar 1.
Gagal membuat proyek pembuatan komponen asli!
Eksekusi perintah gagal dengan kode keluar 1.

@JaedsonBarbosa Apakah Anda menjalankan tes dari prompt perintah pengembang? (btw ini sedikit OT) untuk UWP - Saya akan menyelidiki apakah ini dapat dilakukan dengan cukup murah untuk 2.0 meskipun tidak ada janji

Saya melakukan itu dari Prompt Perintah Pengembang untuk Visual Studio 2017

@JaedsonBarbosa apakah Anda telah menarik perubahan terbaru dari github dan mencoba membangun setelah membersihkan repo Anda ( git clean -fdx )? Hal kedua yang harus dicoba adalah mengurangi panjang jalur (yaitu meletakkan repo Anda di bawah C:\corefx). Hal lain yang harus dicoba adalah membersihkan cache nuget ( %USERPROFILE%\AppData\Local\NuGet dan %USERPROFILE%\.nuget )

Jika masih terjadi, buat masalah terpisah dengan informasi:

• OS Anda
• versi VS Anda
• langkah tepat yang Anda lakukan
• log lengkap (jika besar taruh di Gist)

Saya pikir itu terjadi karena saya pikir jalur C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj tidak valid.

OS: Windows 10
VS: Komunitas 2017
Saya baru saja memulai Prompt Perintah Pengembang untuk VS 2017 dan meletakkan:

cd C:/corefx
build

Sekarang kesalahannya adalah:

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"="Sistem tidak dapat menemukan file yang ditentukan"

Saya menyerah, saya tidak bisa membuatnya bekerja dengan 2017 VS.
Jadi, apakah Anda tahu kapan ini dapat diunduh sebagai paket NuGet?

Anda seharusnya dapat menggunakan pratinjau dari myget.org.
Paket resmi akan menjadi bagian dari gelombang .NET Core 2.0 - lihat deskripsi milestone 2.0.0 , 10 Mei adalah ZBB (#17619), jadi rilis RTW harus mengikuti "segera" setelahnya (tanggal pastinya belum diungkapkan ke publik)

@karelz Bisakah Anda mengirimkan saya tautan paket yang berisi System.Security.Cryptography.Xml?

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

Berikut cara melakukan dogfood 2.0: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

@karelz OK, saya ingin menginstalnya di perpustakaan kelas UWP, tetapi ketika saya mencobanya saya mendapatkan kesalahan itu:

Buka System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 tanpa paket uap10.0 (UAP,Versi=v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 untuk mendukung:

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

Ini project.json saya yang sebenarnya:

{
  "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 , saat ini kami tidak mendukung UAP untuk perpustakaan itu, Anda harus menunggu hingga https://github.com/dotnet/corefx/pull/17969 digabungkan dan paket baru diproduksi.

Oke, saya akan terus menunggu
@krwq Tapi... Apa itu UAP10.1???

@krwq Mengapa Anda tidak menggabungkan PR dotnet/corefx#17969 sekarang?

@JaedsonBarbosa Baru saja digabung, saya yakin paketnya harus ada di sana besok pagi - kami biasanya tidak bergabung kecuali PR berwarna hijau di CI - kami mendapat beberapa masalah OSX CI sejak kemarin jadi agak basi

@krwq Bisakah Anda memberi tahu saya kapan paket NuGet dengan perubahan dapat diunduh?

@JaedsonBarbosa diperingatkan bahwa dukungan .NET Standard 2.0 di UWP berdarah - itu tidak akan menjadi bagian dari .NET Core 2.0 - itu akan menjadi bagian dari versi berikutnya, sementara disebut sebagai 2.1. Kami sedang mengerjakan beberapa hal 2.1 sebelumnya dan secara paralel dengan 2.0, untuk mendukung infrastruktur, dll., sehingga kami kemudian dapat memparalelkan secara besar-besaran (setelah 10 Mei yang merupakan ZBB kami untuk 2.0).
Either way, Anda mungkin mengalami beberapa masalah dalam menggunakan perpustakaan di UWP. Kami mungkin tidak dalam posisi untuk membantu Anda segera. Kami seharusnya dapat membantu lebih banyak setelah 10 Mei. ... hanya menetapkan harapan.

@JaedsonBarbosa sepertinya kami tidak menghasilkan versi baru selama 2 hari Anda dapat mengamati perubahan di sini:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
setiap kali sebuah paket muncul setelah 4/6 itu harus memiliki perubahan yang Anda butuhkan. Saya akan memeriksa hari ini mengapa tidak ada paket - ini mungkin terkait dengan masalah jaringan yang kami miliki dengan build OSX

EDIT: mengonfirmasi - ini terkait dengan masalah jaringan OSX

@krwq Apakah Anda sekarang jika hari ini masalah jaringan OSX akan terpecahkan?

Ini memblokir hampir semua PR kami sehingga prioritas utamanya tetapi kami tidak memiliki ETA

Oke 👍
Jadi saya akan terus menunggu.

part 4 nya kapan ready?

@JaedsonBarbosa kami memiliki sebagian besar bagian penting yang telah diuji dan terbukti berfungsi, Dengan pengujian tidak ada titik "selesai" tunggal - Anda dapat memiliki cakupan kode 100% dan kode yang tidak berfungsi. Apakah ada skenario tertentu yang Anda minati?

Tidak

@krwq Saya berharap kami akan mendeklarasikan hal-hal yang dilakukan untuk perpustakaan, ketika kami merasa nyaman mengirimkannya sebagai stabil. Ketika kami melakukannya, kami dapat mencentang kotak dan menutup masalah ini. Jadi seberapa jauh kita menguji-bijaksana?

@karelz Saat ini saya merasa nyaman dalam pengiriman karena semua skenario E2E penting yang dapat saya pikirkan telah diuji. Saya masih ingin meningkatkan cakupan sehingga skenario yang kurang populer (termasuk penanganan kesalahan) dapat terbukti bekerja dengan benar juga meskipun saya tidak berharap menemukan masalah pemblokiran 2.0.

Bagi saya "selesai" berarti tidak ada yang akan memelihara atau meningkatkan perpustakaan lagi

Oke, jika @bartonjs setuju dengan
Jika kita ingin meningkatkan cakupan pengujian (sebagai non-blocking 2.0), kita harus membuat item pekerjaan terpisah untuk Future.

Jika kita telah menemukan semuanya dari daftar algoritme dan transformasi dan kanonikalisasi, itu bagus untuk saya.

Jadi saya pikir masalah ini akhirnya akan ditutup.

Oke, mari lacak kemajuan cakupan dengan: https://github.com/dotnet/corefx/issues/16829 - Saya pikir kami memperlakukan ini sebagai masalah utama

Ya, kami memperlakukannya sebagai masalah utama, tetapi terkadang Anda harus menyatakan sesuatu telah selesai, jika tidak, Anda akan memiliki 1 masalah terbuka untuk setiap fitur yang lebih besar yang melacak "melakukan lebih banyak" - yang tidak benar-benar membantu siapa pun.

Sekarang sudah tutup
Jadi... Di mana saya harus bertanya tentang System.Security.Cryptography.Xml?

Bukankah jawaban @krwq di atas sudah cukup?
Jika Anda memiliki pertanyaan yang lebih besar, ajukan masalah baru. Jika ini adalah klarifikasi kecil dari jawaban sebelumnya, Anda dapat menyimpannya di sini. Jika tidak yakin, tanyakan di sini dan dalam kasus terburuk kami akan meminta Anda untuk mengajukan masalah baru ;-)

@krwq Ini berlanjut tanpa dukungan untuk UWP

@JaedsonBarbosa tidak https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 tidak berfungsi untuk Anda? Bisakah Anda mengirimkan langkah-langkah dari apa yang Anda lakukan?

@krwq Saya baru saja memasukkan perintah itu:
Install-Package System.Security.Cryptography.Xml -Versi 4.4.0-preview1-25210-01

Itu kesalahannya:

Buka System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 tanpa paket uap10.0 (UAP,Versi=v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 untuk mendukung:

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

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

Sekedar mengingatkan apa yang saya katakan sebelumnya: https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
Saya tidak berpikir Anda akan mendapatkan dukungan UWP dengan paket tersebut. Paket tergantung pada .NET Standard 2.0 AFAIK dan UWP belum memiliki dukungan .NET Standard 2.0 -- ini adalah sesuatu yang akan kami kerjakan untuk .NET Core 2.1 (beberapa bit dilakukan lebih awal untuk membuka blokir tim yang lebih besar untuk mengerjakannya setelah 5 /10, tetapi tidak berfungsi penuh).
IMO untuk mendapatkan dukungan UWP untuk paket Anda harus menunggu pada 2.1.

@karelz Jadi menurut Anda saya harus menunggu sampai kapan?
Bisakah saya membuat proyek uap10.1?

Ya, saya pikir Anda harus menunggu sampai saat itu.
Kecuali jika Anda sangat termotivasi dan dapat melewati semua gundukan kecepatan ini. Seperti yang saya katakan, hingga 5/10 kemampuan kami untuk membantu Anda dengan apa pun UWP akan sangat terbatas , jadi Anda sebagian besar akan sendirian . Hanya menetapkan harapan di sini ...

Jadi saya akan menunggu karena saya tidak bisa membangun corefx-master dengan Visual Studio 2017

@karelz @krwq Saya tidak dapat membuat solusi karena saya memberikan kesalahan, Anda dapat melihat CMakeError di sini:
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYAjeMPkWkI -m6Q
Tolong beri saya bantuan
PS: Itu dalam bahasa Portugis, tetapi Anda dapat menggunakan penerjemah untuk membacanya

Saya pikir gagal itu tidak baik:
-- Identifikasi kompiler C adalah MSVC 19.0.24218.2
-- Identifikasi compiler CXX adalah MSVC 19.0.24218.2
-- Periksa compiler C yang berfungsi: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/AMD64/cl.exe
-- Periksa compiler C yang berfungsi: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/AMD64/cl.exe -- berfungsi
-- Mendeteksi informasi ABI kompiler C
-- Mendeteksi info ABI kompiler C - selesai
-- Periksa compiler CXX yang berfungsi: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/AMD64/cl.exe
-- Periksa kompiler CXX yang berfungsi: C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/AMD64/cl.exe -- berfungsi
-- Mendeteksi info ABI kompiler CXX
-- Mendeteksi info ABI kompiler CXX - selesai
-- Mendeteksi fitur kompilasi CXX
-- Mendeteksi fitur kompilasi CXX - selesai
-- Melakukan Tes COMPILER_HAS_DEPRECATED_ATTR
-- Melakukan Tes COMPILER_HAS_DEPRECATED_ATTR - Gagal
-- Melakukan Tes COMPILER_HAS_DEPRECATED
-- Melakukan Tes COMPILER_HAS_DEPRECATED - Sukses
-- Konfigurasi selesai
-- Pembuatan selesai

Siapa saja sekarang apa yang bisa saya lakukan untuk membuatnya membangun?

@JaedsonBarbosa bagaimana Anda membangun? Proses reguler bagi saya adalah:

1. Buka cmd.exe
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - ini akan membersihkan repositori Anda dari semua file yang tersisa (hati-hati jika Anda tidak yakin apa fungsinya)
5. build atau ./build.sh jika Anda menggunakan non-windows

Untuk membangun komponen asli, Anda perlu menginstal CMake 2.8.12 atau lebih tinggi

Ini selalu berhasil untuk saya.

@Jaedson33 Anda juga dapat memeriksa & membantu kami meningkatkan dokumen kontributor baru kami (ditautkan dari halaman utama CoreFX)

Saya menggunakan CMake 3.8.
@krwq Saya melakukan apa yang Anda katakan, dan saya menunggu sekitar 1 jam dan baru saja menginstal klien dotnet..., menurut Anda berapa jam saya harus menunggu?

@JaedsonBarbosa itu akan memakan waktu hingga beberapa menit, coba mulai ulang - mungkin ada beberapa masalah koneksi, jika tidak berfungsi, harap ajukan masalah terpisah di repo ini, seseorang harus dapat melacak apa yang telah terjadi

@krwq saya mendapatkan kesalahan ini:

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 silakan ajukan masalah baru seperti yang disarankan di atas. Sekedar mengingatkan bahwa kami mungkin tidak dapat memberikan dukungan pemecahan masalah sebanyak yang kami inginkan kepada Anda sebelum 5/10.

@karelz Sekarang berfungsi
Satu-satunya pemikiran yang saya lakukan untuk membuatnya membangun adalah memindahkan file dari C:\Users\jaeds\Source\Repos\corefx-master ke C:\Users\jaeds\Source.
Saya pikir itu harus di README

Hai, sekarang Anda dapat menggunakan paket ini di aplikasi UWP, berikut contoh aplikasi: https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

@JaedsonBarbosa hebat! Apakah ada sesuatu dari pekerjaan Anda yang berharga untuk mengalir kembali ke CoreFX? (yaitu hal-hal yang bukan peretasan sementara)

@karelz Yah, saya pikir Anda dapat menggunakan proyek saya untuk melihat apa yang dapat Anda sederhanakan (atau hapus) di CoreFX

Halo semuanya, upaya besar untuk mem-porting ini!

Bolehkah saya bertanya mengapa paket Nuget merujuk .NET Core 2.0, bukan .NET Standard 2.0? Bukankah itu lebih disukai?

Itu seharusnya sudah dilakukan (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

Saya kira Anda sedang melihat pratinjau resmi di Nuget
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

dan itu hanya sampai di Myget
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

Ya, itu yang saya cari. Terima kasih, @danmosemsft!

@leopignataro tidak masalah, saya mendorong Anda untuk mencoba bit dari "kepala" -- Anda bisa mendapatkannya dari beranda di sini https://github.com/dotnet/cli ... Anda bisa mengunduh zipnya jika mau. Beri tahu kami jika Anda menemukan masalah -- kami hanya memiliki sedikit waktu untuk memperbaikinya sebelum dirilis.

FYI: Berikut info tentang garis waktu: https://github.com/dotnet/corefx/issues/17619#issuecomment -301937346

Karena Anda menyebutkannya, @danmosemsft , ada satu masalah ini:

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

Saya telah menyarankan perbaikan pada utas tetapi pesan saya mungkin terlewatkan di semua buzz.

@leopignataro memperbaiki untuk apa di mana? Jika sudah diperbaiki untuk dotnet/corefx#19198, maka itu harus dilacak di bug. Jika itu adalah sesuatu yang lain, saya lebih suka melihat masalah terpisah untuk itu.
Jika menurut Anda saran perbaikan Anda diabaikan di suatu tempat, ajukan lagi di utas itu dan mintalah umpan balik.

Saya bingung sekarang. Saya pikir paket System.Security.Cryptography.Xml NuGet adalah untuk .NET Framework dan sudah termasuk dalam Dot Net Core v2. Itu tidak mengenali namespace ini di Dot Net Core v2. Apakah saya salah mendengar ini? Terima kasih.

@fletchsod-developer Paket ini terutama untuk .NET Core. Tetapi jika Anda mereferensikannya dari perpustakaan yang menargetkan .NET Standard, itu akan menyatu dengan versi .NET Framework di .NET Framework, dan menjalankan kode dari dalam paket di .NET Core.

Kami tidak memiliki rencana untuk menempatkan SignedXml ke dalam pengalaman penginstalan default untuk .NET Core; itu cukup ceruk sehingga menjadi paket terpisah di NuGet tampaknya merupakan model distribusi terbaik.