I proposed this project to improve on Radicle’s p2p model by using Tor for universal, straightforward seeding of git repos.
Original discussion thread - https://bounties.monero.social/posts/207/
One of the project’s git repos linked in that thread - https://radicle.network/nodes/iris.radicle.network/rad:z2ydYmUCJvDfNFTVTpEbQmm55EPt1/history
Project website - https://cradicle.xyz/
The dev who took the project also expanded it into a project to reimplement Radicle in C.
Since I’m not a coder and I don’t have any git repos of my own, I can only test from the viewpoint of an average layman using the GUI app to seed repos.
It’s impossible for me to properly gauge how the project is progressing without engagement from coders who try using it for their git repos.
If the project doesn’t currently interest you, your suggestions on how to start getting users on board would also be welcome.
Edit - bear in mind that because decentralized discussion platforms like this are currently quite broken, there are comments showing up in the thread when I’m not signed in that don’t show up for me when I’m signed in. Here’s a screenshot of all the comments showing up for me right now where I’m signed in and able to reply, as of UNIX time 1779670288
I’d encourage discussion of this project moreso on nostr (equally broken but my preferred platform) or the discussion thread linked above (seemingly more functional)
So I gave the actual code a one minute look (literally).
Picked
src/radicle/util.c, since that was the last file touched.The level of defensive programming doesn’t look that good (and I’m trying to be nice here).
Here is an example, and note that I didn’t do C in a while:
#include <stdio.h> #include <string.h> void rad_rstrip_nl(char* str) { int len_str = strlen(str); if (str[len_str-1]=='\n') { str[len_str-1] = 0; } } bool rad_get_input (char* str, size_t bufsiz) { if (!fgets(str,bufsiz,stdin)) return false; rad_rstrip_nl(str); return true; } int main() { char a[] = {0,0,0,0}; bool i = rad_get_input(a, 4); printf("%lu\n", strlen(a)); rad_rstrip_nl(a); return i; }The two functions above
main()are copy-pasted from that file.Let’s zoom in:
int len_str = strlen(str); if (str[len_str-1]=='\n') {Here we’re accessing
str[len_str-1]without checkinglen_strfirst.But you might be thinking, maybe
len_strcan’t be zero!Let’s compile first with the AddressSanitizer enabled:
# compile % gcc -Wall -fsanitize=address t.c -o tNow let’s see how easily we can have fun:
% echo -n '\0' | ./t ================================================================= ==2949689==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ba827af001f at pc 0x56032434d259 bp 0x7fff1d199010 sp 0x7fff1d199000 READ of size 1 at 0x7ba827af001f thread T0 #0 0x56032434d258 in rad_rstrip_nl (/tmp/t+0x1258) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51) #1 0x56032434d311 in rad_get_input (/tmp/t+0x1311) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51) #2 0x56032434d3e4 in main (/tmp/t+0x13e4) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51) #3 0x7fa82a227740 (/usr/lib/libc.so.6+0x27740) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049) #4 0x7fa82a227878 in __libc_start_main (/usr/lib/libc.so.6+0x27878) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049) #5 0x56032434d124 in _start (/tmp/t+0x1124) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)(The rest of
AddressSanitizeroutput omitted.)Another function from the same file:
char* rad_strcpy (char* out, const char* inp, int from, int len) { const char* inp_shifted = inp+from; int len_inp_shifted = strlen(inp_shifted); if (len <= len_inp_shifted) { memcpy(out,inp,len); out[len] = 0; } else { memcpy(out,inp,len_inp_shifted); out[len_inp_shifted] = 0; } return out; }Here,
inpis shifted beforeinplength is checked, which doesn’t look safe. But my one minute is up, so I didn’t dive into the function callers.Pretending C is a good choice in 2026, then not being extra vigilant with defensive programming, is not a good look. I remember myself being more vigilant in my wrappers even when I was a beginner.
This is made worse by the developer repeating literal memes like:
Maybe such an enlightened developer should know that you can bootstrap
rustcfrommrustcusing GCC.They are probably also referring to this: https://kerkour.com/rust-supply-chain-nightmare
Cargo and crates are basically just as bad as npm, just less popular, which is why they haven’t been hit yet… And it’s currently very difficult to build rust programs without cargo.
Stable linux distributions have extremely strong supply chain security in comparison to language specific package managers. Debian, for example, was not affected by the xz utils backdoor, due to it’s policy of only doing cherry picked security patches, and ignoring feature or bugfixes for the most part. Given the:
That’s probably what the author was going for. Unfortunately I am too lazy to load up tor browser right now, to check the Debian installation instructions. I suspect they have their own repo with signed keys, just like Radicle does.
Of course, C is still questionable. I would prefer Java if you cared strongly about supply chain security, since its a memory safe language with a mature ecosystem, and many packages available from Debian’s repositories. But, it would be slower than C.
Weird how this random thread came back to life, just to rehash some talking points.
See my comments here and here.
If you followed the link, you would have seen that nothing actually fishy was found, unlike the implication.
The number of actual supply chain attacks actually effecting anybody in the
crates.ioecosystem is ZERO. In npm, it’s a weekly occurrence.Rust cleared the critical mass and critical relevance milestone years ago. Most people can run desktops without npm or local js code. This is increasingly unfeasible for rust components. And yet, nothing happened. And that’s not a coincidence (read linked threads). That doesn’t mean nothing will ever happen. Nothing is fully fail-safe. But the talking points themselves are completely false.
Also, I would like to see you explain how
cargoitself is a problem. It’s a build tool that is not tied tocrates.io. You can use different registries, repos, and even full vendoring with it (which you can switch to with one command, and it will just work). But I can’t wait to hear your explanation 🙂. Examples of tools that do it better, with an explanation why would also be appreciated 🙂.This myth is discussed extensively in the linked threads at the start of this comment, especially the second one.
Also covered in the linked threads. But let’s address specifics.
crates.ioincluded. So they inherently can’t have better supply chain security than upstreams at the code level, unless you’re also a believer in the popular myth "they review and vet everything ". Some distros may have good/better build security practices. But that’s about it.What makes you think JAVA or its ecosystem(s) are unique or immune from any of this?
Debian stable, Red Hat, and Ubuntu LTS were not affected. They also happen to be popular on servers, because of things like this.
Debian only updates packages on a new distro release, every 4 years. Red Hat does so every 13 years. There is a huge difference between a 6+ year window to detect packages, and a less than a week’s notice because you are keeping up with the latest from upstream.
I will address this one at the end, since it’s a longer point.
Okay. And? We are talking about supply chain security here.
There is a huge difference between vetting packages once every 6 years, and the continuous, ongoing, toilsome process that you are made to in order to maintain systems like cargo’s build system.
The XZ utils backdoor could have easily effected any distro that uses xz for any form of root/system level service. The backdoor makers decision to not do this doesn’t actually make Arch or other distros that did this more secure. Debian stable did not receive vulnerable code in the first place. Big difference.
This is because rust and crates makes it impossible to do any form of dynamic linking. Which is why some people have gripes with rust and avoid it.
But for C, Java, and other languages, it is possible for distros to ship and manage libraries, which has the benefit that the various libraries can have their security issues fixed automatically.
The Java ecosystem, and it’s various language specific package managers have lots of problems. But I am specifically talking about the Java ecosystem available from stable Linux distros, like Red Hat or Debian.
So. Why would I want a stable distro? Why would I want “old” packages? The reason is very simple: The absolute guarantee of compatibility between the security updates, of the programs themselves, and dynamically linked libraries.
If I make, say, a Java program, and tie it to Java packages available from the stable distro, when programs in that
The model of vendoring dependencies, breaks this. With Cargo (or uv or etc), the programs move very fast, and updates break things. In order to prevent their program from breaking, developers pin packages. And then, they don’t update them. This results in them shipping code with CVE’s to their users, even though the CVE has already been fixed in an upstream version.
I like to run cargo-audit, or the go equivalents on the open source projects I look at, and I almost always find vulnerabilities of varying degrees of criticallity. Here is cargo-audit ran against radicle-tui: https://gist.github.com/moonpiedumplings/7e71121b76c58ecaba4176be9bb827c4
With a mere 5 months of not being touched, there are now present CVE’s that are critical on the scoring system (radicles top repo had none yippee! and their second to top repo had a few mediums). It irritates me to see them in software that interacts with networked systems.
I only very rarely find programs that are empty of CVE’s. Usually only the most well resourced, active projects are able to keep their audit clean. It’s a lot of work —
Work that a stable distro automates. With a stable Linux distribution like Debian, I can be confident that if I make a program tied to libraries or programs that the distro provides, this stuff will automatically be patched and handled for me.
Look, you don’t have to use a stable distro on your own personal Linux desktop. I use Arch on my laptop. But for servers, not using pinned dependencies, and instead linking against libraries provided by distros means saving thousands of hours of toil doing basic cleanup of updating libraries and figuring out what the newer version of libraries broke. With a stable distro, you just do that once every six years.
And here the myth shows its head. No one is actually “vetting” 10s of thousand of packages, to a meaningful degree.
And all distros have rolling channels and testing channels, so the every X years part is mythical itself.
In the case of Debian, when is the mythical vetting taking place exactly? Whenever a Debian unstable/sid package gets updated? That’s a rolling repo.
Or is it when world is frozen, and the unvetted packages which lived happily in “unstable” and “testing” will now magically get vetted on their way to “stable”, in a few months (not six years as you imagined).
You clearly lack basic knowledge about what actually goes on in a distro release cycle.
You missed the point.
crates.iois a source registry. Debian ships binary packages (yes, including rust ones).Where do you think Debian gets source packages for C or C++ from? Did you think they get them in the (physical) mailbox? 🎅
As for dynamic linking, the “security” argument for it has been discussed and debunked. You can search the web for discussions regarding that. Most arguments for
.sohas been debunked, in fact.Nothing is “automatic” when it comes to distro maintenance. Much more so when an upstream doesn’t give a f*** about helping you patch your X years old version. If Red Hat, Canonical, …etc wasn’t actively paying developers to do maintenance, Debian wouldn’t exist as it is. But even then, that only covers a very small fraction of core packages.
Pinning and vendoring are orthogonal.
The original talking points were about source supply chains. But people like you seem to confuse concerns across multiple chains from the individual upstream dev to the binary distro repo mirror.
Pinning is actually the only way to actually (almost*) guarantee that built code would work correctly. What distros sell you is “should work” and “API looks compatible” and “this patch hopefully doesn’t break the interface”.
And more ironically, why distros do is global pinning, so the problem is apparently not pinning itself, but upstreams choosing the pinning themselves, right? right?
“But they don’t fully pin… security updates smth smth”
Good. Let’s continue…
Good.
The next best thing to pinning is semver-compatible updates.
Now you have an example where you will see that to “fix all CVEs”, you need to run the total of TWO whopping commands.
You ran the first command already. The second is
cargo update(orcargo update <only_audit_mentioned_packages>if you want to be more precise.cargo updateonly does semver-compatible updates, as released, authorized, and supported by the upstreams, whose knowledge of the code and its interfaces infinitely trumps your random distro maintainer doing raw patching. This is how a coherent competent ecosystem operates.Some of what the distros do is actually not far away from this. If you looked close enough, you will find that it’s not rare for a stated “frozen” version to be a complete lie, with distro patches effectively updating the distro source package to a later patch, or sometimes even minor version, without changing the version number.
But of course, they wouldn’t tell you about any of that, because the myths must live on 😉.
While not completely misplaced, your confidence is inspiring 🙂.
Have passed this info onto the dev but it didn’t seem useful to them.
Also, based on your other comments in this thread like the ones where you pretended onion services should never be used due to traffic - blocking you now, no longer interested in seeing if you have anything useful to contribute. If you need to say anything else, feel free to reach out to the dev directly or reach out to me on nostr, where there are no blocks and I’m more patient.
Did you expect him to just outright admit that you paid for granite and got Swiss cheese 🙂 👋
Awesome, I think you’re the first person to give Cradicle a bit of a code audit. Thank you. I’ll check your feedback with a more C-focused programming community to see what others think before passing it onto the dev.
This reminds me of another reason I thought the dev made an interesting choice with C: by using C, we might attract “red team” volunteers to provide scrutiny.