Radicle la alternativa open source P2P a GitHub

Radicle

Radicle el GitHub p2p

Actualmente existen una gran cantidad de alternativas a GitHub, desde alternativas de código abierto, otras que son propias de algunos proyectos (es decir privadas), otras que son públicas, pero dejan mucho que desear, entre otras tantas.

Pero el escuchar una alternativa P2P a GitHub, si es algo de lo que no se sabe todos los días y es que navegando por la red me encontré con Radicle, el cual se presenta como una red de colaboración de código descentralizada, basada en la familiaridad de GitHub y GitLab como repositorios centralizados para la colaboración de código.

Sobre Radicle

Radicle aprovecha todas las características del sistema de control de versiones de Git y agrega descentralización, al mismo tiempo que integra una serie de características de identidad Web3 y como en su web se menciona » diferencia de las plataformas de alojamiento de código centralizado, no existe una entidad única que controle la red. Los repositorios se replican entre pares de manera descentralizada y los usuarios tienen control total de sus datos y flujo de trabajo.

En Radicle puedes iniciar un proyecto Radicle clonando algo almacenado en un repositorio de Git. Si ya estás usando Git pero quieres alejarte de uno de los repositorios centralizados, la experiencia de incorporación es bastante fluida. La interfaz de línea de comando será familiar para ti. Una diferencia clave es que no hay un único maestro inmutable en el que se fusionen los contribuyentes: cada par mantiene una versión ramificada del proyecto con los cambios que le interesa mantener.

El protocolo de red Radicle se centra en localizar, replicar y verificar repositorios en una red de alojamiento de código P2P. Su enfoque descentralizado garantiza el acceso a los repositorios, independientemente de su ubicación o número de réplicas. Utiliza un protocolo de chismes para el intercambio de metadatos entre nodos, facilitando el descubrimiento y la replicación del repositorio.

La arquitectura de Radicle es local primero , lo que garantiza el acceso continuo a los repositorios directamente desde su dispositivo, independientemente de la conectividad a Internet. Los repositorios tienen identificadores únicos y se autocertifican, lo que significa que todas las acciones, desde confirmar el código hasta agregar un comentario a un problema, se realizan localmente y están firmadas criptográficamente , lo que permite a los pares verificar la autenticidad y la procedencia de los datos una vez propagados a la red. Esto permite establecer confianza sin depender de una autoridad centralizada.

La mayoría de los proyectos de código abierto suelen estar alojados en GitHub u otras alternativas como GitLab, aunque ofrecen muchos beneficios, también tienen desventajas, como la pérdida de control y privacidad, como se vio en el caso de la eliminación del proyecto youtube-dl en GitHub. Radicle ofrece un enfoque descentralizado que garantiza el acceso a los repositorios sin importar su ubicación o número de réplicas.

Radicle funciona como un protocolo peer-to-peer donde cada usuario ejecuta un software idéntico, conocido como Radicle Stack. Este stack incluye una interfaz de línea de comandos y un servicio en red llamado Radicle Node, que intercambia datos a través de un protocolo de chismes para formar una red resistente.

Entre las características clave de Radicle que se destacan, podremos encontrar las siguientes:

  • Capacidad para agregar múltiples pares remotos y administrarlos.
  • Funcionalidad para seguir un proyecto de un par específico.
  • No depende de servidores centrales, lo que evita la censura.
  • Interconexión con otros pares en una red resistente y tolerante a las interrupciones.
  • Capacidad para trabajar sin conexión y gestionar problemas locales y soluciones.
  • Integrado con Git para una experiencia de desarrollo simple y cómoda.
  • Posibilidad de recibir financiación mediante Ethereum y gestionar bases de código conjuntas.

Radicle está diseñado para ser una plataforma extensible que permite diversos casos de uso sin necesidad de modificaciones a nivel de protocolo. Aunque la versión inicial de Radicle se centra en la colaboración y publicación de código, se prevé una variedad de otras aplicaciones en el futuro y posibles hoy. Estos incluyen el intercambio de conocimientos, la coordinación de proyectos y la colaboración en conjuntos de datos, lo que amplía significativamente el alcance y la utilidad de la plataforma más allá de la gestión de código.

¿Como instalar Radicle en Linux?

Para los que estén interesados en utilizar Radicle, deben saber que existen diferentes métodos para instalarlo en Linux y uno de ellos es instalarlo en ejecutando lo siguiente:

curl -sSf https://radicle.xyz/install | sh

A ahora para quienes son usuarios de una distro Debian, Ubuntu o alguna derivada de estas, pueden realizar la instalacion tecleando:

sudo apt install curl
curl https://europe-west6-apt.pkg.dev/doc/repo-signing-key.gpg | sudo apt-key add -
echo deb https://europe-west6-apt.pkg.dev/projects/radicle-services radicle-cli main | sudo tee -a /etc/apt/sources.list.d/radicle-registry.list
sudo apt update
sudo apt install radicle-cli

Para conocer mas sobre el funcionamiento de Radicle, puedes consultar el siguiente enlace.

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

Nova, el nuevo controlador escrito en Rust de Red Hat para GPUs NVIDIA

Nova

Nova un nuevo controlador del kernel Direct Rendering Manager (DRM) escrito en Rust

Desde que Nvidia libero sus módulos de kernel GPU como código abierto, parecía que tanto el controlador propietario de Nvidia como el controlador de código abierto Nouveau tendrían grandes mejoras con los aportes que podría realizar la comunidad e incluso que el algún momento Nouveau podría estar a la altura.

Después de varios meses y de que el desarrollo de Nouveau se llegara ralentizar, Red Hat ha tomado cartas en el asunto y hace poco dio a conocer la noticia de que se encuentra trabajando en el proyecto Nova, el cual presenta como un nuevo controlador abierto para GPU NVIDIA el cual está siendo desarrollado en Rust.

Este controlador incluye operaciones de inicialización y control de la GPU en el firmware, utilizando un microcontrolador GSP independiente. Nova está diseñado como un módulo para el kernel de Linux y utiliza el subsistema DRM (Direct Rendering Manager). Este proyecto se considera una continuación del desarrollo del controlador Nouveau para GPU con firmware GSP.

Danilo Krummrich (Red Hat) explica:

Con Nova tenemos la oportunidad de reducir significativamente la complejidad en comparación con Nouveau, por dos razones principales. En primer lugar, la arquitectura histórica de Nouveau, especialmente en torno a nvif/nvkm, es bastante complicada e inflexible y requiere una revisión importante para resolver algunos problemas. A continuación, también queremos aprovechar la oportunidad para contribuir a los esfuerzos de Rust en el kernel y beneficiarnos de la mayor seguridad de la memoria que ofrece el lenguaje de programación Rust.

Además de ello, se menciona que con el desarrollo de Nova, Red Hat pretende aprovechar la oportunidad para contribuir a los esfuerzos de Rust en el kernel, ya que como se mencionó el código del controlador está escrito en Rust y utiliza varias capas para desarrollar controladores de video en este lenguaje. Por ejemplo, el controlador utiliza abstracciones de la rama Rust-Device para crear controladores, componentes de la rama Rust-Pci para trabajar con el bus PCI, y enlaces para los subsistemas DRM y GEM de la rama Rust-DRM.

También se menciona el desarrollo del controlador drm-asahi Rust para GPU de chips Apple M1 y M2. El uso de Rust se espera que aumente la seguridad y confiabilidad del controlador al reducir la probabilidad de errores al trabajar con la memoria y permitir la combinación del trabajo en el controlador de video con el desarrollo de componentes comunes en Rust.

El objetivo de Nova es convertirse eventualmente en un controlador de código abierto para NVIDIA Linux, dirigido a las GPU Turing y modelos más recientes (especialmente en la serie RTX 2000) que admitan GSP. Este nuevo controlador está siendo desarrollado en Rust para lograr una mayor ligereza y flexibilidad, lo cual se presenta como una opción prometedora.

Una de las razones para crear un nuevo controlador es simplificar el proceso en comparación con Nouveau, gracias al uso de controladores listos para usar proporcionados por el firmware GSP. Esto evita la complejidad innecesaria en el código del controlador Nouveau, que necesita soportar GPU NVIDIA más antiguas y presenta problemas como bloqueos en el código VMM/MMU. Al desarrollar Nova desde cero y enfocarse solo en GPU basadas en GSP, se espera evitar estos problemas y complicaciones.

Por otra parte, Red Hat también menciona algunos de los puntos que debe abordar, ya que dice que con la elección de Rust, el primer problema a resolver es la falta de abstracciones de enlace de C para infraestructura integral del kernel:

«por ejemplo, abstracciones de dispositivo/controlador … necesitamos un usuario para las abstracciones en sentido ascendente, pero también necesitamos las abstracciones para crear un controlador: queremos desarrollar Nova en sentido ascendente y comenzar con solo un código auxiliar que solo haga uso de algunas abstracciones básicas de Rust.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace, asi como también consultar el desarrollo y consultar el código fuente de este en su repositorio.

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

Recent ‘MFA Bombing’ Attacks Targeting Apple Users

Several Apple customers recently reported being targeted in elaborate phishing attacks that involve what appears to be a bug in Apple’s password reset feature. In this scenario, a target’s Apple devices are forced to display dozens of system-level prompts that prevent the devices from being used until the recipient responds “Allow” or “Don’t Allow” to each prompt. Assuming the user manages not to fat-finger the wrong button on the umpteenth password reset request, the scammers will then call the victim while spoofing Apple support in the caller ID, saying the user’s account is under attack and that Apple support needs to “verify” a one-time code.

Some of the many notifications Patel says he received from Apple all at once.

Parth Patel is an entrepreneur who is trying to build a startup in the cryptocurrency space. On March 23, Patel documented on Twitter/X a recent phishing campaign targeting him that involved what’s known as a “push bombing” or “MFA fatigue” attack, wherein the phishers abuse a feature or weakness of a multi-factor authentication (MFA) system in a way that inundates the target’s device(s) with alerts to approve a password change or login.

“All of my devices started blowing up, my watch, laptop and phone,” Patel told KrebsOnSecurity. “It was like this system notification from Apple to approve [a reset of the account password], but I couldn’t do anything else with my phone. I had to go through and decline like 100-plus notifications.”

Some people confronted with such a deluge may eventually click “Allow” to the incessant password reset prompts — just so they can use their phone again. Others may inadvertently approve one of these prompts, which will also appear on a user’s Apple watch if they have one.

But the attackers in this campaign had an ace up their sleeves: Patel said after denying all of the password reset prompts from Apple, he received a call on his iPhone that said it was from Apple Support (the number displayed was 1-800-275-2273, Apple’s real customer support line).

“I pick up the phone and I’m super suspicious,” Patel recalled. “So I ask them if they can verify some information about me, and after hearing some aggressive typing on his end he gives me all this information about me and it’s totally accurate.”

All of it, that is, except his real name. Patel said when he asked the fake Apple support rep to validate the name they had on file for the Apple account, the caller gave a name that was not his but rather one that Patel has only seen in background reports about him that are for sale at a people-search website called PeopleDataLabs.

Patel said he has worked fairly hard to remove his information from multiple people-search websites, and he found PeopleDataLabs uniquely and consistently listed this inaccurate name as an alias on his consumer profile.

“For some reason, PeopleDataLabs has three profiles that come up when you search for my info, and two of them are mine but one is an elementary school teacher from the midwest,” Patel said. “I asked them to verify my name and they said Anthony.”

Patel said the goal of the voice phishers is to trigger an Apple ID reset code to be sent to the user’s device, which is a text message that includes a one-time password. If the user supplies that one-time code, the attackers can then reset the password on the account and lock the user out. They can also then remotely wipe all of the user’s Apple devices.

THE PHONE NUMBER IS KEY

Chris is a cryptocurrency hedge fund owner who asked that only his first name be used so as not to paint a bigger target on himself. Chris told KrebsOnSecurity he experienced a remarkably similar phishing attempt in late February.

“The first alert I got I hit ‘Don’t Allow’, but then right after that I got like 30 more notifications in a row,” Chris said. “I figured maybe I sat on my phone weird, or was accidentally pushing some button that was causing these, and so I just denied them all.”

Chris says the attackers persisted hitting his devices with the reset notifications for several days after that, and at one point he received a call on his iPhone that said it was from Apple support.

“I said I would call them back and hung up,” Chris said, demonstrating the proper response to such unbidden solicitations. “When I called back to the real Apple, they couldn’t say whether anyone had been in a support call with me just then. They just said Apple states very clearly that it will never initiate outbound calls to customers — unless the customer requests to be contacted.”

Massively freaking out that someone was trying to hijack his digital life, Chris said he changed his passwords and then went to an Apple store and bought a new iPhone. From there, he created a new Apple iCloud account using a brand new email address.

Chris said he then proceeded to get even more system alerts on his new iPhone and iCloud account — all the while still sitting at the local Apple Genius Bar.

Chris told KrebsOnSecurity his Genius Bar tech was mystified about the source of the alerts, but Chris said he suspects that whatever the phishers are abusing to rapidly generate these Apple system alerts requires knowing the phone number on file for the target’s Apple account. After all, that was the only aspect of Chris’s new iPhone and iCloud account that hadn’t changed.

WATCH OUT!

“Ken” is a security industry veteran who spoke on condition of anonymity. Ken said he first began receiving these unsolicited system alerts on his Apple devices earlier this year, but that he has not received any phony Apple support calls as others have reported.

“This recently happened to me in the middle of the night at 12:30 a.m.,” Ken said. “And even though I have my Apple watch set to remain quiet during the time I’m usually sleeping at night, it woke me up with one of these alerts. Thank god I didn’t press ‘Allow,’ which was the first option shown on my watch. I had to scroll watch the wheel to see and press the ‘Don’t Allow’ button.”

Ken shared this photo he took of an alert on his watch that woke him up at 12:30 a.m. Ken said he had to scroll on the watch face to see the “Don’t Allow” button.

Unnerved by the idea that he could have rolled over on his watch while sleeping and allowed criminals to take over his Apple account, Ken said he contacted the real Apple support and was eventually escalated to a senior Apple engineer. The engineer assured Ken that turning on an Apple Recovery Key for his account would stop the notifications once and for all.

A recovery key is an optional security feature that Apple says “helps improve the security of your Apple ID account.” It is a randomly generated 28-character code, and when you enable a recovery key it is supposed to disable Apple’s standard account recovery process. The thing is, enabling it is not a simple process, and if you ever lose that code in addition to all of your Apple devices you will be permanently locked out.

Ken said he enabled a recovery key for his account as instructed, but that it hasn’t stopped the unbidden system alerts from appearing on all of his devices every few days.

KrebsOnSecurity tested Ken’s experience, and can confirm that enabling a recovery key does nothing to stop a password reset prompt from being sent to associated Apple devices. Visiting Apple’s “forgot password” page — https://ift.tt/mNID8Yl — asks for an email address and for the visitor to solve a CAPTCHA.

After that, the page will display the last two digits of the phone number tied to the Apple account. Filling in the missing digits and hitting submit on that form will send a system alert, whether or not the user has enabled an Apple Recovery Key.

The password reset page at iforgot.apple.com.

RATE LIMITS

What sanely designed authentication system would send dozens of requests for a password change in the span of a few moments, when the first requests haven’t even been acted on by the user? Could this be the result of a bug in Apple’s systems?

Apple has not yet responded to requests for comment.

Throughout 2022, a criminal hacking group known as LAPSUS$ used MFA bombing to great effect in intrusions at Cisco, Microsoft and Uber. In response, Microsoft began enforcing “MFA number matching,” a feature that displays a series of numbers to a user attempting to log in with their credentials. These numbers must then be entered into the account owner’s Microsoft authenticator app on their mobile device to verify they are logging into the account.

Kishan Bagaria is a hobbyist security researcher and engineer who founded the website texts.com (now owned by Automattic), and he’s convinced Apple has a problem on its end. In August 2019, Bagaria reported to Apple a bug that allowed an exploit he dubbed “AirDoS” because it could be used to let an attacker infinitely spam all nearby iOS devices with a system-level prompt to share a file via AirDrop — a file-sharing capability built into Apple products.

Apple fixed that bug nearly four months later in December 2019, thanking Bagaria in the associated security bulletin. Bagaria said Apple’s fix for that bug was to add stricter rate limiting on AirDrop requests, and he suspects that someone has figured out a way to bypass Apple’s rate limit on how many of these password reset requests can be sent in a given timeframe.

“I think this could be a legit Apple rate limit bug that should be reported,” Bagaria said.

from Krebs on Security https://ift.tt/whLeAo6
via IFTTT

RFDS, una vulnerabilidad que afecta a procesadores Intel E-core

vulnerabilidad

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

Intel dio a conocer hace poco, la noticia de que detecto una vulnerabilidad de microarquitectura (catalogada bajo CVE-2023-28746) en los procesadores Intel Atom (E-core), conocida como RFDS (Register File Data Sampling) y el peligro de esta vulnerabilidad radica en que permite determinar los datos utilizados por un proceso que se ejecutaba previamente en el mismo núcleo de la CPU.

RFDS es una vulnerabilidad que comparte similitudes con ataques de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), se diferencia en su método de exposición y los datos expuestos, limitándose a datos de registros obsoletos.

Sobre la vulnerabilidad

La identificación de «RFDS» fue realizada por ingenieros de Intel durante una auditoría interna, aunque no se ha proporcionado información detallada sobre el método de explotación de la misma, los ingenieros de Intel han señalado que el atacante no puede controlar intencionalmente la selección de procesos para la extracción de datos, lo que implica que la exposición de información disponible para su recuperación es aleatoria. Sin embargo, la explotación de RFDS por parte de un actor malicioso que pueda ejecutar código localmente en un sistema podría conducir a la inferencia de valores de datos secretos previamente utilizados en registros, potencialmente comprometiendo la seguridad y confidencialidad de la información.

RFDS se descubrió como parte del extenso trabajo de validación interna de Intel sobre seguridad de microarquitectura. De manera similar a los ataques de ejecución transitoria de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), RFDS puede permitir que un actor malicioso que puede ejecutar código localmente en un sistema infiera los valores de datos secretos que de otro modo estarían protegidos por mecanismos arquitectónicos. RFDS difiere de las vulnerabilidades de MDS tanto en el método de exposición como en los datos expuestos (RFDS expone únicamente datos de registros obsoletos). Ni MDS ni RFDS, por sí solos, brindan a los actores maliciosos la capacidad de elegir qué datos se infieren utilizando estos métodos.

Se menciona que estas fugas afectan a los registros vectoriales utilizados en cifrado, funciones de copia de memoria y procesamiento de cadenas, como en las funciones memcpy, strcmp y strlen. También es posible la fuga a través de registros para almacenar números de punto flotante y enteros, aunque se actualizan con más frecuencia durante la ejecución de tareas, lo que reduce la probabilidad de fugas a través de ellos. Es importante destacar que los datos residuales no permanecen directamente en los registros, sino que se pueden extraer de los archivos de registro mediante técnicas de ataque de canal lateral, como la extracción de datos en la memoria caché de la CPU.

RFDS afecta exclusivamente a los procesadores Atom basados en las microarquitecturas Alder Lake, Raptor Lake, Tremont, Goldmont y Gracemont. Estos procesadores no admiten el modo HyperThreading, lo que limita la fuga de datos a un subproceso de ejecución dentro del núcleo de la CPU actual. Los cambios para abordar esta vulnerabilidad están incluidos en la actualización del microcódigo microcode-20240312-staging.

Los métodos de protección contra esta vulnerabilidad son similares a los utilizados para bloquear ataques previamente identificados, como MDS, SRBDS, TAA, DRPW (Device Register Partial Write), y ataques SBDS (Shared Buffer Data Sampling).

Para protegerse contra las fugas en el kernel y los hipervisores, además de actualizar el microcódigo, es necesario utilizar métodos de protección de software que involucran el uso de la instrucción VERW para borrar el contenido de los buffers de microarquitectura al regresar del kernel al espacio de usuario o al transferir el control al sistema de invitados. Esta protección ya ha sido implementada en el hipervisor Xen y el kernel de Linux.

Para habilitar la protección en el kernel de Linux, se puede utilizar el indicador «reg_file_data_sampling=on» al cargar el kernel. La información sobre la vulnerabilidad y la presencia del microcódigo necesario para la protección se puede evaluar en el archivo «/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling«.

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