Rocky Linux es una distribución cuyo objetivo es crear una compilación libre de RHEL que pueda ocupar el lugar del clásico CentOS

Poco después del anuncio de Red Hat de restringir el acceso al código de RHEL y de las postulaciones iniciales por parte de AlmaLinux y Rocky Linux. Este último ha dado a conocer más información sobre los próximos cambios que realizara dentro de proceso de desarrollo de la distribución.

Con ello, el proyecto Rocky Linux, ha dado a conocer que no dejara de lado su objetivo de continuar ofreciendo una distribución de Linux compatible con Red Hat Enterprise Linux (RHEL) y esto lo continuara realizando aprovechando las lagunas legales en la licencia de RHEL para ofrecer a los usuarios una alternativa gratuita.

Sobre esta acción por parte de Rocky Linux, se menciona que planea usar el programa Red Hat Developer Subscription, que brinda a los desarrolladores individuales acceso gratuito a RHEL para uso personal, y el servicio Red Hat Universal Base Image (UBI), que proporciona imágenes de contenedor basadas en RHEL sin cargo.

En una publicación de blog titulada «Keeping Open Source Open», el Proyecto Rocky Linux, por su parte, describe dos formas diferentes de obtener el código fuente de RHEL sin violar los acuerdos de licencia de Red Hat.

Desde el inicio del Proyecto Rocky, hemos priorizado la repetibilidad, la transparencia en la toma de decisiones y la garantía de que ningún proveedor o empresa pueda tomar como rehén al proyecto. Cuando comenzamos, discutimos nuestro modelo y nuestra misión, y decidimos no dividir la comunidad Enterprise Linux.

Más bien, en el espíritu de los principios y estándares de código abierto, hemos creado algo compatible con Red Hat Enterprise Linux (RHEL). Al adherirnos a este enfoque, mantenemos un estándar único para Enterprise Linux y nos alineamos con los objetivos originales de CentOS.

Sin embargo, Red Hat expresó recientemente su opinión de que «no encuentra ningún valor en una reconstrucción de RHEL». Si bien creemos que este punto de vista es estrecho de miras, Red Hat ha adoptado una postura firme y tiene acceso limitado a las fuentes de RHEL solo para sus clientes que pagan. Estas fuentes consisten principalmente en paquetes de proyectos de código abierto ascendentes que no son propiedad de Red Hat.

Anteriormente, obtuvimos el código fuente de Rocky Linux exclusivamente del repositorio CentOS Git, como recomendaron. Sin embargo, este repositorio ya no alberga todas las versiones correspondientes a RHEL. Por lo tanto, ahora necesitamos recopilar el código fuente de varias fuentes, incluidos CentOS Stream y RHEL SRPM.

Sobre el proceso para obtener las fuentes de RHEL, se menciona que Rocky Linux planea combinar las fuentes y crear una distribución que sea idéntica a RHEL sin infringir los derechos de autor de Red Hat. Como ya se menciono una opción es usar las imágenes del contenedor UBI que están basadas en RHEL y están disponibles en varias fuentes en línea (incluido Docker Hub). Mediante el uso de la imagen UBI, es posible obtener fácilmente fuentes de Red Hat de manera confiable y sin problemas. El método ha sido validado utilizando contenedores Open Container Initiative (OCI) y funciona exactamente como se esperaba.

Otro método que se está aprovechando son las instancias de nube pública de pago por uso. Así, cualquiera puede crear imágenes RHEL en la nube y así obtener el código fuente de todos los paquetes.

«Es la forma más fácil de escalar para nosotros, porque podemos hacerlo todo a través de canalizaciones de CI, girando imágenes en la nube para obtener las fuentes a través de DNF y publicándolas automáticamente en nuestros repositorios de Git», dice el equipo de Rocky Linux.

Estos métodos son posibles gracias al poder de la GPL, ya que nadie puede impedir la redistribución de software bajo la GPL. Para reiterar, ambos métodos hacen posible obtener binarios de RHEL y SRPM legítimamente sin comprometer el compromiso con el software libre o aceptar limitaciones de TOS o EULA que perjudiquen los derechos.

Según los asesores legales de Rocky Linux, es posible obtener las fuentes de todos los binarios recibidos, lo que permite que Rocky Linux siga avanzando de acuerdo con las intenciones iniciales.

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/0lo25fm
via IFTTT

Hace unos meses escribí un artículo sobre 6 tipos de kernels diferentes. El normal, el que usan la mayoría de distribuciones, se llama sencillamente «linux», pero hay uno Real Time (-rt) que tiene baja latencia y es mejor para usarlo en algunos programas de sonido, por ejemplo, y uno Hardened con capas de seguridad extra. Todos tienen su sentido, pero hoy vamos a hablar un poco más sobre Linux Zen, un kernel que, sobre el papel, todo lo que ofrece son ventanas.

La descripción que encontramos en la Wiki de Arch Linux lo define como «el resultado de un esfuerzo colaborativo de hackers del kernel para proporcionar el mejor kernel de Linux posible para sistemas de uso diario«. ¿Un kernel mejorado por hackers que hace que el sistema operativo funcione mejor? Vaya. ¿Por qué si pinta tan bien no lo vemos en las distribuciones más populares? Hay motivos para todo, y el usuario de Linux sabe perfectamente que no llueve a gusto de todos ni en todas partes por igual.

Linux Zen, lo mejor para el escritorio…

… si te va bien. Linux Zen ofrece lo bueno del RT o de tiempo real, y además hace que sea más eficiente y, por qué no decirlo, potente. Es lo que usa por defecto Garuda Linux, y en su página web es descrito como «un kernel más rápido y responsivo optimizado para el escritorio, multimedia y el gaming«, y termina la frase con lo mismo que leemos en la Wiki de Arch Linux. Y ninguno de los dos miente; es así.

Pero es algo que hay que probar y comprobar. Linux original, el de toda la vida, el que crea Linus Torvalds, está diseñado pensando en la mayoría de escenarios y preparado para funcionar en todo tipo de hardware. Linux Zen también, la base es la misma, pero las modificaciones que han realizado los hackers pueden no sentarle igual de bien a todos los equipos.

Otro punto a tener en cuenta es lo que dice Garuda, concretamente esa parte donde menciona «optimizado para el escritorio». Pongamos un ejemplo, el de Canonical: la compañía que dirige Mark Shuttleworth está detrás de ya 11 sabores, pero se encarga directamente de Ubuntu Desktop, Ubuntu Server y Ubuntu para placas como la Raspberry Pi. Aunque puede que en algún momento cambien las cosas, Linux Zen está especialmente diseñado para la arquitectura x86_64, y si Canonical decidiera usar este kernel en Ubuntu Desktop, tendría que usar diferentes kernels para sus diferentes opciones. Al usar el Linux de Linus, y luego mantenerlo, no tiene que derrochar tiempo y recursos.

¿Debería usar Zen en mi distribución?

Quien me lea con asiduidad sabrá que a mí no me gusta mentir ni recomendar grandes cambios si algo nos va bien. Por lo tanto, muchas de mis respuestas a preguntas de sí/no las respondo con un «depende». Lo primero que tendría yo en cuenta es: ¿mi distribución ofrece esa opción? Si no, quizá merezca la pena no hacer esos experimentos que toda la vida se ha dicho que se hacen con gaseosa. Aunque también podemos probar, que cada uno es dueño de lo que usa y decide si correr riesgos y el tamaño de los mismos.

Si la distro que usamos ofrece la opción de usar Linux Zen, y queremos mejorar el rendimiento en juegos, aplicaciones multimedia o mejorar la autonomía, algo que también puede hacer, yo creo que merece la pena probar para ver cómo se comporta en nuestro equipo. Huelga decir que antes de hacer este tipo de movimientos es necesario hacer una copia de seguridad de todos nuestros documentos importantes. Pero, por lo general, lo peor que puede pasar es que no inicie, momento en el que tenemos que reiniciar, entrar en las opciones de inicio, elegir el kernel normal e iniciar desde él.

En el caso de que no la ofrezca por ningún medio oficial, habría que hacer la instalación manual. La página web del proyecto es esta.

from Linux Adictos https://ift.tt/7lWCVrj
via IFTTT

Qt Creator es un IDE multiplataforma, para el desarrollo de aplicaciones

Se dió a conocer el lanzamiento de la nueva versión del entorno de desarrollo integrado Qt Creator 11.0, el cual está diseñado para crear aplicaciones multiplataforma utilizando la biblioteca Qt.

En Qt Creator se admite tanto el desarrollo de programas clásicos de C++ como el uso del lenguaje QML, en el que se utiliza JavaScript para definir scripts, y la estructura y los parámetros de los elementos de la interfaz se establecen mediante bloques tipo CSS.

Principales novedades de Qt Creator 11.0

En esta nueva versión que se presenta de Qt Creator 11.0, se destaca que se ha propuesto un emulador de terminal incorporado que admite pestañas, selección de shell, salida de color y cambio de fuentes. Se menciona que el terminal integrado se utiliza de forma predeterminada al ejecutar comandos a través del menú «Ejecutar en terminal», pero en la configuración se puede volver a ejecutar un emulador de terminal externo en la ruta (Terminal > Usar terminal interno).

Otro de los cambios que se destaca de esta nueva versión es la compatibilidad integrada con el asistente inteligente GitHub Copilot, que puede generar construcciones genéricas al escribir código. La implementación se basa en el complemento Copilot, desarrollado originalmente para el proyecto neovim, pero utilizando el protocolo LSP genérico para la integración IDE.

También podremos encontrar en Qt Creator 11.0, que se agregó el soporte para el kit de herramientas Axivion, que proporciona un analizador estático, herramientas para identificar problemas en el código, utilidades para evaluar la eficiencia y analizar la arquitectura. Qt Creator puede vincular proyectos en desarrollo a proyectos en Axivion y mostrar información sobre herramientas en el editor con información sobre problemas detectados.

Por otra parte, en la interfaz para trabajar con proyectos, se ha agregado la capacidad de agregar archivos directamente a archivos de proyecto basados en CMake .

Además de ello, también se destaca que se agregó el soporte experimental para el administrador de paquetes vcpkg que se usa para distribuir bibliotecas C/C++. Entre otras cosas, se ha agregado un asistente y un editor para archivos vcpkg.json y se ha proporcionado la capacidad de buscar paquetes.

De los demás cambios que se destacan de esta nueva versión de Qt Creator 11.0:

• Interfaz rediseñada para navegar a través de los ejemplos de código proporcionados por Qt. Los ejemplos ahora están divididos en categorías.
  Opción agregada para aumentar el tamaño de la barra de herramientas (Preferencias> Interfaz> Estilo de barra de herramientas> Relajado).
• Se ha rediseñado la interfaz de visualización de la lista de incidencias (Issues).
• Se ha agregado compatibilidad con la vista previa de documentos Markdown (.md) al editor de código.
• Edición mejorada de código C++ y QML.
• Se mejoró el rendimiento del soporte multi-cursor.
• Se corrigió el guardado de archivos vinculados

Finalmente, si quieres conocer más al respecto sobre esta nueva versión pueden consultar el anuncio original en el siguiente enlace.

Obtener Qt Creator 11.0

Para quienes estén interesados, deben saber que la versión de código abierto está disponible en la página de descarga de Qt en «Qt Creator», mientras que para los interesados en la versión comercial podrán encontrar la licencia comercial en el portal de cuentas de Qt.

ComLinux, podremos realizar la instalación con ayuda del instalador que se ofrece de manera general para Linux. Para obtener el paquete offline, basta con abrir una terminal y ejecutar el siguiente comando:

wget https://download.qt.io/official_releases/qtcreator/11.0/11.0.0/qt-creator-opensource-linux-x86_64-11.0.0.run 

Ahora simplemente basta con dar permisos de ejecución al archivo con el siguiente comando:

sudo chmod +x qt-creator-opensource-linux-x86_64-11.0.0.run

Y ahora podremos ejecutar el instalador en nuestro sistema, para ello debemos de teclear el siguiente comando:

./qt-creator-opensource-linux-x86_64-11.0.0.run

Al finalizar la instalación si eres usuario de Ubuntu o algún derviado, debemos de instalar algunos paquetes adicionales para no tener problemas al momento de trabajar con Qt Creator, para ello sobre la misma terminal vamos a teclear los siguientes comandos:

sudo apt-get install build-essential

Y también debemos de instalar librería de configuración de fuentes genéricas:

sudo apt-get install libfontconfig1

sudo apt-get install mesa-common-dev

sudo apt-get install libglu1-mesa-dev -y

O para el caso de quienes prefieren esperar a que el paquete esté listo en los repositorios de Ubuntu y derivados, pueden instalar el paquete con el siguiente comando:

sudo apt install qtcreator

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

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

Se dio a conocer información sobre una vulnerabilidad que fue detectada en la implementación OpenSSH de ssh-agent que permite que el código se ejecute en un sistema que ha proporcionado acceso ssh-agent a un host en el otro extremo de una conexión ssh.

La vulnerabilidad, ya catalogada bajo CVE-2023-38408, es notable debido a que es explotable de manera remota. El ataque solo es posible si el usuario se ha conectado a través de ssh a un sistema controlado por el atacante al habilitar el reenvío de sockets a ssh-agent a través de ssh usando la opción «-A» o la configuración de ForwardAgent en el archivo de configuración.

El proceso de ssh-agent, utilizado para almacenar en caché claves privadas para la autenticación de clave pública, admite un modo de reenvío opcional que permite que el lado remoto de una conexión ssh acceda al ssh-agent en el sistema local para no almacenar datos de autenticación en otros hosts.

La vulnerabilidad está relacionada con la presencia en ssh-agent de soporte para cargar módulos PKCS # 11, que pueden iniciarse, entre otras cosas, a través de un socket unix reenviado a otro sistema a ssh-agent.

Esta característica permite que un atacante que controla el host al que está conectado cargue y descargue inmediatamente cualquier biblioteca compartida de los directorios /usr/lib* en el sistema local de la víctima en un proceso ssh-pkcs11-helper separado. Esta característica aparece en ssh-agent compilado con la opción ENABLE_PKCS11, que está habilitada de forma predeterminada.

Inicialmente, la capacidad de cargar bibliotecas compartidas no se consideró una amenaza para la seguridad, ya que la carga solo es posible desde los directorios del sistema /usr/lib*, que contienen bibliotecas proporcionadas oficialmente por la distribución, y las operaciones con estas bibliotecas se limitan a llamar a las funciones dlopen() y dlclose(), sin llamar a las funciones de la biblioteca.

Sin embargo, se ha pasado por alto que algunas bibliotecas tienen funciones constructoras y destructoras que se llaman automáticamente al realizar las operaciones dlopen() y dlclose(). Esto puede ser suficiente para recoger las bibliotecas necesarias y organizar la ejecución remota de código.

La capacidad de ataque se demuestra en el entorno predeterminado de Ubuntu, ya que no probado en otras distribuciones, que además instala tres paquetes del repositorio «universe» (aun que se supone que en algunas distribuciones es posible atacar en la configuración predeterminada).

Se propusieron 8 variantes del ataque.

Por ejemplo, una de las opciones prometedoras para crear un exploit funcional se basa en el hecho de que la biblioteca libgnatcoll_postgres.so, al ejecutar dlopen(), registra una pila de señales separada utilizada en los controladores de señales llamando a la función sigaltstack(), y después de llamar a dlclose() elimina la asignación de memoria, pero no deshabilita el registro (SS_DISABLE) de la pila de señales.

Para explotar la vulnerabilidad, se realizan las siguientes manipulaciones:

• Se cargan varias bibliotecas para cambiar el diseño mmap.
• Se carga la biblioteca libgnatcoll_postgres.so, se registra una pila de señales alternativa y se ejecuta munmap().
• Las bibliotecas se cargan para cambiar el diseño de mmap y reemplazar la pila de señal separada con otra área de memoria en modo de escritura (por ejemplo, la pila de flujo o los segmentos .data/.bss).
• Carga una biblioteca que registra el controlador de señal SA_ONSTACK pero no lo munmap() cuando se llama a dlclose().
• La biblioteca que recibe la señal y llama al controlador de señales SA_ONSTACK se carga, lo que hace que el área de memoria reemplazada se sobrescriba con marcos de pila del controlador de señales.
• Las bibliotecas se cargan para sobrescribir específicamente el contenido del área de memoria reemplazada.

Sobre la vulnerabilidad, cabe mencionar que esta fue corregida en el lanzamiento de OpenSSH 9.3p2 publicada hace poco. En la nueva versión, las solicitudes para cargar módulos PKCS#11 están deshabilitadas de manera predeterminada. Como solución de seguridad, puede especificar una lista blanca PKCS#11/FIDO vacía (ssh-agent -P ») al iniciar ssh-agent, o definir explícitamente las bibliotecas permitidas en la lista blanca.

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/J76Drbq
via IFTTT