this post was submitted on 24 May 2026

18 points (80.0% liked)

Programming

27551 readers

443 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

Cradicle the p2p github alternative (based on Radicle) is looking for users/testers (piefed.social)

submitted 1 month ago* (last edited 1 month ago) by iloveDigit@piefed.social to c/programming@programming.dev

38 comments fedilink hide all child comments

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)

all 39 comments

sorted by: hot top controversial new old

[–] ISO@lemmy.zip 13 points 1 month ago (1 children)

using Tor for universal, straightforward seeding of git repos.

That doesn't sound right. Maybe design/implementation details would make it less nonsensical.

C implementation of radicle

Now this just sounds like a bad joke. Especially with the tor project itself spending all this effort to give us arti as a readily usable embeddable rust crate.

[–] iloveDigit@piefed.social -2 points 1 month ago* (last edited 1 month ago) (2 children)

That doesn’t sound right. Maybe design/implementation details would make it less nonsensical.

The proposal used Tor's onion addresses as an answer to Radicle (unlike BitTorrent) requiring seeders to have fixed IP addresses or domain names (edit - or preconfigured onion proxies or something making onion addresses complex to use). Another reply suggests this problem with Radicle has been fixed or they've started fixing it while this project was in development. I haven't really kept up with the news on Radicle in that timeframe.

sounds like a bad joke

I don't see why. If radicle is a serious decentralized project at the scale of potentially replacing github, it should of course end up with multiple implementations in multiple programming languages. Can you clarify your view more?

[–] asdfasdfasdf@lemmy.world 5 points 1 month ago* (last edited 1 month ago)

There's almost zero reason to choose C for any greenfield project. C / C++ have been plagued with extremely serious problems throughout history because they are not memory safe. The world needs to move on from memory unsafe languages whenever it can.

Choosing C for something like this would be idiotic.

[–] ISO@lemmy.zip 0 points 1 month ago (1 children)

The proposal used Tor’s onion addresses as an answer to Radicle (unlike BitTorrent) requiring seeders to have fixed IP addresses or domain names

That's an even worse use-case mismatch than anything I had in mind, forcing anonymous transport via a traffic-pressured network primarily used for outproxying, just to get fixed network addressing.

[–] iloveDigit@piefed.social -1 points 1 month ago* (last edited 1 month ago) (1 children)

I don't get what you mean by "traffic-pressured." If you're referring to the Tor devs recommending against the use of torrents, that's because torrents typically involve out-of-Tor traffic which burdens exit nodes. Cradicle isn't torrents, the Tor devs don't recommend against using onion addresses for their intended purpose of traffic within the Tor network, that wouldn't make much sense.

Regardless, if you have a better way to implement one-click seeding like bittorrent clients have, feel free to suggest it or build it.

[–] ISO@lemmy.zip 1 points 1 month ago (1 children)

The bottlenecks don't only exist at the exit nodes. You didn't actually think you will be getting Gigabit speeds using hidden-services, did you?

[–] iloveDigit@piefed.social -1 points 1 month ago* (last edited 1 month ago) (1 children)

You seem to be suggesting 3 things:

I thought onion services got gigabit speeds, for some reason
It's my fault for some reason if people with gigabit client/server connections available insist on using Tor and then complain about speed
Aside from the mostly-unrelated traffic issue I was reminded of - "torrents generally strain exit nodes" like Tor officially says - there's also a more pertinent issue of "onion services should never be used for traffic because that would strain Tor"

Are we on the same page with these 3 bullet points, or am I still not understanding you?

[–] ISO@lemmy.zip 1 points 1 month ago (2 children)

Tor as a network is all busy.
A Tor connection is as slow as the slowest hop in the path.
Tor primary function is to provide anonymous transport.

Tor is slow. People use it when they need the anonymity. Using it when it's not strictly needed doesn't help you (or the network, but that's besides the point).

The problem you presented, as I understand it at least, doesn't require Tor at all, and can be solved with much lighterweight solutions. For example, did you know that PKARR exits?

[–] hirihit640@sh.itjust.works 1 points 1 month ago (1 children)

Anonymity makes sense in this case. Radicle is often proposed as a solution to the censorship of projects in other repos, things like Nintendo Switch emulators, Hayase streaming client, etc. These projects want to remain anonymous to avoid legal threats on their actual identity

[–] ISO@lemmy.zip 1 points 1 month ago (1 children)

P2P already gives you anti-censorship. Publisher anonymity shouldn't be hard for developers to achieve either.

If full network anonymity is desirable, then you would need a full top-down design to do it properly, and this becomes a whole different conversation (and the choice of using bittorrent itself will have to be revisited). But really, I don't think that's needed here.

Pluggable transports can still be useful for varying reasons of course. I don't think anyone would argue against them.

But I would still opine that forcing a slow network on any forge alternative is the fastest way to keep 99% of potential users away.

[–] hirihit640@sh.itjust.works 1 points 1 month ago* (last edited 1 month ago) (1 children)

P2P already gives you anti-censorship

until a lawyer joins the swarm and has the IP of every node. See which node pushes commits to the swarm first, and you found the dev. Send a couple of threats to the dev and watch the project grind to a halt.

Plugging into Tor or I2P is a easy way to give network anonymity, no need to re-invent the wheel. Though it seems like Radicle already supports Tor and I2P so not entirely sure what OP aims to do

[–] ISO@lemmy.zip 1 points 1 month ago (1 children)

How do you send a threat to an IP address? 😏 about supposed push of code encrypted no less. Unless, you're thinking ISP involvement, that would be a hilarious (single) e-mail to read (from the "lawyer" to the ISP, because there will be no other correspondence).

If the threat model is "lawyer", developers will be fine. If it's a "state actor" and/or all users need protection, then again, this is a whole other conversation. If it's something in between, then yes, maybe developers/publishers should specifically be careful, and/or maybe the design of the software should help them, but without compromising the performance of the whole network. But again, bittorrent will not be the right protocol for this anyway.

[–] hirihit640@sh.itjust.works 1 points 1 month ago (1 children)

How do you send a threat to an IP address?

Unless, you're thinking ISP involvement

There's many ways to track somebody down via IP address, but yes ISPs can corroborate. You ever heard of people getting letters from the ISP for torrenting? You think the ISPs actually care about piracy? They are forced by legal pressure.

If the threat model is "lawyer", developers will be fine

The threat model is massive fines and potential prison, depending on how the court case goes. Look up the Yuzu nintendo switch emulator and how that legal battle went. And I'm not arguing that those developers were the brightest of the bunch. I'm saying that those developers could use the privacy that Tor offers.

bittorrent will not be the right protocol for this anyway.

Bittorrent works well enough. Bittorrent works fine over I2P and is used plenty. Better to get something up and running before starting to design bespoke protocols.

[–] ISO@lemmy.zip 1 points 1 month ago (1 children)

You ever heard of people getting letters from the ISP for torrenting?

🤣

I deliberately mentioned this because that "program", as you would expect, ended up as a failed meme, which is why it's sadly no longer with us.

And it wasn't about people seeding their own code, or code otherwise allowed to be redistributed, anyway.

[–] hirihit640@sh.itjust.works 1 points 1 month ago

I actually know somebody that was fined quite a bit for torrenting, so idk what you mean by failed meme. The ISP absolutely does collaborate with copyright lawyers. So if copyright lawyers with enough money want to take down a nintendo switch emulator, and they got the IP of the dev, they cound find the real person behind it easily.

[–] iloveDigit@piefed.social -2 points 1 month ago* (last edited 1 month ago) (1 children)

If Tor gets more users, they can run Tor nodes. The network scales to the traffic because it's decentralized. You're making up a problem that isn't there. The Tor project does not recommend against creating traffic using onion services, again it wouldn't make sense, there would be nothing to do with onion services then.

I'm really not understanding your point about anonymity. Why would we want every user in a P2P network to expose their clearnet IP address to every other user? It seems like if you flipped the release dates of Tor and BitTorrent, then Bram Cohen probably would have designed BitTorrent with Tor in mind from the start and it wouldn't burden exit nodes so much. People would only use it without Tor when speed is more of a priority than security. But instead BitTorrent came first and already relied on an out-of-Tor network.

[–] ISO@lemmy.zip 0 points 1 month ago (1 children)

Most tor peers are not relays. So no, tor's network capacity doesn't auto-scale with more users, even when you're sticking to hidden services.

And you didn't argue for anonymity from the start. And anonymity is a BIG argument, with bigger design implications than you think.

Original Freenet (now called Hyphanet) predates both bittorrent and tor. And it's one early example (and not the only one btw) of how you properly combine anonymous storage with anonymous transport (content addressing too, but that's more of a jibe against the IPFS meme). It's also (relatively) slow, and that's actually intentional, at least in part, because speed can hurt your anonymity (the details are too technical, and that's not the place to delve into them).

Bittorrent didn't lack (native) anonymity because the idea/tech was impossible to imagine. Anonymity didn't come into the picture because availability and speed were the priorities. The protocol didn't have encryption from the start either (or sub-piece downloading, or DHT, or PEX, or udp trackers, or uTP transport, but I digress).

[–] iloveDigit@piefed.social -2 points 1 month ago* (last edited 1 month ago)

Edit - I'll leave my original reply crossed out, but it doesn't feel like a good reply to me and I think sometimes I don't know how to properly respond to people these days.

~~Stop with the gish gallops.~~

~~I should not need to address this many points because you keep pulling random nonsense out of nowhere. Look how fucking long this list of bullet points is just for one reply. Do some amount of double-checking your own thoughts before making me think through every single thought that pops into your head.~~
~~You're incorrect on your first point. Non-relay "peers" don't stop Tor from scaling.~~
~~When you say "from the start" it seems to imply I started "arguing for anonymity" at some point. I didn't. This is an electronic network.~~
~~Instead of explaining how hyphanet is supposed to be better than Tor for p2p git repos, you kept dwelling on conflating "privacy" with something users can get from a widespread software network on today's hardware.~~
~~Tor being "slow" is "intentional" for the same reason, I don't get what makes you think that's groundbreaking.~~
~~What's not the place to delve into what?~~
~~This pattern keeps showing up: the part about BitTorrent seems like you're conflating "anonymity" with something users can get out of a network like this, and not actually getting to whatever your point is about BitTorrent.~~

[–] ISO@lemmy.zip 8 points 1 month ago (3 children)

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 checking len_str first.

But you might be thinking, maybe len_str can't be zero!

Let's compile first with the AddressSanitizer enabled:

# compile
% gcc -Wall -fsanitize=address t.c -o t

Now 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 AddressSanitizer output 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, inp is shifted before inp length 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:

One issue I have with rust is that it adds another layer of trusting the compiler isn't backdoored. All UNIX/Linux systems use the gcc toolchain

Maybe such an enlightened developer should know that you can bootstrap rustc from mrustc using GCC.

[–] iloveDigit@piefed.social 1 points 1 month ago* (last edited 1 month ago)

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.

[–] moonpiedumplings@programming.dev 1 points 1 week ago (1 children)

One issue I have with rust is that it adds another layer of trusting the compiler isn’t backdoored. All UNIX/Linux systems use the gcc toolchain

They are probably also referring to this: https://kerkour.com/rust-supply-chain-nightmare

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

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:

installation instructions for Debian-based distros: here

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.

[–] BB_C@programming.dev 1 points 1 week ago (1 children)

Weird how this random thread came back to life, just to rehash some talking points.

See my comments here and here.

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

If you followed the link, you would have seen that nothing actually fishy was found, unlike the implication.

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.

The number of actual supply chain attacks actually effecting anybody in the crates.io ecosystem is ZERO. In npm, it's a weekly occurrence.

less popular

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 cargo itself is a problem. It's a build tool that is not tied to crates.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 🙂.

Stable linux distributions have extremely strong supply chain security in comparison to language specific package managers.

This myth is discussed extensively in the linked threads at the start of this comment, especially the second one.

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.

Also covered in the linked threads. But let's address specifics.

Debian unstable/sid (the rolling branch) was affected. Debian is not special.
Debian stable was unaffected because it runs multi-year old packages. This specific attack was discovered early, so they were spared. Other upstream-controlled attacks could target projected-to-be-stable upstream versions, and remove the compromised part later, reversing that effect (depending on who would discover the malicious code, and what are they testing looking at).
The stable distro model is broken. Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones. And out-of-date(ness) itself can have adverse affects in other ways. This was always been known/realized by people who know the reality of the situation. But nowadays, "AI" security scanners had a complete mockery of the stable distro model "security" claims.
Debian's willy-nilly "security" patching in particular, lead to multiple scandals in the past. This is not all theoretical. One day half the internet had to re-issue SSL certs/keys because of the mythical Debian super security. And on that subject, do you know what distro wasn't affected by the specific xz attack, despite actually shipping the compromised xz version? It's Arch. Why? Because they didn't patch systemd with xz support thinking they can outsmart an upstream.
Distros pull from upstreams anyway (code has to exist somewhere), crates.io included. 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.

I would prefer Java if you cared strongly about supply chain security

What makes you think JAVA or its ecosystem(s) are unique or immune from any of this?

[–] moonpiedumplings@programming.dev 1 points 1 week ago (1 children)

Debian unstable/sid (the rolling branch) was affected. Debian is not special.

Debian stable, Red Hat, and Ubuntu LTS were not affected. They also happen to be popular on servers, because of things like this.

This specific attack was discovered early,

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.

The stable distro model is broken.

I will address this one at the end, since it's a longer point.

Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones.

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.

despite actually shipping the compromised xz version? It’s Arch. Why? Because they didn’t patch systemd with xz support thinking they can outsmart an upstream.

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.

Distros pull from upstreams anyway (code has to exist somewhere), crates.io included.

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.

What makes you think JAVA or its ecosystem(s)

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.

[–] BB_C@programming.dev 1 points 1 week ago* (last edited 1 week ago)

There is a huge difference between vetting packages once every 6 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.

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.

You missed the point. crates.io is 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 .so has been debunked, in fact.

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.

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.

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.

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..

Here is cargo-audit ran against radicle-tui

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 (or cargo update <only_audit_mentioned_packages> if you want to be more precise.

cargo update only 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 😉.

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.

While not completely misplaced, your confidence is inspiring 🙂.

[–] iloveDigit@piefed.social -1 points 1 week ago (1 children)

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.

[–] ISO@lemmy.zip 1 points 1 week ago

but it didn’t seem useful to them.

Did you expect him to just outright admit that you paid for granite and got Swiss cheese 🙂 👋

[–] onlinepersona@programming.dev 6 points 1 month ago (1 children)

But why? Radicle supports TOR and I2P (see changelog).

[–] iloveDigit@piefed.social 1 points 1 month ago* (last edited 1 month ago) (1 children)

At the time I made the proposal, I couldn't figure out a simple way to seed repos with Radicle like I was familiar with from GUI-based BitTorrent clients, and when I asked people in the community why it was so complicated, the answer I ended up with was that it was due to domain names / static IP addresses being required instead of onion addresses (or other decentralized cryptographic addresses)

Has that changed since then? Doesn't quite seem clear to me from the link you posted

Edit - after thinking about it a little more, I remember it may have been possible to use Tor via a proxy at the time I made the proposal, but it didn't work fully and wasn't anywhere near a 1 click solution like bittorrent. Still not sure if that's changed

[–] onlinepersona@programming.dev 2 points 1 month ago (1 children)

Radicle doesn't have a 1-click solution to TOR and I2P, but there is a guide. Granted, radicle could do with a GUI configuration tool, but I think a fork and C rewrite are unnecessary to achieve that. A script around it could probably achieve the same. On nixos, it would be a simple matter of writing and sharing a configuration.

[–] iloveDigit@piefed.social -1 points 1 month ago* (last edited 1 month ago)

Guide: you can't compete with github using a CLI guide while there's no one click solution. With BitTorrent in its constant state of DDoS and fragmentation despite having easier seeding, radicle's harder seeding makes the math even worse.
Fork: it was up to radicle whether to implement the proposal in their mainline release or require a fork, but I don't see how or why you'd pretend a fork wasn't required after a fork is already the thing that happened faster (and a massively rewritten one, too).
C rewrite: indeed, as I said to begin with that was an expansion by the dev that took the proposal, beyond the scope of the original requirements.

[–] hirihit640@sh.itjust.works 3 points 1 month ago

I don't see the point of forking Radicle. Radicle itself barely has any users, how many users do you expect your fork to have? Think about re-writing Radicle in another language later. It's not certain Radicle will even exist a year from now

[–] FizzyOrange@programming.dev 3 points 1 month ago (1 children)

Is Tor really "straightforward"? It sounds anything but.

Also C? In 2026? Radicle seems to be written mostly in Rust, with Typescript for the web interface. Why on earth would you want to downgrade to C?

[–] iloveDigit@piefed.social -2 points 1 month ago* (last edited 1 month ago) (1 children)

Tor: Our goal is to make seeding a git repo as simple as seeding a torrent, and Tor seems like it can indeed allow users to do it that straightforwardly with the bonus of not exposing everyone's IP addresses to each other.
Typescript: Cradicle's web interface improves security by keeping all the complex functionality in the HTML server and serving pure scriptless HTML to web browsers instead.
C: I'm not a coder but I thought it was pretty cool when the main dev Andrew K announced they're using C, because I hear it allows more control over compiler behavior, and in the long run of course there should be radicle apps in multiple coding languages, like there are BitTorrent apps in multiple coding languages.

[–] FizzyOrange@programming.dev 1 points 1 month ago (1 children)

Cradicle’s web interface improves security by keeping all the complex functionality in the HTML server and serving pure scriptless HTML to web browsers instead.

That isn't really any more secure.

I hear it allows more control over compiler behavior

Not in a good way - more like a "oh good what compiler flags do I need to mess with to make this code work?" way 😄

there should be radicle apps in multiple coding languages, like there are BitTorrent apps in multiple coding languages.

Reasonable. C is still a poor choice though.

[–] iloveDigit@piefed.social -1 points 1 month ago (1 children)

That isn’t really any more secure.

It is when javascript vulnerabilities are exploited, that's why Tor Browser's "safest" preset doesn't allow js

[–] FizzyOrange@programming.dev 0 points 1 month ago (1 children)

Ah you're expecting users to browse with no JS enabled. Does Radicle's web interface actually require JS anyway? And either way that's no reason to pick C over Typescript.

[–] iloveDigit@piefed.social 0 points 1 month ago* (last edited 1 month ago) (1 children)

I don't remember the exact extent or know if it's changed, but Radicle's web interface definitely used javascript excessively at the time I posted the original proposal.

It sounds like I was confused about Typescript, I thought it was more closely related to js

[–] FizzyOrange@programming.dev 1 points 1 month ago

Typescript is JavaScript, just with static type annotations.