Live data from Hacker News

Show HN: Encrypted Git hosting should be easy

github.com

1–10 of 71 posts

Re: Show HN: Encrypted Git hosting should be easy

#2
What'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 the hosting provider does more than just hosting, they have their own CI/CD features which need access to code. If you don't want the hosting provider to have access then you might be better off self-hosting Gitlab rather than dealing with restrictions like remotes can only have 1 branch.

Re: Show HN: Encrypted Git hosting should be easy

#4
post #2

What'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

#5
I still don't have a clear understanding on when you would need such a thing.

This does not help the people who want to use git for video hosting since it puts the storage and usage back onto a persons credit card again (tho if you come into a line of credit it may be useful).

Hosting on AWS like this does not match the dark web requirements for hiding in plain sight and not easily killable. To spread this over multiple aws accounts and s3 buckets alone would need some form of sts cross linking for the permissions to allow pushing to be granted.

Can you provide a business use case or scenario this would be useable. Else it will continue to have the smell of 'resume driven development'.

To block force push, would also suggest that branch deletion would not work either. Is that the case?

Re: Show HN: Encrypted Git hosting should be easy

#6
post #2

What'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…

you pretty much nailed it. this treats aws as an untrusted provider. i version almost everything with git, and there are three buckets something might go in:

- if it's public, it's on github.

- if it's a private company project, it probably already has a home, on github or some other trusted commercial provider with cicd and all the trimmings.

- everything else goes here, as encrypted git bundles on s3.

i previously used git-remote-gcrypt for a long time. recently i've been thinking about how i wish worked with git, cicd, and infra. this is how i'm going to be working with that third bucket from now on.

the first bucket is fine, aside from lock of sha256 support.

the second bucket i'm still thinking about.

Re: Show HN: Encrypted Git hosting should be easy

#7
post #3

Ignorance: What's the use-case for this? If you can't rely on the drives not to be tampered with, surely you also cannot rely on the CPU or kernel? Am I missing something?

This stores blobs in S3. So this is about not trusting hard drives which you have rented. Whether or not that makes sense depends on your threat model, but it seems reasonable to me that there are people who would find this useful.

Re: Show HN: Encrypted Git hosting should be easy

#8
post #4
post #2

What'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.

even when you can trust your provider, and often you can, not trusting them can be psychologically beneficial.

Re: Show HN: Encrypted Git hosting should be easy

#9
post #5

I still don't have a clear understanding on when you would need such a thing. This does not help the people who want to use git for video hosting since it puts the storage and usage back onto a persons credit card again (tho if you come into a line of credit it may be useful). Hosting on AWS like this does not match the dark web requirements for hiding in plain sight and not easily killable. To spread this over multi…

branch deletion also does not work. the data model is very simple, a single chain of git bundles. s3 policy could enforce a variety of data models, such as inability to delete objects.

there is no business use case for this, unless your threat model needs an untrusted git provider and you don't have another way to enable that.

perhaps you could store your dotfiles or other backups with this.

Re: Show HN: Encrypted Git hosting should be easy

#10
post #3

Ignorance: What's the use-case for this? If you can't rely on the drives not to be tampered with, surely you also cannot rely on the CPU or kernel? Am I missing something?

i think the best way to think of this is that it's cheaper than private github/gitlab and easier that aws codecommit. also other stuff.
Post reply on HN