Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Git servers work, and how to keep yours secure

gemini.nytpu.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: How Git servers work, and how to keep yours secure

#21

Post by rav »

neilv wrote: post #10

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…

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."

Re: How Git servers work, and how to keep yours secure

#22

Post by megous »

moistbar wrote: post #20
chungy wrote: post #6

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.

Arch also doesn't make for a particularly good server OS.

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.

Re: How Git servers work, and how to keep yours secure

#24

Post by jeffmk »

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/

Re: How Git servers work, and how to keep yours secure

#25

Post by moistbar »

megous wrote: post #22
moistbar wrote: post #20

Earlier quoted context omitted.

Arch also doesn't make for a particularly good server OS.

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…

This is all personal experience, so obvious salt is required with it.

I've had bizarre networking bugs pop up on arch that I've not had elsewhere. I also just don't like rolling releases as much as I used to. Since the majority of what I do can be containerized, I prefer a much slower release cadence for my hosts, and anything that requires more up to date packages just gets thrown in a container.

Basically, I think my server workflow just doesn't line up with how arch works. On desktops it's great, since I'll always have up to date video drivers, desktop environments, etc, but on a server I don't usually use things that require the latest and greatest software. I figure as long as it's still getting bug fixes, I'm probably fine.

Re: How Git servers work, and how to keep yours secure

#26

Post by mbreese »

1337shadow wrote: post #9
fanf2 wrote: post #7

Earlier quoted context omitted.

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!

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

> basically a shell that will allow certain commands, and assign each ssh key to a git-shell with arguments such as a username

Well, to be fair, you don’t need gitolite for that. You can just do that with any account and the right .ssh/authorized_keys file. prgmr.com uses/used(?) this for out of band access to VMs for example.

Re: How Git servers work, and how to keep yours secure

#27

Post by neilv »

ghostbrainalpha wrote: post #11
neilv wrote: post #10

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…

Is there any reason your example would ever happen? That seems a little far fetched of a security concern to me.

It absolutely happens for some organizations. There's industries around it.

And anyway, seems like good practice, and shouldn't be hard to do, and should fit with workflows already familiar from work.

What would be bad practice is to give less-trusted devices (e.g., Linux development phones, or some disposable PC on which I had to install some sketchy software) access to all my files and backups.

Using git this way might be a simple (given we have to know git anyway) way to give the goodness of backups and selectively syncing various kinds of files both ways with the less-trusted devices.

Re: How Git servers work, and how to keep yours secure

#28

Post by 3np »

elevation wrote: post #18

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 git push But what if I wanted to make this transparent but still highly availabl…

Plenty of alternative approaches that can get you there. Here’s one:

  * distributed file system like gluster or ceph for repos
  * clustered db (eg replicated Postgres)
  * redundant instances of gitea
  * load balancing
Am I missing something?

Re: How Git servers work, and how to keep yours secure

#30

Post by CGamesPlay »

neilv wrote: post #10

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…

I recently asked myself the same question, found no satisfactory answers, and wrote a solution. It uses the backup software "restic" to provide secure hosting on a variety of cloud providers. Restic is immutable by design, and my software basically "backs up" the .git folder to a restic repository. I use S3, but you could easily use any cloud storage provider or local NAS or anything else restic supports.

Shameless plug: https://github.com/CGamesPlay/git-remote-restic

Post reply on HN