2020-02-04_git_response.txt

I decided to switch HardenedBSD to self-hosted git last year in order
to unify our infrastructure. Part of my mentality is one of
self-sustainment. The less HardenedBSD depends on third parties, the
better.

At the risk of sounding hypocritical, I would like to see network
transparency reports from GitHub. I'd like to see network flow
diagrams and system/network hardening procedures.

I also realize that we're still somewhat dependant on GitHub since we
use FreeBSD's git mirror at GitHub as our upstream. And since we sync
with FreeBSD every six hours, we sync from GitHub.

I've run a GitLab server before on both FreeBSD and HardenedBSD. No
complaints about the BSD side of things, but GitLab itself is so
fragile with the vast number of (internet-downloaded?) dependencies
and moving parts. Having that past painful experience to learn from, I
decided that pain wasn't worth it for a project I work on in my spare
time. I'd spend all my time figuring out why GitLab is broken today
instead of spending my time hacking on HardenedBSD.

What if we went with cgit and did patch/issue submission OpenBSD style
via mailing lists? Well, our email is managed by Google. A
not-so-insignificant number of our users dislike our usage of Google.
Thus, by going the "patch submission via email" route, we would
potentially limit community contributions. I'm unsure how sustainable
managing diffs over email really is, at least for my personality and
task management style.

I've used Gitea before for research projects at ${DAYJOB}. It's
incredibly small and simple to use for projects with limited history.
I used Gitea's repo migration tool to do a direct import of
HardenedBSD's src tree from GitHub. I have indeed run into a few
snags.

The biggest snag, which is still hitting us now, is that Gitea seems
to barf when attempting to browse our repo. It's failing to look up an
object. I still need to file a bug report with Gitea on this one. This
email is a good reminder to do that. (I also need to stop working
12-16 hour days, 5-7 days per week, at ${DAYJOB}.)

Gitea pulled down a full mirror of the GitHub repo, I believe.
However, GitHub marks its various pull request branches as read-only.
So when I enabled the hook to publish a read-only full mirror from our
Gitea instance to GitHub (effectively promoting our Gitea server as
the source-of-authority for src.git), Gitea tried to sync the various
pull request branches (refs/pulls/atomically_increasing_number_here),
GitHub flipped out, erroring with permission denied due to read-only
branch. I think I might've resolved that issue, but I'm still not 100%
confident that the resolution was complete.

Our next server purchase will be a dedicated database and storage
server. With our limited funding, our Gitea instance is using sqlite
as its backend. As you can imagine, that is likely the largest
bottleneck in our self-hosted git deployment.

So, where HardenedBSD's self-hosted git stands today:

1. Our Gitea server (git-01.md.hardenedbsd.org) provides basic
   functionality--the bare minimum of what we need.
2. We have some user-visible bugs to address with the Gitea project.
3. Now that we self-host, we can now expose services via IPv6 and via
   Tor Onion Service v3 nodes. We're able to expand access to our
   network resources by virtue of self-hosting. GitHub still does not
   support IPv6.
4. We need to address real-world performance issues with using a
   sqlite-backed Gitea instance on a memory-starved ZFS server.
5. If I know what I knew now, would I still have performed the
   migration? Yup.

I hope that helps. Please let me know if you have any questions,
comments, or concerns.