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.
\nVersão curta: por favor reporte problemas de segurança enviando email para security@djangoproject.com.
\nA 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.
\nPor outro lado, se você acredita que você encontrou algo no Django que tenha implicações de segurança, por favor envie uma descrição do problema via email para security@djangoproject.com. O email enviado para este endereço chega até o 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.
\n\nA qualquer momento, o time Django fornece suporte de segurança oficial para várias versões do Django:
\nA 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.
\nNosso processo para levar um problema de segurança de discussões privadas para divulgação pública envolve alguns passos.
\nAproximadamente uma semana antes da divulgação pública, nós enviamos duas notificações:
\nPrimeiro, 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:
\nAlta:
\nExecução de código remoto
Proteção contra SQL injection
Moderada:
\nCross Site Scripting (XSS)
Cross site request forgery (CSRF)
Ataques negação de serviço
Quebra na autenticação
Baixa:
\nExposiçã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
Segundo, nós notificamos uma lista de pessoas e organizações, primariamente compostas por fornecedores de sistemas operacionais e outros distribuidores do Django. Esse e-mail é assinado com uma chave PGP de alguém do time de edições do Django e consiste de:
\nUma 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:
\nAplicar os patch(es) relevantes para a base de código do Django.
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.
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).
Poste uma notícia nas listas de email django-announce e oss-security@lists.openwall.com 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.
\nAdicionalmente, 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.
\nO time Django também mantém um arquivo de problemas de segurança divulgados no Django.
\nA 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.
\nWe also aim to keep this list as small as effectively possible, in\norder to better manage the flow of confidential information prior to\ndisclosure. As such, our notification list is not simply a list of\nusers of Django, and being a user of Django is not sufficient reason\nto be placed on the notification list.
\nEm linhas gerais, recipientes de notificações de segurança caem dentro de três grupos:
\nFornecedores 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.
De tempos em tempos, mantenedores de pacotes individuais que tenham demonstrado um compromisso em atender e agido de forma responsável nessas notificações.
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.
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 security@djangoproject.com. Por favor use “Security notification request” no assunto.
O seu pedido deve incluir a informação a seguir:
\nO 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 ter 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.
\nPor 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.
\n\n