[RFR] wml://webwml/portuguese/security/faq.wml
--
Augusto Cezar Amaral <augusto.cezar@gmail.com>
#use wml::debian::template title="FAQ de Segurança Debian"
#use wml::debian::translation-check translation="1.49"
#include "$(ENGLISHDIR)/security/faq.inc"
<p>Nós recebemos as seguintes perguntas frequentemente, então suas respostas
estão resumidas aqui.</p>
<maketoc>
<toc-add-entry name=signature>Não consegui verificar corretamente a assinatura em seus
alertas!</toc-add-entry>
<p>R: Provavelmente você está fazendo algo errado. A lista
<a href="http://lists.debian.org/debian-security-announce/">\
debian-security-announce</a> possui um filtro que só permite que mensagens
com a assinatura correta de um dos membros da equipe de segurança sejam
postadas.</p>
<p>É possível que seu software de e-mail esteja alterando sutilmente
a mensagem, o que invalida a assinatura.
Certifique-se de que seu programa não faça codificação ou decodificação
MIME, assim como conversões de tabulação/espaços.</p>
<p>Alguns softwares que fazem isso são o fetchmail (com a opção mimedecode
habilitada), o formail (do procmail versão 3.14) e o evolution.</p>
<toc-add-entry name=handling>Como é a feita a segurança no Debian?</toc-add-entry>
<p>R: Assim que o Time de Segurança recebe uma notificação sobre um
incidente, um ou mais membros revisam e avaliam seu impacto sobre
a versão estável do Debian (ex. se esta é vulnerável ou não). Se nosso
sistema é vulnerável, nós trabalhamos em uma correção para o problema.
O mantenedor do pacote é contatado também, se ele já não contatou
o Time de Segurança. Finalmente, a correção é testada e novos pacotes
são preparados, compilados em todas as arquiteturas da versão estável e
é feito o envio dos mesmos. Depois de tudo isso, um alerta é publicado.
</p>
<toc-add-entry name=oldversion>Por que vocês insistem em versões antigas
daquele pacote?</toc-add-entry>
<p>R: A regra mais importante quando está se fazendo um novo pacote que corrige
problemas de segurança é fazer o menor número possível de alterações. Nossos usuários e
desenvolvedores estão confiando no comportamento correto de um release uma
vez que é feito, então qualquer mudança que fazemos pode possivelmente
quebrar o sistema de alguém. Isso é verdade especialmente no caso de
bibliotecas: tenha certeza que você nunca modifique as
Application Program Interface (API) ou Application Binary Interface (ABI),
não importa quão pequena seja essa alteração.</p>
<p>Isso significa que mudar para a nova versão do autor não é uma boa
solução, em vez disso, as alterações relevantes devem ser adaptadas à versão
antiga. Geralmente os autores dessas novas versões se dispõem a ajudar se for
preciso, se não o Time de Segurança do Debian pode estar disponível para
ajudar.</p>
<p>Em alguns casos não é possível adaptar a versão antiga a uma correção de
segurança, por exemplo quando muita quantidade de código fonte precisa ser
modificada ou reescrita. Se isto acontecer pode ser necessário mudar para a
nova versão do autor, mas isso deve ser coordenado antecipadamente com o
Time de Segurança.</p>
<toc-add-entry name=policy>Qual é a política usada para que pacotes corrigidos
apareçam no security.debian.org?</toc-add-entry>
<p>R: Erros de segurança na distribuição estável garantem a aparição
de um pacote no security.debian.org. Nada mais. O tamanho
do erro não é o problema real aqui. Normalmente, o Time de Segurança
irá preparar pacotes juntamente com o mantenedor do pacote. Desde que
alguém (confiável) investigue o problema e construa os pacotes necessários
e os envie ao Time de Segurança, mesmo problemas de segurança triviais
irão entrar no security.debian.org. Por favor, veja abaixo.</p>
<p>Atualizações de segurança têm um único propósito: fornecer uma correção para
uma vulnerabilidade relacionada à segurança. Elas não são um método para enviar
mudanças adicionais à versão estável sem realizar o procedimento de lançamento normal.</p>
<toc-add-entry name=version>O número de versão de um pacote indica que eu ainda
estou rodando uma versão vulnerável!</toc-add-entry>
<p>R: Ao invés de atualizar para uma versão nova nós adaptamos correções
de segurança das versões mais novas para a versão lançada com a release
estável. A razão para que façamos isto é certificar-nos de que uma release mude o
mínimo possível e que as coisas não mudarão ou quebrarão inesperadamente
como consequência de uma correção de segurança. Você pode checar se
está executando uma versão segura de um pacote verificando o seu changelog
ou comparando o número exato da versão com a versão indicada
no Alerta de Segurança Debian.</p>
<toc-add-entry name=testing>Como a segurança é feita na <tt>testing</tt> e na
<tt>unstable</tt>?</toc-add-entry>
<p>R: A resposta curta é: não é feita. Testing e unstable estão em
constante alteração e o Time de Segurança não possui os recursos
necessários para checá-las devidamente. Se quer ter um servidor seguro e
estável, nós recomendamos fortemente que continue com a versão
estável. Entretanto, há um esforço sendo feito para mudar isso com a formação do
<a href="http://secure-testing-master.debian.net/">time de segurança para a testing</a>,
que já começou a trabalhar para oferecer suporte à segurança para a distribuição
testing e, em certo nível, para a distribuição unstable.</p>
<toc-add-entry name=testing-security>Como a distribuição <tt>testing</tt>
recebe atualizações de segurança?</toc-add-entry>
<p>R: Atualizações de segurança irão migrar para a distribuição
<tt>testing</tt> através da <tt>unstable</tt>. Elas geralmente são
feitas com alta prioridade, reduzindo o tempo de quarentena para dois
dias. Após este período, os pacotes irão migrar para a
<tt>testing</tt> automaticamente, supondo-se que tenham sido construídas
para todas as arquiteturas e suas dependências puderem ser satisfeitas
na <tt>testing</tt>.</p>
<p>O <a href="http://secure-testing-master.debian.net/">time de segurança
para a testing</a> também disponibiliza correções de segurança em seu repositório
quando o processo normal de migração não é rápido o suficiente.</p>
<toc-add-entry name=contrib>Como a segurança é feita para o <tt>contrib</tt> e <tt>non-free</tt>?</toc-add-entry>
<p>A: A resposta curta é: não é feita. Contrib e non-free não
fazem parte oficialmente da Distribuição Debian e não são lançadas, por
isso não são suportadas pelo Time de Segurança. Alguns pacotes non-free
são distribuídos sem o código fonte ou com uma licença que não permite a
distribuição de versões modificadas. Nesses casos, nenhuma correção de
segurança pode ser feita. Se for possível corrigir o problema, e o
mantenedor do pacote ou alguma outra pessoa fornecer pacotes corrigidos,
o Time de Segurança geralmente irá processá-los e publicar um alerta.</p>
<toc-add-entry name=mirror>Por que não há mirrors oficiais de security.debian.org?</toc-add-entry>
<p>R: O propósito de security.debian.org é tornar atualizações de
segurança disponíveis da maneira mais rápida e fácil possível.</p>
<p>Encorajar o uso de mirrors não-oficiais poderá causar uma complexidade
extra desnecessária e a frustração de encontrar um desses mirrors
desatualizados. Mirrors oficiais de security.debian.org estão sendo
planejados para o futuro.</p>
<toc-add-entry name=missing>Vi o DSA 100 e o DSA 102, agora, onde está o DSA 101?</toc-add-entry>
<p>R: Vários distribuidores (a maioria deles de GNU/Linux, mas também
de variações do BSD) coordenam alertas de segurança para alguns
incidentes e concordam com uma determinada linha de tempo para
que todos os distribuidores possam lançar um aviso ao mesmo tempo.
Isso foi decidido para que não haja discriminação com alguns distribuidores que
precisam de mais tempo (por exemplo, quando o distribuidor tem de
passar os pacotes por longos testes de controle de qualidade
ou suporta diversas arquiteturas ou distribuições binárias).
Nosso Time de Segurança também prepara avisos com antecedência.
Dependendo da situação, outros problemas de segurança têm de ser
trabalhados antes do aviso "estacionado" ser lançado, e isso
causa a lacuna na numeração dos avisos.
<toc-add-entry name=contact>Como posso entrar em contato com o Time de Segurança?</toc-add-entry>
<p>R: Informações de segurança podem ser enviadas para security@debian.org ou
team@security.debian.org, ambos são lidos pelos membros do Time de
Segurança.
<p>Caso deseje, a mensagem pode ser criptografada com a chave do
Contato de Segurança Debian (o ID da chave é <a
href="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&exact=on&search=0x363CCD95">\
0x363CCD95</a>). Procure também pelas <a href="keys.txt">\
chaves PGP/GPG do Time de Segurança</a>.</p>
<toc-add-entry name=discover>Eu acho que encontrei um problema de segurança, o que devo fazer?</toc-add-entry>
<p>R: Se você descobrir um problema de segurança, tanto em um dos seus pacotes
ou de outro desenvolvedor, por favor, entre em contato com o Time de Segurança.
Se o Time de Segurança do Debian confirmar a vulnerabilidade e outros
distribuidores também estiverem vulneráveis, eles geralmente contatam estes
outros distribuidores. Se a vulnerabilidade ainda não é pública eles tentam
coordenar os alertas de segurança com os dos outros distribuidores para que
todas as principais distribuições fiquem sincronizadas.</p>
<p>Se a vulnerabilidade for já tiver sido divulgada publicamente, certifique-se
de preencher um relatório de bug no Debian BTS e marcá-lo como "security".</p>
<p>Se você é um mantenedor Debian, <a href="#care">veja abaixo</a>.</p>
<toc-add-entry name=care>O que eu devo fazer com um problema de segurança
em um dos meus pacotes?</toc-add-entry>
<p>R: Se você souber de algum problema de segurança, seja no seu pacote ou
no de outra pessoa, por favor, não deixe de entrar em contato com o Time de
Segurança. Você pode se comunicar com eles através do e-mail
team@security.debian.org. Eles mantém um relatório do andamento dos
problemas de segurança, podem ajudar mantenedores com problemas de segurança
ou até mesmo consertar eles mesmos estes problemas, são responsáveis por mandar
os alertas de segurança e mantém o security.debian.org.</p>
<p>O documento <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Developer's Reference (Referências para Desenvolvedores)</a> tem instruções
completas do que fazer.</p>
<p>É particularmente importante que você não faça o upload para nenhuma outra
distribuição além da unstable sem antes conversar com o Time de
Segurança, pois isso pode causar confusão e mais trabalho.</p>
<toc-add-entry name=enofile>Eu tentei baixar um pacote listado em um dos alertas de segurança,
mas recebo um erro do tipo 'arquivo não encontrado'.</toc-add-entry>
<p>R: Quando algum pacote que leva uma correção de bug substitui um pacote
antigo em security.debian.org, as chances de que o antigo seja removido
assim que o outro entrar são altas. Portanto, você irá
receber o erro 'arquivo não encontrado'. Nós não queremos distribuir
pacotes com erros de segurança conhecidos a não ser que seja absolutamente necessário.</p>
<p>Por favor use os pacotes dos últimos avisos de segurança, que
são distribuídos através da lista de discussão <a
href="http://lists.debian.org/debian-security-announce/">\
debian-security-announce</a>. É melhor simplesmente rodar
<code>apt-get update</code> antes de atualizar o pacote.</p>
<toc-add-entry name=upload>Eu tenho uma correção de bug. Posso enviar para
security.debian.org diretamente?</toc-add-entry>
<p>R: Não, você não pode. O repositório na security.debian.org é mantido
pelo Time de Segurança, que deve aprovar todos os pacotes. Em vez disso
você pode enviar patches ou pacotes fonte apropriados para o Time de Segurança
pelo e-mail team@security.debian.org. Eles serão revisados pelo Time de Segurança
e eventualmente enviados para o repositório, com ou sem modificações.</p>
<p>Se você não está acostumado com uploads de segurança e não tem
100% de certeza que seu pacote está correto, por favor use esta
maneira e não envie para o diretório incoming. O Time de Segurança
não tem muitas opções para tratar com pacotes quebrados, especialmente
se eles não usam uma versão correta. Os pacotes atualmente não podem
ser rejeitados e o <abbr title="Build Daemon - Daemon de construção">\
buildd</abbr> poderia ficar confuso se isto fosse
possível. Então, por favor use o e-mail e ajude evitando colocar mais
peso para o Time de Segurança.</p>
<p>O manual <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Developer's Reference (Referências para Desenvolvedores)</a> tem instruções
completas do que fazer.</p>
<toc-add-entry name=ppu>Eu tenho uma correção de bug. Posso enviar para o
"proposed-updates" diretamente?</toc-add-entry>
<p>A: Tecnicamente falando, você pode. No entanto, você não deve fazê-lo,
uma vez que isso interfere no trabalho do Time de Segurança.
Pacotes do security.debian.org serão copiados para o diretório
proposed-updates automaticamente. Se um pacote com o mesmo número
de versão ou com um número mais alto já se encontra no arquivo, a atualização
de segurança será rejeitada pelo sistema de arquivamento. Dessa forma, a distribuição
estável ficará sem uma atualização de segurança para este pacote, ao menos
que o pacote "errado" do diretório proposed-updates seja rejeitado.
Por favor, em vez disso, contate o Time de Segurança, inclua todos os detalhes da
vulnerabilidade e anexe os arquivos fontes (por exemplo, diff.gz e arquivos
dsc) em seu e-mail.</p>
<p>O manual <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Developer's Reference (Referências para Desenvolvedores)</a> tem instruções completas do que fazer.</p>
<toc-add-entry name=SecurityUploadQueue>Eu tenho certeza que meus pacotes estão corretos,
como posso enviá-los?</toc-add-entry>
<p>R: Se você tem absoluta certeza que seus pacotes não irão quebrar alguma coisa, que
a versão está correta (exemplo maior do que a versão no estável e menor do que
a versão no testing/unstable), que você não alterou o comportamento do pacote,
apesar do problema de segurança correspondente, que você compilou ele para a
distribuição correta (que é a <code>oldstable-security</code> ou
<code>stable-security</code>), que contém o código fonte original se o pacote
for novo no security.debian.org, que você pode confirmar que o patch da versão
mais recente é claro e somente modificado a parte relacionada com o problema de
segurança correspondente (verifique com <code>interdiff -z</code> e ambos
arquivos <code>.diff.gz</code>), que você tenha revisado o patch pelo menos
três vezes, e que o <code>debdiff</code> não tenha mostrado nenhuma mudança, você
pode enviar diretamente os arquivo para o diretório incoming
<code>ftp://security-master.debian.org/pub/SecurityUploadQueue</code> em
security.debian.org. Por favor, envie também uma notificação com todos
os detalhes e links para o e-mail team@security.debian.org.</p>
<toc-add-entry name=help>Como posso ajudar com a segurança?</toc-add-entry>
<p>R: Por favor, reveja cada problema antes de informá-lo ao
security@debian.org. Se você for capaz de fornecer patches,
isto aumentaria a velocidade do processo. Não encaminhe
e-mails do bugtraq, simplesmente, porque nós já os recebemos
— mas nos forneça informações adicionais sobre
o que foi relatado no bugtraq.</p>
<toc-add-entry name=proposed-updates>Qual é o escopo do proposed-updates?</toc-add-entry>
<p>R: Este diretório contém pacotes que são sugeridos para entrar
na próxima versão estável do Debian. Sempre que pacotes são enviados
por um mantenedor para a distribuição estável, eles acabam no
diretório proposed-updates. Já que a estável é feita para ser estável,
atualizações automáticas não são realizadas. O Time de Segurança irá
enviar pacotes corrigidos mencionados em alertas para a estável,
no entanto, eles serão colocados no proposed-updates antes. A cada dois meses,
o Gerente da Versão Estável confere a lista de pacotes
do proposed-updates e discute se um pacote serve ou não para a estável.
Então, os escolhidos são compilados em uma nova versão da estável
(e.x. 2.2r3 ou 2.2r4). Pacotes que não se encaixam na versão estável
provavelmente serão rejeitados e também descartados do proposed-updates.
<p>Note que pacotes com uploads feitos pelos mantenedores (não pelo time
de segurança) no diretório proposed-updates/ não são suportados pelo time
de segurança.</p>
<toc-add-entry name=composing>Como o Time de Segurança é composto?</toc-add-entry>
<p>R: O Time de Segurança do Debian consiste em
<a href="../intro/organization">alguns oficiais e secretários</a>.
O próprio Time de Segurança designa pessoas para se juntar ao grupo.</p>
<toc-add-entry name=lifespan>Por quanto tempo as atualizações de segurança são fornecidas?</toc-add-entry>
<p>R: O time de segurança tenta dar suporte à distribuição estável por mais
ou menos um ano depois que uma próxima distribuição estável é lançada, exceto
quando uma outra distribuição estável é lançada neste período. É impossível
dar suporte a três distribuições; dar suporte a duas simultaneamente já é
difícil o bastante.
<toc-add-entry name=check>Como verifico a integridade de um pacote?</toc-add-entry>
<p>R: É preciso verificar a assinatura do arquivo Release com a
<a href="http://ftp-master.debian.org/ziyi_key_2005.asc">\
chave pública</a> usada para armazenamento. O arquivo Release
contém os checksums MD5 dos arquivos Packages e Sources, que contêm os
checksums dos pacotes binários e fontes. Mais informações de como
verificar integridade dos pacotes pode ser encontrada no <a
href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
Manual de Segurança do Debian</a>.</p>
<toc-add-entry name=break>O que fazer quando um pacote ao acaso quebra após
uma atualização de segurança?</toc-add-entry>
<p>R: Antes de mais nada, você deve descobrir porque o pacote quebrou e como
isto está conectado à atualização de segurança, então contate o time de
segurança se isto for sério ou o mantendor do release estável se for menos
sério. Nós estamos falando de pacotes ao acaso que quebram após uma
atualização de segurança de um pacote diferente. Se você não pode descobrir
o que deu errado mas tem uma correção, fale com o time de segurança também.
Você pode ser redirecionado ao mantenedor do release estável.</p>
Reply to: