possible to make a gitea version that's focused purely on security?

[ouvaa]

Feature Description

1. how secure is gitea for putting it out online?
2. possible to provide a security hardened military grade version of gitea to be put front facing online?

Screenshots

No response

[delvh]

Please elaborate exactly what you mean by that.

Also, why should there be security hardened military grade version? Why shouldn't all instances have the same security features?

[wxiaoguang]

It really depends and impossible for anything to be pure secure.

Golang has bugs (then Gitea needs to use the fixed Golang to compile). Every software you are using including Linux kernel could have security bugs.

For Gitea, every problem in security report gets fixed in first time. And if you'd like to help, you could also to audit the source code and help for the security related problems.

---

Update: if you mean to have some special supported LTS versions (like some big/commercial softwares), I think Gitea doesn't have the manpower at the moment. So Gitea only maintains one active stable release with in-time security fixes.

[ouvaa]

@wxiaoguang @delvh i see plenty features of gitea and i'm just wondering if we can have a minimal version that has been thoroughly security audited and is extremely hardened because there are too many hackers and cybersecurity issues in the world today.

[wxiaoguang]

TBH I do not think it is possible for Gitea at the moment. There are a lot of dependencies between these features, and it's impossible to "partially" build Gitea.

For minimal "git" requirement, a SSH server is enough, then only the Linux & SSH & GIT code needs to be hardened.

[techknowlogick]

Gitea is used in many security sensitive industries, such as healthcare, nuclear energy, finance, aviation/aerospace, and more. However, a defence in depth approach is recommended for any service.

[inferenceus]

I have a pretty hardened Gitea server. As stated in previous comments, defense-in-depth is what matters more than a single program/process being secure, since there are always bugs and even sandboxes can have bugs. It's all about what you're trying to protect and what you're willing to sacrifice in terms of usability and performance etc.

Some starting points:

• Enforce firewall rules for fine-grained incoming and outgoing connections, blocking both directions by default unless rules are explicitly added
• Enforce server ciphers to take priority over client ciphers in your web server
• Enforce TLS 1.3 is the only protocol used, so you have perfect forward secrecy among other benefits
• Set the 3 TLS 1.3 ciphersuites to TLS_AES_256_GCM_SHA384:TLS_AES_CHACHA20_POLY1305:TLS_AES_128_GCM_SHA256
• Set ChaCha20-Poly1305 to be preferred for devices without AES hardware-acceleration (AES is vulnerable to side-channel attacks when done via software)
• Enforce only X25519 as your Diffie-Hellman curve
• Ignore invalid headers
• Enforce HSTS to prevent connections over insecure HTTP, allowing only HTTPS with valid certificates which cannot be bypassed or have an exception added for it by web browsers
• Enforce specific key sizes for SSH keys, preferring modern ED25519 over becoming-deprecated RSA
• Sign all commits and tags via SSH keys
• Avoid PGP/GPG (it has many issues and security researchers such as myself wish it would just go away; see here, here, and here)
• Run as many programs as possible as their own users with their own UIDs

The most important rule of security is you are never unhackable. 100% security does not exist, but the more layers you have, the closer you can get to 99.99%.

[GiteaBot]

We close issues that need feedback from the author if there were no new comments for a month. :tea: