Foi lançado o Node-to-Node CoPy (NNCP), um conjunto de utilitários para a transferência segura de arquivos, e-mails e comandos em modo store-and-forward. Suporta operação em sistemas operacionais compatíveis com POSIX. Os utilitários são escritos na linguagem Go e distribuídos sob a licença GPLv3.
Os utilitários são projetados para ajudar a construir pequenas redes peer-to-peer (dúzias de nós) com roteamento estático para a transferência segura de arquivos em modo fire-and-forget, solicitações de arquivos, e-mails e pedidos de execução de comandos. Todos os pacotes transmitidos são criptografados (end-to-end) e autenticados explicitamente com chaves públicas conhecidas de contatos. Criptografia em camadas (como no Tor) é aplicada a todos os pacotes intermediários. Cada nó pode atuar tanto como cliente quanto servidor e usar tanto o modelo push quanto o poll de comportamento.
A principal diferença do NNCP em relação às soluções UUCP e FTN (FidoNet Technology Network), além da criptografia e autenticação mencionadas acima, é o suporte imediato para redes floppynet e computadores fisicamente isolados (air-gapped) de redes locais e públicas não seguras. Uma característica do NNCP é a fácil integração (junto com UUCP) com os atuais sistemas de correio servidores, como Postfix e Exim.
Possíveis áreas de aplicação do NNCP incluem a organização do envio/recebimento de e-mails em dispositivos sem conexão constante à internet, transferência de arquivos em condições de conexão de rede instável, transferência segura de grandes volumes de dados em mídias físicas, criação de redes isoladas de transmissão de dados protegidas contra ataques MitM, contornar censura e vigilância de rede. Como a chave para descriptografar está apenas com o destinatário, independentemente dos caminhos de entrega do pacote pela rede ou através de mídias físicas, uma terceira parte não pode ler o conteúdo, mesmo interceptando a remessa. Por sua vez, a autenticação por assinatura digital não permite criar uma remessa falsa sob a aparência de outro remetente.
Entre as novidades do NNCP 8.8.0, em comparação com a versão anterior (5.0.0):
- Em vez do hash BLAKE2b para verificar a integridade dos arquivos, foi utilizado o que é conhecido como MTH: Hashing baseado em Árvore de Merkle, que utiliza o hash BLAKE3. Isso permite calcular a integridade da parte criptografada do pacote durante o download, sem a necessidade de leitura posterior. Também oferece a possibilidade de verificação de integridade em paralelo sem limites.
- O novo formato de pacotes criptografados é totalmente amigável para streaming, mesmo quando o tamanho dos dados é desconhecido de antemão. O sinal de conclusão da transmissão, com um tamanho autenticado, é enviado diretamente dentro do fluxo criptografado. Antes, para saber o tamanho dos dados transmitidos, era necessário salvá-los em um arquivo temporário. Assim, a opção "-use-tmp" foi eliminada da equipe "nncp-exec" por total desnecessidade.
- As funções BLAKE2b KDF e XOF foram substituídas por BLAKE3 para reduzir o número de primitivas criptográficas utilizadas e simplificar o código.
- Agora é possível detectar outros nós na rede local através de broadcast para o endereço "ff02::4e4e:4350".
- Grupos de broadcast (análogos às conferências de eco do FidoNet ou grupos de notícias do Usenet) foram introduzidos, permitindo que um único pacote envie dados para múltiplos participantes do grupo, onde cada um também retransmite o pacote para os demais assinantes. A leitura do pacote de broadcast requer conhecimento da chave pública (é necessário ser um participante do grupo), mas a retransmissão pode ser feita por qualquer nó.
- Foi incorporado suporte para confirmação explícita de recebimento do pacote. O remetente pode optar por não excluir o pacote após o envio, aguardando o recebimento de um ACK especial do destinatário.
- O suporte à rede overlay Yggdrasil foi incorporado: daemons online podem atuar como participantes autônomos na rede, sem o uso de implementações externas do Yggdrasil e funcionando plenamente com a pilha IP em uma interface de rede virtual.
- Em vez de strings estruturadas (RFC 3339), o log utiliza gravações no formato recfile, com as quais é possível usar utilitários GNU Recutils.
- Opcionalmente, os cabeçalhos dos pacotes criptografados podem ser armazenados em arquivos separados na subdiretório "hdr/", acelerando significativamente as operações de listagem de pacotes em sistemas de arquivos com grandes tamanhos de bloco, como ZFS. Anteriormente, a obtenção do cabeçalho do pacote exigia a leitura de 128KiB do bloco do disco por padrão.
- A verificação de novos arquivos pode opcionalmente utilizar subsistemas do kernel como kqueue e inotify, fazendo menos chamadas de sistema.
- As utilidades mantêm menos arquivos abertos, ocorrendo menos frequentemente o seu fechamento e reabertura. Com um grande número de pacotes, anteriormente poderia haver uma limitação no número máximo de arquivos abertos.
- Muitas comandos começaram a mostrar progresso e velocidade na execução de operações, como download/upload, cópia e processamento (toss) de pacotes.
- O comando «nncp-file» pode enviar não apenas arquivos únicos, mas também diretórios, criando on-the-fly um arquivo pax com seu conteúdo.
- Utilitários online podem opcionalmente chamar imediatamente o processo de processamento de pacotes (tossing) após o download bem-sucedido de um pacote, sem iniciar um demônio separado «nncp-toss».
- A chamada online de outro participante pode opcionalmente ocorrer não apenas por um evento de disparo de timer, mas também pelo fato da presença de um pacote de saída na diretório spool.
- A funcionalidade foi assegurada para sistemas operacionais NetBSD e OpenBSD, além dos anteriormente suportados FreeBSD e GNU/Linux.
- O «nncp-daemon» é totalmente compatível com a interface UCSPI-TCP. Juntamente com a possibilidade de registro de logs em um descritor de arquivo especificado (por exemplo, definindo «NNCPLOG=FD:4»), é completamente amigável para execução com utilitários semelhantes aos daemontools.
- A compilação do projeto foi totalmente migrada para o sistema redo.
Fonte: opennet.ru
