C-toxcore: Buat format penyimpanan tox standar sederhana portabel baru

Namun ketergantungan eksternal lainnya? Oh tidak! Silahkan!
Cukup tulis penulis/pembaca json sederhana. Ini juga akan berguna untuk beberapa transfer metadata antar klien.
Dan pertanyaan rumit: bagaimana Anda memberikan dukungan peningkatan ini oleh klien lain? Seperti yang saya tahu, tidak ada klien yang menggunakan TokTok (Isotoxin menggunakan sesuatu sendiri dengan mencampur kode dari asli dan toktok)

Saya pikir format ini harus menyediakan penyimpanan nilai kunci sederhana di mana klien dapat menyimpan hal-hal seperti nama pengguna, status online, pesan status, dan daftar alias teman (lihat juga: #112). Beberapa kunci standar kemudian akan ditentukan oleh TCS untuk memastikan interoperabilitas klien.

Saya akan memasukkan https://github.com/TokTok/c-toxcore/issues/112#issuecomment -257151226

@isotoxin Tampaknya salah untuk mencoba mengimplementasikan parser JSON di perpustakaan yang bertanggung jawab untuk menangani komunikasi yang aman, karena Anda hanya memperluas permukaan serangan/bug. Jika, misalnya, Anda menginginkan konfigurasi JSON, maka lebih baik untuk menundanya ke perpustakaan yang terpelihara dengan baik yang dimaksudkan untuk menangani JSON (dan _only_ menangani JSON). https://github.com/akheron/jansson/ sepertinya kandidat yang ideal untuk kasus JSON; itu sama portabelnya dengan toxcore, dan bahkan cocok untuk platform tertanam.

Setelah membaca dokumen saya setuju bahwa format saat ini mengerikan dan harus mati.

Untuk meminimalkan hal-hal yang perlu diterapkan untuk klien minimal, saya pikir file tersebut harus dibagi menjadi dua bagian:

• bagian dasar
• bagian opsional

Bagian dasar akan berisi jumlah minimum data untuk mentransfer teman (akan diputuskan) di seluruh klien dalam format sederhana (bahkan mungkin biner) dan tidak perlu perpustakaan eksternal untuk menguraikan.

Bagian opsional akan ditambahkan ke bagian dasar dan dikodekan JSON (atau apa pun). Beberapa kunci diperlukan untuk setiap klien, seperti alias, terakhir kali online,...

Membahas.

Saya menyukai ide format JSON karena mudah dibaca (untuk manusia) dan aman untuk lintas platform sendiri. Memang itu membutuhkan satu perpustakaan tambahan dan eksternal tetapi setidaknya dalam beberapa kasus klien dapat menggunakan perpustakaan yang sama untuk menangani bagian mereka sendiri dari penanganan konfigurasi (bagian opsional dari konfigurasi). Juga, saya mengalami kesulitan memikirkan kasus di mana penanganan file konfigurasi lintas platform, mungkin berisi konten yang kaya, dilakukan tanpa perpustakaan eksternal (JSON, msgpack, protobuf, apa pun).

Saya suka ide mendadak6 bahwa format penyimpanan tox dapat berisi dua bagian.
Bagian dasar - Berisi bagian data yang penting dan mutlak diperlukan untuk membuat akun berfungsi (hanya bagian yang benar-benar ditafsirkan oleh toxcore). Bagian dasar ini bahkan dapat diversi sehingga versi toxcore yang lebih baru dapat memiliki atribut yang tidak dipahami oleh versi yang lebih lama tanpa masalah.

Bagian opsional - Bagian yang dapat berisi informasi spesifik klien atau informasi lain yang tidak diperlukan untuk membuat sesuatu bekerja. Bagian opsional ini akan menjadi sesuatu yang dapat diminta klien dari toxcore. Klien juga dapat meminta toxcore untuk menyimpan sesuatu di bagian konfigurasi ini. Setiap bagian dari konfigurasi opsional TIDAK boleh ditafsirkan oleh toxcore tetapi core memberikannya kepada klien sebagai string. Klien dapat menanganinya sesuai keinginan.

Dengan format JSON, mengenkripsi file penyimpanan adalah hal yang sepele. Toxcore dapat mengenkripsi menyimpan file dengan menggunakan algoritma enkripsi simetris yang umum digunakan dengan kata sandi yang diberikan pengguna. Pada saat yang sama, enkripsi tidak diperlukan jika pengguna tidak ingin mengenkripsi file simpanannya dan dalam hal ini toxcore dapat melewati fase enkripsi/dekripsi.

Tentang keamanan ide dua bagian. Jika config akan berisi dua bagian terpisah, bagian dasarnya akan menjadi satu-satunya yang benar-benar ditafsirkan oleh toxcore. Dari bagian ini toxcore membaca semua atribut ke struktur internalnya dan bagian ini dibangun kembali ketika toxcore menyimpan file simpan. Untuk bagian opsional dari save file toxcore akan memperkenalkan HANYA mendapatkan dan menempatkan fungsi untuk klien. Fungsi-fungsi tersebut digunakan oleh klien untuk mendapatkan dan memberi mereka bagian konfigurasi opsional. Toxcore tidak boleh mengungkapkan fungsi terkait perpustakaan JSON ke sisi klien atau mencoba menafsirkan bagian opsional. Namun, toxcore harus memvalidasi sintaks JSON dari bagian opsional untuk mendeteksi kasus di mana klien mencoba memasukkan bagian konfigurasi yang tidak valid. Jika saya benar, setiap bagian yang tidak valid di JSON membuat seluruh struktur JSON tidak valid. Ini harus dideteksi oleh toxcore dan inklusi yang tidak valid tidak boleh diabaikan. Validasi sintaks JSON harus cukup sederhana, aman dan kemungkinan besar sudah tersedia oleh perpustakaan.

Mari kita pikirkan tentang pro dan kontra dari file konfigurasi JSON dengan bagian dasar dan opsional:
PROS

• dapat dibaca manusia
• dinamis, config dapat diversi sehingga atribut baru dilewati ketika tidak dipahami oleh versi toxcore yang berbeda.
• sederhana (setidaknya bagian dasar dari konfigurasi di mana atribut didefinisikan dengan baik)
• lintas platform secara alami
• format yang umum digunakan, banyak perpustakaan dan implementasi yang tersedia untuk berbagai bahasa.
• Untuk menjadi format teks, ukuran relatif efisien
• toxcore selalu dapat menyimpan versi sederhana dari file simpan jika diperlukan. File penyimpanan itu hanya akan berisi bagian dasar konfigurasi tanpa bagian opsional. (mencegah kembung konfigurasi dan akan menjadi versi independen)

KONTRA

• Membutuhkan perpustakaan eksternal
• Pemisahan dasar dan opsional menimbulkan masalah keamanan
• tidak efisien untuk data biner (avatar teman?)
• Jika klien dapat dengan bebas memasukkan apa pun yang mereka inginkan ke bagian opsional dari file penyimpanan konfigurasi dapat menjadi tumpukan besar karbage (lihat pro. -> simpan versi sederhana).
• toxcore harus memvalidasi sintaks tetapi tidak menafsirkan bagian opsional

Lagi pula, saya suka ide format JSON untuk file penyimpanan tox. Namun, penerapannya harus dilakukan dengan hati-hati! Silahkan diskusi lagi...

tidak efisien untuk data biner (avatar teman?)

Avatar IIRC tidak disimpan dalam file *.tox sekarang dan saya pikir menyimpan banyak data dalam file konfigurasi adalah ide yang buruk.

Pemisahan dasar dan opsional menimbulkan masalah keamanan

Mengapa?

Jika klien dapat dengan bebas memasukkan apa pun yang mereka inginkan ke bagian opsional dari file penyimpanan konfigurasi dapat menjadi tumpukan besar karbage (lihat pro. -> simpan versi sederhana).

Ya, itu bisa tumbuh menjadi masalah besar.

toxcore harus memvalidasi sintaks tetapi tidak menafsirkan bagian opsional

Juga solusi yang mungkin adalah membiarkan klien menangani parsing JSON dengan perpustakaan dengan pilihannya dan cukup init toxcore dengan struct/fungsi konfigurasi yang sesuai. Tapi saya tidak yakin ini adalah pendekatan yang baik, karena tidak menjamin bahwa file output akan kompatibel.

Ide lain adalah, untuk menghapus konsep "File Simpan Tox" dan hanya menyediakan "File Ekspor Tox". Alih-alih menyimpan/memuat segala sesuatu dari file simpan di setiap awal klien, klien akan memuat data yang diperlukan untuk operasi toxcore dari database/savefile itu sendiri dan hanya menyediakan cara untuk mengimpor/mengekspor data dalam format yang ditentukan untuk pertukaran dengan yang lain. klien.
PROS

• Lebih sedikit file konfigurasi
• Tidak ada ketergantungan keras pada perpustakaan parser

KONTRA

• tidak ada jaminan bahwa setiap klien menerapkan impor/ekspor

Secara keseluruhan saya pikir sebelum menangani cara menyimpan barang, pertama-tama kita harus memutuskan apa yang akan disimpan dalam file ini.

@master-passeli

Dengan format JSON, mengenkripsi file penyimpanan adalah hal yang sepele.

Enkripsi/dekripsi adalah sepele terlepas dari format datanya.

@mendadak6

Juga solusi yang mungkin adalah membiarkan klien menangani parsing JSON dengan perpustakaan dengan pilihannya dan cukup init toxcore dengan struct/fungsi konfigurasi yang sesuai.

Err, tidak, bukan solusi , tetapi melakukan hal-hal dengan cara yang salah.

Saya setuju bahwa menyimpan avatar di file penyimpanan tox mungkin ide yang buruk tetapi avatar hanyalah sebuah contoh. Saya tidak dapat memikirkan sekarang data biner apa pun yang ingin kami simpan dalam file simpan tetapi di masa depan kami mungkin memilikinya. Masa depan agak sulit diprediksi. :)

Bagian dasar dan opsional memiliki beberapa masalah keamanan jika bagian opsional adalah sesuatu yang dapat ditambahkan dengan bebas oleh klien. Itu membuka beberapa cara bagaimana klien bugy dapat mengatur inti tox dalam bahaya dengan memberikan data yang dibuat dengan baik atau bugy. Saya percaya bahwa kemungkinan ini dapat diminimalkan dengan memastikan bahwa bagian yang ditambahkan oleh klien tidak ditafsirkan oleh toxcore dan toxcore secara sintaksis memvalidasi bagian yang ingin disertakan oleh klien.

@mendadak6

Maksud saya persis bahwa klien dapat menggunakan metode penguraian apa pun karena mereka memiliki bagian konfigurasi yang disimpan dan dimuat dari file oleh toxcore. Misalnya qTox tidak memerlukan parser JSON eksternal karena saya pikir Qt sudah memiliki parser JSON sendiri. Juga, jika klien ditulis dengan beberapa bahasa lain, mereka dapat memiliki parser JSON asli dan perpustakaan parser C hanya membuat segalanya lebih rumit di sana.

Saya tidak suka ide di mana klien mengimplementasikan file ekspor mereka sendiri. Saya khawatir bahwa dengan cara itu kami hanya mendapatkan sejumlah besar file ekspor yang tidak kompatibel dan kekacauan besar. Ini harus menjadi tanggung jawab dan fitur toxcore.

Jika pemisahan bagian dasar dan opsional semacam ini terlalu berisiko dalam hal apa pun, saya tetap memberikan +1 untuk format JSON. Saya telah melihat terlalu banyak b *t XML configs atau tumpukan binary * .