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

Show HN: Encrypted Git hosting should be easy

github.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Show HN: Encrypted Git hosting should be easy

#31

Post by ReactiveJelly »

donatj wrote: post #11

This is too dang complicated. For years, across two different jobs we just had bare repos on Linux servers - we used git's built in ssh support and we liked it. Worked great. We wanted a Pull Request workflow and moved to GitHub, but self hosted is fine. All you really need is a server your developers can SSH into with a shared directory. $2 a month Vultr server and you're golden. You want to get real spicy, you can…

SSH is a lot of privilege for a coworker to have. You could get by with HTTP GETs and `update-server-info`

Re: Show HN: Encrypted Git hosting should be easy

#32

Post by justinjlynn »

eftychis wrote: post #27
nathants wrote: post #8

Earlier quoted context omitted.

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

I mean, you need to be a bit realistic, and not kid yourself about who has access.

Better to know for certain (up to confidence and security in the encryption/authentication and key management scheme(s)) than to have faith in the unknown processes and systems of a third party. However, as always, it's all about designing, implementing, and operating a good engineering solution to whatever threat model you have and use.

Re: Show HN: Encrypted Git hosting should be easy

#33

Post by bcjordan »

nathants wrote: post #10
bArray wrote: 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.

I feel like once web browsers / hardware devices start to implement authentication the UX and accessibility of these sorts of tools can become a default choice for user data.

The hard part is solving the "lost my yubikey" UX issue but I suspect Apple will reach a reasonable solution that finds an OK balance of convenience and user-authenticating security.

Re: Show HN: Encrypted Git hosting should be easy

#34

Post by nathants »

bcjordan wrote: post #33
nathants wrote: post #10

Earlier quoted context omitted.

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.

I feel like once web browsers / hardware devices start to implement authentication the UX and accessibility of these sorts of tools can become a default choice for user data. The hard part is solving the "lost my yubikey" UX issue but I suspect Apple will reach a reasonable solution that finds an OK balance of convenience and user-authenticating security.

untrusted hosts open up a bunch of interesting system designs. i’m mostly thinking about these recently. trusted hosts have good use cases, but shouldn’t be used otherwise. trust hard.

lost my yubikey is somewhat covered by the popularity of crypto. recommend users to backup fido2 secrets as bip39 mnemonics.

ios and android will hopefully help popularize fido2.

Re: Show HN: Encrypted Git hosting should be easy

#35

Post by nathants »

bcjordan wrote: post #25
nathants wrote: post #14

Earlier quoted context omitted.

git-remote-gcrypt supports rclone, and all of it's backends. i would use that for your use case. this takes an explicit dependency on aws, though all that is needed is: - (large) object storage with read-after-write consistency (s3) - (small) object storage with compare-and-swap (dynamodb) it would be easy to port this to any provider that provides these two kinds of object storage. compare-and-swap means that multip…

Something about the idea of being able to back things up on multiple remote target storage services sounds extra compelling. Simple encryption with robust backup for e.g. text notes.

it might be worth making dynamodb optional, so all s3 compatible remotes can be used. i made it non-optional to simplify implementation and documentation. there are no knobs, no conditional semantics.

Re: Show HN: Encrypted Git hosting should be easy

#36

Post by nathants »

justinjlynn wrote: post #32
eftychis wrote: post #27

Earlier quoted context omitted.

I mean, you need to be a bit realistic, and not kid yourself about who has access.

Better to know for certain (up to confidence and security in the encryption/authentication and key management scheme(s)) than to have faith in the unknown processes and systems of a third party. However, as always, it's all about designing, implementing, and operating a good engineering solution to whatever threat model you have and use.

i mean, we shouldn’t kid. a lot of kids, with excellent salaries, have access. i’m sure they are a varied bunch. their disposition and competencies are unknowable.

Re: Show HN: Encrypted Git hosting should be easy

#37

Post by hsn915 »

nathants wrote: post #28
hsn915 wrote: post #23

Why S3? I don't have an aws account and don't ever plan on having one. If you want to make git hosting easy, make a self-contained executable that requires nothing but a bare unix-like environment.

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.

Re: Show HN: Encrypted Git hosting should be easy

#38

Post by nathants »

hsn915 wrote: post #37
nathants wrote: post #28

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

then who is sota and for what metrics?

/giphy shutup and take my money

Re: Show HN: Encrypted Git hosting should be easy

#39

Post by paranoidrobot »

hsn915 wrote: post #37
nathants wrote: post #28

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

If you don't like S3 or DynamoDB then it'd be easy enough to sub them out for other things.

Many cloud providers provide an S3-Compatible object-store protocol. There's also open source projects self-hosting your own S3-Compatible object storage.

Swapping out DynamoDB for (say) Redis would also be fairly easy.

The source provided is a few hundred lines of pretty readable Golang.

While I'm not generally a fan of "If you don't like it, submit a PR to fix it" type responses - as a short example of how to implement something like this, it's a pretty decent starting point.

Post reply on HN