#50 onion site wanted

Open
opened 1 year ago by libBletchley · 52 comments

Please setup an onion site so Tor users can avoid the exit node bottleneck. Notice that Notabug has done this.

Please setup an onion site so Tor users can avoid the exit node bottleneck. Notice that Notabug has [done this](https://notabug.org/tor).
hw commented 1 year ago
Owner

interesting idea. Any contributors?

interesting idea. Any contributors?
Ghost commented 1 year ago

It can’t be done from user side. Only the server owner can.

https://2019.www.torproject.org/docs/tor-onion-service.html.en#zero

Only a few git services support Tor. If you support it, that’ll be really cool!

(I’m Tor contributor and relay owner.)

e.g.

apt install tor
mkdir /hidden/codeberg_tor/
nano /etc/tor/torrc

HiddenServiceDir /hidden/codeberg_tor/
HiddenServicePort 443 127.0.0.1:443

https://(your onion).onion/ == https://codeberg.org/
It can't be done from user side. Only the server owner can. https://2019.www.torproject.org/docs/tor-onion-service.html.en#zero Only a few git services support Tor. If you support it, that'll be _really_ cool! (I'm Tor contributor and relay owner.) e.g. ``` apt install tor mkdir /hidden/codeberg_tor/ nano /etc/tor/torrc HiddenServiceDir /hidden/codeberg_tor/ HiddenServicePort 443 127.0.0.1:443 https://(your onion).onion/ == https://codeberg.org/ ```
ashimokawa commented 1 year ago
Owner

@not_cloudflare
Would that require us to become an “exit node”?
Or just an endpoint for traffic to codeberg.org?

@not_cloudflare Would that require us to become an "exit node"? Or just an endpoint for traffic to codeberg.org?
ashimokawa commented 1 year ago
Owner

A quick research says that we do not have to become an exit node, so personally I am open to the idea.

A quick research says that we do not have to become an exit node, so personally I am open to the idea.
Ghost commented 1 year ago

Hosting onion service is easy. You have to install Tor[1] and edit “torrc” file. Even Facebook, New York Times, and CIA have onions.

You don’t have to become a relay(middle node, exit node).

Here’s a list of WeSupportTor. If codeberg become accessible over Tor, I will use it & add you to the list.

https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor

  • http://onion is safe because onion connection is encrypted.
  • https://onion is more safe, but unnecessary.
  • You can assign any subdomains, such as http://codeberg.generatedonionname.onion/
  • v3 onionname(long onion name) is secure than v2(short onion name).

[1] https://2019.www.torproject.org/docs/debian.html.en#ubuntu

Hosting onion service is easy. You have to install Tor[1] and edit "torrc" file. Even Facebook, New York Times, and CIA have onions. You don't have to become a relay(middle node, exit node). Here's a list of WeSupportTor. If codeberg become accessible over Tor, I will use it & add you to the list. https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor - http://onion is safe because onion connection is encrypted. - https://onion is _more_ safe, but unnecessary. - You can assign any subdomains, such as http://_codeberg_.generatedonionname.onion/ - v3 onionname(long onion name) is secure than v2(short onion name). [1] https://2019.www.torproject.org/docs/debian.html.en#ubuntu
hw commented 1 year ago
Owner

@not_cloudflare: Would you like to contribute an example of the config as PR, for example against the etc/ template folder in https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/?

(these files are directly deployed into /etc/, after templates for ${HOSTNAME_FQDN} etc have been resolved)

@not_cloudflare: Would you like to contribute an example of the config as PR, for example against the etc/ template folder in https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/? (these files are directly deployed into /etc/, after templates for ${HOSTNAME_FQDN} etc have been resolved)
Ghost commented 1 year ago

Tor is a server, not gitea.
(below should work for debian system)

e.g.

---request---> server [{Codeberg Tor} <===localhost===> {Codeberg WWW server}]

---request---> Tor(redirect to 127.0.0.1:80) ======> WWW(listen 127.0.0.1:80)

easy guide: https://www.reddit.com/r/TOR/comments/8tyrye/how_to_create_onion_website_on_web_server_which/

TLDR Example:

0. Create a directory for private key (mkdir /var/dontshareme/codebergonion/)

1. "apt install tor"  <--- https://2019.www.torproject.org/docs/debian.html.en

2. "nano /etc/tor/torrc"

3. Add 3 lines:

HiddenServiceDir /var/dontshareme/codebergonion/
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3

4. "service tor restart"

Tor will connect to the network and generate your .onion hostname(domain).
Don't upload /var/dontshareme/codebergonion/ contents
because these are private keys!

5. You'll find your .onion in /var/dontshareme/codebergonion/.

6. Open http://(your onion).onion/ on Tor Browser and enjoy!

Here’s my test server’s torrc (I’ve hidden some lines but it will be useful):

And manual. https://2019.www.torproject.org/docs/tor-manual.html.en

Log err /dev/null

AvoidDiskWrites 1
CookieAuthentication 1

DataDirectory ????????????
GeoIPFile ????????????
GeoIPv6File ????????????

DirReqStatistics 0
ExtraInfoStatistics 0
HiddenServiceStatistics 0

ExcludeNodes default,CIA,NSA,{us}

ReachableAddresses *:443
ReachableAddresses reject *:*

HiddenServiceDir ????????????
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 465 unix:/var/lib/mailer2/usocket.sox
HiddenServiceVersion 3
Tor is a server, not gitea. (below should work for debian system) e.g. ``` ---request---> server [{Codeberg Tor} <===localhost===> {Codeberg WWW server}] ---request---> Tor(redirect to 127.0.0.1:80) ======> WWW(listen 127.0.0.1:80) ``` easy guide: https://www.reddit.com/r/TOR/comments/8tyrye/how_to_create_onion_website_on_web_server_which/ TLDR Example: ``` 0. Create a directory for private key (mkdir /var/dontshareme/codebergonion/) 1. "apt install tor" <--- https://2019.www.torproject.org/docs/debian.html.en 2. "nano /etc/tor/torrc" 3. Add 3 lines: HiddenServiceDir /var/dontshareme/codebergonion/ HiddenServicePort 80 127.0.0.1:80 HiddenServiceVersion 3 4. "service tor restart" Tor will connect to the network and generate your .onion hostname(domain). Don't upload /var/dontshareme/codebergonion/ contents because these are private keys! 5. You'll find your .onion in /var/dontshareme/codebergonion/. 6. Open http://(your onion).onion/ on Tor Browser and enjoy! ``` --- Here's my test server's torrc (I've hidden some lines but it will be useful): And manual. https://2019.www.torproject.org/docs/tor-manual.html.en ``` Log err /dev/null AvoidDiskWrites 1 CookieAuthentication 1 DataDirectory ???????????? GeoIPFile ???????????? GeoIPv6File ???????????? DirReqStatistics 0 ExtraInfoStatistics 0 HiddenServiceStatistics 0 ExcludeNodes default,CIA,NSA,{us} ReachableAddresses *:443 ReachableAddresses reject *:* HiddenServiceDir ???????????? HiddenServicePort 80 127.0.0.1:80 HiddenServicePort 465 unix:/var/lib/mailer2/usocket.sox HiddenServiceVersion 3 ```
hw commented 1 year ago
Owner

Plain vanilla debian, no 3rdparty apt sources. All local services are routed through haproxy (we want to publish the infrastructure deployment files too, but didn’t have the time for a thourough review yet).

Plain vanilla debian, no 3rdparty apt sources. All local services are routed through haproxy (we want to publish the infrastructure deployment files too, but didn't have the time for a thourough review yet).
hunger commented 8 months ago

Is this still relevant after (partially?) blocking Tor due to abuse?

Is this still relevant after (partially?) blocking Tor due to abuse?
ashimokawa commented 8 months ago
Owner

@hunger

We are current not blocking tor in any way. And we never did. Not one single second.

@hunger We are current not blocking tor in any way. And we never did. Not one single second.
hunger commented 8 months ago

@ashimokawa: I read something about abusive account creation via tor and at least some discussion to block it and must have over-interpreted this.

Sorry for that.

@ashimokawa: I read something about abusive account creation via tor and at least some discussion to block it and must have over-interpreted this. Sorry for that.

I’m interested in providing Codeberg as onion site. I do have experience running various parts of the TOR network so I’m able to help.

I’m interested in providing Codeberg as onion site. I do have experience running various parts of the TOR network so I’m able to help.
hw commented 5 months ago
Owner

nice! What would be needed from our side?

nice! What would be needed from our side?

Some kind of access to the infrastructure code. Esspecially important the /etc dir (of the server not of Gitea like pointed out here #50) in such a way that I can open a PR or something similar.
I also need read access to enough infrastructure code so I can setup a test system to ensure the resulting configuration will actually work.

Some kind of access to the infrastructure code. Esspecially important the `/etc` dir *(of the server not of Gitea like pointed out here https://codeberg.org/Codeberg/Community/issues/50#issuecomment-4151)* in such a way that I can open a PR or something similar. I also need read access to enough infrastructure code so I can setup a test system to ensure the resulting configuration will actually work.
hw commented 5 months ago
Owner

Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option?

You could for example use createVM.sh in https://codeberg.org/Codeberg/build-deploy-gitea as starting point, happy to help if needed.

Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option? You could for example use createVM.sh in https://codeberg.org/Codeberg/build-deploy-gitea as starting point, happy to help if needed.

youre right its probably better not to have TOR on the main machine.
The VM pointer helps I`ll probably start some time next week.

you`re right it`s probably better not to have TOR on the main machine. The VM pointer helps I`ll probably start some time next week.
Ghost commented 3 months ago
@hw @ashimokawa https://blog.torproject.org/more-onions-porfavor
jscott commented 2 months ago

Running tor on main server is a no-go for obvious reasons.

I think there may be a misunderstanding here. What’s the problem with running Tor on the main server?

> Running tor on main server is a no-go for obvious reasons. I think there may be a misunderstanding here. What's the problem with running Tor on the main server?
kreyren commented 1 month ago

It can’t be done from user side. Only the server owner can. #50

Just to clarify: Can be done by a user, but owner provided onion link is prefered for obvious reasons and to avoid limitation like having only read access.

Would that require us to become an “exit node”? #50

Not required for a hidden service afaik

http://onion is safe because onion connection is encrypted.
https://onion is more safe, but unnecessary. #50

Just to clarify:

http://<random-things-here>.onion is safe as Tor is encrypting everything it can

http://clearweb-website.com is not safe as the trafic from the exit node is exposed to the exit node provider and to the clearweb

https://clearweb-website.com is generally considered not unsafe, but can be used for a fingerprinting and tracking for websites that doesn’t have a lot of Tor users (The idea of torbrowser is to have a huge crowd of people with the same browser as a counter-measure to fingerprinting).

We are current not blocking tor in any way. And we never did. Not one single second. #50

That is not secure enough for tor users as we have to depend on an exit node to connect to the clearweb to reach this website, but generally acceptable.


Now to demistify the setup

Basically you download and install tor and add following lines:

############### This section is just for location-hidden services ###

## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
##
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.

#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 127.0.0.1:80

#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22

In codeberg’s case that would be:

HiddenServiceDir /var/lib/tor/codeberg
HiddenServicePort <gitea_port> 127.0.0.1:<gitea_port>

which should be all that is needed for tor users to access the website from tor.

Your onion url will be then stored in /var/lib/tor/codeberg/hostname


Recommending doing a peer-review in irc.oftc.net/#tor for official support.

Referencing my configuration: https://github.com/RiXotStudio/server-setup/blob/master/src/sefunc/00-tor.sh

> It can’t be done from user side. Only the server owner can. https://codeberg.org/Codeberg/Community/issues/50#issuecomment-4136 Just to clarify: Can be done by a user, but owner provided onion link is prefered for obvious reasons and to avoid limitation like having only read access. > Would that require us to become an “exit node”? https://codeberg.org/Codeberg/Community/issues/50#issuecomment-4140 Not required for a hidden service afaik > http://onion is safe because onion connection is encrypted. > https://onion is more safe, but unnecessary. https://codeberg.org/Codeberg/Community/issues/50#issuecomment-4144 Just to clarify: `http://<random-things-here>.onion` is safe as Tor is encrypting everything it can `http://clearweb-website.com` is not safe as the trafic from the exit node is exposed to the exit node provider and to the clearweb `https://clearweb-website.com` is generally considered not unsafe, but can be used for a fingerprinting and tracking for websites that doesn't have a lot of Tor users (The idea of torbrowser is to have a huge crowd of people with the same browser as a counter-measure to fingerprinting). > We are current not blocking tor in any way. And we never did. Not one single second. https://codeberg.org/Codeberg/Community/issues/50#issuecomment-49785 That is not secure enough for tor users as we have to depend on an exit node to connect to the clearweb to reach this website, but generally acceptable. --- Now to demistify the setup Basically you download and install tor and add following lines: ```conf ############### This section is just for location-hidden services ### ## Once you have configured a hidden service, you can look at the ## contents of the file ".../hidden_service/hostname" for the address ## to tell people. ## ## HiddenServicePort x y:z says to redirect requests on port x to the ## address y:z. #HiddenServiceDir /var/lib/tor/hidden_service/ #HiddenServicePort 80 127.0.0.1:80 #HiddenServiceDir /var/lib/tor/other_hidden_service/ #HiddenServicePort 80 127.0.0.1:80 #HiddenServicePort 22 127.0.0.1:22 ``` In codeberg's case that would be: ``` HiddenServiceDir /var/lib/tor/codeberg HiddenServicePort <gitea_port> 127.0.0.1:<gitea_port> ``` which should be all that is needed for tor users to access the website from tor. Your onion url will be then stored in `/var/lib/tor/codeberg/hostname` --- Recommending doing a peer-review in irc.oftc.net/#tor for official support. Referencing my configuration: https://github.com/RiXotStudio/server-setup/blob/master/src/sefunc/00-tor.sh
kreyren commented 1 month ago

Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option? @hw

Elaborate on obvious reasons?

> Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option? @hw Elaborate on obvious reasons?
hw commented 1 month ago
Owner

Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option? @hw

Elaborate on obvious reasons?

All attacks on Codeberg came via Tor in the past. Any DDOS/attack on this channel would harm the entire platform if running in the same machine.

> > Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option? @hw > > Elaborate on obvious reasons? All attacks on Codeberg came via Tor in the past. Any DDOS/attack on this channel would harm the entire platform if running in the same machine.
hw commented 1 month ago
Owner

To clarify once again: if one or more contributors volunteer to sponsor/setup/run the required infrastructure, we will happily endorse this. It is just that nobody raised his hand yet to commit.

To clarify once again: if one or more contributors volunteer to sponsor/setup/run the required infrastructure, we will happily endorse this. It is just that nobody raised his hand yet to commit.
kreyren commented 1 month ago

EDIT: Upon peer-review the rate limits might be only for relays will update once clarified
EDIT2: BandwidthRate is used for this, adapted

All attacks on Codeberg came via Tor in the past. Any DDOS/attack on this channel would harm the entire platform if running in the same machine.

@hw I believe that you are misinformed about the subject, there were lot of DDoS attacks in 2019 due to the bug discovered in Tor itself[1] which has been allegedly fixed so these attacks should be drastically reduced by now as they are much more difficult and much more resource intensive to perform.

As said in general performing DDoS/DoS from Tor to a hidden service and/or clearweb is more resource intensive compared to just using clearweb as Tor has to encrypt the traffic multiple times and route it through three relays so theoretically to perform a successful DDoS/DoS from Tor you would need to set up multiple tor clients sandboxed with cherrypicked ExcludeNodes i.e using curl https://onionoo.torproject.org/details 2>/dev/null | jq -r '.relays[] | select(.observed_bandwidth <= 1310720) | .or_addresses' | grep -oP "^\s+\"(\w+\.\w+\.\w+\.\w+\:\w+)" | sed "s/^ \"//gm" | tr '\n' ',' (Tool from https://github.com/Krey-s-Tor/torrc/blob/master/src/ExcludeSlowRelays.conf) to exclude slow tor relays that would be limiting the Tor DDoS/DoS then set up a loop that runs something alike pidof tor | xargs sudo kill -HUP to generate a new routes which based on my unreliable and questionable experiment (so the experiment should be verified) would take 100mbps upload into 8mbps attack in which case it’s much more efficient to perform the attack from a clearweb not to mension that such changes to the Tor are going to make the attacker fingerprintable and sacrifice anonymity.

But if you are still concerned about Tor halting your system then you can rate limit it by using:

# Bandwidth limiters
BandwidthRate 125 KB # Throttle traffic to 125KB/s 1000Kbps)

So even if attacker takes down Tor (very unlikely) you can still have working system and if that it not enough to you then the application itself should be optimized on DDoS/DoS i.e the registration which torproject suggest[1] to make proof-of-work which is for example implemented on Hackint.org[4].

And if that is still not enough to you i would recommend Linux kernel with MuQSS scheduler from weebo dentist CK which shown[5][6] to be much more difficult to made halt and to be more efficient in handling the load on systems with more then 4 threads at the cost of generating more heat (optimizable) and requiring more electricity compared to Complitely Fair Scheduler (CFS). Based on my experience MuQSS is more economical in commercial application as it allows the system the have a reliable scheduler as CFS likes to halt and get confused too much.

I’ve also linked an utility to test the system agains tor DDoS/DoS[3]

References

  1. Bug in tor allowing DDoS https://trac.torproject.org/projects/tor/ticket/29607
  2. Referenced from torproject to handle DDoS on hidden services https://blog.torproject.org/stop-the-onion-denial
  3. Tool used to perform the DDoS attack through Tor https://github.com/r3nt0n/torDDoS
  4. Proof-of-work is for example utilized on hackint.org https://www.hackint.org/transport/tor
  5. Reference to liquorix kernel https://liquorix.net/
  6. Benchmark of CFS vs MUQSS https://openbenchmarking.org/result/2005044-NI-SMALLPT1752&hgv=kernel+5.3.14%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss&rmm=kernel+5.3.14%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss&hnr=1&hni=1&swl=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6&hnr=1&hni=1&sgm=1&swl=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6&hnr=1&hni=1&sgm=1&swl=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=Arch+5.4.8&hnr=1&hni=1&scalar=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2C5.6-tkg-acpi-pbo%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6
EDIT: Upon peer-review the rate limits might be only for relays will update once clarified EDIT2: `BandwidthRate` is used for this, adapted > All attacks on Codeberg came via Tor in the past. Any DDOS/attack on this channel would harm the entire platform if running in the same machine. @hw I believe that you are misinformed about the subject, there were lot of DDoS attacks in 2019 due to the bug discovered in Tor itself[1] which has been allegedly fixed so these attacks should be drastically reduced by now as they are much more difficult and much more resource intensive to perform. As said in general performing DDoS/DoS from Tor to a hidden service and/or clearweb is more resource intensive compared to just using clearweb as Tor has to encrypt the traffic multiple times and route it through three relays so theoretically to perform a successful DDoS/DoS from Tor you would need to set up multiple tor clients sandboxed with cherrypicked `ExcludeNodes` i.e using `curl https://onionoo.torproject.org/details 2>/dev/null | jq -r '.relays[] | select(.observed_bandwidth <= 1310720) | .or_addresses' | grep -oP "^\s+\"(\w+\.\w+\.\w+\.\w+\:\w+)" | sed "s/^ \"//gm" | tr '\n' ','` (Tool from https://github.com/Krey-s-Tor/torrc/blob/master/src/ExcludeSlowRelays.conf) to exclude slow tor relays that would be limiting the Tor DDoS/DoS then set up a loop that runs something alike `pidof tor | xargs sudo kill -HUP ` to generate a new routes which based on my unreliable and questionable experiment (so the experiment should be verified) would take 100mbps upload into 8mbps attack in which case it's much more efficient to perform the attack from a clearweb not to mension that such changes to the Tor are going to make the attacker fingerprintable and sacrifice anonymity. But if you are still concerned about Tor halting your system then you can rate limit it by using: ``` # Bandwidth limiters BandwidthRate 125 KB # Throttle traffic to 125KB/s 1000Kbps) ``` So even if attacker takes down Tor (very unlikely) you can still have working system and if that it not enough to you then the application itself should be optimized on DDoS/DoS i.e the registration which torproject suggest[1] to make proof-of-work which is for example implemented on Hackint.org[4]. And if that is still not enough to you i would recommend Linux kernel with MuQSS scheduler from weebo dentist CK which shown[5][6] to be much more difficult to made halt and to be more efficient in handling the load on systems with more then 4 threads at the cost of generating more heat (optimizable) and requiring more electricity compared to Complitely Fair Scheduler (CFS). Based on my experience MuQSS is more economical in commercial application as it allows the system the have a reliable scheduler as CFS likes to halt and get confused too much. I've also linked an utility to test the system agains tor DDoS/DoS[3] ### References 1. Bug in tor allowing DDoS https://trac.torproject.org/projects/tor/ticket/29607 2. Referenced from torproject to handle DDoS on hidden services https://blog.torproject.org/stop-the-onion-denial 3. Tool used to perform the DDoS attack through Tor https://github.com/r3nt0n/torDDoS 4. Proof-of-work is for example utilized on hackint.org https://www.hackint.org/transport/tor 5. Reference to liquorix kernel https://liquorix.net/ 6. Benchmark of CFS vs MUQSS https://openbenchmarking.org/result/2005044-NI-SMALLPT1752&hgv=kernel+5.3.14%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss&rmm=kernel+5.3.14%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss&hnr=1&hni=1&swl=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6&hnr=1&hni=1&sgm=1&swl=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6&hnr=1&hni=1&sgm=1&swl=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=Arch+5.4.8&hnr=1&hni=1&scalar=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2C5.6-tkg-acpi-pbo%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6
hw commented 1 month ago
Owner

To clarify once again: if one or more contributors volunteer to sponsor/setup/run the required infrastructure, we will happily endorse this. It is just that nobody raised his hand yet to commit.

^^^^^^^^^^^^^^^^^^^^^^^^ once again: this. ^^^^^^^^^^^^^^^^^^^^^^^^^^

Right now it’s just extra burden of an additional project nobody had the time to pick up yet: as soon a volunteer Codeberg e.V. member steps up and takes responsibility for set-up and maintenance of a properly isolated VM running the onion protocol translation, we can do this :)

> To clarify once again: if one or more contributors volunteer to sponsor/setup/run the required infrastructure, we will happily endorse this. It is just that nobody raised his hand yet to commit. ^^^^^^^^^^^^^^^^^^^^^^^^ once again: this. ^^^^^^^^^^^^^^^^^^^^^^^^^^ Right now it's just extra burden of an additional project nobody had the time to pick up yet: as soon a volunteer Codeberg e.V. member steps up and takes responsibility for set-up and maintenance of a properly isolated VM running the onion protocol translation, we can do this :)
kreyren commented 1 month ago

Like i am willing to fork https://github.com/rixotstudio/server-setup (namely https://github.com/RiXotStudio/server-setup/blob/master/src/sefunc/00-tor.sh) set up for codeberg’s usage if wanted (this would be set as an isolated busybox instance), but making Tor in VM makes no sense to me for reasons provided.

Please justify usage of VM and check if proposed solution is sufficient for codeberg.

Like i am willing to fork https://github.com/rixotstudio/server-setup (namely https://github.com/RiXotStudio/server-setup/blob/master/src/sefunc/00-tor.sh) set up for codeberg's usage if wanted (this would be set as an isolated busybox instance), but making Tor in VM makes no sense to me for reasons provided. Please justify usage of VM and check if proposed solution is sufficient for codeberg.
ashimokawa commented 1 month ago
Owner

@kreyren

Putting this inside a VM would allow us to hand over the administration task to someone else without giving access to the main server.

@kreyren Putting this inside a VM would allow us to hand over the administration task to someone else without giving access to the main server.
kreyren commented 1 month ago

@ashimokawa Why though? Tor doesn’t require babysitting if you are not a relay operator (which you should if you have a spare bandwith where the relay administration is also maintainance friendly).

Basically just configuring it once and letting the system package manager to keep it up to date is enough in my mind.

I would think that keeping it inside a VM container and outsourcing it is a really bad idea in terms of privacy as then tor would have to rely on the security of the VM container and it’s configuration and would probably expose the traffic to the container maintainer which is generally unwanted as the service should be always maintained by the upstream and as it’s a VM container it requires much more processing power.

@ashimokawa Why though? Tor doesn't require babysitting if you are not a relay operator (which you should if you have a spare bandwith where the relay administration is also maintainance friendly). Basically just configuring it once and letting the system package manager to keep it up to date is enough in my mind. I would think that keeping it inside a VM container and outsourcing it is a really bad idea in terms of privacy as then tor would have to rely on the security of the VM container and it's configuration and would probably expose the traffic to the container maintainer which is generally unwanted as the service should be always maintained by the upstream and as it's a VM container it requires much more processing power.
kreyren commented 1 month ago
Relevant: https://github.com/go-gitea/gitea/issues/12876
jscott commented 1 month ago

@ashimokawa Why though? Tor doesn’t require babysitting if you are not a relay operator

Basically just configuring it once and letting the system package manager to keep it up to date is enough

As someone who takes interest in onion services and in particular has seen Debian’s smooth rollout of them, I must affirm @kreyren’s point that running an onion service is primarily one-time setup and I suspect that there’s misunderstanding, or conflation with the concept of Tor relays.

Because onion sites don’t use TLS, there’d be no way to distinguish a phishing Codeberg onion service from the genuine one if it were not operated by the same entity. In fact you’d be letting an outside party have your secret key to the .onion pseudo-domain name.

The overhead of the Tor daemon is much lesser than any web server, because as the hidden service operator you’re only the last hop. I believe the Tor daemon can even use Unix sockets to connect to supporting services, but that might’ve been a dream.

Lastly, onion-ifying Codeberg may go beyond the website. Take things one step at a time, but SSH over Tor would be appreciated as well. (Since onions are encrypted end-to-end, telnet would actually be safe enough.)

Edit: Here are a couple brief primary sources. Here’s the complete instructions to start a service, and here’s a post about the Tor Project’s #MoreOnionsPorFavor campaign. This explicitly called for users to contact their favorite websites and explains the rationale of providing more privacy-preserving and secure options.

Your questions would also be very welcome on the tor-onions list.

> @ashimokawa Why though? Tor doesn't require babysitting if you are not a relay operator > > Basically just configuring it once and letting the system package manager to keep it up to date is enough As someone who takes interest in onion services and in particular has seen Debian's [smooth rollout of them](https://onion.debian.org), I must affirm @kreyren's point that running an onion service is primarily one-time setup and I suspect that there's misunderstanding, or conflation with the concept of Tor relays. Because onion sites don't use TLS, there'd be no way to distinguish a phishing Codeberg onion service from the genuine one if it were not operated by the same entity. In fact you'd be letting an outside party have your secret key to the .onion pseudo-domain name. The overhead of the Tor daemon is much lesser than any web server, because as the hidden service operator you're only the last hop. I believe the Tor daemon can even use Unix sockets to connect to supporting services, but that might've been a dream. Lastly, onion-ifying Codeberg may go beyond the website. Take things one step at a time, but SSH over Tor would be appreciated as well. (Since onions are encrypted end-to-end, telnet would actually be safe enough.) Edit: Here are a couple brief primary sources. [Here's the complete instructions to start a service](https://community.torproject.org/onion-services/setup/), and here's a post about the Tor Project's [#MoreOnionsPorFavor campaign](https://blog.torproject.org/more-onions-porfavor). This explicitly called for users to contact their favorite websites and explains the rationale of providing more privacy-preserving and secure options. [Your questions would also be very welcome on the tor-onions list.](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions)
kreyren commented 1 month ago

Take things one step at a time, but SSH over Tor would be appreciated as well. (Since onions are encrypted end-to-end, telnet would actually be safe enough.)

Can recommend SSH over tor as well i use it daily and it’s great ^-^

Note that there is a delay on SSH over tor (in general tor adds delay of around 120ms) for which you might need to adapt your client if you are using it interactively and i woudn’t recommend it for things that need fast responsivness i.e using emacs this way, but it can also be made work on bases of emulating the terminal locally and then sending the commands to the remote.

Would be great for SSH clonning and submitting merges though! and very welcomed!

I could also recommend it for the mailserver as on clearweb there is an issue with people sniffing the traffic to know where you are sending the e-mails and to whom which is generally unwanted in commercial use for business reasons and commonly abused for targeted advertising.

> Take things one step at a time, but SSH over Tor would be appreciated as well. (Since onions are encrypted end-to-end, telnet would actually be safe enough.) Can recommend SSH over tor as well i use it daily and it's great ^-^ Note that there is a delay on SSH over tor (in general tor adds delay of around 120ms) for which you might need to adapt your client if you are using it interactively and i woudn't recommend it for things that need fast responsivness i.e using emacs this way, but it can also be made work on bases of emulating the terminal locally and then sending the commands to the remote. Would be great for SSH clonning and submitting merges though! and very welcomed! I could also recommend it for the mailserver as on clearweb there is an issue with people sniffing the traffic to know where you are sending the e-mails and to whom which is generally unwanted in commercial use for business reasons and commonly abused for targeted advertising.
6543 commented 1 month ago
Collaborator

@kreyren report tor gateway integration upstream ... wont help anyone

this has to be configured by instance admins/maintainers ...

@kreyren report tor gateway integration upstream ... wont help anyone this has to be configured by instance admins/maintainers ...
hw commented 1 month ago
Owner

yes, not part of gitea

yes, not part of gitea
kreyren commented 1 month ago

@kreyren report tor gateway integration upstream ... wont help anyone @6543

Disagree as the concern was mainly about (D)DoS which Gitea is seemingly vulnerable to atm for example nothing prevents bad actors:

  • from setting up a browser macro to create X amount of accounts at the same time and denying the registration process
  • in uploading X amount of GB per second and overwhelming the server which would deny: closing, merge requests, resolving of merge requests and other git related functions
  • from creating X amount of repositories per second which would deny probably the main server
  • spamming the issues which would probably deny the server’s ability to submit messages in tickets
  • Etc..

See https://github.com/go-gitea/gitea/issues/12876 where upstream just panics irationally about the subject of (D)DoS and does it’s best to close the issue as fast as possible..

this has to be configured by instance admins/maintainers ... @6543

Agree, but @hw mentioned a concern about (D)DoS (which is unlikely and not realistic to be performed through Tor after a bug that allowed the execution efficiently has been fixed) so i am trying to provide the required information to make Gitea less susceptible to it.

> @kreyren report tor gateway integration upstream ... wont help anyone @6543 Disagree as the concern was mainly about (D)DoS which Gitea is seemingly vulnerable to atm for example nothing prevents bad actors: - from setting up a browser macro to create X amount of accounts at the same time and denying the registration process - in uploading X amount of GB per second and overwhelming the server which would deny: closing, merge requests, resolving of merge requests and other git related functions - from creating X amount of repositories per second which would deny probably the main server - spamming the issues which would probably deny the server's ability to submit messages in tickets - Etc.. See https://github.com/go-gitea/gitea/issues/12876 where upstream just panics irationally about the subject of (D)DoS and does it's best to close the issue as fast as possible.. > this has to be configured by instance admins/maintainers ... @6543 Agree, but @hw mentioned a concern about (D)DoS (which is unlikely and not realistic to be performed through Tor after a bug that allowed the execution efficiently has been fixed) so i am trying to provide the required information to make Gitea less susceptible to it.
hw commented 1 month ago
Owner

[...] (D)DoS which Gitea is seemingly vulnerable [...]

(D)DOS protection currently handled in haproxy and fail2ban

> [...] (D)DoS which Gitea is seemingly vulnerable [...] (D)DOS protection currently handled in haproxy and fail2ban
kreyren commented 1 month ago

Note: The (D)DoS tests performed locally using sandboxing and limiting available system resources to Gitea sandbox which might not represent the same behavior in the wild.

Note: The (D)DoS tests performed locally using sandboxing and limiting available system resources to Gitea sandbox which might not represent the same behavior in the wild.
hw commented 1 month ago
Owner

nothing prevents bad actors [...]

Yes, there will always be good folks and bad guys. We need to find a good balance so that the latter cannot harm the former, without restricting general use. In the past this worked very well. Let’s do the best to keep it like this for the future!

> nothing prevents bad actors [...] Yes, there will always be good folks and bad guys. We need to find a good balance so that the latter cannot harm the former, without restricting general use. In the past this worked very well. Let's do the best to keep it like this for the future!
6543 commented 1 month ago
Collaborator

@kreyren just panics irationally ...

I would not say that, the issue tracker is just not subject to broad conversations
https://discourse.gitea.io/ is the platform you are looking for

@kreyren ` just panics irationally` ... I would not say that, the issue tracker is just not subject to broad conversations https://discourse.gitea.io/ is the platform you are looking for
kreyren commented 1 month ago

@hw Fail2ban can be avoided using a dynamically allocated IP adress from the ISP (some people are their own ISP so this is really easy for them to change) or using proxies or Tor.

haproxy can be allegedly overwhelmed as well depending on the amount of proxy servers (and their state) that do the load balancing.

In my mind the best defense agains (D)DoS is to adapting the software to sanitize the tasks that can be abused for the (D)DoS.

For example: if someone tries to create more then X accounts per minute then set a timeout for that region and process only 100 registration request per Z amount of time. So that end-users trying to make an account would be waiting in line for the server to process their registration request which seemed to work well in the wild.

@hw Fail2ban can be avoided using a dynamically allocated IP adress from the ISP (some people are their own ISP so this is really easy for them to change) or using proxies or Tor. haproxy can be allegedly overwhelmed as well depending on the amount of proxy servers (and their state) that do the load balancing. In my mind the best defense agains (D)DoS is to adapting the software to sanitize the tasks that can be abused for the (D)DoS. For example: if someone tries to create more then X accounts per minute then set a timeout for that region and process only 100 registration request per Z amount of time. So that end-users trying to make an account would be waiting in line for the server to process their registration request which seemed to work well in the wild.
hw commented 1 month ago
Owner

I am sure every sound contribution to gitea the improves application-level service robustness will be highly welcome, both at codeberg and gitea!

I am sure every sound contribution to gitea the improves application-level service robustness will be highly welcome, both at codeberg and gitea!
kreyren commented 1 month ago

About fail2ban there are apparently a paid services that provide a user-friendly environment to change the IP adresses within miliseconds so if codeberg is high value target do bad actors this would be an option for them.

About fail2ban there are apparently a paid services that provide a user-friendly environment to change the IP adresses within miliseconds so if codeberg is high value target do bad actors this would be an option for them.
hw commented 1 month ago
Owner

:) we can always think of worse scenarios ... just if we focus exclusively on what-could-be instead of what-is we will get nothing done ;)

Again: a properly done PR solving actual issues is always welcome!

:) we can always think of worse scenarios ... just if we focus exclusively on what-could-be instead of what-is we will get nothing done ;) Again: a properly done PR solving actual issues is always welcome!
kreyren commented 1 month ago

I am sure every sound contribution to gitea the improves application-level service robustness will be highly welcome, both at codeberg and gitea! @hw

Disagree that gitea upstream wants them for reasons provided, would be willing to make tracking in Codeberg/gitea to handle these concerns, but i would process them with low priority as these are currently not that important to be implemented and codeberg doesn’t seem to be a target for bad actors. If that’s fine with you? ^-^

Ideally would like to focus on implementing Tor for now.

> I am sure every sound contribution to gitea the improves application-level service robustness will be highly welcome, both at codeberg and gitea! @hw Disagree that gitea upstream wants them for reasons provided, would be willing to make tracking in Codeberg/gitea to handle these concerns, but i would process them with low priority as these are currently not that important to be implemented and codeberg doesn't seem to be a target for bad actors. If that's fine with you? ^-^ Ideally would like to focus on implementing Tor for now.
kreyren commented 1 month ago

I would not say that, the issue tracker is just not subject to broad conversations
https://discourse.gitea.io/ is the platform you are looking for @6543

Noted, should be probably adjusted in github template for issues and contributing file then as there is currently no way of knowing the development process in gitea as a new contributor..

Also it’s kinda insane to resolve these in a forum as the merge requests should have tracking to the issue where the feature was discussed for reference if needed and the forum doesn’t seem to be a good place to resolve code quality issues.

But IMHO upstream that bans the contributors without reasoning is not worth my time investing so i would still prefer to put these in Codeberg/Gitea for you to handle the upstream.


just if we focus exclusively on what-could-be instead of what-is we will get nothing done ;) @hw

So what is preventing you from deploying tor based on informations provided in #50 ? :p

> I would not say that, the issue tracker is just not subject to broad conversations https://discourse.gitea.io/ is the platform you are looking for @6543 Noted, should be probably adjusted in github template for issues and contributing file then as there is currently no way of knowing the development process in gitea as a new contributor.. Also it's kinda insane to resolve these in a forum as the merge requests should have tracking to the issue where the feature was discussed for reference if needed and the forum doesn't seem to be a good place to resolve code quality issues. But IMHO upstream that bans the contributors without reasoning is not worth my time investing so i would still prefer to put these in `Codeberg/Gitea` for you to handle the upstream. --- > just if we focus exclusively on what-could-be instead of what-is we will get nothing done ;) @hw So what is preventing you from deploying tor based on informations provided in https://codeberg.org/Codeberg/Community/issues/50#issuecomment-80942 ? :p
hw commented 1 month ago
Owner

So what is preventing you from deploying tor based on informations provided in #50 ? :p

extra setup+maintenance effort someone has to volunteer for

> So what is preventing you from deploying tor based on informations provided in #50 ? :p extra setup+maintenance effort someone has to volunteer for
kreyren commented 1 month ago

I volunteer

#!/bin/sh
# shellcheck shell=sh # Written to be POSIX-compatible

# Quick-script created by Jacob Hrbek <kreyren@rixotstudio,cz> under GPLv3 license <https://www.gnu.org/licenses/gpl-3.0.en.html> in 18/09/2020-EU 09:01:31 CEST

set -e

die() { printf '%s\n' "$2"; exit "$1" ;}

# Root check
[ "$(id -u)" = 0 ] || die 3 "Insufficient permisson, reinvoke as root"

# Check if we have uname to identify the kernel
command -v uname 1>/dev/null || die 1 "Command 'uname' is not available"

# Define kernel in KERNEL variable
KERNEL="$(uname -s)"

# Define distribution in DISTRO variable
if [ -f /etc/os-release ]; then
	DISTRO="$(cat /etc/os-release | grep "^ID=.*" | sed "s/ID\=//")"
	[ -n "$DISTRO" ] || die 1 "Unable to determine the distribution used"
elif [ ! -f /etc/os-release ]; then
	die 1 "Standard file '/etc/os-release' is not available"
else
	die 255 "os-release unexpected"
fi

# Get The Onion Router!
case "$KERNEL/$DISTRO" in
	"linux/debian" | "linux/ubuntu" | "linux/devuan")
		apt-get update || true
		apt-get install tor || exit 1
	;;
	"linux/fedora" | "linux/RHEL")
		dnf install tor || exit 1
	;;
	"linux/gentoo")
		emerge --sync
		emerge net-vpn/tor
	;;
	*) die 26 "Unimplemented combination of kernel '$KERNEL' and distribution '$DISTRO'"
esac

# Configure the tor for codeberg
case "$KERNEL/$DISTRO" in
	"linux/*")
		cat <<-EOF > /etc/tor/torrc
			# Provide Codeberg as hidden service
			HiddenServiceDir /var/lib/tor/codeberg/
			HiddenServicePort 3000 127.0.0.1:3000
		EOF
	;;
	*) die 26 "Unimplemented combination of kernel '$KERNEL' and distribution '$DISTO' to find torrc"
esac
I volunteer ```sh #!/bin/sh # shellcheck shell=sh # Written to be POSIX-compatible # Quick-script created by Jacob Hrbek <kreyren@rixotstudio,cz> under GPLv3 license <https://www.gnu.org/licenses/gpl-3.0.en.html> in 18/09/2020-EU 09:01:31 CEST set -e die() { printf '%s\n' "$2"; exit "$1" ;} # Root check [ "$(id -u)" = 0 ] || die 3 "Insufficient permisson, reinvoke as root" # Check if we have uname to identify the kernel command -v uname 1>/dev/null || die 1 "Command 'uname' is not available" # Define kernel in KERNEL variable KERNEL="$(uname -s)" # Define distribution in DISTRO variable if [ -f /etc/os-release ]; then DISTRO="$(cat /etc/os-release | grep "^ID=.*" | sed "s/ID\=//")" [ -n "$DISTRO" ] || die 1 "Unable to determine the distribution used" elif [ ! -f /etc/os-release ]; then die 1 "Standard file '/etc/os-release' is not available" else die 255 "os-release unexpected" fi # Get The Onion Router! case "$KERNEL/$DISTRO" in "linux/debian" | "linux/ubuntu" | "linux/devuan") apt-get update || true apt-get install tor || exit 1 ;; "linux/fedora" | "linux/RHEL") dnf install tor || exit 1 ;; "linux/gentoo") emerge --sync emerge net-vpn/tor ;; *) die 26 "Unimplemented combination of kernel '$KERNEL' and distribution '$DISTRO'" esac # Configure the tor for codeberg case "$KERNEL/$DISTRO" in "linux/*") cat <<-EOF > /etc/tor/torrc # Provide Codeberg as hidden service HiddenServiceDir /var/lib/tor/codeberg/ HiddenServicePort 3000 127.0.0.1:3000 EOF ;; *) die 26 "Unimplemented combination of kernel '$KERNEL' and distribution '$DISTO' to find torrc" esac ```
hw commented 1 month ago
Owner

it’s not a one-time effort (monitor, adjust throttling if necessary, fight spammers through the channel etc)

it's not a one-time effort (monitor, adjust throttling if necessary, fight spammers through the channel etc)
kreyren commented 1 month ago

Concluded throttling not neccesary atm, can be adjusted using BandwidthRate as mentioned in #50.

How do you want to handle the monitoring?

How do you want to fight spammers?

EDIT: Added reference on BandwidthRate

Concluded throttling not neccesary atm, can be adjusted using `BandwidthRate` as mentioned in https://codeberg.org/Codeberg/Community/issues/50#issuecomment-80942. How do you want to handle the monitoring? How do you want to fight spammers? EDIT: Added reference on `BandwidthRate`
jscott commented 1 month ago

I don’t think I’m understanding why an onion service would increase the risk of DoS or abuse. If an attacker wanted to do that over Tor, couldn’t they connect over the clearnet (codeberg.org) anyway? An onion service would actually improve on this, since it would add three additional hops.

I don't think I'm understanding why an onion service would increase the risk of DoS or abuse. If an attacker wanted to do that over Tor, couldn't they connect over the clearnet (codeberg.org) anyway? An onion service would actually improve on this, since it would add three additional hops.
6543 commented 1 month ago
Collaborator

☝️

:point_up:
kreyren commented 1 month ago

I don’t think I’m understanding why an onion service would increase the risk of DoS or abuse... @jscott

Note that explained in: #50

TLDR: i doubt that Tor used for (D)DoS is a viable option for clearweb nor onions as it needs way more processing power to perform the task.

> I don’t think I’m understanding why an onion service would increase the risk of DoS or abuse... @jscott Note that explained in: https://codeberg.org/Codeberg/Community/issues/50#issuecomment-80942 TLDR: i doubt that Tor used for (D)DoS is a viable option for clearweb nor onions as it needs way more processing power to perform the task.
kreyren commented 2 weeks ago

FWIW i’ve helped to set up hidden service for https://git.dotya.ml currently available on http://2crftbzxbcoqolvzreaaeyrod5qwycayef55gxgzgfcpqlaxrnh3kkqd.onion

There are some issues with gitea configuration atm (gitea not replacing clearnet link with hidden) and droneCI (DroneCI blocking hidden as second provider but that seems to be pebcak), but seems to work quite well.

FWIW i've helped to set up hidden service for https://git.dotya.ml currently available on http://2crftbzxbcoqolvzreaaeyrod5qwycayef55gxgzgfcpqlaxrnh3kkqd.onion There are some issues with gitea configuration atm (gitea not replacing clearnet link with hidden) and droneCI (DroneCI blocking hidden as second provider but that seems to be pebcak), but seems to work quite well.
qorg11 commented 20 hours ago

If codeberg is going to have onion address, please make sure it is a v3 onion addresses, v2 onion addresses are getting deprecated next years and i associate them with honeypots

If codeberg is going to have onion address, please ***make sure*** it is a v3 onion addresses, v2 onion addresses are getting deprecated next years and i associate them with honeypots
Sign in to join this conversation.
No Milestone
No Assignees
10 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.