Después de cuatro meses de desarrollo se dio a conocer el lanzamiento de la implementación gratuita de las API de OpenGL y Vulkan: Mesa 21.3.0, la cual se posiciona como la primera versión de la rama Mesa 21.3.x y que tiene un estado experimental. Después de la estabilización final del código, se lanzará la versión estable 21.3.1.

Mesa 21.3 proporciona compatibilidad completa con OpenGL 4.6 para los controladores 965, iris (Intel), radeonsi (AMD), zink y llvmpipe. El soporte para OpenGL 4.5 está disponible para la GPU AMD (r600) y NVIDIA (nvc0), y OpenGL 4.3 a virgl (virtual la GPU Virgil3D para QEMU / KVM). El soporte Vulkan 1.2 está disponible para tarjetas Intel y AMD, así como el modo emulador (vn) y el rasterizador de software lavapipe, el soporte Vulkan 1.1 está disponible para Qualcomm GPU y el rasterizador de software lavapipe, y Vulkan 1.0 está disponible para Broadcom VideoCore VI GPU (Raspberry Pi 4).

Principales novedades de Mesa 21.3.0

En esta nueva versión que se presenta de Mesa, se destaca que el controlador Zink (una implementación de la API OpenGL sobre Vulkan, que le permite obtener OpenGL acelerado por hardware si el sistema tiene controladores limitados para admitir solo la API Vulkan) es compatible con OpenGL ES 3.2.

Mientras que el controlador Panfrost, diseñado para funcionar con GPU basadas en microarquitecturas Midgard (Mali-T6xx, Mali-T7xx, Mali-T8xx) y Bifrost (Mali G3x, G5x, G7x), está oficialmente certificado para compatibilidad con OpenGL ES 3.1.

Por otra parte, el controlador v3dv desarrollado para el acelerador de gráficos VideoCore VI utilizado a partir del modelo Raspberry Pi 4 ha sido certificado para admitir la API de gráficos Vulkan 1.1 y también ha agregado compatibilidad con sombreadores de geometría. El rendimiento del código generado por el compilador de sombreadores se ha mejorado significativamente, lo que tiene un efecto positivo en la velocidad de los programas que usan sombreadores de forma activa, por ejemplo, juegos basados ​​en Unreal Engine 4.

El controlador RADV Vulkan (AMD) agrega soporte experimental para el trazado de rayos y los sombreadores de trazado de rayos. Para las tarjetas GFX10.3, la selección primitiva está habilitada de forma predeterminada mediante los motores de sombreado NGG (geometría de próxima generación).

Ademas se destaca que el controlador de lavapipe con la implementación del rasterizador de software para la API de Vulkan (similar a llvmpipe, pero para Vulkan, que traduce las llamadas de la API de Vulkan a la API de Gallium) tiene soporte para filtrado de texturas anisotrópicas y soporte agregado para Vulkan 1.2.
El controlador OpenGL llvmpipe, agregó soporte para operaciones FP16, filtrado de textura anisotrópica ( GL_ARB_texture_filter_anisotropic ) y regiones de memoria fijadas ( GL_AMD_pinned_memory ). Se proporcionó soporte para el perfil de compatibilidad OpenGL 4.5.

El controlador OpenGL Iris (nuevo controlador para GPU Intel) agregó capacidad de compilación de sombreadores multiproceso y el rastreador de estado VA-API (Video Acceleration API) proporciona soporte para acelerar la codificación y decodificación de video AV1 cuando se utilizan controladores de GPU AMD.

Tambien se menciona que el soporte EGL está implementado para la plataforma Windows y que se agregó soporte para la extensión EGL_EXT_present_opaque para Wayland, ademas de que se corrigieron problemas con la visualización de transparencia en juegos que se ejecutan en entornos basados ​​en el protocolo Wayland.

En cuanto a los controladores Vulkan RADV (AMD), ANV (Intel) y lavapipe, se agregaron soporte para extensiones:

• VK_EXT_shader_atomic_float2 (Intel, RADV).
• VK_EXT_vertex_input_dynamic_state (RADV).
• VK_EXT_primitive_topology_list_restart (RADV, lavapipe).
• VK_KHR_shader_integer_dot_product (RADV).
• VK_KHR_synchronization2 (Intel).
• VK_KHR_maintenance4 (RADV).
• VK_KHR_format_feature_flags2 (RADV).
• VK_KHR_shader_subgroup_extended_types (lavapipe).
• VK_KHR_spirv_1_4 (lavapipe).
• VK_KHR_timeline_semaphore (lavapipe).
• VK_EXT_external_memory_host (lavapipe).
• VK_KHR_depth_stencil_resolve (lavapipe).
• VK_KHR_shader_float16_int8 (lavapipe).
• VK_EXT_color_write_enable (lavapipe).

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

¿Cómo instalar los drivers de video Mesa en Linux?

Los paquetes de Mesa se encuentran en todas las distribuciones de Linux, por lo que su instalación puede realizarse ya sea descargando y compilando el código fuente (toda la información al respecto aquí) o de una forma relativamente sencilla, la cual depende de la disponibilidad dentro de los canales oficiales de tu distribución o de terceros.

Para los que son usuarios de Ubuntu, Linux Mint y derivados pueden añadir el siguiente repositorio en donde los controladores son actualizados de manera rápida.

sudo add-apt-repository ppa:kisak/kisak-mesa -y

Ahora vamos a actualizar nuestro listado de paquetes y repositorios con:

sudo apt update

Y finalmente podemos instalar los drivers con:

sudo apt upgrade

Para el caso de los que son usuarios de Arch Linux y derivados estos los instalamos con el siguiente comando:

sudo pacman -S mesa mesa-demos mesa-libgl lib32-mesa lib32-mesa-libgl

Para quienes sean usuarios de Fedora 32 pueden utilizar este repositorio, por lo que deben de habilitar corp con:

sudo dnf copr enable grigorig/mesa-stable

sudo dnf update

Finalmente, para los que son usuarios de openSUSE, pueden instalar o actualizar tecleando:

sudo zypper in mesa

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

Hace algunos dias GitHub revelo dos incidentes en la infraestructura del repositorio de paquetes de NPM, de los cuales detalla que el 2 de noviembre, investigadores de seguridad de tercero como parte del programa Bug Bounty encontraron una vulnerabilidad en el repositorio de NPM que permite publicar una nueva versión de cualquier paquete utilizando aunque no está autorizado para realizar dichas actualizaciones.

La vulnerabilidad fue causada por verificaciones de autorización incorrectas en el código de microservicios que procesan solicitudes a NPM. El servicio de autorización realizó una verificación de permisos en los paquetes en función de los datos pasados ​​en la solicitud, pero otro servicio que cargaba la actualización en el repositorio determinó el paquete a publicar en función del contenido de metadatos en el paquete cargado.

Así, un atacante podría solicitar la publicación de una actualización para su paquete, al que tiene acceso, pero indicar en el propio paquete información sobre otro paquete, que eventualmente sería actualizado.

Durante los últimos meses, el equipo de npm ha estado invirtiendo en mejoras de infraestructura y seguridad para automatizar el monitoreo y análisis de las versiones recientemente publicadas de paquetes con el fin de identificar malware y otros códigos maliciosos en tiempo real.

Hay dos categorías principales de eventos de publicación de malware que ocurren en el ecosistema npm: malware que se publica debido a la apropiación de cuentas y malware que los atacantes publican a través de sus propias cuentas. Aunque las adquisiciones de cuentas de alto impacto son relativamente poco frecuentes, en comparación con el malware directo publicado por atacantes que utilizan sus propias cuentas, las adquisiciones de cuentas pueden tener un gran alcance cuando se dirigen a los mantenedores de paquetes populares. Si bien nuestro tiempo de detección y respuesta a las adquisiciones de paquetes populares ha sido tan bajo como 10 minutos en incidentes recientes, continuamos evolucionando nuestras capacidades de detección de malware y estrategias de notificación hacia un modelo de respuesta más proactivo

El problema se solucionó 6 horas después de que se informó de la vulnerabilidad, pero la vulnerabilidad estuvo presente en NPM más tiempo de lo que cubren los registros de telemetría. GitHub afirma que no se han registrado rastros de ataques que utilicen esta vulnerabilidad desde septiembre de 2020, pero no hay garantía de que el problema no haya sido explotado antes.

El segundo incidente tuvo lugar el 26 de octubre. En el curso del trabajo técnico con la base de datos del servicio replicant.npmjs.com, se reveló que había datos confidenciales en la base de datos disponibles para consultas externas, revelando información sobre los nombres de los paquetes internos que se mencionaron en el registro de cambios.

La información sobre dichos nombres se puede utilizar para llevar a cabo ataques a dependencias en proyectos internos (en febrero, tal ataque permitió que se ejecutara código en los servidores de PayPal, Microsoft, Apple, Netflix, Uber y otras 30 empresas).

Además, en relación con la creciente incidencia de incautación de repositorios de grandes proyectos y la promoción de código malicioso a través del compromiso de las cuentas de los desarrolladores, GitHub decidió introducir la autenticación obligatoria de dos factores. El cambio entrará en vigor en el primer trimestre de 2022 y se aplicará a los mantenedores y administradores de los paquetes incluidos en la lista de los más populares. Adicionalmente, se informa sobre la modernización de la infraestructura, en la que se introducirá el monitoreo y análisis automatizado de nuevas versiones de paquetes para la detección temprana de cambios maliciosos.

Recordemos que según un estudio realizado en 2020, solo el 9.27% ​​de los administradores de paquetes usan autenticación de dos factores para proteger el acceso, y en el 13.37% de los casos, al registrar nuevas cuentas, los desarrolladores intentaron reutilizar contraseñas comprometidas que aparecen en contraseñas conocidas.

Durante el chequeo de la solidez de las contraseñas utilizadas, se logró acceder al 12% de las cuentas en NPM (13% de los paquetes) debido al uso de contraseñas predecibles y triviales como «123456». Entre las problemáticas se encontraban 4 cuentas de usuario de los 20 paquetes más populares, 13 cuentas cuyos paquetes se descargaron más de 50 millones de veces al mes, 40 – más de 10 millones de descargas al mes y 282 con más de 1 millón de descargas al mes. Teniendo en cuenta la carga de módulos a lo largo de la cadena de dependencias, comprometer cuentas que no son de confianza podría afectar hasta el 52% de todos los módulos en NPM en total.

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/3cVQRUU
via IFTTT