Política de Segurança do Django

O time de desenvolvimento do Django é fortemente comprometido em reportar e divulgar problemas de segurança. Como tal, nós adotamos e seguimos um conjunto de políticas que se adequam a esse ideal e são voltados a nos permitir entregar atualizações de segurança pontuais para as distribuições oficiais do Django, assim como para distribuições de terceiros.

Reportando problemas de segurança

Versão curta: por favor reporte problemas de segurança enviando email para [e-mail].

A maioria dos bugs normais no Django são reportados na `nossa instância publica do Trac `_, mas devido a natureza sensível dos problemas de segurança, nós pedimos que eles não sejam publicamente reportados desta maneira.

Instead, if you believe you’ve found something in Django which has security implications, please send a description of the issue via email to [e-mail]. Mail sent to that address reaches the security team.

Uma vez que você tenha submetido via email, você deve receber um recebido de um membro do time de segurança dentro de 48 horas, e dependendo da ação a ser tomada, você poderá receber mais emails de retorno.

Enviando relatórios encriptados

Se você quiser enviar um email criptografado (optional), o ID da chave pública para [e-mail] é 0xfcb84b8d1d17f80b, e essa chave pública está disponível nos keyservers mais comuns.

Versões suportadas

A qualquer momento, o time Django fornece suporte de segurança oficial para várias versões do Django:

• A branch de desenvolvimento master, hospedado no Github, que deve se tornar a próxima versão do Django, recebe suporte de segurança. Problemas de segurança que apenas afeta a branch master, mas não afeta as versões estáveis são resolvidos em público sem passar por processo de divulgação.
• As duas séries de releases mais recentes do Django recebem suporte de segurança. Por exemplo, durante o ciclo de desenvolvimento que culminou com a release do Django 1.5, suporte será provido para o Django 1.4 en Django 1.3. Com a release do Django 1.5, o suporte de segurança do Django 1.3 será encerrado.
• Long-term support releases irão receber atualizações de segurança por um período de tempo especificado.

Quando novas releases são lançadas por questões de segurança, a notícia que a acompanha irá incluir uma lista de versões afetadas. Essa lista é composta somente de versões suportadas pelo Django: versões antigas também podem ser afetadas, mas nós não investigamos para determinar isso, e nós não lançamos patches ou novas releases para essas versões.

Como o Django divulga problemas de segurança

Nosso processo para levar um problema de segurança de discussões privadas para divulgação pública envolve alguns passos.

Aproximadamente uma semana antes da divulgação pública, nós enviamos duas notificações:

Primeiro, nós notificamos o django-announce da data e hora aproximada do lançamento da próxima versão de segurança, bem como a gravidade do problema. Isso ajuda as organizações que precisam disso para garantir que tem pessoal disponível para lidar com a triagem do anúncio e atualizar Djagno se necessário. Os níveis de severidade são:

Grave:

• Execução de código remoto
• Proteção contra SQL injection

Moderada:

• Proteção contra Cross Site Scripting (XSS)
• Proteção contra Cross site request forgery (CSRF)
• Denial-of-service attacks
• Quebra na autenticação de usuário

Baixa:

• Exposição de dados sensíveis
• Quebra no gerenciamento de sesssões
• Redirecionamento/Encaminhamento não validados
• Problemas que pedem uma opção de configuração incomum

Second, we notify a list of people and organizations, primarily composed of operating-system vendors and other distributors of Django. This email is signed with the PGP key of someone from Django’s release team and consists of:

• Uma descrição completa do problema e das versões afetadas do Django.
• Os passos que serão tomados para remediar o problema.
• O patch (ou os patches), se existirem, que irá ser aplicado no Django.
• A data em que o time Django irá aplicar essas patches, lançando novas releases e publicamente divulgando o problema.

No dia da divulgação, nós tomaremos as seguintes providências:

1. Aplicar os patch(es) relevantes para a base de código do Django.
2. Lançar as releases (ou a release) relevantes, colocando novos pacotes no Python Package Index e no website do Django, criando tags das novas releases (ou da release) no repositório git do Django.
3. Postar uma entrada pública no blog oficial de desenvolvimento do Django, descrevendo o problema e a sua resolução em detalhe, apontando para os patches relevantes e novas releases, e creditando a pessoa que reportou o problema (se essa pessoa que o reportou quiser ser identificada publicamente).
4. Poste uma notícia nas listas de email django-announce e [e-mail] que tenha links para o post no blog.

Se acredita-se que o problema reportado é particularmente sensível ao tempo – devido a uma conhecida vulnerabilidade de segurança em aberto, por exemplo – o tempo entre a notificação prévia e a divulgação pública pode ser encurtada consideravelmente.

Adicionalmente, se nós tivermos razões para acreditar que o problema reportado para nós afeta outras frameworks e ferramentas no ecossistema Python/web, nós podemos contatar privadamente e discutir esses problemas com os mantenedores apropriados, e coordenar nossa própria divulgação e resolução com eles.

O time Django também mantém um arquivo de problemas de segurança divulgados no Django.

Quem recebe notificação prévia

A lista completa de pessoas e organizações que recebem uma notificação prévia de problemas de segurança não é e não será tornada pública.

Nós também focamos em manter essa lista o quão pequena quanto for efetivamente possível, para gerenciar melhor o fluxo de informação confidencial que precede a divulgação. Como tal, nossa lista de notificação não é simplesmente uma lista de usuários do Django, e meramente ser um usário do Django não é razão suficiente para ser colocado na lista de notificação.

Em linhas gerais, recipientes de notificações de segurança caem dentro de três grupos:

1. Fornecedores de sistemas operacionais e outras distribuições do Django que fornecem um endereço de email genérico para reportar problemas (ex. não são emails pessoais de indivíduos) para reportar problemas com o Django, ou para reportar problemas gerais de segurança. Em qualquer caso, tais endereços não devem redirecionar para listas de email públicas ou rastreadores de bugs. Endereços que encaminham para o email individual de um mantenedor ou contato para respostas de segurança são aceitas, embora rastreadores de segurança privados ou grupos de resposta a segurança são fortemente preferidos.
2. De tempos em tempos, mantenedores de pacotes individuais que tenham demonstrado um compromisso em atender e agido de forma responsável nessas notificações.
3. De tempos em tempos, outras entidades que, no julgamento do time de desenvolvimento do Django, precisem estar cientes do problema de segurança pendente. Tipicamente, membros do grupo irão consistir de alguns dos maiores usuários e distribuidores do Django e dos mais provavelmente impactados severamente com o problema, e irão requerer uma abilidade demonstrada para responder prontamente, manter confidencial e agir nessas notificações.

Requisitando notificações

Se você acredita que você, ou a organização que você está autorizado a representar, cai em um dos grupos listados acima, você pode pedir para ser adicionado a lista de notificações do Django enviando um email para [e-mail]. Por favor use “Security notification request” no assunto.

O seu pedido deve incluir a informação a seguir:

• O seu nome completo, real e o nome da organização que você representa. Se aplicável, assim como o seu perfil dentro da organização.
• Uma explicação detalhada de como você ou sua organização se encaixam pelo menos em um dos grupos listados acima.
• Uma explicação detalhada do porque você está solicitando notificações de segurança. Novamente, tenha em mente de que esta não é simplesmente uma lista para usuários do Django, e a esmagadora maioria dos usuários devem se inscrever em django-announce para receber aviso prévio de quando uma release de segurança irá lançar, sem os detalhes dos problemas, em vez de pedir notificações detalhadas.
• O endereço de email que você gostaria de fosse adicionado em nossa lista de notificação.
• Uma explicação de quem irá estar recebendo/revisando os emails enviados para esse email, asim como as informações referentes a qualquer ação automatizada que será realizada (ex. preencher um registro de problema confidencial em um bug tracker).
• Para indivíduos, o ID ou a chave pública associada com o seu endereço que pode ser usado para verificar o seu email recebido de você e email encriptado enviado para você, quando necessário.

Uma vez submetido, a sua solicitação será considerada pelo time de desenvolvimento do Django; você irá receber uma resposta notificando você do resultado da sua solicitação dentro de 30 dias.

Por favor tambén tenha em mente que para qualquer indivíduo ou organização, receber notificações de segurança é um privilégio dado somente ao critério do time de desenvolvimento do Django, e que esse privilégio pode ser revogado a qualquer momento, com o sem explicação.