Godot, deja el manto de la SFC y crea su propia fundación independiente 

Fundación Godot

La Fundación Godot se dedica a crear software libre y de código abierto y a garantizar que el trabajo en el proyecto Godot sea sostenible

Hasta hace poco Godot, un motor de video juegos de código abierto, formaba parte de la Software Freedom Conservancy (SFC), como es el caso de muchos proyectos de código abierto, para cumplir con el patrocinio fiscal y otras obligaciones similares.

Y ahora los desarrolladores del motor Godot y la Software Freedom Conservancy, han decidido conjuntamente transferir el proyecto del motor de juego de código abierto a su propia fundación la cual fue creada en los Países Bajos como su propia organización, siguiendo el modelo de las políticas de la SFC. El objetivo es ayudar al motor del juego a alcanzar su próximo nivel de crecimiento y proyectar una imagen más sólida para el proyecto.

Para quienes desconocen de Godot, deben saber que este es un motor de juego 2D y 3D versátil diseñado para soportar todo tipo de proyectos. Puede usarlo para crear juegos o aplicaciones que luego puede transmitir a la computadora de escritorio o al dispositivo móvil, así como a la web. Ejemplos de juegos hechos con Godot incluyen Ex-Zodiac y Helms of Fury.

“Acabamos de iniciar el proceso de transferencia a la Fundación. Por ahora, toda la financiación y los contratos de Godot siguen siendo gestionados por la SFC. La SFC reducirá gradualmente sus inversiones para permitir que la nueva fundación tome impulso”, dice el equipo a cargo de Godot.

Por la parte de la Software Freedom Conservancy, esta es una organización sin fines de lucro centrada en la ética tecnológica. Su misión es garantizar el derecho a reparar, mejorar y reinstalar el software. “Promovemos y defendemos estos derechos fomentando proyectos de software libre y de código abierto, liderando iniciativas que hacen que la tecnología sea más inclusiva y promoviendo estrategias de políticas que defienden el software libre y de código abierto (como el copyleft).

«Software Freedom Conservancy y los líderes de Godot se complacen en compartir su decisión de que el proyecto Godot ha alcanzado un nivel de éxito en el que tiene sentido que Godot tenga su propia fundación independiente», dijo Juan Linietsky, miembro del equipo de desarrollo de Godot, en una publicación de blog. publicado el 1 de noviembre.

El SFC era un socio ideal para Godot, ya que funciona como una estructura sin fines de lucro para varios proyectos de software libre y de código abierto de alto perfil (como Git, Samba, Wine, etc.) y tienen reglas probadas para garantizar que las donaciones no se utilicen solo en beneficio de los proyectos, así como reglas para evitar conflictos de interés. Permiten que los proyectos de código abierto crezcan, prosperen y se concentren en su proyecto, mientras que la SFC se ocupa de los asuntos de gobernanza, contabilidad y legales (incluida la anulación exitosa de los acuerdos de confidencialidad); esencialmente reuniendo el trabajo necesario para operar una organización sin fines de lucro.

El equipo de Godot no puede proporcionar exportación de consola de código abierto debido a los términos de licencia impuestos por los fabricantes de consolas. Independientemente del motor utilizado, lanzar juegos en consolas siempre es mucho trabajo.

Si bien no es cosa de todos, es posible codificar los juegos usando GDScript, un lenguaje estrechamente integrado y específico de Godot con una sintaxis liviana, o C#, que es popular en la industria del juego. Estos son los dos principales lenguajes de scripting soportados por Godot. Godot también admite un lenguaje de programación visual llamado VisualScript.

Con la tecnología GDNative, también es posible escribir juegos o algoritmos de alto rendimiento en C o C++ sin volver a compilar el motor. Es posible utilizar esta tecnología para integrar bibliotecas de terceros y otros kits de desarrollo de software (SDK) en el motor. Por supuesto, también es posible agregar módulos y funcionalidades directamente al motor.

En general, los responsables del proyecto Godot están “tremendamente agradecidos y orgullosos de haber sido parte de Software Freedom Conservancy.

Godot se unió a SFC cuando el proyecto aún estaba en pañales y sus necesidades eran bastante limitadas. Hoy, el proyecto Godot es mucho más grande, emplea a muchas personas y sus necesidades y aspiraciones son más complejas. Por lo tanto, a medida que el proyecto continúa creciendo aún más, solo tendría sentido que ella tuviera el control, la independencia y la flexibilidad en la administración de fondos de una organización que se enfoca únicamente en Godot.

Por esta razón, el Comité Directivo del Proyecto Godot (el PLC) y la SFC acordaron que era hora de que el Proyecto Godot dejara su sede en la SFC y formara su propia organización: la Fundación Godot. Como muchos otros proyectos de código abierto (Blender y Krita, por ejemplo), la Fundación estará ubicada en los Países Bajos. La estructura de la Fundación sigue el modelo de las políticas de la SFC, lo que garantizará la continuidad en la forma en que opera Godot.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/Uf0B7vC
via IFTTT

Descubrieron que pueden introducir paquetes maliciosos en AUR mediante dominios caducados

vulnerabilidad

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco dieron a conocer mediante una publicación de blog los resultados de un experimento, en el cual demuestran como se puede tomar el control de los paquetes en el repositorio AUR.

Para quienes desconocen de AUR (Arch User Repository), deben saber que este es un repositorio de software para Arch Linux. Se diferencia de los repositorios oficiales de Arch Linux, ya que en este sus paquetes son proporcionados por sus usuarios y Arch Linux no los admite oficialmente.

AUR es utilizado por desarrolladores externos para distribuir sus paquetes sin estar incluidos en los repositorios principales de la distribución Arch Linux.

En este, se realizó una investigación debido a la falta de soporte, que es más una característica que un error, ya que permite que AUR contenga paquetes que son difíciles de soportar (por ejemplo, debido a problemas de licencia) o que solo son utilizados por un puñado de usuarios.

Sin embargo, la falta de soporte también significa menos control de calidad, lo que permite a los malos actores introducir paquetes maliciosos. Para advertir a los usuarios de este riesgo, AUR tiene un gran descargo de responsabilidad en la página principal (una leyenda que muchos ignoran o simplemente desconocen):

ESCARGO DE RESPONSABILIDAD: Los paquetes AUR son contenido producido por el usuario. Cualquier uso de los archivos proporcionados es bajo su propio riesgo.

Sobre el experimento realizado, los investigadores prepararon un script que comprueba la caducidad del registro de los dominios que aparecen en los archivos PKGBUILD y SRCINFO. La ejecución de este script identificó 14 dominios caducados utilizados en 20 paquetes de carga de archivos.

Con ello, pudieron identificar que hay varias formas de introducir un paquete malicioso (o cambios maliciosos en un paquete legítimo) en AUR. Por ejemplo, convirtiéndose en el mantenedor de paquetes huérfanos (es decir, paquetes que ya no son compatibles con sus mantenedores anteriores) o escribiendo nombres de paquetes populares.

Otra opción es encontrar paquetes que utilicen URL con dominios caducados durante su proceso de creación, registrar el dominio y alojar archivos maliciosos. ¿Cuántos de los paquetes son vulnerables a tal ataque? ¡Vamos a averiguar!

Se menciona que el proceso no es tan simple como se pudiera tener en cuenta, ya no basta simplemente con registrar un dominio, ya que esto no es suficiente para falsificar el paquete, pues el contenido descargado se compara con la suma de verificación ya cargada en AUR. Sin embargo, los mantenedores de alrededor del 35% de los paquetes en AUR parecen usar el parámetro «SKIP» en el archivo PKGBUILD para omitir la verificación de la suma de control (por ejemplo, especifique sha256sums=(‘SKIP’)). De los 20 paquetes con dominios vencidos, en 4 se utilizó el parámetro SKIP.

Para demostrar la posibilidad de cometer un ataque, los investigadores compraron el dominio de uno de los paquetes que no verifican las sumas de verificación y colocaron un archivo con el código y un script de instalación modificado.

Desafortunadamente, no existe una forma estandarizada de verificar si un dominio está disponible. Las respuestas de WHOIS de los TLD más populares contienen algo como «No coincide con el dominio» para los dominios disponibles, pero esto no es cierto para todos los TLD. Un buen primer paso es filtrar cualquier dominio que tenga un Aconjunto de registros DNS, ya que esos dominios (lo más probable) todavía estarán en uso. Para realizar rápidamente muchas solicitudes de DNS, usamos blechschmidt/massdns . Esta es una gran herramienta que nos permite resolver miles de dominios en segundos

En lugar del contenido real, se ha agregado al script una advertencia sobre la ejecución de código de terceros. Un intento de instalar el paquete condujo a la descarga de archivos falsificados y, dado que no se verificó la suma de verificación, a la instalación y ejecución exitosas del código agregado por los experimentadores.

Finalmente se menciona que el secuestro de paquetes AUR no es un concepto nuevo, ya que el secuestro de paquetes AUR siempre ha sido posible (de múltiples maneras) y es un riesgo conocido.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/29MItDJ
via IFTTT