Linus Benedict Torvalds es un ingeniero de software, conocido por iniciar y mantener el desarrollo del kernel Linux

Hace unas pocas semanas compartimos aquí en el blog la noticia sobre una propuesta que se ha reavivado después de muchos años en relación a la viabilidad de adoptar el código C++ en el kernel de Linux, una propuesta que fue lanzada en el 2018 a modo de broma.

La propuesta fue nuevamente lanzada en las listas de correo del Kernel, pero ya de manera seria por Hans Peter Anvin, un desarrollador clave del kernel de Intel y el desarrollador planteaba la viabilidad de la inclusión de C++ como un tercer lenguaje de programación en Linux.

Con la introduccion de Rust en Linux, muchos desarrolladores y parte de la comunidad vieron un gran camino por delante en Linux, además de que también han surgido diversas «ideas» de implementar otros lenguajes de programación, la propuesta de implementar C++  abre nuevamente un debate entre muchos de los desarrolladores del Kernel e incluso que Linus Torvalds nuevamente explique de la manera más pasiva y comprensiblemente posible, el porqué Linux no está preparado para C++ (sarcasmo).

Hay que recordar que Rust no fue aceptado en Linux de un momento a otro, pues el proyecto de Rust en Linux (Rust for Linux) tuvo una serie de revisiones por parte del mismo Linus Torvalds antes de que fuera aceptado en la rama principal del Kernel para que fuera incluido y cabe mencionar que el padre de Linux no fue nada blando al momento de realizar las revisiones y comentar sobre los cambios propuestos.

Ahora en el caso de la propuesta de C++ como tercer lenguaje de programación, en el supuesto caso, y digo “supuesto”, la implementación debería de pasar por una serie de revisiones similar, si no hasta más rigurosa de lo que fue para Rust. Y es que el hecho de mencionar esto es debido a que C++ y Linus tienen su historia, pequeña, pero que tiene ya muchos años.

La razón de mencionar que el caso de C++ como un tercer lenguaje de Linux como un “supuesto”, es debido a que el padre de Linux, Linus Torvalds, no ha visto ni verá con buenos ojos a C++, ya que en más de una ocasión en cada oportunidad que tiene ha mencionado que C++ «es un lenguaje terrible».

Por mencionar algunos de los momentos en los que se ha planteado el uso de C++ en Linux y Linus Torvalds ha expresado no solo su desacuerdo, sino un «cierto odio» hacia C++ el cual sobrepone para mencionar el porqué «simplemente no es una opción para Linux», uno de los más recientes fue durante las revisiones de la implementación de Rust, ya que durante una discusión en una la publicación de Google, se mencionó la inclusión de C++ en forma de sugerencia:

«La solución aquí es simple: simplemente use C++ en lugar de Rust»

A lo cual Linus Torvalds no pudo evitar reírse y su respuesta fue:

«LOL». «C++ no resuelve ninguno de los problemas de C y sólo empeora las cosas, realmente es un lenguaje basura.

Para las personas a las que no les gusta C, opten por un lenguaje que realmente les ofrezca algo que valga la pena. Como lenguajes con seguridad de memoria y «que» pueden evitar algunos de los peligros de C, o lenguajes que tienen soporte interno de GC «recolección de basura» y facilitan la administración de la memoria. C++ resuelve todos los problemas equivocados, y cualquiera que diga ‘reescribir el núcleo en C++’ es demasiado ignorante para siquiera saberlo.»

Linus Torvalds siempre ha considerado C ++ como un “desperdicio” y lo ha considerado “inútil” pues para el “C++ no puede resolver el problema del lenguaje C en absoluto, solo empeorará las cosas». Torvalds cree a quienes no les gusta el lenguaje C pueden buscar un lenguaje que realmente pueda aportar valor. Por ejemplo, lenguajes que tienen seguridad de memoria y pueden evitar peligros ocultos causados ​​por C (como por ejemplo Rust).

En comparación con C ++, Linus ha mencionado el porqué C, es su elección estándar:

“Cuando la gente habla de los peligros causados ​​por C, también habla de una parte de la razón por la que C es tan poderoso: ‘Te permite implementar eficientemente todas estas cosas de bajo nivel’”, mencionó Linus. Además, aunque GC es bueno para simplificar la programación en la mayoría de los casos, generalmente no es algo que se pueda hacer en la programación de sistemas de bajo nivel.

De hecho, en las listas de correo se menciona que en algún momento se intentó usar C++ en Linux, en 1992 (más o menos un año después del nacimiento de Linux), pero esto se quedó solo asi como «un intento», ya que Torvalds menciona sobre este intento:

Es terrible. Créeme: escribir código de kernel en C++ es una IDEA ESTÚPIDA DE MIERDA.

El hecho es que los compiladores de C++ no son confiables. Eran aún peores en 1992, pero algunos hechos fundamentales no han cambiado:

– todo el asunto del manejo de excepciones en C++ está fundamentalmente roto. Está «especialmente» roto para los kernels.
– cualquier compilador o lenguaje que le guste ocultar cosas como asignaciones de memoria a sus espaldas simplemente no es una buena elección para un kernel.
– puedes escribir código orientado a objetos (útil para sistemas de archivos, etc.) en C, «sin  la basura que es C++.»

Ante estos y otros tantos comentarios, podemos entender un poco sobre el porqué para Linus Torvalds C++ es un lenguaje horrible, además de que ha criticado al lenguaje por ser utilizado por «programadores de baja calidad, hasta el punto en que es mucho, mucho más fácil generar basura total y absoluta con él.» Y es que pareciera que C++ fue en algún momento, un amargo sabor de boca para Torvalds, ya que en sus críticas da a pensar que intento probar con C++, pues menciono en un correo que:

«C++ conduce a elecciones de diseño realmente malas. Invariablemente comienzas a usar las características «agradables» de la biblioteca del lenguaje como STL y Boost y otra basura total y absoluta, que pueden «ayudarte» a programar, pero causan:

cantidades infinitas de dolor cuando no funcionan (y cualquiera que me diga que STL y especialmente Boost son estables y portables está tan lleno de tonterías que ni siquiera es divertido)
modelos de programación abstractos ineficientes donde dos años más tarde notas que alguna abstracción no fue muy eficiente, pero ahora todo tu código depende de todos los bonitos modelos de objetos a su alrededor, y no puedes arreglarlo sin reescribir tu aplicación.»

Entonces, retomando el titulo de la publicación y ya habiendo entendido un poco la punta del iceberg del odio que tiene Linus Torvalds hacia C++, no hace falta indagar mucho puesto que para Torvalds, Linux no necesita ningún otro lenguaje porque C le basta y durante todo este tiempo C es, ha sido y será el lenguaje que se adapta a su trabajo y Linus seguirá atacando a los lenguajes de programación que no le gustan, en especial a C++.

Y es que una de entre las tantas razones por la que C++ simplemente no es considerado para Linux, es que admite excepciones, mientras que Rust no al igual que C, ya que en la programación del kernel, no se puede permitir que una excepción no detectada pueda desactivar el sistema operativo, además de que ni siquiera se debe pensar que el kernel falle alguna vez.

Y en el dado «supuesto» que Torvalds llegara a considerar a C++ en Linux, esto podría suponer más que un beneficio la inclusión de un tercer o más lenguajes de programación, se convertirían en un problema, ya que por ejemplo con la implementación de Rust actualmente ya están empezando a salir a la luz algunos problemas, tales como los que ya mencionamos en una publicación sobre el estado actual de Rust en Linux.

Dentro de los desafíos actuales mencionamos en el artículo que uno de ellos es el «reclutar más revisores para el código que se está desarrollando» además de que el progreso del compilador Rust basado en GCC se ha ralentizado, también hay muy pocas posibilidades de que reescriban grandes porciones del kernel en Rust corto plazo e incluso muy bajas posibilidades de que puedan hacerlo sin introducir todo tipo de errores y sobre todo los problemas de compatibilidad.

Si estos problemas, que se están viendo reflejados en Rust los sumamos en C++ o cualquier otro lenguaje que se llegue a sumar en Linux, el desarrollo del Kernel se vería afectado en gran medida y con ello de inicio no estaríamos recibiendo una versión cada dos meses, sino que sería el desarrollo entre versiones de más tiempo, se requerirían de más desarrolladores, más revisores y todo esto se traduce en un mayor esfuerzo.

Sin dudas el planteamiento de la introduccion de C++ como un tercer lenguaje de programación, está lejos de ser considerado y como ya mencionamos, uno de los impedimentos principales para ello es el mismísimo Linus Torvalds.

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

Logo de Arkime

Hace pocos días se dio a conocer el lanzamiento de la nueva versión de Arkime 5.0, la cual llega con una de las características más esperadas, la cual es la búsqueda masiva de Cont3xt, asi como también unificación del subsistema de configuración, nuevas configuraciones y más.

Para quienes desconocen de Arkime, deben saber que esta es una herramienta de captura de paquetes y análisis de red de código abierto, cuenta con herramientas para evaluar visualmente los flujos de tráfico y buscar información relacionada con la actividad de la red.

Arkime se destaca por capturar e indexar el tráfico en formato PCAP, con herramientas para un acceso rápido a los datos indexados. La adopción del estándar PCAP facilita su integración con analizadores de tráfico existentes como Wireshark. La cantidad de datos almacenados está limitada solo por el tamaño disponible de la matriz de discos. Los metadatos de sesión se indexan en un clúster basado en el motor Elasticsearch u OpenSearch.

Captura de pantalla de Arkime

El componente de captura de tráfico opera en modo multiproceso y aborda tareas como monitoreo, escritura de volcados de PCAP en disco, análisis de paquetes capturados y envío de metadatos sobre sesiones y protocolos al clúster Elasticsearch/OpenSearch. Además, ofrece la posibilidad de almacenar archivos PCAP en forma cifrada.

¿Qué hay de nuevo en Arkime 5.0?

En esta nueva actualización que se presenta de Arkime 5.0 se destaca la introduccion de la búsqueda masiva de Cont3xt, la cual permite recopilar información disponible en múltiples indicadores simultáneamente con una sola consulta, lo que agiliza significativamente el proceso de análisis de datos.

Otro de los cambios que se destaca de la nueva versión, es que la interfaz de usuario de Arkime ha sido renovada, pues ahora la sección de detalles de la sesión ha sido rediseñada para optimizar el espacio en pantalla y se han agregado menús desplegables de múltiples visualizadores en las pestañas lo que facilita la navegación y la búsqueda de información.

Además de ello, Arkime 5.0 introduce soporte para los métodos de huellas dactilares de tráfico JA4 y JA4+, que se muestra como nuevos campos de sesión para visualización y búsqueda para identificar protocolos y aplicaciones de red. El soporte se puede añadir mediante un complemento fácil de instalar.

Otra mejora significativa en Arkime 5.0 es la unificación del subsistema de configuración en todas las aplicaciones, ya que ahora se han trasladado a un subsistema de configuración que admite el procesamiento de configuraciones en diferentes formatos. Esto permite la compatibilidad con múltiples formatos de archivos de configuración y facilita la recuperación desde fuentes de disco y de red. Además, puede cargar configuraciones desde diversas fuentes, como el disco, a través de la red mediante HTTPS o desde OpenSearch/Elasticsearch.

De los demás cambios que se destacan:

• La capacidad para importar volcados de PCAP sin conexión directamente desde varias fuentes de red, como S3 y HTTP(S), es otra característica destacada de esta versión.
• Se incluye una serie de correcciones de errores y optimizaciones, como la actualización de zstd, nghttp2, maxmind y yara, entre otros.
• El sistema de autorización se ha unificado y separado en un módulo independiente
• Se han añadido nuevos modos de autorización, incluidos básico, formulario, básico+formulario, básico+oidc, headerOnly, encabezado+digest y encabezado+básico.
• Se eliminó el modo de solo panel.
• zstd a veces no leía todos los paquetes
• visualización detallada de la sesión mejorada
• enlace de detalle de sesión a un enlace ahora, elementos de columna de información de selección múltiple ahora
• nuevos viewRoles en el archivo de configuración por integración para controlar el acceso
• transferir la propiedad de los recursos
• nueva fuente de datos csv/json compatible
• soporte para nueva fuente de datos de redis
• modo de demostración agregado

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

Descargar y obtener Arkime 5.0

Para los interesados en la nueva versión, deben saber que pueden obtener los paquetes precompilados RPM y DEB para distribuciones con soporte para este tipo de paquetes. Los paquetes los puedes obtener en el siguiente enlace.

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

Logo de la Post-Quantum Cryptography Alliance

Hace pocos días, la Fundación Linux, dio a conocer mediante una publicación de blog la formación de la Post-Quantum Cryptography Alliance (PQCA), una entidad dedicada a abordar los desafíos de seguridad asociados con la implementación de la computación cuántica.

Se menciona que la misión principal de la Post-Quantum Cryptography Alliance es desarrollar e implementar algoritmos de cifrado post-cuánticos para contrarrestar las amenazas que plantea la computación cuántica para la seguridad de la información. La Alianza se compromete a crear implementaciones altamente confiables de algoritmos de cifrado post-cuánticos estandarizados, además de participar activamente en la estandarización y prototipado de nuevos algoritmos post-cuánticos.

La PQCA pretende ser la base central para organizaciones y proyectos de código abierto que buscan bibliotecas y paquetes listos para producción para respaldar su alineación con el Aviso de ciberseguridad de la Agencia de Seguridad Nacional de EE. UU. en relación con el Commercial National Security Algorithm Suite 2.0. La PQCA se esforzará por permitir la agilidad criptográfica en todo el ecosistema durante los plazos descritos en el mismo.

Entre los miembros fundadores de la alianza se encuentran destacadas empresas y organizaciones como AWS, Cisco, Google, IBM, NVIDIA, IntellectEU, Keyfactor, Kudelski IoT, QuSecure y SandboxAQ, junto con la Universidad de Waterloo. Es importante destacar que entre los participantes de la iniciativa se encuentran coautores de algoritmos como CRYSTALS-Kyber, CRYSTALS-Dilithium, Falcon y SPHINCS+, los cuales son resistentes a los ataques de computación cuántica y han sido seleccionados para estandarización por el NIST.

La necesidad de promover algoritmos criptográficos poscuánticos surge debido al rápido desarrollo de las computadoras cuánticas. Estas computadoras tienen la capacidad de resolver de manera significativamente más rápida, problemas como la factorización de números primos (RSA) y los logaritmos discretos de puntos de curvas elípticas (ECDSA), que son la base de los algoritmos modernos de cifrado de clave pública asimétrica. Estos problemas son intratables de manera efectiva en procesadores clásicos.

La PQCA participará en varios proyectos técnicos para respaldar sus objetivos, incluido el desarrollo de software para evaluar, crear prototipos e implementar nuevos algoritmos poscuánticos. Al proporcionar estas implementaciones de software, la fundación busca facilitar la adopción práctica de la criptografía poscuántica en diferentes industrias.

El trabajo de la PQCA se basa en las bases sentadas por muchos de los miembros fundadores durante la última década preparándose para la transición a la criptografía poscuántica. Varios miembros de la PQCA han desempeñado papeles importantes en la estandarización de la criptografía poscuántica hasta la fecha, incluso como coautores de los primeros cuatro algoritmos seleccionados en el Proyecto de estandarización de criptografía poscuántica del NIST (CRYSTALS-Kyber y CRYSTALS-Dilithium, Falcon y ESFINCAS+).

Aunque las capacidades actuales de las computadoras cuánticas no son suficientes para descifrar los algoritmos de cifrado clásicos y las firmas digitales basadas en claves públicas como ECDSA, se anticipa que esta situación pueda cambiar en los próximos 10 años. Por lo tanto, es fundamental desarrollar y adoptar algoritmos criptográficos poscuánticos que sean resistentes a los ataques cuánticos, para garantizar la seguridad de la información en el futuro.

Se menciona que actualmente, dos proyectos se han transferido bajo los auspicios de la alianza, los cuales son:

• Open Quantum Safe (OQS): Este proyecto se dedica al desarrollo y prototipado de sistemas criptográficos que sean resistentes a la computación cuántica. OQS está trabajando en una biblioteca abierta en lenguaje C llamada liboqs, que contiene implementaciones de algoritmos post-cuánticos. Además, el proyecto está desarrollando una serie de proyectos para integrar estos algoritmos en varios protocolos tales como SSH, TLS, S/MIME y X.509 y aplicaciones como lo son OpenSSL, OpenSSH, wolfSSL, entre otras.

• PQ Code Package: Este proyecto se centra en crear y mantener implementaciones altamente confiables de algoritmos poscuánticos que se promueven como estándares. En su primera etapa, el proyecto tiene como objetivo el proporcionar una implementación del algoritmo ML-KEM (Mecanismo de encapsulación de claves basado en módulo). Posteriormente, se comenzará a trabajar en la implementación de ML-DSA y SLH-DSA. Para garantizar la confiabilidad de las implementaciones, se llevará a cabo una auditoría externa e independiente, además de una verificación formal. Además, hay interés en continuar desarrollando las implementaciones existentes de ML-KEM en lenguajes como C y Rust, así como en opciones optimizadas utilizando instrucciones AVX2 y extensiones de CPU Aarch64.

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

Nuitka el compilador optimizador Python que crea ejecutables

Nuitka es un proyecto de Python escrito en Python que compila Python en C, es decir un compilador de Python capaz de generar un binario independiente que no requiriera el tiempo de ejecución de Python en el sistema donde se ejecuta.

Nuitka se destaca por mantener, en la medida posible, la máxima compatibilidad con el ecosistema Python, lo que asegura que bibliotecas de terceros como NumPy funcionen de manera fiable. Además, Nuitka se esfuerza por mejorar el rendimiento de los programas Python compilados siempre que sea factible, manteniendo al mismo tiempo una compatibilidad general sólida.

Sin embargo, es importante tener en cuenta que las mejoras de rendimiento no están garantizadas y pueden variar considerablemente según la carga de trabajo. Es posible que algunos programas no experimenten mejoras significativas en el rendimiento. Por lo tanto, como regla general, se recomienda no depender de Nuitka como una solución para mejorar el rendimiento, sino más bien como una herramienta de empaquetado confiable.

Nuitka admite las versiones 2.6, 2.7 o 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11 de Python y cuenta con soporte para Linux, FreeBSD, NetBSD, macOS X y Windows, además de soporte para las arquitecturas x86, x86_64 (amd64) y ARM.

¿Qué hay de nuevo en Nuitka 2.0?

Actualmente, Nuitka se encuentra en su versión 2.0 la cual hace poco fue lanzada y en ella se destaca que se han incorporado diversas mejoras y funcionalidades a la configuración del paquete, lo que permite consultar valores de paquetes instalados durante la compilación y utilizar dichos valores para definir el backend. La compatibilidad con variables en la configuración simplifica muchas tareas estándar que anteriormente requerían la conexión de complementos.

Además, se ha añadido soporte para parámetros definidos por el usuario para influir en la configuración de cada paquete. Estos parámetros pueden ser leídos utilizando la nueva función get_parameter y emplearse para seleccionar el comportamiento de los módulos. Por ejemplo, es posible configurar un parámetro para deshabilitar Numba JIT o Torch JIT.

Se introdujo la opción «–include-onefile-external-data» para especificar plantillas de archivos de datos definidos en la configuración pero que deben suministrarse por separado del archivo ejecutable cuando se compila en modo onefile. Asimismo, se agregó la opción «–cf-protection» para configurar el modo de protección CFI (Integridad de flujo de control) en GCC, el cual previene las violaciones del orden de ejecución normal (flujo de control).

De los demás cambios que se destacan:

• Soporte agregado para decisiones de módulo, que permiten a los usuarios influir en la configuración de Nuitka por paquete.
• Adición de soporte para configuraciones de paquetes de Nuitka, lo que facilita la consulta de valores de paquetes instalados.
• Detección de ejecutables compilados demasiado grandes para evitar violaciones de límites de tamaño.
• Mejoras en la generación de informes y la capacidad de crear relaciones públicas con los cambios en Nuitka-Watch.
• Se ha implementado un análisis de tipos de bucles, que se utilizará en el futuro para implementar optimizaciones selectivas.
• Se han agregado optimizaciones para acelerar el trabajo con variables no compartidas y de escape.
• Solución alternativa para funciones privadas como ranuras Qt que no tenían nombres alterados.
• Corrección de la detección de paquetes pip al usar Nuitka.
• Mejoras en el analizador de carga diferida para pydantic.
• Agregado de archivos de datos para varios paquetes, como pyocd y cmsis_pack_manager.
• Correcciones para manejar correctamente las especificaciones ampliadas en tiempo de ejecución.
• Solución para evitar fallas durante la ejecución de ciertos métodos.
• Mejoras en la inclusión de paquetes desde la línea de comando.
• Soluciones específicas para plataformas como Android, Windows y Debian.
• Mejoras en la compatibilidad con diferentes versiones de Python y sistemas operativos.

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

¿Como instalar Nuitka en Linux?

Para los interesados en poder instalar Nuitka en su sistema, deben saber que la instalación es sencilla, solo deben contar con Python instalado y el sistema de gestión de paquetes pip.

Para instar Nuitka basta con ejecutar el siguiente comando:

pip install nuitka

En cuanto al uso de este compilador, pueden consultar el manual de usuario en el siguiente enlace.

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