Sin no contáramos con Vivaldi u Opera, que tienen la filosofía de añadir y añadir funciones para tener algo diferente que ofrecer, las novedades en los navegadores web más usados llegan a cuentagotas. Por lo menos para el usuario final, ya que sí se añaden muchas APIs para que los desarrolladores puedan hacer algo más. La novedad más destacada que llegó junto a Chrome 116 es una que está en un punto medio, una API que pronto la podremos aprovechar los usuarios.

Esa API permitiría hacer algo así como lo que se ha intentado representar en la imagen de cabecera. Está claro que es un poco chapucera, pero la intención ha sido mostrar que hay dos pestañas, que el navegador está aquí en LinuxAdictos, pero hay una ventana flotante con un PDF de otra página. Eso es lo que permitiría hacer la nueva API de Picture-in-Picture de documentos del nuevo Chrome 116.

Otras noveades de Chrome 116

La posibilidad de hacer Picture-in-Picture está disponible desde hace mucho en todos los navegadores web más importantes, pero sólo para vídeos. Este Picture-in-Picture para documentos permitiría tener siempre una ventana en primer plano con elementos HTML arbitrarios. Cómo terminará implementándose es algo que veremos con el paso del tiempo. Por ejemplo, podría permitir que los mensajes de chats aparecieran flotando por una página web diferente a la del servicio de mensajería.

Entre el resto de novedades, Chrome 116 añade animaciones de pantalla y visibilidad de contenido, soporte para BYOB para la API Fetch, ruta de movimiento de CSS y algunas otras novedades para desarrolladores. Además y como siempre, se ha aprovechado la ocasión para corregir fallos de seguridad. Las aportaciones de la comunidad están disponibles en este enlace, en donde vemos que un desarrollador ha recibido 30.000$ por su trabajo.

Chrome 116 ya está disponible para descargar desde su página web oficial en paquetes DEB y RPM, y también hay un paquete flatpak en Flathub. Las distribuciones basadas en Arch Linux lo tienen disponible en AUR bajo el nombre de google-chrome, aún por actualizar.

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

zero day es un término ámplio que describe vulnerabilidades de seguridad que son desconocidas para los usuarios y para el fabricante o desarrollador

Hace pocos días el equipo de Google Security dio a conocer mediante una publicación de blog, un informe sobre toda la recopilación del año pasado (2022) relacionado con las vulnerabilidades 0 day en las que aparecieron exploits antes de que se desarrollaran parches para software vulnerable relacionado.

En su informe presentado, mencionan que durante el 2022, el equipo de Project Zero identificó 41 vulnerabilidades 0 day (un 40 % menos que las encontradas en 2021) y que a pesar de una disminución notable en el número de vulnerabilidades, el numero continúa siendo mayor al promedio de los 6 años anteriores.

Esta es la cuarta revisión anual de Google de 0 días explotados en estado salvaje [ 2021 , 2020 , 2019 ] y se basa en la revisión de mediados de año 2022. El objetivo de este informe no es detallar cada hazaña individual , sino analizar las hazañas del año en su conjunto, buscando tendencias, brechas, lecciones aprendidas y éxitos.

Grafica de numero de vulnerabilidades zero day de los ultimos años

Se menciona que la aparición de una gran cantidad de vulnerabilidades del tipo zero day se ve potencialmente facilitada por factores como la necesidad continua de que los atacantes utilicen exploits para llevar a cabo ataques y la simplificación de los métodos para encontrar tales vulnerabilidades, ademas de que el aumento de la velocidad de aplicación de parches obliga a buscar vulnerabilidades este tipo en lugar de utilizar problemas ya conocidos. Este tambien es factor, ya que el desarrollo deficiente de parches permite a los autores de exploits encontrar nuevos vectores de ataque para vulnerabilidades ya conocidas.

Por ejemplo, más del 40 % (17 de 41) de los exploits de día cero identificados en 2022 estaban relacionados con vulnerabilidades previamente reparadas y divulgadas públicamente. Tal oportunidad surge debido a correcciones de vulnerabilidades insuficientemente completas o de baja calidad: los desarrolladores de programas vulnerables a menudo corrigen solo un caso especial o simplemente crean la apariencia de una solución sin llegar a la raíz del problema. Dichas vulnerabilidades de día cero podrían haberse evitado potencialmente con una investigación más exhaustiva y la corrección de las vulnerabilidades.

La disminución en el número de vulnerabilidades 0 day en comparación con 2021 se puede explicar por el hecho de que se necesita más tiempo, conocimiento y dinero para crear exploits, el número de vulnerabilidades explotables disminuye debido al uso más activo de métodos de protección, para cada exploit, a menudo se desarrollan nuevas técnicas operativas.

La disminución de las vulnerabilidades 0 day también puede deberse al uso de métodos de ataque más simples, como el phishing y la distribución de malware. También puede verse afectado por la capacidad de prescindir de exploits para vulnerabilidades ya conocidas debido a que los usuarios retrasan la aplicación de correcciones.

El informe concluye que los exploits para vulnerabilidades parcheadas de día N en Android no son menos efectivos que las vulnerabilidades 0 day debido a la demora de los proveedores en generar actualizaciones. Por ejemplo, incluso si Google corrige rápidamente una vulnerabilidad en la plataforma central de Android, es posible que la solución para esta vulnerabilidad no esté disponible para la mayoría de los usuarios hasta meses después, ya que los fabricantes de dispositivos finales a menudo tardan en trasladar las correcciones a sus revisiones de firmware.

Un ejemplo es la vulnerabilidad CVE-2022-3038 identificada en el motor del navegador Chrome 105 y corregida en junio de 2022. Esta vulnerabilidad permaneció sin parches durante mucho tiempo en navegadores específicos de proveedores como Samsung Internet. En diciembre de 2022, se revelaron hechos de ataques a usuarios de Samsung utilizando un exploit para esta vulnerabilidad (en diciembre, la versión actual del navegador de Internet de Samsung continuó usando el motor Chromium 102, lanzado en mayo de 2022).

Al mismo tiempo, para los navegadores, también hay un cambio en los intereses de los creadores de exploits a favor de las vulnerabilidades de 0-click en lugar de las vulnerabilidades de 1-click. 0-clic se refiere a las vulnerabilidades que no requieren la acción del usuario, por lo general afectan a otros componentes además del código del navegador en sí.

Se menciona que las vulnerabilidades 0-click son difíciles de detectar porque:

• son de corta duración
• A menudo no tienen un indicador visible de su presencia.
• Puede apuntar a muchos componentes diferentes y los proveedores ni siquiera siempre se dan cuenta de todos los componentes a los que se puede acceder de forma remota
• Entregado directamente al objetivo en lugar de ampliamente disponible como en un ataque de abrevadero
• A menudo no está alojado en un sitio web o servidor navegable

Mientras que con los 1-click, hay un enlace visible en el que el objetivo debe hacer clic para entregar el exploit. Esto significa que el objetivo o las herramientas de seguridad pueden detectar el enlace. Luego, los exploits se alojan en un servidor navegable en ese enlace.

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

LXD, un administrador de contenedores del sistema, una herramienta para LXC

Ante la noticia que fue dada a conocer hace algunas semanas por parte de Canonical, sobre cambiar el modelo de desarrollo de LXD como un proyecto empresarial, en lugar de un proyecto comunitario independiente, se ha creado en respuesta a ello Incus.

Para quienes desconocen de LXD, deben saber que este proporciona herramientas para la gestión centralizada de contenedores implementados en un clúster de varios servidores. El kit de herramientas LXC se utiliza como tiempo de ejecución para ejecutar contenedores y LXD se implementa como un proceso en segundo plano que acepta solicitudes a través de la red a través de una API REST y admite varios backends de almacenamiento, instantáneas de estado, migración en vivo de contenedores en ejecución de una máquina a otra y herramientas para contenedores de almacenamiento de imágenes.

Y es que después de 8 años de desarrollo como parte de Linux Containers, Canonical, que es el creador y principal desarrollador de LXD, decidió que era lo más óptimo para el desarrollo de LXD. Esta decisión llevó a mover el código LXD del repositorio lxc/lxd a canonical/lxd , y la página principal del proyecto se convirtió en ubuntu.com/lxd, ademas de que la integración continua para LXD se migrará a los servidores de Canonical.

Este movimiento ha generado muchas preocupaciones a los desarrolladores, ya que uno de los problemas que más preocupa es el código adicional agregado a LXD, que se requiere para ejecutarse en formato snap y haga que LXD sea más difícil de usar y probar.

Sobre esto, Mark Shuttleworth, afirmó que Canonical no tiene la intención de dejar de admitir otras distribuciones en LXD, y que el proyecto continúa desarrollándose públicamente en GitHub y acepta correcciones y cambios de otros colaboradores.

Es por ello que en respuesta a ello se crearon los «Forks», Incus, que curiosamente son dos y coinciden en el mismo nombre, pero que fueron creados por personas diferentes, uno por Alexa Sarai, que trabaja para SUSE y mantiene los paquetes LXD en el proyecto openSUSE y el otro por Stéphane Graber, ex líder del proyecto LXD.

Sobre este último, Stéphane Graber, me gustaría mencionar que renuncio a su puesto de líder del proyecto LXD, una semana después de que Canonical se hiciera cargo de LXD, ya que no tiene la intención de firmar un acuerdo CLA con Canonical. Stefan creó una bifurcación de LXD, también bajo el nombre de Incus y que en su comentario sobre el anuncio de la nueva bifurcación, de Alexa Sarai, Stefan confirmó que el repositorio de la segunda bifurcación debería considerarse el principal.

Sobre el nuevo fork de Alexa Sarai se menciona que se pretende desarrollar una bifurcación del sistema de gestión de contenedores LXD.  La bifurcación se creó debido a la preocupación de que Canonical dejará de admitir correctamente otras distribuciones en LXD, ya que como se menciono los dentro de los planes de Canonical está el centrarse en entregar LXD en formato snap, que se posiciona como el formato principal para instalar LXD.

Y es que en particular, la mayor cantidad de usuarios de LXD no están en Ubuntu, sino en la plataforma ChromeOS, que utiliza la herramienta de compilación ebuild/portage de Gentoo Linux.

Incus (de Alexa Sarai) está trabajando actualmente para eliminar las dependencias redundantes y deshabilitar los enlaces a herramientas y tecnologías específicas de los productos de Canonical. El desarrollo de la bifurcación se realizará con la participación de la comunidad y teniendo en cuenta los intereses de proyectos de terceros.

Se menciona que la bifurcación se realizó en la versión LXD 5.16, lo que hace posible actualizar desde versiones LXD hasta LXD 5.16 inclusive. Es posible que la actualización desde una versión posterior de LXD no funcione, ya que es probable que los dos proyectos comiencen a divergir a partir de este punto.

Incus seguirá monitoreando e importando los cambios relevantes de LXD a lo largo del tiempo, aunque es poco probable que los cambios y características que son específicos de los productos de Ubuntu o Canonical se trasladen.

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

Garuda Linux, la joven distribución basada en Arch que tan buenos comentarios recibe de la comunidad, es diferente. Igual, pero diferente. Es otra opción para usar Linux, pero su diseño, rendimiento y todo tipo de herramientas propias son como una bocanada de aire fresco. Que sea diferente pero igual significa que, aunque haya cosas que se sientan nuevas, en realidad todo lo que usa es algo conocido para el que haya usado Linux durante algún tiempo.

Entre el software conocido que podemos usar tenemos las diferentes tiendas de software. Cualquier distro puede instalar cualquier software center, pero unos van mejor y otros peor, dependiendo de la base y el entorno gráfico. Hoy vamos a explicar cuáles son las mejores tiendas de software que se pueden usar en Garuda Linux, aunque es probable que alguno de vosotros tenga una opinión muy distinta a la mía.

Garuda Linux ofrece tiendas de software desde su asistente (Setup Assistant)

Como ya hemos explicado durante la última semana aquí en LXA, Garuda Linux tiene un asistente que nos ofrece software importante para instalar. En la pestaña «Software centers» hay una selección de lo más recomendado, pero sin ningún orden de importancia. De la lista que muestra la captura anterior, yo eliminaría algunas opciones por no ser tiendas de software y ni siquiera gestores de paquetes, como AppImage Launcher o GNOME Firmware. El primero es un programa para integrar y ejecutar AppImages, y el segundo para gestionar el firmware de nuestro equipo. De todo lo demás, yo me quedaría, o mejor dicho, hablaré de cuatro opciones, una compuesta:

GNOME Software

GNOME Software, o sencillamente Software, es la tienda de software oficial de GNOME. Muchas distribuciones que usan GNOME la tienen instalada por defecto, e incluso Ubuntu usa un fork de la misma. La normal, la no modificada, es compatible con paquetes nativos de la distribución, flatpak y snap, siempre y cuando se instalen los paquetes necesarios, y es una buena opción y fiable.

Sólo hay que tener en cuenta una cosa: Garuda Linux usa KDE como entorno gráfico, y es probable que al instalar GNOME Software se instalen dependencias que no se van a usar con otro software.

Discover

Cuando he dicho que iba a hablar de tres opciones era porque no de todas iba a hablar del todo bien. Discover es la tienda de software de KDE, y por algún motivo siempre se me ha hecho extraño usarla. Cuando he usado Kubuntu o KDE neon sí he dejado la tienda por defecto, en parte porque el software de KDE le sienta muy bien a KDE, pero hay parte de la comunidad que, como quien dice, no la quieren tocar «ni con un palo».

A diferencia GNOME Software, si se usa Discover no hay que preocuparse por instalar dependencias que no se van a usar, ya que estaremos instalando en KDE la tienda de software de proyecto. Al final, creo que entre GNOME Software y Discover es más una cuestión de gustos que cualquier otra cosa.

Bauh

En el titular podemos leer «para no perderte nada», y si es eso lo que se busca, la mejor opción es Bauh. Está escrita en Qt y nos permite, además de instalar paquetes nativos, los flatpak y snap, si se activa el soporte, «instalar» AppImages y aplicaciones web. Si he usado las comillas es porque las AppImages no se instalan, como mucho se integran, y un poco lo mismo para las aplicaciones web.

Haciendo clic en la hamburguesa vemos esas dos opciones. La de las AppImage nos mostrará una ventana con las opciones de integración. Cuando aceptemos, creará un acceso directo en el menú de inicio y la aplicación estará perfectamente integrada. Si lo que queremos es instalar una aplicación web, sólo tenemos que poner una URL, indicarle algunos parámetros, como si se permite el uso de DRM, y darle a crear. Nos instala la app con Electron.

Octopi, Pamac y el terminal, el combo perfecto para Garuda Linux

Para mí, lo más recomendado es usar este combo, o incluso prescindir de Octopi. Lo que viene instalado por defecto es Octopi, que más que una tienda de software es un gestor de paquetes, y se puede trabajar perfectamente con él y actualizando/instalando con el terminal o las herramientas nativas. Pero ni desde el terminal ni con Octopi se van a ver ni aplicaciones destacadas ni capturas.

Como usuario de Manjaro el, mmm 80% del tiempo, al que esté buscando la mejor tienda de software para Garuda Linux le recomendaría usar Pamac. Motivos hay muchos, pero ahora mismo me vienen a la cabeza esas veces que la herramienta nativa del asistente me han dado error al actualizar y Pamac me ha instalado hasta 5GB sin problemas. Además, justamente Garuda no soporta de entrada AUR, sino el Chaotic-AUR de Dr460nf1r3, y activar el soporte en Pamac es tan sencillo como ir a sus ajustes y hacer clic en un interruptor. Pamac también soporta paquetes flatpak y snap, y la interfaz gráfica es sencilla pero efectiva

Está claro que cada uno puede tener sus preferencias, y es probable que muchos prefieran las herramientas nativas de Garuda o tirar de terminal. Lo cierto es que eso sería lo que yo recomendaría usar si nunca hubiera visto problemas que me han impedido instalar una actualización algo grande. Así que lo que haré será justamente eso, recomendar primero las herramientas nativas (terminal y Octopi) y, si se echa en falta algo, Pamac.

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

AOUSD, una alianza para impulsar OpenUSD para estándares abiertos para contenido 3D

Hace pocos días la Fundación Linux, asi como tambien varios de los participantes, dieron a conocer mediante una publicación de blog la creación de la alianza AOUSD (Alliance for OpenUSD) con la cual Pixar, Adobe, Apple, Autodesk y NVIDIA junto con Joint Development Foundation, buscan una promover de manera conjunta la tecnología OpenUSD (Universal Scene Description), su desarrollo y el desarrollo de estándares relacionados.

Sobre esta nueva «Alliance for OpenUSD», se menciona que se creó bajo una plataforma independiente bajo los auspicios de la Joint Development Foundation (JDF), la cual es supervisada por la Fundación Linux.

“En Adobe, creemos en proporcionar a los artistas un conjunto de soluciones potentes y flexibles que se ejecutan en una variedad de dispositivos”, dijo Guido Quaroni, director sénior de Ingeniería, 3D&I en Adobe…

Para quienes desconocen de USD (Universal Scene Description), deben saber que esta es una plataforma de software extensible y de alto rendimiento que fue desarrollada por Pixar, para la construcción colaborativa de escenas animadas en 3D, diseñada para satisfacer las necesidades de la producción de efectos visuales y películas a gran escala.

“OpenUSD ayudará a acelerar la próxima generación de experiencias AR, desde la creación artística hasta la entrega de contenido, y producirá una gama cada vez mayor de aplicaciones de computación espacial”, dijo Mike Rockwell, vicepresidente de Vision Products Group de Apple. 

USD permite un sólido intercambio entre herramientas de creación de contenido digital a través de su conjunto de esquemas en expansión, que cubre áreas como la geometría, el sombreado, la iluminación y la física. Además, la capacidad de composición única del marco de Pixar proporciona formas ricas y variadas de combinar activos.

“Ya sea que esté creando mundos generados por computadora o gemelos digitales o pensando en la web en 3D, los creadores de contenido necesitan una forma cohesiva de colaborar y compartir datos entre herramientas, servicios y plataformas”, dijo Gordon Bradley, Fellow, Media & Entertainment, Autodesk . 

También permite flujos de trabajo colaborativos para que muchos creadores puedan trabajar juntos fácilmente y más. USD se lanzó por primera vez como software de código abierto (como OpenUSD) en 2016, bajo una licencia Apache modificada.

“OpenUSD brinda a los desarrolladores, artistas y diseñadores 3D la base completa para abordar cargas de trabajo de simulación y creación de contenido digital industrial a gran escala con una amplia interoperabilidad de múltiples aplicaciones”, dijo Guy Martin, director de código abierto y estándares de NVIDIA .

Se menciona que OpenUSD, es un sistema para codificar datos escalables, jerárquicamente vinculados, estáticos y distribuidos en el tiempo. OpenUSD proporciona un conjunto de operadores para composición, administración de recursos, procesamiento de múltiples capas y administración de enlaces de archivos que le permiten vincular una serie de recursos dispares en una sola escena gráfica, mientras mantiene la capacidad de procesar y reemplazar cada recurso por separado.

Para la extensión de OpenUSD, se proporciona un sistema de complemento que se puede usar para integrarse con otros formatos y traducir cualquier dato al formato de escena gráfica de OpenUSD.

Se menciona que los miembros de la alianza trabajaran para permitir que los desarrolladores y creadores de contenido describan, compongan y simulen proyectos 3D a gran escala y creen una gama más amplia de productos y servicios 3D. Empresas como Epic Games Hexagon, Foundry, IKEA, SideFX y Unity también se han registrado como los primeros miembros generales de la alianza.

El objetivo de la alianza es mejorar la portabilidad entre aplicaciones de gráficos 3D y desarrollar y estandarizar herramientas universales para transferir datos 3D entre aplicaciones. Las empresas interesadas en asegurar la portabilidad de sus productos tienen la intención de preparar una especificación que describa en detalle todas las características de OpenUSD, que planean aprobar más adelante en la ISO (Organización Internacional de Normalización) como estándar internacional.

Con ello se busca que AOUSD también será el foro principal para la definición colaborativa de mejoras tecnológicas en toda la industria, ademas de que la alianza invita a una amplia gama de organizaciones a unirse y participar en la configuración del futuro de OpenUSD.

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/4lYJ0Id
via IFTTT

AlmaLinux hace recapacitar a Red Hat después de negarse a aceptar un parche

A los desarrolladores de AlmaLinux se les ha presentado la oportunidad de poder demostrar a Red Hat que no son «una amenaza» que dedica únicamente a duplicar otros desarrollos y crear una reconstrucción simple (esto en referencia al comentario realizado por Red Hat por restringir el acceso al código de RHEL)

Y es que justamente poco después de haber realizado el anuncio en el cambio a un nuevo modelo de mantenimiento de distribución, que permite la aplicación de sus propios parches, los desarrolladores de AlmaLinux corrigieron la vulnerabilidad en el paquete iperf3 (ya catalogada bajo CVE-2023-38403 ) e intentaron enviar la corrección preparada a CentOS Stream, ya que la vulnerabilidad permaneció sin parches en RHEL y CentOS Stream.

De manera inicial Red Hat se negó a aceptar la solución, citando la regla de que «solo se pueden solucionar los problemas importantes», ya que para los desarrolladores de Red Hat, dicha vulnerabilidad no era importante y no presentaba un riesgo «importante» como para marcalo como»prioritario» pues otro de sus comentarios fue que las soluciones este tipo de problemas se incluyen en los paquetes solo cuando es necesario, debido a solicitudes de clientes o necesidades comerciales.

Gracias por la contribución. En este momento no planeamos abordar esto en RHEL, pero lo mantendremos abierto para su evaluación en función de los comentarios de los clientes.

Poco después de «la evaluación» por parte de Red Hat de la solución a la vulnerabilidad, el representante de Alma Linux expresó desconcierto, ya que se envió un parche listo para solucionar el problema para su inclusión en CentOS Stream y:

Red Hat no estaba obligado a crear una solución por sí mismo, sino que solo necesitaba revisar el cambio final aceptado en el base de código del proyecto iperf .

El desarrollador de Alma Linux tampoco estuvo de acuerdo en catalogar que la vulnerabilidad es menor, ya que el error corregido conduce a un desbordamiento de enteros y corrupción de la memoria del proceso cuando se pasa un valor incorrecto al campo de tamaño de datos.

Y es que menciona el desarrollador de AlmaLinux que como tal la vulnerabilidad en iperf3, permite enviar un mensaje especialmente diseñado y causar daños en la memoria (es posible un ataque tanto del cliente al servidor como del servidor al cliente). Esto se debe a que iperf3 está diseñado para probar el rendimiento de la red, utiliza un modelo cliente-servidor en el que el cliente envía una solicitud con parámetros al proceso del servidor a través de una conexión TCP, y el servidor realiza la prueba y devuelve el resultado.

En la práctica, la vulnerabilidad permite a un atacante atacar servidores iperf3 de acceso público existentes o crear su propio servidor y atacar a los usuarios que se conectan a través de él. Se supone que la explotación de la vulnerabilidad se limita a bloquear el proceso, pero incluso en este caso, es necesario reparar la capacidad de provocar que el proceso del servidor iperf3 se bloquee de forma remota en servidores de acceso público.

En respuesta, un empleado de Red Hat explicó que el asunto no se limita a un parche terminado y que el desarrollo de una solución es solo una de las etapas en la preparación de una actualización del paquete: debe asegurarse de que la solución pase el control de calidad y luego de ser aplicado en el paquete, no conduce a cambios regresivos.

Nos comprometemos a abordar los problemas de seguridad críticos e importantes definidos por Red Hat. Las vulnerabilidades de seguridad con gravedad baja o moderada se abordarán a pedido cuando existan requisitos del cliente u otros requisitos comerciales para hacerlo.

Por lo tanto, solo las vulnerabilidades críticas e importantes se corrigen sin falta, y los problemas con un nivel de gravedad bajo y medio se resuelven según surge la necesidad.

Finalmente, cabe mencionar que después de la discusión, el equipo de seguridad de Red Hat reconsideró su posición, clasificó el problema como importante, aceptó el parche y lanzó una actualización del paquete para corregir la vulnerabilidad.

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/Ap5mPZB
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.4, versión en la cual se han implementado una serie de correcciones y pequeñas mejoras de las cuales se destaca el soporte para etiquetas de configuración soporte para extensiones KRL y mas.

Para quienes desconocen de OpenSSH (Open Secure Shell) deben saber que este es un conjunto de aplicaciones que permiten realizar comunicaciones cifradas a través de una red, usando el protocolo SSH. Fue creado como una alternativa libre y abierta al programa Secure Shell, que es software propietario.

Principales novedades de OpenSSH 9.4

En esta nueva versión que se presenta de la implementación OpenSSH 9.4 una de sus principales novedades es el soporte para etiquetas de configuración a ssh mediante la directiva «Tag»  y una operación de coincidencia «Match tag» al archivo de configuración ssh_config para permitir el uso de etiquetas para definir condiciones de selección para un bloque de configuración específico.

Otro de los cambios que se destaca de esta nueva versión es que sshd, las directivas AuthorizedPrincipalsCommand y AuthorizedKeysCommand admiten dos secuencias adicionales, las cuales son «%- y %D» para sustituir la dirección de la puerta de enlace a través de la cual se enruta la sesión actual y «%C» para sustituir las direcciones y los números de puerto del lado local y remoto de la conexión

Ademas de ello, tambien se destaca que en esta nueva versión de OpenSSH 9.4 se elimina la compatibilidad con versiones anteriores de libcrypto. Con lo cual a partir de OpenSSH 9.4 se requiere versiones superiores a LibreSSL 3.1.0 y OpenSSL 1.1.1.

Tambien otro de los cambios que causan incompatibilidad y como una forma adicional de bloquear la vulnerabilidad asociada con la capacidad de cargar módulos PKCS # 11 en ssh-agent, está prohibido especificar rutas relativas e incompletas a los módulos (anteriormente, la función dlopen buscaba un módulo por nombre en el directorio de la biblioteca).

Por otra parte, se destaca que se agregó el soporte para conectar extensiones en formato KRL a ssh, sshd y ssh-keygen. Las extensiones en sí aún no están disponibles en esta etapa de desarrollo.

Ademas, en la utilidad ssh-keygen predeterminada, la cantidad de rondas en la función bcrypt se incrementó en un 50 % al generar claves para el cifrado de archivos simétricos con claves protegidas con contraseña.

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

• La utilidad ssh permite la redirección a otro host de socket Unix usando el comando «ssh -W».
• Se agregó la operación «match localnetwork» a ssh lo que permite hacer coincidir con las direcciones de las interfaces de red disponibles y puede usarse para variar la configuración efectiva del cliente según la ubicación de la red.
• sshd proporciona un reemplazo para la función SELinux matchpathcon(), que está en desuso.
• Solucion de problemas de compilación para el módulo de proveedor sk-dummy.so FIDO
  utilizado en algunas pruebas.
• ssh-agent mejora el aislamiento entre los módulos PKCS#11 cargados
  mediante la ejecución de ssh-pkcs11-helpers independientes para cada proveedor cargado.
• En sshd, ssh y ssh-keygen se elimina la compatibilidad residual con las firmas KRL. Esta
  versión elimina el código parcialmente implementado para verificar los KRL.
• ssh-keygen corrige que «no comment» no se muestra cuando se ejecuta `ssh-keygen -l` en varias teclas donde una tiene un comentario y otras teclas siguientes no.
• Se ajusto la lógica ftruncate() para manejar servidores que reordenan solicitudes. Anteriormente, si el servidor reordenaba las solicitudes, entonces el archivo resultante se truncaría por error.

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.4 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.4.tar.gz

Entramos al directorio creado:

cd openssh-9.4

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

Lo confieso, a veces me equivoco. Durante mucho tiempo fui un ferviente defensor de la incorporación de las empresas de software al ecosistema del software libre. Pero, OpenELA es una pésima noticia y la demostración de mi error.

En mi defensa, no son Microsoft o Apple las que están haciendo lo de adaptar, extender y extinguir sino empresas de larga relación con el código abierto como Red Hat, IBM, Oracle, SUSE o Google.

Por qué OpenELA es una pésima noticia

Mi compañero Darkcrizt escribió bastante sobre las recientes decisiones de Red Hat de cerrar el acceso a sus repositorios y cómo respondieron los proyectos de código abierto perjudicados.

La última movida fue la creación de la Open Enterprise Linux Alliance.

El anuncio, publicado el 10 de agosto de 2023 dice concretamente que:

CIQ, Oracle y SUSE anunciaron hoy su intención de formar Open Enterprise Linux Association (OpenELA), una asociación comercial colaborativa para fomentar el desarrollo de distribuciones compatibles con Red Hat Enterprise Linux (RHEL) al proporcionar código fuente Enterprise Linux (EL) abierto y gratuito.

Sobre las metas y plazos del proyecto se explica:

A partir de finales de este año, OpenELA proporcionará las fuentes necesarias para que existan versiones posteriores compatibles con RHEL, con un enfoque inicial en las versiones EL8, EL9 y posiblemente EL7 de RHEL. El proyecto se compromete a garantizar la disponibilidad continua de las fuentes de OpenELA para la comunidad de forma indefinida.

Los principios básicos de OpenELA, que reflejan el espíritu del proyecto, incluyen el pleno cumplimiento de este estándar existente, actualizaciones rápidas y soluciones seguras, transparencia, comunidad y garantizar que el recurso siga siendo gratuito y redistribuible para todos.

Suena fantástico, al menos si eres una compañía que usa Red Hat en su centro de cómputos, un prestador de servicios que no quiere pagar las licencias de Red Hat o una empresa que quiere sacarle mercado a Red Hat por precio o por servicios adicionales.

Pero, no es una buena noticia para el ecosistema Linux.

Estándares acordados y de facto

Hace unos cuantos años, cuando todavía la empresa desarrolladora del navegador Opera estaba en Noruega, un fabricante de hardware les prestó un servidor para que evaluaran la compra.

El encargado de hacerlo se encontró con que no podía entrar a la interfaz web de configuración, revisando el código descubrió que había una instrucción específica que bloqueaba el acceso al navegador Opera.

En aquella época Internet Explorer tenía el dominio casi total del mercado y un absoluto desprecio por los estándares de la W3C. Muchos desarrolladores simplemente se limitaban a bloquear a otros navegadores no compatibles con las tecnologías web de Microsoft.

Es decir que Internet Explorer era un estándar de facto.

Los estándares acordados son aquellos en los que la comunidad se pone de acuerdo con las especificaciones. Algunos ejemplos son HTM, Epub u ODF.

En un proceso conocido como coo-petencia las empresas y organizaciones colaboran para crear y difundir un estándar y compiten por ofrecer el mejor producto compatible con ese estándar.

No es el caso.

Adoptar, extender y extinguir

Adoptar, extender y extinguir es una estrategia para lograr el monopolio en la industria del software. Se compone de los siguientes pasos:

1. Adoptar: Se anuncia el apoyo a un determinado proyecto comunitario o estándar y se le asignan recursos y empleados. Red Hat lo hizo con muchos proyectos de código abierto como GNOME o CentOS.
2. Extender: Se usa el poder que da asignar el recurso y personal a esos proyectos para imponer tecnologías de desarrollo propio en lugar de alternativas. Por ejemplo, Wayland en lugar de X11 o Flatpak en lugar de Appimage.
3. Extinguir: A través de organizaciones controladas directa o indirectamente se logra que las tecnologías del competidor se vuelvan irrelevantes y este deba abandonarlas o hacer más lento su desarrollo. Unity, MIr, Snap.

OpenELA es una mala noticia porque lo que hace es convertir a Red Hat Enterprise Linux en el estándar de facto para las distribuciones empresariales.  Algo parecido a lo que sucedió con Chrome cuando casi todos los navegadores adoptaron su motor de búsqueda como base.

¿Necesitamos un estándar para distribuciones empresariales? Probablemente sí, pero tiene que construirse en base a las mejores tecnologías existentes y no a los intereses comerciales de tres empresas.

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

Con la unión de las distribuciones afectadas por RHEL nace OpenELA

Tal parece que la decisión de Red Hat de restringir el acceso al código de RHEL, ha comenzado a tomar su relevancia y lejos de afectar a distribuciones que están basadas en RHEL (cosa que de un inicio parecía), esto ha llevado no solo a los afectados a tomar carta en el asunto, sino que tambien que proyectos como SUSE, se sumaran al apoyo y esté dando inicio a un movimiento que muy posiblemente pueda tener muy buenos resultados a futuro.

Para poner un poco en contexto a aquellos que aún desconocen de la situación, debo recordarles que a finales de junio Red Hat (IBM) anuncio cambios en la forma en la que distribuiría el código de RHEL, los cuales básicamente son restringir el acceso a este y evitar que distribuciones terceras (Rocky Linux, AlmaLinux, Oracle, entre otras) hagan uso de él.

Esto de inicio llevo a Rocky y AlmaLinux a realizar cambios en el proceso de construcción de sus distribuciones, en su momento comentaron el utilizar los repositorios de Oracle e incluso el aprovechar los vacíos legales. Posterior a ello, se replantearon los cambios que tenían en mente realizar y por su parte AlmaLinux anuncio que ya no sería 1:1 con RHEL y que los cambios no serían notables.

En el caso de Oracle, a este no le tembló la mano y critico fuertemente a Red Hat, algo que para muchos fue algo que no esperaban (principalmente viniendo de Oracle). En su publicación ademas de la critica a Red Hat menciono que Oracle Linux seguiría siendo compatible con RHEL.

En el caso de SUSE este básicamente dio a conocer que crearía un fork de RHEL en apoyo de la comunidad y este sería un proyecto de dominio público organizado por una organización sin fines de lucro independiente.

Y ahora, estas distribuciones que de manera independiente tenían en mente ofrecer soluciones a sus usuarios, han tomado la decisión de unir fuerzas y con ello Rocky Linux, Oracle y SUSE anunciaron que trabajaran en conjunto para la creación OpenELA, con el objetivo de desarrollar conjuntamente una base de paquetes compatible con Red Hat Enterprise Linux.

Con esta nueva asociación se busca que el grupo de desarrolladores de las distribuciones unan esfuerzos para trabajar por la compatibilidad con RHEL. Entre otras cosas, el proyecto ha generado un repositorio que contiene un conjunto de software de origen compartido que se puede utilizar para generar distribuciones que sean totalmente compatibles a nivel binario con RHEL, idénticas en comportamiento (a nivel de errores) a RHEL y utilizables como reemplazo de RHEL.

“ La colaboración es fundamental para fomentar la innovación, por lo que damos la bienvenida a todos a formar parte de esta asociación y ayudarnos a mantener los estándares abiertos de la comunidad ”, dijo Thomas Di Giacomo, director de tecnología y producto de SUSE. “ SUSE cree firmemente en hacer realidad la elección. Junto con la comunidad de código abierto, redefiniremos lo que realmente significa ser abierto y brindar un futuro más sólido para EL. ”

Este nuevo repositorio se puede ver como la solución al repo de git.centos.org, en donde se difundieron los componentes de RHEL para ser utilizados en la distribución. El sitio de OpenELA dará a conocer todas las herramientas que sean necesarias para generar distribuciones que se puedan comparar con las versiones de RHEL 8 y 9, y de ser posible, una variante que se pueda comparar con RHEL 7. Además de los códigos de fuente de los productos, la colectividad también ofrece las herramientas fundamentales para generar distribuciones que sean totalmente compatibles con  RHEL.

Finalmente se menciona que los involucrados se comprometen a mantener el repositorio con altos estándares de calidad, utilizando un proceso de desarrollo completamente abierto y asegurando que las actualizaciones y las correcciones de seguridad se publiquen rápidamente.

El proyecto es abierto, independiente, neutral y controlado por la comunidad, ademas de que la gestión estará a cargo de un comité directivo formado por representantes de la comunidad y miembros de la asociación. Las decisiones se tomarán teniendo en cuenta las opiniones de todos los participantes y partes interesadas.

Cualquier organización interesada, empresas y desarrolladores individuales pueden unirse al trabajo conjunto para mantener el repositorio. Los textos fuente de los paquetes se distribuirán de forma gratuita y sin restricciones.

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

Cuando alguien se plantea usar Linux por primera vez se encuentra con un problema: ¿cuál elegir? No hay un solo sistema operativo basado en Linux cómo en Windows y macOS, que, como mucho, hay que elegir una versión más nueva o una más antigua. Podemos consultar con conocidos, en la web para ver qué es lo más popular o echar un vistazo en DistroWatch, en donde MX Linux lleva mucho tiempo encabezando la lista de distros más populares.

Lo primero que hay que saber es cómo funciona esa lista de DistroWatch. Si en vez de quedarnos en la página principal hacemos clic en «More statistics», iremos a lo que ellos llaman DistroWatch Page Hit Ranking. Además de un poco de historia, el texto explicativo dice que no hay relación ni con el uso ni la calidad, y no debería usarse para medir la cuota de mercado de las distribuciones. Sólo muestran el número de veces que se ha accedido a la información de una distro cada día.

MX Linux, un Debian más simplificado

MX Linux está basado en Debian, y entre sus intenciones está que sea más sencillo de usar. El escritorio que usa por defecto es Xfce, muy popular entre distribuciones y usuarios que prefieren algo ligero y a la vez personalizable. Usa la última versión de Firefox, pero otros paquetes se mantienen en un punto más estable. Cuenta con algunas herramientas propias, como su instalador de paquetes, que soporta el repositorio Backports de Debian o Flatpak, un reparador del arranque, creador de snapshots (copias de seguridad) y para modificar el diseño, entre otras.

¿Explica todo lo anterior el motivo de su popularidad? Bueno, ya dice DistroWatch que lo que muestra su Page Hit Ranking no refleja popularidad real. Sí muestra una especie de interés de sus usuarios por las distribuciones, pero poco más. En este enlace de Truelist vemos que Ubuntu se queda con el 33.9% de cuota de mercado de Linux, seguido por Debian con un 16% y CentOS con un 9.3%. Muy atrás encontramos a Red Hat con un 0.8%, Gento con un 0.5% y Fedora con un 0.2%. El resto de los conocidos se queda por debajo del 0.1%, y un total del 39.1% es desconocido.

Por lo tanto, el más popular es Ubuntu, y luego el Debian en el que se basa MX Linux. Y para el que esté pensando que forma parte de ese 39.1%, sería más fácil creer en esto si en la lista no apareciera Raspbian, ahora conocido como Raspberry Pi OS, que también está basado en Debian.

Justamente lo popular despierta menos interés

Lo que es popular de verdad aparece por todas partes, por lo que solemos estar bien informados. Si llevamos desde abril diciendo que Ubuntu 23.10 usará GNOME 45 no iremos a DistroWatch a mirar nada de Ubuntu porque ya lo sabremos. Hacemos más clic en lo que desconocemos, y si sumamos un poco de información por aquí, un poco de dudas por allá y un poco de popularidad, el resultado es el ranking de DistroWatch.

Quien usa MX Linux trabaja con un sistema operativo fácil de usar, estable, ligero, personalizable y con herramientas útiles, y hablará de ello. Los que escuchamos o leemos esta información, y lo hacemos con frecuencia, sabemos que algo hay y luego iremos a dejar nuestros clics en cualquier medio que ofrezca información sobre el sistema operativo que tanto gusta a quien lo prueba.

Un ejemplo válido es el de Garuda Linux, que hemos escrito varios artículos en las últimas semanas y han recibido buena acogida. Garuda tiene menos de 4 años, es relativamente nuevo, quien lo prueba opina bien sobre él y es bonito, por lo que queremos saber más. No creo que se use ni guste más que KDE neon, que está tres posiciones por detrás en DistroWatch, ni mucho menos que Kubuntu, sabor oficial que está en la posición 45, pero nos interesa más porque hay menos.

Bueno y un poco menos popular

Y eso sería lo que explicaría el por qué MX Linux está ahí siempre. Hay usuarios que se preguntan por qué es tan popular, y entre las respuestas encontramos, primero, que DistroWatch no debería usarse como la mejor referencia, y, segundo, usuarios satisfechos con la experiencia de usuario que ofrece MX Linux. Si gusta y no existe un bombardeo constante subirá, y veremos si alguien lo baja de ahí.

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