@ploum
Or one of the decentralized forges. I know of two, #radicle and #tangled

@bagder Essentially, #curl commit 0ae0abbe72514a75c10bfc4108d9f254f594c086 broke updating #HardenedBSD packages for certain users who use HardenedBSD behind a fully Tor-ified network (a network that uses transparent Tor proxying).

Those users were unable to update their HardenedBSD systems since the package manager uses libcurl behind-the-scenes. Some of these users live in malicious environments (malicious to human life), with actively-exploited applications.

So, this prohibition had a real negative impact, putting our users in harm's way.

If curl had a way to bypass the prohibition, we would've been able to keep our users safe.

This is why I mention #Radicle: they, too, do not support the .onion TLD by default, but can be configured to provide that support.

Radicle has three options:

1. Default: No support, .onion domain lookups will fail.
2. SOCKS support where .onion lookups succeed.
3. Explicit transparent proxying support, so .onion lookups succeed

curl is missing that third option.

@bagder #Radicle supports being configured to access #Tor Onion service endpoints via SOCKS or via transparent proxying.

@dentangle this is great, and very interesting. The other day we were test-driving #radicle for a #p2p forge, but bumped into some issues that await troubleshooting in some spare time.

Let's go @librecast

I'd love to learn more about the general context of "forging free software" in this set up, within decentralized environments.

Good material to blog about?

@mrmasterkeyboard I took it one step further and went for the decentralized alternative. #Radicle
(there are a couple more decentralized choices, mind you)

@yorgos @radicle @tshepang @data0 @ayo

Thank you, that is wonderful.

I can add that people I work with already have a yearslong experience with #radicle, and they were very positive about its operation.

Kudos to the great efforts of you and your team!

@smallcircles

Anything we can do on the #Radicle side to help you try out @radicle , please do let us know!

We're currently working to smooth out the rough edges of the onboarding experience, so any problems you come across would be really helpful to know!

We're over on https://radicle.zulipchat.com/ . Please feel free to join us! :)

@tshepang @data0 @ayo

@voidcontext @radicle Signing a commit (with the radicle ssh key) and then pushing it to GitHub is certainly a great way to show the accounts are linked !

As far as I understand, that is only on the project level though - not on the user level.

I would ideally be looking for a generic way for the GitHub user to attest "this is my #Radicle public key and here is something signed by it to prove that it really is mine".

Maybe signing a commit to their "GitHub Profile Readme" though ??

@tshepang @data0 @ayo

For its 'hackability' as advertised on the project page, and that it is a more lightweight comprehensive codebase in Rust.

But at this moment we are looking into both, using #radicle as-is as a daily driver for our own purposes and #ayllu to integrate with. (Though this is currently on pause).

@ferki @radicle Start from https://radicle-ci.liw.fi/ and hang out on the Radicel Zulip "#radicle-ci" channel (https://radicle.zulipchat.com/#narrow/channel/452370-radicle-ci)