Como revisar um pacote AUR

Na sexta-feira, 18 de julho de 2025, a equipe do Arch Linux foi notificada que três OURO foram carregados pacotes que continham malware. Alguns mantenedores, inclusive eu, cuidaram de excluir esses pacotes, removendo todos os vestígios do código malicioso e protegendo contra futuros uploads maliciosos.

Meu colega mantenedor Quentin Michaud já fiz um belo artigo sobre como o malware funcionouentão não vou entrar em muitos detalhes sobre isso. Se você quiser saber mais sobre isso, leia o blog dele. Em vez disso, gostaria de fazer um curso intensivo sobre como esses scripts de empacotamento funcionam e como você mesmo os revisaria.

Qual é o OURO?

O Arch User Repository é uma coleção de scripts de empacotamento, PKGBUILD arquivos, criados pelos usuários. Qualquer pessoa que crie uma conta no aur.archlinux.orgpode fazer upload de um script de empacotamento do Arch Linux, desde que ainda não exista um com o mesmo nome. Claro que existem
algumas regras em torno do que você pode enviar (por exemplo, não duplique outros documentos oficiais ou
OURO pacotes), mas geralmente vale tudo.

Cada pacote tem um mantenedor principal, por padrão quem carregou o script de empacotamento primeiro, mas isso pode mudar com o tempo, seja pelo próprio mantenedor transferindo a responsabilidade ou pelos moderadores removendo o mantenedor por vários motivos. Isto não é uma democracia, nem mesmo uma meritocracia, mas funciona e há muitos softwares úteis aí.

Instalando de OURO empacotar scripts não é tão simples quanto instalar a partir dos repositórios de pacotes principais. Você pode correr makepkg em um PKGBUILD e instale o pacote resultante, mas isso fica mais difícil à medida que PKGBUILDs geralmente dependem de outros pacotes encontrados apenas no OURO. Para tornar isso mais fácil, as pessoas costumam usar OURO-ajudantes, que fornecem um pacman-como experiência para gerenciá-los. Isso traz algumas desvantagens, no entanto.

Quem quiser fazer isso pode enviar seu PKGBUILD para o OURO. Isso é ótimo para diminuir a barreira de entrada, e foi assim que comecei a contribuir para o Arch Linux. Infelizmente, nem todos têm as melhores intenções e já aconteceu de pessoas carregarem malware. Por isso, é crucial que você examine o PKGBUILDé que você instala.

O que fazer PKGBUILDparece?

Como mencionado anteriormente, o OURO não contém pacotes, mas contém scripts de construção para criar pacotes. Arco Linux PKGBUILDs são simplesmente scripts bash que seguem um determinado padrão. Tomemos por exemplo o seguinte exemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34



# Maintainer: John Doe 
pkgname=example
pkgver=1.0
pkgrel=1
pkgdesc="An example package"
arch=(x86_64)
url="https://example.org/"
license=('WTFPL')
install="example.install"
source=("https://example.org/$pkgname-$pkgver.tar.gz"
        "$pkgname-$pkgver.patch::https://git.example.org/example/pull/42.patch")
sha256sums=("de4bba005e86b4fbf0399e2cb492b1e941099b951a45137212507c2cbc8fae63"
            "b6dc933311bc2357cc5fc636a4dbe41a01b7a33b583d043a7f870f3440697e27")

prepare() {
    cd "$pkgname-$pkgver"
    patch -p1 -i "$srcdir/$pkgname-$pkgver.patch"
}

build() {
    cd "$pkgname-$pkgver"
    ./configure --prefix=/usr
    make
}

check() {
    cd "$pkgname-$pkgver"
    make -k check
}

package() {
    cd "$pkgname-$pkgver"
    make DESTDIR="$pkgdir/" install
}

Começa com uma linha de mantenedor, que não é usada programaticamente, mas ajuda os usuários do software a entrar em contato com o mantenedor se algo não funcionar. É uma boa prática ter também lá os e-mails dos mantenedores anteriores, para reconhecer suas contribuições. Então chegamos a algumas variáveis ​​de metadados.

Metadados

pkgname

define o pacote que estamos construindo no momento.

pkgver

significa qual versão upstream do software está sendo construída. Este número só deverá aumentar, à medida que pacman usará esse número para determinar se uma atualização é necessária.

pkgrel

é o número de lançamento do pacote. Este número de versão é incrementado sempre que uma atualização é feita no PKGBUILD sem atualizar o pkgvercomo quando as opções de embalagem mudam. Ele redefine para 1 toda vez que uma nova versão upstream é feita.

pkgdesc

é uma descrição curta e legível do pacote. Isso é mostrado nas listas de pacotes e é usado para pesquisa, mas de outra forma não afeta o software construído.

arch

é uma lista de arquiteturas de CPU válidas para as quais este pacote pode ser construído. Também pode ser o array especial ('any')o que não indica (apenas) que este pacote pode ser construído para qualquer arquitetura, mas sim que o pacote resultante não contém nenhum código específico da arquitetura. Isso é comum para pacotes escritos em linguagens como Python.

url

é apenas um link que um usuário do pacote pode acessar para obter mais informações e não afeta o pacote de outra forma.

license

é a licença sob a qual este pacote é distribuído. Costumava ser uma matriz de todas as licenças aplicáveis ​​ao projeto, mas como o significado disso é um pouco ambíguo, atualmente a matriz de licenças deve conter um único item que é um Expressão de licença SPDX.

install

geralmente não está presente em um PKGBUILD. Se presente, refere-se ao nome de um script (incluído junto com o arquivo do pacote) com funções bash específicas que serão executadas quando o pacote for instalado, atualizado ou removido. É executado de pacmane, portanto, como raiz.

source

é uma matriz de fontes. Podem ser URLs para download, URLs de controle de versão, como git, ou nomes de arquivo simples, ou seja, o arquivo em questão como parte dos arquivos do pacote.

sha256sums

é outra matriz, do mesmo comprimento das fontes, especificando o esperado SHA-256 somas de verificação para as fontes do pacote. Existem outros algoritmos de hash disponíveis, desde crc32sums para b2sums. Vários conjuntos de resumos podem ser especificados, mas pelo menos um deve ser. O valor mágico SKIP pode ser usado para ignorar a verificação de somas de verificação para determinados arquivos, por exemplo, para somas de verificação externas ou assinaturas PGP.

Depois de todos esses metadados, chegamos ao código real que faz alguma coisa: as funções de empacotamento.

Funções de construção

A construção de pacotes é feita em 4 etapas, cada uma com sua própria função bash. Começa com
prepare(). Espera-se que esta função faça todas as alterações necessárias no código-fonte, como aplicar arquivos de patch ou editar certas linhas com sed. Em certos ecossistemas, como Node.js e Rust, ele também baixa as dependências. Idealmente, todas as etapas seguintes prepare() não precisa mais de acesso à rede.

Então chegamos a build()que, como o nome sugere, cria o pacote. Este é o lugar para chamar scripts de configuração, compiladores e qualquer outra coisa que produza os binários envolvidos. Esta é, geralmente, a parte que leva tempo.

Após a embalagem, geralmente há um check() etapa. Aqui queremos verificar se o pacote funciona conforme pretendido, dentro do pacote Arch Linux. O que fazer aqui varia, mas a maioria PKGBUILDVamos tentar executar os testes de unidade do pacote. O Arch Linux geralmente nunca tem versões de bibliotecas diferentes daquelas com as quais os projetos upstream são testados, e tais testes formam um teste razoável de que as coisas não quebraram de maneiras inesperadas.

Finalmente, o package() função é chamada. Esta é a única função tecnicamente necessária, todas as outras podem ser omitidas. Esta função deve mover os arquivos, gerados no build() passo, em suas posições finais em relação a alguns $pkgdir. Muitos ecossistemas fornecem (o equivalente a)
make install para isso, o que torna a vida mais fácil, mas muitas vezes você simplesmente terá que explicar isso.

O que procurar

Agora que sabemos quais são as diferentes partes de um PKGBUILD quer dizer, podemos falar sobre a revisão de seu conteúdo. Quero abordar alguns dos itens que considero mais importantes, mas esta não é de forma alguma uma lista exaustiva. O fato de eu estar escrevendo isso provavelmente afetará de alguma forma as estratégias que as pessoas usam. No entanto, vamos fechar…

Verifique o sources variedade

Independentemente do que PKGBUILD ele mesmo diz que se as fontes que ele vai compilar forem maliciosas, nada mais importa. Certifique-se de confiar no projeto upstream e de que os arquivos sejam baixados de um local razoável, como tags em repositórios git oficiais ou versões de código-fonte no site oficial. As assinaturas PGP dos autores são geralmente ainda melhores, então você sabe quem criou, ou pelo menos assinou as fontes.

O projeto Arch Linux tem aceitou uma RFC sobre quais fontes devem ser usadaspara ter as fontes mais confiáveis ​​de embalagens. Embora tal rigor não seja necessário ou, em alguns casos, até desejável para o OUROvocê pode usá-lo como inspiração.

Os patches também são fontes e o malware pode se esconder neles. Você deve dar uma olhada em quaisquer patches aplicados ao código-fonte e, se possível, de onde eles vêm. Não é incomum aplicar alterações mescladas, mas não lançadas, do upstream para lidar com versões mais recentes de bibliotecas, mas certifique-se de que isso faça sentido.

Verifique se as etapas de construção fazem sentido

O prepare(), build(), check()e package() funções são inerentemente código que será executado em sua máquina quando você construir um pacote, então se houver

• Nenhum download deve acontecer em build(), check()ou package()e, idealmente, não em
  prepare()embora muitos ecossistemas (Go, Node.js, Rust, para citar alguns) exijam isso.

• Os comandos executados pelo script devem ser comandos de empacotamento óbvios e quaisquer scripts personalizados devem vir dos repositórios upstream. Freqüentemente, o script de empacotamento corresponde ao “como instalar” do upstream, mas muitas vezes não, já que os mantenedores do pacote geralmente chamam as ferramentas de construção diretamente, em vez de chamar os scripts de wrapper.

• Os scripts de compilação não devem ser executados sudo ou algo semelhante. Se isso acontecer de qualquer maneira, está errado. Na melhor das hipóteses, é um erro de embalagem, pois sudo não se deve esperar que funcione em um ambiente não interativo como um chroot de construção. Às vezes, um empacotador tenta erroneamente mover os arquivos do pacote para o lugar em vez de adicioná-los ao pacote.

Examine os scripts de instalação

Os scripts de instalação são, como mencionado acima, raramente vistos, mas se forem, eles precisam ser examinados, pois seu conteúdo será executado, como raizquando um pacote é instalado, atualizado ou removido. A maioria dos softwares não precisa disso, pois os casos de uso comuns têm alternativas mais seguras.

Da mesma forma, recém-instalados pacman ganchos também devem levantar uma sobrancelha. Ganchos Pacman instalados em
/usr/share/libalpm/hooks (e às vezes para /etc/pacman.d/hooks embora isso esteja incorreto) e pode executar um comando sempre que seus gatilhos forem acionados. Os incluídos nos principais repositórios Arch são benignos e de fato reduzem a necessidade de install scripts, regenerando automaticamente caches de fontes e ícones conforme necessário, regenerando o initramfse muito mais. Um arbitrário PKGBUILD adicionar um deles é incomum e você deve prestar atenção ao que esse gancho está tentando fazer.

Se você não entende, não use

Enquanto tentamos mantê-lo limpo, o OURO é acessível gratuitamente para qualquer pessoa que descubra como superar o CAPTCHA, e qualquer pessoa pode fazer upload de código para ele. Mesmo códigos populares e bem-intencionados podem ter bugs às vezes e causar danos ao seu sistema. O OURO é, na melhor das hipóteses, mantido por voluntários, muitos dos quais estão atualmente molhando os pés pela primeira vez enquanto embalam. Erros podem e irão acontecer, e tudo bem.

Quando algo pode ser malicioso

Agora que temos um palpite sobre o que pode ser malicioso, podemos decidir o que fazer com isso. A maneira mais fácil é simplesmente perguntar. O melhor lugar para isso, na minha opinião, é o #archlinux-aur Canal IRC ativado Livreque é o local oficial para OURO discussão.
Os fóruns também são um bom lugar para perguntar. Se tudo falhar, há também o lista de discussão.

Se o pacote for realmente malicioso, um dos mantenedores do pacote poderá retirá-lo e bloquear o(s) usuário(s) infrator(es). Caso tentem evitar a proibição, as medidas também aumentarão. Como usuário, é aí que termina sua contribuição.

Isso parece muito simples

E é. O OURO foi feito para um tipo diferente de internet. Mais cooperativo, menos hostil. É baseado na confiança de que os usuários geralmente farão coisas sensatas. ^{O OURO é um software antigo. Tudo começou como “apenas um servidor FTP” onde as pessoas podiam fazer upload de arquivos. Tal sistema não seria concebido em 2026.}

Há melhorias a serem obtidas, com certeza. Os sistemas de moderação são um tanto arcaicos, o fluxo de trabalho de contribuição não é o que as pessoas esperam. O licenciamento de PKGBUILD arquivos, especialmente quando o autor original já se foi, é complicado. ^{Um sistema semelhante a uma solicitação pull é frequentemente sugerido. Acho que isso seria uma melhoria real. Em geral, o sistema precisa de mais amor. Isso é o que você obtém com projetos de código aberto; se ninguém quiser trabalhar nisso, não há trabalho. E tudo bem.}

Neste momento, acredito que não há fim à vista para o OURO. Podemos continuar como estão por mais algum tempo. Mas se as pessoas se esforçassem para melhorar as coisas, poderíamos fazer muito mais.