Openrsync - implementação de rsync da equipe do OpenBSD

 (github.com/kristapsdz)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • openrsync é uma implementação do rsync sob licença BSD (ISC) e atualmente está integrada à base do OpenBSD
  • É compatível com versões recentes do rsync, e nos testes foi usado o rsync 3.1.3, mas funciona desde que haja suporte ao protocolo 27
  • Como aceita apenas parte dos argumentos de linha de comando do rsync, ao usar openrsync junto com rsync é necessário utilizar flags suportadas por ambos os lados
  • O sistema operacional oficialmente suportado é o OpenBSD, mas inclui glue de portabilidade para que possa ser compilado e executado em outros sistemas UNIX
  • A documentação padrão está nas páginas de manual; os detalhes do protocolo estão em rsync(5) e rsyncd(5), e a documentação do utilitário está em openrsync(1)
  • O projeto foi escrito como parte do rpki-client(1) para OpenBSD, com financiamento de NetNod, IIS.SE, SUNET e 6connect
  • A instalação em sistemas UNIX comuns é feita com ./configure, make, make install e não entra em conflito com uma instalação existente do rsync
  • O algoritmo do rsync é dividido entre sender e receiver; o sender cria a lista de arquivos de origem e os metadados, e ambos os lados ordenam os nomes dos arquivos em ordem alfabética para referenciar os itens com base na posição
  • Na sincronização normal de arquivos, se o tamanho do arquivo e a hora de modificação forem iguais, ele é ignorado; se forem diferentes, os dados alterados são reconstruídos usando, para cada bloco de tamanho fixo, um hash rápido de 4 bytes no estilo Adler-32 e um hash lento MD4 de 16 bytes
  • O tamanho do bloco, por padrão, é o valor arredondado da raiz quadrada do tamanho total do arquivo; o tamanho mínimo é 700 B e o resultado da raiz quadrada, por um motivo desconhecido, é arredondado para cima até um múltiplo de 8
  • A sessão é dividida entre o cliente executado pelo usuário e um processo servidor executado remotamente; o servidor pode ser iniciado sob demanda via ssh(1) ou operar como um daemon de rede persistente
  • Diferentemente do generator do rsync, que roda como um processo separado ao lado do receiver, o openrsync combina generator e receiver em um único processo e responde a requisições de leitura e escrita com um loop de eventos
  • Em termos de segurança, ele usa pledge(2) do OpenBSD para limitar operações do sistema conforme o modo de execução, e unveil(2) para permitir acesso ao sistema de arquivos apenas dentro do diretório de destino
  • No modo servidor, a seed do hash MD4 é gerada com arc4random(3), e não com time(3)
  • Pode ser portado para Linux (glibc·musl), FreeBSD, NetBSD, Mac OS X e OmniOS, e o GitHub CI executa testes nas arquiteturas x86_64, aarch64 e s390x, mas a principal limitação da portabilidade é reproduzir recursos de segurança equivalentes ao pledge e ao unveil do OpenBSD

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • A explicação de que, quando o servidor remoto é a origem ou o destino, o cliente cria um filho com fork(2), inicia o servidor openrsync no host remoto via ssh(1) e então cliente e servidor se comunicam por um pipe socketpair(2) é meio ambígua sobre como isso funciona
    Imagino que isso queira dizer que o processo filho bifurcado passa a conexão ao pai por meio do par de sockets, ou conecta a entrada e saída padrão ao “pipe” do par de sockets e depois faz exec do ssh
    Mas isso é como dizer que você vai de carro até o aeroporto e então afirmar que vai de carro para a Austrália

  • Venho usando o openrsync aqui e ali desde que foi anunciado, e com o tempo ele claramente melhorou bastante. Estou esperando o momento em que poderei usá-lo totalmente
    Só há um ponto em que ele não bate com o Samba rsync no meu padrão de uso: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
    O comportamento esperado é criar o arquivo /tmp/services no remoto, mas na prática ele cria /tmp/services/services
    Espelhamento de diretório normal, como -av -e ssh /path/to/src/ example.com:/path/to/dst/, funciona como no Samba rsync

    • Esse comportamento parece bater também com o rsync “normal”. Para sincronizar só o conteúdo, provavelmente seria preciso uma barra final depois de services
      Correção: na verdade, meu rsync “normal” também era o openrsync do macOS
    • A questão importante é se já existia um diretório /tmp/services no destino
      Uma das partes mais confusas do rsync é justamente como ele trata diretórios e barras finais
    • Com uma barra final na origem, ele copia a partir de dentro do diretório; sem ela, copia o diretório em si. Pelo que sei, esse é um comportamento bem padrão entre ferramentas POSIX em geral
    • Como alguém que foi atormentado pelo rsync por incontáveis anos, entendo o impulso, mas criar o segundo services faz muito mais sentido e é um padrão mais seguro
      Se existe uma chance de mudar o padrão do rsync para algo menos insano, temos que poupar as futuras gerações dessa confusão

  • Considerando o aumento repentino recente de commits de vibe coding na base de código do rsync, e até regressões causadas por isso, essa é uma notícia muito boa

    • O rsync sempre foi sólido, então eu quis ignorar esse tipo de comentário, mas na prática meus scripts de backup quebraram depois do upgrade
      As issues mais recentes no GitHub listam muitos bugs introduzidos nos 2 últimos patches, incluindo um commit monstruoso de cerca de 9 mil linhas que provavelmente nem significava muita coisa
      LLMs tornam escrever código mais rápido e fácil, mas o importante sempre foi pensar. Não faço ideia de por que estragar um software tão antigo e confiável

  • Para quem precisa de contexto sobre a motivação desse pacote, este projeto está sendo desenvolvido atualmente como parte de um validador de RPKI
    https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

  • Também existe a implementação em Go do Michael Stapelberg / time do Gokrazy: https://github.com/gokrazy/rsync

  • O cerne do trabalho real de portar isso é reproduzir as funcionalidades de segurança oferecidas por pledge(2) e unveil(2) no OpenBSD. Elas são fatores decisivos do sistema
    Sem essas funcionalidades, o sistema acaba aceitando dados arbitrários de redes públicas
    https://justine.lol/pledge/
    No Alpine Linux edge eu não vejo pledge. Alguém já testou o Pledge no Linux? Estou entendendo errado o risco de usar openrsync sem pledge, ou esse texto é voltado apenas para usuários de OpenBSD?

    • O Linux não tem pledge, unveil nem recursos como o Capsicum. Ele tem cgroups, namespaces e um monte de outras coisas que você precisa combinar para fazer algo parecido
      Em vez de ser construído como uma funcionalidade de isolamento que fornece o conceito inteiro por meio de certas syscalls e caminhos do kernel, o Linux foi sendo montado com vários sistemas adicionados repetidamente e combinados entre si para compor sandboxing ou restrição de capacidades
      Hoje em dia o lado do Linux parece ter recursos novos como Landlock, mas provavelmente de uma forma construída sobre elementos básicos já existentes no Linux, em vez de algo totalmente novo
      “Bagunçado” provavelmente quer dizer que está espalhado por toda parte. Há formas demais de trancar o sistema, e para escolher a melhor você precisa se aprofundar bastante em cada subsistema, em contraste com usar só 1 ou 2 syscalls simples
    • Acima do trecho citado está escrito: “O único sistema operacional oficialmente suportado é o OpenBSD, porque possui funcionalidades de segurança substanciais”
      E abaixo está escrito: “Talvez fosse possível com o Capsicum do FreeBSD, mas as facilidades de segurança do Linux são uma bagunça e seria preciso o toque de um especialista para protegê-lo corretamente”
      Ou seja, dizer que é portável significa que compila e roda, não que tenha os mesmos recursos de segurança
      Seria bom se pledge/unveil entrassem no upstream do Linux, mas eu não contaria com isso
    • Essa citação parece simplificar demais as coisas, a ponto de ficar quase totalmente errada
      Ao contrário da frase “sem essas funcionalidades, o sistema aceita dados arbitrários de redes públicas”, pledge e unveil não mudam se ele aceita ou não dados arbitrários. Elas limitam o que um processo comprometido por uma vulnerabilidade pode fazer
      A seção Security explica isso corretamente, então não sei de onde veio aquela formulação

  • Esta é a versão usada no macOS 15.0 em diante

    • Foi no 15.0? Eu lembrava de ela ter entrado em uma das versões menores da linha 15.x, e lembro de alguns scripts quebrando sem explicação
      Correção: curiosamente, embora ela tenha sido incluída no 15.0, parece que eles guardaram a mudança incompatível que quebrava retrocompatibilidade até o 15.4. https://apple.stackexchange.com/a/479297

  • Como ele não suporta o protocolo rsync recente, não há suporte a timestamps de 64 bits, então em sistemas de arquivos novos ele não consegue sincronizar os metadados de fato

  • Fico curioso com o nome. Openrsync soa como uma alternativa open source a um programa de código fechado
    Mas o Rsync original também não é GPL? É só no sentido de que ele é “mais aberto” por ter uma licença mais permissiva?

    • O pessoal do OpenBSD provavelmente diria que a GPL é menos aberta, por exigir que obras derivadas também sejam distribuídas sob GPL
    • Há muitos projetos ligados de perto ao OpenBSD que começam com open, como openssh, openbgpd, openntpd e opensmtpd