Paglabas ng NNCP 8.8.0, mga utility para sa paglilipat ng mga file/utos sa store-and-forward mode

Ang paglabas ng Node-to-Node CoPy (NNCP), isang set ng mga utility para sa ligtas na paglilipat ng mga file, email, at mga command para sa pagpapatupad sa store-and-forward mode. Sinusuportahan ang operasyon sa mga operating system na katugma sa POSIX. Ang mga utility ay nakasulat sa Go at ipinamahagi sa ilalim ng lisensya ng GPLv3.

Nakatuon ang mga utility sa pagtulong na bumuo ng maliliit na peer-to-peer na kaibigan-sa-kaibigan na network (dosenang mga node) na may static na pagruruta para sa secure na fire-and-forget na paglilipat ng file, mga kahilingan sa file, email, at mga kahilingan sa command. Ang lahat ng ipinadalang packet ay naka-encrypt (end-to-end) at tahasang pinatotohanan gamit ang mga kilalang pampublikong key ng mga kaibigan. Ang onion (tulad ng sa Tor) encryption ay ginagamit para sa lahat ng intermediate na packet. Ang bawat node ay maaaring kumilos bilang isang kliyente at isang server at gumamit ng parehong mga modelo ng pag-uugali ng push at poll.

Ang pagkakaiba sa pagitan ng mga solusyon sa NNCP at UUCP at FTN (FidoNet Technology Network), bilang karagdagan sa nabanggit na pag-encrypt at pagpapatunay, ay out-of-the-box na suporta para sa mga floppinet network at mga computer na pisikal na nakahiwalay (air-gapped) mula sa hindi secure na lokal at publiko mga network. Nagtatampok din ang NNCP ng madaling pagsasama (katulad ng UUCP) sa mga kasalukuyang mail server tulad ng Postfix at Exim.

Kabilang sa mga posibleng lugar ng aplikasyon para sa NNCP ang pag-aayos ng pagpapadala/pagtanggap ng mail sa mga device na walang permanenteng koneksyon sa Internet, paglilipat ng mga file sa mga kondisyon ng hindi matatag na koneksyon sa network, ligtas na paglilipat ng napakaraming data sa pisikal na media, paglikha ng mga nakahiwalay na network ng paghahatid ng data na protektado mula sa Mga pag-atake ng MitM, pag-bypass sa censorship at pagsubaybay sa network. Dahil ang decryption key ay nasa kamay lamang ng tatanggap, hindi alintana kung ang packet ay naihatid sa network o sa pamamagitan ng pisikal na media, hindi mabasa ng isang third party ang mga nilalaman, kahit na ang package ay naharang. Sa turn, hindi pinapayagan ng digital signature authentication ang paglikha ng isang gawa-gawang mensahe sa ilalim ng pagkukunwari ng isa pang nagpadala.

Kabilang sa mga inobasyon ng NNCP 8.8.0, kumpara sa nakaraang balita (bersyon 5.0.0):

  • Sa halip na BLAKE2b hash, ang tinatawag na MTH: Merkle Tree-based Hashing, na gumagamit ng BLAKE3 hash, ay ginagamit upang suriin ang integridad ng mga file. Binibigyang-daan ka nitong kalkulahin ang integridad ng naka-encrypt na bahagi ng packet sa panahon ng pag-download, nang hindi kinakailangang basahin ito sa hinaharap. Nagbibigay-daan din ito para sa walang limitasyong parallelization ng integrity checks.
  • Ang bagong naka-encrypt na packet format ay ganap na streaming-friendly kapag ang laki ng data ay hindi alam nang maaga. Ang pagbibigay ng senyas ng pagkumpleto ng paglipat, na may napatotohanang laki, ay direktang napupunta sa loob ng naka-encrypt na stream. Noong nakaraan, upang malaman ang laki ng inilipat na data, kinakailangan na i-save ito sa isang pansamantalang file. Kaya ang command na "nncp-exec" ay nawala ang "-use-tmp" na opsyon dahil ito ay ganap na hindi kailangan.
  • Ang BLAKE2b KDF at XOF function ay pinalitan ng BLAKE3 upang bawasan ang bilang ng mga cryptographic primitive na ginamit at pasimplehin ang code.
  • Posible na ngayong makakita ng iba pang mga node sa lokal na network sa pamamagitan ng multicasting sa address na "ff02::4e4e:4350".
  • Ang mga multicast na grupo ay lumitaw (katulad sa FidoNet echo conference o Usenet news group), na nagpapahintulot sa isang packet na magpadala ng data sa maraming miyembro ng grupo, kung saan ang bawat isa ay nagre-relay din ng packet sa iba pang mga signatories. Ang pagbabasa ng multicast packet ay nangangailangan ng kaalaman sa key pair (dapat kang tahasang miyembro ng grupo), ngunit ang pag-relay ay maaaring gawin ng anumang node.
  • Mayroon na ngayong suporta para sa tahasang pagkumpirma ng packet receipt. Maaaring hindi tanggalin ng nagpadala ang packet pagkatapos ipadala, naghihintay hanggang makatanggap ito ng espesyal na ACK packet mula sa receiver.
  • Built-in na suporta para sa Yggdrasil overlay network: ang mga online na daemon ay maaaring kumilos bilang ganap na independiyenteng mga kalahok sa network, nang hindi gumagamit ng mga third-party na pagpapatupad ng Yggdrasil at hindi ganap na gumagana sa IP stack sa isang virtual na interface ng network.
  • Sa halip na mga structured string (RFC 3339), ang log ay gumagamit ng mga recfile entries, na maaaring gamitin sa mga utility ng GNU Recutils.
  • Opsyonal, ang mga naka-encrypt na packet header ay maaaring iimbak sa magkahiwalay na mga file sa "hdr/" subdirectory, na makabuluhang nagpapabilis ng mga operasyon sa pagkuha ng listahan ng packet sa mga file system na may malalaking sukat ng block, tulad ng ZFS. Dati, ang pagkuha ng packet header ay nangangailangan ng pagbabasa lamang ng 128KiB block mula sa disk bilang default.
  • Ang pagsuri para sa mga bagong file ay maaaring opsyonal na gamitin ang kqueue at i-notify ang mga kernel subsystem, na gumagawa ng mas kaunting mga system call.
  • Ang mga utility ay nagpapanatili ng mas kaunting bukas na mga file at isara at muling buksan ang mga ito nang mas madalas. Sa isang malaking bilang ng mga pakete, dati ay posible na tumakbo sa isang limitasyon sa maximum na bilang ng mga bukas na file.
  • Maraming mga koponan ang nagsimulang ipakita ang pag-unlad at bilis ng mga operasyon tulad ng pag-download/pag-upload, pagkopya at pagproseso (paghahagis) ng mga pakete.
  • Ang command na "nncp-file" ay maaaring magpadala hindi lamang ng mga solong file, kundi pati na rin ng mga direktoryo, na lumilikha ng isang pax archive na may mga nilalaman ng mga ito sa mabilisang.
  • Ang mga online utilities ay maaaring opsyonal na agad na mag-invoke ng packet tossing pagkatapos na matagumpay na ma-download ang isang package, nang hindi nagpapatakbo ng hiwalay na "nncp-toss" na daemon.
  • Ang isang online na tawag sa isa pang kalahok ay maaaring opsyonal na mangyari hindi lamang kapag ang isang timer ay na-trigger, ngunit din kapag ang isang papalabas na packet ay lumitaw sa direktoryo ng spool.
  • Tinitiyak ang operability sa ilalim ng NetBSD at OpenBSD OS, bilang karagdagan sa dating suportadong FreeBSD at GNU/Linux.
  • Ang "nncp-daemon" ay ganap na katugma sa interface ng UCSPI-TCP. Kasama ng kakayahang mag-log sa isang tinukoy na file descriptor (halimbawa sa pamamagitan ng pagtatakda ng "NNCPLOG=FD:4"), ito ay ganap na magiliw na tumakbo sa ilalim ng mga utility na tulad ng daemontools.
  • Ang pagpupulong ng proyekto ay ganap na nailipat sa redo system.

Pinagmulan: opennet.ru

Magdagdag ng komento