Gogs, Gitea, Forgejo

Mon, 18 Dec 2023 00:00:00 +0000

I’ve been really pleased with Gogs - it’s lightweight, was simple to spin up, and has worked perfectly. But then this morning on Mastodon, there’s a post from @Codeberg.org describing a security vulnerability in their Git hosting project Forgejo. This issue also apparently affects Gitea and Gogs - what’s up with that?

I actually already did spend a bit of time comparing Gogs and Gitea before deciding on Gogs, since I’d heard of people running Gitea over the past year or so, but only seen that Gogs seemed to be popular with self-hosters in a Lemmy post I’d read. My first impression was that Gitea was more focused on CI/CD and seemed to have a more complicated install process.

What I didn’t do, was think about the project management and teams. It turns out that Gitea was forked from Gogs by contributors in 2016 due to disagreements about the project management. Then at the end of 2022 Forgejo was forked from Gitea due to Gitea moving the trademarks and domain into a company providing Gitea support.

The CVE announcement from Forgeo, while a little snarky about their ancestors, does give the impression of a functional organisation that’s able to deal with issues as they come up. It’s a credit to the group to be in that position after just a year, and their repo (which is dogfooded) seems plenty active.

I’ve only just started on Gogs, so it’s still easy to move if that’s what I decide. I guess my learning from stumbling upon this security announcement is more that I should:

take into account more than just project features when making these decisions
I need to be subscribed to the channels where I’d learn about security issues in the projects I’m using and their major dependencies.

Gogs - your own tiny GitHub

Wed, 06 Dec 2023 00:00:00 +0000

(edit: - I’ve had a rethink about my source hosting)

Once you’re familiar with coding tools, like the excellent VS Code, and git, it’s immediately apparent that these tools can be applicable for other purposes. A great example is that I now do my financial accounting in plain text (using beancount). I have a python script that converts by bank account data in to the beancount format text files, I edit them in VS Code with a plugin that does the syntax highlighting and checks everything balances.

Naturally, I want to version control that, so my text based accounts are all committed to git. But I don’t really want to push them up to GitHub, even to a private repo. I want to push them to a git server that’s available for me to pull down from anywhere, and is backed up with all my other data.

It actually is possible to run a git server to do this with vanilla git, and I’m sure that’s how the hairy chested sysadmins of old do it. But I want a web gui a bit like GitGub that I’m familiar with. Of course, GutHub does all that other sweet stuff like CI/CD, but I don’t need that for my accounts.

There are a couple of popular options for this job, one is Gitea which does lean into that CI/CD functionality, and the other is Gogs, which being a bit simpler, is also a bit simpler to get going. When I say simpler, it’s still massive overkill for my needs - you can have thousands of users, do pull requests, track issues, write project wikis - all that good stuff. It also has webhooks so you can knit together a pipeline with drone.io, Jenkins or other CI/CD tools. So I went with Gogs

Installing

It’s not mentioned on the install page for Gogs, but there is an official container build. Possibly this is because there’s a couple of rough edges that I’ll get to shortly. I’ve talked before about how I like to run services in Docker on LXC, so I won’t go over that again. Here’s my docker-compose:

version: '3'

services:
 gogs:
 image: gogs/gogs
 container_name: gogs
 ports:
 - "23:22"
 - "80:3000"
 volumes:
 - ./data:/data
 restart: always

However, there is a gotcha I hadn’t encountered before - when I docker compose up with this, I got the error “failed to register layer: unlinkat /app/gogs/docker/build: invalid argument”.

When I asked ChatGPT about this, she thought it might be to do with the storage driver. I didn’t know what that was so I spent time googling around.

Pretty soon, I discovered this thread. Part way down there’s the suggestion to edit /etc/docker/daemon.json to add a different storage driver, followed by many comments of “Thanks!” and “That fixed it”. I followed that advice, (it uses a different driver “vfs” rather than “aufs” as suggested by ChatGPT) and then the container came up properly.

With that out of the way, and the container live, if you go to the port you’ve specified in the docker-compose file (mine was :80), you’ll be greeted with the “Install Steps For First-time Run”.

They are not joking. You won’t be able to guess these settings. I guess they haven’t put a lot of work into the container experience - some of these settings need to be for inside the container, and some are used for prompting the user, which are outside of the container settings. I suspect this rough edge is why the container install is not on the Gogs website yet.

Anyway, after I’d ignored this suggestion, run into problems, google them, found closed issues where people had had the same problem and the devs pointed them to the perfectly clear guidelines we hadn’t read…

I’ll leave you to read the guidelines. The only other things of note is that I used the SQLite database to make my life simpler, and you don’t need to muck around making an admin account - it just makes the first person to log in the admin. Once that’s all done, you have to create a user account, then log in with it. You’ll be greeted by a reasonably familiar sight.

If you go ahead and create a repository in Gogs, it will give you the commands to push a repo up:

So let’s do that:

The back in our repo on Gogs:

Gogs on blog.iankulin.com

Gogs, Gitea, Forgejo

Gogs - your own tiny GitHub

Installing