Tal y como informa Daniel Stenberg, hoy hace un mes desde que se lanzó la versión anterior de esta herramienta para usar en un intérprete de comandos para transferir archivos con sintaxis URL, pero también coincide con otra fecha: su cumpleaños. Hoy han lanzado cURL 8.0.0, y en este día se cumplen 25 años desde que se dio inicio a esta proyecto, y el cambio de número parece tener más que ver con este acontecimiento que con un lanzamiento realmente mayor.

Stenberg dice que es un cambio mayor de primer número, pero no hay cambios innovadores ni fuegos artificiales. Sencillamente decidieron que era cuestión de tiempo poner a cero las otras cifras, y qué mejor momento que en un cumpleaños en el que se celebra el cuarto de siglo de existencia. Tampoco hay roturas ni de API ni de ABI, y eso es lo que provocaría un salto a una versión con muchos cambios.

cURL 8.0.0 no incluye grandes novedades

En cuanto a los números, y aunque las convenciones están para cumplirlas o pasar de ellas, cada uno es libre de hacer lo que quiera, en algo con formato X.Y.Z cuando sube Z es un cambio para corregir errores, Y son versiones medianas que suelen incluir nuevas funciones y X son actualizaciones mayores que, además de nuevas funciones, pueden romper la compatibilidad con versiones anteriores. De ahí que expliquen lo de que no hay roturas de este tipo.

Se trata de una versión mayor, pero sin cambios revolucionarios ni fuegos artificiales. Decidimos que ya era hora de restablecer el número menor a un nivel más manejable y hacerlo exactamente en el 25 cumpleaños de curl lo hizo extra divertido. No hay ruptura de API o ABI en esta versión.

Ahora bien, dicen que este es probablemente el mejor lanzamiento de curl que han hecho nunca, pero yo no me tomaría esas palabras muy en serio. Es algo que se dice siempre, en parte porque es lógico que se lance una nueva versión de un software para mejorar lo existente, no para empeorarlo. Así que sí, por una parte será verdad, pero por otra es algo que se podrían ahorrar.

En cuanto a los cambios, se han añadido varios parches de seguridad (CVE), corrección de errores y sólo un cambio real, que es la primera versión de cURL que deja de soportar la construcción en sistemas que carecen de un tipo de datos de 64 bits.

cURL 8.0.0 ya se puede descargar desde este enlace, pero, si no corre prisa, y no tiene el por qué hacerlo, lo mejor para los usuarios de Linux es esperar a que nuestra distribución actualice el paquete en sus repositorios oficiales.

cURL es un software importante en el mundo FOSS que incluso ha ganado el premio del mes que otorga Microsoft a software libre y de código abierto.

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

LLVM es una marco para el desarrollo de compiladores ademas de que ayuda a construir nuevos lenguajes de programación y mejorar los lenguajes existentes

Después de poco más de seis meses de desarrollo, se dio a conocer el lanzamiento de la nueva versión del proyecto LLVM 16.0, versión en la que se implementan una gran cantidad de cambios y mejoras.

Para quienes desconocen de LLVM, deben saber que este es un compilador compatible con GCC (compiladores, optimizadores y generadores de código) que compila programas en un código de bits intermedio de instrucciones virtuales tipo RISC (una máquina virtual de bajo nivel con un sistema de optimización multinivel).

El pseudocódigo generado puede ser convertido por el compilador JIT en instrucciones de máquina justo en el momento de la ejecución del programa.

Principales novedades de LLVM 16.0

En esta nueva versión que se presenta, podremos encontrar diversas mejoras importantes en Clang 16.0, de las cuales de destaca el estándar C++/ObjC++ predeterminado que se establece en gnu++17 (anteriormente gnu++14), lo que implica soporte para funciones de C++17 con extensiones GNU de forma predeterminada. En el código LLVM se permite el uso de elementos definidos en el estándar C++17.

Otro de los cambios que se destaca, es que se ha agregado soporte para CPU Cortex-A715, Cortex-X3 y Neoverse V2, extensiones Armv8.3 y funciones de versiones múltiples al backend AArch64.
La compatibilidad con las plataformas Armv2, Armv2A, Armv3 y Armv3M se suspendió en el backend de la arquitectura ARM, para el cual no se garantizaba la generación correcta de código. Se agregó la capacidad de generar código para instrucciones para trabajar con números complejos y se agregó soporte para arquitecturas de conjuntos de instrucciones (ISA) AMX-FP16, CMPCXADD, AVX-IFMA, AVX-VNNI-INT8, AVX-NE-CONVERT al backend X86.

Ademas de ello, se han aumentado los requisitos para construir LLVM, ademas de que la compilación ahora debería ser compatible con el estándar C++ 17, es decir, la compilación requiere al menos GCC 7.1, Clang 5.0, Apple Clang 10.0 o Visual Studio 2019 16.7.

Por otra parte, tambien se destacan los backends mejorados para arquitecturas MIPS, PowerPC y RISC-V, asi como tambien el soporte para depurar ejecutables de 64 bits para la arquitectura LoongArch al depurador LLDB y el manejo mejorado de los símbolos de depuración COFF.

De los demás cambios que se destacan:

• En la biblioteca Libc++ , el trabajo principal se centró en implementar soporte para nuevas características de los estándares C++20 y C++23.
• El tiempo de enlace se ha reducido significativamente en el enlazador LDD al paralelizar el escaneo de reubicación de direcciones y las operaciones de inicialización de secciones. Se agregó soporte para la compresión de secciones usando el algoritmo ZSTD.
• Tambien se destacan las funciones avanzadas implementadas con el estándar C++20.
• capturar enlaces estructurados en funciones lambda.
• El operador de igualdad dentro de expresiones.
• Capacidad para no especificar la palabra clave typename en algunos contextos,
• Permisibilidad de la inicialización agregada entre paréntesis («Aggr(val1, val2)»).
• Funciones implementadas definidas en el futuro estándar C++2b.
• Compatibilidad proporcionada con el tipo char8_t,
• Se amplió el rango de caracteres permitidos para su uso en «\N{…}»,
• Se agregó la capacidad de usar variables declaradas como «static constexpr» en funciones declaradas como constexpr.
• Funciones implementadas definidas en el futuro estándar C2x C:
• Se agregó soporte para cargar múltiples archivos de configuración (los archivos de configuración predeterminados se cargan primero y luego los especificados mediante el indicador «–config=», que ahora se puede especificar varias veces).
• Se modificó el orden de carga de los archivos de configuración predeterminados: clang primero intenta cargar el archivo <triple>-<driver>.cfg y, si no lo encuentra, intenta cargar dos archivos <driver>.cfg y <triple>.cfg.
• Se agregó un nuevo indicador de compilación «-fcoro-aligned-allocation» para la distribución alineada de marcos de rutina.
• Se agregó el indicador «-fmodule-output» para habilitar el modelo de compilación monofásico de los módulos estándar de C++ .
• Se agregó el modo «-Rpass-analysis=stack-frame-layout» para diagnosticar problemas con el diseño del marco de pila.
• Se agregó un nuevo atributo __attribute__((target_version(«cpu_features»))) y se amplió la funcionalidad del atributo __attribute__((target_clones(«cpu_features1″,»cpu_features2»,…))) para seleccionar versiones específicas de funciones proporcionadas por la CPU AArch64 .
• Herramientas de diagnóstico mejoradas:
• Se agregó la advertencia «-Wsingle-bit-bitfield-constant-conversion» para detectar el truncamiento implícito al asignar uno a un campo de bits con signo de un bit.
• Diagnóstico extendido de variables constexpr no inicializadas.
• Se agregaron advertencias «-Wcast-function-type-strict» y «-Wincompatible-function-pointer-types-strict» para detectar posibles problemas al transmitir tipos de función.

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

Xen es un hipervisor que proporciona aislamiento seguro, control de recursos, garantías de calidad de servicio y migración de máquinas virtuales

Los desarrolladores de la plataforma XCP-ng, que se desarrolla bajo el ala del proyecto Xen, han publicado un plan para crear un reemplazo de Rust para varios componentes de la pila de software Xen.

El hipervisor Xen en sí aún no se va a procesar y el trabajo se centra principalmente en volver a trabajar los componentes individuales del conjunto de herramientas.

La plataforma actualmente usa componentes en C, Python, OCaml y Go, algunos de los cuales están desactualizados y causan problemas de mantenimiento. Se observa que el uso de Rust no conducirá a un aumento general en la cantidad de idiomas involucrados, ya que solo se implementa un componente en Go, que se planea reemplazar en primer lugar.

Obviamente, no espere que reescribamos el hipervisor Xen y todo en Rust como nuestro primer intento. De hecho, nuestro objetivo aquí es comenzar a reemplazar algunos componentes más pequeños a su alrededor, lo que nos permite «aumentar» el lenguaje en sí y pensar en cómo reemplazar las cosas bloque tras bloque, para toda la plataforma.

Rust se elige como un lenguaje que combina un alto rendimiento del código resultante con capacidades de memoria segura, no requiere el uso de un recolector de basura, es adecuado para desarrollar componentes de bajo y alto nivel, proporciona características adicionales para reducir el potencial errores, como el préstamo variable (borrow checker). Rust también está más extendido que el actual lenguaje XAPI OCaml, lo que facilitará la atracción de nuevos desarrolladores al proyecto.

En la primera etapa, se planea desarrollar reemplazos para varios componentes con el fin de resolver los procesos y preparar la base para reemplazar otras partes de la pila de software. En particular, en primer lugar, las herramientas de invitado de Linux se reescribirán en Rust, para el cual se usa actualmente el lenguaje Go, y el proceso en segundo plano para recopilar métricas, se escribirá en OCaml.

Dado que Rust es seguro y rápido, ¿qué más necesitamos? También necesitamos un lenguaje de programación que sea capaz de trabajar en varios niveles (inferior y superior en la pila). Yo no confiaría en Go o Python para hacer frente a cosas de tan bajo nivel que podemos tener en XCP-ng, y -de la misma manera- tampoco en C para hacer cosas de mayor nivel. El uso de Rust brinda el potencial de estar en todas partes en la pila XCP-ng’.

Además, Rust ya no es un lenguaje de «nicho». Por ejemplo, incluso si es excelente, OCaml (usado en XAPI) no se conoce lo suficiente, lo que reduce nuestras oportunidades de contratar fácilmente a personas con experiencia en este idioma. Esto también reduce la capacidad de una comunidad de código abierto para obtener colaboradores. Creemos que Rust no será un obstáculo para eso (tanto para la contratación como para las contribuciones), probablemente incluso lo contrario: un impulsor para atraer a más personas, ya que es una tecnología «deseada» .

La necesidad de rediseñar las herramientas de Linux guest tools (xe-guest-utilities) se debe a problemas de calidad de código y desarrollo fuera del Proyecto Xen bajo el control de Cloud Software Group, lo que dificulta el empaquetado y la influencia de la comunidad en el desarrollo. Se planea crear una nueva variante del conjunto de herramientas ( xen-guest-agent ) completamente desde cero, manteniéndolo lo más simple posible y separando la lógica del agente de las bibliotecas. Se decidió volver a trabajar en el proceso de fondo para recopilar métricas ( rrdd ), ya que es compacto y está separado, lo que facilita experimentar con el uso de un nuevo lenguaje durante el desarrollo.

El próximo año, probablemente se comenzará a trabajar en el desarrollo del componente xenopsd-ng en Rust, que nos permitirá optimizar la arquitectura de la pila de software. La idea principal es concentrar el trabajo con una API de bajo nivel en un componente y organizar la provisión de todas las API de alto nivel al resto de la pila a través de él.

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

Como cada dos semanas en esta fase del desarrollo, y tras 8.3, WineHQ ha lanzado hace unas horas WINE 8.4. Aunque se introducen muchos cambios en estos lanzamientos, de hecho se introducen cientos, la mayoría de ellos son pequeñas mejoras que hacen que la ejecución de aplicaciones de Windows en otras plataformas sea más fiable, pero esta semana han destacado algo que salta a la vista con tan sólo mirar los puntos que han considerado dignos de mostrar por separado.

WineHQ suele destacar de entre 3-6 novedades en cada versión de desarrollo, y esta semana la primera es que se ha dado el paso inicial para soportar Wayland. Hasta ahora se ha podido usar, pero el soporte oficial ha empezado en WINE 8.4. Además, también han destacado limpiezas en el soporte IME, un número de correcciones de pruebas y correcciones de errores varias. Más abajo, en donde está todo lo que han hecho, nos hablan de 51 bugs corregidos y 344 cambios.

Bugs corregidos en WINE 8.4

• Thief: the dark project se cuelga al pulsar la tecla ‘esc’ en el juego si X en modo 24bpp.
• Hard Truck 2: King of The Road (GOG) las películas no se reproducen.
• Amazon Games se instala pero no se inicia (¿necesita código de inicio WindowsFormsApplicationBase?).
• Varias aplicaciones tienen un rendimiento muy pobre después de 4261369e5d8 (Secondhand Lands, SPORE).
• t2embed:t2embed falla en Windows con la codificación UTF-8.
• gdi32:font – test_EnumFonts() falla con Arial Bold en Windows en ruso.
• advapi32:registry – test_enum_value() tiene un par de fallos raros en locales de sistema UTF-8.
• shell32:shelllink – A save(NULL, TRUE) falla aleatoriamente en test_load_save() en Wine.
• d3d9:device – test_wndproc() a veces obtiene un WM_DISPLAYCHANGE inesperado en Wine.
• .test_WSARecv() falla al usar thunks wow64 [Wow64ApcRoutine() sobrescribe el valor de retorno establecido por NtContinue()].
• La salida dxgi:dxgi es demasiado grande en debiant.
• kernel32:sync – test_timer_queue() falla ocasionalmente al borrar el temporizador en Windows 10.
• ntdll:info – test_query_kerndebug() falla en Windows 8 a 10 1709.
• foobar2000 v1.6 se bloquea poco después del inicio en Wine 7.19 o superior.
• d3drm:d3drm a veces se bloquea tras fallar la creación de la interfaz IDirect3DRMDevice* en Wine.
• d3drm:d3drm a veces falla al crear un dispositivo de modo inmediato en Wine.
• vbscript:run a veces falla en Windows UTF-8 locales.
• d3d9:device a veces falla al crear un objeto D3D en Wine, se bloquea.
• ntdll:wow64 de 64 bits falla en Windows 11.
• La ntdll:wow64 de 32 bits falla en Windows 11.
• winhttp:notification falla aleatoriamente en Wine.
• user32:input – test_ToAscii() falla en la configuración regional hindi UTF-8.
• ntdll:pipe – test_blocking() falla a veces en Wine cuando la tubería no está señalizada.
• kernel32:console – test_wait() falla a veces en Windows 8+.
• d3d12:d3d12 – test_desktop_window() falla en Windows 10 1709.
• d3d12:d3d12 – test_create_device() obtiene un 0 refcount inesperado en Windows 10 1909+.
• HS_hevo_gc 8.8.1.1 falla al iniciar.
• desde wine 8.0 print ya no funciona.
• nethack se bloquea.
• regedit/regproc.c – export_key() no puede devolver TRUE.
• Motorola Ready For Assistant no se inicia, necesita ext-ms-win-networking-wlanapi-l1-1-0.dll.
• dbghelp:dbghelp, ntdll:wow64 & psapi:psapi_main fallan en Windows 11 debido a la reasignación de ruta de notepad.exe.
• psapi:psapi_main – La función test_EnumProcessModules() de 64 bits obtiene un caso inesperado de Notepad en Windows 11.
• psapi:psapi_main – La función de 64 bits test_EnumProcessModulesEx() obtiene fallos pcs-6464 y pcs-6432 en Windows 11.
• psapi:psapi_main – La función de 32 bits test_EnumProcessModulesEx() obtiene muchos fallos pcs-3232 debido a errores de copia parcial en Windows 11.
• psapi:psapi_main – La función de 64 bits test_EnumProcessModules() obtiene un tercer módulo inesperado en Windows 11.
• jsproxy:jsproxy se bloquea en Windows 11.
• Fallo en la inicialización del juego Starcraft Remastered.
• mmdevapi:propstore – El test_setvalue_on_wow64() de 32 bits falla en Windows 10 2004+.
• El gif se muestra incorrectamente, con fondos extraños de varios colores.
• gdi32:dc – La prueba SetDeviceGammaRamp() falla en Windows 10 1909.
• El dbghelp de 32 bits:dbghelp no puede ejecutarse en Windows <= 10 1607 debido a la llamada IsWow64Process2().
• La ventana de edición de texto de KakaoTalk IM deja artefactos cuando el texto se desborda y aparece la barra de desplazamiento.
• Wine 8.3 64-bit no aparece en el repositorio de Debian bookworm.
• riched20:txtsrv – test_TxGetNaturalSize falla si el ancho de los glifos de la fuente GUI del sistema es mayor de lo esperado por la prueba.
• La instalación de TextPad 9.1 falla en Wine 6 desde el repositorio de Linux Mint.
• windows.perception.stub:perception – Windows 10 1607 no tiene ISpatialSurfaceObserverStatics2.
• kernel32:loader – test_import_resolution() obtiene datos tls erróneos en Windows 7.
• ldp.exe se bloquea en la función no implementada wldap32.dll.ldap_set_dbg_flags.
• imm32:imm32 – ime_install() falla en algunas localizaciones en Windows.
• ldp.exe se bloquea al intentar conectarse a un host no válido.

WINE 8.2 está disponible en este enlace. En la página de descargas hay información sobre cómo instalar esta y otras versiones en sistemas operativos como Debian y Ubuntu, pero también se puede instalar en Android y macOS.

La próxima versión será WINE 8.5 y llegará el 31 de marzo.

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

Una de las preocupaciones más comunes entre quienes planean pasarse a Linux es si van a disponer del software que necesitan para su trabajo, estudio o entretenimiento. En este artículo comentaremos una categoría en la que el sistema operativo del Pingüino está bastante bien provisto: las aplicaciones para escribir.

En lo personal, no comparto la costumbre de muchos difusores de establecer tablas de equivalencias entre títulos de software libre y privativo ya que creo que los títulos de software libre son lo suficientemente buenos y cuentan con características distintivas que hacen innecesario definirlos a partir de otros títulos.

Del papel a los bits

Con aplicaciones para escribir en Linux nos estamos refiriendo a programas que sirven para redactar y corregir textos. Vamos a dejar afuera por el momento a 2 tipos de programas: los basados en LaTeX y los de creación de publicaciones de escritorio dado que estos están más enfocados a la presentación del texto que a la redacción del mismo.

En la época en que la escritura manuscrita era más frecuente que ahora, uno podía encontrar en las papelerías tres tipos de soporte para escribir.

En primer lugar, teníamos los que en Argentina llamábamos anotadores. Una serie de hojas unidas por la parte superior completamente lisas en las cuales uno elegía la posición en la cual empezar a escribir y el formato se lo daba a mano haciendo los subrayados y viñetas en forma artesanal.

El siguiente peldaño eran los cuadernos tanto de tapa dura como blanda. Ellos incluían hojas con formato, ya sea renglones, cuadrículas o pentagramas. También estaban las que permitían llevar las cuentas con columnas para el Debe y el Haber.

La cima de la pirámide les correspondía a las agendas. Estas incluían hojas formateadas y ordenadas alfabética o cronológicamente para guardar teléfonos y recordar compromisos.

Con el tiempo aparecieron las hojas sueltas con un adhesivo que permitían adherir y quitarlas de cualquier superficie.

Este formato sería replicado por los sistemas operativos modernos.

Aplicaciones para escribir en Linux

Dado que el primer sistema operativo con interfaz gráfica estaba pensado para el manejo de impresoras láser, no es casualidad que uno de los primeros programas que aprovecharan estas características fuera un procesador de textos.

Con el tiempo llegaría la primera versión de Windows incluyendo un bloc de notas. Cuenta la leyenda que este bloc surgió a partir de un fallido procesador de textos que iba a ocupar el lugar que después sería de Word. Bill Gates decidió reciclar el código.

En general en Linux contamos con las siguientes aplicaciones de escritura:

• Bloc de notas: en principio es la más simple de las herramientas de edición de texto dado que sólo trae funciones básicas para la escritura, copiado y pegado. Algunos permiten una forma básica de formateo encerrando porciones del texto entre código. Un Bloc de notas simples que puedes instalar es Paper, que permite un formateo básico y el esquema de colores se adapta al color del fondo.
• Editor de textos: El editor de textos incluye herramientas para diferenciar y establecer jerarquías entre diferentes partes del texto. También se agregan funciones de edición como la búsqueda y reemplazo de palabras. Cada uno de los escritorios incluye su propio editor por lo que solo debes buscarlo en el menú.
• Procesador de textos: El procesador de textos suele formar parte de una suite ofimática que incluye además una planilla de cálculo y un programa de presentaciones. Se diferencia del editor en que puede incorporar elementos como imágenes, tablas o gráficos e incluso incrustar documentos de la suite. Algunos agregan también funciones básicas para la creación de publicaciones de escritorio. La mayoría de las distribuciones Linux incluyen LibreOffice Writer preinstalado y como alternativa (Solo la elijo porque casi nunca habló de ella) WPS Office.
• Entorno integrado de desarrollo: Es un editor pensado para programadores. Es decir, que no solo permite escribir texto, modificar o reemplazarlo, sino que además cuenta con herramientas que corrigen automáticamente la diagramación y auto completan el código dependiendo del lenguaje de programación elegido. Tal vez el mejor IDE por su relación prestaciones, respeto por la privacidad sea VSCodium

Hoy las fronteras entre este tipo de programas están completamente diluidas. Algunos editores de texto incluyen funciones de edición de código mientras que varios entornos integrados de desarrollo disponen de extensiones que incorporan la función de corrección ortográfica convirtiéndolos en un más que decente procesador de textos.

¿Qué opción elegir en cada caso? La verdad es que eso depende de cada usuario. Solamente tienes que descargar, probar y quedarte con la que más te convenga

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

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

Los investigadores del equipo de Google Project Zero, dieron a conocer hace poco mediante una publicación de blog, el descubrimiento de 18 vulnerabilidades detectadas en los módems Samsung Exynos 5G/LTE/GSM.

Según los representantes de Google Project Zero, después de un poco de investigación adicional, los atacantes calificados podrán preparar rápidamente un exploit funcional que permita obtener el control de forma remota a nivel del módulo inalámbrico, conociendo solo el número de teléfono de la víctima. El ataque puede llevarse a cabo sin que el usuario lo perciba y no requiere que realice ninguna acción, lo que vuelve criticas algunas de las vulnerabilidades detectadas.

Las cuatro vulnerabilidades más peligrosas (CVE-2023-24033) permiten la ejecución de código a nivel de chip de banda base a través de la manipulación de redes externas de Internet.

A fines de 2022 y principios de 2023, Project Zero informó dieciocho vulnerabilidades de día cero en los módems Exynos producidos por Samsung Semiconductor. Las cuatro más graves de estas dieciocho vulnerabilidades (CVE-2023-24033 y otras tres vulnerabilidades a las que aún no se les han asignado CVE-ID) permitieron la ejecución remota de código de Internet a banda base.

De las 14 vulnerabilidades restantes, se menciona que tienen un nivel de gravedad menor, ya que el ataque requiere acceso a la infraestructura del operador de red móvil o acceso local al dispositivo del usuario. Con la excepción de la vulnerabilidad CVE-2023-24033, cuya solución se propuso en la actualización de firmware de marzo para los dispositivos Google Pixel, los problemas siguen sin solucionarse.

Hasta el momento, lo único que se sabe sobre la vulnerabilidad CVE-2023-24033 es que está causada por una verificación incorrecta del formato del atributo «accept-type» transmitido en los mensajes SDP (Session Description Protocol ) .

Las pruebas realizadas por Project Zero confirman que esas cuatro vulnerabilidades permiten que un atacante comprometa de forma remota un teléfono a nivel de banda base sin interacción del usuario, y solo requiere que el atacante conozca el número de teléfono de la víctima. Con investigación y desarrollo adicionales limitados, creemos que los atacantes expertos podrían crear rápidamente un exploit operativo para comprometer los dispositivos afectados de forma silenciosa y remota.

Las vulnerabilidades se manifiestan en dispositivos equipados con chips Samsung Exynos, según la información de los sitios web públicos que asignan conjuntos de chips a dispositivos, es probable que los productos afectados incluyan:

• Dispositivos móviles de Samsung, incluidos los de las series S22, M33, M13, M12, A71, A53, A33, A21s, A13, A12 y A04;
• Dispositivos móviles de Vivo, incluidos los de las series S16, S15, S6, X70, X60 y X30;
• Las series de dispositivos Pixel 6 y Pixel 7 de Google; y
• cualquier vehículo que use el chipset Exynos Auto T5123.

Hasta que los fabricantes solucionen las vulnerabilidades, se recomienda a los usuarios que deshabiliten la compatibilidad con VoLTE (Voice-over-LTE) y la función de llamada a través de Wi-Fi en la configuración. Desactivar estas configuraciones eliminará el riesgo de explotación de estas vulnerabilidades.

Debido al peligro de las vulnerabilidades y al realismo de la rápida aparición de un exploit, Google decidió hacer una excepción para los 4 problemas más peligrosos y posponer la divulgación de información sobre la naturaleza de los problemas.

 Como siempre, alentamos a los usuarios finales a que actualicen sus dispositivos lo antes posible para asegurarse de que están ejecutando las últimas compilaciones que solucionan las vulnerabilidades de seguridad reveladas y no reveladas.

Para el resto de vulnerabilidades se seguirá el calendario de divulgación de detalles 90 días después de la notificación al fabricante (información sobre vulnerabilidades CVE-2023-26072, CVE-2023-26073, CVE-2023-26074, CVE-2023-26075 y CVE -2023-26076 ya está disponible en el sistema de seguimiento de errores y para los 9 problemas restantes, la espera de 90 días aún no ha vencido).

Las vulnerabilidades reportadas CVE-2023-2607* son causadas por un desbordamiento de búfer al decodificar ciertas opciones y listas en los códecs NrmmMsgCodec y NrSmPcoCodec.

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

Cheerp: un compilador de C++ para la Web

Se dio a conocer hace poco el lanzamiento de Cheerp 3.0, un compilador que permite compilar cualquier código C/C++ en WebAssembly o JavaScript. La nueva rama se destaca por mover el compilador y las bibliotecas que lo acompañan para usar licencias permisivas de Apache 2.0 y LLVM, en lugar de la política de licencias limitada aplicada anteriormente, que ofrece una opción de licencia GPLv2 para proyectos no comerciales y una licencia propietaria para proyectos comerciales.

Cheerp se puede utilizar tanto para portar bibliotecas y aplicaciones C/C++ existentes para ejecutarlas en el navegador como para crear aplicaciones web de alto rendimiento y componentes WebAssembly desde cero.

Ha pasado más de un año desde el lanzamiento anterior de Cheerp ( Cheerp 2.7 ), y esta nueva versión viene repleta de nuevas características y optimizaciones que, una vez más, mueven el estado del arte del uso de C++ como lenguaje de programación para aplicaciones Web y juegos.

Lo que es más importante, con este lanzamiento estamos realizando un cambio significativo en el modelo de licencias de Cheerp. A partir de Cheerp 3.0, todos los componentes y bibliotecas principales del compilador ahora tienen licencia permisiva bajo la licencia Apache 2.0/LLVM . Esto marca un cambio radical con respecto a nuestro modelo de licencia comercial dual/GPLv2 anterior, lo que permite que Cheerp 3.0 se use para cualquier propósito, sin restricciones.

Sobre Cheerp

El proyecto permite combinar código C/C++ y JavaScript en una aplicación web con la capacidad de acceder desde código JavaScript a funciones desarrolladas originalmente en C/C++, y desde código C/C++ a objetos JavaScript, JavaScript bibliotecas, Web API y todas las características DOM, ademas de que se permite crear compilaciones combinadas, parte del código que se compila en JavaScript y parte en WebAssembly. Admite proyectos de construcción que utilizan las bibliotecas libc y libc++ estándar.

En comparación con el compilador Emscripten, Cheerp genera código intermedio WebAssembly más optimizado y compacto (en promedio, el tamaño de los archivos resultantes es un 7 % más pequeño).

Conceptualmente, las diferencias se reducen al hecho de que Emscripten se utiliza como formato de objeto de WebAssembly y realiza el enlace y la optimización en la etapa de posprocesamiento de WebAssembly (wasm-opt). Cheerp usa el código de bytes LLVM como una representación intermedia para bibliotecas y archivos de objetos, lo que permite optimizaciones más amplias en todo el proyecto que usan metadatos de nivel LLVM sin necesidad de posprocesamiento.

Además, Cheerp usa el optimizador PreExecuter para ejecutar código de forma preventiva en tiempo de compilación, por ejemplo, para convertir constructores usados ​​para inicializar objetos globales en constantes. Además, durante la compilación se utiliza PartialExecuter, que, basándose en el análisis de los parámetros de la función, elimina código que se garantiza que no se utilizará durante la ejecución.

Cheerp también puede generar código JavaScript para trabajar dinámicamente con la memoria cubierta por el recolector de basura. En particular, en lugar de emular un espacio de direcciones tradicional con matrices escritas, Cheerp proporciona una asignación directa de objetos de C++ a objetos de JavaScript, lo que reduce el consumo de memoria porque el recolector de elementos no utilizados de JavaScript tiene la capacidad de eliminar objetos no utilizados. Para mejorar el rendimiento, el código intermedio WebAssembly generado utiliza extensiones SIMD para organizar la paralelización de las operaciones de datos.

Cheerp se puede usar como una plataforma para crear aplicaciones web integradas de cliente/servidor en C++. En la práctica actual, es común desarrollar un front-end separado basado en navegador escrito en JavaScript y un back-end separado escrito en PHP, Python, Ruby o JavaScript/Node.js.

Cheerp proporciona los medios para crear aplicaciones web C++ completas que admitan el backend y el frontend en una sola base de código.

Durante el proceso de compilación, el lado del servidor se compila en código nativo y la interfaz se convierte en una representación de JavaScript. La depuración de todos los componentes del proyecto, incluidos los convertidos a JavaScript, se lleva a cabo utilizando textos fuente C++ utilizando la tecnología Source Map.

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

El código del compilador se basa en los desarrollos de LLVM y Clang e incluye optimizaciones adicionales para mejorar el rendimiento y reducir el tamaño del resultado compilado.

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

NordVPN está lanzando tres de sus productos bajo una licencia de código abierto

El proveedor de VPN, NordVPN dio a conocer hace poco mediante una publicación de blog el lanzamiento de un cliente para Linux de código abierto, la biblioteca de red Libtelio y la biblioteca para compartir archivos Libdrop.

El cliente de Linux proporciona una interfaz de línea de comandos para administrar las conexiones a los servidores NordVPN, lo que permite seleccionar un servidor de la lista en función de la ubicación deseada, cambiar la configuración del protocolo y habilitar el modo Kill Switch, que bloquea el acceso a la red si la conexión a la VPN del servidor se pierde.

Para quienes desconocen de NordVPN, deben saber que este es un servicio VPN proporcionado por la empresa Nordsec con aplicaciones para Microsoft Windows, macOS, Linux, Android, iOS y Android TV.

NordVPN enruta el tráfico a través de un servidor remoto ocultando así la dirección IP y encriptando todos los datos entrantes y salientes. Para el cifrado, NordVPN ha estado utilizando las tecnologías OpenVPN e Internet Key Exchange v2/IPsec en sus aplicaciones y también introdujo su tecnología patentada NordLynx.

NordLynx es una herramienta VPN basada en el protocolo WireGuard , que tiene como objetivo un mejor rendimiento que los protocolos de tunelización IPsec y OpenVPN.

NordVPN para Linux

Sobre el cliente para Linux, se menciona que es compatible con los protocolos NordLynx (basados ​​en WireGuard) y OpenVPN. Usa iptables para cambiar la configuración del firewall, iproute para enrutar, tuntap para tunelizar conexiones y systemd-resolved para resolver nombres DNS.

La biblioteca Libtelio incluye funciones de red típicas y proporciona una implementación de una red virtual MeshNet formada a partir de sistemas de usuario y usada para comunicarse entre sí. Meshnet le permite establecer túneles encriptados entre dispositivos y crear una apariencia de una red local separada basada en ellos.

Estamos haciendo que estos productos sean de código abierto como una señal de nuestro compromiso con la transparencia y la responsabilidad. Queremos el aporte y el escrutinio de la comunidad de programación y mostrarle que tenemos confianza en nuestro propio software.

Este paso también subraya nuestra firme creencia en el progreso colaborativo. La comunidad de ciberseguridad y desarrollo de aplicaciones está llena de codificadores y pentesters talentosos que pueden aportar sus propias perspectivas únicas a nuestras aplicaciones.

A diferencia de VPN, las conexiones en Meshnet no se establecen entre el dispositivo y el servidor VPN, sino entre dispositivos finales, que también participan como nodos para el enrutamiento del tráfico.

Para toda la red MeshNet, puede definir un servidor común para interactuar con el mundo exterior (por ejemplo, si el nodo saliente está ubicado en la casa del usuario, entonces no importa a qué viajes y lugares se conecte el usuario desde los dispositivos conectados a MeshNet, para servicios externos, la actividad de la red se verá así, como si el usuario se estuviera conectando desde su dirección IP de casa).

El código abierto de Libtelio es un paso particularmente importante porque este código forma la columna vertebral de todas nuestras aplicaciones NordVPN, no solo de nuestro cliente Linux. Poner este material en manos de la comunidad de Linux, una de las comunidades de código abierto más sólidas actualmente activas, alienta a los codificadores y desarrolladores talentosos a examinar nuestro código y mejorar nuestro servicio.

Se pueden usar varias implementaciones de Wireguard para cifrar el tráfico en MeshNet. Tanto los servidores VPN como los nodos de usuario dentro de MeshNet se pueden usar como nodos de salida.

Se proporciona un filtro de paquetes configurable para limitar el tráfico dentro de la red y se proporciona un servicio basado en DNS para determinar los hosts. La biblioteca publicada le permite organizar sus propias redes MeshNet en sus aplicaciones.

La biblioteca Libdrop proporciona funciones para organizar el intercambio seguro de archivos entre dispositivos de usuario. Admite el envío y la recepción directos de archivos a través de MeshNet o la red global, sin involucrar servidores de terceros.

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

Debes saber que el código del cliente está abierto bajo la licencia GPLv3. En el desarrollo se utilizaron los lenguajes de programación Go, Rust, C y Python. Las distribuciones compatibles son Ubuntu, Fedora, Manjaro, Debian, Arch, Kali, CentOS y Rasbian.

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

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

Hace pocos días se dio a conocer el lanzamiento de las actualizaciones correctivas de Wasmtime 6.0.1, 5.0.1 y 4.0.1 que llegan a solucionan una vulnerabilidad (ya catalogada bajo CVE-2023-26489) que se calificó como crítica.

La vulnerabilidad permite organizar la escritura de datos en un área de memoria fuera de los límites permitidos para el código WebAssembly aislado, que potencialmente puede ser utilizado por un atacante para organizar la ejecución de su código fuera del entorno WASI aislado.

Para quienes desconocen de Wasmtime, deben saber que este es un tiempo de ejecución para ejecutar aplicaciones WebAssembly con extensiones WASI (WebAssembly System Interface) como aplicaciones independientes normales.

Wasmtime está escrito en Rust y la vulnerabilidad se debe a un error lógico en la definición de reglas de direccionamiento de memoria lineal en el generador de código Cranelift, que traduce una representación intermedia independiente de las arquitecturas de hardware en un código de máquina ejecutable para la arquitectura x86_64.

Sobre la vulnerabilidad corregida, se menciona que en particular, se calcularon direcciones efectivas de 35 bits para las aplicaciones de WebAssembly en lugar de las direcciones de 33 bits permitidas en WebAssembly, lo que cambió el límite de memoria virtual permitida para operaciones de lectura y escritura a 34 GB, mientras que la configuración del entorno de espacio aislado proporciona protección para 6 GB. de la dirección base.

El generador de código de Wasmtime, Cranelift, tiene un error en los objetivos x86_64 donde el cálculo del modo de dirección calcularía por error una dirección efectiva de 35 bits en lugar de la dirección efectiva de 33 bits definida por WebAssembly. Este error significa que, con la configuración de generación de código predeterminada, una operación de carga/almacenamiento controlada por wasm podría leer/escribir direcciones de hasta 35 bits de distancia de la base de la memoria lineal. 

Como resultado, el rango de memoria virtual de 6 a 34 GB desde la dirección base estuvo disponible para lectura y escritura desde aplicaciones WebAssembly. Esta memoria puede albergar otros entornos de WebAssembly o componentes de tiempo de ejecución de WebAssembly.

Por ejemplo (i32.load (i32.shl (local.get 0) (i32.const 3))), se carga desde la dirección WebAssembly $local0 << 3. Cuando se traduce a Cranelift, el calculo de $local0 << 3 en un valor de 32 bits, se amplía a cero a un valor de 64 bits y luego se agrega a la dirección base de la memoria lineal. Cranelift generaría una instrucción de la forma movl (%base, %local0, 8), %dst que calcula %base + %local0 << 3.

El error aquí, sin embargo, es que el cálculo de la dirección ocurre con valores de 64 bits, donde $local0 << 3 se suponía que el cálculo se truncaba a un valor de 32 bits. Esto significa que %local0, que puede usar hasta 32 bits para una dirección, obtiene 3 bits adicionales de espacio de direcciones para ser accesible a través de movl .

Por último, como siempre se recomienda actualizar la paquetería a la última versión disponible, tambien vale la pena mencionar que existen varias soluciones posibles que se pueden emplear para mitigar este problema si la actualización no es posible.

Se menciona que ninguna de estas soluciones está activada de forma predeterminada y requiere una configuración explícita:

• Si no es posible actualizar la versión de Wasmtime, se menciona la opción «Config::static_memory_maximum_size(0)» para habilitar la verificación de límites separados obligatorios en cualquier acceso a la memoria lineal como solución alternativa para bloquear el error (da como resultado una degradación significativa del rendimiento).
• Otra opción es utilizar la configuración «Config::static_memory_guard_size(1 < 36)» para aumentar la cantidad de páginas de protección (Página de protección, se lanza una excepción cuando se accede) ubicadas en el rango de memoria virtual problemático (conduce a reservar una gran cantidad de memoria virtual y limitando el número de aplicaciones WebAssembly concurrentes).
• Si es posible usar un host que no sea x86_64, eso también solucionará este error. Este error no afecta al backend AArch64 de Wasmtime o Cranelift, por ejemplo.

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

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

Se ha publicado el lanzamiento de OpenSSH 9.3, una implementación abierta de cliente y servidor para trabajar con los protocolos SSH 2.0 y SFTP. La nueva versión de OpenSSH 9.3 llega a corregir algunos problemas de seguridad, ademas de añadir algunas nuevas caracteristicas

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.3

En esta nueva versión que se presenta de OpenSSH 9.3 de las nuevas características, es que sshd agrega una opción `sshd -G` que analiza e imprime la configuración efectiva sin intentar cargar claves privadas y realizar otras comprobaciones. Esto permite el uso de la opción antes se han generado claves y para la evaluación de la configuración y verificación por parte de usuarios sin privilegios.

Por la parte de la corrección de errores, se encontró un error lógico en la utilidad ssh-add, por lo que, al agregar claves de tarjetas inteligentes a ssh-agent, las restricciones especificadas con la opción «ssh-add -h» no se pasaban al agente. Como resultado, se agregó una clave al agente, por lo que no se aplicaron restricciones que permitieran conexiones solo desde ciertos hosts.

Otra de las correcciones que se implemento, es el de la vulnerabilidad en la utilidad ssh que podría hacer que los datos se leyeran desde el área de la pila fuera del búfer asignado al procesar respuestas de DNS especialmente diseñadas si la configuración VerifyHostKeyDNS está incluida en el archivo de configuración.

El problema existe en la implementación integrada de la función getrrsetbyname(), que se usa en versiones portátiles de OpenSSH creadas sin usar la biblioteca ldns externa (–with-ldns) y en sistemas con bibliotecas estándar que no admiten getrrsetbyname () llamar. La posibilidad de explotación de la vulnerabilidad, que no sea para iniciar una denegación de servicio para el cliente ssh, se considera improbable.

De las nuevas versiones que se destacan:

• En scp y sftp corrige la corrupción del medidor de progreso en pantallas anchas;
• ssh-add y ssh-keygen usa RSA/SHA256 cuando prueba la usabilidad de claves privadas, ya que algunos sistemas están comenzando a deshabilitar RSA/SHA1 en libcrypto.
• En sftp-server se realizo un arreglo para una fuga de memoria.
• En ssh, sshd y ssh-keyscan se elimino el código de compatibilidad y simplificar lo que queda del protocolo «vestigal».
• Se realizo una corrección en la serie de resultados de análisis estático de Coverity de bajo impacto.
  Estos incluyen varios informados:
  * ssh_config(5), sshd_config(5): mencionar que algunas opciones no son
  primer partido ganado.
  * Registro de reelaboración para las pruebas de regresión. Las pruebas de regresión ahora
  capturar registros separados para cada invocación ssh y sshd en una prueba.
  * ssh(1): hacer que `ssh -Q CASignatureAlgorithms` funcione como página de manual
  dice que debería; bz3532.

Por último cabe destacar, que se puede observar una vulnerabilidad en la biblioteca libskey incluida con OpenBSD, que se usa en OpenSSH. El problema ha estado presente desde 1997 y puede provocar un desbordamiento del búfer en la pila cuando se procesan nombres de host especialmente diseñados.

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.3 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.2.tar.gz

Entramos al directorio creado:

cd openssh-9.2

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/2dyFrb8
via IFTTT