If I may, I made one using restic that seems much easier to use [0]. You only need a dumb storage host and no database. Restic takes care of the indexing and we use snapshots just like commits. [0] https://github.com/CGamesPlay/git-remote-restic
Show HN: Encrypted Git hosting should be easy
61–70 of 71 posts
Re: Show HN: Encrypted Git hosting should be easy
#62Earlier quoted context omitted.
s3 is sota, but there are others. just run git on a server! not one executable, but you can pretend.
S3 is a cloud service provided by one company. It's not state of the art.
At this point it's basically a standard as many blob storage providers just implement the S3 API.
Re: Show HN: Encrypted Git hosting should be easy
#63The Keybase encrypted Git is just fine [0]. While Keybase still exists at least. Still sad about that one :( [0] https://book.keybase.io/git
Im happy that there are some alternatives being developed.
Re: Show HN: Encrypted Git hosting should be easy
#64I use it for plain text accounting and personal notes. It's been working great so far, of course I'm the only user and I don't do concurrent writes.
In theory I think the only files that could get conflicts are the ones in the refs directory.
Re: Show HN: Encrypted Git hosting should be easy
#65Got also does E2E encryption, but it can additionally encrypt branch names from remote servers. It also handles syncing large files and directories better thanks to an improved data structure.
Re: Show HN: Encrypted Git hosting should be easy
#66What's the threat model here? Anyone who needs to interact with the source code needs access to the plaintext version (employees, contractors, CodeClimate/CircleCI/Atlassian/Slack/etc type vendors, etc, all retain access), and people who don't need to interact with the source code should have their access removed in the first place. This only protects you against a malicious/compromised hosting provider, but usually…
> This only protects you against a malicious/compromised hosting provider In the increasingly large set of countries without absolute freedoms, such a thing is a given for any hosting provider.
Re: Show HN: Encrypted Git hosting should be easy
#67What's the threat model here? Anyone who needs to interact with the source code needs access to the plaintext version (employees, contractors, CodeClimate/CircleCI/Atlassian/Slack/etc type vendors, etc, all retain access), and people who don't need to interact with the source code should have their access removed in the first place. This only protects you against a malicious/compromised hosting provider, but usually…
I haven't looked at the project being discussed, but assuming it stores your code encrypted in some hosted git, one usecase I can think of is to protect the code from the hosting platform. For e.g. Microsoft ToS for Github allows it to scan / read your code for various kinds of analysis, which some may not want given their history of abuse. Encrypted git can prevent such things. And ofcourse, if one of the BigTech is…
Re: Show HN: Encrypted Git hosting should be easy
#68If I may, I made one using restic that seems much easier to use [0]. You only need a dumb storage host and no database. Restic takes care of the indexing and we use snapshots just like commits. [0] https://github.com/CGamesPlay/git-remote-restic
Much, much better. I don't know why so many devs rely on solely AWS as much.
Re: Show HN: Encrypted Git hosting should be easy
#69I work on a project which solves a similar use case. https://github.com/gotvc/got Got also does E2E encryption, but it can additionally encrypt branch names from remote servers. It also handles syncing large files and directories better thanks to an improved data structure.
Re: Show HN: Encrypted Git hosting should be easy
#70For encrypted git remotes I just create a bare repo on a nextcloud folder that gets synced automatically. I use it for plain text accounting and personal notes. It's been working great so far, of course I'm the only user and I don't do concurrent writes. In theory I think the only files that could get conflicts are the ones in the refs directory.