[HN Gopher] How Git servers work, and how to keep yours secure
___________________________________________________________________
How Git servers work, and how to keep yours secure
Author : danielg0
Score : 90 points
Date : 2021-03-12 15:34 UTC (7 hours ago)
(HTM) web link (gemini.nytpu.com)
(TXT) w3m dump (gemini.nytpu.com)
| epja wrote:
| What would be the best practice way of allowing git pushes
| similar to how heroku handles them? I'm wanting to implement a
| feature that allows users to push to deploy new themes.
| urda wrote:
| Does anyone host something like "gogs" in the cloud for
| themselves ?
| Sebb767 wrote:
| We use Gitea (a Gogs fork) for our company and it works great
| :)
| 1337shadow wrote:
| What CI runner ?
| gnabgib wrote:
| Not OP, but we use Drone[https://www.drone.io/] with
| Gitea[https://gitea.io/en-us/]
| Sebb767 wrote:
| We actually use drone, too! It has its quirks (for
| example, it would be nice to be able to start jobs via
| the web interface), but it works well for us.
| jeffmk wrote:
| Gitea[0] is a pleasant, easy-to-set-up 'GitHub lite', if you are
| looking for something more turnkey and less custom:
| - users/organizations - issues - PRs -
| milestones - releases - wikis -
| activity/contrib graphs
|
| I have it running on a $5/mo Linode instance for some of my
| personal projects.
|
| [0] https://gitea.io/
| elevation wrote:
| I like self hosting git but these tutorials set you up with only
| a one-machine solution. I'd like to be able to self-host a git
| service that's robust in the face of network/hardware/OS
| maintenance.
|
| I know git is distributed by design. So if I want to push code to
| a pair of servers for better availability, I can do it
| explicitly: git push <remote1> <branch> git
| push <remote2> <branch>
|
| But what if I wanted to make this transparent but still highly
| available, such that the remote URL in git push
| <remote> <branch>
|
| is actually backed by a HA cluster?
|
| Some of the software and ops to make this happen is Github's
| secret sauce. I'm not looking to compete with them, but would
| love an open source solution that had a better uptime than a
| single digital ocean droplet running debian. Ideally, I could get
| there without green-fielding raft consensus shims into a modified
| git binary.
| Ajedi32 wrote:
| git remote set-url --add origin $second_url
|
| Not quite HA cluster levels of redundancy, but it's also way
| simpler to set up.
| amelius wrote:
| You can also install git-shell, which is a login-shell which can
| be accessed through SSH and provides access restricted to Git
| commands.
| lobo_tuerto wrote:
| If interested in self hosting your git repos have a look at
| gitolite: https://gitolite.com/gitolite/index.html
| fanf2 wrote:
| Gitolite is good if you want a locked-down git server with
| sophisticated access control
|
| Gitolite provides a command-line UI only; you can use it with
| gitweb or cgit to allow people to view repositories in a web
| browser.
|
| No issues or pull requests or fancy stuff like that!
| 1337shadow wrote:
| gitolite is pretty fancy but depends on a text based
| configuration, and it's easy to make your own git-shell which
| is basically a shell that will allow certain commands, and
| assign each ssh key to a git-shell with arguments such as a
| username if you want to bind to a db or something
| neilv wrote:
| Is there a rock-solid git server that I can use on a home server
| for versioned _immutable_ backups of misc. files on personal
| devices (e.g., account config), as well as private software
| development git repos?
|
| (I've done a cheaper version of this -- except for the immutable
| part, and the separation of accounts between devices -- in the
| past using SSH+SVN to a home server, and it was great.)
|
| I was thinking immutable from the perspective of a device. A
| given device can pull branches of certain repos, and make commits
| to the branches. But a device's user account on the git server
| doesn't have permission to affect past commits. So, for example,
| if my dodgy Linux smartphone is compromised, a hypothetical
| person who isn't being nice can't do anything to my backups,
| other than make bogus additional commits.
|
| Maybe each device has its own branch (e.g., `big-laptop`,
| `little-laptop`, `smartphone`, `media-server`), where they can
| commit their changes, and maybethey can pull from main/trunk. And
| then the physical console for the git server lets me inspect and
| merge changes from the different devices, so that other devices
| can pick up those changes.
|
| I thought about starting with Gitlab CE, but that's pretty big,
| so, even if the features could be made to do what I want, I don't
| know whether I'd always be running too many vulnerabilities that
| defeat some of my purposes.
| rsync wrote:
| "Is there a rock-solid git server that I can use on a home
| server for versioned immutable backups ..."
|
| A few things ...
|
| First, 'git' is built into the rsync.net platform and you can
| do anything you like with it, remotely, over ssh:
| ssh user@rsync.net "git clone
| git://github.com/freebsd/freebsd.git freebsd"
|
| I personally track a number of repos I consider important and
| keep my own source trees up to date _without running git
| locally_.
|
| Second, the ZFS snapshots that are taken, nightly, of your
| entire rsync.net account are _immutable_ (read-only) so if you
| clone /update your git repos into your account, they are
| protected from ransomeware/mallory.
|
| Third, we _finally have LFS / git-lfs support_ which pleases me
| greatly.
| ghostbrainalpha wrote:
| Is there any reason your example would ever happen? That seems
| a little far fetched of a security concern to me.
| nucleardog wrote:
| gitea is super easy to set up and self-host. It has branch
| permissions. Relatively straightforward to, e.g., allow devices
| to push only to their own branch but not allow force pushes
| that overwrite old commits.
| rav wrote:
| Maybe this git-config setting will do what you need?
| receive.denyNonFastForwards
|
| "If set to true, git-receive-pack will deny a ref update which
| is not a fast-forward. Use this to prevent such an update via a
| push, even if that push is forced. This configuration variable
| is set when initializing a shared repository."
| LanternLight83 wrote:
| I was going to say, I've got my got server on my NAS, which is
| itself on a ZFS filesystem, through which snapshots provide
| immutable backups;
|
| But considering the case of a malicious got contributer, access
| to any of my devices and ssh keys is already a wayyy bigger
| issue to begin with, and likely entails restoring the rest of
| the system to a known-secure state due the sheer number of
| files an intruder could have tampered with _outside_ of
| version-controlled directories.
| cogman10 wrote:
| Depends on what you are after, but why not GIT + SSH and run
| regular snapshots of the repo? That way a dodgy person doing
| bad things could ultimately be undone relatively quickly.
|
| Any sort of backup of the git repo would also achieve the same
| thing.
|
| If you are super paranoid, you could also do git over email ala
| the linux kernel on sensitive repos and only apply trusted
| patches yourself.
| chungy wrote:
| The article makes the presumptions that one would be running Arch
| on a server and that you must be using nginx as a web server.
|
| The latter half of that is particularly striking to me, given
| that he immediately dives into a shortcoming of nginx... rather
| than reaching for Apache, he works around nginx's shortcoming.
| moistbar wrote:
| Arch also doesn't make for a particularly good server OS.
| megous wrote:
| Why? (Asking as someone running Arch on many servers for the
| last 5 years, and debian server for much longer)
|
| I can think of a few things I dislike, but all of the
| failures so far were self-inflicted. Like forgetting to
| update packages that I self compiled outside of supported
| repository.
|
| It's not completely autonomous when it comes to upgrades, you
| have to think for a while before hitting "yes" after seeing
| the list of packages to update, but so is not Debian in the
| long run... (some of the servers I have to manage are 13
| years old or so, and going through major dist-upgrades is
| never that pleasant either. It's a bit more hassle, because I
| don't trust the major version upgrade so I have to run them
| on a backup VM first just to see whether some issues will
| crop up).
|
| But having the latest versions of the programs is great, I
| don't have to second guess myself when writing new programs
| (will it be compatible?), can use the latest kernel APIs,
| etc.
___________________________________________________________________
(page generated 2021-03-12 23:00 UTC)