> Network traffic between nodes is not encrypted and not authenticated.
Oh.
After all of the work they put into using cryptographic identities and decentralization tricks, how did they forget to do anything about the network traffic?
Was this a case of thinking they'd handle it later, but then it fell off the TODO list?
Reading the blog, it sounds more like they were depending on libraries (both by Cyphernet, interestingly) and implicitly trusting them, instead of verifying.
Which I can understand to an extent with large, high-traffic dependencies but these were really low traffic projects with like 10 stars on github and barely any development... Well, hindsight is 20/20.
The fact that this was reported three months ago and the "workaround" is to stop using private repos and assume they are all pwnd is quite something. How do you not notice that cross-node traffic is not encrypted when building something like this?
>This was reported to us by Konstantinos Maninakis on 2026-06-24.
announcement 3 months later is not super great, considering that the current advice is "Stop using private repositories (over the network) until the security update is released."
This whole project reads like amateur hour. Still using curl pipe to shell install and everything. Plus this lax security disclosure with just an outstandingly foolish security flaw. Gross.
It's a team of 3. It's not like they have a security team, dedicated testers. They were for very long released beta software. That in fact already worked.
My main wish is if radicle had a way to make issues online, without installing the software. Runing a piece of software is a high barrier of entry to make a bug report, which the entire reason I use codeberg instead.
That's a downside of all decentralised software, isn't it? If there's a convenient access point, that access point is also a point of centralisation. To be distributed, you have to be running the software yourself. The big problem is that the software always ends up being inconvenient. People have no problem using bittorrent because the software is actually usable.
> Peer authentication in the connection handshake is broken and allows impersonation. An attacker can connect to your node and present a Node ID that is not its own. Private repositories are shared only with allow-listed Node IDs. An attacker who fakes an allow-listed Node ID can fetch a private repository directly, without being on the network path. This was reported to us by cryptocode on 2026-08-12. We proposed a fix upstream, see this pull request.
They are trying to sweet write it as much as possible. But basically there is neither encryption nor authentication. The person who made the protocol/program simply didn't care.
I find this to be very telling about what kind of people they are. If you make a mistake this big you need to own up to it. BS all you want, maybe you think that works for you.. but people see through it.
Honestly issues like this crop up pretty commonly. JWT alg:none for example. Or even older people forcing SSL to downgrade to encryption null.
In any system that provides security it should only be designed to run if the security is in use, and to fail immediately with no further action if the security is not used.
Is there a risk that other projects that may be using the same cyphernet-labs/netservices.rs code, like Nym & Farcaster, have also been expecting authentication & encryption where it hasn't been happening?
> Network traffic between nodes is not encrypted and not authenticated.
Oh.
After all of the work they put into using cryptographic identities and decentralization tricks, how did they forget to do anything about the network traffic?
Was this a case of thinking they'd handle it later, but then it fell off the TODO list?
Which I can understand to an extent with large, high-traffic dependencies but these were really low traffic projects with like 10 stars on github and barely any development... Well, hindsight is 20/20.
announcement 3 months later is not super great, considering that the current advice is "Stop using private repositories (over the network) until the security update is released."
FAQ still says that "Radicle supports private repositories [...] completely invisible to the rest of the network" [1]
[0] https://radicle.dev/guides/user#initializing-a-private-repos...
[1] https://radicle.dev/faq
Me: "No!"
https://github.com/radicle-dev
> Peer authentication in the connection handshake is broken and allows impersonation. An attacker can connect to your node and present a Node ID that is not its own. Private repositories are shared only with allow-listed Node IDs. An attacker who fakes an allow-listed Node ID can fetch a private repository directly, without being on the network path. This was reported to us by cryptocode on 2026-08-12. We proposed a fix upstream, see this pull request.
They are trying to sweet write it as much as possible. But basically there is neither encryption nor authentication. The person who made the protocol/program simply didn't care.
In any system that provides security it should only be designed to run if the security is in use, and to fail immediately with no further action if the security is not used.
https://radicale.org/v3.html