Mixed assessmentCautious credit for transparency, skepticism about recovery
4 Today 1:43 PM · 9h ago · 14 comments · 1 source · development 4 of 4
While some commenters acknowledged Radicle's decision to disclose before releasing a fix as commendable, others questioned the project's viability. One commenter called the situation 'death' for private repository use. A separate technical analysis showed session keys were established but never used for encryption.
“Well, they at least get some kudos for *admitting* it.”
retr0idRadicle Decentralized git hosting platformKonstantinos Maninakis Security researcher
The whole story articlespostscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 22 voices · verbatim
-
I was wondering how you get from "custom protocol using Noise" to "network traffic between nodes is not encrypted". Turns out it's fairly simple: they didn't encrypt anything after the initial handshake.
-
N
this is, indeed, radical https:// radicle.dev/2026/09/23/disclos ure-of-vulnerability-in-network-protocol.html
-
Well, they at least get some kudos for *admitting* it.
-
Holy poop. Reading the article I thought it was a flaw in the encryption or key exchange or something, such that traffic was “encrypted but not really.” Like you could trivially derive the session keys or something but the traffic was protected against casual inspection. Now reading the bug reports it would appear that, no, the session keys…
-
But…I mean. You write a custom wire protocol and don’t once in 3+ years look at a pcap? It’s just really weird to me.
-
I think they mean a focus on redundancy and resilience (so availability in the CIA-trifecta sense)
-
I keep seeing [Iroh](https://iroh.computer/) show up in re-decentralising projects. (e.g. Delta Chat, Radicle. I guess it's time to learn how its protocol is different than tailscale, libp2p, ipfs, cjdns, yggdrasil, and all the wormhole variants.
-
Wow, this is hella disturbing! Didn't they rewrite the protocol 3 times *from scratch*? And now they: - apparently have *no versioning*?? ("Due to a lack of version negotiation features") - No encryption?? A real bummer! From a high-level architectural view I still believe Radicle would be the best (F)OSS Github alternative (given the focus on…
-
> I still believe Radicle would be the best (F)OSS Github alternative (given the focus on source availability which lacks in all alternatives) That is a very bizarre thing to say given the (at least) 3 other forge implementations that I know of with FLOSS licenses
-
admitting that there's a fundamental security issue with your software that can't be fixed in near future is... probably one of the worst possible results of a vuln disclosure
-
Overall, i feel like it may be important to recognize the value of the tool that they are building while also acknowledging the serious security flaws presented here. Echoing, one of the other commenters at the end of the day, we are all humans, and we're going to make mistakes. Personally I think this is one of those mistakes that really isn't…
-
90days usually also gives you time to fix… here they say: > Which versions are affected? > > All versions of Radicle that were released to date are vulnerable. Between the time of the initial report and now, there were several releases. So in addition of being really bad, it seems like low priority for them to fix…
-
90 days is a normal disclosure timeline. Theoretically it gives them time to investigate, confirm, etc, and let high-profile users know about the issue privately. Though in this case I can’t imagine confirmation took too long…
-
True. In a world of limited (if any) responsibility by virtually everybody who is in a position of power, at least someone took the time to release this statement _before_ releasing the fix. That's uncommon.
-
Interesting. I only had a very superficial look at it in the past, but my first impressions were positive - so this news was all the more surprising to me.
-
> This was reported to us by Konstantinos Maninakis on 2026-06-24. Why did Radicle need 3 months after knowing this fundamental flaw to disclose it?
-
Whenever I've built anything with its own wire protocol, I've looked at it in Wireshark at some point...
-
It's tough with this requiring a fix that breaks the existing on-wire communications protocol. The Radicle network has grown pretty substantially over the past few months, so it takes a bit of juggling to get all the right pieces in all the right places for all the right people. I do think during early development, it would have been good to have…
-
To answer the questions in "EDIT": Yes, we should definitely fix the website with regards to mentions of private repos until there is a fix. I agree on the "not fit for purpose" comment there. However, please consider the perspective of public repositories as well. In My Humble Opinion (IMHO), that is where the peer-to-peer architecture (that…
-
Did they bother to put this on the socials? I am pretty certain I did not see this on mastodon. I think I only saw it because their zulip sent out a mail. I doubt that zulip has more users than the socials they announce on the web page.
-
It looks like they were using a dependency to deal with the Noise stuff, trusting that it did the right thing... but it didn't.
-
It sounds like they used a Noise library, and I guess git packfiles (or whatnot) are hard to distinguish from noise by eye?
All 4 developments of Radicle discloses critical network protocol vulnerabilities… →
LobstersHacker NewsNewswiresMastodon