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.
my position is that people who are part of radicle’s core team run radicle.garden, not the project at large, or even the core team at large. this is based on the following:
radicle was born out of monadic gmbh, an organisation that almost, but not quite, appears a bunch in radicle.garden’s terms of service. the address of monadic works gmbh there happens to be the address of monadic gmbh as well, and it doesn’t look like it’s a mail clearinghouse. both are registered in the charlottenburg borough of berlin, which isn’t a particularly big place by the looks of it, and i couldn’t find anyone claiming that it’s germany’s delaware. they also share a director, who was one of the two named creators of radicle.
it’s entirely possible that these are just a couple of overlapping coincidences and my thinking cap is on a bit too tight here, but so far this math seems to do well.
i lost a solid 90 minutes of prime stardew valley time digging into this, partly because germany’s business register appeared to take a nap right as i got into gear.
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
my position is that people who are part of radicle’s core team run
radicle.garden, not the project at large, or even the core team at large. this is based on the following:it’s entirely possible that these are just a couple of overlapping coincidences and my thinking cap is on a bit too tight here, but so far this math seems to do well.
i lost a solid 90 minutes of prime stardew valley time digging into this, partly because germany’s business register appeared to take a nap right as i got into gear.
score 4 · canonical