Please wait...
0 files
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
I have yet to check the soure code in deepth since I am first experimenting with how the software itself is supposed to _feel_. I am setting a little lab for testing, but so far I haven't gone very far because real life is getting in my way non stop :(
I am not interested in shoehorning WebCit into the role yet, because any web interface I would place in a darknet needs to not require Javascript support from the browser. People in darknets can become very paranoid regarding client-side scripting and executable applets and the like. There is a lot of concern for drive-by-hacking in which somebody hacks a server and then tries to exploit browsers. That is why I am interested in the Telnet side of things. As far as I understand, legacy protocols such as Telnet and Gopher lack cookies, http headers, user-agents and many of the regular resources that can be used for fingerprinting users.
As for setting a hidden service in a darknet, well, making a port available as an onion address or i2p address is actually easy as long as you are familiar with the software. Say your server is listening at port 504, on all interfaces. In i2p, standard way is to install an i2p node in headless mode (you can configure the reference i2p software via web interface) and then create a server tunnel configured to use 127.0.0.1:504 as source. BOOM, i2p generates an address and now you can access that port using the address you just generated to access that port via any i2p client.
Now, if you want to have services that federate themselves dynamically, such as XMPP, Email and such, then you are a bit out of luck, because you have to set a client tunnel for each of the nodes you want your application to talk to and them map them manually. So you could have a federated Citadel network in i2p, but peering must either a) be statically configured b) patched into Citadel so Citadel becomes i2p aware and can interface with the i2p daemon in order to dynamically create and close tunnels.
Long story short: standalone service is to be set in 5 minutes, complex distributed or federated application needs work. There are actual IRC *networks* in i2p, and torrent, and gnutella clones in it, but those are not that trivial to set up.
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
I2P is a totally different protocol and network, and it is not related to Tor. It is a hidden-service only network.
Disabling the init function at calendar_server.c and then wiping out the proper module_init line did the trick. I suppose the same can be done with any other module. As you can expect, Webcit thows an error and cannot access any of the citadel backend because it tries to initiate an ICAL call that gets no correct answer. So far it is a really good start. I think it would be good form to have the modules be "selectable" during ./configure time, but then it would make a mess with users trying to use webcit with citaldel backends that don't have all the modules compiled in.
When playing with the citadel text client, I get the following lines upon connection:
Attaching to server...
[localhost:504]
Citadel: $some_number
CItadel server
[null]
pause next stop
etc etc etc
May I ask what $some_numer (which is an actual number, ofc) is? Is it an instance identifier? A server ID?
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
Silly me, it is the software version, hahahaha
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
really good start. I think it would be good form to have the modules
be "selectable" during ./configure time, but then it would make a
mess with users trying to use webcit with citaldel backends that
At one time we had everything set up as dynamic loadable modules. It was great when it worked, but there were a lot of issues with portability and build problems so we pulled that out. But as you can see, it lives on in the form of a high degree of modularity in the server.
Calendar was once a compile-time option as well. Again, it made the build more complicated, so we ended that.
More likely than not, we can simply put in a runtime option to switch the feature off for sites that don't need it. The same would be true for contacts, notes, etc. It just creates too many support problems to add options at build time. Also ... in the not too distant future, Citadel will be shipped as a Docker container. Compilable source code will continue to be available but I expect Docker will replace Easy Install as the "mainstream" way to install Citadel. (Unfortunately, someone already claimed the "citadel" namespace on dockerhub.)
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
So far I think I have everything I need. If I end up setting a serviceable node anywhere I will tell you.
Cheers!
FIXED!
Citadel Server should now work properly on the latest Linux/Linux distributions, including Debian Stretch and whatever is running on the Raspberry Pi these days.
The newest distributions of the Linux operating system, which uses the Linux kernel, seem to have changed the behavior of pthread_getspecific() when the supplied thread key is uninitialized. And we were doing exactly that, a couple of times during startup. It's been working that way for 20+ years without any problems, but it *is* an invalid call. Once the problem was found, it was easy to fix, but it sure was hard to find.
citadel-927.tar.gz is available for download. Easy Install has also been updated.
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
I2P is a totally different protocol and network, and it is not
related to Tor. It is a hidden-service only network.
If I want to make Uncensored available via I2P as well as on the open Internet, does that create any security risks? My approach to this would be similar to what Fucking Fecesbook did when they made their service available on the Tor network -- it's more to protect the users than to protect the site.
Subject: Re: Disabling features in order to make Citadel fit for darknet use.
The only other real problem is that it gets hard to ban users, because then they can generate tunnel addresses faster than you can usually ban them. It does not look to be a problem in practice, probably because these networks are so small. The people who has some countermessure in place against ban evasion are quite content to require people to email the administrator for activating new accounts, that sort of thing.
Citadel install without problems on Raspberry Pi 3B+ running Raspbian Buster. Thanks IGnatius T Foobar for your effort.