No offense, but how can you build a protocol that accidentally does not encrypt stuff at all? Don’t you at some point look at the wires? Re-implement the protocol as a different clients - for tests?
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…
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…
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 caught this with a simple tcpdump. But we’re all humans and make mistakes. I, too, naively trusted that all of Radicle’s comms were encrypted as described in their documentation. I, too, could have run tcpdump and noticed the obvious.
I would hope that as they work on migrating to iroh, they learn from this and perform testing to ensure encrypted comms. But that migration, as discussed in the disclosure, is a comms-breaking change. The entire Radicle world will need to migrate (at around the same time? I’m not sure.)
I’m having a hard time imagining it being very tough. You break the protocol, and you do it urgently. It sucks in so many ways, but it is in my opinion the only right choice. Instead, the project chose to violate the trust of all the users who have started using it “over the past few months” – which in even generous definitions of “few” is mostly while this vulnerability was known.
Their migration to iroh has been in the works for quite a while now. It’s simply not ready. Rome wasn’t built in a day. This vulnerability has given them all the more motivation to migrate away from Noise towards iroh. They’re now pouring more resources in that direction. And I’m glad they publicly acknowledged the issue, even if their announcement left some questions in my mind.
I’m going to choose to encourage them to learn from this as they migrate to iroh. I’ve provided some constructive feedback to the Radicle development team. I’m hoping to help guide them towards a successful and complete migration. I do also plan to do some traffic analysis between two private nodes as their migration work continues. I should caveat that with the fact that I’m not a cryptographer, so I can only attest to “do things look like a garbled mess on the wire?”
So, they’re working on it. However, we, as members of the community, can only encourage them to move in a certain direction. We cannot impose our own arbitrary timelines on others, especially in open source. The developers are going through a rough time right now, given that this is a pretty junior mistake (I’m in no way trying to diminish the seriousness of the issue–I actually think the cleartext traffic vulnerability might be more serious than initially postured, but I haven’t formalized those thoughts just yet. I might need to develop a PoC, but ENOTIME as it would be pretty complex.)
Anyways, we’re humans. We make mistakes. Lets encourage improvements, and hope the migration to iroh proves fruitful and goes smoothly. (I’m concerned about how migrating to iroh might change how I structure some Tor Onion Service endpoints.) But, if we’re not going to contribute patches, the least we can contribute is encouragement in the right direction.
We cannot impose our own arbitrary timelines on others
perhaps not, but i can impose the expectation that if one is selling it as a service as well, the response would be more than “well it’s really hard so let’s just hang in there”.
six days before the disclosure, this post was put out, actively encouraging people to use radicle for private repositories. obviously you can’t say “actually hold on don’t do this right now” because that would defeat the point of the coordinated disclosure, but you could perhaps not continue to promote something that you know is broken in a severe way that undermines data confidentiality.
those two, i’d say, are concerningly irresponsible beyond a “mistake”.
The radicle.garden service is not run by the Radicle project. That is run by a few members of the wider Radicle community, but not by the Radicle project itself. It’s quite likely that the folks running radicle.garden were as knowledgeable about the issue as I was (read: not at all knowledgeable) when that article was written.
The folks at radicle.garden thus have no bearing on this issue.
No offense, but how can you build a protocol that accidentally does not encrypt stuff at all? Don’t you at some point look at the wires? Re-implement the protocol as a different clients - for tests?
score 2 · canonical
Why did Radicle need 3 months after knowing this fundamental flaw to disclose it?
score 2 · canonical
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…
score 1 · canonical
90days usually also gives you time to fix… here they say:
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…
score 2 · canonical
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 caught this with a simple tcpdump. But we’re all humans and make mistakes. I, too, naively trusted that all of Radicle’s comms were encrypted as described in their documentation. I, too, could have run tcpdump and noticed the obvious.
I would hope that as they work on migrating to
iroh, they learn from this and perform testing to ensure encrypted comms. But that migration, as discussed in the disclosure, is a comms-breaking change. The entire Radicle world will need to migrate (at around the same time? I’m not sure.)score 1 · canonical
I’m having a hard time imagining it being very tough. You break the protocol, and you do it urgently. It sucks in so many ways, but it is in my opinion the only right choice. Instead, the project chose to violate the trust of all the users who have started using it “over the past few months” – which in even generous definitions of “few” is mostly while this vulnerability was known.
score 1 · canonical
Their migration to iroh has been in the works for quite a while now. It’s simply not ready. Rome wasn’t built in a day. This vulnerability has given them all the more motivation to migrate away from Noise towards iroh. They’re now pouring more resources in that direction. And I’m glad they publicly acknowledged the issue, even if their announcement left some questions in my mind.
I’m going to choose to encourage them to learn from this as they migrate to iroh. I’ve provided some constructive feedback to the Radicle development team. I’m hoping to help guide them towards a successful and complete migration. I do also plan to do some traffic analysis between two private nodes as their migration work continues. I should caveat that with the fact that I’m not a cryptographer, so I can only attest to “do things look like a garbled mess on the wire?”
So, they’re working on it. However, we, as members of the community, can only encourage them to move in a certain direction. We cannot impose our own arbitrary timelines on others, especially in open source. The developers are going through a rough time right now, given that this is a pretty junior mistake (I’m in no way trying to diminish the seriousness of the issue–I actually think the cleartext traffic vulnerability might be more serious than initially postured, but I haven’t formalized those thoughts just yet. I might need to develop a PoC, but ENOTIME as it would be pretty complex.)
Anyways, we’re humans. We make mistakes. Lets encourage improvements, and hope the migration to iroh proves fruitful and goes smoothly. (I’m concerned about how migrating to iroh might change how I structure some Tor Onion Service endpoints.) But, if we’re not going to contribute patches, the least we can contribute is encouragement in the right direction.
score 1 · canonical
perhaps not, but i can impose the expectation that if one is selling it as a service as well, the response would be more than “well it’s really hard so let’s just hang in there”.
six days before the disclosure, this post was put out, actively encouraging people to use radicle for private repositories. obviously you can’t say “actually hold on don’t do this right now” because that would defeat the point of the coordinated disclosure, but you could perhaps not continue to promote something that you know is broken in a severe way that undermines data confidentiality.
those two, i’d say, are concerningly irresponsible beyond a “mistake”.
score 2 · canonical
The
radicle.gardenservice is not run by the Radicle project. That is run by a few members of the wider Radicle community, but not by the Radicle project itself. It’s quite likely that the folks runningradicle.gardenwere as knowledgeable about the issue as I was (read: not at all knowledgeable) when that article was written.The folks at
radicle.gardenthus have no bearing on this issue.score 1 · canonical