Mediante una publicación de blog, Brandon LeBlanc de Microsoft dio a conocer que después de realizar algunas actualizaciones para mejorar el rendimiento de WSL  se pudo realizar un cambio que permite buscar listas de tipos de archivos, protocolos y archivos.

Con ello el acceso a los sistemas de archivos de Linux en el subsistema de Windows para Linux agrega la capacidad para que los usuarios conecten y monten un disco físico dentro de una distribución WSL 2. Esto permite acceder a sistemas de archivos que no son compatibles de forma nativa con Windows como ext4.

Todo esto podrá ser posible a partir de la versión preliminar 20211 de Windows Insiders, WSL 2 se ofrecerá la nueva función: wsl –mount que es la que se encarga de realizar dicha acción.

En la publicación de blog, se menciona que para montar un disco, es necesario que se abra una ventana de PowerShell con privilegios de administrador y en ella se ejecute:

wsl --mount <DiskPath>

Y para enumerar los discos disponibles en Windows, se debe ejecutar:

wmic diskdrive list brief

Para desmontar y desconectar el disco de WSL 2, se debe ejecutar:

wsl --unmount <Diskpath>

Las rutas de disco están disponibles en las columnas «DeviceID», generalmente en el formato \\. \\\. \ PHYSICALDRIVE *.

A continuación se muestra un ejemplo de cómo montar una partición específica de un disco duro determinado en WSL y examinar sus archivos.

Una vez montados, también es posible acceder a estos discos a través del Explorador de Windows yendo a \wsl

Por defecto, wsl –mount intenta montar el disco como ext4.

De momento se mencionan que se cuentan con ciertas limitaciones en este momento,  y es que solo se pueden adjuntar discos completos a WSL 2, lo que significa que no es posible adjuntar solo una partición.

Concretamente, esto significa que no es posible utilizar wsl –mount para leer una partición en el dispositivo de arranque, ya que este dispositivo no se puede desconectar de Windows.

Las unidades flash USB no son compatibles en este momento y no se conectarán a WSL 2. Sin embargo, las unidades USB son compatibles.

Solo los sistemas de archivos soportados de forma nativa en el kernel pueden ser montados por wsl –mount. Esto significa que no es posible utilizar los controladores del sistema de archivos instalados (como ntfs-3g, por ejemplo) llamandowsl –mount.

Por otra parte en las actualizaciones para desarrolladores se menciona que siempre que se envíe una nueva versión del sistema operativo al canal de desarrollo, también se enviará el SDK de Windows correspondiente. Siempre puede instalar el SDK de Insider más reciente de aka.ms/InsiderSDK.

Por último de las correcciones que se mencionan en la publicación:

• Se solucionó un problema por el cual algunas aplicaciones de 32 bits que se ejecutaban en un sistema operativo de 64 bits no se promocionaban correctamente a la GPU discreta para configuraciones híbridas.
• Solucionamos un problema que podía provocar que los mosaicos del menú Inicio siguieran mostrando una barra de progreso de «Actualización de la aplicación en curso» después de actualizar una aplicación.
• Solucionamos un problema que podía causar que algunos de los íconos de la aplicación aparecieran inesperadamente en Inicio.
• Solucionamos un problema en los dispositivos ARM64 que causaba que el menú Inicio se bloqueara al iniciarse la próxima vez que se abriera después de iniciar ciertas aplicaciones desde el menú Inicio y luego cerrarlas.
• Solucionamos un problema que podía hacer que la pantalla de bloqueo se congelara.
• Solucionamos un problema que podía hacer que ShellExperienceHost.exe se bloqueara.
• Solucionamos un problema por el cual la imagen de fondo predeterminada para Windows 10 no se mostraba en las notificaciones (por ejemplo, al tomar una captura de pantalla con WIN + Shift + S).
• Solucionamos un problema con las últimas versiones que podría hacer que Windows Update se bloquee al descargar la actualización.
• Ya no se le pedirá que reinstale una actualización de .NET después de cada versión.

Si quieres conocer mas al respecto sobre la nota, puedes consultar la publicación realizada en el blog de Microsoft dirigiéndote al siguiente enlace.

from Linux Adictos https://ift.tt/3ij3avI
via IFTTT

El equipo que está a cargo del desarrollo del popular entorno de escritorio “Gnome” ha dado a conocer que durante los últimos dos meses han estado trabajando a marchas forzadas y que “A medida que se acercaba la congelación de la versión, parte de la cola de solicitudes de fusión necesitaba una decisión final sobre si estaban listas o no” para la próxima versión de GNOME 3.38.

Pero finalmente realizaron una publicación de blog en la cual comparten lo mas relevante del trabajo que han estado realizando para la próxima version de Gnome 3.38 que esta ya casi a la vuelta de la esquina.

Y es que según el equipo, en los días en que Clutter era un conjunto de herramientas de aplicación, solo tenía que procesar un reloj de un solo cuadro. Sin embargo, dado que ahora es un conjunto de herramientas de composición, tener un reloj con un solo cuadro se ha convertido en un aspecto limitante de Clutter, ya que cada monitor funciona a veces a ritmos y tiempos diferentes.

Por otra parte el equipo recordó que aplicaciones como juegos, reproductores multimedia, etc.  Permiten su funcionamiento en modo de pantalla completa.

Idealmente, cuando una aplicación está en modo de pantalla completa, debería poder evitar un diseño de escritorio innecesario cuando lo único visible es la ventana de pantalla completa del cliente.

Esto se conoce comúnmente como «bypass del compositor» o «pantalla completa no redireccionada». En GNOME 3.38, el equipo hizo que Mutter ahora admita la omisión del compositor siempre que sea posible.

Al omitir el compositor, el contenido de la ventana se muestra directamente en la pantalla, sin ninguna composición innecesaria. Los resultados varían de un hardware a otro, pero, en principio, esto debería reducir el uso de CPU y GPU y, por lo tanto, mejorar el rendimiento.

Otro grupo de mejoras de screencasting llegó a Mutter. De hecho, el equipo cree que el screencasting ahora funciona bien, incluso en los casos en que una aplicación pasa por alto al compositor.

En estos últimos casos, Mutter copia el contenido de la aplicación directamente en la transmisión de screencast. Además, la transmisión de ventana ha sido objeto de una serie de correcciones de errores y mejoras.

También el equipo señala que ha habido un gran cambio en GNOME 3.38: la capacidad de personalizar la cuadrícula de la aplicación. Esta característica ha sido un deseo desde hace mucho tiempo, pero requirió una serie de mejoras bajo el capó y otros cambios para respaldarla. Actualmente le permite crear carpetas arrastrando iconos de aplicaciones uno encima del otro, mover aplicaciones hacia y desde carpetas y reposicionar aplicaciones en la cuadrícula. Pero eso no es todo.

Los diálogos también han visto pequeñas mejoras visuales para adaptarse a estos nuevos cambios.

Mientras que para el menú del calendario también ha experimentado algunas mejoras visuales. Los eventos del calendario ahora se muestran debajo del calendario real y las secciones ya no son visibles. Se han realizado otras mejoras en este menú, pero están en cola para la próxima versión.

Además de que ahora varios componentes del entorno se integran opcionalmente con el servicio de controles parentales que forma parte de GNOME 3.38. Esto permite a los padres, tutores, supervisores, escuelas, etc. limitar a qué aplicaciones puede acceder un usuario en particular.

Finalmente en la publicación, también mencionan que:

• El menú de apagado se ha dividido y que la opción de «Reiniciar» es ahora una entrada, junto con «Apagar».
• El algoritmo de diseño de cuadrícula de la aplicación se ha reescrito y debería mejorar el diseño de los iconos en diferentes escenarios.
• El número de filas y columnas ahora se establece en función del formato de pantalla y el espacio disponible, y los iconos crecen y se reducen en consecuencia.
• El número de iconos por página se fija en 24 iconos. Este límite se ha establecido, porque al cambiar el número de iconos por página se corre el riesgo de perder las personalizaciones realizadas en la cuadrícula de la aplicación.

Fuente: https://blogs.gnome.org

from Linux Adictos https://ift.tt/2FuYLqS
via IFTTT

Se ha revelado información sobre una nueva vulnerabilidad en el protocolo TLS, cuyo nombre en código es «Raccoon Attack» y que permite, en raras circunstancias, determinar una clave primaria preliminar que se puede usar para descifrar conexiones TLS, incluido HTTPS al interceptar el tráfico de tránsito (MITM).

De la información que se dio a conocer, se menciona que el ataque es muy difícil de implementar en la práctica y es de naturaleza más teórica. Un ataque requiere una configuración específica del servidor TLS y la capacidad de medir con mucha precisión el tiempo de procesamiento de las operaciones por parte del servidor.

El problema está presente directamente en la especificación TLS y solo afecta a las conexiones que utilizan cifrados basados ​​en el protocolo de intercambio de claves DH.

Los cifrados ECDH no manifiestan el problema y siguen siendo seguros. Solo los protocolos TLS hasta la versión 1.2 incluida son vulnerables y el protocolo TLS 1.3 no se ve afectado y la vulnerabilidad se manifiesta en las implementaciones de TLS que reutilizan la clave secreta DH en diferentes conexiones TLS.

En OpenSSL 1.0.2e y versiones anteriores, la clave DH se reutiliza en todas las conexiones de servidor, a menos que la opción SSL_OP_SINGLE_DH_USE esté establecida explícitamente.

Mientras que desde OpenSSL 1.0.2f, la clave DH se reutiliza solo cuando se utilizan cifrados DH estáticos. En OpenSSL 1.1.1, la vulnerabilidad no se manifiesta por sí misma, ya que esta rama no usa la clave DH primaria y no usa cifrados DH estáticos.

Cuando se utiliza el método de intercambio de claves DH, ambos lados de la conexión generan claves privadas aleatorias (en adelante, clave «a» y clave «b»), sobre la base de las cuales se calculan y envían las claves públicas (g^a  mod p y g^bmod p).

Después de recibir las claves públicas, cada parte calcula una clave primaria común (g^ab mod p), que se utiliza para generar claves de sesión.

El ataque Raccoon permite determinar la clave primaria mediante el análisis de la información a través de canales laterales, partiendo del hecho de que las especificaciones TLS hasta la versión 1.2 requieren que todos los bytes cero iniciales de la clave primaria sean descartados antes de los cálculos con su participación.

La inclusión de la clave primaria truncada se pasa a la función de generación de claves de sesión basada en funciones hash con diferentes retrasos al procesar diferentes datos.

Medir con precisión el tiempo de las operaciones clave realizadas por el servidor permite a un atacante identificar pistas que proporcionan una forma de juzgar si la clave principal comienza en cero o no. Por ejemplo, un atacante puede interceptar la clave pública (g^a) enviada por el cliente , reenviarla al servidor y determinar si la clave primaria resultante comienza con cero.

Por sí misma, la definición de un byte de la clave no da nada, pero interceptando el valor «g^a» transmitido por el cliente durante la negociación de la conexión, el atacante puede formar un conjunto de otros valores relacionados con «g^a» y enviarlos al servidor en sesiones de negociación de conexión separadas.

Al formar y enviar los valores «g^r_i*g^a«, el atacante puede, mediante el análisis de cambios en los retrasos de respuesta del servidor, determinar los valores que conducen a la recepción de claves primarias a partir de cero. Con estos valores determinados, el atacante puede componer un conjunto de ecuaciones para resolver el problema del número oculto y calcular la clave primaria original.

La vulnerabilidad de OpenSSL se calificó de gravedad baja, y la solución fue mover los cifrados problemáticos «TLS_DH_ *» en la versión 1.0.2w a la categoría «cifrados débiles» que estaba deshabilitada de forma predeterminada. Los desarrolladores de Mozilla hicieron lo mismo al deshabilitar los conjuntos de cifrado DH y DHE en la biblioteca NSS utilizada en Firefox.

Por separado, hay problemas adicionales en la pila TLS de dispositivos F5 BIG-IP que hacen que el ataque sea más realista.

En particular, se encontraron desviaciones en el comportamiento de dispositivos con un byte cero al comienzo de la clave primaria, que se pueden usar en lugar de medir la latencia exacta en los cálculos.

Fuente: https://raccoon-attack.com/

from Linux Adictos https://ift.tt/33muqmL
via IFTTT

En HDC 2020, Huawei dio a conocer mediante un anunció la expansión de planes para el nuevo sistema operativo en el que ha estado trabajando «Harmony OS» anunciado el año pasado.

Además de los dispositivos portátiles anunciados originalmente y los productos de Internet de las cosas (IoT), como pantallas, dispositivos portátiles, altavoces inteligentes y sistemas de información para automóviles, el sistema operativo que se está desarrollando también se aplicará a los teléfonos inteligentes.

Las pruebas del SDK para desarrollar aplicaciones móviles para Harmony comenzarán a fines de 2020, y los primeros teléfonos inteligentes basados ​​en el nuevo sistema operativo están programados para ser lanzados hasta el último trimestre del próximo año, es decir si las cosas salen bien podremos ver los resultados en octubre del 2021.

Se destaca que el nuevo SO ya está listo para dispositivos IoT con RAM de 128KB a 128MB y se estaba trabajando para que en abril de 2021 comenzará la promoción de la opción para dispositivos con memoria de 128MB a 4GB y en octubre para dispositivos con más de 4GB de RAM.

Recordemos que el proyecto Harmony ha estado en desarrollo desde 2017 y es un sistema operativo de microkernel que puede verse como un competidor del sistema operativo Fuchsia de Google.

La plataforma se publicará en código fuente como un proyecto de código completamente abierto con gestión independiente (Huawei ya está desarrollando LiteOS abierto para dispositivos IoT).

El código de la plataforma se donará a China Open Atomic Open Source Foundation, una organización sin fines de lucro.

Huawei cree que Android no es tan bueno para los dispositivos móviles debido a la cantidad innecesariamente grande de código, el programador de procesos desactualizado y los problemas de fragmentación de la plataforma.

Dentro de las características que se detallan de Harmony OS, son las siguientes:

• El núcleo del sistema se verifica a un nivel de lógica/matemática formal para minimizar el riesgo de vulnerabilidades. La verificación se realizó utilizando métodos que se utilizan comúnmente en el desarrollo de sistemas críticos en áreas como la aviación y la astronáutica, y pueden lograr el cumplimiento del nivel de seguridad EAL 5+.
• El micronúcleo está aislado de dispositivos externos. El sistema está desacoplado del hardware y permite a los desarrolladores crear aplicaciones que se pueden utilizar en diferentes categorías de dispositivos sin crear paquetes separados.
• El microkernel solo implementa el planificador y el IPC, y todo lo demás se traslada a los servicios del sistema, la mayoría de los cuales se ejecutan en el espacio del usuario.
• Como programador de tareas, se propone un motor de latencia determinista, que analiza la carga en tiempo real y utiliza métodos para predecir el comportamiento de la aplicación. En comparación con otros sistemas, el programador logra una reducción del 25,7% en la latencia y una reducción del 55,6% en el jitter de latencia.
• Para proporcionar comunicación entre el microkernel y los servicios externos del kernel, como el sistema de archivos, la pila de red, los controladores y el subsistema de lanzamiento de la aplicación, se utiliza IPC, que según la compañía es cinco veces más rápido que IPC en Zircon y tres veces más rápido que IPC en QNX.
• En lugar de la pila de protocolos de cuatro capas que se usa comúnmente para reducir la sobrecarga, Harmony emplea un modelo simplificado de una sola capa basado en un bus virtual distribuido que se comunica con equipos como pantallas, cámaras, tarjetas de sonido y similares.
• El sistema no proporciona acceso de usuario a nivel raíz.
• La aplicación está construida con su propio compilador Arc, que admite código C, C ++, Java, JavaScript y Kotlin.

Además, para poder crear aplicaciones para varias clases de dispositivos, como televisores, teléfonos inteligentes, relojes inteligentes, sistemas de información para automóviles, etc., Huawei menciona que proporcionara un marco universal para desarrollar interfaces y SDK con un entorno de desarrollo integrado.

El kit de herramientas adaptará automáticamente las aplicaciones para diferentes pantallas, controles y métodos de interacción del usuario. También menciona la provisión de herramientas para que Harmony adapte las aplicaciones de Android existentes con cambios mínimos.

Fuente: https://www.xda-developers.com

from Linux Adictos https://ift.tt/3md0e6j
via IFTTT