How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
> 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?
>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."
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?
Radicle has been one of those projects that had seemed interesting, but something always bothered me about it. (I think it was very highly tied to the cryptocurrency movement for a while? And the Cyphernet GitHub org seems to have rebranded from a DAO?)
This, unfortunately, kinda seals the deal on never using this thing, at least not for anything I intend to keep private. This isn't about proficiency in some protocol which has XYZ footgun: they never checked that payloads were encrypted. Ridiculous.
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 releasing beta software. That in fact already worked.
Oh, so when they advertise “Your Data, Forever and Secure”[1] in big bold letters on their homepage with total disregard for the truth of that statement they are just committing fraud. Got it.
What's the alternative though? A .deb you download over the same HTTPS and install as root has the same trust model. Unless it's signed and you verified the key out-of-band, how is curl | sh meaningfully worse than the package?
It should appear as encrypted iroh traffic. Depending on how radicle handles things, this could make it difficult to identify versus other applications using iroh. If needed, they could add noise or dummy traffic in the future for further obfuscation.
They may be overselling, but I’ve had good experiences using apps built on it.
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.
> If there's a convenient access point, that access point is also a point of centralisation
I don't think that's true. Bitcoin and Ethereum are very decentralized but most casual users don't run a node and do everything with a gateway. ATProto/Bluesky is the same.
What they have in common is shared global state, using a blockchain or PLC. That means everyone gets a full view of the network (outside of censoring relays) and user account are portable. You can go with a commercial provider for convenience but always have the option of self hosting if they raise prices or censor you.
That option is more important than the share or users who self host right now.
That only helps if they actually take issues there. We hit this with a project on a self-hosted forge: we mirrored it to GitHub, left issues enabled, and copied the important ones back by hand. Check whether radicle-dev does that first.
My main wish is a way to search the repositories on a node. Or a way to have tags. The whole network is like a blackbox of projects unless you can get an outside link.
> The network protocol used by Radicle does not give the confidentiality it was expected to give. Anyone who can observe the network path between two nodes can read the data they exchange as the data is sent in plain text.
Is this a... design choice? This feels like too egregious of an omission to be a regular vulnerability here.
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?
> 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.
I was very surprised when I realized what defaults postgres uses when it comes to SSL. I can see how people consider it a pragmatic choice - but still...
Just use mTLS via QUIC, it’s standardized, secure, future proof and has implementations in tons of languages and supports proper certificate checks and that whole ecosystem around it which they apparently tried to reinvent. It’s such a great protocol for these use cases, I don’t get why it’s not used more.
I don't see how mTLS would work for Radicle or other decentralized systems because, as far as I understand, both parties need to have their certificates signed by a shared root.
You don't need a shared root. With rustls you can write a custom cert verifier that pins the peer's public key, SSH-style. I did this with quinn and it works fine. Gotcha: the verifier is on you, and getting it wrong is its own vulnerability.
I don't think the consumer ecosystem is mature yet.
Adding a cert to my Android phone was a huge pain in the ass. Most homelab apps like Jellyfin don't support it. The homelab space is so buck broken it assumes i don't have a public IP address to just expose things without going through the convoluted VPN setup.
One letter apart is close enough. Someone will typo it in an apt install or a config management run, and then you're debugging why a CalDAV server showed up on a box at 3am. Naming collisions always end up as tickets.
Nitpick: "not encrypted" and "not authenticated" are separate failures. IIRC Radicle signs the repo data itself, so public repos are probably still tamper-evident, and it's mainly private repo confidentiality that's gone. Still, sitting on this for three months is hard to defend.
> 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?