<!-- CVS revision of this document "$Revision: 1.3 $"  -->
<!-- original version: 1.11 -->
<!-- last translator: sdiasneto@yahoo.com.br -->

<chapt>Infraestrutura do Debian Security

<sect id="debian-sec-team">O time Debian Security

<p>O Debian tem um Security Team (Time de Segurança), composto por cinco membros e duas secretárias que manipulam a segurança na distribuição <em>stable</em> (estável). Manipular a segurança significa que eles acompanham as vulnerabilidades que aparecem nos software (vendo foruns como bugtraq o vuln-dev) e determinam se a distribuição <em>stable</em> é afetada por eles.

<p>O Debian Segurity Team também é o contato para problemas que são coordenados pelos desenvolvedores ou organizações como <url id="http://www.cert.org" name="CERT"> que podem afetar muitos vendedores. Isto é, quando os problemas não são específicos do Debian. Existem dois contatos com o Security Team:

<list>

<item><url id="mailto:team@security.debian.org"
name="team@security.debian.org"> o qual só é lido pelos membros do security team . 

<item><url id="mailto:security@debian.org" name="security@debian.org"> o qual é lido por todos os desenvolvedores Debian (incluindo o security team). Emails enviados para esta lista não são publicados na internet (esta não é uma lista de email pública).

</list>

<p>Informações sensíveis devem ser enviadas para o primeiro email e, em alguns casos, deve ser encriptada com a Debian Security Contact key
(key ID 363CCD95).

<p>Quando um provável problema for recebido pelo Security Team, ele investigará se a distribuição <em>stable</em> foi afetada e, caso positivo, uma correção será feita no código fonte base. Esta correção algumas vezes incluirá algum patch (que normalmente é mais recente que a versão distribuída pelo Debian). Após o teste da correção, novos pacotes são preparados e publicados em <url id="security.debian.org"> e podem ser baixados com o <prgn>apt</prgn> (veja <ref id="security-update">). Ao mesmo tempo um <em>Debian Security Advisory</em> (DSA) é publicado no web site e enviado para a listas de email incluindo <url
id="lists.debian.org/debian-security-announce"
name="debian-security-announce"> e bugtraq.

<p>Outras perguntas frequentes do Debian Security Team podems er encontradas em <ref id="debian-sec-team-faq">.


<sect id="dsa">Debian Security Advisories

<p>Debian Security Advisories são avisos emitidos quandos uma vulnerabilidade de segurança que afeta um pacote Debian é descoberta. Estes avisos, assinados por um membro do Security Team, inclui informação das versões afetadas assim como a localização das atualizações e seus MD5sums. Esta informação consiste de:

<list>
<item>número da versão para correção.
<item>tipo de problema.
<item>se ele é remoto ou localmente explorável.
<item>pequena descriçãod do pacote.
<item>descrição do problema.
<item>descrição da exploração.
<item>descrição da correção.
</list>


<p>DSAs são publicados em <url id="http://www.debian.org/"
name="Debian's mainserver frontpage"> e em <url
id="http://www.debian.org/security/" name="Debian security
pages">. Normalmente isto não é feito até a reconstrução diária do website, então eles podem não estar presentes imediatamente, o canal preferido é a  debian-security-announce mailing list.

<p>Usuários interessados podem, porém, usar o canal RDF para baixar automaticamente as DSAs para seu computador. Algumas aplicações, como o  <prgn>Evolution</prgn> (um cliente de email e assistente de informações pessoais)  e o <prgn>Multiticker</prgn> (um applet do GNOME), podem ser usados para baixar os avisos automaticamente. O canal RDF está disponível em <url id="http://www.debian.org/security/dsa.rdf">.

<p>Os DSAs publicados no website podem ser atualizados após enviados para as listas de email. Uma atualização comum é adicionada através de referências ao banco de dados de vulnerabilidades de segurança. Além disso, traduções 
<footnote>Traduções estão disponíveis em dez idiomas</footnote> dos DSAs não são enviadas para as listas de email mas são diretamente incluídas no site.


<sect1 id="crossreference">Referências sobre vulnerabilidades

<p>Debian fornece uma referência completa em <url
id="http://www.debian.org/security/crossreferences"
name="crossreferenced table"> incluindo todas as remomendações publicadas desde 1998. Esta tabela é fornecida em complemento a <url
id="http://cve.mitre.org/cve/refs/refmap/source-DEBIAN.html"
name="reference map available at CVE">. 

<P>Você notará que esta tabela fornece referências aos bancos de dados como <url id="http://www.securityfocus.com/bid"
name="Bugtraq">,
<url id="http://www.cert.org/advisories/" name="CERT/CC Advisories">
and <url id="http://www.kb.cert.org/vuls" name="US-CERT Vulnerability
Notes Database"> assim como aos nomes CVE (veja abaixo). Estas referências são fornecidas para uso, porém apenas referências CVE são periodicamente revisadas e incluídas. Este recurso foi adicionado ao website em junho de 2002.

<p>Uma das vantagens de adicionar referências ao banco de dados de vulnerabilidades é que:

<list>
<item>torna fácil aos usuários Debian ver e tratar com recomendações publicadas que já tenham sido resolvidas pelo Debian.

<item>administradores de sistema podem aprender mais sobre vulnerabilidades e seu impacto através das referências.

<item>esta informação pode ser usada para a checagem de vulnerabilidades referentes ao CVE e detectar avisos falsos. (veja <ref id="vulnasses-false-positive">).

</list>
</sect1>

<sect1 id="cve-compatible">Compatibilidade CVE

<P>As recomendações de segurança, Debian Security Advisories eram <url
id="http://www.debian.org/security/CVE-certificate.jpg" name="declared
CVE-Compatible"><footnote>O completo <url
id="http://cve.mitre.org/compatible/phase2/SPI_Debian.html"
name="capability questionnaire"> estava disponível para o CVE </footnote> em fevereiro de 2004.

<p>Desenvolvedores Debian entendeream que precisavam fornecer precisas e atualizadas informações de segurança para a distribuição, permitindo aos usuários gerenciar o risco associado com novas vulnerabilidades. CVE fornece referências padronizadas que permitem aos usuários desenvolver um <url
id="http://www.cve.mitre.org/compatible/enterprise.html"
name="CVE-enabled security management process">.

<p>O projeto <url id="http://cve.mitre.org" name="Common Vulnerabilities and
Exposures (CVE)"> é mantido pela MITRE Corporation e fornece uma lista de nomes padronizados para vulnerabilidades e exposições de segurança.

<P>Debian acredita que fornecer aos usuários informações relacionadas a segurança que afetem a distribuição é extremamente importante. A inclusão dos nomes CVE em avisos ajudam os usuários a associar vulnerabilidades genéricas com atualizações específicas, com redução do tempo gasto para manusear as vulnerabilidades. Além disso, é fácil o gerenciamento da segurança em um ambiente onde já existem ferramentas que utilizam o CVE, como redes ou sistemas de deteccão de invasão, ou ferramentas de avalição de vulnerabilidades, mesmo que elas não sejam baseadas em uma distribuição Debian.

<p>Debian iniciou adicionando nomes CVE aos DSAs em junho de 2002 e agora fornecer para todos os DSAs lançados desde setembro de 1998 após a revisão iniciada em agosto de 2002. Todos os avisos podem ser recuperados do website do Debian e notícias relacionadas a novas vulnerabilidades incluindo nomes CVE se disponíveis na época de seu lançamento. Avisos associados com um dado nome CVE pode ser procurado diretamente através do <url id="http://search.debian.org/" name="search engine">.

<p>Usuários que querem procurar por um nome CVE em particular podem usar o sistema de busca disponível em debian.org para recuperar avisos disponíveis (em inglês e traduzidos para outros idiomas). Uma busca pode ser feita para um nome específico (como aviso <url
id="http://search.debian.org/?q=advisory+%22CAN-2002-0001%22&amp;ps=50&amp;o=1&amp;m=all"
name="CAN-2002-0001">) ou para nomes parciais (como todos os avisos de 2002 para <url
id="http://search.debian.org/?q=advisory+%22CAN-2002%22&amp;ps=50&amp;o=1&amp;m=all"
name="CAN-2002">). Observe que você precisa entrar com a palavra advisory junto com o nome CVE para recuperar apenas avisos de segurança.

<p>Em alguns casos você pode nãO encontrar um CVE em avisos publicados porque:

<list>
   <item> No Debian os produtos não são afetados pela vulnerabilidades.
   <item> Ainda não existe uma viso abordando a vulnerabilidade (ele pode ter sido informado para a <url
   id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security"
   name="security bug"> mas uma correção ainda não ter sido testada a atualizada)
   <item> Um aviso foi publicado antes que um CVE fosse assinado para a vulnerabilidade em questão (procure por uma atualização no web site)
</list>
</sect1>

</sect>

<sect>Infraestrutura da segurança Debian

<p>Uma vez que o Debian é normalmente suportado em um grande número de arquiteturas, administradores algumas ficam admirados se uma dada arquitetura levar mais tempo para receber atualizações de segurança. De fato, exceto em raras circunstâncias, atualizações estão disponíveis para todas as arquiteturas ao mesmo tempo.

<p>Enquanto antigamente a tarefa de construir atualizações de segurança era feita a mão, hoje não é mais (como Anthony Towns descreve em <url id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html" name="a mail">, enviado para a lista debian-devel-announce em 6 de junho de 2002.)

<p>Pacotes atualizados pelo time de segurança (para <url
id="security.debian.org:/org/security.debian.org/queue/unchecked"> ou
<url id="ftp://security.debian.org/pub/SecurityUploadQueue">) tem suas assinaturas checada com um patch adequado dentro de quinze minutos, uma vez isto feito eles são adicionados a lista de auto construtores. Então, os pacotes podem ser disponibilizados para <em>todas</em> as arquiteturas num tempo de trinta minutos a uma hora do momento em que foram atualizados. Porém, atualizações de segurança são um pouco diferentes da atualização normal envidada pelos mantenedores de pacotes, uma vez que, em alguns casos, antes de ser publicadas, elas precisam esperar até serem testadas, um aviso ser escrito ou, ainda, precisam esperar uma semana ou mais para evitar publicação da falhar até que todos os vendedores tenham chance de corrigí-la.   

<p>Assim, a atualização de segurança trabalha da seguinte maneira (chamada  <em>"Accepted-Autobuilding"</em>):

<list>

<item>Alguém encontra um problema de segurança.
     
<item>Alguém corrige o problema e atualiza 
      security.debian.org (este <em>alguém</em> normalmente é um membro do Time de Segurança mas pode ser também um mantenedor de pacote com uma correção apropriada que contactou o time de segurança previamente). O Changelog inclui uma indicação <em>testing-security</em> ou <em>stable-security</em>.

<item>Ocorre o upload checado e processado por um sistema Debian e movido para queue/accepted, e buildds são notificados. Arquivos aqui podem ser acessados pelo time de segurança e (indiretamente) pelos buildds.

<item>O Security-enable buildds pega o pacote fonte (que tem prioridade sobre os builds normais), o constrói, e envia logs para o time de segurança.

<item>O time de segurança reproduz os logs, e novos pacotes construídos são enviados para queue/unchecked, onde são processados pelo sistema Debian, e movidos para queue/accepted.

<item>Quando o time de segurança verifica que o pacote fonte está aceitável (isto é, ele foi corretamente construído para todas as arquiteturas, corrigiu os problemas de segurança e não introduziu novos problemas) eles rodam um script que:

<list>
<item>instala o pacote em um arquivo de segurança.

<item>atualiza os pacotes, fontes e release files de security.debian.org de uma maneira normal (<prgn>dpkg-scanpackages</prgn>,
<prgn>dpkg-scansources</prgn>...)

<item>configura um aviso modelo que o time de seguranaça pode encerrar os trabalhos.

<item>(opcionalmente) envia os pacotes para as atualizações adequadas e eles podem ser incluídos assim que for possível.

</list>

</list>

<p>Este procedimento, antes feito a mão, foi testado e usado completamente durante o estágio freeze do Debian 3.0 Woody (Julho de 2002). Graças a esta infraestrutura do Security Team foi possível ter pacotes atualizados prontos para o apache e OpenSSH para todas as arquiteturas suportadas (quase vinte) em menos de um dia.

<sect1>Guia dos desenvolvedores de atualizações de seguranaça

<p>Este email foi enviado por Wichert Akkerman para <url
id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00004.html"
name="Debian-devel-announce mailing list"> a fim de descrever o comportamento do desenvolvedor Debian para manipulação de problemas de segurança em seus pacotes. Ele está publicado aqui tanto para os desenvolvedores quanto os usuários entenderem melhor como a segurança é manipulada no Debian.

<p>Por favor observe que a última referência para esta informação é <url id="http://www.debian.org/doc/manuals/developers-reference/ch-pkgs#bug-security" name="Debian Developer's Reference">, esta seção será removida em futuro próximo.

<sect2>Coordenando com o time de segurança

<p>Se um desenvolvedor tem conhecimento de um problema de segurança, seja em seu pacote seja em outro, ele deve sempre contactar o time de segurança (através de team@security.debian.org). Eles mantém controle dos problemas de segurança, podem ajudar mantenedores, corrigir os problemas, são responsáveis por enviar os avisos e manter o security.debian.org.

<p>Observe que os avisos de segurança não são feitos apenas para releases, não apenas para testing, unstable (veja <ref id="sec-unstable">)
ou distribuições antigas (veja <ref id="sec-older">).

<sect2>Tomando conhecimento dos problemas de segurança

<p>Como um desenvolvedor toma conhecimento de um problema de segurança:

<list>
<item>ele observa em um fórum público (mailing list, website, etc.):
<item>alguém arquiva um bugreport (um tag <em>Security</em> deve ser usada, ou adicionada)
<item>alguém o informa via email.
</list>

<p>Nos dois primeiros casos a informação é pública e é importante ter uma correção o mais rápido possível. Em último caso porém ela pode não ser uma informação pública. Neste caso existem poucas opções para tratar o problema:

<list>

<item>Se é um problema trivial (como arquivos inseguros temporários) não há necessidade de manter o problema secreto e a correção deve ser feita e lançada.

<item>se o problema é grave (exploração remota, possibilitando adquirir privilégios de root) é preferível compartilhar a informação com outros vendedores e coordenar o lançamento. O time de segurança mantém contato com  várias organizações e indivíduos e é cuidadoso com isto.

</list>

<p>Em todos os casos, se a pessoa que reporta o problema pede para não divulgar a informação, deve ser respeitada, com execeção óbviade informar ao time de segurança (o desenvolvedor deve estar certo que ele disse ao time de segurança que a informação não deve ser divulgada).

<p>Por favor observe que se o segredo é necessário o desenvolvedor pode também não atualizar uma correção para a unstable (ou qualquer outra), uma vez que o chagelog para a unstable é uma informação pública.

<p>Existem duas razões para o lançamento da informação mesmo se o segredo é solicitado: o problema torna-se conhecido por muitos, ou a informação torna-se pública.

<sect2>Construindo um pacote

<p>A mais importante guideline quando fazendo um novo pacote que corrige um problema de segurança é mazer o mínimo de alterações necessário. As pessoas sabem exatamente o comportamento de um lançamento, assim qualquer alteração feita pode quebrar o sistema de alguém. Isto é especialmente verdade para bibliotecas: o desenvolvedor deve estar certo de nunca alterar a API ou a ABI, mesmo que seja uma pequena mudança.

<p>Isto significa que mudar para uma nova versão não é uma boa solução, em vez disto só as alterações relevantes devem ser feitas. Geralmente os mantenedores estão dispostos a ajudar que precisa, se não, o time de segurança da Debian pode.

<p>Em alguns casos não é possível fazer o backport de uma correção de segurança, por exemplo quando uma grande quantidade do código fonte precisa ser modificado ou reescrito. Se isto acontece pode ser necessário mover para uma nova versão, mas isto deve sempre ser coordenado com o time de segurança.

<p>Relacionado a isto existe outro importante aspecto: desenvolvedores devem sempre testar suas alterações. Se existe uma falha que permita exploração, o desenvolvedor deve testar e verificar se ela aconteceu em um pacote não corrigido ou em um pacote corrigido. O desenvolvedor deve tentar o uso normal também, algumas vezes uma correção de segurança pode quebrar o uso normal sutilmente.

<p>Finalmente algumas coisas que os desenvolvedores devem ter em mente:

<list>
<item>Esteja certo que você assinalou a distribuição correta em seu debian/changelog. Para a distrituição estável (stable) você deve assinalar como stable-security e para a distribuição em teste, testing-security. Não assinale &lt;codename&gt;-proposed-updates.

<item>Verifique o número da versão. Ele deve ser maior que o pacote atual, mas menor que versões do pacote em distribuições anteriores. Para a distribuição testing isto sigfinifica que deve haver uma versão maior na distribuição unstable. Se ainda não existe (testing e unstable tem a mesma versão por exemplo) atualize a nova versão para a unstable primeiro.

<item>Não faça atualizações source-only se seu pacote tem alguns pacotes binary-all. A infraestrutura de construção não construirá aqueles.

<item>Quando compilar um pacote faço isto em um sistema limpo, o qual tem só tem instalados pacotes da distribuição para a qual você está construindo. Se você não tem um sistema assim pode tentar a debian.org machine (veja http://db.debian.org/machines.cgi) ou configurar um chroot (os pacotes <package>pbuilder</package> e
  <package>debootstrap</package> podem ajudar neste caso).

</list>

<sect2>Realizando o uplaod com as correções de segurança

<p>Após o desenvolvedor ter criado e testado um novo pacote ele precisa realizar o upload pois assim a correçaõ será instalada nos archives. Por segurança os arquivos para upload devem ser colocados em 
ftp://security.debian.org/pub/SecurityUploadQueue/ .

<p>Uma vez que o upload foi aceito o pacote será automaticamente reconstruído para todas as arquiteturas e armazenado para verifiração pelo time de segurança.

<p>Uploads aguardando por aceitação e verificação só são acessíveis pelo time de segurança. Isto é necessãrio uma vez que podem ser correções para problemas de segurança que ainda não foram descobertos.

<p>SE um mebro do time de segurança aceita um pacote ele será instalado em  security.debian.org assim como o apropriado &lt;codename&gt;-proposed-updates
em ftp-master ou non-US archive.

<sect2>O aviso de segurança

<p>Os avisos de segurança são escritos e postados pelo time de segurança. Porém, eles certamente não pensam se um mantenedor pode fornecer o texto para eles (pelo menos uma parte). As informações que devem fazer parte de um aviso são descritas em <ref id="dsa">.

<sect id="deb-pack-sign">Assinatura de pacote no Debian

<p>Esta seção também pode ser chamada "como atualizar seu sistema Debian GNU/Linux em segurança" e mereçe sua própria seção basicamente porque é uma parte importante da infraestrutura de segurança. Assinatura de pacote é uma coisa importante porque evita alterações de pacotes distribuídos em mirros. Atualização automatica de software é um recurso importante mas também é importante remover ameaças de segurança que poderiam ajudar a distribuir cavalos de tróia e comprometer os sistemas durante as atualizações.
<footnote>
<p>Alguns sistemas operacionais já tiveram problemas com atualizações automáticas como 
<url name="Mac OS X Software Update vulnerabity"
id="http://www.cunap.com/~hardingr/projects/osx/exploit.html">.
<p>FIXME: probably the Internet Explorer vulnerability handling
certificate chains has an impact on security updates on Microsoft Windows.
</footnote>.


<p>Atualmente (maio de 2005) o Debian não fornece assinatura de pacotes para as distribuições lançadas <em>woody</em> ou <em>sarge</em> (3.0 ou 3.1). Elas não possuem este recurso. Existe uma solução para isto que será fornecida na próxima distribuição (codename <em>etch</em>). Este novo recurso estará disponível no apt 0.6 (atualmente disponível numa distribuição <em>experimental</em>, veja <ref id="apt-0.6">).

<p>Isto é melhor descrito em <url id="http://www.cryptnet.net/fdp/crypto/strong_distro.html" name="Strong
Distribution HOWTO"> por V. Alex Brennen.

<sect1>O esquema proposto para checagem de assinatura dos pacotes

<p>O esquema atual para checagem da assinatura dos pacotes usando  <prgn>apt</prgn> é:

<list>
<item>o arquivo lançado incluirá o md5sum do Packages.gz (que contém os md5sum dos pacotes) e será assinado. A assinatura é de uma fonte certificada.

<item>A arquivo assinado é baixado pelo 'apt-get update' a armazenado com o Packages.gz.

<item>Quando o pacote está sendo instalado, ele primeiro é baixado, então o md5sum é gerado.

<item>A assinatura é checada (assinatura ok) e extraído o md5sum do arquivo Pakages.gz, este por sua vez é gerado e (se ok) o md5sum do pacote baixado é extraído.

<item>Se o md5sum do pacote baixado é o mesmo que o do Packages.gz, o pacote será instalado. Caso contrário o administrador será alertado e o pacote será colocado num cache (e o administrador pode decidir se instalará o pacote ou não). Se o pacote não estiver no Packages.gz e o administrador tiver configurado o sistema para só instalar pacotes checados, o pacote não será instalado.
</list>

<p>A sequência seguinte de checagens MD5 do <prgn>apt</prgn> é capaz de verificar se o pacote origina de um release específico. Isto é menos flexível que a assinatura de cada pacote, mas pode ser combinada com este esquema também (veja abaixo).

<p>Atualmente, este esquema é <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg01986.html
" name="fully implemented"> no apt 0.6
par mais informações veja <ref id="apt-0.6">. Pacotes que fornecem um front-end para o apt precisam ser modificados para adaptar este novo recurso,
 isto é o caso do <prgn>aptitude</prgn> o qual tem feito
<url id="http://lists.debian.org/debian-devel/2005/03/msg02641.html"
name="modified"> para adaptar-se a este esquema.

<p>Assinatura de pacotes foi discutido no Debian por um bom tempo, para mais informações leia:
<url id="http://www.debian.org/News/weekly/2001/8/"> e
<url id="http://www.debian.org/News/weekly/2000/11/">.

<sect1 id="check-releases">Checando releases das distribuições

<p>Caso você queira adicionar os novos recursos de checagem de segurança e não queira rodar a versão experimental do apt (embora nõs realmente apreciemos
o teste dele) você pode usar o script abaixo, fornecido por Anthony Towns. Este script pode automaticamente fazer algumas novas checagens de segurança para permitir ao usuário certificar-se que o software que está baixando corresponde aquele distribuído pelo Debian. Isto é para desenvolvedores Debian usarem em sistemas sem a funcionalidade de uploading dos sistemas tradicionais, ou mirrors que tem quase tudo mas não como o Debian, ou mirrors que fornecem dados da versão unstable sem conhecimento dos problemas de segurança.

<p>Este código, renomeado como <prgn>apt-check-sigs</prgn>, deve ser usado da seguinte maneira:
<example>
# apt-get update
# apt-check-sigs
(...resultados...)
# apt-get dist-upgrade
</example>

<p>Primeiro você precisa:

<list>

<item>pagar as chaves para assinar os Release files, 
<url id="http://ftp-master.debian.org/ziyi_key_2003.asc"> e adicioná-las a <file>~/.gnupg/trustedkeys.gpg</file> (que
<prgn>gpgv</prgn> usa por padrão).
<example>
  gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2003.asc
</example>

<item>remover qualquer linha do <file>/etc/apt/sources.list</file> que não usa a estrutura normal de "dist", ou alterar o script para ele trabalhe com elas.

<item>estar preparado para ignorar o fato que o Debian security updates não assinou os Release files, e que os Sources files não tem os checksums apropriados no Release file (ainda).

<item>estar preparado para checar se as fontes estão assinadas com as chaves apropriadas.

</list>

<p>Este é o código de exemplo do <prgn>apt-check-sigs</prgn>, a última versão pode ser conseguida de <url
id="http://people.debian.org/~ajt/apt-check-sigs">.
Este código atualmente está em beta, para mais informações leia 
<url id="http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html">.

<example>
#!/bin/bash

# Copyright (c) 2001 Anthony Towns &lt;ajt@debian.org&gt;
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

rm -rf /tmp/apt-release-check
mkdir /tmp/apt-release-check || exit 1
cd /tmp/apt-release-check

>OK
>MISSING
>NOCHECK
>BAD

arch=`dpkg --print-installation-architecture`

am_root () {
        [ `id -u` -eq 0 ]
}

get_md5sumsize () {
        cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | 
          MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { 
print "$f[1] $f[2]\n"; exit(0); }'
}

checkit () {
        local FILE="$1"
        local LOOKUP="$2"

        Y="`get_md5sumsize Release "$LOOKUP"`"
        Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
                        # No file, but not needed anyway
                        echo "OK"
                        return
                fi
                echo "$FILE" >>MISSING
                echo "MISSING $Y"
                return
        fi
        if [ "$Y" = "" ]; then
                echo "$FILE" >>NOCHECK
                echo "NOCHECK"
                return
        fi
        X="`md5sum < /var/lib/apt/lists/$FILE | cut -d\  -f1` `wc -c < /var/lib
/apt/lists/$FILE`"
        X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "BAD"
                return
        fi
        echo "$FILE" >>OK
        echo "OK"
}

echo
echo "Checking sources in /etc/apt/sources.list:"
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
echo
(echo "You should take care to ensure that the distributions you're downloading
"
echo "are the ones you think you are downloading, and that they are as up to"
echo "date as you would expect (testing and unstable should be no more than"
echo "two or three days out of date, stable-updates no more than a few weeks"
echo "or a month)."
) | fmt
echo

cat /etc/apt/sources.list | 
  sed 's/^ *//' | grep '^[^#]' |
  while read ty url dist comps; do
        if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then
                baseurl="${url#*://}"
        else
                continue
        fi

        echo "Source: ${ty} ${url} ${dist} ${comps}"

        rm -f Release Release.gpg
        lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1
        wget -q -O Release "${url}/dists/${dist}/Release"

        if ! grep -q '^' Release; then
                echo "  * NO TOP-LEVEL Release FILE"
                >Release
        else
                origline=`sed -n 's/^Origin: *//p' Release | head -1`
                lablline=`sed -n 's/^Label: *//p' Release | head -1`
                suitline=`sed -n 's/^Suite: *//p' Release | head -1`
                codeline=`sed -n 's/^Codename: *//p' Release | head -1`
                dateline=`grep "^Date:" Release | head -1`
                dscrline=`grep "^Description:" Release | head -1`
                echo "  o Origin: $origline/$lablline"
                echo "  o Suite: $suitline/$codeline"
                echo "  o $dateline"
                echo "  o $dscrline"

                if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then
                        echo "  * WARNING: asked for $dist, got $suitline/$codeline"
                fi

                lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1
                wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"

                gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do
                        if [ "$gpgcode" = "GOODSIG" ]; then
                            if [ "$err" != "" ]; then
                                echo "  * Signed by ${err# } key: ${rest#* }"
                            else
                                echo "  o Signed by: ${rest#* }"
                                okay=1
                            fi
                            err=""
                        elif [ "$gpgcode" = "BADSIG" ]; then
                            echo "  * BAD SIGNATURE BY: ${rest#* }"
                            err=""
                        elif [ "$gpgcode" = "ERRSIG" ]; then
                            echo "  * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}"
                            err=""
                        elif [ "$gpgcode" = "SIGREVOKED" ]; then
                            err="$err REVOKED"
                        elif [ "$gpgcode" = "SIGEXPIRED" ]; then
                            err="$err EXPIRED"
                        fi
                    done
                    if [ "$okay" != 1 ]; then
                        echo "  * NO VALID SIGNATURE"
                        >Release
                    fi)
        fi
        okaycomps=""
        for comp in $comps; do
                if [ "$ty" = "deb" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * PROBLEMS WITH $comp ($X, $Y)"
                        fi
                elif [ "$ty" = "deb-src" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * PROBLEMS WITH component $comp ($X, $Y)"
                        fi
                fi
        done
        [ "$okaycomps" = "" ] || echo "  o Okay:$okaycomps"
        echo
  done

echo "Results"
echo "~~~~~~~"
echo

allokay=true

cd /tmp/apt-release-check
diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED

cd /tmp/apt-release-check
if grep -q ^ UNVALIDATED; then
    allokay=false
    (echo "The following files in /var/lib/apt/lists have not been validated."
    echo "This could turn out to be a harmless indication that this script"
    echo "is buggy or out of date, or it could let trojaned packages get onto"
    echo "your system."
    ) | fmt
    echo
    sed 's/^/    /' < UNVALIDATED
    echo
fi

if grep -q ^ BAD; then
    allokay=false
    (echo "The contents of the following files in /var/lib/apt/lists does not"
    echo "match what was expected. This may mean these sources are out of date,"
    echo "that the archive is having problems, or that someone is actively"
    echo "using your mirror to distribute trojans."
    if am_root; then 
        echo "The files have been renamed to have the extension .FAILED and"
        echo "will be ignored by apt."
        cat BAD | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' < BAD
    echo
fi

if grep -q ^ MISSING; then
    allokay=false
    (echo "The following files from /var/lib/apt/lists were missing. This"
    echo "may cause you to miss out on updates to some vulnerable packages."
    ) | fmt
    echo
    sed 's/^/    /' < MISSING
    echo
fi

if grep -q ^ NOCHECK; then
    allokay=false
    (echo "The contents of the following files in /var/lib/apt/lists could not"
    echo "be validated due to the lack of a signed Release file, or the lack"
    echo "of an appropriate entry in a signed Release file. This probably"
    echo "means that the maintainers of these sources are slack, but may mean"
    echo "these sources are being actively used to distribute trojans."
    if am_root; then 
        echo "The files have been renamed to have the extension .FAILED and"
        echo "will be ignored by apt."
        cat NOCHECK | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' < NOCHECK
    echo
fi

if $allokay; then
    echo 'Everything seems okay!'
    echo
fi

rm -rf /tmp/apt-release-check
</example>

<p>Você pode precisar aplicar o seguinte patch para <em>sid</em> uma vez que
<prgn>md5sum</prgn> adiciona um '-' após o sum quando a entrada é stdin:

<example>
@@ -37,7 +37,7 @@
        local LOOKUP="$2"

        Y="`get_md5sumsize Release "$LOOKUP"`"
-       Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"
+       Y="`echo "$Y" | sed 's/-//;s/^ *//;s/  */ /g'`"

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
@@ -55,7 +55,7 @@
                return
        fi
        X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`"
-       X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
+       X="`echo "$X" | sed 's/-//;s/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "BAD"
</example>
<sect1>Esquema alternativo de assinatura per-package

<p>The additional scheme of signing each and every packages allows
packages to be checked when they are no longer referenced by an
existing Packages file, and also third-party packages where no
Packages ever existed for them can be also used in Debian but will not
be default scheme.

<p>Este esquema de assinatura pode ser implementado usando
<package>debsig-verify</package> e <package>debsigs</package>.
Estes dois pacotes podem assinar e verificar assinaturas embutidas em pacotes .deb. Debian já tem a capacidade de fazer sito, mas a implementação de policiamento e ferramentas não será iniciada até as releases posteriores ao woody.

<p>As últimas versões do dpkg (a partir de 1.9.21) incorporam um 
<url
id="http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200103/msg00024.html"
name="patch"> que fornece esta funcionalidade tão logo
<package>debsig-verify</package> seja instalado.

<p>NOTA: Atualmente <file>/etc/dpkg/dpkg.cfg</file> trabalha com
"no-debsig" como padrão.

<p>NOTA 2: Signatures from developers are currently stripped when they
enter off the package archive since the currently preferred method is
release checks as described previously.

<sect1 id="apt-0.6">Pacotes experimentais apt

<p>O release do apt 0.6 inclui <em>apt-secure</em> que é uma ferramenta que permitirá a um administrador de sistema testar a integridade dos pacotes baixados através do esquema acima. Esta release inclui a ferramenta  <prgn>apt-key</prgn> para adicionar novas chaves ao chaveiro do apt, o qual por padrão inclui apenas o arquivo de assinatura de chaves atual do Debian.

<p>Se quer testar este recurso você precisa adicionar a distribuição experimental ao seu <file>sources.list</file> e rodar

<example>
# apt-get -t experimental install apt
</example>

<p>Estas alterações são baseadas no patch para <prgn>apt</prgn> (disponível em <url
id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203741" name="Bug
#203741">) o qual fornece esta implementação.  

<p>Este recurso ainda está em desenvolvimento, se você acredita que pode encontrar bugs nele por favor tenha certeza que está usando a última versão e, se estiver rodando a última versão, envie o bug para o pacote 
<package>apt</package> package usando a tag <em>experimental</em>.

<P>Observe que, usar esta versão experimental do apt não exige nada mais de sua parte a menos que você não use sources Debian, neste caso um passo extra de confirmação será requerido pelo apt-get. Isto é evitado fornecendo Release e Release.gpg em non-Debian sources. O arquivo Release pode ser gerado com
<prgn>apt-ftparchive</prgn> (disponível em apt-utils 0.5.0 e posteriores), 
o Release.gpg é apenas uma assinatura destacada. 
Para gerar ambos siga este simples procedimento:

<example>
$ rm -f dists/unstable/Release
$ apt-ftparchive release dists/unstable > dists/unstable/Release
$ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release
</example>
