backdoor XZ

En días anteriores compartimos aquí en el blog la noticia sobre el caso del backdoor que fue detectado en la utilidad XZ, la cual es utilizada en una gran cantidad de distribuciones de Linux y que por ende afecta a todas estas. Lo interesante del caso para muchos y entre los cuales me incluyo, es el cómo se fue preparando la inclusión del backdoor y el cómo género, o se fueron dando las circunstancias para favorecer la introduccion del código y fuera pasado por alto.

En la publicación de blog de Evan Boehs (un programado y hacker), compartió un pequeño análisis cronológico del caso del backdoor en XZ. En la publicacion menciona que el desarrollador Jia Tan fue el responsable de introducir el backdoor en el paquete xz, ya que Jia Tan obtuvo el estatus de mantenedor en 2022 y comenzó a lanzar versiones desde la 5.4.2 del proyecto xz. Además de trabajar en xz, Jia Tan también contribuyó a los paquetes xz-java y xz-embedded, y fue reconocido como mantenedor del proyecto XZ Embedded utilizado en el kernel de Linux.

Además de Jia Tan, se mencionó la participación de dos usuarios más, Jigar Kumar y Hans Jansen, quienes muchos suponen que aparentemente podrían ser personajes virtuales. Jigar Kumar estuvo involucrado en la promoción de los primeros parches de Jia Tan en xz presionando al entonces mantenedor Lasse Collin para que aceptara cambios útiles e implementar el soporte para filtros de cadena en abril de 2022.

En junio de 2022, Lasse Collin cedió el rol de mantenedor a Jia Tan, reconociendo el agotamiento y los problemas de salud mental. Después de estos eventos, Jigar Kumar ya no apareció en la lista de correo del proyecto.

Con el nuevo estatus de mantenedor, Jia Tan comenzó a realizar activamente cambios en el proyecto xz y, según las estadísticas, ocupó el segundo lugar entre los desarrolladores en términos de número de cambios durante dos años.

En marzo de 2023, Lasse Collin reemplazó a la persona responsable de probar el paquete xz en el servicio oss-fuzz por Jia Tan, y en junio se implementaron cambios en la composición de xz, incluyendo el soporte para el mecanismo IFUNC en liblzma, que luego se utilizó para organizar la interceptación de funciones en el backdoor. La sugerencia para este cambio provino de Hans Jansen, cuya cuenta se creó justo antes de enviar la solicitud de extracción relacionada con estos cambios.

En julio de 2023, Jia Tan solicitó a los desarrolladores de oss-fuzz deshabilitar la verificación ifunc debido a su incompatibilidad con el modo «-fsanitize=address». En febrero de 2024, se modificó el enlace al sitio web del proyecto xz en oss-fuzz y tukaani.org, trasladándose de «tukaani.org/xz/» a «xz.tukaani.org». Este último subdominio estaba alojado en GitHub Pages y era controlado personalmente por Jia Tan.

El 23 de febrero, se publicaron en el repositorio xz archivos para probar el decodificador, incluyendo archivos con un backdoor y las macros M4 para activar el backdoor se incluyeron solo en el tarball de la versión 5.6.0 y se excluyeron del repositorio de Git, pero aparecieron en el archivo .gitignore.

El 17 de marzo, Hans Jansen, previamente involucrado en parches con soporte IFUNC, se registró como colaborador en el proyecto Debian. El 25 de marzo, recibió una solicitud para actualizar la versión del paquete xz-utils en el repositorio de Debian. Cabe mencionar que llegaron solicitudes similares, de desarrolladores de Fedora y Ubuntu (aunque en Ubuntu, el cambio fue rechazado debido a la congelación del repositorio).

Varios usuarios se unieron a las solicitudes de actualización de xz, argumentando que la nueva versión solucionaba errores detectados durante la depuración en valgrind. Estos problemas surgieron debido a una determinación incorrecta del diseño de la pila en el controlador del backdoor, intentando resolverlos en la versión xz 5.6.1.

Sobre esto, Lasse Collin, emitió una declaración confirmando que los archivos que contienen las versiones del backdoor fueron creados y firmados por Jia Tan. Además, anunció la eliminación del subdominio xz.tukaani.org, indicando que el sitio xz volverá al servidor principal tukaani.org. También mencionó que su cuenta de GitHub fue bloqueada. Es importante destacar que Lasse Collin tiene control únicamente sobre el sitio web tukaani.org y los repositorios git.tukaani.org. Por otro lado, Jia Tan solo controlaba el proyecto en GitHub y el host xz.tukaani.org, pero no tenía acceso al servidor tukaani.org.

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

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

ROSA Linux es una distribución y sistema operativo Linux, desarrollado por la compañía rusa LLC NTC IT ROSA

STC IT ROSA dio a conocer mediante una publicación de blog el lanzamiento de la nueva versión correctiva ROSA Fresh 12.5, la cual continúa el trabajo de mejorar, corregir errores y proporcionar paquetes actualizados de la rama 12.x. Esta actualización trae consigo una serie de mejoras importantes, nuevas funciones y una serie de actualizaciones.

Para quienes desconocen de ROSA Fresh deben saber que esta es una distribucion de Linux rusa, moderna, creada por la comunidad, ya que se originó como un fork de la ahora desaparecida distribución Linux Mandriva y desde entonces ha sido desarrollado en forma independiente. La compañía ROSA fue fundada a principios de 2010 y lanzó la primera versión de su sistema operativo en diciembre de 2010. Inicialmente, apuntaba a los usuarios empresariales, pero a fines de 2012 ROSA inició su distribución orientada al usuario final, la Desktop Fresh.

Principales novedades de ROSA Fresh 12.5

En esta nueva versión que se presenta de ROSA Fresh 12.5 la base del sistema se ha actualizado al kernel de Linux 6.6 (los kernels de las ramas anteriores 5.10 y 5.15 continúan siendo compatibles y actualizados dentro de su rama sin transición automática a 6.1), se menciona que en la mayoría de las diferentes ediciones se actualizaron a la rama estable actual (ya que para la arquitectura i686 se sigue con los Kernels 5.10 y 5.15).

Por el lado del las compilaciones con el nuevo kernel LTS Linux 6.1.20 se menciona que tiene MGLRU habilitado de forma predeterminada y se ha actualizado el firmware y los controladores para Wi-Fi y Bluetooth. Además de ello, de manera general se incluyen las actualizaciones de la pila de gráficos MESA 23.3, con soporte de Steam.

En la edición de ROSA Fresh 12.5 KDE, se han actualizado los componentes del entorno, ya que ahora se ofrece la version de KDE Plasma 5.27.10 junto con KDE Frameworks 5.112.0, y por la parte de las aplicaciones de usuario se ofrece KDE Applications 23/08/04 con Qt 5.15.10.

Ademas de ello, se ha agregado soporte extendido para impresoras y escáneres que utilizan tecnologías ipp-usb y sane-airscan, simplificando su uso y facilitando la compatibilidad con una amplia gama de dispositivos periféricos y se han incluido nuevos controladores propietarios para las tarjetas de video NVIDIA 550, complementando las ramas existentes 340, 390 y 470 que siguen disponibles para aquellos que las necesiten.

Por otra parte,  la nueva versión de ROSA Fresh 12.5 presenta un repositorio completamente rediseñado para garantizar la seguridad y cerrar más de mil vulnerabilidades, además de que se ha implementado el cifrado de datos en el instalador del sistema y la función para guardar contraseñas de discos cifrados en la memoria no volátil de la computadora utilizando la tecnología TPM2 (luksunlock/lukslock) proporciona una capa adicional de protección sin sacrificar la comodidad de uso.

Se introdujo una nueva versión del indicador de actualización en ROSA, que ofrece opciones para restringir el acceso a la instalación de actualizaciones: ahora es posible requerir una contraseña de administrador, una contraseña solo para usuarios o incluso no requerir contraseña alguna.

Tambien se ha añadido soporte para paquetes «sconfigs-*«, que proporcionan configuraciones avanzadas de seguridad y auditoría del sistema, mejorando la gestión y la protección de los entornos de usuario y se ha introducido la utilidad qemoo, que permite iniciar rápidamente imágenes iso en el emulador QEMU, facilitando las pruebas y el desarrollo en entornos virtuales.

De los demás cambios:

• Se ha mejorado la compatibilidad con tarjetas de red Realtek cableadas en chips RTL8111, RTL8168 y RTL8411
• Se corrigió el retraso de inicio al instalar en BTRFS sin una partición /boot separada en ext2/3/4 (“No se permiten archivos dispersos”): la funcionalidad de guardar el último elemento cargado en Grub ahora se desactiva automáticamente al instalar el sistema operativo en tales configuraciones
• se ha agregado y suministrado como parte del sistema operativo un módulo de kernel r8168 listo para usar, que se usa automáticamente como controlador para estas tarjetas de red, y desde el Controlador r8169 en el kernel predeterminado de Linux 6.1
• se eliminó la compatibilidad con estas tarjetas
• Se corrigió el trabajo del comando «reboot» en los scripts kickstart.

Finalmente si estás interesado en poder conocer más al respecto sobre esta nueva versión, puedes consultar los detalles en el siguiente enlace.

Descargar y obtener ROSA Fresh 12.5

Para aquellos interesados en probar o explorar la distribución, se ofrecen compilaciones completamente gratuitas diseñadas para la plataforma x86_64 en versiones con KDE Plasma 5, LXQt, GNOME, Xfce y sin interfaz gráfica (modo texto). Los usuarios que ya tengan instalada una versión anterior de ROSA Fresh R12.x recibirán la actualización de forma automática.

Requisitos mínimos para probar o instalar el sistema:

• Procesador x86 de 64 bits (compatibilidad limitada con i686, solo kernels 5.10 y 5.15)
• 20 GB de espacio disponible en disco
• Pantalla gráfica con una resolución de 1024×768 (también se admite el modo texto del instalador)
• Soporte de arranque desde dispositivos USB (flash)

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

Ubuntu 24.04 está a la vuelta de la esquina. Mañana deberían haber lanzado la versión beta, pero finalmente se retrasará una semana por el conocido y gravísimo fallo de seguridad de XZ. Cuando llegue, lo hará con una de esas novedades que gustarán más a unos que a otros, pero creo que los primeros serán mayoría: el icono del lanzador de aplicaciones, que hasta ahora eran 9 cuadros en rejilla, pasa a ser el logotipo de Ubuntu.

Ahora mismo, GNOME tiene por defecto el panel en forma de dock – sin llegar a los extremos – y en la parte inferior. Para acceder a él es necesario hacer clic en Actividades o un gesto en el panel táctil, pero se aloja en la parte inferior de la pantalla. Canonical, como parte de su seña de identidad, lo pone a la izquierda, está siempre visible y el botón lanzador de aplicaciones está abajo, pero todo esto se puede modificar. Aquí vamos a explicarte cómo hacer varias modificaciones de este tipo en Ubuntu 24.04.

Poner el lanzador de aplicaciones de Ubuntu 24.04 arriba

La manera más sencilla y rápida es haciendo uso del terminal. Hay una opción de la extensión dash-to-dock que dice justamente eso, mostrar las aplicaciones en la parte superior, y por defecto está en false. Lo único que hay que hacer es abrir un terminal y escribir lo siguiente:

gsettings set org.gnome.shell.extensions.dash-to-dock show-apps-at-top true

El cambio es instantáneo; no es necesario reiniciar ni siquiera esperar. Veremos lo que hay en la captura de cabecera.

Si preferís una herramienta gráfica, algo que no recomendaría para cambios tan pequeños y sencillos para evitar instalar software de más, se puede instalar Editor de dconf desde el Centro de Aplicaciones. También desde el terminal, pero como los que están prestando más atención a este punto son justamente aquellos que no quieren usarlo, explicamos cómo hacerlo desde la tienda de software de Ubuntu 24.04 (el comando para terminal sería sudo apt install dconf-editor, y así todos contentos):

Pasos a seguir

1. Lo primero que hay que hacer es abrir Apps Center.
2. No aparecerá ningún resultado, pero esto es porque Canonical prioriza los paquetes snap sobre los nativos de Debian. Hay que hacer clic en el desplegable que pone «Filtrar por: Paquetes snap» y elegir «Paquetes de Debian».

3. Al hacerlo ya aparecerá «Editor de dconf». Para finalizar la instalación, lo de siempre: hacer clic sobre ese resultado, luego en el botón verde de «Instalar» y, finalmente, se pone la contraseña.

4. Con el Editor de dconf instalado, ahora hay que abrirlo. Hay que hacer clic en el cajón de aplicaciones, que supuestamente lo tendréis abajo, o sacar las apps con tres dedos del teclado hacia arriba y luego clic sobre su icono.

5. Veremos una ventana de aviso. La aceptamos para poder avanzar. Si queremos hacer más cambios en el futuro y no volver a ver este aviso, hay que desmarcar la caja de verificación.

6. Haciendo clic en las carpetas, hay que entrar a /org/gnome/shell/extensions/dash-to-dock, y buscar «top» allí. Hay que dar con «show-apps-at-top» y activar el interruptor. Yo lo tengo activado porque ya he hecho el cambio con el comando.

Como al hacerlo con desde el terminal, el cambio será instantáneo y no requiere esperas ni reinicios.

Haz que el dock sea un dock

Un dato: la opción «top» que estamos modificando aquí es también la izquierda si ponemos el panel en la parte inferior. Y es que un dock de verdad es ese tipo de panel que sólo tiene aplicaciones, puede que la papelera, el lanzador de apps y no llega de parte a parte. También debe crecer conforme vamos abriendo aplicaciones.

Si queremos ver algo como lo de la captura anterior, las indicaciones también se encuentran en la imagen. Hay que abrir los ajustes, desplazarse al apartado «Escritorio de Ubuntu», luego a la sección «Dock», desactivar el modo panel – lo que hace que vaya de parte a parte – y, en posición en la pantalla, elegir «Abajo».

En caso de que prefiramos que el lanzador de aplicaciones esté a la derecha, simplemente omitiremos todo lo de moverlo a la parte superior, que esto también lo pone a la izquierda. GNOME lo prefiere a la derecha cuando está abajo, pero a la izquierda tiene más sentido para los que han usado otros docks o están más acostumbrados a Windows y macOS.

Cambiar la opacidad del panel de Ubuntu 24.04

La opacidad también se puede cambiar con el terminal o con Editor de dconf. Los comandos del terminal serían:

gsettings set org.gnome.shell.extensions.dash-to-dock transparency-mode 'FIXED'

Con el segundo, le cambiamos la opacidad (0.0 es totalmente transparente y 1.0 totalmente opaco):

gsettings set org.gnome.shell.extensions.dash-to-dock background-opacity 0.0

Para revertir los cambios, introduciremos los comandos de nuevo, pero con ‘DEFAULT’ (comillas incluidas) en el primero y 0.8 en el segundo. No es exacto, ya que el valor de la opacidad por defecto tiene muchos más ceros, como veréis en el siguiente método.

Con el Editor de dconf hay que:

1. Ir a la misma ruta /org/gnome/shell/extensions/dash-to-dock.
2. Desplazarse abajo del todo y buscar «transparency-mode».
3. Desactivar el interruptor de «Usar el valor predeterminado».

4. Luego hay que hacer clic en el botón,  que por defecto pone «DEFAULT»,  seleccionar «FIXED» y luego hacer clic en el botón verde de aceptar.

5. Volvemos atrás – si os preguntáis cómo, sencillamente haciendo clic en la ruta del panel superior – y buscamos «background-opacity». Entramos.

6. Una vez dentro:
   1. Desactivamos el interruptor.
   2. Ponemos un valor pesonalizado.
   3. Hacemos clic en el botón de aceptar. Los cambios, como siempre, son instantáneos.

Igual que en versiones recientes

Todo esto ya estaba disponible y era posible en versiones anteriores de GNOME, pero no está de más confirmar que también funciona en el Ubuntu 24.04 que actualmente está en desarrollo. Son opciones que podemos modificar, y al que no le gusten, sencillamente que lo deje todo como está. En Linux somos nosotros los que decidimos, e incluso podemos volver a poner el icono de la rejilla si lo descargamos de este commit de Ubuntu, por ejemplo, y lo ponemos en /usr/share/icons/Yaru/scalable/actions con el nombre de siempre, es decir, como view-app-grid-symbolic.svg. Ojo con sobrescribir porque se podría perder el logotipo de Ubuntu. Con lo bonito que queda.

.barra {display: flex;justify-content: flex-end;height: 25px; background-color: #333;border-radius: 5px 5px 0 0;}.rojo, .naranja, .verde{width: 12px;height: 12px; position: relative;border-radius: 50%;top: 7px; margin: 0 3px;}.rojo{background-color: rgb(248, 82, 82); margin-right: 7px;}.naranja{background-color: rgb(252, 186, 63);}.verde{background-color: rgb(17, 187, 17);}.terminal{background-color: black !important; border-radius: 5px !important;}pre{font-family:monospace !important; padding: 0 10px 10px; line-height: 1.5em; overflow: auto; background-color: black !important; color: #0EE80E !important}code {background-color: rgba(255, 255, 0, 0.18); color: #d63384; padding: 1px 3px; font-family: monospace; border-radius: 2px;}

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

Un backdoor afecta a Linux

Hace poco se dio a conocer la noticia de que en el paquete XZ Utils ha sido identificado un backdoor que permite a los atacantes interceptar y modificar datos procesados por aplicaciones asociadas a la biblioteca liblzma. La principal vulnerabilidad (ya catalogada bajo CVE-2024-3094) se encuentra en el servidor OpenSSH, que en algunas distribuciones utiliza la biblioteca libsystemd, que a su vez depende de liblzma. Al vincular sshd con una versión vulnerable de liblzma, los atacantes pueden acceder al servidor SSH sin autenticación.

El descubrimiento del backdoor en el proyecto XZ Utils ocurrió tras la detección de problemas como el consumo excesivo de CPU y errores generados por valgrind al conectarse a sistemas basados en Debian sid a través de SSH. Estos problemas llevaron a una investigación más profunda que reveló la presencia del backdoor.

El presunto autor del backdoor, Jia Tan, era un desarrollador activo y respetado en el proyecto xz, con el estatus de «co-mantenedor» durante varios años y contribuciones significativas al desarrollo de varias versiones. Además del proyecto xz, también contribuyó a otros paquetes relacionados, como xz-java y xz-embedded. Incluso fue incluido recientemente entre los mantenedores del proyecto XZ Embedded utilizado en el kernel de Linux.

El cambio malicioso fue descubierto después de quejas sobre problemas con la versión xz 5.6.0, que incluía el backdoor, como desaceleraciones y fallas en sshd. La versión siguiente, xz 5.6.1, incluyó cambios preparados por Jia Tan en respuesta a estas quejas, lo que posiblemente fue una forma de encubrir la presencia del backdoor

Además, se menciona que Jia Tan realizó cambios incompatibles con el modo de inspección «-fsanitize=address» el año pasado, lo que llevó a la deshabilitación de las pruebas fuzz en ese momento. Estos detalles sugieren que la introducción del backdoor fue una acción planeada y oculta dentro del desarrollo del proyecto, lo que podría haber comprometido a un número desconocido de usuarios y proyectos que utilizan XZ Utils.

Aunque esta vulnerabilidad afecta a sistemas x86_64 basados ​​en el kernel de Linux y la biblioteca Glibc C que incluye sshd con libsystemd para admitir el mecanismo sd_notify, varios factores han atenuado el impacto. Por ejemplo, la versión de liblzma con el backdoor no se incluyó en las versiones estables de grandes distribuciones, y algunas distribuciones como Arch Linux y Gentoo usaron una versión vulnerable de xz pero no son susceptibles al ataque debido a ciertas configuraciones.

Se menciona que la activación del backdoor estaba oculto en macros m4 en el archivo build-to-host.m4 utilizado durante la compilación, lo que permitió la inserción de código malicioso en la biblioteca liblzma. Este código malicioso modificó la lógica de funcionamiento de algunas funciones en la biblioteca, lo que facilitó el acceso no autorizado al servidor SSH en sistemas afectados.

El proceso de implementación del backdoor en el paquete XZ Utils implicó varios pasos y técnicas para ocultar su presencia y activación. Se utilizaron macros m4 en el archivo build-to-host.m4 durante la compilación para introducir el código malicioso en la biblioteca liblzma. Estas macros estaban presentes en los archivos tar de la versión, pero no en el repositorio de Git, y se añadieron al .gitignore. Además, se incluyeron archivos de prueba maliciosos en el repositorio, lo que sugiere un acceso privilegiado al proceso de generación de versiones.

El backdoor se activaba mediante la ejecución del comando /usr/sbin/sshd y se ocultaba en entornos no depurados o de producción, evitando la detección en terminales normales. Se falsificó la función RSA_public_decrypt para eludir el proceso de autenticación sshd, lo que permitía a los atacantes obtener acceso no autorizado al servidor SSH.

Para ocultar aún más la presencia del backdoor, se incluyeron mecanismos de protección contra la detección y se verificó la ejecución en entornos de depuración. Todo esto demuestra un nivel avanzado de planificación y conocimiento técnico por parte de los responsables del backdoor para evadir la detección y llevar a cabo ataques exitosos en sistemas afectados.

Si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.

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

sudo rm

En cuantas ocasiones nos hemos topado con la famosa broma (que más que broma es un acto mal intencionado) del «sudo rm -rf» con una diagonal (no lo coloco completo dado que puede venir algún despistado y advierto que no me hago responsable) el cual si un usuario lo ejecuta mal en su terminal puede terminal sin un solo archivo en su sistema y sobre todo quedarse sin sistema. Relacionando este acto con Windows, es algo similar a que si el usuario borrara la carpeta system32 lo cual es algo más conocido, pero sí desconoces, es básicamente dejar tu sistema inservible, ya que estás eliminando todo lo necesario para su funcionamiento.

La razón de mencionar esto, es que en Linux es muy común que los usuarios eliminen algún archivo o carpeta de manera gráfica, es decir, dando clic secundario y “eliminar”, hasta aquí todo bien. Pero cuando ya se entra en algo más avanzado o el usuario prefiere eliminar de raiz y por completo algo, se suele ocupar el comando «rm» el cual si se utiliza con algún argumento realiza la tarea aplicando algún tipo de instrucción, es decir, eliminar sin preguntar (se debe tener cuidado), eliminar carpetas y sub carpetas o, por otra parte, eliminar, pero preguntando en todo momento que se debe hacer con cada archivo y carpeta.

Ya habiendo explicando un poco esto para aquellos novatos, cuya finalidad del artículo es informar sobre un reciente incidente y tengan cuidado con lo que instalan. El motivó del artículo es debido a que hace unos dias los desarrolladores de KDE emitieron una recomendación de no instalar temas y widgets globales no oficiales para KDE.

Esta recomendación la realizaron después de que se enteraron de un incidente en el que un usuario experimentó la eliminación de todos sus archivos personales al instalar el tema Gray Layout desde la Tienda KDE, el cual tenía alrededor de 4000 descargas. Se cree que este incidente no fue causado por intenciones maliciosas, sino por un error relacionado con el uso inseguro del comando «rm -rf».

Los desarrolladores explican que los temas globales de KDE permiten el uso de plasmoides que ejecutan comandos arbitrarios, incluidos aquellos que pueden eliminar archivos.

Esto puede ocurrir cuando se utilizan construcciones como «rm -rf $VAR/*» en el código, lo que puede llevar a una situación donde la variable $VAR no esté inicializada, resultando en la ejecución real del comando «rm -rf /*». Errores similares se han visto anteriormente en scripts de inicialización o instalación de otros programas como Squid, Steam, yandex-disk-indicator y bumblebee.

El incidente específico ocurrió debido a una llamada al código del widget PlasmaConfSaver, que incluye un script save.sh diseñado para eliminar archivos de configuración antiguos de una instalación previa. Este script utiliza el comando «rm -Rf «$configFolder», pero el código no verifica adecuadamente la configuración de la variable $configFolder, cuyo valor se pasa a través del argumento de línea de comando («configFolder=$2»). Esto puede llevar a situaciones donde el valor de la variable configFolder se malinterprete, resultando en la eliminación inadvertida de todos los datos del usuario.

Para evitar que esta situación vuelva a situarse a futuro, los desarrolladores de KDE están planeando auditar los temas de terceros publicados en el directorio de la Tienda KDE para identificar posibles errores similares al incidente previo. También están considerando agregar advertencias al instalar temas de usuarios de terceros y evalúan la posibilidad de implementar una selección previa de proyectos alojados en la Tienda KDE para evitar la colocación selectiva de temas por parte de atacantes con intenciones maliciosas, como robar datos confidenciales o ejecutar procesos para manipular números de billetera criptográfica en el portapapeles de la tienda KDE.

Es importante destacar que muchos usuarios no son conscientes de que la instalación de un tema puede ejecutar código, lo que puede llevar a una falta de atención a la seguridad al instalar temas. Los temas globales no solo afectan la apariencia visual, sino que también pueden modificar el comportamiento de Plasma al incluir implementaciones propias de bloqueadores de pantalla y otros subprogramas que ejecutan código. Debido a limitaciones de recursos, los proyectos en el directorio de la Tienda KDE no se verifican de manera exhaustiva y se publican principalmente basándose en la confianza, a pesar de que cualquiera puede registrar proyectos en el directorio.

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

Nitrux continua con la migración hacia Maui Shell

Se dio a conocer hace poco el lanzamiento de la nueva versión de Nitrux 3.4 con el nombre clave»pl», esto con referencia a que la distribucion continuara utilizando KDE Plasma 5 hasta que los desarrolladores consideren oportuno la migración completa hacia Maui Shell (su propio entorno de escritorio) con lo cual la distribucion no dará el salto hacia Plasma 6, como lo han venido haciendo otras distros que utilizan KDE como entorno de escritorio.

Para quienes desconocen de esta distribución, deben saber que está construida sobre la base del paquete Debian, las tecnologías KDE y el sistema de inicio OpenRC. Esta distribución se destaca por el desarrollo de su propio escritorio «NX», que es un complemento sobre el entorno KDE Plasma del usuario, además de que el proceso de instalación de aplicaciones está basado en el uso de paquetes AppImages.

Como se mencionó anteriormente, las nuevas versiones de Nitrux no usarán KDE Plasma 6. En cambio, continuaremos usando KDE Plasma 5 durante la mayor parte de 2024, ya que la versión 5.27.x es una versión LTS; Si quieres saber por qué, sigue leyendo.

Para permitir a los usuarios interesados ​​en utilizar la versión más nueva de Plasma en la distribución, podemos considerar crear una AppImage de KDE Plasma 6 por diversión . Sin embargo, no se utilizará para proporcionar un entorno de escritorio predeterminado.

Principales novedades de Nitrux 3.4 «pl»

En esta nueva versión que se presenta de Nitrux 3.4 la base de la distribucion se ha actualizado al uso del kernel de Linux 6.7.11 con parches de Liquorix de forma predeterminada, junto con lo cual se ha actualizado el microcódigo para procesadores AMD e Intel, y se han agregado nuevos firmware para adaptadores inalámbricos, GPU y tarjetas de sonido al paquete de firmware de Linux.

Además de ello, se cambió el uso de paquetes con componentes de KDE de los repositorios de Debian en lugar de los repositorios del proyecto KDE Neon, se han actualizado las versiones de varios paquetes, como Firefox 124.0.1, Distrobox 1.7.0.1 y Touchegg 2.0.17, se han propuesto nuevas versiones del controlador AMD Vulkan 2024.Q1.3.

Otro de los cambios que se destaca de esta nueva versión, es que la biblioteca MauiKit, utilizada para crear interfaces de usuario en aplicaciones como Maui Shell y MauiApps, se ha actualizado a la versión 3.3.0 e incluye componentes como cuentas MauiKit, navegación de archivos MauiKit, editor de textos MauiKit, calendario MauiKit, documentos MauiKit y terminal MauiKit.

Screenshot de Nitrux 3.4 pl

La herramienta NUTS (Nitrux Update Tool System) se actualizó a la versión 2.1.3 para facilitar la actualización del sistema y se agregó una configuración en la utilidad de configuración de escritorio para habilitar o deshabilitar la apertura de directorios en Maui Apps con doble clic.

Por otra parte, se incluyeron nuevas aplicaciones, como saferm (protección contra la eliminación del directorio raíz y de inicio), ethtool (gestión de dispositivos Ethernet), Powercap (acceso al subsistema powercap del kernel) y GeoClue (servicio de autobús D-Bus para datos de localización).

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

• System Monitor ahora muestra la temperatura y frecuencia del procesador, y se actualizó la página con los parámetros de la GPU.
• Se eliminó la aplicación Agenda (Calendar Maui) debido a problemas de estabilidad no resueltos.
• Se solucionó un problema con el script de servicio para el demonio multiplexor USB para dispositivos iPhone y iPod Touch (usbmuxd), que impedía que OpenRC iniciara el servicio.
• Se solucionó un problema con el script de servicio para Tor, que impedía que OpenRC iniciara el servicio.

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

Descargar la nueva versión de Nitrux 3.4

Si quieren descargar esta nueva versión de Nitrux deberán de dirigirse a la página web oficial del proyecto en donde podrán obtener el enlace de descarga de la imagen del sistema y la cual podrán grabar en un USB con ayuda de Etcher. Nitrux está disponible para su descarga inmediata desde el siguiente enlace. 

Para aquellos que ya se encuentran sobre una versión anterior de la distribución, pueden hacer la actualización a la nueva versión, tecleando los siguientes comandos:

sudo apt update

sudo apt install --only-upgrade nitrux-repositories-config amdgpu-firmware-extra

sudo apt install -o Dpkg::Options::="--force-overwrite" linux-firmware/trixie

sudo apt dist-upgrade

sudo apt autoremove

sudo reboot

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

En la comunidad Linux, somos muchos los que responderíamos «Fedora» si nos preguntaran cuál es la distribución GNOME por excelencia. Sí, están Ubuntu y Debian, pero la primera cambia la interfaz para ofrecer una experiencia propia y la segunda suele ir varias versiones por detrás de lo último. Es por esto que he tenido que mirar bien la fecha cuando he leído sobre una propuesta que pide que, empezando por Fedora 42, el escritorio de la versión principal pase a ser Plasma.

La descripción de la propuesta reza «Cambiar la experiencia por defecto de Workstation a KDE Plasma. El escritorio GNOME se mueve a una edición/spin separada, manteniendo el bloqueo de la liberación«. El cambio, de producirse, sería dentro de aproximadamente un año, cuando se espera que llegue Fedora 42. Pero, ¿es probable que termine pasando?

La propuesta existe, pero parece poco probable que Fedora 42 pase a usar Plasma

En la descripción se explica que con Plasma 6, KDE Plasma se ha desarrollado con una calidad alta y ofrece una buena experiencia de escritorio. Según la propuesta, «Plasma ha estado a la vanguardia de la creación de una plataforma de escritorio cohesiva que permite al usuario controlar plenamente su experiencia informática».

Además, continua, «Plasma proporciona esta experiencia accesible, altamente flexible y extensible al usuario con previsibilidad en todas las versiones de Plasma. A diferencia de otras experiencias de escritorio como GNOME Shell, las API aprovechadas por los applets / widgets de Plasma han sido más estables a través de versiones «menores» de Plasma, reduciendo la frustración del usuario a largo plazo y promoviendo un ecosistema más saludable para desarrolladores y usuarios por igual«.

Wayland tiene su parte de culpa

Una de razones que motivan la propuesta es Wayland. Hace meses fueron los desarrolladores de PCSX2 los que pusieron a GNOME en el punto de mira, llegando a asegurar que «es un completo desastre». Aunque no son muy fans de Wayland en general, sí que dijeron que al menos en KDE no va tan mal, no es tan buggy.

La propuesta asegura que KDE ofrece la experiencia de escritorio Wayland más avanzada hoy en día, soportando cosas como el escalado fraccional, gestión de colores, ratio de refresco variable en las pantallas compatibles y soporte para aplicaciones X11 heredadas, entre otras cosas.

También se menciona que Plasma está en cada vez más dispositivos, siendo el último en llegar la Steam Deck, pero también está en los aparatos de PINE64 u ordenadores Tuxedo.

En lo personal, yo habría jurado que era al contrario, ya que GNOME pasó a usar Wayland antes que KDE. Pero mis pruebas se han limitado a un uso normal del sistema operativo, y el portátil en donde juego a emuladores tengo KDE en X11. Así que YO no he notado ninguna diferencia, por lo menos a favor de Plasma.

La posibilidad de que sea sólo un toque de atención

A mí, que me gusta mirar las cosas desde diferentes puntos de vista y buscarle los tres pies al gato, la propuesta me parece seria, y que el día 2 de abril siga publicada me hace descartar que sea una broma de April Fools’. Pero, valorando posibilidades, una es que todo esto sea un amago, un farol, un toque de atención para que GNOME siga mejorando su experiencia en apartados como Wayland.

Fedora y GNOME llevan mucho tiempo juntos, yo diría que desde siempre, y el cambio suena irreal. Pero no es imposible. Ubuntu también empezó con GNOME en 2004 y lo abandonó en 2011 para usar Unity. Volvió años más tarde, pero la «aventura» la tuvo.

Fedora es actualmente la experiencia más GNOME que existe, y el matrimonio siempre ha parecido ejemplar. Yo suelo decantarme por el software de KDE y no vería con malos ojos el cambio, pero me suena tan extraño…

Lo único confirmado a estas alturas es que Fedora 42 llegará en el primer cuarto de 2025. Todo lo demás está por ver. ¿Terminaremos viendo a Fedora cambiarse de gorro?

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

A mediados de marzo publicamos un artículo sobre las mejores alternativas a ChatGPT. Entre ellas estaba AnonChatGPT, y entre sus funciones encontramos que no requiere registro. Creo que a muchos nos gusta usar ciertos servicios sin tener que registrarnos, y los mejores ejemplos los encontramos en los diferentes buscadores web. Desde el principio, OpenAI requería una cuenta para poder usar su chatbot, pero ahora se puede abrir y preguntar directamente. O se podrá muy pronto.

Por diferentes medios en redes sociales y la blogosfera de todo el mundo se está publicando la noticia de que ChatGPT ya no requiere registro obligatorio para poder usarlo, pero esto no es así en todos los casos. En el mío sigue apareciendo la ventana para registrarme o iniciar sesión, y no importa el navegador, ni el User Agent ni el idioma que use. Por lo que parece, el lanzamiento está siendo gradual.

ChatGPT sin registro tiene limitaciones

Cuando esta disponible, lo que se ve es algo similar a lo de la captura de cabecera, es decir, directamente el chat con sus ejemplos. Ahora bien, hay ciertas limitaciones que probablemente no sean tales para los que prefieren la versión gratuita:

• No es posible usar GPT-4. La única opción es GPT-3.5, la misma que en la versión gratuita.
• No hay historial de chats más allá de la sesión del navegador. Al cerrarlo, desaparecerán.

Esto sólo es posible en la versión web; las aplicaciones siguen requiriendo una cuenta.

Por qué lo permite OpenAI

El motivo por el que OpenAI permite usar ChatGPT sin registro no se ha hecho público, pero parece que guardar relación con la recopilación de datos para entrenar a su IA. Cuanta más gente lo use, mejor. Y como por defecto está activada la opción de usar nuestros chats para este entrenamiento, recibirán mucha información.

Si no queremos participar en esto, se puede hacer clic en el botón del interrogante que hay arriba a la derecha, entrar en las opciones y desactivarlo, pero las conversaciones se guardarán 30 días como en el modelo gratuito. Esto es algo que hay que hacer en cada uno de los chats que abramos, y se gana un poco de privacidad porque los chats ya no están asociados a ninguna cuenta.

ChatGPT sin registro es oficial, y si no podéis acceder a él desde chat.openai.com, pronto podréis.

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

Hace ya algún tiempo desde que Google liberó chromeOS Flex. Es un sistema operativo que promete resucitar ordenadores viejos, pero yo ya llevaba haciendo eso con Linux más de 10 años. Teniendo en cuenta que probarlo no es tan directo, no lo había hecho hasta hace poco, y si me decidí es porque he heredado un PC muy viejo que, aunque no demasiado bien, funciona. Como no tiene nada importante en el disco duro, pues me lancé.

Cuando lo heredé, tenía un intento de instalación de un Linux que ni siquiera supieron decirme cuál era. Para no pensar mucho, le instalé Kubuntu, pero sólo para comprobar que se podía usar. Le cuesta horrores moverse, pero se mueve. Tras leer varios artículos de autores que aseguran que chromeOS Flex es lo mejor que le ha pasado a sus equipos viejos, quise probarlo más que nada para llevarles la contraria.

Instalación de chromeOS Flex

Para instalar chromeOS Flex, es posible descargar una imagen, pero quise hacerlo de la manera lo más oficial posible. Ésta obliga a instalar la Herramienta de Recuperación de Chromebooks, una extensión para navegadores basados en Chromium… que no funciona en Linux. La primera en la frente, pero bueno. No hay nada que una máquina virtual no arregle. Usar esa herramienta es similar a hacerlo con Raspberry Pi Imager, ya que también permite descargar imágenes antes de grabarlas.

Con el USB creado, lo metí en aquel viejo rockero e inicié. La instalación es básicamente un camino de una única dirección, intuitivo. Mi único pero aquí es que el proceso de instalación no muestra nada más que una imagen en movimiento, y no tenía claro si estaba funcionando o no. Pero la instalación fue rápida.

Una vez se inicia el sistema operativo, estamos ante algo muy Google, con muchas de sus aplicaciones instaladas por defecto. Mi mayor sorpresa fue lo ligero que funciona todo. Pero para de contar. En mi caso, el PC tiene problemas con la virtualización, por lo que no pude hacer uso del subsistema de Linux. Pero la posibilidad existe, todo hay que decirlo.

Ligero de verdad

Me parece importante remarcar que el equipo en el que lo he probado funcionaba sacando la lengua con Kubuntu 23.10 y es solvente con chrome OS Flex. A esto es a lo que se referirán los autores que aseguran que puede resucitar equipos viejos, sobre todo si lo que necesitas vive en el navegador o en aplicaciones web.

El contenedor de Linux puede instalar una versión de las tres últimas de Debian, y ya sabemos que gracias a Distrobox podemos instalar cualquier programa que exista en Linux.

Sin soporte para aplicaciones de Android

Las aplicaciones de Android del chromeOS original se ejecutan en otra especie de subsistema, y para que funcione es necesario virtualizar. Por lo tanto, yo no podría haberlo hecho aunque chromeOS Flex lo soportara. De hecho es algo que probé a través de FydeOS, lo que es chromiumOS con soporte para GApps (Google Apps).

Que no soporte aplicaciones de Android deja a chromeOS Flex como un sistema operativo con aplicaciones basadas en la web al que se le pueden instalar aplicaciones de Linux, pero no es un Linux normal.

A quién va dirigido chromeOS Flex

Con todo lo anterior, os estaréis preguntando si merece la pena y a quién va dirigida esta opción de Google, y ahí tengo mis dudas, pero también otras cosas claras:

• Usuarios cuyo ordenador tenga recursos muy limitados. chromeOS Flex funciona en equipos con 4GB de RAM y sólo 16GB de almacenamiento. Como ya he mencionado, el equipo en el que lo he probado no movía muy bien Kubuntu, y sí trabajaba bien en chromeOS Flex.
• Personas que siempre trabajan con el navegador.
• Usuarios a los que les gusta el ecosistema de Google.

Otras opciones

Alternativas a chromeOS Flex hay muchas, pero menos si lo que queremos es algo con su misma naturaleza. El FydeOS mencionado anteriormente es parecido, e incluso mejor. Tiene una opción para añadir soporte para las GApps, y con esto podremos instalar casi cualquier aplicación de la Google Play. Además, también soporta el contenedor de Linux, con lo que lo tendríamos casi todo.

No todo, porque no es igual que otras distribuciones Linux. Si queremos un Linux tradicional, y tenemos un equipo antiguo, antes de probar chromeOS Flex yo instalaría una distro ligera, a poder ser una con un gestor de ventanas y sin escritorio al uso. Por ejemplo, Manjaro en su edición de la comunidad i3. El motivo principal es que es un sistema completo y no hay que configurar demasiado para personalizarlo.

chromeOS Flex ha llegado a sorprenderme, y por eso he cambiado un poco mi opinión sobre él. La fluidez + interfaz es interesante, pero sigo quedándome con las distribuciones tradicionales, o incluso con FydeOS antes que chromeOS Flex.

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

Las máquinas virtuales existen desde hace mucho tiempo, y, como todo, cumplen una función. Últimamente estoy viendo a cada vez más gente usarlas justamente para instalar Linux, ya que con Windows es más complicado gestionar algunas cosas, pero también las podemos usar como caja de arena, como un entorno seguro en el que hacer pruebas.

Yo usé mi primera máquina virtual, si no recuerdo mal, en 2006, y lo hice para probar Linux antes de dar el salto real. Hoy en día tengo una con Windows, otra con Manjaro y otra con Ubuntu Daily Build, pero también hago otras pruebas. Unas veces por ver las novedades, otras por curiosidad… y otras para evitar romper algo de mi sistema operativo, y aquí expongo algunos estropicios que he visto yo o algún conocido y que podrían haber echado a perder, e incluso lo hicieron por no tomar precauciones, una instalación nativa.

Usar máquinas virtuales para probar antes de instalar

Yo uso en mi equipo principal Manjaro, y tengo otra máquina virtual con Manjaro para probar ciertas cosas. ¿Por qué? Justamente porque antes no lo hacía, y una vez, probando algo con WINE y Bottles, algo salió mal, muy mal, y decidí instalar de cero. Hace ya un par de años de eso, y no lo he vuelto a hacer gracias a esta máquina virtual. Podría haberlo arreglado sin reinstalar, pero mis manías me impiden trabajar con algo que podría tener algún problemilla.

Aunque hacerlo en virtual no siempre es una prueba fiable de cómo deben ser las cosas, yo pruebo mucho software en esa máquina virtual. ¿Que quiero instalar un programa y veo una larga lista de dependencias? Lo pruebo en mi máquina virtual de Manjaro. Luego puedo eliminar software principal, dependencias y huérfanos sin miedo a romper nada importante. Total, si algo va mal, la reinstalo.

Archivos eliminados por accidente

Cuando un conocido se cargó /bin

Conozco el caso de alguien que estaba probando a crear su propio script y, para lanzarlo directamente desde el terminal, no se le ocurrió otra cosa que añadirlo a la carpeta /bin. Lo hizo con privilegios y desde el terminal, y lo copió con cp. Viendo que algo no terminaba de convencerle, se propuso a hacer el camino inverso, y básicamente repitió el comando, pero con rm. Sin fijarse en lo que le decía la primera vez, lo repitió con la flag -f. Explicándolo con la canción del mamut chiquitito, «¿y qué pachó? ¡Mi****! ¡La carpeta /bin se hiso mi****!».

La carpeta /bin contiene gran parte de los ejecutables de un sistema operativo basado en Linux, y sin ella no se puede hacer prácticamente nada. Al haberla eliminado desde terminal, no hay papelera desde donde reciclar. Pasó en una máquina virtual, por lo que no se perdió mucho.

El archivo ubuntu.sources desapareció

Esto me pasó a mí y además recientemente. En Ubuntu y otras distros, hay un archivo de fuentes llamado sources.list, pero en 24.04 habrá cambios y estará en otra ruta y con otro nombre. Esto me pasó en una de mis máquinas virtuales que uso para ver las novedades, más concretamente en la de la Daily Build de Ubuntu. Quería probar WARP, y me estaba dando fallo en el repositorio. Fui a eliminarlo manualmente, me metí en la nueva ruta, le di a eliminar y… bye, bye, ubuntu.sources; me equivoqué de archivo. Ahora bien, esto sí tiene solución y pasa por ir a Software y actualizaciones, volver a marcar las casillas y recargar.

Paquetes no disponibles

En mi Manjaro virtual voy a todo trapo, no me preocupo porque para eso está. Ahí instalo y elimino indiscriminadamente, y en alguna ocasión he intentado hacer algo, como instalar software de AUR, y he visto como da fallo. Eliminar los huérfanos suele ir bien, pero en ocasiones no lo hace. O sí, pero el caso es que no me permitía compilar porque no encontraba un paquete. Podría haberme dado un susto en nativo, pero no en una máquina virtual no. Además, la solución pasó por instalar ese paquete y volver a intentarlo.

El arranque secuestrado por Android

El arranque y algo más. No recuerdo muy bien cómo sucedió, pero me dio por probar Android en un USB, o algo así. Yendo a la mía y sin consultar, hice un «to p’alante» e hice dualboot… o no. En uno de los pasos, el ahora descontinuado Android-x86 consultaba si instalar el arranque, y terminé con el de Android y el de Ubuntu, ambos.

Hace mucho de esto, y yo sabía mucho menos que ahora. Al intentar eliminar el arranque de Android, lo que hice fue cargármelo todo, y al intentar iniciar no encontraba ninguna unidad. Tampoco sabía cómo recuperar portátiles, así que le llevé el mío a un amigo para que lo reparara un conocido informático. Era «x86», y no habría pasado nada de esto si hubiera usado una máquina virtual.

Máquinas virtuales para probar sistemas rápidamente

DistroSea a mí me hace papel. Puedo ir a su página, iniciar un sistema, hacer algunas capturas y escribir un artículo con una imagen propia, por ejemplo. Pero si quiero realizar pruebas exhaustivas, no me vale. El rendimiento no es muy bueno, y en cualquier momento pueden tirarte para hacer espacio. Muchas veces tampoco es necesario instalar un sistema operativo ni crear un Live USB. En un punto medio están las máquinas virtuales que permiten probar sin instalar y, si el equipo lo permite, con un rendimiento medio.

Para qué nos sirven las máquinas virtuales

Las máquinas virtuales no sirven para todo. Por ejemplo, si queremos probar una distribución como Vanilla OS o BlendOS, que son compatibles con aplicaciones de Android, no podemos hacerlo en ellas. Virtualizar en un entorno virtualizado no suele ir muy bien, o no va en absoluto.

Tampoco merece la pena instalar y usar programas pesados o juegos en máquinas virtuales, a no ser que tengamos un equipo muy potente que nos permita darle recursos al sistema huésped. Aún así, todo esto es mejor hacerlo en nativo.

Las máquinas virtuales son útiles

Las máquinas virtuales son útiles, y merece la pena que nos acostumbremos a usarlas para no correr riesgos. Entre los programas que permiten virtualizar y se usan mucho en Linux, GNOME Boxes y VirtualBox están al frente de cualquier ránking. Son un cinturón de seguridad que en este caso salvan a un sistema nativo, entre otras cosas.

code {background-color: rgba(255, 255, 0, 0.18); color: #d63384; padding: 1px 3px; font-family: monospace; border-radius: 2px;}

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