19 Atualizações de segurança

Ocasionalmente, vulnerabilidades de segurança importantes são descobertas em pacotes de software e devem ser corrigidas. Os desenvolvedores do Guix se esforçam para manter o controle das vulnerabilidades conhecidas e aplicar correções o mais rápido possível no branch master do Guix (ainda não fornecemos um branch “stable” contendo apenas atualizações de segurança). A ferramenta guix lint ajuda os desenvolvedores a descobrirem sobre versões vulneráveis de pacotes de software na distribuição:

$ guix lint -c cve
gnu/packages/base.scm:652:2: glibc@2.21: probably vulnerable to CVE-2015-1781, CVE-2015-7547
gnu/packages/gcc.scm:334:2: gcc@4.9.3: probably vulnerable to CVE-2015-5276
gnu/packages/image.scm:312:2: openjpeg@2.1.0: probably vulnerable to CVE-2016-1923, CVE-2016-1924
…

Veja Invocando guix lint, para mais informações.

Guix segue uma disciplina de gerenciamento de pacotes funcional (veja Introdução), o que implica que, quando um pacote é alterado, todo pacote que depende dele deve ser reconstruído. Isso pode desacelerar significativamente a implantação de correções em pacotes principais, como libc ou Bash, já que basicamente toda a distribuição precisaria ser reconstruída. Usar binários pré-construídos ajuda (veja Substitutos), mas a implantação ainda pode levar mais tempo do que o desejado.

To address this, Guix implements grafts, a mechanism that allows for fast deployment of critical updates without the costs associated with a whole-distribution rebuild. The idea is to rebuild only the package that needs to be patched, and then to “graft” it onto packages explicitly installed by the user and that were previously referring to the original package. The cost of grafting is typically very low, and order of magnitudes lower than a full rebuild of the dependency chain.

For instance, suppose a security update needs to be applied to Bash. Guix developers will provide a package definition for the “fixed” Bash, say bash-fixed, in the usual way (veja Definindo pacotes). Then, the original package definition is augmented with a replacement field pointing to the package containing the bug fix:

(define bash
  (package
    (name "bash")
    ;; …
    (replacement bash-fixed)))

From there on, any package depending directly or indirectly on Bash—as reported by guix gc --requisites (veja Invocando guix gc)—that is installed is automatically “rewritten” to refer to bash-fixed instead of bash. This grafting process takes time proportional to the size of the package, usually less than a minute for an “average” package on a recent machine. Grafting is recursive: when an indirect dependency requires grafting, then grafting “propagates” up to the package that the user is installing.

Currently, the length of the name and version of the graft and that of the package it replaces (bash-fixed and bash in the example above) must be equal. This restriction mostly comes from the fact that grafting works by patching files, including binary files, directly. Other restrictions may apply: for instance, when adding a graft to a package providing a shared library, the original shared library and its replacement must have the same SONAME and be binary-compatible.

The --no-grafts command-line option allows you to forcefully avoid grafting (veja --no-grafts). Thus, the command:

guix build bash --no-grafts

returns the store file name of the original Bash, whereas:

guix build bash

returns the store file name of the “fixed”, replacement Bash. This allows you to distinguish between the two variants of Bash.

To verify which Bash your whole profile refers to, you can run (veja Invocando guix gc):

guix gc -R $(readlink -f ~/.guix-profile) | grep bash

… e compare os nomes dos arquivos de armazém que você obtém com os acima. Da mesma forma para uma geração completa do sistema Guix:

guix gc -R $(guix system build my-config.scm) | grep bash

Por fim, para verificar quais processos Bash estão em execução, você pode usar o comando lsof:

lsof | grep /gnu/store/.*bash