2023, un año que con mucho movimiento para el open source

año 2024

Este 2023 represento un año con bastantes cambios, eventos importantes y destacados en el open source. Entre los tantos acontecimiento, novedades, lanzamientos, actualizaciones, sucesos, entre otras cosas, este artículo es una recopilación de todos esos eventos y noticias que considero fueron las más relevantes y de las cuales muchas de ellas hablamos aquí en el blog y en los otros blogs dónde también público.

Cabe mencionar que he tardado un poco en compartir el artículo, por diferentes cuestiones, pero considero que es un artículo bastante esencial que nos permite hacer un reencuentro de los hechos del 2023 en el mundo del open source.

Eventos y acontecimientos del 2023

De manera inicial y sin dudas, creo yo que el 2023 fue un año en el cual Red Hat dio mucho de que hablar y es que durante todo el año Red Hat se dedicó a realizar una gran cantidad de cambios que genero tanto criticas, como también la división de la comunidad. Y es que entre los cambios más importantes que realizo Red Hat fueron el cambio de CentOS Stream como la única fuente de RHEL, con lo cual básicamente dejo de publicar el código del paquete en el repositorio Git de CentOS y que genero una gran cantidad de críticas tanto de la comunidad, desarrolladores y también de Oracle, la SFC, entre otros.

Este movimiento género que distribuciones como AlmaLinux y Rocky Linux anunciaran cambios en sus procesos y que Oracle por su cuenta continuará distribuyendo el código fuente de su distribución Oracle Linux de forma gratuita y lo hará compatible con versiones anteriores de RHEL. Posterior a ello, SUSE también quiso colgarse del conflicto generado por RHEL y junto con Rocky Linux y Oracle crearon un repositorio compatible con RHEL y anuncio la creación de su propia bifurcación de RHEL.

Además de ello, en el 2023 Red Hat despidió y elimino el puesto de gerente de programas de Fedora, anunció el cese de la compilación de paquetes rpm con LibreOffice para RHEL y Fedora, asi como también anuncio la transición hacia Wayland y eliminado el servidor X.org y los componentes relacionados en RHEL.

Otro de los sucesos más relevantes desde 2023 fue la transición de muchos proyectos y distribuciones hacia Wayland, que claro no es un movimiento específico que se generó en el 2023, pero como tal el 2023 represento el punto de no retorno de migrar de X.org a Wayland, ya que desde indios del 2023 por ejemplo en Wine ya se anunciaba la promoción del soporte de Wayland para brindar la capacidad de usar Wine en entornos basados ​​​​en el protocolo Wayland sin el uso de componentes XWayland y X11, asi como también la transición de Lubuntu a Qt 6 y Wayland y en general el movimiento de comenzar a dar fin al soporte X11 en GNOME, KDE, Cinnamon, Fedora, Ubuntu, Raspberry OS entre otros, asi como también por parte de aplicaciones, tales como JetBrains en IntelliJ y OpenJDK IDE.

Por su parte, Google también dio mucho que hablar y es que el gigante se ganó una oleada de críticas en su intento de promover la API Web Integrity y su eliminación de Chromium en respuesta a los temores de la aparición de algo como DRM para la Web, asi como también la reciente resolución de litigios relacionados con violaciones de privacidad al “engañar” a los usuarios al hacerlos creer que no rastrearía la actividad en el modo incógnito.

Pero no todo el 2023 fue malo para Google, ya que el gigante de las búsquedas también realizo diversos aportes al open source que merecen ser mencionados en este articuló, ya que libero Buzzer el marco eBPF Fuzzing, la implementación de Passkeys, asi como también el envío una propuesta para Linux para mejorar la transferencia de datos de red entre dispositivos, la liberación de su tecnología de transferencia de datos Falcony el lanzamiento de su sistema de software y hardware Open Se Cura.

Por último y no menos importante, también Google lanzo durante todo el 2023 las versiones de Chrome/Chromium desde la versión 110 hasta la versión 120 con los respectivos lanzamientos de Chrome OS y sobre todo el lanzamiento de Android 14.

Finalmente, debo mencionar que esto no es todo y como mencione solo es una pequeña recopilación de los eventos más sonados. Por lo que en un próximo artículo le estaré dando continuidad.

from Desde Linux https://ift.tt/28gnu6z
via IFTTT

GitHub volvió a hacer de las suyas y su nueva víctima, el repositorio de OpenXRay

OpenXRay es una versión mejorada de X-Ray Engine, el motor de juego utilizado en la mundialmente famosa serie de juegos STALKER

Desde que Microsoft adquirió GitHub, el proceso de bloqueo de repositorios se ha vuelto una burla, pues tal parece que cualquier persona con una solicitud bien elaborada, puede enviarla para solicitar el bloqueo hasta eliminación de un repositorio, es que las personitas a cargo de esta área en GitHub no hacen bien su trabajo.

Y es que desde dicha adquirió, hemos compartido aquí en el blog algunos de los casos más sonados en la red sobre el bloqueo de X repositorio de GitHub, que por mencionar uno de los que más hemos compartido es el del repositorio de youtube-dl y que en teoría desde el 2020, GitHub prometió trabajar para evitar bloqueos irrazonables, lo cual solo se quedo en promesas o al menos eso es lo que ha demostrado.

La razón de hablar de ello, es que hace poco el repositorio del proyecto abierto OpenXRay sufrió de un bloqueo de por parte de GitHub, esto debido a que GitHub recibió una solicitud de reclamación de derechos de autor, en la cual, la supuesta solicitud se mencionaba información sobre la violación de DMCA en nombre de la empresa GSC Game World, enviada por la división de protección antipiratería, actuando en interés de GSC, en la cual básicamente argumentaban que el proyecto OpenXRay viola los derechos de GSC.

Para poner en un poco del contexto a quienes desconocen de OpenXRay, deben saber que este es un proyecto que reproduce el motor del juego para las primeras partes del juego STALKER. Como tal, el proyecto nació después de una filtración de los códigos fuente del motor STALKER y como tal, el proyecto no es una copia «mas», pues a pesar de tener su base sobre el código fuente filtrado, podemos decir que es una versión mejorada, pues ha implementado correcciones en las deficiencias originales, ha introducido nuevas características, como soporte para plataformas de 64 bits, Linux y OpenGL, entre otras cosas más.

Ahora ya mencionado esto, muchos podrían entender el porqué de la «supuesta» solicitud, por parte de GSC Game World , que desarrolló la serie de juegos STALKER. En la cual se menciona que el repositorio contiene materiales obtenidos mediante ingeniería inversa que viola los derechos de autor y términos de uso.

Aviso de infracción de derechos de autor

Estimado github.com:

Yo, [privado] de Protección Antipiratería, me comunico con usted en nombre de GSC GAME WORLD GLOBAL LTD. Bajo pena de perjurio, certifico que estoy autorizado a actuar en nombre de GSC GAME WORLD GLOBAL LTD, el propietario de los derechos exclusivos sobre el juego de ordenador STALKER.

Una búsqueda ha detectado que su sitio web, github.com, proporciona acceso a archivos que infringen los derechos exclusivos de GSC GAME WORLD GLOBAL LTD sobre el juego de computadora STALKER. Creo de buena fe que el contenido de GSC GAME WORLD GLOBAL LTD que se describe anteriormente tiene no ha sido autorizado para su uso, publicación, intercambio o distribución en github.com por parte de GSC GAME WORLD GLOBAL LTD, su agente o la ley. Por lo tanto, le solicito que actúe con prontitud para eliminar o deshabilitar el acceso al contenido infractor identificado en este aviso, y que cese y desista de cualquier infracción adicional de las propiedades de GSC GAME WORLD GLOBAL LTD.

Afirmo que la información contenida en este aviso es precisa a mi leal saber y entender.

Propiedad GSC GAME WORLD GLOBAL LTD infringida:

Esta solicitud, no solo sorprendió a los desarrolladores dé OpenXRay, sino a también toda la comunidad, pues hasta cierto punto se tenía entendido un «acuerdo no firmado» (por asi llamarlo) pues siempre ha estado en duda, que GSC conocía el proyecto, pero no interfirió con su desarrollo, ya que para usar OpenXRay, se requieren recursos del juego de STALKER, que se puede obtener mediante la compra del juego original.

El repositorio estuvo bloqueado durante algunos días, hasta que en una actualización posterior, el Twitter oficial de GSC negó la iniciativa del bloqueo, indicando que la solicitud era falsa. Aseguran respaldo al proyecto OpenXRay y prometen investigar la situación, destacando que no es el primer intento de bloqueo de recursos de terceros no relacionados con la empresa.

Posterior a ello, GitHub anunció que levantaría el bloqueo tras una «verificación adicional», que mostraba que la solicitud se envió de manera fraudulenta y en la cual los desarrolladores del motor expresaron su agradecimiento a «GSC  por la rápida respuesta».

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

from Desde Linux https://ift.tt/YumwXWM
via IFTTT

Snoop 1.4 llega con mas sitios de búsqueda, mejoras de optimización y mas

Snoop es un trabajo de investigación (base de datos propia / bugbounty cerrado) en el campo de la búsqueda y procesamiento de datos públicos en Internet.

Hace pocos días se dio a conocer el lanzamiento de la nueva versión de Snoop 1.4, versión en la cual se ha implementado diversas mejoras de las cuales se destaca la que búsqueda se ha expandido a más sitios, se ha añadido más información a la CLI, se han integrado mejoras para Android y más.

El programa analiza varios sitios, foros y redes sociales para detectar la presencia del nombre de usuario que está buscando, es decir, le permite al usuario poder determinar en qué sitios hay un usuario con el apodo especificado.

El código está escrito en Python y se distribuye bajo una licencia que restringe el uso únicamente para uso personal. Al mismo tiempo, el proyecto es una rama del código base del proyecto Sherlock, suministrado bajo la licencia MIT (la bifurcación se creó debido a la imposibilidad de expandir la base de datos del sitio).

Actualmente, Snoop rastrea la presencia de un usuario en 2700 recursos de Internet en la versión completa y en los recursos más populares en la versión Demo.

Principales novedades de Snoop 1.4

En esta nueva versión que se presenta de Snoop 1.4 se destaca la ampliación de la base de datos, pues en este lanzamiento la lista de sitios de búsqueda se ha ampliado a 3716, lo que mejora la cobertura y la precisión de las búsquedas, se han implementado mejoras en el inicio en equipos antiguos con Windows/HDD y junto con ello también se destaca que se trabajó en la aceleración de la búsqueda, pues se ha logrado una aceleración del 140%. La velocidad de búsqueda por nombre de usuario en la base de datos completa de Snoop en el modo rápido ahora toma menos de 1 minuto, especialmente con una conexión a internet de al menos 12 Mbit/s.

Otro de los cambios que se destaca de esta nueva versión de Snoop 1.4  es la detección automática de codificaciones, ya que se ha agregado un nuevo algoritmo inteligente para la detección automática de codificaciones en sitios claramente no especificados, problemáticos o confusos al realizar búsquedas en varios modos.

También podremos encontrar que el contenido de la información de la CLI se ha ampliado al buscar en una base de datos reducida usando opciones de filtro, como ‘–site’, ‘–exclude’ o ‘–include’. Se muestra el número de sitios web al restringir la búsqueda entre corchetes a la derecha del número total de sitios en la base de datos.

Se han implementado mejoras en el informe HTML, como cambios en los estilos de los botones, líneas resaltadas y ampliadas en la lista de sitios al pasar el cursor, y una mayor visualización de títulos de bandas sonoras al pasar el cursor sobre ellos.

Además de ello, también se destacan las actualizaciones de complementos, pues en el complemento ‘ReverseVgeocoder’, la escala de cobertura/precisión en ubicaciones se ha incrementado entre 10 y 100 veces, se han añadido funciones como cambiar para filtrar datos por país, gráficos con estadísticas sobre países, regiones, objetos y proveedores, y nuevas capas como mapas topográficos, entre otros.

En Android, la búsqueda en modo verbalización se ha acelerado ligeramente, y se han activado todos los estilos al abrir informes HTML manualmente desde la GUI de FM, asi como también que se ha mejorado el formato de la información en la CLI para terminales pequeños o comprimidos, como por ejemplo en Termux.

De los demás cambios que se destacan:

• Se corrigió la prueba automática de red en el modo de verbalización ‘–verbose/-v’ cuando las pruebas a veces fallaban debido a una falla.
• Los complementos ‘GEO_IP/domain’ y ‘ReverseVgeocoder’ han sido actualizados, y se ha ampliado la visualización de datos en informes HTML en versiones completas de Snoop.
• Se han eliminado las notificaciones sonoras sobre errores y finalización de búsqueda de la CLI.
• Se han agregado versiones ligeras a la versión completa de Snoop, permitiendo un inicio casi instantáneo del software.

Si quieres conocer más al respecto debes saber que el proyecto se desarrolló sobre la base del trabajo de investigación en el campo del raspado de datos públicos, puedes consultar los detalles en el siguiente enlace.

Obtener Snoop

Finalmente para quienes estén interesados en poder obtener la herramienta, deben saber que se ofrecen compilaciones preparadas para Linux y Windows.

Para el caso de los que somos usuarios de Linux, podemos obtener Snoop de una forma bastante sencilla, solo debemos abrir una terminal y teclear:

git clone https://github.com/snooppr/snoop
cd ~/snoop

Y podremos instalar las dependencias con:

pip install --upgrade pip
python3 -m pip install -r requirements.txt

Y para conocer más al respecto sobre el funcionamiento de Snoop basta con teclear:

snoop -h

from Desde Linux https://ift.tt/XUVL0Oq
via IFTTT

Maestro, un kernel y un OS similar a Unix escrito desde cero en Rust

screenshot de Maestro

Rust ha ganado suficiente popularidad a tal grado de que se ha convertido en uno de los elegidos para integrarse como lenguaje secundario en Linux, asi como también en otros sistemas operativos, tal es el caso de Android, que ya cuenta con parte de código en Rust, Windows que también le ha dado el visto bueno, entre otros.

Rust ha demostrado ser un lenguaje robusto y que ha generado tal confianza que incluso se han creado ya algunos sistemas operativos con este lenguaje de programación y solo por mencionar algunos tenemos a Redox, también tenemos a Kernels escritos desde cero como por ejemplo Kerla o el Kernel utilizado en el satélite que recientemente lanzo china.

La razón de mencionar esto, es que hace poco me encontré con una noticia que llamo mi atención y es que se presentó un proyecto en el cual se desarrolla un Kernel escrito en Rust y el cual es parcialmente compatible con Linux.

El nombre de este proyecto es «Maestro» y como se mencionó, es un kernel similar a Unix escrito en Rust implementando un subconjunto de llamadas al sistema del kernel de Linux suficientes para crear entornos de trabajo estándar. Como tal, el proyecto de «Maestro» no es algo nuevo, pues el desarrollador menciona que el proyecto nació en el año 2018, pero en ese momento estaba escrito en C y por las diferentes bondades y características de Rust, el proyecto fue reescrito desde cero.

En la página del proyecto se describen las razones del cambio:

En ese momento decidí cambiarme a Rust (mi primer proyecto en este lenguaje), lo que representó varias ventajas:

• Reinicie el proyecto desde el principio, utilizando las lecciones aprendidas de errores anteriores.
• Sea un poco más innovador que simplemente escribir un kernel similar a Linux en C. Después de todo, simplemente use Linux en ese momento.
• Utilice la seguridad del lenguaje Rust para aprovechar algunas dificultades de la programación del kernel. El uso del sistema de escritura de Rust permite transferir parte de la responsabilidad sobre la seguridad de la memoria del programador al compilador.

En el desarrollo del kernel, la depuración es muy difícil por varias razones:

• La documentación suele ser difícil de encontrar y las implementaciones del BIOS pueden tener fallas (más a menudo de lo que cree).
• Al arrancar, el kernel tiene acceso total a la memoria y puede escribir donde no debería (su propio código, por ejemplo).
• Solucionar problemas de pérdidas de memoria no es fácil. No se pueden utilizar herramientas como valgrind.
• gdb se puede usar con QEMU y VMWare , pero el kernel puede tener un comportamiento diferente cuando se ejecuta en un emulador o máquina virtual diferente. Además, es posible que esos emuladores no sean compatibles con gdb (por ejemplo, VirtualBox ).
• Faltan algunas funciones en el soporte para gdb en QEMU o VMWare y gdb puede incluso fallar en ocasiones

En relación con las características del proyecto, se destaca que el Kernel es monolítico y actualmente solo es compatible con sistemas x86 en modo de 32 bits. La base del código del kernel abarca cerca de 49 mil líneas, siendo ejecutable tanto en hardware real como en entornos virtualizados, como QEMU o VirtualBox.

En el desarrollo actual de «Maestro», se han implementado el 31% (135 de 437) de las llamadas al sistema Linux. Esto es suficiente para cargar un entorno de consola basado en Bash y la biblioteca C estándar Musl. Además, el entorno basado en Maestro puede ejecutar algunas utilidades de la suite GNU coreutils y una paquetería básica de cualquier sistema Unix. Actualmente, se está trabajando en la implementación de una pila de red y también se está trabajando en el desarrollo de un servidor X11, un administrador de paquetes, un cargador de arranque, un instalador y otras utilidades esenciales para construir un sistema operativo.

Entre las funciones disponibles de Maestro se destacan las siguientes::

• Controladores para teclado y terminal PS/2 con modo texto y soporte parcial para secuencias ANSI.
• Sistema de asignación de memoria con soporte para memoria virtual.
• Programador de tareas basado en el algoritmo round-robin con soporte para señales POSIX.
• Definición de dispositivos PCI.
• Controlador IDE/PATA.
• Sistema de archivos Ext2.
• Soporte para sistemas de archivos virtuales /tmp y /proc.
• Capacidad para montar particiones de disco FS, MBR y GPT.
• Soporte de initramfs.
• Controlador RTC para temporizador y hora precisa.
• Soporte para cargar módulos del kernel.
• Capacidad para ejecutar archivos ejecutables en formato ELF.

Para los interesados en poder conocer un poco más sobre el proyecto, pueden consultar los detalles en el siguiente enlace.  En cuanto a los interesados en el código del proyecto, deben saber que este se distribuye bajo la licencia MIT. 

from Desde Linux https://ift.tt/sGTlgRu
via IFTTT

ChromeOS 120 llega con nuevas funciones para Chromebooks, mejoras y mas

ChromeOS​ es un sistema operativo basado en Linux diseñado por Google

Google dio a conocer hace poco la liberación de la nueva versión de «ChromeOS 120» en el canal estable y este nuevo lanzamiento llega cargado de una serie de características importantes, grandes mejoras y más.

Para quienes desconocen de Chrome OS, deben saber que el sistema está basado en el kernel de Linux, las herramientas de compilación ebuild/portage, los componentes abiertos y el navegador web Chrome

Principales novedades de Chrome OS 120

Sin dudas, uno de los aspectos más destacados de ChromeOS 120 es la nueva función «Self Share» para compartir archivos entre múltiples dispositivos del mismo usuario. Gracias a esta funcionalidad, los usuarios pueden transferir archivos automáticamente entre todos sus dispositivos conectados a la misma cuenta de Google. La recepción de datos se confirma automáticamente en todos los dispositivos Android o ChromeOS que estén vinculados a la misma cuenta de Google, incluso si la pantalla del dispositivo está apagada. La función se puede habilitar en «chrome://flags/#nearby-sharing-self-share»

Otro de los cambios que se destaca de ChromeOS 120, es el nuevo botón de «escritorio virtual» en la barra de tareas, para cambiar rápidamente entre escritorios virtuales, crear un nuevo escritorio, evaluar visualmente el contenido de los escritorios y agruparlos.

Además de ello, se destaca una nueva página » Personalizar teclas del teclado » que permite «Seleccionar un atajo para cada acción», eliminar, avanzar o retroceder página, finalizar, inicio e insertar, así como la capacidad de habilitar/usar F11 y F12 mediante combinaciones de teclas predefinidas.

También podremos encontrar una característica que nos muestra todos los detalles relevantes sobre las aplicaciones en «Configuración > Aplicaciones > Administrar tus aplicaciones» en la cual se muestra una nueva sección en la parte inferior de cada una que resalta donde se instaló la aplicación y qué tipo de aplicación es. Ya sea una aplicación de Android de Play Store, una aplicación web del sistema, una aplicación web que instaló a través de Chrome o una PWA de Google Play Store.

Por otra parte, la herramienta de captura de pantalla de ChromeOS recibió una actualización, con lo cual ahora, el usuario puede emplear fácilmente la función de arrastrar y soltar inmediatamente después de tomar una captura de pantalla, lo cual es más conveniente que pegar una captura de pantalla de manera convencional.

De los demás cambios que se destacan:

• Se ha propuesto un nuevo diseño de interfaz para ingresar Emoji y GIF animados.
• En las ventanas PIP se agregó el gesto de “pellizco” para ampliar o disminuir el tamaño de las ventanas flotantes con un simple movimiento.
• La compatibilidad con el códec de vídeo MPEG4 Parte 2 y el contenedor de medios AVI ha quedado obsoleta.
• Se añadió un indicador especializado para un mouse conectado externamente que tiene la capacidad de cambiar la forma en que se comportan los clics izquierdo y derecho en una Chromebook
• Indicadores experimentales de controles multimedia mediante un widget que aparece en el área del estante para ayudar a controlar la reproducción.

Por último y no menos importante, Chrome OS 120 incluye la corrección de dos vulnerabilidades en el controlador para GPU PowerVR, causadas por el acceso a un área de memoria ya liberada, asi como también la solución a las vulnerabilidades: CVE-2023-7024 desbordamiento de búfer en WebRTC, CVE-2023-6508, CVE-2023-6509 de uso después de liberación en Media Stream y Side Panel Search y del kernel de Linux  CVE-2023-39191 en el subsistema eBPF.

Si quieres conocer más al respecto sobre esta nueva versión del sistema, puedes consultar los detalles dirigiéndote al siguiente enlace.

Descargar Chrome OS 120

La nueva build ya está disponible para la mayoría de las Chromebooks actuales, además de que desarrolladores externos han formado versiones para computadoras comunes con procesadores x86, x86_64 y ARM.

Por último y no menos importante, si eres usuario de Raspberry debes saber que también puedes instalar Chrome OS en tu dispositivo, solo que la versión que puedas encontrar no es la más actual además de que aún se tiene el problema con la aceleración de video por hardware.

from Desde Linux https://ift.tt/EY5sA8Q
via IFTTT

En PyPI la autenticación de dos factores ya es obligatoria para todos

2FA es un método de seguridad de administración de identidad y acceso que requiere dos formas de identificación

Después de año y medio de trabajo y de algunos cambios graduales, por fin se ha presentado la autenticación obligatoria por medio de 2FA de manera general para todos los usuarios en PyPI, ya que desde mediados del 2022 los desarrolladores del repositorio de paquetes Python PyPI (Python Package Index) anunciaron ruta para la transición a la autenticación obligatoria de dos factores para paquetes críticos.

Un año después de dicho anuncio (en junio del 2023) se implementó la autenticación obligatoria de dos factores para todas las cuentas de usuario que mantenían en ese momento, al menos un proyecto o eran parte de una organización que selecciona paquetes para el uso obligatorio de la autenticación de dos factores.

Y ahora, la introducción de la autenticación obligatoria de dos factores se ha aplicado a todos los usuarios en general, por lo cual al no habilitar la autenticación de dos factores, el usuario ahora no podrá cargar archivos ni realizar acciones relacionadas con la gestión de su proyecto.

Esta publicación es un reconocimiento al arduo trabajo que se realizó para hacer esto realidad y un agradecimiento a todos los usuarios que habilitaron 2FA en sus cuentas.

También es un recordatorio para aquellos que aún no han habilitado 2FA, que deberán hacerlo antes de poder realizar cualquier acción de administración o cargar archivos en PyPI.

Una vez que 2FA esté habilitado, podrá realizar acciones de administración, incluida la generación de tokens API o la configuración de editores confiables (preferido) para cargar archivos.

Como se ha señalado en artículos previos, los desarrolladores del repositorio de paquetes Python PyPI han destacado la importancia de implementar la autenticación de dos factores. Esta medida se introduce con el propósito de mejorar la seguridad en el proceso de desarrollo y proteger los proyectos contra posibles cambios maliciosos originados por la filtración de credenciales. La autenticación de dos factores proporciona una capa adicional de protección, mitigando riesgos asociados al uso de contraseñas compartidas, la vulnerabilidad de contraseñas en sitios comprometidos, ataques al sistema local del desarrollador o tácticas de ingeniería social.

La necesidad de fortalecer la seguridad radica en la amenaza significativa de accesos no autorizados debido a la apropiación de cuentas. Este tipo de ataque representa un riesgo considerable, ya que, en caso de éxito, los atacantes podrían introducir cambios maliciosos en otros productos y bibliotecas que dependen del paquete comprometido. Por ende, la autenticación de dos factores se presenta como una medida esencial para salvaguardar la integridad y la confianza en el ecosistema de desarrollo de software en Python, previniendo potenciales consecuencias negativas derivadas de accesos no autorizados y cambios malintencionados en proyectos fundamentales.

Además de ello, los desarrolladores mencionan que la autenticación de dos factores preferida se basa en un esquema que emplea tokens de hardware compatible con la especificación FIDO U2F y el protocolo WebAuthn. Este método se destaca por proporcionar un nivel de seguridad más elevado en comparación con la generación de contraseñas de un solo uso. Los tokens de hardware, alineados con FIDO U2F y WebAuthn, ofrecen una capa adicional de protección, mejorando la seguridad en el proceso de autenticación.

Además de los tokens de hardware, existe la opción de utilizar aplicaciones de autenticación que generan contraseñas de un solo uso y admiten el protocolo TOTP (Time-Based One-Time Password). Ejemplos de estas aplicaciones incluyen Authy, Google Authenticator y FreeOTP. Estas aplicaciones proporcionan otra alternativa segura para la autenticación de dos factores.

Al descargar paquetes, se recomienda encarecidamente a los desarrolladores que utilicen el método de autenticación denominado ‘Editores de Confianza’. Este método se basa en el estándar OpenID Connect (OIDC) o utiliza tokens de API. La elección de este enfoque ayuda a fortalecer la seguridad en las interacciones y transacciones relacionadas con la descarga de paquetes, proporcionando un nivel adicional de confianza mediante la autenticación de los editores involucrados.

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

from Desde Linux https://ift.tt/Ox6fJv2
via IFTTT

¡Crea tus propias aplicaciones portables AppImage con AppImageTool!

AppImageTool: ¿Cómo construir nuestras propias apps AppImage?

La fragmentación o abundancia de alternativas en Linux siempre suele ser algo relevante, positivo o no, en la Comunidad Linuxera. Por ello, siempre estamos inmersos, tanto como creadores/consumidores de contenidos como usuarios profesionales o no, en las múltiples noticias, novedades y sucesos relacionados con las muchas Distribuciones GNU/Linux, Aplicaciones, Sistemas, Plataformas y más. Y por supuesto que también, en las muchas Guías rápidas y Completos tutoriales posibles para aprender o resolver problemas y necesidades.

Por ello, y pensando en ambas cosas, hoy les traemos una muy útil Guía rápida para lograr crear nuestras propias apps AppImage utilizando otra herramienta adicional llamada «AppImageTool». La cual, es un utilitario de software alternativo o complementario a Pkg2AppImage, que en una anterior publicación también enseñamos a utilizar para lograr el mismo objetivo. Ya que, cuando hablamos de aplicaciones universales y portables, entre Flatpak, Snap y AppImage, muchos solemos preferir a este último formato, y más si de forma fácil y rápida podemos crear nosotros mismos las aplicaciones y juegos portables necesarios, a partir de los archivos fuentes y binarios existentes de desarrollos ya existentes.

Pkg2appimage: ¿Cómo construir nuestros propios archivos AppImage?

Pero, antes de iniciar la lectura de esta publicación sobre qué la útil y complementaria aplicación del proyecto AppImage llamada «AppImageTool», les recomendamos la anterior publicación relacionada con la app similar previamente mencionada y abordada:

AppImageTool: ¿Cómo construir nuestras propias apps AppImage?

¿Qué es AppImageTool?

Según sus propios desarrolladores del Proyecto AppImage en su sitio web oficial, la aplicación «AppImageTool» es descrita brevemente de la siguiente forma:

AppImageTool es una herramienta que le permite generar archivos AppImage. Una AppImage es un paquete autoejecutable que contiene una aplicación y todo lo que necesita para una ejecución exitosa, de forma tal de que, si no se encuentran en el sistema operativo donde serán ejecutadas, entonces no haya problemas. Esto puede incluir archivos de librerías que no suelen estar disponibles en los sistemas de destino, recursos como traducciones, iconos, fuentes y otros archivos auxiliares (dependencias).

En fin, AppImageTool hace que sea fácil tomar una AppDir (Estructura normalizada de una aplicación) al estilo de LinuxDeployQt, para convertirla en una aplicación AppImage.

Esta herramienta de implementación de Linux, toma una aplicación como entrada y la hace autónoma copiando los recursos que utiliza la aplicación (como bibliotecas, gráficos y complementos) en un paquete. El paquete resultante se puede distribuir como AppDir o como AppImage a los usuarios, o se puede colocar en paquetes de distribución cruzada. Sobre LinuxDeployQt en GitHub

Pasos para crear una aplicación AppImage

Para nuestra guía rápida de hoy, utilizaremos el juego Urban Terror 4 para aprender a convertir una aplicación con binarios ejecutables y toda su paquetería asociada en una aplicación universal y portátil con el formato AppImage mediante AppImageTool.

Y los pasos necesarios son los siguientes:

• Descargar la aplicación AppImageTool: Directamente de su sitio web oficial en GitHub. Y para ello, hemos descargado el ejecutable AppImage en su última versión estable disponible en la adecuada arquitectura de nuestro sistema operativo y ordenador, cuyo nombre es appimagetool-x86_64.AppImage. Y luego, de la forma acostumbrada, CLI o GUI, le hemos dado permiso de ejecución.
• Descargar la aplicación a convertir: En nuestro caso, como ya expresamos, descargamos la última versión disponible del juego Urban Terror 4, cuyo nombre es UrbanTerror434_full.zip. Y luego, procedemos a descomprimir el archivo para obtener la carpeta de nombre UrbanTerror43.
• Adecuación del directorio de la aplicación a convertir: Para el caso de Urban Terror 4, antes de ejecutar el proceso de conversión hemos borrado aquellos archivos que consideramos innecesarios, los cuales corresponden a los binarios incluidos para Windows, la arquitectura i386 y su modo Servidor. Es decir, solo dejamos el ejecutable para la arquitectura x86_64 llamado originalmente Quake3-UrT.x86_64, y que hemos renombrado simplemente como UrT4. Nota: Para cada aplicación puede ser necesario borrar distintos archivos o ninguno. O mover, crear o añadir algunos.
• Creación de archivos necesarios para la conversión: Para llevar a cabo de forma exitosa la conversión debemos crear y disponer de mínimo 3 archivos que corresponden a:

Archivos necesarios

Un archivo AppRun cuyo contenido es:

#!/bin/bash

cd "$(dirname "$0")"
exec ./UrT4

Un archivo .desktop cuyo contenido es:

[Desktop Entry]
Type=Application
Exec=AppRun
Icon=UrT4
Name=Urban Terror 4
Terminal=false
StartupNotify=true
Comment=Juego FPS UrT4
Categories=Game;

Por último, un archivo de imagen correspondiente al icono de la aplicación y del futuro archivo AppImage. Que en nuestro caso práctico de hoy, llamaremos UrT4.png.

Y ya luego de que tengamos todo en orden y listo, procedemos a ejecutar nuestra orden de comando de conversión, tal como lo indican en el sitio web oficial: ./appimagetool-x86_64.AppImage AppDir. Sin embargo, para el caso de nuestra aplicación se hace necesario el agregar el prefijo siguiente: ARCH=x86_64. Por lo que, nuestra orden de comando final fue la siguiente:

ARCH=x86_64 ./appimagetool-x86_64.AppImage UrbanTerror43

Y si hemos realizado todo con cuidado y con éxito tendremos lista nuestra aplicación llamada Urban_Terror_4-x86_64.AppImage ubicado en la misma carpeta donde estemos trabajando la conversión, por ejemplo: Descargas. Tal como se muestra en los siguientes pantallazos:

Resumen

En resumen, «AppImageTool» junto a Pkg2AppImage, son sin duda alguna, 2 herramientas de software bien útiles y versátiles que podría usar cualquiera sobre su actual Distro GNU/Linux, para aprender a crear y disfrutar de sus propias aplicaciones portables en el formato de AppImage. Sin embargo, en el futuro, sería genial poder contar con una aplicación de escritorio, es decir, gráfica (con interfaz visual), que automatice y facilite aún más dicho proceso. Por ello, si ya has usado antes alguna de estas 2 u otras similares con el mismo fin, te invitamos vía comentario a contarnos tu experiencia con ellas, en beneficio de todos y la realización de una futura publicación sobre las posibles nuevas mencionadas.

Por último, recuerda visitar nuestra «página de inicio» en español. O, en cualquier otro idioma (con solo agregar al final de nuestra URL actual, 2 letras al final, por ejemplo: ar, de, en, fr, ja, pt y ru, entre muchas otras) para conocer más contenidos actuales. Además, te invitamos a unirte a nuestro canal oficial de Telegram para leer y compartir más noticias, guías y tutoriales de nuestra web. Y también, al siguiente Canal alternativo de Telegram para aprender más sobre el Linuxverso en general.

from Desde Linux https://ift.tt/5fAH3Su
via IFTTT