This process is subject to change. Please refer to this page for the current VRP.

This page was last updated April 2023.

Researchers: during your study and network testing, we ask that you refrain from the following: - Performing active exploits or Denial of Service attacks on the I2P network - Performing social engineering on I2P team and community members - Performing any physical or electronic attempts against I2P property and/or data centers

As I2P is an open-source community, many volunteers and development team members run their own I2P Sites as well as public (“non-private internet”) domains. These sites/servers are NOT in the scope of the vulnerability assessment / response process, only the underlying code of I2P is.

I. Point of Contact for Security Issues

II. Security Response Team

Echelon is the trusted security point-of-contact. He forwards emails to team members as appropriate.

III. Incident Response

1. Researcher submits report via: security (at) geti2p.net
2. Response Team designates a Response Manager who is in charge of the particular report based on availability and/or knowledge-set.
3. In no more than 3 working days, Response Team should respond to researcher using only encrypted methods.
4. Response Manager makes inquiries to satisfy any needed information and to confirm if submission is indeed a vulnerability.
   1. If submission proves to be vulnerable, proceed.
   2. Se não vulnerável:
      1. Response Manager responds with reasons why submission is not a vulnerability.
      2. Response Manager moves discussion to a new or existing ticket on public Trac if necessary.
5. Establish severity of vulnerability:

   HIGH

   Affects network as a whole, has potential to break entire network or is on a scale of great catastrophe.

   MEDIUM

   Affects individual routers, or must be carefully exploited.

   LOW

   Is not easily exploitable.

6. Respond according to the severity of the vulnerability:
   1. HIGH severities must be notified on website and news feed within 3 working days of classification.
      1. The notification should list appropriate steps for users to take, if any.
      2. The notification must not include any details that could suggest an exploitation path.
      3. The latter takes precedence over the former.
   2. MEDIUM and HIGH severities will require a Point Release.
   3. LOW severities will be addressed in the next Regular Release.
7. Response Team applies appropriate patch(es).
   1. Response Manager works on a patch LOCALLY, patches are shared by the response team via PGP-encrypted e-mail until such a time as it is safe to expose to the public.
   2. Patches are reviewed with the researcher.
   3. Any messages associated with PUBLIC commits during the time of review should not make reference to the security nature of the PRIVATE branch or its commits.
   4. Vulnerability announcement is drafted.
      1. Include severity of vulnerability.
      2. Include systems/apps effected.
      3. Include solutions (if any) if patch cannot be applied.
   5. A data de lançamento é discutida.
8. Na data de lançamento, a Equipe de Resposta coordena com os desenvolvedores para finalizar a atualização:
   1. O Gerenciador de Resposta propaga a "ramificação do hotfix" para o tronco.
   2. O Gerenciador de Resposta inclui rascunho de anúncio de vulnerabilidade nas notas de versão.
   3. Proceed with the Point or Regular Release. At this time, it is not possible to release an in-network update for only one operating system or architecture. In order that all affected products can be released as quickly as possible, the person responsible for that software should be able to perform necessary release processes in a timely manner. Importantly this should include consideration for package maintainers in Debian, Ubuntu and F-Droid.

IV. Processo de Divulgação Pós-lançamento

1. Response Team has 90 days to fulfill all points within section III.
2. Se o processo de Resposta a Incidentes na seção III for concluído com êxito:
   1. O Response Manager entra em contato com o pesquisador e pergunta se o pesquisador deseja crédito.
   2. Finalize o rascunho do anúncio de vulnerabilidade e inclua o seguinte:
      1. Nome do projeto e URL.
      2. Versões conhecidas por serem afetadas.
      3. Versões conhecidas por não serem afetadas (por exemplo, o código vulnerável foi introduzido em uma versão recente e, portanto, as versões mais antigas não são afetadas).
      4. Versões não verificadas.
      5. Tipo de vulnerabilidade e seu impacto.
      6. Se já obtido ou aplicável, um CVE-ID.
      7. A data de lançamento é planejada e coordenada.
      8. Fatores atenuantes (por exemplo, a vulnerabilidade só é exposta em configurações incomuns e não padrão).
      9. Soluções alternativas (alterações de configuração que os usuários podem fazer para reduzir sua exposição à vulnerabilidade).
      10. Se for o caso, créditos ao repórter original.
   3. Lançamento de anúncio de vulnerabilidade finalizado no site e no feed de notícias.
   4. 1. If the vulnerability may be exploited while the network is being upgraded, delay the announcement until the vulnerable routers are upgraded.
      2. After the update is successful, write the announcement for the news feed, send it for translation, and release it.
      3. When translations come in, news operators should pull in the translations and update their feeds.
   5. Para severidades ALTAS, libere o anúncio de vulnerabilidade finalizado em listas de discussão conhecidas:
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
   6. Se aplicável, os desenvolvedores solicitam um CVE-ID.
      1. A confirmação que aplicou a correção também é feita referência em uma confirmação futura e inclui uma CVE-ID.
3. Se o processo de Resposta a Incidentes na seção III *não* for concluído com êxito:
   1. A equipe de resposta e os desenvolvedores organizam uma reunião de IRC para discutir por que/quais pontos na seção III não foram resolvidos e como a equipe pode resolvê-los no futuro.
   2. Any developer meetings immediately following the incident should include points made in section V.
   3. If disputes arise about whether or when to disclose information about a vulnerability, the Response Team will publicly discuss the issue via IRC and attempt to reach consensus.
   4. If consensus on a timely disclosure is not met (no later than 90 days), the researcher (after 90 days) has every right to expose the vulnerability to the public.

V. Análise de Incidentes

1. Isolar a base de código
   1. A equipe de resposta e os desenvolvedores devem se coordenar para trabalhar no seguinte:
      1. Implementação problemática de classes/bibliotecas/funções, etc.
      2. Concentre-se em empacotamento de aplicativos/distro, etc.
      3. Erro de operador/configuração, etc.
2. Auditoria
   1. A equipe de resposta e os desenvolvedores devem se coordenar para trabalhar no seguinte:
      1. Auditoria da(s) área(s) problemática(s), tal como referido no ponto 1.
      2. Gere relatórios internos e armazene para referência futura.
      3. Se os resultados não forem sensíveis, partilhe com o público através de IRC ou Trac público.
3. Response Team has 45 days following completion of section III to ensure completion of section V.

VI. Resoluções

Quaisquer outras perguntas ou resoluções sobre o(s) incidente(s) entre o pesquisador e a equipe de resposta + desenvolvimento após adivulgação pública podem serabordadas através do seguinte:

1. Trac
2. IRC
3. Email
4. Twitter

VII. Aperfeiçoamento Contínuo

1. A equipe de resposta e os desenvolvedores devem realizar reuniões anuais para revisar os incidentes do ano anterior.
2. A Equipe de Resposta ou a(s) pessoa(s) designada(s) deve(m) fazer uma breve apresentação, incluindo:
   1. Áreas da I2P afetadas pelos incidentes.
   2. Qualquer tempo de inatividade da rede ou custo monetário (se houver) dos incidentes.
   3. Maneiras pelas quais os incidentes poderiam ter sido evitados (se houver).
   4. Como esse processo foi eficaz para lidar com os incidentes.
3. Após a apresentação, a Equipe de Resposta e os desenvolvedores devem discutir:
   1. Possíveis mudanças nos processos de desenvolvimento para reduzir incidentes futuros.
   2. Possíveis mudanças nesse processo para melhorar as respostas futuras.