Build with CGO_ENABLED=0

[silverwind]

Feature Description

We should aim to build with CGO_ENABLED=0, which brings benefits:

• The resulting binary is statically linked and can run inside docker from: scratch images, which is ideal for security and image size because it only has the binary in the container, nothing else.
• xgo can be removed because without CGO, go can cross-compile everything itself.
• When CGO is enabled, go will switch to a suboptimal and toolchain and afaik also produce suboptimal binaries.

What are the remaining dependencies here? Just sqlite, or is there more?

[wxiaoguang]

The only blocker is sqlite.

• 20614

(actually, I have somewhat objection for using that CCGO based sqlite package in Gitea)

I do not need sqlite, so I can perfectly cross compile Gitea on my macOS and deploy it to my Linux servers.

[silverwind]

There is https://github.com/glebarez/go-sqlite, not sure how stable it is though, but I guess if it survives a few runs in our CI, it should be good enough for a spin.

[wxiaoguang]

Are we willing to take the risk of a complex essential core library getting unmaintained (some unfixable bugs)?

[lunny]

There are two build tags SQLite and pam. Both are optional for build from source. So we are discussing the official release.

Since Gitea with SQLite are welcome by many individuals users. I don't think we should provide the official binaries without SQLite support.

[lunny]

There is https://github.com/glebarez/go-sqlite, not sure how stable it is though, but I guess if it survives a few runs in our CI, it should be good enough for a spin.

It's the same as our PR

[silverwind]

Are we willing to take the risk of a complex essential core library getting unmaintained?

SQLite is popular enough to ensure there will always be some kind of pure-go solution around.

[wxiaoguang]

The problem is, SQLite is popular doesn't mean its pure-go solution is popular (actually, most people do not need the pure-go solution).

Git is much more popular than sqlite, but gogit is far from complete.

[silverwind]

Git is also much more complicated than SQLite I assume. Probably by a factor of 10.

[zeripath]

I'm just putting a note here to say we already can build with CGO_ENABLED=0 - in fact it's part of our test suite. There are costs though:

• No SQLite
• No PAM

[wxiaoguang]

Git is also much more complicated than SQLite I assume. Probably by a factor of 10.

At least I can see gogit is used by some apps but I doubt whether pure-go-sqlite is battle-tested.

I would still question whether it's worth to use CCGO in Gitea. What if there is an unfixable bug?

• If we use a 3rd go package, even if there is a bug, we can fork and fix.
• But if there is a bug in CCGO related package, how to fix it? I don't have the time to patch the CCGO compiler ....

If CCGO pakcage has been proven to be stable enough, then I have no objection.

[lunny]

I'm just putting a note here to say we already can build with CGO_ENABLED=0 - in fact it's part of our test suite. There are costs though:

* No SQLite

* No PAM

Maybe we can close this issue or we can change the title like Support sqlite without CGo ?

[silverwind]

What features is PAM used for? At least I don't see it as on option for authentification sources.

[wxiaoguang]

• 13257

• 16639

• 19249

and more

[silverwind]

IDK how PAM integration was done, but it does seem it should be its own authentification source, which could be made to require specific build tag, like sqlite. Maybe this is already the case. Or maybe there are native Go PAM modules.

[lunny]

In fact, for our current build progress(with xgo), we can build linux official release with the PAM tag which is different from other OS. But for the future, if we want to remove xgo, we may don't want to do that.

[p0da]

Disregarding the PAM issue, which is of limited concern on single tenant systems with only basic auth configured (something that I presume quite a few Gitea instances are) could we look further into this issue? @lunny

Not sure how difficult the go-sqlite integration would be but the opt-in capability to run a fully static binary would be very useful, especially in the containerization space.

[lunny]

For the default official binary, PAM is not enabled. So the only CGO is from sqlite. Users can build a pure Go binary from source without sqlite support from day 1. But for official binary, we want to support many personal developers/small teams who don't want to install database.

[p0da]

@lunny Sorry for the confusion, to clarify I am referring to adding the opt-in capacity to use go-sqlite instead of linked against sqlite through CGO. That is all, this does not have to be shipped in the official binary.

[lunny]

To keep the compatible old version, I think making the default official binary without sqlite support will break some Gitea instances.

[p0da]

You are likely correct, that is why I said it should be an opt-in feature. Advanced users could enabled it at compile time through build tags allowing for the deployment of gitea without a bundled libc.

[lunny]

Yes. It's ready from day one. TAGS="bindata" make build will generate a Gitea binary without sqlite support. And you can also use GOOS=linux GOARCH=arm64 TAGS="bindata" make build for cross-compiling.

Since we cannot remove sqlite tag in a short term, maybe we can have a try by zig for cross-compiling with CGO. https://docs.gitea.com/installation/install-from-source#compile-or-cross-compile-using-linux-with-zig