On 3/29/06, Felipe Augusto van de Wiel (faw) <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/29/2006 03:19 PM, Augusto Cezar Amaral da C Silva wrote: > > eduardo tião wrote: > >>>Atualização do FAQ. > > > > Segue diff da revisão. > > > > - Correção do número de revisão > > - Correção de pontuação > > - Sugestões de tradução > > - Substituição de alguns termos utilizados
[...] > Eu apóio as modificações que você fez e recomendo que o > Eduardo adote-as. Inclusive as correções de localização. Eduardo, > você poderia aplicar o patch e reenviar o faq.wml para revisão? > Assim podemos proceder para o DONE rapidamente. :) > > Mas há um detalhe importante, vamos ter que fazer outros > ajustes na tradução, a última questão em inglês é: > > <toc-add-entry name=break>What to do if a random package breaks after a > security update?</toc-add-entry> > <p>A: First of all, you should figure out why the package breaks and > how it is connected to the security update, then contact the > security team if it is serious or the stable release manager if it > is less serious. We're talking about random packages that break > after a security update of a different package. If you can't > figure out what's going wrong but have a correction, talk to the > security team as well. You may be redirected to the stable release > manager though.</p> > > > Fala-se de Stable Release Manager e não de Stable Release > Maintainer, ou seja, é preciso fazer uma revisão mais ampla, não > só da última adição mas do FAQ como um todo, Eduardo e Augusto, > acham que podem encarar essa? :-) Além de incorporar as mudanças aceitas, fiz o seguinte: - "equipe" -> "time" (uma ocorrência, só pra padronizar :P) - sugestão de tradução - erros de digitação Abraços. -- Augusto Cezar Amaral da C Silva
#use wml::debian::template title="FAQ de Segurança Debian" #use wml::debian::translation-check translation="1.52" #include "$(ENGLISHDIR)/security/faq.inc" <p>Nós recebemos as seguintes perguntas freqüentemente, 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 do time de segurança sejam postadas.</p> <p>Provavelmente, seu software de e-mail está 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 o Debian lida com a segurança?</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 (ou seja, se ela é 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 uma versão antiga de determinado 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 uma versão, uma vez que ela é lançada, então qualquer mudança que fazemos tem o potencial de quebrar o sistema de alguém. Isso é verdade especialmente no caso de bibliotecas: certifique-se de nunca modificar as Application Program Interfaces (APIs) ou Application Binary Interfaces (ABIs), 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 uma grande 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=localremote>O que significa "local (remote)"?</toc-add-entry> <p>R:Alguns alertas tratam de vulnerabilidades que não podem ser identificadas usando o esquema clássico de explorações locais ou remotas. Algumas vulnerabilidades não podem ser exploradas remotamente, ou seja, não correspondem a um <em>daemon</em> associado a uma porta de rede. Nos casos em que é possível explorá-las através de arquivos especiais que possam estar disponíveis via rede enquanto o serviço vulnerável não se encontra conectado permanentemente com a rede, nós utilizamos "local (remote)". <p>Essas vulnerabilidades estão entre as vulnerabilidades locais e as remotas, e muitas vezes dizem respeito a arquivos que poderiam ser disponibilizados através rede, como um anexo de correio eletrônico ou por uma página de download.</p> <toc-add-entry name=version>O número de versão de um pacote indica que eu ainda estou executando 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 distribuição estável. A razão para que façamos isto é certificar-nos de que uma distribuição mude o mínimo possível, de forma que nada quebre ou mude inesperadamente, como conseqüência de uma correção de segurança. Você pode checar se está executando uma versão segura de um pacote verificando o seu registro de mudanças, 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 distribuição <tt>"testing"</tt> e na <tt>"unstable"</tt>?</toc-add-entry> <p>R: A resposta curta é: não é feita. As distribuições "testing" (em teste) e "unstable" (instável) estão em constante alteração e o Time de Segurança não possui os recursos necessários para suportá-las devidamente. Se quer ter um servidor seguro (e estável), nós recomendamos fortemente que continue com a distribuição "stable" (estável). Entretanto, há um esforço em andamento 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 da distribuição "testing" e, em certo nível, da 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ídos para todas as arquiteturas e que suas dependências possam 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á espelhos 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 espelhos não-oficiais poderá causar uma complexidade extra desnecessária e a frustração de encontrar um desses espelhos desatualizados. Espelhos 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 [EMAIL PROTECTED] ou [EMAIL PROTECTED], 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 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 [EMAIL PROTECTED] 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ência 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 por um período de tempo maior do que o estritamente necessário.</p> <p>Por favor use os pacotes dos últimos alertas 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 executar <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 em 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 [EMAIL PROTECTED] Eles serão revisados pelo Time de Segurança e eventualmente enviados ao 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 lidar 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, a 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 na "stable" e menor do que a versão na "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 foi modificada 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 arquivos 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 [EMAIL PROTECTED]</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 [EMAIL PROTECTED] 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 Distribuiçã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_2006.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 a integridade dos pacotes podem ser encontradas 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 aleatório quebra após uma atualização de segurança?</toc-add-entry> <p>R: Antes de mais nada, você deve descobrir por que 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 gerente da distribuição estável se for menos sério. Nós estamos falando de pacotes aleatórios 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. É possível que você seja redirecionado ao gerente da distribuição estável.</p>
