From c549b0597f3842619cfd8b8fb02df34b032ec883 Mon Sep 17 00:00:00 2001 From: Jose Suarez Date: Fri, 27 Jul 2018 15:00:59 -0400 Subject: [PATCH] Update Spanish i18n - Bump spanish i18n to the latest version - delete some redundant files to match with english folder - fix little typo - Fix wording in acknowledgements - fix developer guides typos --- i18n/es/acknowledgements.md | 15 +- i18n/es/contributing.md | 152 ------------ i18n/es/developer_guide.md | 450 ++++++++++++++++++------------------ i18n/es/faq.md | 163 +++++++++---- i18n/es/index.md | 10 +- i18n/es/quality.md | 55 ----- i18n/es/style.md | 68 ------ i18n/es/testnet_guide.md | 66 ++++++ i18n/es/user_guide.md | 138 ++++++++--- 9 files changed, 525 insertions(+), 592 deletions(-) delete mode 100644 i18n/es/contributing.md delete mode 100644 i18n/es/quality.md delete mode 100644 i18n/es/style.md create mode 100644 i18n/es/testnet_guide.md diff --git a/i18n/es/acknowledgements.md b/i18n/es/acknowledgements.md index a3e4d9e..015800c 100644 --- a/i18n/es/acknowledgements.md +++ b/i18n/es/acknowledgements.md @@ -1,8 +1,9 @@ -En adición a los contribuidores de Boost y OpenSSL, y a todos los programadores desde los tiempos inmemoriales, que han hecho este proyecto posible, queremos reconocer lo siguiente: +## Reconocimientos +Adicional a los contribuyentes de Boost y OpenSSL, y a todos los programadores desde los tiempos inmemoriales, que han hecho este proyecto posible, queremos reconocer lo siguiente: -- Wei Dai, Jeffrey Walton, y todos los desarrolladores en Cryoto++ por proveer una influencial y libre librería de criptografía en C++ -- Dean Michael Berris, Glyn Matthews, y todos los desarrolladores en cpp-netlib por proveer una librería activamente desarrollada cross-plataforma de red. -- zzz, str4d, y todos los desarrolladores de I2P Java, en ambos, pasado y presente, que tienen un set de estándares a seguir para las demás implementaciones de I2P -- orion por proveer ```i2pcpp```: la implementación en C++ [original](http://git.repo.i2p.xyz/w/i2pcpp.git) de I2P -- orignal por proveer ```i2pd```: la mas completa implementación de I2P [de la cual poder copiar](https://github.com/purplei2p/i2pd/commit/45d27f8ddc43e220a9eea42de41cb67d5627a7d3) -- EinMByte por mejorar todas las implementaciones en C++ de I2P (Incluyendo Kovri) +- A Wei Dai, Jeffrey Walton y a todos los desarrolladores de Crypto++ por entregarnos una libreria criptográfica de C++ libre de gran influencia (o, "con una gran influencia"). +- A Dean Michael Berri, Glyn Matthews y a todos los desarrolladoes en cpp-netlib por proporcionar una librería de redes multiplataforma activa +- A zzz, str4d y a todos los desarrolladores de Java, que en el presente y en el pasado, establecieron el estándar de todas las otras implementaciones a seguir para I2P +- A orion por proveer ```i2pcpp:```: la implementación en C++ [original](http://git.repo.i2p.xyz/w/i2pcpp.git) de I2P +- A orignal por proveer ```i2pd:``` la mas completa implementación de I2P [de la cual poder copiar](https://github.com/purplei2p/i2pd/commit/45d27f8ddc43e220a9eea42de41cb67d5627a7d3) +- A EinMByte por mejorar todas las implementaciones en C++ de I2P (Incluyendo Kovri) diff --git a/i18n/es/contributing.md b/i18n/es/contributing.md deleted file mode 100644 index 9552895..0000000 --- a/i18n/es/contributing.md +++ /dev/null @@ -1,152 +0,0 @@ -## Seguros de calidad -- Mira nuestros [Seguros de calidad](https://github.com/monero-project/kovri-docs/blob/master/i18n/es/quality.md) para tener una idea de nuestro flujo de trabajo - -## Conformidad -- Nosotros apuntamos a usar las conformidades de C++11/14; siéntete libre de usar esto para mejorar tu trabajo -- También es altamente recomendable usar las librerías y dependencias estándar cuando sea posible - -## Enviando tú trabajo -Para contribuir tu trabajo, por favor procede con lo siguiente: - -1. Forkea Kovri -2. Lee nuestra [guía de estilo](https://github.com/monero-project/kovri-docs/blob/master/i18n/es/style.md) -3. Crea una [branch](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) para trabajar -4. [**Firma**](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) tu(s) commit(s) -5. envía tu pull-request a la branch ```master``` - - Actualmente no tenemos ningún tag por estar en Alpha. Por ahora, puedes basar tu trabajo desde la rama master. - - Los mensajes del Commit deben ser verbose por default, considerando una línea de asunto de (50 caracteres máximo), una línea en blanco y una explicación detallada como párrafo(s) separado(s) - a menos que el titulo se auto-explique. - - El título de commit debe preponer class u otro aspecto del proyecto. Por ejemplo, "HTTPProxy: implementado depurador de User-Agent. Arregla #193." o "Garlic: arregla padding no inicializado en ElGamalBlock". - - Si un commit en particular referencia otro issue, por favor agrega una referencia. Por ejemplo, "Leer #123", o "Arregla #123". Esto ayudara a resolver tickets cuando se mezclen con ```master```. - - En general, los commits deben ser [atomicos](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) y los diffs deben ser fáciles de leer. Por esta razón, por favor intenta no mezclar arreglos de formato con commits de sin formato. - - El cuerpo de los pull requests deben contener una descripción adecuada de lo que hace el parche, y proveer una justificación o razonamiento para el parche (cuando sea apropiado). Debes incluir referencias a cualquier discusión como tickets, chats, o IRC. - -## Propuestas -Para contribuir una propuesta, por favor lee nuestros [issues abiertos](https://github.com/monero-project/kovri/issues) para ver los ya existentes. Si lo que quieres proponer no está ahí, entonces [abre un nuevo issue](https://github.com/monero-project/kovri/issues/new). - -A pesa r de que nuestro C4 dicta, que nosotros mezclamos todo, pedimos abrir una propuesta por las siguientes razones: - -1. Una propuesta abre la comunicación -2. Una propuesta muestra que el colaborador respeta la opinión de todos los colaboradores del proyecto -3. Una propuesta permite a los colaboradores opinar en un foro abierto -4. Una propuesta ahorra tiempo si un colaborador ya está trabajando en algo similar -5. Una propuesta previene catástrofes, y errores, o permite a los colaboradores prepararse para catástrofes, o errores - -*No* abrir una nueva propuesta *no* va a prevenirte de colaborar; nosotros mezclaremos tu PR - pero una propuesta es altamente recomendada. - -## TODO -- Haz una búsqueda rápida en el código base por ```TODO(sin asignar):``` y/o elige un ticket y ¡comienza a trabajar! -- Si creas un TODO, asígnatelo a ti mismo o escribe ```TODO(sin asignar):``` - -# [Código de conducta (22/C4.1)](http://rfc.zeromq.org/spec:22) - -## Licencia - -Copyright (c) 2009-2015 Pieter Hintjens. - -This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. - -This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - -You should have received a copy of the GNU General Public License along with this program; if not, see . - -## Lenguaje - -Las palabras "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", y "OPTIONAL" en este documento, no deben ser interpretadas como esta descrito en el RFC 2119. - -## Metas - -C4 está hecho para ser un modelo óptimo de colaboración para proyectos de software de código abierto. Y se especifican los siguientes objetivos: - -- Maximizar la escala y la diversidad de la comunidad en torno a un proyecto, reduciendo la fricción para los nuevos colaboradores y creando un modelo de participación escalado con fuertes retroalimentaciones positivas; -- Para aliviar las dependencias de individuos clave, separando diferentes conjuntos de habilidades para que haya un mayor grupo de competencia en cualquier dominio requerido; -- Permitir que el proyecto se desarrolle de forma más rápida y precisa, aumentando la diversidad del proceso de toma de decisiones; -- Apoyar el ciclo de vida natural de las versiones del proyecto, desde el experimental hasta el estable, permitiendo la experimentación segura, el fracaso rápido y el aislamiento del código estable; -- Reducir la complejidad interna de los repositorios de proyectos, facilitando así la participación de los contribuyentes y reduciendo el margen de error; -- Reforzar la propiedad colectiva del proyecto, lo que aumenta el incentivo económico a los contribuyentes y reduce el riesgo de secuestro por entidades hostiles. - -## Diseño - -### Preliminares -- El proyecto DEBE utilizar el sistema de control de revisión distribuido git. -- El proyecto ESTARÁ alojado en github.com o equivalente, llamado "Plataforma". -- El proyecto DEBE utilizar la plataforma de Tracker de issues. -- El proyecto DEBE tener directrices claramente documentadas para el estilo de código. -- Un "Colaborador" es una persona que desea proporcionar un parche, siendo un conjunto de compromisos que resuelven algún problema claramente identificado. -- Un "Mantenedor" es una persona que fusiona parches al proyecto. Los mantenedores no son desarrolladores; Su trabajo es hacer cumplir el proceso. -- Los colaboradores NO tendrán acceso de commit al repositorio a menos que sean también Mantenedores. -- Los mantenedores DEBEN tener acceso de commit al repositorio. -- Todos, sin distinción ni discriminación, tendrán el mismo derecho de convertirse en un Colaborador en los términos de este contrato. - -### Licencia y propiedad - -- El proyecto DEBE utilizar una licencia compartida, como la GPLv3 o una variante de la misma (LGPL, AGPL), o la MPLv2. -- Todas las contribuciones al código fuente del proyecto ("parches") DEBERÁ utilizar la misma licencia que el proyecto. -- Todos los parches son propiedad de sus autores. No habrá ningún proceso de asignación de derechos de autor. -- Los derechos de autor del proyecto serán de propiedad colectiva de todos sus colaboradores. -- Cada Contribuyente DEBERÁ ser responsable de identificarse en la lista de Colaboradores del proyecto. - -### Requisitos del parche - -- Mantenedores y contribuyentes DEBEN tener una cuenta de la plataforma y DEBERÍAN utilizar sus nombres verdaderos o un alias conocido. -- Un parche DEBE ser una respuesta mínima y precisa a exactamente un problema identificado y acordado. -- Un parche DEBE adherirse a las directrices de estilo de código del proyecto si se definen. -- Un parche DEBE adherirse a la "Evolución de los contratos públicos" directrices definidas a continuación. -- Un parche NO incluirá código no trivial de otros proyectos a menos que el Colaborador sea el autor original de ese código. -- Un parche DEBE compilar de forma limpia y pasar las auto pruebas del proyecto en al menos la plataforma objetivo principal. -- Un mensaje de commit de parche DEBERÍA consistir en una sola línea corta (menos de 50 caracteres) que resume el cambio, seguido opcionalmente por una línea en blanco y luego una descripción más completa. -- Un "Patch Correcto" es aquel que satisface los requisitos anteriores. - -### Proceso de desarrollo - -- El cambio en el proyecto deberá ser gobernado por el patrón de identificar con precisión los issues y aplicar soluciones mínimas y precisas a estos issues. -- Para solicitar cambios, un usuario DEBE registrar un issue en el Tracker de issues de plataforma del proyecto. -- El usuario o el colaborador DEBE escribir el issue describiendo el issue que enfrentan u observan. -- El usuario o colaborador DEBE buscar un consenso sobre la exactitud de su observación, y el valor de resolver el issue. -- Los usuarios NO deben registrar solicitudes de información, ideas, sugerencias o soluciones a issues que no estén explícitamente documentados y probables. -- Así, el historial de lanzamiento del proyecto SERÁ una lista de asuntos significativos registrados y resueltos. -- Para trabajar en un issue, un colaborador DEBE hacer un fork del repositorio del proyecto y luego trabajar en su repositorio forkeado. -- Para enviar un parche, un colaborador DEBERÁ crear un pull request al proyecto. -- Un colaborador NO DEBE hacer commits directamente al proyecto. -- Si la Plataforma implementa pull request directo a issues, un Contribuyente PUEDE enviar directamente un pull request sin registrar un issue separado. -- Para discutir un parche, la gente PUEDE comentar en el pull request, en el commit, o en cualquier otro lugar. -- Para aceptar o rechazar un parche, un mantenedor DEBE utilizar la interfaz de la plataforma. -- Los mantenedores NO DEBEN fusionar sus propios parches excepto en casos excepcionales, como la falta de respuesta de otros Mantenedores durante un período prolongado (más de 1-2 días). -- Los mantenedores NO HARÁN juicios de valoración sobre los parches correctos. -- Los mantenedores deben fusionar los parches correctos de otros Colaboradores rápidamente. -- El colaborador PUEDE marcar un issue como "Listo" después de realizar un pull request del issue. -- El usuario que creó un issue DEBE cerrar el issue después de comprobar el parche es un éxito. -- Los mantenedores DEBEN pedir mejoras a los parches incorrectos y DEBEN rechazar los parches incorrectos si el Colaborador no responde de manera constructiva. -- Cualquier Contribuyente que tenga juicios de valoración en un parche correcto DEBERÍA expresarlos a través de sus propios parches. -- Los mantenedores PUEDEN realizar cambios en la documentación que no sea de origen directamente al proyecto. - -### Creación de versiones estables - -- El proyecto DEBE tener una rama ("master") que siempre tiene la última versión en curso y siempre debe compilar. -- El proyecto NO UTILIZARÁ ramas temáticas por ningún motivo. Los fork personales PUEDEN utilizar ramas temáticas. -- Para hacer una liberación estable, alguien FORK el repositorio copiándolo y así convertirse en mantenedor de este repositorio. -- El fork de un proyecto para estabilización PUEDE hacerse unilateralmente y sin el acuerdo de los mantenedores del proyecto. -- Un proyecto de estabilización DEBE ser mantenido por el mismo proceso que el proyecto principal. -- Un parche de un proyecto de estabilización declarado "estable" deberá ir acompañado de un caso de prueba reproducible. - -### Evolución de los contratos públicos - -- Todos los contratos públicos (APIs o protocolos) DEBEN ser documentados. -- Todos los contratos públicos DEBEN tener espacio para la extensibilidad y la experimentación. -- Un parche que modifica un contrato público estable NO DEBE romper las aplicaciones existentes a menos que haya un consenso sobre el valor de hacer esto. -- Un parche que introduce las nuevas características de un contrato público DEBE hacerlo utilizando nuevos nombres. -- Los nombres antiguos DEBEN ser obsoletos de una manera sistemática marcando nuevos nombres como "experimentales" hasta que sean estables, después marcando los viejos nombres como "inutilizados". -- Cuando haya pasado el tiempo suficiente, los viejos nombres obsoletos DEBERÍAN ser marcados como "heredados" y eventualmente eliminados. -- Los nombres antiguos NO SERAN reutilizados por las nuevas funciones. -- Cuando se quitan los nombres antiguos, sus implementaciones DEBEN provocar una excepción (aserción) si son utilizadas por las aplicaciones. - -### Administración del proyecto - -- Los fundadores del proyecto DEBERÁ actuar como Administradores para administrar el conjunto de los Mantenedores del Proyecto. -- Los Administradores DEBEN asegurar su propia sucesión a cierto tiempo promoviendo a los Mantenedores más efectivos. -- Un nuevo colaborador que hace un parche correcto se invitará a convertirse en un mantenedor. -- Los Administradores PUEDEN quitar a los Mantenedores que permanezcan inactivos por un periodo de tiempo prolongado, o que repetidamente no apliquen este proceso con exactitud. -- Los administradores DEBEN bloquear o prohibir a los "malos actores" que causan estrés y dolor a los demás en el proyecto. Esto debe hacerse después de una discusión pública, con la posibilidad de que todas las partes hablen. Un mal actor es alguien que ignora repetidamente las reglas y la cultura del proyecto, que es innecesariamente argumentativo u hostil, o que es ofensivo, y que es incapaz de auto-corregir su comportamiento cuando se le pide que lo haga por otros. - -# Proceso de gobernanza - -![Proceso de gobernanza](https://getmonero.org/blog/assets/2015-year-in-review/governance-process.jpg) diff --git a/i18n/es/developer_guide.md b/i18n/es/developer_guide.md index c493724..cea3140 100644 --- a/i18n/es/developer_guide.md +++ b/i18n/es/developer_guide.md @@ -1,90 +1,90 @@ -# Guidelines -- We aim for complete C++11/14 compliance; please use this to your advantage -- Please use the standard library and dependency libraries whenever possible - -## Vulnerability Response -- Our [Vulnerability Response Process](https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md) encourages responsible disclosure -- We are also available via [HackerOne](https://hackerone.com/monero) - -## Style -1. Read [Google's C++ Style Guide](https://google.github.io/styleguide/cppguide.html) (particularly for non-formatting style reference) - - If bash programming, read [Google's Shell Style Guide](https://github.com/google/styleguide/blob/gh-pages/shell.xml) -2. For files containing only new work, run [clang-format](http://clang.llvm.org/docs/ClangFormat.html) with ```-style=file``` (which uses our provided [.clang-format](https://github.com/monero-project/kovri/blob/master/.clang-format)) +# Pautas +- Nuestro objetivo es el cumplimiento completo de C++ 11/14; por favor use esto para su ventaja +- Utilice la biblioteca estándar y las bibliotecas de dependencia siempre que sea posible + +## Respuesta de vulnerabilidad +- Nuestro [Proceso de Respuesta de Vulnerabilidad](https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md) fomenta la divulgación responsable +- También estamos disponibles a través de [HackerOne](https://hackerone.com/monero) + +## Estilo +1. Lea [Guía de estilo de C ++ de Google](https://google.github.io/styleguide/cppguide.html) (particularmente para referencia de estilo sin formato) + - Si se trata de programación bash, lea [Guía de estilo de shell de Google](https://github.com/google/styleguide/blob/gh-pages/shell.xml) +2. Para los archivos que solo contengan trabajo nuevo, ejecute [clang-format](http://clang.llvm.org/docs/ClangFormat.html) con ```-style = file``` (que usa nuestro [.clang-format](https://github.com/monero-project/kovri/blob/master/.clang-format) proporcionado) ```bash -$ cd kovri/ && clang-format -i -style=file src/path/to/my/file +$ cd kovri / && clang-format -i -style=file /ruta/a/mi/archivo ``` -3. For files with mixed (existing + new) work, run [clang-format](http://clang.llvm.org/docs/ClangFormat.html) selectively over only lines directly related to the new work. - - See [vim](http://clang.llvm.org/docs/ClangFormat.html#vim-integration) and [emacs](http://clang.llvm.org/docs/ClangFormat.html#emacs-integration) documentation for examples of configuring keybindings for `clang-format` plugins. -4. Run [cpplint](https://github.com/google/styleguide/tree/gh-pages/cpplint) (which uses our provided [CPPLINT.cfg](https://github.com/monero-project/kovri/blob/master/CPPLINT.cfg)) to catch any issues that were missed by clang-format +3. Para archivos con trabajo mixto (existente + nuevo), ejecute [clang-format](http://clang.llvm.org/docs/ClangFormat.html) selectivamente solo sobre las líneas directamente relacionadas con el nuevo trabajo. + - Ver la documentacion de [vim](http://clang.llvm.org/docs/ClangFormat.html#vim-integration) y [emacs](http://clang.llvm.org/docs/ClangFormat.html#emacs-integration ) para ejemplos de configuración de combinaciones de teclas para complementos `clang-format`. +4. Ejecute [cpplint](https://github.com/google/styleguide/tree/gh-pages/cpplint) (que utiliza nuestro [CPPLINT.cfg](https://github.com/monero-project/kovri/blob/master/CPPLINT.cfg)) para detectar cualquier problema que se haya perdido por el formato clang ```bash -$ cd kovri/ && cpplint src/path/to/my/file && [edit file manually to apply fixes] +$ cd kovri / && cpplint src/ruta/a/mi/archivo && [edita el archivo manualmente para aplicar los cambios] ``` ### Plugins -- Vim integration +- Integrcion con VIM - [clang-format](http://clang.llvm.org/docs/ClangFormat.html#vim-integration) - - [clang-format ubuntu 16.04 vim workaround](http://stackoverflow.com/questions/39490082/clang-format-not-working-under-gvim) + - [clang-format ubuntu 16.04 vim](http://stackoverflow.com/questions/39490082/clang-format-not-working-under-gvim) - [cpplint.vim](https://github.com/vim-syntastic/syntastic/blob/master/syntax_checkers/cpp/cpplint.vim) -- Emacs integration +- Integracion a Emacs - [clang-format](http://clang.llvm.org/docs/ClangFormat.html#emacs-integration) + [clang-format.el](https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/clang-format.el) - [flycheck-google-cpplint.el](https://github.com/flycheck/flycheck-google-cpplint) -### Amendments to Google's proposed C++ style +### Enmiendas al estilo de C ++ propuesto por Google -- Avoid prepended mixed-case ```k``` and MACRO_TYPE for all constants -- Use Doxygen three-slash ```/// C++ comments``` when documenting for Doxygen -- Try to document all your work for Doxygen as you progress -- If anonymity is a concern, try to blend in with a present contributor's style +- Evite el caso mixto ```k``` y el MACRO_TYPE antes de la mezcla para todas las constantes +- Utilice Doxygen three-slash ```/// C ++ comments``` al documentar para Doxygen +- Trate de documentar todo su trabajo para Doxygen a medida que progresa +- Si el anonimato es una preocupación, intente mezclarse con el estilo de un colaborador actual -### Optional Checks +### Verificaciones opcionales 1. [cppdep](https://github.com/rakhimov/cppdep) - for component dependency, physical insulation, and include checks. -2. [cppcheck](https://github.com/danmar/cppcheck/) for static analysis - (complementary to Coverity). -3. [lizard](https://github.com/terryyin/lizard) for code complexity checks. - -## Sending your work -To contribute your work, please proceed with the following: - -1. [Fork](https://help.github.com/articles/fork-a-repo/) Kovri -2. Review the style section of this document -3. Create a [topic branch](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) - - We currently do not have any tags as we are in Alpha. For now, you can base your work off of master -4. Make changes - - Commits should be [atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) when possible and diffs should be easy to read - - Please try to not mix formatting fixes with non-formatting commits -5. Be courteous of the git-log - - Commit title should prepend class or aspect of project. For example, "HTTPProxy: implement User-Agent scrubber. Fixes #193." or "Garlic: fix uninitialized padding in ElGamalBlock" - - Commit messages should be verbose by default, consisting of a short subject line (50 chars max), a blank line, and detailed explanatory text as separate paragraph(s) - unless the title alone is self-explanatory - - If a particular commit references another issue, please add a reference. For example; *See #123*, or *Fixes #123*. This will help us resolve tickets when we merge into `master` - - If a particular commit is rebased after collaboration within a pull-request, please reference the pull-request number within the commit message. For example; *References #123* -6. [**Sign**](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) your commit(s) and, if you are a new contributor, open a new pull-request which adds your PGP key to our repository (see contrib) -7. Send a pull-request to branch `master` - - The body of the pull request should contain an accurate description of what the patch does and should also provide justification/reasoning for the patch (when appropriate). You should include references to any discussions such as other tickets or chats on IRC - -## Proposals -To contribute a proposal, please review our [open issues](https://github.com/monero-project/kovri/issues) for existing proposals. If what you propose is not there, then [open a new issue](https://github.com/monero-project/kovri/issues/new). - -Even though our C4 dictates that we merge everything, we ask that you open a proposal for the following reasons: - -1. A proposal opens up communication -2. A proposal shows that the contributor respects the input of all project collaborators -3. A proposal allows seamless collaborator input in an open forum -4. A proposal saves time if a collaborator is working on a similar feature/issue -5. A proposal prevents catastrophes and mishaps or allows collaborators to prepare for catastrophes and mishaps - -*Not* opening a proposal will *not* prevent you from contributing; we will merge what you PR - but a proposal is highly recommended. - -## TODO's -- Do a quick search in the codebase for ```TODO(unassigned):``` and/or pick a ticket and start patching! -- If you create a TODO, assign it to yourself or write in ```TODO(unassigned):``` + para la dependencia de los componentes, el aislamiento físico e incluir controles. +2. [cppcheck](https://github.com/danmar/cppcheck/) para el análisis estático + (complementario a Coverity). +3. [lizard](https://github.com/terryyin/lizard) para verificar la complejidad del código. + +## Envío de tu trabajo +Para contribuir con su trabajo, proceda con lo siguiente: + +1. Haz un [Fork](https://help.github.com/articles/fork-a-repo/) de Kovri +2. Revisa la sección de estilo de este documento +3. Cree una [rama](https://git-scm.com/book/es/v2/Git-Branching-Basic-Branching-and-Merging) + - Actualmente no tenemos ningún tag por estar en Alpha. Por ahora, puedes basar tu trabajo desde la rama master. +4. Haz cambios + - En general, los commits deben ser [atomicos](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) y los diffs deben ser fáciles de leer. + - Intente no mezclar correcciones de formato con confirmaciones sin formato +5. Sé cortés con el registro de git + - El título de commit debe preponer class u otro aspecto del proyecto. Por ejemplo, "HTTPProxy: implementado depurador de User-Agent. Arregla #193." o "Garlic: arregla padding no inicializado en ElGamalBlock". + - Los mensajes del Commit deben ser verbose por default, considerando una línea de asunto de (50 caracteres máximo), una línea en blanco y una explicación detallada como párrafo(s) separado(s) - a menos que el titulo se auto-explique. + - Si un commit en particular hace referencia otro issue, por favor pon una referencia. Por ejemplo, "Leer #123", o "Arregla #123". Esto ayudara a resolver issues cuando se mezclen con ```master```. + - Si un commit en particular se vuelve a establecer después de la colaboración dentro de un pull request, consulte el número de pull request dentro del mensaje del commit. Por ejemplo; *Referencia #123* +6. [**Firma**](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) tu(s) commit(s), y si eres un colaborador nuevo, haz un pull request para agregar tu clave PGP a nuestro repositorio. +7. Envía tu pull-request a la branch ```master``` + - El cuerpo de los pull requests deben contener una descripción adecuada de lo que hace el parche, y proveer una justificación o razonamiento para el parche (cuando sea apropiado). Debes incluir referencias a cualquier discusión como issues, chats, o IRC. + +## Propuestas +Para contribuir una propuesta, por favor lee nuestros [issues abiertos](https://github.com/monero-project/kovri/issues) para ver los ya existentes. Si lo que quieres proponer no está ahí, entonces [abre un nuevo issue](https://github.com/monero-project/kovri/issues/new). + +A pesar de que nuestro C4 dicta, que nosotros mezclamos todo, pedimos abrir una propuesta por las siguientes razones: + +1. Una propuesta abre la comunicación +2. Una propuesta muestra que el colaborador respeta la opinión de todos los colaboradores del proyecto +3. Una propuesta permite a los colaboradores opinar en un foro abierto +4. Una propuesta ahorra tiempo si un colaborador ya está trabajando en algo similar +5. Una propuesta previene catástrofes, y errores, o permite a los colaboradores prepararse para catástrofes, o errores + +*No* abrir una nueva propuesta *no* va a prevenirte de colaborar; nosotros mezclaremos tu PR - pero una propuesta es altamente recomendada. + +## TODO +- Haz una búsqueda rápida en el código base por ```TODO(sin asignar):``` y/o elige un issue y ¡comienza a trabajar! +- Si creas un TODO, asígnatelo a ti mismo o escribe ```TODO(sin asignar):``` ## Fuzz testing -From [reference](http://llvm.org/docs/LibFuzzer.html) : "LibFuzzer is under active development so you will need the current (or at least a very recent) version of the Clang compiler" +Para [referencia](http://llvm.org/docs/LibFuzzer.html) : "LibFuzzer esta bajo desarrollo activo caso que necesitaras la versión actual (o la mas reciente) del compilador Clang" -Get a recent version of clang: +Obtén una versión reciente de Clang: ```bash $ cd ~/ && mkdir TMP_CLANG && git clone https://chromium.googlesource.com/chromium/src/tools/clang TMP_CLANG/clang @@ -92,19 +92,19 @@ $ ./TMP_CLANG/clang/scripts/update.py $ cd -- ``` -Get libFuzzer: +Obtén libFuzzer: ```bash $ git clone https://chromium.googlesource.com/chromium/llvm-project/llvm/lib/Fuzzer contrib/Fuzzer ``` -Build kovri with fuzz testing enabled: +Compila kovri con fuzz testing habilitado: ```bash $ PATH="~/third_party/llvm-build/Release+Asserts/bin:$PATH" CC=clang CXX=clang++ make fuzz-tests ``` -Usage (Example for RouterInfo): +Uso (Ejemplo de RouterInfo): ```bash mkdir RI_CORPUS MIN_RI_CORPUS @@ -113,64 +113,64 @@ find ~/.kovri/core/network_database/ -name "router_info*" -exec cp {} RI_CORPUS ./build/kovri-util fuzz --target=routerinfo -jobs=2 -workers=2 MIN_RI_CORPUS ``` -# Quality Assurance - -The following is a proposed model for QA workflow. While linear in nature, any phase can be worked on individually if needed - as long as all phases are eventually addressed. - -## Phase 1: Basic Review - -- Review open issues on our [Issue Tracker](https://github.com/monero-project/kovri/issues/) -- Review our [Vulnerability Response Process](https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md) -- All code must adhere to our contributing guidelines -- Note areas that need improving (mentally or in code) -- Create TODO's and assign if possible - -## Phase 2: Specification Review / Implementation / Code Documentation - -- Complete specification review on a per module basis; e.g., Streaming, I2PControl, etc. - - Code must be in-line with essential parts of the specification that will maintain the same (or better) level of anonymity that java I2P provides - - Refactor/implement/patch when/where needed -- Ensure C++11/14 compliant implementation - - Review phase 2 if needed -- Resolve all related TODO's -- Document code as much as possible with inline comments and Doxygen - - Code should be understood by novice to experienced coders - - Code should guide the reader to a better understanding of I2P - - I2P is very complex so our code should act as sovereign replacement of spec documentation and not simply as a supplement (this can be a tedious objective but very rewarding in terms of maintenance and software lifespan) - -## Phase 3: Crypto Review / Security auditing - -- Ensure that crypto is up-to-date and properly implemented -- Establish every vector for known exploitation - - Keep these vectors in mind when writing tests -- Break Kovri every which-way possible - - Fix what you break -- Always use trustworthy, well-written libraries when possible - - Avoid homebrewed, ad-hoc, *I'm sure I know better than the community* type of code -- Seek a 2nd (or more) opinion(s) from colleagues before proceeding to next phase - -## Phase 4: Bug squashing / Tests / Profiling - -- Resolve priority bugs/issues -- Write unit-tests tests for every module - - Run tests. Run them again - - Full review of test results. Patch if needed. Refactor as necessary -- Ensure that automation is running on a regular basis +# Seguros de calidad + +El siguiente modelo es el propuesto para el trabajo de QA. Mientras se tiene una naturaleza linear, cualquier fase puede ser trabajada individualmente si se necesita - mientras que todas las fases eventualmente son revisadas. + +## Fase 1: Revisión básica + +- Revisa nuestros issues abiertos en nuestro [Issue Tracker](https://github.com/monero-project/kovri/issues/) +- Revisa nuestro [Proceso de respuesta de vulnerabilidades](https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md) +- Todo el código debe adherirse a nuestras guías de contribución +- Anotar todas las áreas que necesitan ser mejoradas (mentalmente o en el código) +- Crear TODOs y asignarse de ser posible + +## Fase 2: Revisión de especificaciones / Implementación / Documentación de código + +- Completa las revisiones de especificaciones por módulos; ejemplo: Streaming, I2PControl, etc. + - El código debe estar en-linea con las partes esenciales de las especificaciones que se mantendrán iguales (o en mejores) niveles de anonimato que provee java I2P + - Refactorizar/implementar/parchear donde/cuando se necesite. +- Asegurarse de cumplir con la implementación en C++11/14 + - realizar la Fase 2 si se necesita +- Resolver todo lo relacionado a los TODOs +- Documentar el código tanto como sea posible con comentarios en-linea y Doxygens + - El código debe ser entendible desde programadores novatos a experimentados + - El código debe guiar al lector a un mejor entendimiento de I2P + - I2P es un código muy largo y complejo, así que el nuestro debe ser un reemplazo de documentación y no simplemente un suplemento (esto puede ser un objetivo tedioso pero muy beneficioso en términos de mantenimiento y vida del software) + +## Fase 3: Revisión criptográfica / auditoria de seguridad + +- Asegurarse que la criptografía este al día y correctamente implementada +- Establecer cada vector para explotaciones conocidas + - Mantener esos vectores en mente cuando se escriban pruebas +- Romper Kovri en cada forma posible + - Arreglar lo que rompes +- Siempre usa librerías de confianza, y bien escritas cuando sea posible + - Evita código hecho-en-casa, ad-hoc, *Yo se mas que la comunidad, por eso mi código es mejor* +- Busca una segunda, tercera y mas opiniones, antes de proceder a la siguiente fase + +## Fase 4: Arreglar bugs / Pruebas / Profiling + +- Resolver los bugs/issues de prioridad +- Escribir pruebas de unit-test para cada modulo + - Correr pruebas, y correrlas de nuevo + - Revisa los resultados por completo. Parchea si se necesita, refactoriza si es necesario +- Asegúrate que la automatización este corriendo a intervalos regulares - valgrind, doxygen, clang-format - - Patch if needed, refactor as necessary + - Parchea si es necesario, refactoriza si es necesario -## Phase 5: Confer +## Fase 5: Conferir -- Confer with colleagues and the community - - Conferring should be done publicly via ticket, meetings, and/or IRC -- Accept all feedback and, in response, produce tangible results -- If satisfied, proceed with next phase, else repeat this phase (or start from a previous phase) +- Conferir con colegas y la comunidad + - Conferir debe ser públicamente via issues, reuniones, y/o IRC +- Aceptar toda retroalimentación y, en respuesta, producir resultados tangibles +- Si se satisface, proceder con la siguiente fase, si no repetir esta fase, (o comenzar de una fase previa) -## Phase 6: Repeat the cycle from the beginning +## Fase 6: Repetir todo desde el inicio -# [Code of Conduct (22/C4.1)](http://rfc.zeromq.org/spec:22) +# [Código de conducta (22/C4.1)](http://rfc.zeromq.org/spec:22) -## License +## Licencia Copyright (c) 2009-2015 Pieter Hintjens. @@ -180,105 +180,105 @@ This Specification is distributed in the hope that it will be useful, but WITHOU You should have received a copy of the GNU General Public License along with this program; if not, see . -## Language - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. - -## Goals - -C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals: - -- To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks; -- To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain; -- To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process; -- To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code; -- To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error; -- To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities. - -## Design - -### Preliminaries - -- The project SHALL use the git distributed revision control system. -- The project SHALL be hosted on github.com or equivalent, herein called the "Platform". -- The project SHALL use the Platform issue tracker. -- The project SHOULD have clearly documented guidelines for code style. -- A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem. -- A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process. -- Contributors SHALL NOT have commit access to the repository unless they are also Maintainers. -- Maintainers SHALL have commit access to the repository. -- Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract. - -### Licensing and Ownership - -- The project SHALL use a share-alike license, such as the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2. -- All contributions to the project source code ("patches") SHALL use the same license as the project. -- All patches are owned by their authors. There SHALL NOT be any copyright assignment process. -- The copyrights in the project SHALL be owned collectively by all its Contributors. -- Each Contributor SHALL be responsible for identifying themselves in the project Contributor list. - -### Patch Requirements - -- Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias. -- A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem. -- A patch MUST adhere to the code style guidelines of the project if these are defined. -- A patch MUST adhere to the "Evolution of Public Contracts" guidelines defined below. -- A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code. -- A patch MUST compile cleanly and pass project self-tests on at least the principle target platform. -- A patch commit message SHOULD consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description. -- A "Correct Patch" is one that satisfies the above requirements. - -### Development Process - -- Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems. -- To request changes, a user SHOULD log an issue on the project Platform issue tracker. -- The user or Contributor SHOULD write the issue by describing the problem they face or observe. -- The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem. -- Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable. -- Thus, the release history of the project SHALL be a list of meaningful issues logged and solved. -- To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository. -- To submit a patch, a Contributor SHALL create a Platform pull request back to the project. -- A Contributor SHALL NOT commit changes directly to the project. -- If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue. -- To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere. -- To accept or reject a patch, a Maintainer SHALL use the Platform interface. -- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days). -- Maintainers SHALL NOT make value judgments on correct patches. -- Maintainers SHALL merge correct patches from other Contributors rapidly. -- The Contributor MAY tag an issue as "Ready" after making a pull request for the issue. -- The user who created an issue SHOULD close the issue after checking the patch is successful. -- Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively. -- Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches. -- Maintainers MAY commit changes to non-source documentation directly to the project. - -### Creating Stable Releases - -- The project SHALL have one branch ("master") that always holds the latest in-progress version and SHOULD always build. -- The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches. -- To make a stable release someone SHALL fork the repository by copying it and thus become maintainer of this repository. -- Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers. -- A stabilization project SHOULD be maintained by the same process as the main project. -- A patch to a stabilization project declared "stable" SHALL be accompanied by a reproducible test case. - -### Evolution of Public Contracts - -- All Public Contracts (APIs or protocols) SHALL be documented. -- All Public Contracts SHOULD have space for extensibility and experimentation. -- A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this. -- A patch that introduces new features to a Public Contract SHOULD do so using new names. -- Old names SHOULD be deprecated in a systematic fashion by marking new names as "experimental" until they are stable, then marking the old names as "deprecated". -- When sufficient time has passed, old deprecated names SHOULD be marked "legacy" and eventually removed. -- Old names SHALL NOT be reused by new features. -- When old names are removed, their implementations MUST provoke an exception (assertion) if used by applications. - -### Project Administration - -- The project founders SHALL act as Administrators to manage the set of project Maintainers. -- The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers. -- A new Contributor who makes a correct patch SHALL be invited to become a Maintainer. -- Administrators MAY remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately. -- Administrators SHOULD block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others. - -# Governance Process - -![Governance Process](https://getmonero.org/blog/assets/2015-year-in-review/governance-process.jpg) +## Lenguaje + +Las palabras "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", y "OPTIONAL" en este documento, deben ser interpretadas como esta descrito en el RFC 2119. + +## Metas + +C4 está hecho para ser un modelo óptimo de colaboración para proyectos de software de código abierto. Y se especifican los siguientes objetivos: + +- Maximizar la escala y la diversidad de la comunidad en torno a un proyecto, reduciendo la fricción para los nuevos colaboradores y creando un modelo de participación escalado con fuertes retroalimentaciones positivas; +- Para aliviar las dependencias de individuos clave, separando diferentes conjuntos de habilidades para que haya un mayor grupo de competencia en cualquier dominio requerido; +- Permitir que el proyecto se desarrolle de forma más rápida y precisa, aumentando la diversidad del proceso de toma de decisiones; +- Apoyar el ciclo de vida natural de las versiones del proyecto, desde el experimental hasta el estable, permitiendo la experimentación segura, el fracaso rápido y el aislamiento del código estable; +- Reducir la complejidad interna de los repositorios de proyectos, facilitando así la participación de los contribuyentes y reduciendo el margen de error; +- Reforzar la propiedad colectiva del proyecto, lo que aumenta el incentivo económico a los contribuyentes y reduce el riesgo de secuestro por entidades hostiles. + +## Diseño + +### Preliminares + +- El proyecto USARÁ el sistema de control de revisión distribuido git. +- El proyecto ESTARÁ alojado en github.com o equivalente, llamado "Plataforma". +- El proyecto USARÁ utilizar la plataforma de Tracker de issues. +- El proyecto DEBERÁ tener directrices claramente documentadas para el estilo de código. +- Un "Colaborador" es una persona que desea proporcionar un parche, siendo un conjunto de compromisos que resuelven algún problema claramente identificado. +- Un "Mantenedor" es una persona que fusiona parches al proyecto. Los mantenedores no son desarrolladores; Su trabajo es hacer cumplir el proceso. +- Los colaboradores NO TENDRÁN acceso de commit al repositorio a menos que sean también Mantenedores. +- Los mantenedores TENDRÁN tener acceso de commit al repositorio. +- Todos, sin distinción ni discriminación, TENDRÁN el mismo derecho de convertirse en un Colaborador en los términos de este contrato. + +### Licencia y propiedad + +- El proyecto DEBE utilizar una licencia compartida, como la GPLv3 o una variante de la misma (LGPL, AGPL), o la MPLv2. +- Todas las contribuciones al código fuente del proyecto ("parches") DEBERÁ utilizar la misma licencia que el proyecto. +- Todos los parches son propiedad de sus autores. No habrá ningún proceso de asignación de derechos de autor. +- Los derechos de autor del proyecto serán de propiedad colectiva de todos sus colaboradores. +- Cada Contribuyente DEBERÁ ser responsable de identificarse en la lista de Colaboradores del proyecto. + +### Requisitos del parche + +- Mantenedores y contribuyentes DEBEN tener una cuenta de la plataforma y DEBERÍAN utilizar sus nombres verdaderos o un alias conocido. +- Un parche DEBE ser una respuesta mínima y precisa a exactamente un problema identificado y acordado. +- Un parche DEBE adherirse a las directrices de estilo de código del proyecto si se definen. +- Un parche DEBE adherirse a la "Evolución de los contratos públicos" directrices definidas a continuación. +- Un parche NO incluirá código no trivial de otros proyectos a menos que el Colaborador sea el autor original de ese código. +- Un parche DEBE compilar de forma limpia y pasar las auto pruebas del proyecto en al menos la plataforma objetivo principal. +- Un mensaje de commit de parche DEBERÍA consistir en una sola línea corta (menos de 50 caracteres) que resume el cambio, seguido opcionalmente por una línea en blanco y luego una descripción más completa. +- Un "Patch Correcto" es aquel que satisface los requisitos anteriores. + +### Proceso de desarrollo + +- El cambio en el proyecto deberá ser gobernado por el patrón de identificar con precisión los issues y aplicar soluciones mínimas y precisas a estos issues. +- Para solicitar cambios, un usuario DEBE registrar un issue en el Tracker de issues de plataforma del proyecto. +- El usuario o el colaborador DEBE escribir el issue describiendo el issue que enfrentan u observan. +- El usuario o colaborador DEBE buscar un consenso sobre la exactitud de su observación, y el valor de resolver el issue. +- Los usuarios NO deben registrar solicitudes de información, ideas, sugerencias o soluciones a issues que no estén explícitamente documentados y probables. +- Así, el historial de lanzamiento del proyecto SERÁ una lista de asuntos significativos registrados y resueltos. +- Para trabajar en un issue, un colaborador DEBE hacer un fork del repositorio del proyecto y luego trabajar en su repositorio forkeado. +- Para enviar un parche, un colaborador DEBERÁ crear un pull request al proyecto. +- Un colaborador NO DEBE hacer commits directamente al proyecto. +- Si la Plataforma implementa pull request directo a issues, un Contribuyente PUEDE enviar directamente un pull request sin registrar un issue separado. +- Para discutir un parche, la gente PUEDE comentar en el pull request, en el commit, o en cualquier otro lugar. +- Para aceptar o rechazar un parche, un mantenedor DEBE utilizar la interfaz de la plataforma. +- Los mantenedores NO DEBEN fusionar sus propios parches excepto en casos excepcionales, como la falta de respuesta de otros Mantenedores durante un período prolongado (más de 1-2 días). +- Los mantenedores NO HARÁN juicios de valoración sobre los parches correctos. +- Los mantenedores deben fusionar los parches correctos de otros Colaboradores rápidamente. +- El colaborador PUEDE marcar un issue como "Listo" después de realizar un pull request del issue. +- El usuario que creó un issue DEBE cerrar el issue después de comprobar el parche es un éxito. +- Los mantenedores DEBEN pedir mejoras a los parches incorrectos y DEBEN rechazar los parches incorrectos si el Colaborador no responde de manera constructiva. +- Cualquier Contribuyente que tenga juicios de valoración en un parche correcto DEBERÍA expresarlos a través de sus propios parches. +- Los mantenedores PUEDEN realizar cambios en la documentación que no sea de origen directamente al proyecto. + +### Creación de versiones estables + +- El proyecto DEBE tener una rama ("master") que siempre tiene la última versión en curso y siempre debe compilar. +- El proyecto NO UTILIZARÁ ramas temáticas por ningún motivo. Los fork personales PUEDEN utilizar ramas temáticas. +- Para hacer una versión estable, alguien debe hacer un FORK del repositorio copiándolo y así convertirse en mantenedor de este repositorio. +- El fork de un proyecto para estabilización PUEDE hacerse unilateralmente y sin el acuerdo de los mantenedores del proyecto. +- Un proyecto de estabilización DEBE ser mantenido por el mismo proceso que el proyecto principal. +- Un parche de un proyecto de estabilización declarado "estable" deberá ir acompañado de un caso de prueba reproducible. + +### Evolución de los contratos públicos + +- Todos los contratos públicos (APIs o protocolos) DEBEN ser documentados. +- Todos los contratos públicos DEBEN tener espacio para la extensibilidad y la experimentación. +- Un parche que modifica un contrato público estable NO DEBE romper las aplicaciones existentes a menos que haya un consenso sobre el valor de hacer esto. +- Un parche que introduce las nuevas características a un contrato público DEBE hacerlo utilizando nuevos nombres. +- Los nombres antiguos DEBEN ser obsoletos de una manera sistemática marcando nuevos nombres como "experimentales" hasta que sean estables, después marcando los viejos nombres como "inutilizados". +- Cuando haya pasado el tiempo suficiente, los viejos nombres obsoletos DEBERÍAN ser marcados como "heredados" y eventualmente eliminados. +- Los nombres antiguos NO SERÁN reutilizados por las nuevas funciones. +- Cuando se quitan los nombres antiguos, sus implementaciones DEBEN provocar una excepción (aserción) si son utilizadas por las aplicaciones. + +### Administración del proyecto + +- Los fundadores del proyecto DEBERÁ actuar como Administradores para administrar el conjunto de los Mantenedores del Proyecto. +- Los Administradores DEBEN asegurar su propia sucesión a cierto tiempo promoviendo a los Mantenedores más efectivos. +- Un nuevo colaborador que hace un parche correcto se invitará a convertirse en un mantenedor. +- Los Administradores PUEDEN quitar a los Mantenedores que permanezcan inactivos por un periodo de tiempo prolongado, o que repetidamente no apliquen este proceso con exactitud. +- Los administradores DEBEN bloquear o prohibir a los "malos actores" que causan estrés y dolor a los demás en el proyecto. Esto debe hacerse después de una discusión pública, con la posibilidad de que todas las partes hablen. Un mal actor es alguien que ignora repetidamente las reglas y la cultura del proyecto, que es innecesariamente argumentativo u hostil, o que es ofensivo, y que es incapaz de auto-corregir su comportamiento cuando se le pide que lo haga por otros. + +# Proceso de gobernanza + +![Proceso de gobernanza](https://getmonero.org/blog/assets/2015-year-in-review/governance-process.jpg) diff --git a/i18n/es/faq.md b/i18n/es/faq.md index 4da4eba..23fb497 100644 --- a/i18n/es/faq.md +++ b/i18n/es/faq.md @@ -1,70 +1,143 @@ +# Preguntas frecuentes + +## Tabla de contenido +- Preguntas generales + - ¿Qué es Kovri? + - ¿Quién está desarrollando Kovri? + - ¿Cómo ayudará Kovri a Monero? + - ¿Por qué debería obtener Kovri en lugar de I2P? + - ¿Qué hace / no hace Kovri por ti? + - ¿Cuál es el estado actual de Kovri? + - Cuando es el alfa? + - ¿En qué se está centrando actualmente el equipo de desarrollo? + - ¿Cuál es la usabilidad actual de Kovri y la privacidad que ofrece? + - ¿Cómo puedo contactar a los desarrolladores de Kovri? +- Kovri vs i2pd + - ¿Por qué debería usar Kovri en lugar de i2pd? + - ¿Cuáles son las principales diferencias entre Kovri e i2pd? + - ¿Por qué te burlaste de i2pd? + - ¿Cuáles fueron los puntos de inflexión que llevaron a la bifurcación de i2pd (y por qué hay dos repositorios de i2pd: uno en Bitbucket y otro en GitHub)? +- Usando Kovri + - ¡Encontré una vulnerabilidad! Encontré un error! ¿Qué debo hacer? + - ¿Por qué mi registro muestra una fecha / hora diferente de mi zona horaria? # Preguntas frecuentes (y sus respuestas) -## ¿Que es Kovri? -Kovri es una implementación del router [I2P](https://geti2p.net) en C++, segura, privada, no rastreable y anónima. Lo que una vez fue un fork de i2pd, Kovri se ha convertido en una implementación única y activamente desarrollada implementación en C++ de I2P implementación llevada por la comunidad con muchas mejoras de seguridad, y nuevas características por sobre su predecesor. +## Preguntas Generales -Lee más de Kovri en la [Moneropedia](https://getmonero.org/resources/moneropedia/kovri.html). +### ¿Que es Kovri? -## ¿Cuál es el estado actual de Kovri? -Kovri está en desarrollo activo y actualmente en fase Alpha. Kovri aun *no* está integrada con Monero pero, en adición a algunas funciones principales estamos desarrollando un [cliente](https://github.com/monero-project/kovri/issues/351) y [una API](https://github.com/monero-project/kovri/issues/350) principal para Monero y otras App. +[Kovri](https://getmonero.org/resources/moneropedia/kovri.html) es una tecnología gratuita, descentralizada y anónima desarrollada por [Monero](https://getmonero.org). -Actualmente, puedes conectarte y (formar parte de) la red I2P: navegar eepsites, conectarte a IRC y correr túneles cliente y servidor. +Actualmente basado en las especificaciones abiertas de [I2P](https://getmonero.org/resources/moneropedia/i2p.html), Kovri usa ambos [encriptación de ajo (Garlic)](https://getmonero.org/resources/moneropedia/garlic-encryption.html) y [routing de ajo (Garlic)](https://getmonero.org/resources/moneropedia/garlic-routing.html) para crear una red privada superpuesta protegida a través de Internet. Esta superposición de red proporciona a los usuarios la capacidad de *ocultar* de manera efectiva su ubicación geográfica y su dirección IP de Internet. -## ¿Cuándo será su primer lanzamiento? -Una versión alpha será lanzada al principio del 2017. Una vez que se tengan todos los seguros de calidad y se haya resuelto e implementado una API funcional, iremos a la versión beta. +Esencialmente, Kovri *cubre* el tráfico de Internet de una aplicación para que sea anónimo dentro de la red. -## ¿Porque mi log muestra una fecha/hora diferente a mi zona? -Los logs son guardados en UTC para proteger tu privacidad, usando UTC estas en una mejor posición de subir logs y compartirlos con los desarrolladores o la comunidad sin comprometer su anonimato. +Un enrutador ligero y centrado en la seguridad, Kovri es totalmente compatible con la red I2P. Una versión alfa de Kovri está en proceso. -## ¿En que se está enfocando el equipo de desarrollo? -Actualmente, nos estamos enfocando en todo lo que se encuentra en nuestro [issues tracker](https://github.com/monero-project/kovri/issues/). Ellos cubren un montón de cosas que necesitamos finalizar antes de lanzar una versión oficial (alpha, beta, o mayor). +### ¿Quién está desarrollando Kovri? +Kovri es un proyecto de código abierto, lo que significa que depende de la comunidad para las contribuciones. El desarrollador principal del proyecto es [anonimal](https://github.com/anonimal), a quien puede contactar con preguntas en los canales IRC de Kovri [#kovri](irc://chat.freenode.net/#kovri ), [# kovri-dev](irc://chat.freenode.net/#kovri-dev), y su [cuenta de Twitter](https://twitter.com/whoisanonimal). -## ¿Es Kovri usable, parcialmente usable, o recomendado no usarlo actualmente? -Kovri es usable al punto de lo que ```./kovri --help``` tiene para ofrecer. Kovri aún no tiene interacción con Monero. Con respecto a la privacidad hemos arreglado muchos agujeros de seguridad desde los inicios, pero aún estamos en Alpha. +Kovri se está desarrollando bajo el cobijo de [The Monero Project](https://github.com/monero-project), que es otro proyecto de código abierto que desarrolla la [Moneda Monero](https://getmonero.org) y [Open Alias](https://openalias.org). La relación entre The Monero Project y Kovri es mutuamente beneficiosa, con Kovri buscando integrarse en la red de Monero, y Monero brindando un flujo de desarrolladores y recursos para el desarrollo de Kovri. -Aún hay mucho código que cubrir así que no esperamos un anonimato fuerte asegurado como en Tor, o incluso java I2P. Esos proyectos tienen más de 10 años de experiencia en investigación e implementación - nosotros apenas estamos comenzando. +### ¿Cómo ayudará Kovri a Monero? +Monero es una criptomoneda segura, privada, imposible de rastrear y fungible que tiene privacidad de forma predeterminada y utiliza tecnologías tales como stealth addresses, RingCT y firmas de anillo para ocultar el receptor, los importes y el remitente, respectivamente. Algunas debilidades potenciales en Monero están filtrando la dirección IP que transmite una transacción y los ataques de correlación. -Siéntete libre de jugar el rol de desarrollador y experimentar/jugar con Kovri, pero solo si **no** ser totalmente anónimo no te coloca en peligro - porque siempre hay riesgo de una posible des- anonimización dado a que aún se está en Alpha, esto no es único de Kovri. +Entra en Kovri. Kovri se implementará en la billetera Monero oficial, por lo que todas las transacciones se enrutarán a través de la red anónima Kovri, ocultando la dirección IP desde la cual se originó la transacción. En el futuro, todas las transacciones se enrutarán a través de Kovri de forma predeterminada, aunque descargar el blockchain seguirá siendo a través de la red transparente para mayor eficiencia. -## ¿Información de contacto de Kovri? -Lee nuestro [README](https://github.com/monero-project/kovri/blob/master/README.md). +### ¿Por qué debería usar Kovri en lugar de I2P? +[I2P](https://geti2p.net) es un gran proyecto, pero había algunas cosas que sentimos que era necesario ajustar para integrar la tecnología en Monero. Primero, I2P está desarrollado en Java, y pensamos que desarrollar un enrutador en C++ ayudaría a que el código sea rápido y liviano. -## ¿Porque debería usar Kovri en vez de I2P? +En segundo lugar, aunque la implementación de I2P en Java es excelente, viene con muchas características adicionales que no creemos que sean necesarias para que la use Monero. Entonces, decidimos comenzar desde cero y crear un enrutador que sea JUSTO el enrutador. Este enfoque básico es perfecto para Monero, y también es una buena noticia para otros que quieren hacer aplicaciones I2P. Tienen la opción de usar un enrutador ligero sin todo el exceso, mientras que otros usuarios que tienen un uso para esas características adicionales podrán usar la implementación de Java. Es una situacion de ganar-ganar para todos. -- Seguridad: nuestro enfoque es en la seguridad de nuestro software; no [apurarnos a tener todo listo](https://github.com/monero-project/kovri/issues/65) por el hecho de tener las cosas listas -- Calidad: estas apoyando esfuerzos para ayudar a tener un código base de calidad que perdurara en el tiempo. Esto incluye todos los aspectos del mantenimiento del código -- Monero: estarás apoyando una cripto-moneda que su orgullo principal es la preservación de la privacidad y anonimato mientras incrementa ambos tu privacidad y anonimato +### ¿Qué hace Kovri ahora? +- Te permite convertirte en un nodo en la red I2P +- Oculta su ubicación física de los sitios que visita +- Anonimiza en IRC y permite el correo electrónico anónimo +- Te permite alojar sitios web o servicios anónimos +- Proporciona fondos a desarrolladores, hackers e investigadores a través de FFS y HackerOne. +- Busca estándares rigurosos de calidad de código y desarrollo -## ¿Cuáles son las principales diferencias entre Kovri y i2pd? +### ¿Qué novedades tendra Kovri en el futuro? +- Confirmar las transacciones de Monero sobre I2P +- GUI para una mejor configuración y usabilidad +- API de biblioteca y enlaces para aplicaciones / librerías externas +- Extensión de Firefox para acceder fácilmente a eepsites +- Desarrollo de sitios web (getkovri.org / kovri.i2p) +- Amplia documentación de ELI5 para desarrolladores -- Proveemos un [Forum Funding System](https://forum.getmonero.org/8/funding-required) (sistema de recaudación de fondos) para desarrollo/características. -- Nos enfocamos en crear una ["seguridad por defecto"](http://www.openbsd.org/security.html), fácilmente mantenible, un router I2P mas-probable-de-ser-revisado. Esto viene con el costo de bajar las características menos usadas por usuarios en otros routers, pero con la funcionalidad principal de que una API estará completamente intacta. Creando un router esqueleto, más pequeño y eficiente, hemos provisto a investigadores y desarrolladores más tiempo para auditorias de seguridad y más tiempo para analizar el diseño y especificaciones de I2P. -- Nos enfocamos en implementar una API intuitiva y amigable para que cualquier aplicación se conecte y use la red I2P; incluyendo Monero -- Hemos otorgado a ambos, usuarios finales y desarrolladores un [seguro de calidad](https://github.com/monero-project/kovri/issues/58) y [modelos de desarrollo](https://github.com/monero-project/kovri-docs/blob/master/i18n/es/contributing.md) para proveer un mejor software para todos. -- Hemos implementado una opción de re-plantar como alternativa para que los usuarios puedan usar [Transportes Pluggables](https://www.torproject.org/docs/pluggable-transports.html.en) en vez de HTTPS para re-plantar. -- Hemos implementado una extensa funcionalidad *(modo escondido + inbound deshabilitado)* para proveer anonimato a los que viven en países con condiciones extremas o con firewall de NAT o DS-Lite. -- Siempre creamos un entorno amigable para la colaboración. -- Siempre escuchamos la retroalimentación de las personas y hacemos nuestro mayor esfuerzo para mejorar Kovri! +### ¿Qué no hará Kovri por ti? +- Sacrificar tu seguridad por motivos ocultos +- Proporcionar una interfaz de usuario web complicada y dolorosa +- Requerir autoridades para consenso de red +- Acceso a sitios web de Internet a través de un "outproxy" +- Requiere una VM Java asesina de rendimiento +- Caminar a tu perro o mascota favorita, pagar tus impuestos -## ¿Porque un fork de i2pd? +### ¿Cuál es el estado actual de Kovri? +Kovri está en desarrollo activo y actualmente se encuentra en una fase Alfa. *No* aún está integrado con Monero, pero, además de varias funciones principales, estamos desarrollando un [cliente](https://github.com/monero-project/kovri/issues/351) y [core](https://github.com/monero-project/kovri/issues/350) API para monero y otras aplicaciones para usar. -Copiamos por algunas razones: -- Queríamos una implementación robusta, segura y viable en C++ de la red I2P; y i2pd no lo ofrecía -- Queríamos una comunidad positiva que alentara la colaboración para mejorar el software; no negativa, o de gloria narcisista -- Queríamos un desarrollador líder que pudiera liderar; no alguien que ignora las peticiones de liberación de información responsable o se fuera con la cola entre las piernas cuando había problemas entre colaboradores +Pero solo porque estamos en Alpha no significa que no puedas usar Kovri. Actualmente, puede usar Kovri para conectarse (y participar) en la red I2P, explorar eepsites, conectarse a IRC y ejecutar túneles de clientes y servidores. -## ¿Cuáles son los puntos que llevaron copiarse de i2pd (y porque hay dos repos de i2pd, uno en Bitbucket y otro en GitHub)? +### ¿Cuándo es el alfa? +Está en preparación una versión alfa para lanzarse (¡esperamos!) Antes de finales de 2017. Una vez que estamos en alfa, inmediatamente comienza el trabajo sobre la versión beta, que requerirá: una API completamente implementada, resolución a calidad esencial problemas de seguridad y varias correcciones de errores. -*comienza el drama de i2pd*. +### ¿En qué se está centrando actualmente el equipo de desarrollo? +Actualmente, nos estamos centrando en todo lo que se detalla en nuestro [issue tracker](https://github.com/monero-project/kovri/issues/). Cubren la mayor parte de lo que necesitamos para terminar antes del lanzamiento alfa oficial. -Comenzando/Mediados en el 2015 uno de los desarrolladores con privilegios de Push en GitHub, subió un commit que el primer autor no le gusto. En vez de trabajar juntos para resolver el problema, dicho autor se llevó i2pd a Bitbucket, y borro **TODA** historial de git, y se hizo único contribuidor del software. El entonces juro que nunca regresaría a Irc2P. +### ¿Cuál es la usabilidad actual de Kovri y el nivel de privacidad que ofrece? +Kovri es utilizable en la medida de lo que `./kovri --help` tiene para ofrecer. Kovri actualmente no tiene interacción con Monero. Con respecto a la privacidad, hemos solucionado muchos problemas de seguridad desde el inicio, pero le pedimos que tenga en cuenta que todavía estamos en Alpha. -Esas acciones ofendieron a muchos en la comunidad I2P, incluyendo desarrolladores, y casi termino el proyecto C++. +Todavía hay mucho código por cubrir, así que no esperes una garantía sólida de anonimato como con Tor, o incluso Java I2P. Esos proyectos tienen más de 10 años de experiencia en investigación e implementación, y recién estamos comenzando. -A finales del 2015, llega anonimal, quien, no queriendo ver que el trabajo de todos se perdiera, revivió el proyecto bajo contribuciones de su autoría, y reiniciando el desarrollo. Una invitación abierta a todos los demás desarrolladores activos a una reunión sobre el futuro de i2pd. El primer autor de i2pd nunca se apareció, pero la reunión resulto en tal punto, que él se [retractó](https://github.com/PurpleI2P/i2pd/issues/279), y comenzó a trabajar en GitHub de nuevo - pero esta vez con un branch ```openssl``` en que resultó ser el repositorio de Bitbucket en vez de la rama ```master``` de la comunidad. +Siéntete libre de jugar el rol de desarrollador y experimentar con Kovri, pero solo si **no** el no ser anónimo no te pone en peligro, ya que siempre existe el riesgo de una posible de-anonimización debido a estar en Alpha (esto es no exclusivo de Kovri). -Ver que este comportamiento errático, solamente hería la red I2P y el proyecto como un todo, los demás desarrolladores continuaron en [varias reuniones importantes](https://github.com/monero-project/kovri/issues/47) y asentaron los fundamentos de lo que ahora es Kovri. +### ¿Cómo puedo contactar a los desarrolladores de Kovri? +Vea nuestro [README](https://github.com/monero-project/kovri/blob/master/README.md). -## ¡Encontré una vulnerabilidad! ¿Qué hago? -- Vulnerabilidades: leer nuestro [README](https://github.com/monero-project/kovri/blob/master/README.md) -- Bugs: leer nuestra [Guía para contribuir](https://github.com/monero-project/kovri-docs/blob/master/i18n/es/developer_guide.md) +## Kovri vs i2pd + +### ¿Por qué debería usar Kovri en lugar de i2pd? + +- Seguridad: nuestro enfoque es asegurar nuestro software; no [apurarnos en hacer las cosas](https://github.com/monero-project/kovri/issues/65) por el bien de tener un lanzamiento +- Calidad: estás apoyando los esfuerzos para garantizar una base de código de calidad que resista la prueba del tiempo. Esto incluye todos los aspectos de la mantenibilidad del código +- Monero: apoyará una moneda criptográfica que se enorgullece de la preservación de la privacidad y el anonimato, al tiempo que aumenta su privacidad y su anonimato. + +### ¿Cuáles son las principales diferencias entre Kovri e i2pd? + +- Brindamos un [Foro con un Sistema de Financiamiento (FFS)](https://forum.getmonero.org/8/funding-required) para funciones / desarrollo. +- Nos centramos en crear un enrutador I2P ["seguro por defecto"](http://www.openbsd.org/security.html), de fácil mantenimiento y con más posibilidades de ser revisado. Esto vendrá con el costo de eliminar las características de menor uso que se encuentran en los otros enrutadores, pero la funcionalidad central y una API estarán completamente intactas. Al crear un enrutador más pequeño, eficiente y "básico", brindaremos a los desarrolladores e investigadores más tiempo para la auditoría de seguridad y más tiempo para cuestionar el diseño y las especificaciones de I2P. +- Nos enfocamos en implementar una API intuitiva y amigable para el desarrollador para que cualquier aplicación se conecte y use la red I2P; esto incluye a Monero. +- Brindamos a los usuarios finales y a los desarrolladores una [garantía de calidad](https://github.com/monero-project/kovri/issues/58) y [modelo de desarrollo](https://github.com/monero-project/kovri-docs/blob/master/i18n/en/contributing.md) para proporcionar un mejor software para todos. +- Implementaremos opciones alternativas de reseed para que los usuarios puedan usar [Transportes conectables](https://www.torproject.org/docs/pluggable-transports.html.en) en lugar de HTTPS para hacer reseed. +- Implementaremos una funcionalidad extendida *(hidden mode + disabled inbound)* para brindar anonimato a aquellos que viven en países con condiciones extremas o aquellos que cuentan con cortafuegos NAT o DS-Lite de grado operador. +- Siempre crearemos un ambiente de bienvenida para la colaboración. +- Siempre escucharemos tus comentarios y haremos nuestro mejor esfuerzo para mejorar Kovri. + +### ¿Por qué te sales de i2pd? + +Hicimos un fork por al menos varias razones: + +- Queríamos una implementación C++ robusta, segura y viable de la red I2P; y i2pd no estaba listo para ello +- Queríamos una comunidad positiva que fomentara la colaboración para la mejora del software; no negativo, gloria narcisista +- Queríamos un desarrollador principal que pudiera liderar; no alguien que ignorara las solicitudes de revelación responsable o hacer un "esconder la colaand y correr" cuando se enfrenta con el conflicto del colaborador + +### ¿Cuáles fueron los puntos de inflexión que llevaron al fork de i2pd (y por qué hay dos repositorios de i2pd: uno en Bitbucket y otro en GitHub)? + +*Así comenzó el drama de i2pd*. + +A principios / mediados de 2015, uno de los desarrolladores con privilegios de edicion en GitHub hizo uno(s) commit(s) que al primer autor de i2pd no le gustó. En lugar de trabajar juntos para resolver el problema, dicho autor se llevo i2pd a Bitbucket, y borró **todo** el historial de git existente y se convirtió en el único 'colaborador' del software. Luego juró nunca volver a Irc2P. + +Estas acciones ofendieron a muchos en la comunidad I2P, incluidos los desarrolladores, y casi terminaron el proyecto C ++. + +En el otoño de 2015, llegó un momento en el que, no queriendo que el trabajo de todos se desperdiciara, revivió el proyecto a través de contribuciones propias y por el desarrollo reinante. Luego se dio una invitación abierta para que todos los desarrolladores activos restantes se reunieran y discutieran el futuro de i2pd. El primer autor de i2pd nunca apareció, pero el acto de reunirse aparentemente hizo crujir las plumas de i2pd hasta el punto en que [tomó represalias](https://github.com/PurpleI2P/i2pd/issues/279) y comenzó a trabajar en GitHub nuevamente, pero esta vez dentro de una rama ```openssl``` (que resultó ser el repositorio Bitbucket) en lugar de la rama``` master``` impulsada por la comunidad. + +Al ver que este tipo de comportamiento errático solo dañaría la red I2P y el proyecto en su conjunto, los desarrolladores restantes continuaron teniendo [varias reuniones importantes](https://github.com/monero-project/kovri/issues/47) y establecerieron las bases para lo que ahora es Kovri. + +## Usando Kovri + +### ¡Encontré una vulnerabilidad! Encontré un error! ¿Qué debo hacer? +- Vulnerabilidades: vea nuestro [README](https://github.com/monero-project/kovri/blob/master/README.md) +- Errores: vea nuestra [Guía del Desarrollador](https://github.com/monero-project/kovri-docs/blob/master/i18n/en/developer_guide.md) + +### ¿Por qué mi registro muestra una fecha / hora diferente a la de mi zona horaria? +Los registros se registran en UTC para proteger su privacidad. Al usar UTC, se encuentra en una mejor posición para cargar las contraseñas de registro para compartirlas con los desarrolladores o la comunidad sin afectar su anonimato. \ No newline at end of file diff --git a/i18n/es/index.md b/i18n/es/index.md index 520c988..d7fcc7a 100644 --- a/i18n/es/index.md +++ b/i18n/es/index.md @@ -1,7 +1,9 @@ -Kovri es una implementación router de la red anónima I2P, segura, privada e intraceable. Lo que una vez fue un fork de i2pd, Kovri se ha convertido en una única y activamente desarrollada, implementación en C++ de I2P, llevada por la comunidad con muchas mejoras en seguridad, y nuevas características sobre su predecesor. +[Kovri](https://getmonero.org/resources/moneropedia/kovri.html) es una tecnología gratuita, descentralizada y anónima desarrollada por [Monero](https://getmonero.org). -Kovri está en activo desarrollo, y se encuentra en Alpha. Kovri aún no está integrado con Monero pero, en adición a algunas características principales, estamos desarrollando un cliente, y un API principal para usarse en Monero y otras aplicaciones +Actualmente basado en las especificaciones abiertas de [I2P](https://getmonero.org/resources/moneropedia/i2p.html), Kovri usa ambos [encriptación de ajo (Garlic)](https://getmonero.org/resources/moneropedia/garlic-encryption.html) y [routing de ajo (Garlic)](https://getmonero.org/resources/moneropedia/garlic-routing.html) para crear una red privada superpuesta protegida a través de Internet. Esta superposición de red proporciona a los usuarios la capacidad de *ocultar* de manera efectiva su ubicación geográfica y su dirección IP de Internet. -Actualmente, puedes usar Kovri para conectarte a (y formar parte en) la red I2P: navegar en eepsites, conectarte a IRC, y correr túneles cliente y servidor. +Esencialmente, Kovri *cubre* el tráfico de Internet de una aplicación para que sea anónimo dentro de la red. -Un lanzamiento alpha está previsto para comienzos del 2017. Una vez que todos los seguros de calidad estén resueltos y una API haya sido completamente implementada, se lanzara una versión beta. +Un enrutador ligero y centrado en la seguridad, Kovri es totalmente compatible con la red I2P. Una versión alfa de Kovri está en proceso. + +Mire el desarrollo a través del repo de [Kovri](https://github.com/monero-project/kovri#downloads) y [únase a la comunidad](https://github.com/monero-project/kovri#contact). \ No newline at end of file diff --git a/i18n/es/quality.md b/i18n/es/quality.md deleted file mode 100644 index 7956432..0000000 --- a/i18n/es/quality.md +++ /dev/null @@ -1,55 +0,0 @@ -El siguiente modelo es el propuesto para el trabajo de QA. Mientras se tiene una naturaleza linear, cualquier fase puede ser trabajada individualmente si se necesita - mientras que todas las fases eventualmente son revisadas. - - -## Fase 1: Revision basica - -- Todo el codigo debe adherirse a nuestras guias de contribucion -- Anotar todas las areas que necesitan ser mejoradas (mentalmente o en el codigo) -- Crear TODOs y asignarse de ser posible - -## Fase 2: Revision de espesificaciones / Implementacion / Documentacion de codigo - -- Completa las revisiones de espesificaiones por modulos; ejemplo: Streaming, I2PControl, etc. - - El codigo debe estar en-linea con las partes escenciales de las espesificaciones que se mantendran iguales (o en mejores) niveles de anonimato que provee java I2P - - Refactorizar/implementar/parchear donde/cuando se necesite. -- Asegurarse implementacion acorde con C++11/14 - - Fase 2 de revision si se necesita -- Resolver todo lo relacionado a los TODOs -- Documentar el codigo tanto como sea posible con comentarios en-linea y Doxygens - - El codigo debe ser entendible desde programadores novatos a experimentados - - El codigo debe guiar al lector a un mejor entendimiento de I2P - - I2P es un codigo muy largo y complejo, asi que el nuestro debe ser un reemplazo de de documentacion y no simplemente un suplemento (esto puede ser un objetivo tedioso pero muy beneficioso en terminos de mantenimiento y vida del software) - -## Fase 3: Revision criptografica / auditoria de seguridad - -- Asegurarse que la criptografia este al dia y correctamente implementada -- Establecer cada vector para explotaciones conocidas - - Mantener esos vectores en mente cuando se escriban pruebas -- Romper Kovri en cada forma posible - - Arreglar lo que rompes -- Sempre usa librerias de confianza, y bien escritas cuando sea posible - - Evita codigo hecho-en-casa, ad-hoc, *Yo se mas que la comunidad, por eso mi codigo es mejor* -- Busca una segunda, tercera y mas opiniones, antes de proceder a la siguiente fase - -## Fase 4: Arreglar bugs / Pruebas / Profiling - -- Resolver los bugs/issues de prioridad -- Escribir pruebas de unit-test para cada modulo - - Correr pruebas, y correrlas de nuevo - - Revisa los resultados por complet. Parchea si se necesita, refactoriza si es necesario -- Asegurate que la automatizacion este corriendo a intervalos regulares - - Parchea si es necesario, refactoriza si es necesario - -## Fase 5: Conferir - -- Conferir con colegas y la comunidad - - Conferir debe ser publicamente via tickes, reuniones, y/o IRC -- Aceptar toda retroalimentacion y, en respuesta, producir resultados tangibles -- Si se satisface, proceder con la siguiente fase, si no repetir esta fase, (o comenzar de una fase previa) - -- Confer with colleagues and the community - - Conferring should be done publicly via ticket, meetings, and/or IRC -- Accept all feedback and, in response, produce tangible results -- If satisfied, proceed with next Fase, else repeat this Fase (or start from a previous Fase) - -## Fase 6: Repetir todo desde el inicio \ No newline at end of file diff --git a/i18n/es/style.md b/i18n/es/style.md deleted file mode 100644 index 155d38f..0000000 --- a/i18n/es/style.md +++ /dev/null @@ -1,68 +0,0 @@ -1. Lee [La guía de estilo de C++ de Google](https://google.github.io/styleguide/cppguide.html) -2. Inicia [cpplint](https://pypi.python.org/pypi/cpplint/) -```bash -$ cpplint src/path/to/my/file -``` -3. Inicia [clang-format](http://llvm.org/releases/3.8.0/tools/clang/docs/ClangFormat.html) con ```-style=file``` usando el [.clang-format](https://github.com/monero-project/kovri/blob/master/.clang-format) -```bash -$ cd kovri/ && clang-format -i -style=file src/path/to/my/file -``` - -## Aquí esta lo que no se acomoda por clang-format y difiera de lo propuesto por el estilo C++ de Google - -- Mantente con la base del código (verticalmente) para tener consistencia -- Las funciones siempre comienzan con una nueva línea para tener consistencia en el código -- Las nuevas líneas en los argumentos de las funciones, deben tener 4 espacios en *todos* los argumentos - -```cpp - /// @brief Constructs SSU header with pre-determined payload type - explicit SSUHeader( - SSUPayloadType type); - - /// @brief Constructs SSU header with pre-determined payload type and content - /// @note Assumes content is valid - /// @param SSUPayloadType SSU payload type - /// @param mac Pointer to header's MAC material - /// @param iv Pointer to header's IV material - /// @param time Header's timestamp - SSUHeader( - SSUPayloadType type, - std::uint8_t* mac, - std::uint8_t* iv, - std::uint32_t time); - - /// @brief Sets MAC from appointed position within header - /// @note Assumes content is valid (based on position) - void SetMAC( - std::uint8_t* mac); - - /// @brief Gets acquired MAC after it has been set when parsed - /// @return Pointer to MAC material - std::uint8_t* GetMAC() const; -``` - -- Las expresiones pueden ser rotas antes de los operadores si: - - La línea es mayor a 80 columnas - - Hacerlo mejora la documentación - -```cpp -if (esta es una expresión muy larga expr1 - && esta es una expresión muy larga expr2 - && esta también es una expresión muy larga expr3) - HazAlgo(); -``` - -```cpp -return SSUPacket::GetSize() - + static_cast(SSUSize::DHPublic) // Y to complete the DH agreement - + 1 + m_AddressSize // 1 byte address size, address size, - + 2 + 4 + 4 // Port size (2 bytes), relay tag size, time size - + m_SignatureSize; // Signature size -``` - -- Las variables miembro de una clases deben iniciar con ```m_``` -- No uses nombres "baratos" en funciones; siempre usa FuncionesConMayusculas() -- No prepongas ```k``` o MACRO_TYPE para todas las constantes -- Usa triple-barra Doxygen ```/// Comentario en C++``` cuando documentes Doxygens -- Documenta todo tu trabajo para Doxygen mientras progresas -- Si el anonimato es una preocupación, mézclalo con la presente guía de contribuidores \ No newline at end of file diff --git a/i18n/es/testnet_guide.md b/i18n/es/testnet_guide.md new file mode 100644 index 0000000..1a99267 --- /dev/null +++ b/i18n/es/testnet_guide.md @@ -0,0 +1,66 @@ +# Comenzar con la testnet de Kovri + +## Preámbulo + +La testnet de Kovri actualmente reside dentro de una serie de contenedores Docker e imágenes que se comunican a través de una sola red Docker. +Esto permite realizar pruebas y monitoreos en redes privadas sin la necesidad de conectarse a la red pública de kovri. + +## Prerrequisitos + +- Entorno de desarrollo Linux (actualmente, Linux es compatible) + - Consulte el [README](https://github.com/monero-project/kovri#building) de kovri para obtener una lista de las dependencias de compilación. +- [Docker](https://www.docker.com/) + - El usuario de compilación debe tener permisos para usar Docker (agregado al grupo de Docker, por ejemplo) +- Clonar el repositorio +```bash +$ git clone --recursive https://github.com/monero-project/kovri +``` + +## Paso 1: Crea el testnet + +Para obtener una lista completa de opciones, ejecute la opción `help`: +```bash +$ ./kovri/contrib/testnet/testnet.sh ayuda +``` +Puede exportar las variables de entorno enumeradas desde su shell o configurarlas manualmente durante la instalación. + +Crea el entorno y establece los valores correctamente: +```bash +$ ./kovri/contrib/testnet/testnet.sh create +``` +- Para los nuevos desarrolladores, se aconseja utilizar los valores predeterminados con la excepción de la ubicación de su repositorio +- Consulte el directorio Dockerfiles para ver los archivos Docker disponibles para compilar durante la configuración +- Para mantener el repositorio Kovri limpio, elija un directorio fuera del repositorio + +## Paso 2a: inicia el testnet + +```bash +$ ./kovri/contrib/testnet/testnet.sh start +``` +Para las opciones de monitoreo, ejecute `help` para obtener detalles sobre cómo monitorear. + +## Paso 2b: ejecutar comandos personalizados + +**TODO (sin asignar): mejore esta sección** + +Para ejecutar comandos desde un contenedor, consulte la documentación de Docker. + +También puedes probar: +```bash +$ ./contrib/testnet/testnet.sh exec "bash" +``` + +## Paso 3: detener el testnet + +```bash +$ ./kovri/contrib/testnet/testnet.sh stop +``` +- Debería aparecer un intervalo de tiempo de espera del contenedor (si env no está configurado) + - Esto es útil en el caso de enrutadores congelados (que no responden) + +## Paso 4: destruir el testnet + +```bash +$ ./kovri/contrib/testnet/testnet.sh destroy +``` +- Debería pedírsele que configure el directorio testnet para que se destruya (si env no se configuró) \ No newline at end of file diff --git a/i18n/es/user_guide.md b/i18n/es/user_guide.md index b87fbe4..103634c 100644 --- a/i18n/es/user_guide.md +++ b/i18n/es/user_guide.md @@ -7,11 +7,21 @@ Notas: -- **No compartas con nadie tu puerto, porque puede comprometer tu anonimato!!** - Si no guardas el puerto, Kovri va a generar uno de forma aleatorio cada vez que se inicie (también puedes elegir pasar el puerto con el parámetro `--port` en cada inicio). - Si no tienes acceso a tu NAT, mira las instrucciones en [Compilando](https://github.com/monero-project/kovri-docs/blob/master/i18n/es/building.md) para tu OS. +- **No compartas con nadie tu puerto, porque puede comprometer tu anonimato!!** + + +## Paso 2. (Recomendado) Seguridad Operacional + +- Considere crear un usuario designado `kovri` y ejecute kovri solo usando ese usuario +- Si usa Linux, considere usar un kernel reforzado (como [grsec](https://en.wikibooks.org/wiki/Grsecurity) con RBAC) +- Después de instalar los recursos apropiados en su ruta de datos kovri, considerando que establecio el control de acceso apropiado con [setfacl](https://linux.die.net/man/1/setfacl), [umask](https://en.wikipedia.org/wiki/Umask), o lo que sea que su sistema operativo use para ACL +- Nunca compartas tu número de puerto con nadie, ya que afectará tu anonimato. -## Paso 2. Configurar Kovri +**Nota: vea kovri.conf para encontrar su ruta de datos para Linux/OSX/Windows** + +## Paso 3. Configurar Kovri, configurar tuneles Para una lista completa de opciones: @@ -30,59 +40,115 @@ Para una lista completa detallada: - `kovri.conf` archivo de configuración del router y cliente - `tunnels.conf` archivo de configuración para cliente/servidor de túneles -## Paso 3. Iniciar Kovri +## Paso 4. (Opcional) Configurar tuneles + +En resumen, *túneles de cliente* son túneles que usted usa para conectarse a otros servicios y *túneles de servidor* se utilizan para cuando usted aloja servicios (y otras personas se conectan a su servicio). + +De forma predeterminada, tendrá túneles de cliente configurados para IRC (Irc2P) y correo electrónico (i2pmail). Para agregar/eliminar túneles de clientes, consulte `tunnels.conf`. + +Al crear túneles de servidor, deberá crear *claves privadas persistentes*. Para hacerlo, descomente o cree `keys = your-keys.dat` y reemplace`your-keys` con un nombre apropiado. **No comparta su archivo `.dat` privado con nadie, ¡y asegúrese de hacer una copia de seguridad!** + +Una vez configurada, su [dirección Base32](https://getmonero.org/resources/moneropedia/base32-address) se mostrará en su registro después de iniciar kovri. También puede encontrar la dirección en un archivo de texto junto con el archivo de claves privadas en su ruta de datos kovri en el directorio `client/keys`. La dirección dentro de este archivo de texto `.txt` es segura de distribuir para que otras personas puedan conectarse a su servicio. + +Ejemplo: + +- Archivo de claves privadas: `client/keys/your-keys.dat` +- Dirección pública [Base32](https://getmonero.org/resources/moneropedia/base32direction)/[Base64](https://getmonero.org/resources/moneropedia/base64-address): `client/keys/your-keys.dat.txt` + +**Nota: vea kovri.conf para encontrar su ruta de datos para Linux / OSX / Windows** + +## Paso 5. (Opcional) Registre su nuevo [eepsite](https://getmonero.org/resources/moneropedia/eepsite) + +**ALTO! Hasta que [#498](https://github.com/monero-project/kovri/issues/498) se resuelva, solo considere registrar su servicio con Kovri y *not* stats.i2p!** + +- Abra una solicitud con `[Solicitud de suscripción] your-host.i2p` (reemplace su-host.i2p con su nombre de host deseado) en el [issue tracker de Kovri](https://github.com/monero-project/kovri/issues) +- En el cuerpo de la solicitud, pegue los contenidos de su archivo público `.txt` que se mencionó en el paso anterior +- Después de la revisión, agregaremos su host y firmaremos la suscripción +- ¡Hecho! + +## Paso 6. Ejecutar Kovri ```bash $ cd build/ && ./kovri ``` +- Espere 5 minutos o más esperar el bootstrap en la red antes de intentar usar los servicios -- Espera 5 minutos o algo más para que quedes inicializado en la red antes de intentar usar los servicios. - -## Paso 4. Únete a nuestro IRC -1. Inicia tu [cliente IRC](https://en.wikipedia.org/wiki/List_of_IRC_clients) -2. Configura tu cliente para conectarse al puerto IRC de Kovri (default 6669). Esto te conectara a la red Irc2p (I2P's IRC network) -3. Únete a `#kovri` y `#kovri-dev` +## Paso 7. Únete a nosotros en IRC +1. Inicie su [Cliente de IRC](https://en.wikipedia.org/wiki/List_of_IRC_clients) +2. Configure su cliente para conectarse al puerto IRC de kovri (predeterminado 6669). Esto lo conectará a la red Irc2P (red IRC de I2P) +3. Únete a `# kovri` y` # kovri-dev` -## Paso 5. Navega una web I2P (garlic-site/eepsite) -1. Inicia el navegador de tu preferencia (preferiblemente uno dedicado al uso de Kovri) -2. Configura tu navegador leyendo [estas instrucciones](https://geti2p.net/en/about/browser-config) **pero en vez del puerto 4444 y 4445** cambia el proxy HTTP al puerto **4446** y puerto SSL *también* a **4446** -3. Visita el [sitio de chequeo](http://check.kovri.i2p) para verificar si funciona +## Paso 8. Navega por un sitio web I2P (garlic-site / eepsite) +1. Inicie un navegador de su elección (preferiblemente un navegador dedicado al uso de kovri) +2. Configure su navegador leyendo [estas instrucciones](https://geti2p.net/en/about/browser-config) **pero en lugar del puerto 4444 y 4445** cambie el puerto proxy HTTP a **4446** y Puerto proxy SSL *también* a **4446** +3. Visite http: //check.kovri.i2p Notas: -- **Así como en TOR, no necesitas SSL para navegar de forma segura la red** -- Soporte de SSL en sitios y proxies de salida aun no está implementado -- Si alguien te da una dirección .i2p que no está en tu cartera de direcciones, usa el servicio de `Jump` en este [sitio](http://stats.i2p/i2p/lookup.html) -- Mira a través de hosts.txt en tu directorio de datos para ver una lista de sitios por defecto que puedes visitar fácilmente -- En general, la implementación del proxy HTTP y cartera de direcciones aun están desarrollo y aun no están completos +- **Al igual que con Tor, no se necesita SSL para usar la red de manera segura.** +- El soporte de sitio SSL y el servicio externo no se implementan actualmente +- Si alguien te da una dirección .i2p que no está en tu libreta de direcciones, utiliza el servicio `Jump` en http: //stats.i2p/i2p/lookup.html +- Busque en hosts.txt en su directorio de datos para ver una lista de sitios predeterminados que puede visitar fácilmente +- En general, la implementación del proxy HTTP y la libreta de direcciones están en desarrollo y aún no cuentan con funciones completas. -## Paso 6. Hostea tu propio servicio-garlic (garlic-site/eepsite) -- Lee `tunnels.conf` para aprender como colocar un servicio túnel que apunte a un servicio que estés hosteando +## Paso 9. ¡Disfruta! +- Lea más sobre Kovri en la [Moneropedia](https://getmonero.org/resources/moneropedia/kovri). +- Abra sus solicitudes de funciones o informe de errores en nuestro [issue tracker](https://github.com/monero-project/kovri/issues) +- Obtenga más información sobre la red I2P en el [sitio web java I2P](https://geti2p.net/en/docs) -## Paso 7. ¡Disfruta! -- Lee más de Kovri en la [Moneropedia](https://getmonero.org/resources/moneropedia/kovri.html). -- Abre una petición de nueva característica, o reporta bugs en nuestro [issues tracker](https://github.com/monero-project/kovri/issues) -- Aprende más de la red I2P en el [sitio de java I2P](https://geti2p.net/en/docs) +# Opciones de contenedor -# Alternativamente, Docker +## Snapcraft -## Paso 1. Instalar Docker -Instalar Docker está fuera del propósito de este documento, por favor lee la [documentación de docker](https://docs.docker.com/engine/installation/) +En sistemas Linux, use snapcraft para una fácil implementación. -## Paso 2. Configurar / Abrir Firewall +### Paso 1. Obtenga el repositorio del codigo de Kovri -La imagen de docker ya viene con la configuración por default de Kovri, pero puedes configurarlo como se explica en secciones anteriores +```bash +$ git clone --recursive https://github.com/monero-project/kovri +``` + +### Paso 2. Instalar snapcraft -Deberías escoger un puerto aleatorio y abrir ese puerto +- Consulte el administrador de paquetes de su distribución para snapcraft y [snapd](https://snapcraft.io/docs/core/install) + +En Ubuntu, simplemente ejecute: +```bash +$ sudo apt-get install snapcraft +``` + +### Paso 3. Crea el snap + +```bash +$ cd kovri / && snapcraft && sudo snap install * .snap --dangerous +``` +Nota: la bandera --dangerous es necesaria solo porque el snap no ha sido firmado (sin embargo, tú mismo lo construiste, así que esto no debería ser un problema) -## Paso 3. Iniciar +### Paso 4. Ejecuta Kovri con snapcraft -### Configuración por defecto ```bash -KOVRI_PORT=42085 && sudo docker run -p 127.0.0.1:4446:4446 -p 127.0.0.1:6669:6669 -p $KOVRI_PORT --env KOVRI_PORT=$KOVRI_PORT geti2p/kovri +$ snap run kovri ``` -### Configuración personalizada -Donde `./kovri-settings/` contiene `kovri.conf` y `tunnels.conf`. +## Docker + +### Paso 1. Instalar Docker +La instalación de Docker está fuera del alcance de este documento, consulte la [documentación de docker](https://docs.docker.com/engine/installation/) + +### Paso 2. Configurar / Abrir el Firewall (contrafuegos) + +La imagen de docker viene con los valores predeterminados de kovri, pero se puede configurar como se explicó en secciones anteriores. + +Debe elegir un puerto aleatorio y abrir ese puerto (ver secciones anteriores). + +### Paso 3. Ejecutar + +#### Configuración por defecto ```bash -KOVRI_PORT=42085 && sudo docker run -p 127.0.0.1:4446:4446 -p 127.0.0.1:6669:6669 -p $KOVRI_PORT --env KOVRI_PORT=$KOVRI_PORT -v kovri-settings:/home/kovri/.kovri/config:ro geti2p/kovri +KOVRI_PORT = 42085 && sudo docker run -p 127.0.0.1:4446:4446 -p 127.0.0.1:6669:6669 -p $ KOVRI_PORT --env KOVRI_PORT = $ KOVRI_PORT geti2p / kovri ``` + +#### Ajustes personalizados +Donde `. / Kovri-settings /` contiene `kovri.conf` y` tunnels.conf`. +```bash +KOVRI_PORT = 42085 && sudo docker run -p 127.0.0.1:4446:4446 -p 127.0.0.1:6669:6669 -p $ KOVRI_PORT --env KOVRI_PORT = $ KOVRI_PORT -v kovri-settings: /home/kovri/.kovri/ config: ro geti2p / kovri +``` \ No newline at end of file