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

Intel dio a conocer hace poco, la noticia de que detecto una vulnerabilidad de microarquitectura (catalogada bajo CVE-2023-28746) en los procesadores Intel Atom (E-core), conocida como RFDS (Register File Data Sampling) y el peligro de esta vulnerabilidad radica en que permite determinar los datos utilizados por un proceso que se ejecutaba previamente en el mismo núcleo de la CPU.

RFDS es una vulnerabilidad que comparte similitudes con ataques de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), se diferencia en su método de exposición y los datos expuestos, limitándose a datos de registros obsoletos.

Sobre la vulnerabilidad

La identificación de «RFDS» fue realizada por ingenieros de Intel durante una auditoría interna, aunque no se ha proporcionado información detallada sobre el método de explotación de la misma, los ingenieros de Intel han señalado que el atacante no puede controlar intencionalmente la selección de procesos para la extracción de datos, lo que implica que la exposición de información disponible para su recuperación es aleatoria. Sin embargo, la explotación de RFDS por parte de un actor malicioso que pueda ejecutar código localmente en un sistema podría conducir a la inferencia de valores de datos secretos previamente utilizados en registros, potencialmente comprometiendo la seguridad y confidencialidad de la información.

RFDS se descubrió como parte del extenso trabajo de validación interna de Intel sobre seguridad de microarquitectura. De manera similar a los ataques de ejecución transitoria de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), RFDS puede permitir que un actor malicioso que puede ejecutar código localmente en un sistema infiera los valores de datos secretos que de otro modo estarían protegidos por mecanismos arquitectónicos. RFDS difiere de las vulnerabilidades de MDS tanto en el método de exposición como en los datos expuestos (RFDS expone únicamente datos de registros obsoletos). Ni MDS ni RFDS, por sí solos, brindan a los actores maliciosos la capacidad de elegir qué datos se infieren utilizando estos métodos.

Se menciona que estas fugas afectan a los registros vectoriales utilizados en cifrado, funciones de copia de memoria y procesamiento de cadenas, como en las funciones memcpy, strcmp y strlen. También es posible la fuga a través de registros para almacenar números de punto flotante y enteros, aunque se actualizan con más frecuencia durante la ejecución de tareas, lo que reduce la probabilidad de fugas a través de ellos. Es importante destacar que los datos residuales no permanecen directamente en los registros, sino que se pueden extraer de los archivos de registro mediante técnicas de ataque de canal lateral, como la extracción de datos en la memoria caché de la CPU.

RFDS afecta exclusivamente a los procesadores Atom basados en las microarquitecturas Alder Lake, Raptor Lake, Tremont, Goldmont y Gracemont. Estos procesadores no admiten el modo HyperThreading, lo que limita la fuga de datos a un subproceso de ejecución dentro del núcleo de la CPU actual. Los cambios para abordar esta vulnerabilidad están incluidos en la actualización del microcódigo microcode-20240312-staging.

Los métodos de protección contra esta vulnerabilidad son similares a los utilizados para bloquear ataques previamente identificados, como MDS, SRBDS, TAA, DRPW (Device Register Partial Write), y ataques SBDS (Shared Buffer Data Sampling).

Para protegerse contra las fugas en el kernel y los hipervisores, además de actualizar el microcódigo, es necesario utilizar métodos de protección de software que involucran el uso de la instrucción VERW para borrar el contenido de los buffers de microarquitectura al regresar del kernel al espacio de usuario o al transferir el control al sistema de invitados. Esta protección ya ha sido implementada en el hipervisor Xen y el kernel de Linux.

Para habilitar la protección en el kernel de Linux, se puede utilizar el indicador «reg_file_data_sampling=on» al cargar el kernel. La información sobre la vulnerabilidad y la presencia del microcódigo necesario para la protección se puede evaluar en el archivo «/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling«.

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

Linux es un núcleo mayormente libre semejante al núcleo de Unix.​ Es uno de los principales ejemplos de software libre y de código abierto.

La OpenELA (Open Enterprise Linux Association), una asociación formada el año pasado por CIQ (Rocky Linux), Oracle y SUSE (de la que ya hablamos aquí en el blog en su momento) se ha unido para garantizar la compatibilidad con RHEL (Red Hat Enterprise Linux). Dentro de este marco, han presentado el proyecto kernel-lts, el cual proporcionará soporte adicional para algunas ramas obsoletas de kernels LTS después de que dejen de recibir soporte oficial.

Con el lanzamiento de este proyecto, la versión 4.14, será la primera rama del kernel que recibirá este soporte adicional (esta versión del Kernel fue lanzada en noviembre de 2017 y ha recibido soporte durante 6 años). En enero, el equipo de desarrollo del kernel dejó de mantener esta rama y OpenELA ha asumido el mantenimiento y las actualizaciones para el kernel 4.14 se lanzarán al menos hasta diciembre de 2024. Tras la última versión del kernel de Linux 4.14.336, el equipo de OpenELA ha lanzado las actualizaciones extendidas 4.14.337-openela, 4.14.338-openela y 4.14.339-openela.

El mantenimiento proporcionado por OpenELA seguirá las mismas reglas y procesos que se aplican a los kernels LTS estables normales. No habrá restricciones adicionales, como la vinculación a equipos o productos específicos. Las actualizaciones se publicarán basadas en el trabajo de seguimiento de correcciones en las ramas actuales del kernel y su migración a las ramas LTS extendidas mantenidas por OpenELA.

El proyecto OpenELA kernel-lts es el primer foro para que los proveedores de distribución empresarial de Linux agrupen nuestros recursos y colaboren en esos kernels más antiguos después de que finalice el soporte upstream para esos kernels», dijo Greg Marsden, vicepresidente senior de Oracle Linux, Oracle. «Los proveedores de distribución empresarial de Linux que contribuyen al proyecto kernel-lts tienen kernels empresariales más recientes que recomendamos para la mayoría de las cargas de trabajo».

«Como proveedores de distribución empresarial, a menudo tenemos la tarea de mantener la viabilidad del software incluso después de que finalice el soporte de la comunidad», afirmó Gregory M. Kurtzer, director ejecutivo de CIQ. “Creemos que la colaboración abierta es la mejor manera de mantener la infraestructura empresarial fundamental. A través de OpenELA, los proveedores, los usuarios y la comunidad de código abierto en general pueden trabajar juntos para brindar la longevidad que las organizaciones profesionales de TI requieren para Linux empresarial”

Además de brindar soporte a las ramas del kernel LTS, OpenELA mantiene un repositorio con paquetes que pueden ser utilizados como base para crear distribuciones totalmente compatibles binariamente con Red Hat Enterprise Linux, manteniendo un comportamiento idéntico (a nivel de errores) a RHEL y adecuados para su uso como reemplazos de RHEL. Este repositorio es mantenido conjuntamente por los equipos de desarrollo de distribuciones como Rocky Linux, Oracle Linux y SUSE Liberty Linux, todas compatibles con RHEL. Incluye los paquetes necesarios para crear distribuciones compatibles con las ramas RHEL 8 y 9 (con planes para RHEL 7 en el futuro). Cabe destacar que este repositorio reemplazó al repositorio git.centos.org, que fue descontinuado por Red Hat.

Los desarrolladores del kernel de Linux continúan manteniendo varias ramas a largo plazo, cada una con su propio período de soporte:

1. Rama 6.6: Soportada hasta diciembre de 2026. Esta rama es utilizada en Ubuntu 24.04.
2. Rama 6.1: Soportada hasta diciembre de 2026, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 12 y la rama principal de OpenWRT.
3. Rama 5.15: Soportada hasta octubre de 2026. Esta rama es utilizada en Ubuntu 22.04, Oracle Unbreakable Enterprise Kernel 7 y OpenWRT 23.05.
4. Rama 5.10: Soportada hasta diciembre de 2026, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 11, Android 12 y OpenWRT 22.
5. Rama 5.4: Soportada hasta diciembre de 2025. Esta rama es utilizada en Ubuntu 20.04 LTS y Oracle Unbreakable Enterprise Kernel 6.
6. Rama 4.19: Soportada hasta diciembre de 2024, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 10 y Android 10.

Además, la Fundación Linux proporciona ramas SLTS (Super Long Term Support) basadas en los Kernels 4.4, 4.19, 5.10 y 6.1. Estas ramas SLTS se mantienen por separado y reciben soporte durante períodos extendidos de 10 a 20 años. El proyecto Civil Infrastructure Platform (CIP) es responsable de mantener estas ramas SLTS, con la participación de empresas como Toshiba, Siemens, Renesas, Bosch, Hitachi, MOXA, mantenedores de las ramas LTS del núcleo principal, desarrolladores de Debian y el proyecto KernelCI. Estas ramas SLTS están diseñadas para su aplicación en sistemas técnicos de infraestructura civil y en sistemas industriales críticos.

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/J8TjoF0
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

Hace poco se dio a conocer la noticia por parte de los desarrolladores del proyecto GrapheneOS, sobre una vulnerabilidad que detectaron en Android 14 en la pila Bluetooth LE, el error se debe a una corrupción de memoria introducido en Android 14 QPR2.

Para quienes desconocen de GrapheneOS, deben saber que este es un proyecto que desarrollar una versión segura del código base de AOSP, y ellos fueron quienes detectaron la vulnerabilidad en la pila Bluetooth de Android 14 la cual mencionan que puede ser explotada y permite conducir a la ejecución remota de código.

Sobre la vulnerabilidad, los desarrolladores de GrapheneOS mencionan que esta se origina en el acceso a un área de memoria liberada previamente, lo que se conoce como «uso después de liberación» (use-after-free). El problema se encuentra en el código encargado de procesar audio transmitido a través de Bluetooth LE.

Nuestra compatibilidad con el etiquetado de memoria de hardware para Pixel 8 y Pixel 8 Pro ha descubierto un error de corrupción de memoria introducido en Android 14 QPR2 para Bluetooth LE. Actualmente lo estamos investigando para determinar cómo solucionar o desactivar temporalmente la función recién introducida como solución alternativa.

La identificación de esta vulnerabilidad se debe en parte a la implementación de protecciones adicionales mediante la función hardened_malloc, que utiliza la extensión ARMv8.5 MTE. Esta extensión permite asignar etiquetas a cada operación de asignación de memoria y realizar verificaciones para garantizar el uso correcto de los punteros, evitando así la explotación de vulnerabilidades relacionadas con el acceso a memoria liberada, desbordamientos de búfer, llamadas a funciones antes de su inicialización y uso fuera del contexto actual.

Este error comenzó a surgir después de la actualización a Android 14 QPR2 (versión trimestral de plataforma), lanzada a principios de marzo. En la versión principal del código de Android 14, la funcionalidad MTE está disponible como opción pero aún no se encuentra habilitada de forma predeterminada.

Sin embargo, en GrapheneOS, se ha activado la protección MTE para proporcionar una capa adicional de seguridad, lo que permitió identificar el error después de la actualización a Android 14 QPR2. Este error causó bloqueos al utilizar auriculares Bluetooth Samsung Galaxy Buds2 Pro con firmware que habilitaba la protección basada en MTE. El análisis posterior del incidente reveló que el problema estaba relacionado con el acceso a memoria liberada en el controlador Bluetooth LE, y no fue causado por la integración de la funcionalidad MTE en sí misma.

Por la parte de las posibles soluciones a la vulnerabilidad, los desarrolladores de GrapheneOS mencionan que el deshabilitar el etiquetado de memoria para este proceso no es una solución alternativa aceptable ni siquiera a corto plazo porque es una superficie de ataque importante, independientemente de que este error en particular resulte explotable o no. Esto solo ocurre con ciertos dispositivos Bluetooth LE, no con todos los dispositivos Bluetooth.

La vulnerabilidad mencionada se ha solucionado en la versión 2024030900 de GrapheneOS. Es importante destacar que esta vulnerabilidad afecta a versiones de teléfonos inteligentes que no cuentan con protección de hardware adicional basada en la extensión MTE. Actualmente, la extensión MTE está habilitada únicamente para dispositivos Pixel 8 y Pixel 8 Pro.

Desarrollamos un parche para el error de uso después de la liberación de QPR2 de Android 14 que descubrimos con Bluetooth LE. Nuestra prioridad es lanzar pronto una versión de GrapheneOS con nuestra solución y lo informaremos como un error de seguridad de Android. Esto también debería resolver las regresiones de audio BLE.

La vulnerabilidad se ha observado en los smartphones Google Pixel 8 con firmware basado en Android 14 QPR2. Para los dispositivos de la serie Pixel 8, es posible habilitar el modo MTE en la configuración del desarrollador. Esto se puede hacer accediendo a «Configuración/Sistema/Opciones de desarrollador/Extensiones de etiquetado de memoria». Es importante tener en cuenta que habilitar MTE conlleva un aumento en el consumo de memoria de aproximadamente un 3 %, pero no afecta el rendimiento del dispositivo.

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

Hace poco más de un mes, el Centro de Aplicaciones de Ubuntu cambió de imagen. Lo hizo en Ubuntu 24.04, actualmente en desarrollo, pero también en la última versión estable, 23.10 en el momento de escribir este artículo. Se abrieron hilos preguntando por el cambio, más tarde nos enteramos de que era un bug y poco después volvió a la normalidad. El viaje ha sido de ida, vuelta y vuelta a ir, puesto que en las últimas horas tenemos nuevo icono, pero este cambio parece que se mantendrá. Y el destino, aunque diferente al origen, es un tercer punto.

Del mismo modo que en la vez anterior, si nos desplazamos a la página de GitHub del Centro de Aplicaciones, vemos que hay un commit en el que se describe la eliminación del logotipo anterior y la adición del nuevo. Si nos fijamos en las imágenes, tanto la anterior como la actual tienen en la parte inferior una parte más clara, algo que yo no había visto hasta hoy. La bolsa ha pasado de ser algo más parecido a una maleta a una que se parece más a una de compras.

El Centro de Aplicaciones cambia de look

Lo que es el diseño general queda consistente en el tema por defecto de Ubuntu, a diferencia del del bug que era una imagen plana. Y se espera que sea así a partir de Ubuntu 24.04.

Para ver el nuevo icono, hay que escribir sudo snap refresh en Ubuntu 24.04; en versiones anteriores del sistema operativo de Canonical se sigue con el icono y versiones de la tienda anteriores. Lo que no cambia ni cambiará es que sigue siendo una tienda en formato snap, que prioriza este tipo de paquetes y no soporta paquetes flatpak.

Ubuntu 24.04 Noble Numbat llegará el 25 de abril con las principales novedades de GNOME 46 lanzado la semana pasada y el kernel Linux 6.8.

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

firefox Manifest V3

Hace poco los desarrolladores de Mozilla que están a cargo de Firefox, dieron a conocer sus planes relacionados con el soporte de las versiones 2 y 3 del manifiesto de Chrome en Firefox. Y es que, aunque Google tiene la intención de dejar de admitir complementos que utilicen la segunda versión del manifiesto en las versiones de prueba de Chrome 127  Mozilla ha decidido no dejar de admitir la segunda versión del manifiesto en el futuro previsible.

Además de ello Mozilla asegura que mantendrá la capacidad de lanzar complementos que utilicen funciones no disponibles en la tercera versión del manifiesto. La decisión de no hacer que Firefox sea totalmente compatible con la versión 3 del manifiesto de Chrome sigue vigente. Firefox conservará la API webRequest completa, la cual cambiará al modo de solo lectura en Chrome.

Además, Firefox utilizará el mecanismo de páginas de eventos para conservar el soporte para ejecutar scripts en segundo plano basados en el DOM. Mientras que la tercera versión del manifiesto requiere el uso de Service Workers, los scripts en segundo plano basados en Service Workers aún no son compatibles con Firefox. Sin embargo, los desarrolladores tendrán la oportunidad de definir tanto un controlador basado en páginas de eventos como scripts basados en Service Workers en el complemento, lo que les permitirá crear complementos que cumplan con la tercera versión del manifiesto y funcionen en Chrome y Firefox.

El manifiesto de Chrome define las capacidades y recursos disponibles para las extensiones escritas utilizando la API WebExtensions. Desde la versión 57, Firefox pasó por completo a utilizar la API WebExtensions para desarrollar complementos, abandonando la tecnología XUL.

Esta transición permitió unificar el desarrollo de complementos con otras plataformas como Chrome, Opera, Safari y Edge, simplificó la transferencia de complementos entre diferentes navegadores web y habilitó completamente el modo multiproceso de operación. Firefox proporciona compatibilidad casi total con la segunda versión del manifiesto de Chrome para unificar el desarrollo de complementos con otros navegadores.

Como parte de una iniciativa para facilitar la creación de complementos seguros y de alto rendimiento, y dificultar la creación de complementos lentos e inseguros, Google ha desarrollado la versión tres del manifiesto. Sin embargo, ha habido descontento principalmente debido a la traducción al modo de solo lectura de la API webRequest en la tercera versión del manifiesto.

La principal preocupación con la tercera versión del manifiesto radica en la traducción de la API webRequest al modo de solo lectura, lo que ha generado cierto descontento entre los desarrolladores. Esta API permitía conectar controladores propios que tenían acceso completo a las solicitudes de red y podían modificar el tráfico de manera dinámica. En lugar de la API webRequest, la tercera versión del manifiesto agregó la API declarativaNetRequest, que tiene capacidades más limitadas y proporciona acceso al motor de filtrado integrado sin permitir el uso de algoritmos de filtrado propios.

A pesar de estas diferencias y desafíos, Firefox ha implementado características importantes al adoptar la tercera versión del manifiesto de Chrome:

• Una nueva API de filtrado de contenido declarativo en la cual se ha mantenido la compatibilidad con el antiguo modo de bloqueo de la API webRequest.
• Implementación del mecanismo de Páginas de eventos: Este mecanismo elimina las limitaciones asociadas con el uso de Service Workers y permite que las adiciones de páginas de fondo cumplan con los requisitos de la tercera versión del manifiesto.
• Firefox ha introducido un nuevo modelo de permisos que requiere la aprobación del usuario para cada sitio en el que el complemento desea funcionar.
• Se ha agregado un botón «Extensiones unificadas» para controlar directamente el acceso de cada complemento a los sitios.
• Cambio en el procesamiento de solicitudes de origen cruzado: Se aplican las mismas restricciones de permisos a los scripts de procesamiento de contenido que a la página principal en la que están integrados.
• Firefox ha implementado restricciones para evitar la ejecución de código descargado de fuentes externas, aumentando así la seguridad de los complementos.

Finalmene 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/LBU1Cf2
via IFTTT

Vulnerabilidad GhostRace

Se dio a conocer hace poco, información sobre un nuevo ataque de ejecución especulativa, bautizado como GhostRace (catalogado bajo CVE-2024-2193), este es un nuevo método desarrollado por investigadores de la Vrije Universiteit Amsterdam e IBM para explotar el mecanismo de ejecución especulativa presente en procesadores modernos de Intel, AMD, ARM e IBM.

Los investigadores mencionan que, GhostRace se enfoca en manipular condiciones de carrera especulativas para acceder a áreas de memoria previamente liberadas, lo que puede llevar a la extracción de datos sensibles del kernel de Linux, especialmente en entornos de virtualización donde un atacante en un sistema invitado puede comprometer la seguridad del sistema anfitrión o de otros sistemas invitados.

El funcionamiento del ataque se basa en la ejecución especulativa de instrucciones condicionales con primitivas de sincronización de subprocesos, como mutex y spinlock. Si el procesador predice incorrectamente ramas en el código que manejan estas operaciones, se pueden realizar accesos especulativos a la memoria que ya ha sido liberada. Aunque el procesador descarta estos accesos después de detectar la predicción errónea, los rastros de ejecución permanecen en la memoria caché y pueden ser recuperados mediante técnicas de análisis de canal lateral.

GhostRace requiere la presencia de ciertas secuencias de instrucciones en el kernel, conocidas como gadgets, que son utilizadas para la ejecución especulativa dependiendo de condiciones externas controladas por el atacante. Estos gadgets se forman a partir de secciones de código donde se verifica el estado en un bucle sin fin y se sale del bucle después de eliminar el bloqueo de acceso al recurso. Esto permite activar falsamente una transición y ejecutar instrucciones protegidas por un bloqueo, a pesar de que el recurso permanece bloqueado.

Durante el análisis de la vulnerabilidad, que se realizó en el código del kernel de Linux 5.15.83, se reveló la presencia de 1283 dispositivos que podrían conducir a un acceso especulativo a la memoria ya liberada. Este tipo de ataque representa un riesgo potencial para sistemas de virtualización, cualquier kernel del sistema operativo y programas que utilicen primitivas de sincronización de subprocesos verificadas mediante declaraciones condicionales y se ejecuten en plataformas que permitan la ejecución especulativa de operaciones de ramificación, como x86, ARM, RISC-V, entre otros.

Para probar la vulnerabilidad, los investigadores desarrollaron un prototipo de exploit que demuestra la efectividad del ataque al permitir la extracción de datos de la memoria del kernel de Linux con un rendimiento de 12 KB por segundo y un nivel de confiabilidad similar a los ataques de la clase Spectre. Es importante destacar que este tipo de ataques enfocados en la ejecución especulativa representan un desafío significativo para la seguridad de los sistemas informáticos modernos y requieren medidas de mitigación adecuadas por parte de los fabricantes de hardware y software.

Los desarrolladores del kernel de Linux y las empresas de fabricación de CPU fueron informados sobre este problema a finales de 2023. AMD ya ha publicado un informe sobre la vulnerabilidad y recomienda el uso de técnicas estándar para protegerse contra ataques similares a Spectre v1. Por otro lado, Intel y ARM aún no han respondido a esta notificación.

Aunque los desarrolladores del kernel de Linux no tienen planes inmediatos de implementar la serialización de primitivas de sincronización debido a la pérdida de rendimiento, ya han incorporado restricciones para protegerse contra la técnica de explotación IPI Storming (CVE-2024-26602). Esta técnica de ataque implica interrumpir un proceso en el momento adecuado para proporcionar una ventana de tiempo para el acceso especulativo a la memoria liberada.

Para mitigar este tipo de ataque, se propone utilizar la serialización de primitivas de sincronización mediante la inclusión de una instrucción LFENCE después de la instrucción cmpxchq que verifica el estado de bloqueo. Sin embargo, esta medida de protección conlleva una penalización de rendimiento de aproximadamente el 5 % en el punto de referencia LMBench, debido a que la instrucción LFENCE deshabilita la ejecución preventiva de instrucciones posteriores antes de confirmar todas las operaciones anteriores.

En el caso del hipervisor Xen, los desarrolladores han preparado cambios para implementar el mecanismo de bloqueo protegido LOCK_HARDEN, similar al método BRANCH_HARDEN utilizado anteriormente. Sin embargo, debido a posibles impactos negativos en el rendimiento y la falta de evidencia de ataques en Xen, el modo LOCK_HARDEN está deshabilitado de forma predeterminada.

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

El servicio de localización de mozilla es un servicio abierto y crowdsourced de geolocalización

Mozilla sigue en decadencia y desde la última década, a pesar de aportar ideas y proyectos, Mozilla se ha visto en la incapacidad financiera de poder mantener cada uno de los proyectos que ha lanzado al mercado.

Y aunque la empresa se podría escudar hoy en día con el tema de la pandemia de Covid-19, lo cierto es que la decadencia de Mozilla fue firmada desde que Google Chrome llego a arrebatarle el mercado de usuarios y con ello las ganancias que tenía el navegador se fueron en picada.

Con ello, una gran cantidad de servicios y proyectos de Mozilla han pasado a la historia o han pasado a manos de la comunidad para continuar con el desarrollo de estos proyectos que en su momento prometieron mucho. A pesar de que incluso Mozilla ha tenido que reducir su plantilla de empleados en diversas ocasiones, los fondos para mantener sus proyectos simplemente no son suficientes o eso es lo que al menos nos dice en esta ocasión Mozilla.

En esta ocasión Mozilla dio a conocer la mala noticia de que ha tomado la decisión de dejar de apoyar el servicio de «Mozilla Location Service» (MLS), un proyecto desarrollado por Mozilla desde 2013 para proporcionar un servicio público de determinación de ubicación geográfica basado en información de puntos de acceso Wi-Fi, estaciones base de operadores móviles y direcciones IP emitidas al suscriptor. Sin embargo, el proyecto ha sido cerrado debido a varios factores.

Desde 2019, MLS enfrentó limitaciones debido a acusaciones de infracción de patentes y un acuerdo extrajudicial que estableció restricciones en el número de llamadas API por día para proyectos comerciales. Esto llevó a la disminución de la precisión y a la pérdida de atractivo para Mozilla, especialmente después de que algunos proyectos se negaran a utilizar MLS debido a las restricciones.

La precisión del Servicio de localización de Mozilla (MLS) ha disminuido constantemente. Sin planes de reiniciar el programa Stumbler o aumentar las inversiones en MLS, hemos tomado la decisión de retirar el servicio.

La falta de inversión adicional y la tendencia a la baja en la precisión de la ubicación, junto con la falta de interés en reactivar programas como MozStumbler, han sido citadas como razones para el cierre del proyecto. MozStumbler, que era parte del antiguo Firefox para Android, también dejó de desarrollarse, lo que contribuyó a la disminución de nuevos datos para la base de datos de MLS.

Aunque existen alternativas como TowerCollector y bases de datos abiertas como OpenCellID, la relevancia de la información de ubicación vinculada a MLS ha disminuido significativamente, llevando al cierre del proyecto por parte de Mozilla.

Sobre el caso, también Mozilla compartió un cronograma que implementa el retiro en etapas. El plan de eliminación del servicio se llevará en 5 etapas

1. A partir del 13 de marzo: Se detiene la emisión de nuevas claves de acceso API.
2. El 27 de marzo: Se detiene la aceptación de solicitudes de datos POST a través de la API, y también se detiene la publicación de nuevos volcados de bases de datos para exportar a otros sistemas.
3. El 10 de abril: Todos los volcados de bases de datos publicados anteriormente se eliminan y ya no están disponibles para su descarga.
4. El 12 de junio: Se eliminan todas las claves de acceso a la API, excepto las claves utilizadas en proyectos de Mozilla.
5. El 31 de julio: El repositorio con el código de la plataforma se transferirá a GitHub en modo archivo. El código fuente de la plataforma Mozilla Ichnaea subyacente a MLS seguirá estando disponible bajo la licencia Apache 2.0 para aquellos que deseen reactivar el servicio y mantenerlo internamente.

Finalmente, cabe mencionar que no todo está perdido, ya que Mozilla menciona que el código fuente de la aplicación MLS, Mozilla Ichnaea, seguirá estando disponible bajo la licencia Apache 2.0 y se espera que alguien o alguna comunidad tome cartas en el asunto y continúe con el proyecto.

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/9le03aA
via IFTTT

Logo de Void Linux

Si estás en busca de una distro que sea independiente y que no sea de esas que tienen su base en otras distros y que además que ofrezca un modelo Rolling Release, Void Linux es la solución ideal para ti.

Y es que Void Linux es una de esas distribuciones de Linux que pasan desapercibidas por muchos y que para quienes no la han probado, no saben de lo que se están perdiendo, ya que a diferencia de muchas de las distribuciones populares, Void Linux es una distro qué fue construida desde cero, está centrada para usuarios avanzados y que ofrece una gran cantidad de características.

Void Linux utiliza el administrador del sistema runit para inicializar y administrar servicios, lo cual es una característica distintiva de la distribución. Además, cuenta con su propio administrador de paquetes llamado xbps y sistema de compilación de paquetes llamado xbps-src.

El administrador de paquetes xbps permite instalar, desinstalar y actualizar aplicaciones, gestionar dependencias, y detectar incompatibilidades de bibliotecas compartidas. Es importante destacar que es posible utilizar Musl como biblioteca estándar en lugar de Glibc en los sistemas desarrollados por Void.

Void Linux añade soporte a la Raspberry Pi 5

Como se mencionó al inicio Void Linux es una distribucion basada en el modelo Rolling Release, pero es importante tomar en cuenta que al igual que otras distros basadas en el mismo modelo, suelen ofrecer imágenes del sistema actualizadas, esto con la finalidad de evitar que los usuarios tengan que descargar una gran cantidad de GB en actualizaciones, que desde un inicio se pueden ofrecer.

 La razón de mencionar esto es que hace poco los desarrolladores de Void Linux actualizaron las imágenes del sistema y en estas nuevas actualizaciones ofrecidas se han implementado unos cambios bastante interesantes. Los cambios en las nuevas construcciones de la distribución Void Linux incluyen:

• Actualización de las versiones del paquete para mantenerlos actualizados y mejorar la estabilidad y seguridad del sistema.
• En las compilaciones con el entorno de usuario Xfce, se ha añadido un widget en la pantalla de inicio de sesión que permite seleccionar la distribución del teclado. Esta funcionalidad permite a los usuarios seleccionar su distribución de teclado preferida en la pantalla de inicio de sesión.
• En las compilaciones Live, se ha habilitado un proceso en segundo plano para sincronizar automáticamente la hora exacta del sistema. Este proceso se basa en el servidor NTP Chrony y garantiza una hora precisa en el sistema.
• Para las placas Raspberry Pi que admiten el arranque desde unidades USB, se ha agregado la opción de instalar el sistema en unidades distintas a las tarjetas SD.  La mejora mencionada se aplica a los modelos de Raspberry Pi que admiten el arranque desde almacenamiento USB o NVMe.
• En las compilaciones para placas Raspberry Pi, se ha aumentado el tamaño predeterminado de la partición /boot de 64 a 256 MB. Esto puede mejorar la compatibilidad y la capacidad de almacenamiento para el sistema en estas placas.
• Se ha añadido soporte para la placa Raspberry Pi 5 a las compilaciones rpi-aarch64*. Después de la instalación, se recomienda instalar el paquete rpi5-kernel, que incluye una versión del kernel de Linux optimizada específicamente para las placas Raspberry Pi 5, mejorando así el rendimiento y la compatibilidad con este modelo específico.

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

Descargar y obtener Void Linux

Para los interesados en poder instalar o probar Void Linux, deben saber que las imagenes se encuentran disponibles en versiones basadas en las bibliotecas del sistema Glibc y Musl y con base en ello se han preparado imágenes en vivo con el escritorio Xfce y una consola básica para plataformas como x86_64, i686, armv6l, armv7l y aarch64.  Para el caso de las ediciones ARM de Void Linux, estas admiten placas como BeagleBone/BeagleBone Black, Cubieboard 2, Odroid U2/U3 y Raspberry Pi.

Puedes obtener las imágenes, asi como también consultar la documentación de instalación desde el siguiente enlace.

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

OpenSSH es un conjunto de aplicaciones que permiten realizar comunicaciones cifradas a través de una red, usando el protocolo SSH

Se dio a conocer el lanzamiento de la nueva versión de OpenSSH 9.7, versión en la cual se destaca por iniciar con la implementación de cambios para anticipar la futura obsolescencia de las claves basadas en DSA, asi como también la implementación de algunas nuevas características, correcciones de errores y más.

Para quienes desconocen de OpenSSH, deben saber que esta es una implementación gratuita y de código abierto del protocolo SSH (Secure Shell) que proporciona funcionalidades tanto de cliente como de servidor para comunicaciones seguras a través de una red. El protocolo SSH se utiliza principalmente para acceder de forma remota a sistemas y para transferir archivos de forma segura entre sistemas, especialmente en entornos de red donde la seguridad es una preocupación primordial.

¿Qué hay de nuevo en OpenSSH 9.7?

Una de las características principales de esta nueva versión de OpenSSH 9.7 y como se mencionó al inicio, es el adelanto al plan de desuso futuro del algoritmo de firma DSA y aunque OpenSSH 9.7 conserva la compilación predeterminada con soporte DSA por ahora, proporciona una opción para deshabilitar DSA en tiempo de compilación.

Es importante destacar que, por defecto, el uso de claves DSA se suspendió en 2015, pero el código para admitir DSA se mantuvo predeterminadamente y permitió la activación de DSA a través de la configuración. En la próxima versión, programada para junio, el modo de compilación cambiará para deshabilitar DSA de forma predeterminada, y OpenSSH tiene previsto eliminar el soporte para DSA a principios de 2025

Esta decisión se debe a que el algoritmo DSA fue necesario para la implementación en el protocolo SSHv2 debido a las restricciones de patentes en el momento de su creación y aprobación. Sin embargo, con el paso del tiempo, las patentes asociadas con RSA han expirado, y se han introducido algoritmos como ECDSA, que ofrece mejor rendimiento y seguridad que DSA, y EdDSA, que es aún más seguro y rápido que ECDSA. Estos avances tecnológicos han llevado a la decisión de anticipar la obsolescencia de DSA en OpenSSH.

Además de los cambios relacionados con DSA, OpenSSH 9.7 presenta varias mejoras y características adicionales y una de estas mejoras es la introducción de un nuevo tipo de tiempo de espera en ssh y sshd, que se activa al especificar el valor «global» en la directiva ChannelTimeout. Este tipo de tiempo de espera monitorea todos los canales abiertos y cerrará todos los canales abiertos si no hay tráfico en ninguno de ellos durante el intervalo especificado. Esta función es útil en situaciones donde se tienen múltiples canales abiertos, como sesiones y reenvío y se desea cerrarlos si permanecen inactivos durante un período prolongado.

Por otra parte, OpenSSH 9.7 también incluye varias correcciones de errores para mejorar la estabilidad y el rendimiento. Estas correcciones abarcan áreas como el análisis de configuración, el manejo de señales y la mejora de las pruebas de interoperabilidad contra otras implementaciones de SSH.

De los demás cambios que se destacan de esta nuevá versión de OpenSSH 9.7

• OpenSSH incluye una mejora significativa en las pruebas de compatibilidad con el proyecto PuTTY.
• En términos de portabilidad, se han realizado mejoras en la detección de cadena de herramientas rota y se ha mejorado el mensaje de error en ciertas situaciones, lo que contribuye a una experiencia de usuario más fluida y eficiente.

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

¿Como instalar OpenSSH 9.7 en Linux?

Para quienes estén interesados en poder instalar esta nueva versión de OpenSSH en sus sistemas, de momento podrán hacerlo descargando el código fuente de este y realizando la compilación en sus equipos.

Esto es debido a que la nueva versión aún no se ha incluido dentro de los repositorios de las principales distribuciones de Linux. Para obtener el código fuente, puedes hacer desde el siguiente enlace.

Hecha la descarga, ahora vamos a descomprimir el paquete con el siguiente comando:

tar -xvf openssh-9.7.tar.gz

Entramos al directorio creado:

cd openssh-9.7

Y podremos realizar la compilación con los siguientes comandos:

./configure --prefix=/opt --sysconfdir=/etc/ssh
make
make install

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

Screenshot de TileOS

Últimamente están comenzados a ganar terreno las distribuciones centradas en el uso de administradores de ventanas en mosaico, y es que no es para hacerlas menos dado que el uso administradores de ventanas en mosaico en lugar de un entorno de escritorio completo dígase por ejemplo, Gnome, KDE, Cinnamon o incluso XFCE, suelen ofrecer un gran rendimiento y una menor demanda de recursos.

Por otra parte, en comparación de hace unos 10 e incluso 5 años atrás, los administradores de ventanas en mosaico no solían ser tan atractivos visualmente, esto claro no de primera mano, ya que si eras un entusiasta y destinabas el tiempo suficiente podías tener un escritorio bastante «elegante».

El motivo de mencionar esto y como mencione, «hoy en dia», ya existen diversas distribuciones que nos pueden entregar un escritorio decente que utilicé un administrador de ventanas en mosaico y en esta ocasión vamos a hablar un poco sobre TileOS.

¿Qué es TileOS?

TileOS es una distribucion de Linux basada en Debian que ofrece un entorno de escritorio que utiliza administradores de ventanas en mosaico y está diseñado para proporcionar una experiencia lista para usar, sin necesidad de configuraciones adicionales, y está dirigido tanto a usuarios experimentados de Linux como a principiantes que deseen explorar un entorno de administrador de ventanas en mosaico sin dedicar mucho tiempo a la configuración.

TileOS tiene objetivos similares a otras distribuciones como Ubuntu Sway Remix, pero se destaca por su flexibilidad en cambios y personalizaciones, así como por su enfoque en administradores de ventanas que utilizan el protocolo Wayland.

Una de las características más notables de TileOS es que se centra en los administradores de ventanas que emplean el protocolo Wayland. Oficialmente, se han lanzado ediciones con los entornos de escritorio Sway y River, y actualmente se están desarrollando versiones con SwayFX (una variante de Sway con varios efectos visuales integrados) y Qtile.

Aunque la distribución se basa en la rama estable de paquetes Debian, se han incorporado mejoras y versiones más recientes de controladores de software y gráficos desde la rama de pruebas. Además, el paquete incluye correcciones que optimizan el rendimiento del subsistema de almacenamiento y memoria, junto con mejoras provenientes de Ubuntu, como la capacidad de montar discos en el administrador de archivos sin solicitar contraseña, entre otras características adicionales.

TileOS 1.0 «T-Rex»

Actualmente, la distribución se encuentra sobre su versión TileOS 1.0 «T-Rex», la cual cuenta con el Kernel Linux 6.6.15  con optimizaciones para mejorar el tiempo de respuesta, utilizando la opción CONFIG_HZ=1000, en contraste con la configuración estándar de Debian que emplea CONFIG_HZ=300.

En TileOS 1.0 se implementaron mejoras en Calamares, permitiendo a los usuarios seleccionar y personalizar el software adicional durante la instalación. Además, utiliza D-Bus Broker como la implementación del bus del sistema D-Bus y PipeWire como servidor de sonido, mejorando la gestión del sistema y la experiencia de audio.

Tambien cuenta con un conjunto de controladores de vídeo de código abierto, como Mesa 23.2.1 y Xwayland 23.2.2. Además, viene con el motor Zram habilitado de forma predeterminada, utilizando el algoritmo de compresión zstd para mejorar el rendimiento del sistema.

En cuanto a la compatibilidad de hardware, TileOS preinstala una amplia gama de controladores y firmware propietarios, lo que amplía significativamente la compatibilidad con diferentes dispositivos. También proporciona acceso a repositorios con software adicional, como VirtualBox, Visual Studio Code, Librewolf, OnlyOffice y Brave, conectados de forma predeterminada para facilitar la instalación de herramientas y aplicaciones populares.

Para la administración de sesiones de usuario, TileOS utiliza systemd, lo que garantiza un cierre adecuado de aplicaciones y componentes al reiniciar, apagar o cerrar sesión, y facilita el procesamiento correcto del inicio de la aplicación. En la edición Sway, TileOS utiliza systemd-oomd como el demonio OOM Killer, mientras que otras ediciones utilizan EarlyOOM para gestionar eficazmente la memoria.

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

Descargar y obtener TileOS

Para los interesados en probar o instalar TileOS, deben saber que la imagen del sistema está disponible solo para la arquitectura amd64 y se menciona que se tienen planes futuros para soporte para arm64, especialmente para las placas Raspberry Pi.

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