ToaruOS es un sistema operativo «completo» para PC x86-64 y soporte experimental para ARMv8.

A finales del año pasado compartí aquí en el blog la noticia del lanzamiento de un sistema operativo que llamo la atención de muchos, este sistema tiene el nombre de ToaruOS, que lo interesante de este OS es que está escrito desde cero y provisto con su propio kernel, cargador de arranque, biblioteca C estándar, administrador de paquetes, componentes de espacio de usuario y una interfaz gráfica con un administrador de ventanas compuesto.

Inicialmente, el proyecto se desarrolló en la Universidad de Illinois como un trabajo de investigación en el campo de la creación de nuevas interfaces gráficas compuestas, pero luego se transformó en un sistema operativo independiente.

Sobre ToaruOS

En el corazón de ToaruOS hay un kernel que utiliza una arquitectura modular híbrida que combina una base monolítica y medios para usar módulos cargables, en la forma en que se diseñan la mayoría de los controladores de dispositivos disponibles, como controladores de disco, sistema de archivos, teclado, mouse, tarjetas de red, chips de sonido y complementos para invitados de VirtualBox.

El núcleo es compatible con subprocesos de Unix, TTY, sistema de archivos virtual, sistema de pseudo archivos /proc, subprocesos múltiples, IPC, ramdisk, ptrace, memoria compartida, multitarea y otras características comunes.

El sistema está equipado con un administrador de ventanas compuesto, admite archivos ejecutables vinculados dinámicamente en formato ELF, multitarea, una pila de gráficos, puede ejecutar Python 3 y GCC. ext2 se usa como sistema de archivos. El gestor de arranque es compatible con BIOS y EFI. La pila de red permite API de socket de estilo BSD y admite interfaces de red, incluido el bucle invertido.

De las aplicaciones nativas destaca el editor de código Bim tipo Vi, que se ha utilizado durante los últimos años para desarrollar aplicaciones específicas de ToaruOS como un administrador de archivos, un emulador de terminal, un panel gráfico con soporte para widgets, un administrador de paquetes, así como bibliotecas para imágenes compatibles (PNG, JPEG) y fuentes TrueType.

Para ToaruOS se han portado programas como Vim, GCC, Binutils, FreeType, MuPDF, SDL, Cairo, Doom, Quake, emulador de Super Nintendo, Bochs, etc.

Principales novedades de ToaruOS 2.1

Se ha dado a conocer el lanzamiento de la nueva versión de ToaruOS 2.1 versión en la cual se agregó soporte inicial para la arquitectura AArch64 (ARMv8), incluida la capacidad experimental de usar ToaruOS en la placa Raspberry Pi 400 y en el emulador QEMU.

Otro de los cambios que se destaca es que se ha rediseñado el procesamiento y el paso de señales a procesos en el espacio del usuario, ademas de que se implementaron llamadas a sigaction, sigprocmask, sigwait y sigsuspend.

Ademas de ello la gestión de memoria ha sido mejorada en el espacio de usuario, asi como tambien la Pila de red y la representación del terminal, se implementó la representación diferida y se agregó un caché de glifos para las fuentes TrueType.

Tambien se han agregado mecanismos para configurar el reloj, incluida la llamada al sistema settimeofday y capacidades ampliadas de la utilidad de fecha.

De las demás novedades que se destacan de esta nueva versión:

• Se agregó la llamada al sistema munmap.
• El administrador compuesto tiene un efecto de desenfoque y un manejo de eventos rediseñado cuando se cambia el tamaño de la ventana.
• Se ha agregado soporte para configurar direcciones IPv4 y configuraciones de enrutamiento a la utilidad ifconfig. Compatibilidad con conectores ICMP.
• Se agregó soporte para la función recvfrom para sockets UDP e ICMP.
• Se agregó la capacidad de trabajar con teclados USB en el gestor de arranque.
• Se ha agregado un elemento para eliminar archivos al menú contextual del administrador de archivos.
• Visualización mejorada de gráficos en el monitor del sistema.
• Se agregó la utilidad grep con soporte para expresiones regulares.
• Salida mejorada del comando ps (columnas adicionales agregadas).

Finalmente si estás interesado en poder conocer más al respecto, debes saber que el código del proyecto está escrito en C y se distribuye bajo la licencia BSD, de igual forma puedes consultar los detalles en el siguiente enlace.

Descargar y obtener ToaruOS 2.1

Para los interesados en probar esta nueva versión, ha preparado una imagen en vivo para su descarga, de 14,4 MB de tamaño, que se puede probar en QEMU, VMware o VirtualBox.

El enlace es este.

from Linux Adictos https://ift.tt/6NAPxra
via IFTTT

Esta semana, un conocido me ha preguntado qué podría instalarle a un portátil que ya no puede actualizar su versión de Windows. Yo le respondí, claro, que alguna versión de Linux, concretamente alguna que aún soportara los 32bits, y una de las opciones es una versión pasada de lo que han lanzado hoy. Y es que esta tarde se ha hecho oficial el lanzamiento de Zorin OS 16.2, una versión que, por cierto, ya no soporta los 32bits.

Este lanzamiento llega un año después de Zorin OS 16, y unos cinco meses después de 16.1. Es una actualización que refina lo existente en versiones pasadas, entre lo que está que ahora es más fácil instalar aplicaciones de Windows. El soporte se puede activar desde el menú/herramientas del sistema/Soporte de aplicaciones de Windows.

Otras novedades de Zorin OS 16.2

Zorin OS 16.2 mejora la experiencia de ofimática, introduciendo alternativas a las fuentes de Microsoft de código abierto. Siguiendo con la ofimática, 16.2 incluye la última versión de LibreOffice, a saber, la serie 7.4. Además, se han actualizado las aplicaciones a versiones más nuevas, entre las que está Firefox.

Por otra parte, se ha mejorado el soporte de Zorin Connect. Entre las novedades, las estadísticas de la batería se comparten con el teléfono vinculado. Otras cosas que se pueden hacer ahora con Zorin Connect:

• Envía el portapapeles del teléfono con un solo toque desde la pantalla de inicio de la aplicación del teléfono.
• Opción de mostrar las notificaciones en el ordenador sólo si la pantalla del teléfono está apagada.
• Añadir controles de bucle y reproducción aleatoria a Control Multimedia (para los reproductores multimedia compatibles).
• Permitir la configuración de la acción para los clics izquierdos en la Entrada Remota.
• Nueva pantalla «Acerca de».

En esta versión se han añadido retoques estéticos, como el efecto flan de las ventanas, y se ha mejorado la seguridad, así como la compatibilidad con nuevo hardware. Y es que Zorin OS 16.2 usa el kernel de Ubuntu 22.04, es decir, Linux 5.15.

Los usuarios existentes ya pueden actualizar desde el mismo sistema operativo. La nueva imagen está disponible en este enlace.

Imagen y fuente, blog de Zorin.

from Linux Adictos https://ift.tt/6JgZ4Rt
via IFTTT

En este post empezaremos haciendo un sitio con Bootstrap, el framework de código abierto que nos facilita hacerlo responsivo y dotarlo de cierta interactividad. Se trata de un template básico generado automáticamente por un complemento del entorno de desarrollo que recomendamos antes y que deberemos ir modificando.

En el artículo anterior encontrarás las instrucciones para instalar VS Codium, traducir su interfaz de usuario al español e instalar el complemento de Bootstrap.

Dos cosas que debes tener en cuenta:

1. Los comandos que usamos son atajos de teclado, tienes que tipearlos. No funciona el Copy/paste.
2. Nuestro gestor de contenidos no me permite mostrar el código HTML por lo que debo usar capturas de pantalla. Para que tengas acceso al código de los ejemplos los subí a GitHub.

Cómo clonar un repositorio GitHub

Lo que separa a los grandes del resto de nosotros es la forma en la que reaccionan a los problemas. A Richard Stallman no le gustaba el driver de su impresora y como no lo dejaron cambiarlo inició el movimiento del software libre. A Linus Torvalds no le convencía ninguna de las plataformas para compartir código y creó la suya propia. Git.

A diferencia de los tradicionales sistemas de distribución de software en el que la única interacción permitida al usuario es la descarga, con Git se puede seguir la evolución del proyecto a lo largo del tiempo. Otras personas pueden clonar el repositorio, hacer modificaciones y proponerles a los desarrolladores del proyecto original que las incorporen. En caso de aceptarlas, los desarrolladores pueden hacerlo fácilmente sin tener que descargar y volver a cargar los archivos.

Existen varios servicios basados en Git, yo elegí GitHub simplemente porque se integra con VS Codium.

Para poder descargar los archivos de ejemplo en tu ordenador solo necesitas instalar el paquete git siguiendo las instrucciones de tu distribución para instalar paquetes en la terminal.

Luego escribes los siguientes comandos.

Yo prefiero guardar los archivos en la carpeta Documentos por eso cambio el directorio con

cd Documentos

Luego clono los archivos con:

git clone https://github.com/dggonzalez1971/bootstrap.git

Te voy a recordar estos pasos en cada uno de los artículos que restan ya que de esta forma irás actualizando los archivos de ejemplo a medida que los vaya subiendo.

Para ver los archivos solo abre el explorador de archivos y busca la carpeta bootstrap.

Haciendo un sitio con Bootstrap

En el caso de que prefieras tipear el código manualmente comenzamos creando una carpeta en la que guardaremos el sitio. Puedes ponerle el nombre que te guste.

Luego seguimos los siguientes pasos:

1. Vamos al menú Archivo.
2. Pulsamos en Nuevo Archivo de texto.
3. Pulsamos sobre Guardar.
4. Buscamos la carpeta que creamos y ponemos al archivo el nombre ejemplo1.html.
5. Pulsamos en Guardar.

A veces es posible que la ventana del Explorador de archivos quede oculta por la de VSCodium.

Vamos a hacer que la extensión nos cree la plantilla básica. Para esto tipeamos !b5-$

Esto generará el código que vas a encontrar en la carpeta de ejemplos como ejemplo1.html

Veremos lo siguiente:

Este es el código generado por la extensión de Bootstrap.

A este archivo vamos a hacerle algunos cambios. Encontrarás las modificaciones bajo el nombre ejemplo2.html

• En la línea 2 cambiamos el idioma reemplazando eng por es. Esto indica a los buscadores que el idioma del sitio es el español.
• En la línea 6 cambiamos el texto que está bajo las etiquetas title. Ponemos Mi primer sitio Bootstrap.
• En la línea 12 cambiamos el contenido entre las etiquetas h1 por Esto es un sitio hecho con Bootstrap.

A continuación, realizaremos unas modificaciones importantes. Esas modificaciones tienen que ver con:

1. El desarrollador del complemento no puede seguir el ritmo de las versiones de Bootstrap y hay otras más actuales.
2. Hay muchas opciones de componentes bootstrap y a mi me interesa otra.
3. Según la documentación oficial, la llamada a las librerías Javascript deben estar dentro de las etiquetas body.

Para el ejemplo 2 modificamos el contenido de la línea 7, borramos la línea 8 y 9 y subimos el contenido restante para mantener la compatibilidad en la numeración. Luego pulsamos en el final de la línea 10 para crear una nueva línea 11 y poner el enlace a las librerías Javascript.

No te preocupes si no entiendes el código. Voy a explicar la función de cada línea en el próximo artículo.

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

El soporte RISC-V en Android abre un nuevo panorama de posibilidades

Hace poco, mediante una publicación de blog RISC-V anuncio que en el repositorio AOSP (Android Open Source Project) que desarrolla el código fuente de la plataforma Android, ha comenzado a incluir cambios para soportar dispositivos con procesadores basados ​​en la arquitectura RISC-V.

El conjunto de parches de soporte de RISC-V fue preparado por Alibaba Cloud e incluye 76 parches que cubren varios subsistemas.

Dentro de los trabajos realizados se incluye la pila de gráficos, el sistema de sonido, los componentes de reproducción de video, la biblioteca biónica, la máquina virtual dalvik, los marcos, las pilas Wi-Fi y Bluetooth, las herramientas para desarrolladores y varios módulos de terceros, incluidos modelos para TensorFlow Lite y módulos de aprendizaje automático para reconocimiento de texto, clasificación de sonido e imagen.

Del conjunto total de parches, 30 parches relacionados con el entorno del sistema y las bibliotecas ya se han integrado en AOSP. Durante los próximos meses, Alibaba Cloud tiene la intención de lanzar parches adicionales para AOSP para habilitar la compatibilidad con RISC-V en el kernel, Android Runtime (ART) y el emulador.

“¡Nos complace ver más apoyo de Google para crear AOSP dirigido a RISC-V! Alibaba Cloud se ha comprometido a apoyar a la comunidad RISC-V a través de una serie de innovaciones, como el avance de la migración de funciones básicas de Android a RISC-V, lo que demuestra la viabilidad de usar dispositivos basados ​​en RISC-V en escenarios que van desde multimedia hasta señal procesamiento, interconexión de dispositivos e inteligencia artificial. Esperamos colaborar con el equipo de Android para contribuir a la próspera comunidad RISC-V en el futuro”, dijo el Dr. David Chen, Director de Ecosistema de Alibaba Cloud y Vicepresidente del Comité Horizontal de Aplicaciones y Herramientas de RISC-V International. .

“RISC-V ha crecido en popularidad a través de la gran demanda de flexibilidad y opciones en todo el espectro de la informática, desde los dispositivos integrados más pequeños hasta las implementaciones de nube de escalamiento horizontal más grandes”, dijo Calista Redmond, CEO de RISC-V International. “Esta demanda ha hecho que RISC-V sea inevitable como el estándar abierto ISA más prolífico de nuestro tiempo, acelerando la innovación y la adopción con el ecosistema más fuerte de partes interesadas globales”.

Para admitir la compatibilidad con RISC-V en Android, RISC-V International ha creado un SIG de Android dedicado al que pueden unirse otras empresas interesadas en ejecutar la pila de software de Android en procesadores RISC-V. El traslado de la compatibilidad con RISC-V a la corriente principal de Android se está realizando en colaboración con Google y la comunidad.

Los cambios propuestos para Android forman parte de una iniciativa para ampliar el alcance de los dispositivos basados ​​en la arquitectura RISC-V.

En 2020, ingenieros y desarrolladores de software del laboratorio PLCT de la Academia de Ciencias de China comenzaron a migrar Android 10 a la arquitectura RISC-V en un esfuerzo por abrir este importante ecosistema a la comunidad RISC-V. Desde los primeros días del esfuerzo, la división Alibaba Cloud ha sido una estrecha colaboradora y líder en este trabajo pionero y ha mantenido el desarrollo actualizado con versiones más nuevas de Android.

El año pasado, Alibaba abrió los desarrollos relacionados con los procesadores XuanTie RISC-V y comenzó a promover activamente RISC-V no solo para dispositivos IoT y sistemas de servidores, sino también para dispositivos de consumo y varios chips especializados, cubriendo diversas aplicaciones desde sistemas multimedia hasta señales de procesamiento y aceleradores para el aprendizaje automático.

Para quienes desconocen de RISC-V, deben saber que este proporciona un sistema abierto y flexible de instrucciones de máquina que le permite crear microprocesadores para aplicaciones arbitrarias, sin requerir regalías y sin imponer condiciones de uso. RISC-V permite la creación de SoC y procesadores completamente abiertos.

Para los interesados, deben saber que actualmente, en base a la especificación RISC-V, diversas empresas y comunidades bajo diversas licencias libres (BSD, MIT, Apache 2.0) están desarrollando varias decenas de variantes de núcleos de microprocesadores, alrededor de un centenar de SoC y chips ya fabricados. La compatibilidad con RISC-V ha estado presente desde los lanzamientos de Glibc 2.27, binutils 2.30, gcc 7 y Linux kernel 4.15.

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

Sigstore se puede considerar como un Let’s Encrypt para código, que proporciona certificados para firmar código digitalmente y herramientas para automatizar la verificación.

Google dio a conocer mediante una publicación de blog, el anunció de la formación de las primeras versiones estables de los componentes que forman el proyecto Sigstore, que se declara adecuado para crear implementaciones de trabajo.

Para quienes desconocen de Sigstore, deben saber que este es un proyecto que tiene la finalidad de desarrollar y proporcionar herramientas y servicios para la verificación de software utilizando firmas digitales y manteniendo un registro público que confirma la autenticidad de los cambios (registro de transparencia).

Con Sigstore, los desarrolladores pueden firmar digitalmente artefactos relacionados con aplicaciones, como archivos de lanzamiento, imágenes de contenedores, manifiestos y ejecutables. El material utilizado para la firma se refleja en un registro público a prueba de manipulaciones que se puede utilizar para la verificación y auditoría.

En lugar de claves permanentes, Sigstore utiliza claves efímeras de corta duración que se generan en base a las credenciales verificadas por los proveedores de OpenID Connect (en el momento de generar las claves necesarias para crear una firma digital, el desarrollador se identifica a través del proveedor de OpenID con enlace de correo electrónico).

La autenticidad de las claves se verifica mediante un registro público centralizado, que le permite asegurarse de que el autor de la firma es exactamente quien dice ser, y que la firma fue formada por el mismo participante que fue responsable de versiones anteriores.

La preparación de Sigstore para la implementación se debe a la formación de versiones de dos componentes clave: Rekor 1.0 y Fulcio 1.0, cuyas interfaces de programación se declaran estables y, en adelante, conservan la compatibilidad con versiones anteriores. Los componentes del servicio están escritos en Go y se distribuyen bajo la licencia Apache 2.0.

El componente Rekor contiene una implementación de registro para almacenar metadatos firmados digitalmente que reflejan información sobre proyectos. Para garantizar la integridad y la protección contra la corrupción de datos, se utiliza una estructura de árbol Merkle Tree en la que cada rama verifica todas las ramas y nodos subyacentes a través de hash conjunto (árbol). Al tener un hash final, el usuario puede verificar la exactitud de todo el historial de operaciones, así como la exactitud de los estados pasados ​​de la base de datos (el hash de verificación raíz del nuevo estado de la base de datos se calcula teniendo en cuenta el estado pasado). Se proporciona una API RESTful para verificar y agregar nuevos registros, así como una interfaz de línea de comandos.

El componente Fulcio (SigStore WebPKI) incluye un sistema para crear autoridades de certificación (CA root) que emiten certificados de corta duración basados ​​en correo electrónico autenticado a través de OpenID Connect. La vida útil del certificado es de 20 minutos, durante los cuales el desarrollador debe tener tiempo para generar una firma digital (si en el futuro el certificado cae en manos de un atacante, ya estará caducado). Además, el proyecto desarrolla el kit de herramientas Cosign (Container Signing), diseñado para generar firmas para contenedores, verificar firmas y colocar contenedores firmados en repositorios compatibles con OCI (Open Container Initiative).

La introducción de Sigstore permite aumentar la seguridad de los canales de distribución de software y proteger contra ataques dirigidos a la sustitución de bibliotecas y dependencias (cadena de suministro). Uno de los problemas de seguridad clave en el software de código abierto es la dificultad de verificar la fuente del programa y verificar el proceso de compilación.

El uso de firmas digitales para la verificación de versiones aún no se ha generalizado debido a las dificultades en la gestión de claves, la distribución de claves públicas y la revocación de claves comprometidas. Para que la verificación tenga sentido, también se requiere organizar un proceso confiable y seguro de distribución de claves públicas y sumas de verificación. Incluso con una firma digital, muchos usuarios ignoran la verificación porque lleva tiempo aprender el proceso de verificación y comprender qué clave es confiable.

El proyecto se está desarrollando bajo el auspicio de la organización sin fines de lucro Linux Foundation de Google, Red Hat, Cisco, vmWare, GitHub y HP Enterprise con la participación de OpenSSF (Open Source Security Foundation) y la Universidad de Purdue.

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/28TZGM0
via IFTTT

El nuevo arranque Linux funcionará en el futuro con un enfoque en la robustez y la simplicidad.

Lennart Poettering (el creador de Systemd) dio a conocer hace poco una propuesta para modernizar el proceso de arranque de las distribuciones de Linux, con el objetivo de resolver los problemas existentes y simplificar la organización de un arranque verificado completo, confirmando la autenticidad del kernel y el entorno del sistema subyacente.

Los cambios propuestos se reducen a la creación de una única imagen universal UKI (Unified Kernel Image) que combina la imagen del kernel de Linux, el controlador para cargar el kernel desde UEFI (UEFI boot stub) y el entorno del sistema initrd cargado en memoria, utilizado para inicialización inicial en la etapa antes de montar el FS.

En lugar de una imagen de disco RAM initrd, todo el sistema se puede empaquetar en el UKI, lo que permite la creación de entornos de sistema totalmente verificados que se cargan en la RAM. La imagen UKI se empaqueta como un archivo ejecutable en formato PE, que no solo se puede cargar con los cargadores de arranque tradicionales, sino que también se puede llamar directamente desde el firmware UEFI.

La capacidad de llamar desde UEFI permite usar una verificación de validez e integridad de firma digital que cubre no solo el kernel, sino también el contenido del initrd. Al mismo tiempo, la compatibilidad con las llamadas desde los cargadores de arranque tradicionales permite guardar funciones como la entrega de varias versiones del kernel y la reversión automática a un kernel en funcionamiento en caso de que se detecten problemas con el nuevo kernel después de instalar la actualización.

Actualmente, la mayoría de las distribuciones de Linux utilizan la cadena «firmware → capa shim de Microsoft firmada digitalmente → cargador de arranque GRUB de distribución firmado digitalmente → kernel de Linux de distribución firmado digitalmente → entorno initrd sin firmar → FS root» en el proceso de inicialización. La falta de verificación initrd en las distribuciones tradicionales crea problemas de seguridad, ya que, entre otras cosas, este entorno extrae claves para descifrar el FS root.

No se admite la verificación de la imagen initrd, ya que este archivo se genera en el sistema local del usuario y no puede ser certificado por la firma digital de la distribución, lo que complica mucho la organización de la verificación cuando se utiliza el modo SecureBoot (para verificar el initrd, el usuario necesita para generar sus claves y cargarlas en el firmware UEFI).

Además, la organización de arranque existente no permite usar información de los registros TPM PCR (Registro de configuración de plataforma) para controlar la integridad de los componentes del espacio de usuario que no sean shim, grub y kernel. Entre los problemas existentes, también se menciona la complicación de actualizar el gestor de arranque y la imposibilidad de restringir el acceso a claves en TPM para versiones anteriores del sistema operativo que se han vuelto irrelevantes después de instalar la actualización.

Los principales objetivos de implementar la nueva arquitectura de arranque:

• Proporcionar un proceso de descarga completamente verificado, que cubra todas las etapas, desde el firmware hasta el espacio del usuario, y que confirme la validez e integridad de los componentes descargados.
• Vinculación de recursos controlados a registros TPM PCR con separación por propietarios.
• Capacidad para precalcular los valores de PCR en función del arranque del kernel, initrd, configuración e ID del sistema local.
• Protección contra ataques de reversión asociados con la reversión a la versión vulnerable anterior del sistema.
• Simplifique y mejore la confiabilidad de las actualizaciones.
• Compatibilidad con actualizaciones del sistema operativo que no requieren volver a aplicar o aprovisionar recursos protegidos por TPM localmente.
• Preparación del sistema para la certificación remota para confirmar la corrección del sistema operativo y la configuración de arranque.
• La capacidad de adjuntar datos confidenciales a ciertas etapas de arranque, por ejemplo, extrayendo claves de cifrado para el FS root del TPM.
• Proporcione un proceso seguro, automático y silencioso para desbloquear claves para descifrar una unidad con una partición root.
• El uso de chips que admiten la especificación TPM 2.0, con la capacidad de recurrir a sistemas sin TPM.

Los cambios necesarios para implementar la nueva arquitectura ya están incluidos en el código base de systemd y afectan a componentes como systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase y systemd-creds.

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

El navegador Chrome se diferencia de Chromium en el uso de los logotipos de Google

Google dio a conocer el lanzamiento de la nueva versión de su navegador web «Google Chrome 107» junto con el cual tambien está disponible una versión estable del proyecto gratuito Chromium, que es la base de Chrome.

Además de las innovaciones y la corrección de errores, se han corregido 14 vulnerabilidades en la nueva versión de las cuales no se han identificado problemas críticos que permitan eludir todos los niveles de protección del navegador y ejecutar código en el sistema fuera del entorno sandbox. Como parte del programa de recompensas por vulnerabilidades de la versión actual, Google pagó 10 premios por valor de 57 000 USD.

Principales novedades de Chrome 107

En esta nueva versión de Chrome 107 podremos encontrar el soporte para el mecanismo ECH que continúa el desarrollo de ESNI (Indicación de nombre de servidor cifrado) y se utiliza para cifrar información sobre los parámetros de la sesión TLS, como el nombre de dominio solicitado. La diferencia clave entre ECH y ESNI es que en ECH, en lugar del cifrado a nivel de campos individuales, se cifra todo el mensaje TLS ClientHello, lo que le permite bloquear fugas a través de campos que no están cubiertos por ESNI, por ejemplo, el PSK. Para controlar si ECH está habilitado, se sugiere la configuración «chrome://flags#encrypted-client-hello».

Otra de las novedades que se destaca de la nueva versión de Chrome 107 es el cambio en el diseño de la interfaz para rastrear el estado de las descargas. En lugar de la línea inferior con datos sobre el progreso de la descarga, se ha agregado un nuevo indicador al panel con la barra de direcciones, al hacer clic, se muestra el progreso de la descarga de archivos y un historial con una lista de archivos ya descargados.

Para usuarios de escritorio, se proporciona la capacidad de importar contraseñas guardadas en un archivo en formato CSV. Anteriormente, las contraseñas de un archivo al navegador solo podían transferirse a través del servicio passwords.google.com, y ahora esto se puede hacer a través del administrador de contraseñas integrado en el navegador (Google Password Manager).

Tambien se destaca que se habilitó la retirada automática del permiso para mostrar notificaciones de sitios detectados enviando notificaciones y mensajes que interfieren con el usuario. Además, para dichos sitios, se suspenden las solicitudes para obtener permisos para enviar notificaciones.

Por otra parte, tambien se destaca la quinta etapa de recorte de información en el encabezado HTTP del agente de usuario y los parámetros de JavaScript navigator.userAgent, navigator.appVersion y navigator.platform se ha habilitado para reducir la información que se puede usar para identificar pasivamente a un usuario. En Chrome 107, la cadena de agente de usuario se ha reducido en la información de la plataforma y el procesador para los usuarios de escritorio, y el contenido del parámetro de JavaScript navigator.platform se ha congelado. El cambio solo se nota en las versiones para la plataforma Windows, donde la versión específica de la plataforma se cambia a «Windows NT 10.0». En Linux, el contenido de la plataforma en User-Agent no ha cambiado.

Anteriormente, los números MINOR.BUILD.PATCH que componían la versión del navegador se reemplazaron con 0.0.0. En el futuro, el encabezado contendrá solo información sobre el nombre del navegador, la versión principal del navegador, la plataforma y el tipo de dispositivo (teléfono móvil, PC, tableta).

De los demás cambios que se destacan de esta nueva version:

• En Android se ofrece una nueva interfaz para seleccionar archivos multimedia para cargar fotos y videos (en lugar de su propia implementación, se utiliza la interfaz estándar de Android Media Picker).
• El soporte para Android 6.0 ya no es compatible y ahora requiere al menos Android 7.0.
• CSS Grid agrega soporte para interpolar las propiedades grid-template-columns y grid-template-rows para proporcionar una transición suave entre los diferentes estados de la cuadrícula.
• Se han realizado mejoras en las herramientas para desarrolladores web.
• Se agregó la capacidad de personalizar las teclas de acceso rápido. Inspección de memoria mejorada de objetos de aplicación C/C++ convertidos al formato WebAssembly.
  Compatibilidad habilitada para la decodificación de video acelerada por hardware en formato H.265 (HEVC).

¿Como instalar Google Chrome 107 en Linux?

Si estás interesado en poder instalar esta nueva versión de este navegador web y aún no lo tienes instalado, puedes visitar la siguiente publicación en donde te enseñamos a como poder instalarlo en algunas distribuciones de Linux.

El enlace es este. 

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

«Nuevo» logo de Flatpak

Hace unos instantes hemos publicado un artículo en el que os hablábamos de las sensaciones que nos dan los paquetes snap y flatpak. La frecuencia de las actualizaciones es algo en lo que los flatpak quedan por delante, lo que no siempre significa que sea mejor, y eso es algo que también podemos ver en el software que usan para empaquetar el software. Sólo dos meses después de la versión anterior, ya está disponible Flatpak 1.15.0.

Entre las novedades más destacadas, hay cambios en cuanto a la compilación: a partir de ahora este tipo de paquetes se puede compilar usando Meson en vez de Autotools. Para poder hacerlo es necesario usar Meson 0.53.0 o posterior y Python 3.5 o posterior. Según dicen, es probable que el sistema de construcción Autotools sea eliminado durante el ciclo de 1.15 o 1.17.

Otras novedades de Flatpak 1.15

Esta versión permite la llamada del sistema modify_ldt como parte de --alow=multiarch, lo que aumenta la superficie de ataque, pero es necesario al usar ejecutables de 16-bit en algunas versiones de WINE. También se puede compartir el socket gssproxy, lo que actúa como un portal para la autentificación de Kerberos y permite a las apps usar esta autentificación sin un agujero en el sandbox. Por último, se ha añadido una variable httpbackend a flatpak.pc, permitiendo a objetos dependientes como GNOME Software detectar si son compatibles con libflatpak.

Por otra parte, se han corregido estos errores:

• Terminar los servicios flatpak-session-helper y flatpak-portal cuando la sesión, para que las aplicaciones no hereden direcciones de socket Wayland y las direcciones de los sockets X11.
• Cuando se utiliza fish shell, no se sobrescribe un XDG_DATA_DIRS previamente establecido.
• No intenta habilitar HTTP 2 si está vinculado a una versión de libcurl que no lo soporta.
• Se detiene systemd reportando la sesión-ayudante como fallida cuando se termina por una señal.
• Corregida una advertencia al listar un documento sin permisos.
• Corregida la compilación con GLib 2.66.x (como se usa en Debian 11).
• Corregida la compilación con GLib 2.58.x (como se usa en Debian 10).
• Se ha hecho que los archivos generados sean más reproducibles.
• Actualizaciones de traducción: cs, id, pl, pt_BR

Flatpak 1.15 se ha anunciado hace menos de 24 horas, y se puede descargar desde este enlace en GitHub, en donde se ha publicado toda la información sobre este lanzamiento. En los próximos días/semanas llegará a los repositorios oficiales de la mayoría de distribuciones Linux.

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

Ya hace bastante tiempo desde que se empezaron a usar los paquetes snap y flatpak. Aunque llevaban ya un tiempo en pruebas, ambos se empezaron a usar de verdad en 2016, por lo que cualquier usuario de Linux habrá probado ya algún que otro paquete de este tipo. A principios de este año, mi compañero Diego escribió un artículo explicando las diferencias, ventajas y desventajas de cada uno, y hoy vamos a hacer un poco lo mismo, pero enfocando la información hacia el uso personal.

Adelantando un poco el veredicto, o parte de él, yo diría que hay que elegir uno u otro sólo cuando un paquete esté en los dos formatos, dependiendo de cómo nos funcione cada uno. También hay que tener en cuenta que los flatpak se actualizan más, mientras que los snap lo hacen sólo cuando se sube de versión. Es habitual ver que el flatpak se actualiza a la misma versión muchas veces, porque se supone que han corregido algo y la actualización llega tan pronto en cuanto suben el parche.

Snap y Flatpak, cuestión de gustos

Hay algunos paquetes en Flathub que llevan la etiqueta de alfa o beta, y lo hacen en el repositorio oficial, nada del beta. Otros paquetes se actualizan muy pronto, parecido a como lo hacen las distribuciones Rolling Release, y esto no siempre nos trae cosas buenas. Los snap se actualizan algo menos y suelen ofrecer versiones que parecen más estables, pero esta diferencia en general es poca.

Entonces, de cara al usuario final, ¿qué diferencias hay entre ambas opciones? Ya explicó bastante Diego, pero yo me quedaría con cuatro:

Software disponible

Creo que en cuanto a software disponible, Flathub gana por mucho a Snapcraft. De hecho, he visto en varias ocasiones como aplicaciones que estaban en Snapcraft desaparecían, mientras que en Flathub siguen estando y actualizándose. Los desarrolladores, por lo menos los medianos y pequeños, suelen elegir Flathub, y allí aparecen pronto todas las nuevas aplicaciones que llegan al círculo de GNOME. Una de las últimas, Retro, un reloj que se puede editar con reglas CSS.

Ahora bien, el diseño de los snap les hace ser una mejor opción para empaquetar y distribuir otro tipo de software, como drivers o incluso versiones de Python como la 3.8.

Integración con el sistema operativo

Tal y como decía Diego, «los paquetes snap tienen un completo sistema de permisos por lo que es posible configurarlos para que interactúen con el sistema operativo y las aplicaciones instaladas por el modo habitual«. Estos permisos permiten, valga la redundancia, que los paquetes snap se integren mejor con el sistema que los flatpak. Por ejemplo, hay aplicaciones multimedia que muestran información en el gestor de tareas de KDE cuando usamos la versión snap, pero sólo el icono de la aplicación cuando usamos la versión flatpak.

Velocidad de apertura

Esto puede parecer una tontería, pero no lo es. Hay que tirarle de las orejas a Canonical y decir que no se pueden esperar 10s a que se abra una aplicación en formato snap si se tiene un equipo con un buen procesador y disco SSD. Se está mejorando mucho con el paquete de Firefox, por lo que hay margen de mejora y hay que reducir el tiempo de carga. Los flatpak se abren mucho antes.

Software privativo

Puede ser algo que no gusta a muchos usuarios de la comunidad Linux, pero a veces es necesario usarlo. En Snapcraft está el Visual Studio Code de Microsoft (oficial) o el Steam de Valve con absolutamente todo en el mismo paquete. Las compañías importantes suelen elegir los snap, en parte por su diseño, pero también cuenta que Canonical llega a acuerdos con las empresas para que les den prioridad.

¿Qué instalo: snaps o flatpaks?

Como dije en el spoiler al inicio del post, creo que no hay que decantarse por uno por decreto. Hay que probarlos. Si se quiere algo más actualizado, probablemente haya que elegir el flatpak. Si se necesita mayor integración, quizá merezca la pena usar el snap. Si no se puede aguantar unos segundos a que se abra el snap, pues hay que ir a por el flatpak, y si se quiere algo menos corporativo, aunque Diego ya explicó que la sombra de Red Hat está presente, merecen la pena los flatpak. Por supuesto, si una de las dos opciones no funciona en nuestro equipo hay que usar la otra.

En lo personal, yo uso más los flatpak que los snap, pero principalmente por un motivo: el programa o aplicación que uso está en Flathub y no en Snapcraft. Ahora bien, si está en repositorios oficiales… Adiós a ambos.

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

Hacía tiempo que estaba en fase de pruebas, y ya han lanzado la versión estable. Este lenguaje de programación con nombre de serpiente es uno de los preferidos por muchos desarrolladores, por lo que el lanzamiento de Python 3.11 es un acontecimiento de cierta importancia. Es una actualización mayor, o mediana si se prefiere etiquetar de mayores a las que cambian el primer número, pero no se puede negar que ha mejorado bastante.

En Phoronix, medio que debe gran parte de su fama a sus pruebas de software y hardware, estuvieron testando el rendimiento de Python 3.11 y confirmaron que es entre un 10% y un 60% más rápido que Pyhon 3.10, la que hasta hoy era la versión estable más actualizada. Pero no absolutamente todo son buenas noticias, por lo menos para los usuarios de Linux, ya que una actualización como esta podría romper la compatibilidad con software que estemos usando, y una muestra de ello es lo que estamos sufriendo los usuarios de Kodi en Linux desde que se subió a «Matrix».

Cambios generales de Python 3.11

Lo más destacado de Python 3.11 incluye que ahora se incluyen localizaciones de error de grano fino en los trazados, lo que, en teoría, permitirá reconocer mejor los fallos; grupos de excepciones y except*; en tomllib, se ha añadido soporte para el análisis de TOML en la biblioteca estándar; introducidos grupos de tareas en asyncio; la agrupación atómica ((?>…)) y los cuantificadores posesivos (*+, ++, ?+, {m,n}+) están ahora soportados en las expresiones regulares.

Pero lo más destacado es la velocidad:

El proyecto Faster CPython ya está dando algunos resultados interesantes. Python 3.11 es hasta un 10-60% más rápido que Python 3.10. De media, hemos medido un aumento de velocidad de 1,22 veces en el conjunto de pruebas estándar.

Aunque todo pinta muy bien, hay que tener en cuenta que los cambios en los lenguajes de programación pueden dar problemas, como el de Kodi. Los desarrolladores deben adaptar su código a las nuevas versiones, y si no todo el código, sí la versión «camuflada» para que no les roben su trabajo. Por lo tanto, si se depende de algo así, es mejor aguantar la actualización lo máximo posible.

Python 3.11 ha sido anunciado hoy (ayer en huso horario del proyecto), y su tarball ya se puede descargar desde la página de descargas del proyecto. Su llegada a los repositorios oficiales dependerá de la filosofía de la distribución que estemos usando, pero en la mayoría de casos pasarán semanas o incluso meses.

Más información y logo de la imagen: foro de Python.

from Linux Adictos https://ift.tt/6L1PIU0
via IFTTT