Hay palabras que pueden tener distintos significados dependiendo de quien las use. Hace algunos años en una serie del Disney Channel los protagonistas instalaban un virus por utilizar «software de código abierto». No se trataba de una campaña orquestada por las empresas de software privativo, Los guionistas confundieron open source con freeware y pensaron que estaban hablando de cualquier programa disponible sin costo en Internet.

Me acordé de esto, porque Satya Nadella, el presidente de Microsoft le acaba de decir al Wall Street Journal que Windows 11 pretende ser el centro de «un ecosistema tecnológico abierto». ¿Debemos enterder que cualquiera va a poder revisar, modificar o redistribuir el código. No, para nada.

El concepto de abierto de Microsoft

En un reportaje por video conferencia con el Wall Street Journal, Nadella afirmó que mientras Google (Chrome OS y Android) y Apple arrastran a los usuarios a plataformas cada vez más cerradas, Windows apuesta a los usuarios que quieren libertad para decidir lo que usan pretendiendo ser el más abierto ecosistema que existe (Por si se lo están preguntando, lo dijo sin reirse).

Para Nadella, un ecosistema abierto es el que puede interactuar con otro, por ejemplo conectando el teléfono al ordenador utilizando a este último para conectarse con otros teléfonos u ordenadores. También habla de la capacidad de Windows de correr varios tipos de aplicaciones, entre ellos:

• Aplicaciones nativas.
• Aplicaciones web progresivas.
• Aplicaciones Android.

Cuando la periodista del Wall Street Journal le pregunta por las diferencias entre el nuevo modelo de Windows y el de Apple, Nadella le responde que es la capacidad del usuario de poder elegir otras tiendas de aplicaciones. También señala que aunque Windows 11 tendrá integrada su propia plataforma colaborativa (Microsoft Teams), de ninguna manera se bloqueará a competidores como Zoom o Slack.

Nuestro concepto de abierto

Por algún motivo, lo primero que pensé al ver los 7 minutos del reportaje es que ya que están tan abiertos a otras plataformas, bien podrían habilitar el soporte para Ext4. Sería genial poder ver los archivos de la partición home de Linux en el explorador de Windows y no tener que guardarlos en la nube. Si, ya sé que hay programas. Pero, ya que van a abrirse a otras plataformas, bien podrían habiitarlo en forma nativa.

Por otra parte, más allá de la posibilidad de instalar aplicaciones de Android (Nada menos que de la tienda de Amazon, una empresa cuyas prácticas monopólicas están siendo cuestionadas) no hay nada nuevo, salvo la ampliación de los formatos de aplicaciones que se pueden subir a la tienda oficial (De la que casi nadie descargaba nada). Uno ya podía instalar Zoom o Google Meet y desactivar Skype (En el futuro reemplazado por Teams) Una muestra de apertura sería que te dejaran elegir que navegador, cliente de video conferencia, servicio de almacenamiento en la nube o tienda de aplicaciones utilizar durante la instalación).

Todo este rollo de la apertura es para escapar del escrutinio de los entes reguladores que ya pusieron sus ojos en Apple, Google y Amazon.

Tampoco es una buena señal de «apertura» la obligación de contar con un chip TPM que no suele venir incluído en la mayoría de las placas base.  Según nuestro relevamiento, su precio en los portales de compra muestran una tendencia a subir.

Recordemos que según la Open Source Initiative, el concepto de abierto aplicado al software debe cumplir los siguientes requisitos:

• No se puede poner ningún tipo de restricciones a la libre distribución. Una de las funciones del dichoso chip TPM es impedir la piratería.
• El código fuente debe ser accesible.
• La licencia debe permitir modificaciones y trabajos derivados. ¿Nunca soñaron con hacer su propio Windows? Bueno, no pueden.
• No se puede impedir el uso del programa a ninguna persona por ninguna razón. Por ejemplo por vivir en Cuba o no pagar la licencia.
• El derecho a usar un programa no puede estar sujeto al uso en conjunto con otros programas o  una tecnología específica. ¿Cómo un chip TPM por ejemplo?

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

Linus torvalds asi como muchos desarrolladores del Kernel y de diferentes distribuciones han expresado su agrado sobre Rust e incluso en más de una ocasión se ha presentado el tema sobre la implementación de controladores en este lenguaje de programación sobre el Kernel de Linux.

Y sobre ello ya se han dado a conocer diversos trabajos de los cuales ya hemos mencionado aquí en el blog y podemos mencionar por ejemplo al experimento exitoso del conjunto alternativo de utilidades, coreutils, reescrito en Rust (este incluye utilidades como sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln y ls).

Ante esto, Linus torvalds no ha dado del todo su punto a favor sobre esta iniciativa y ha expresado los puntos negativos (puedes consultar los detalles en el siguiente enlace.)

Pese a la dura crítica de Linus, los trabajos sobre la implementación de Rust en el Kernel no han dejado de seguir adelante y hace poco se presentó la primera versión de la biblioteca Aya, que permite crear controladores eBPF en Rust que se ejecutan dentro del kernel de Linux en una máquina virtual JIT especial.

A diferencia de otras herramientas de desarrollo EBPF, Aya no utiliza libbpf y el BCC compilador, pero ofrece su propia implementación escrita en Rust que utiliza la libc paquete de cajón a las llamadas al sistema del kernel directamente de acceso. La construcción de Aya no requiere las herramientas del lenguaje C ni los encabezados del kernel.

Para quienes desconocen de eBPF, deben saber que este es un intérprete de código de bytes integrado en el kernel de Linux que le permite crear controladores de operaciones de red, monitorear el funcionamiento del sistema, interceptar llamadas al sistema, controlar el acceso, procesar eventos con cronometraje, calcular la frecuencia y el tiempo de las operaciones y realizar el seguimiento mediante kprobes/uprobes/tracepoints.

Gracias a la compilación JIT, el código de bytes se traduce en instrucciones de máquina sobre la marcha y se ejecuta con el rendimiento del código nativo. XDP proporciona un medio para ejecutar programas BPF en el nivel del controlador de red, con acceso directo al búfer DMA de paquetes, lo que le permite crear controladores de alto rendimiento para condiciones de alta carga de red.

Sobre Aya

De las características clave que se mencionan de Aya podremos encontrar que cuenta con el soporte para BTF (formato de tipo BPF), que proporciona información de tipo en pseudocódigo BPF para verificar y comparar tipos proporcionados por el kernel actual. El uso de BTF hace posible crear controladores eBPF universales que se pueden usar sin tener que volver a compilarlos con diferentes versiones del kernel de Linux.

Asi como tambien el soporte para llamadas bpf-to-bpf, variables globales e inicializadores, lo que permite diseñar programas para eBPF por analogía con programas convencionales utilizando aya como tiempo de ejecución, anulando funciones teniendo en cuenta el trabajo en eBPF.

Por otra parte, tambien cuenta con el soporte para tipos de kernel internos, incluidas matrices regulares, mapas hash, pilas, colas, seguimientos de pila y estructuras para sockets y seguimiento del rendimiento.

Tambien cuenta con la capacidad para crear varios tipos de programas eBTF, incluidos programas para filtrado y gestión de tráfico, cgroup y varios controladores de socket, programas XDP y tambien soporte de plataforma para el procesamiento de solicitudes asincrónicas en modo tokio sin bloqueo y async-std .
Compilación rápida, sin estar atado a la compilación del kernel ni a los encabezados del kernel.

Es importante mencionar que el proyecto aún se considera experimental, ya que la API aún no está estabilizada y continúa evolucionando. Además, aún no se han implementado todas las funciones concebidas.

Para finales de año, los desarrolladores esperan llevar la funcionalidad de Aya a la par con libbpf y en enero de 2022 formar la primera versión estable. También se planea combinar las partes de Aya necesarias para escribir código Rust para el kernel de Linux con los componentes del espacio de usuario utilizados para cargar, adjuntar e interactuar con programas eBPF.

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

Hace pocos se dio a conocer el lanzamiento de la nueva versión  Tor 0.4.6.5 la cual se considera como la primera versión estable de la rama 0.4.6, que ha evolucionado durante los últimos cinco meses.

La rama 0.4.6 se mantendrá como parte de un ciclo de mantenimiento regular; las actualizaciones se interrumpirán 9 meses o 3 meses después del lanzamiento de la rama 0.4.7.x, además de que se continúa proporcionando un ciclo de soporte largo (LTS) para la rama 0.3.5, cuyas actualizaciones se publicarán hasta el 1 de febrero de 2022.

Al mismo tiempo, se formaron las versiones 0.3.5.15, 0.4.4.9 y 0.4.5.9 de Tor, que corrigieron las vulnerabilidades de DoS que podrían causar la denegación de servicio a los clientes de servicios de cebolla y retransmisiones.

Principales novedades de Tor 0.4.6.5

En esta nueva versión se agregó la capacidad de crear «servicios onion» basados ​​en la tercera versión del protocolo con autenticación de acceso de clientes a través de archivos en el directorio ‘authorized_clients’.

Además de que tambien se proporcionó la capacidad de pasar información de congestión en datos extrainfo que se pueden usar para equilibrar la carga en la red. La transferencia métrica está controlada por la opción OverloadStatistics en torrc.

Tambien podremos encontrar que se ha agregado una bandera para los relés que permite al operador del nodo comprender que el relé no está incluido en el consenso cuando los servidores seleccionan directorios (por ejemplo, cuando hay demasiados relés en una dirección IP).

Por otra parte se menciona que se eliminó el soporte para los servicios onion más antiguos basados ​​en la segunda versión del protocolo, que se declaró obsoleto hace un año. Se espera la eliminación completa del código asociado con la segunda versión del protocolo en otoño. La segunda versión del protocolo se desarrolló hace unos 16 años y, debido al uso de algoritmos obsoletos, no se puede considerar segura en las condiciones modernas.

Hace dos años y medio, en la versión 0.3.2.9, se ofreció a los usuarios la tercera versión del protocolo, notable por la transición a direcciones de 56 caracteres, protección más confiable contra fugas de datos a través de servidores de directorio, un extensible estructura modular y el uso de algoritmos SHA3, ed25519 y curve25519 en lugar de SHA1, DH y RSA-1024.

De las vulnerabilidades solucionadas se mencionan las siguientes:

• CVE-2021-34550: acceso a un área de memoria fuera del búfer asignado en el código para analizar descriptores de servicios cebolla basados ​​en la tercera versión del protocolo. Un atacante puede, colocando un descriptor de servicio de cebolla especialmente diseñado, iniciar el bloqueo de cualquier cliente que intente acceder a este servicio de cebolla.
• CVE-2021-34549 – Capacidad para realizar un ataque que provoque la denegación de servicio de los relés. Un atacante puede formar cadenas con identificadores que provoquen colisiones en la función hash, cuyo procesamiento conduce a una gran carga en la CPU.
• CVE-2021-34548: un relé podría falsificar las celdas RELAY_END y RELAY_RESOLVED en flujos semicerrados, lo que permitió terminar un flujo que se creó sin la participación de este relé.
• TROVE-2021-004: se agregaron verificaciones adicionales para detectar fallas al acceder al generador de números aleatorios de OpenSSL (con la implementación predeterminada de RNG en OpenSSL, tales fallas no aparecen).

De los demás cambios que se destacan:

• Se ha agregado al subsistema de protección DoS la capacidad de limitar la intensidad de las conexiones de los clientes a los relés.
• En relevos se implementa la publicación de estadísticas sobre el número de servicios cebolla en base a la tercera versión del protocolo y el volumen de su tráfico.
• Se eliminó el soporte para la opción DirPorts del código para relés, que no se usa para este tipo de nodo.
  Refactorización del código.
• El subsistema de protección DoS se ha trasladado al administrador de subsistemas.

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

¿Como obtener Tor 0.4.6.5 ?

Para poder obtener esta nueva versión, basta con dirigirnos al sitio web oficial del proyecto y en su sección de descargas podremos obtener el código fuente para su compilación. Puedes obtener el código fuente desde el siguiente enlace.

Mientras que para el caso especial de usuarios de Arch Linux podremos obtenerlo desde el repositorio de AUR. Solo que en estos momentos no se ha actualizado el paquete, puedes monitorearlo desde el siguiente enlace y en cuanto este disponible puedes realizar la instalación tecleando el siguiente comando:

yay -S tor-git

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