BRL-CAD

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia en la página de su proyecto. El estado de la insignia se ve así: El nivel de insignia para el proyecto 66 es passing Aquí se explica cómo insertarla:
Puede mostrar el estado de su insignia insertando esto en su archivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/66/badge)](https://www.bestpractices.dev/projects/66)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/66"><img src="https://www.bestpractices.dev/projects/66/badge"></a>


Estos son los criterios de nivel Básico. También puede ver los criterios de nivel Plata o Oro.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos 13/13 ●

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

    BRL-CAD is an open source solid modeling system with interactive 3D geometry editing, high-performance ray tracing for rendering, hybrid representation geometry conversion, and processing for geometric analysis.

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

  • Contenido básico del sitio web del proyecto


    ¡Suficiente para una insignia!

    El sitio web del proyecto DEBE describir sucintamente qué hace el software (¿qué problema resuelve?). [description_good]
    Esto DEBE estar en un lenguaje que los usuarios potenciales puedan entender (por ejemplo, utiliza jerga mínima).

    http://brlcad.org


    ¡Suficiente para una insignia!

    El sitio web del proyecto DEBE proporcionar información sobre cómo: obtener, proporcionar comentarios (como informes de errores o mejoras), y contribuir al software. [interact]

    http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/HACKING


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBE explicar el proceso de contribución (por ejemplo, ¿se utilizan "pull requests" en el proyecto?) (URL requerida) [contribution]
    Se asume que los proyectos en GitHub usan "incidencias" y "pull requests" a menos que se indique lo contrario. Esta información puede ser breve, por ejemplo, indicando que el proyecto utiliza "pull requests", un gestor de incidencias o publicaciones en una lista de correo (Indíquese cuál)

    http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/HACKING


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBERÍA incluir los requisitos para las contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). (URL requerida) [contribution_requirements]

    http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/HACKING


  • Licencia FLOSS


    ¡Suficiente para una insignia!

    El software producido por el proyecto DEBE ser publicado como FLOSS. [floss_license]
    FLOSS es software publicado de una manera que cumple con la Definición de Código Abierto o la Definición de Software Libre. Ejemplos de tales licencias incluyen CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Para nuestros propósitos, esto significa que la licencia DEBE ser: El software PUEDE también estar licenciado de otras maneras (por ejemplo, "GPLv2 o propietario" es aceptable).

    http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/COPYING


    ¡Suficiente para una insignia!

    Se SUGIERE que cualquier licencia(s) requerida(s) para el software producido por el proyecto sea aprobada por la Open Source Initiative (OSI). [floss_license_osi]
    La OSI utiliza un proceso de aprobación riguroso para determinar qué licencias son OSS.

    ¡Suficiente para una insignia!

    El proyecto DEBE publicar la(s) licencia(s) de sus resultados en una ubicación estándar en su repositorio de código fuente. (URL requerida) [license_location]
    Una convención es publicar la licencia como un archivo de nivel superior llamado LICENSE o COPYING, que PUEDE ser seguido por una extensión como ".txt" o ".md". Una convención alternativa es tener un directorio llamado LICENSES que contenga archivo(s) de licencia; estos archivos generalmente se nombran según su identificador de licencia SPDX seguido de una extensión de archivo apropiada, como se describe en la Especificación REUSE. Tenga en cuenta que este criterio es solo un requisito para el repositorio de código fuente. NO necesita incluir el archivo de licencia al generar algo desde el código fuente (como un ejecutable, paquete o contenedor). Por ejemplo, al generar un paquete R para el Comprehensive R Archive Network (CRAN), siga la práctica estándar de CRAN: si la licencia es una licencia estándar, use la especificación de licencia corta estándar (para evitar instalar otra copia del texto) y liste el archivo LICENSE en un archivo de exclusión como .Rbuildignore. De manera similar, al crear un paquete Debian, puede poner un enlace en el archivo de derechos de autor al texto de la licencia en /usr/share/common-licenses, y excluir el archivo de licencia del paquete creado (por ejemplo, eliminando el archivo después de llamar a dh_auto_install). Alentamos a incluir información de licencia legible por máquina en formatos generados cuando sea práctico.

    http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/COPYING
    http://svn.code.sf.net/p/brlcad/code/brlcad/trunk/doc/legal/


  • Documentación


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar documentación básica para el software producido por el proyecto. [documentation_basics]
    Esta documentación debe estar en algún medio (como texto o video) que incluya: cómo instalarlo, cómo iniciarlo, cómo usarlo (posiblemente con un tutorial usando ejemplos), y cómo usarlo de manera segura (por ejemplo, qué hacer y qué no hacer) si eso es un tema apropiado para el software. La documentación de seguridad no necesita ser larga. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. Si el proyecto no produce software, elija "no aplicable" (N/A).

    http://brlcad.org/wiki/Documentation


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar documentación de referencia que describa la interfaz externa (tanto entrada como salida) del software producido por el proyecto. [documentation_interface]
    La documentación de una interfaz externa explica a un usuario final o desarrollador cómo usarla. Esto incluiría su interfaz de programación de aplicaciones (API) si el software tiene una. Si es una biblioteca, documente las clases/tipos principales y los métodos/funciones que se pueden llamar. Si es una aplicación web, defina su interfaz URL (a menudo su interfaz REST). Si es una interfaz de línea de comandos, documente los parámetros y opciones que admite. En muchos casos es mejor si la mayor parte de esta documentación se genera automáticamente, de modo que esta documentación permanezca sincronizada con el software a medida que cambia, pero esto no es obligatorio. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. La documentación PUEDE generarse automáticamente (donde sea práctico, esta es a menudo la mejor manera de hacerlo). La documentación de una interfaz REST puede generarse usando Swagger/OpenAPI. La documentación de la interfaz del código PUEDE generarse usando herramientas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), y Doxygen (muchos). Simplemente tener comentarios en el código de implementación no es suficiente para satisfacer este criterio; necesita haber una manera fácil de ver la información sin leer todo el código fuente. Si el proyecto no produce software, elija "no aplicable" (N/A).

    http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf


  • Otro


    ¡Suficiente para una insignia!

    Los sitios del proyecto (sitio web, repositorio y URLs de descarga) DEBEN admitir HTTPS usando TLS. [sites_https]
    Esto requiere que la URL de la página de inicio del proyecto y la URL del repositorio de control de versiones comiencen con "https:", no "http:". Puede obtener certificados gratuitos de Let's Encrypt. Los proyectos PUEDEN implementar este criterio usando (por ejemplo) GitHub pages, GitLab pages, o SourceForge project pages. Si admite HTTP, le instamos a redirigir el tráfico HTTP a HTTPS.

    https://brlcad.org
    https://svn.code.sf.net/p/brlcad/code/brlcad/trunk
    https://sourceforge.net/projects/brlcad/files/
    https://github.com/BRL-CAD


    ¡Suficiente para una insignia!

    El proyecto DEBE tener uno o más mecanismos para la discusión (incluyendo cambios propuestos y problemas) que sean buscables, permitan que los mensajes y temas sean direccionables mediante URL, permitan que nuevas personas participen en algunas de las discusiones y no requieran la instalación del lado del cliente de software propietario. [discussion]
    Ejemplos de mecanismos aceptables incluyen listas de correo archivadas, discusiones de issues y pull requests de GitHub, Bugzilla, Mantis y Trac. Los mecanismos de discusión asíncrona (como IRC) son aceptables si cumplen con estos criterios; asegúrese de que haya un mecanismo de archivo direccionable por URL. JavaScript propietario, aunque desaconsejado, está permitido.

    https://sourceforge.net/projects/brlcad/support


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA proporcionar documentación en inglés y ser capaz de aceptar informes de errores y comentarios sobre el código en inglés. [english]
    El inglés es actualmente la lengua franca de la tecnología informática; el soporte del inglés aumenta el número de diferentes desarrolladores y revisores potenciales en todo el mundo. Un proyecto puede cumplir con este criterio incluso si el idioma principal de sus desarrolladores principales no es el inglés.

    http://brlcad.org/wiki/Documentation
    https://sourceforge.net/projects/brlcad/support


    ¡Suficiente para una insignia!