Ask HN: Any ways to make Gitea safer for my private projects?
Having hard coded database password is insane. If my linode is hacked, then the password will be seen
20 comments
Now here is something I'm wondering. Why not just install Gitea locally? I run it on my Mac Mini and I can access it from any computer in my local network. And maybe also consider rethinking what you're using git itself for. Gitea might not be the whole problem here. I personally would never put a gitea on the world wide web just for personal private projects. That would mean that it would be completely up to me to manage that security and I'm not really sure of any upsides on that.
Also a quick Google brought this up https://book.hacktricks.xyz/cloud-security/gitea-security
Also a quick Google brought this up https://book.hacktricks.xyz/cloud-security/gitea-security
Have you filed an issue with gitea about this? Accepting a bcrypt/scrypt/etc hashed password via ENV is likely a like… <4 hour pull request for the project
While there are solutions here, generally an app needs to have the actual database password or the ability to create one. A bcrypt of the password just won’t let the gitea server connect.
You can only limit the access. For example: limit access for other users than gitea to the config including sshd. Limiting the data that can be accessed with the databasepassword. Gitea doesn't need access to your wordpress.
using an sso can also help: in this case gitea doesn't even have the password.
If someone hack my linode, they can be gitea user?
I'm not sure I understand the concern. If they have shell access to your linode they already have access to everything - even if your db password were encrypted gitea can communicate with the db and so can any attacker coming from that system.
yes they can, but the risk is relative low.
SSH-Auth should be only over keypairs,2fa should be on for your account and then most attacks should be unsuccessful.
I bought Yubikey recently. Should be usable
I will be doomed if there is RCE?
Golang is relative save in case of rces. The only problem is git with its hooks, but you need authentication to do harm. Gitea would rather crash than giving access to the attacker.
git server are not really in danger.
Unless you have very private data in your private repos: no
if you have your bankaccount password, your ssn or similar important data in your git repos: yes, but its your fault
Is it stored in plain text? If it uses scrypt / argon2 / pbkdf2 it is enough. Also, you may simply use a randomly generated password so your other accounts wont be hacked if someone hacks your linode server.
If I'm not mistaken gitea stores codebases/projects on the filesystem, so having a hardcoded database password makes no difference. If someone gets into the server they can simply copy the files without touching the database.
As others have indicated, a VPN server of your choosing (openvpn/wireguard) can solve your issues. Even if at some point there's an "unauthenticated RCE" exploit for gitea, having it behind a VPN will mitigate that.
As others have indicated, a VPN server of your choosing (openvpn/wireguard) can solve your issues. Even if at some point there's an "unauthenticated RCE" exploit for gitea, having it behind a VPN will mitigate that.
They can get my username and tokens from the db
If your linode is hacked, the attacker doesn't need your database password anymore...
The database password is irrelevant unless your database is exposed to an attacker - if it is, you've not set your system up correctly.
Your first line of security should be the perimeter - preventing access to services which aren't needing exposed (like databases).
Then you should consider your exposed attack surfaces you can't avoid - the SSH interface for git over SSH, and the HTTPS interface for web access.
You could protect the HTTPS interface by requiring a client certificate before allowing a connection, by using a reverse proxy like nginx or caddy. If you do this, make sure your underlying gitea web server isn't accessible from outside of the server (e.g. via another port).
For the SSH interface, look at whether you are using the system SSH instance, or another one - if you run gitea via docker, you can have an isolated SSH instance running on a separate IP (or port) from your underlying system, and limit the risk of a compromise.
But don't overlook the simplest issues - using weak or re-used user passwords, not using MFA, using passwords for SSH. At a certain point, your VPS is probably more vulnerable to attack through your regular management SSH access, or the customer portal of your VPS provider.
Your first line of security should be the perimeter - preventing access to services which aren't needing exposed (like databases).
Then you should consider your exposed attack surfaces you can't avoid - the SSH interface for git over SSH, and the HTTPS interface for web access.
You could protect the HTTPS interface by requiring a client certificate before allowing a connection, by using a reverse proxy like nginx or caddy. If you do this, make sure your underlying gitea web server isn't accessible from outside of the server (e.g. via another port).
For the SSH interface, look at whether you are using the system SSH instance, or another one - if you run gitea via docker, you can have an isolated SSH instance running on a separate IP (or port) from your underlying system, and limit the risk of a compromise.
But don't overlook the simplest issues - using weak or re-used user passwords, not using MFA, using passwords for SSH. At a certain point, your VPS is probably more vulnerable to attack through your regular management SSH access, or the customer portal of your VPS provider.
I am using SQLite. Is this unsafe?