undefined | Better HN

0 pointsfalsedan6y ago0 comments

> it doesn't have access controls (and there's only so much you can add)

so there's a lot of drawbacks to using gitolite but we were able to customise access controls down to allowing some users the ability to only change lines of checked-in config only to certain values

0 comments

klodolph6y ago

How do you prevent users from reading certain parts of the repository, though? This was what I meant by "there's only so much you can add"... you can reject pushes that change parts of the repo, but you can't prevent reads without breaking everything.

falsedanOP6y ago

> can't prevent reads without breaking everything

I don't understand, you can lie to git-upload-pack and send anything you want to the user?

but when we used gitolite, we put sensitive stuff in a separate server and restricted reads to trusted users/deployment tools

edit oh I see, you want to let some people clone the repo but with some stuff redacted and still be able to make changes to the non-redacted stuff. I'd used LFS and move the ACLs to the file server, if using a single repo was a hard requirement

klodolph6y ago

> I'd used LFS and move the ACLs to the file server, if using a single repo was a hard requirement

If you're putting a few large files in LFS, or maybe a couple sensitive files, I can understand and I'd say you're still using Git, but with some extensions.

If you're putting an entire sensitive subtree in LFS, I don't think you're really using Git any more, in the sense that many of your standard Git workflows will have to be different.

j / k navigate · click thread line to collapse

0 comments

klodolph6y ago

falsedanOP6y ago

> can't prevent reads without breaking everything

I don't understand, you can lie to git-upload-pack and send anything you want to the user?

but when we used gitolite, we put sensitive stuff in a separate server and restricted reads to trusted users/deployment tools

klodolph6y ago

> I'd used LFS and move the ACLs to the file server, if using a single repo was a hard requirement

If you're putting a few large files in LFS, or maybe a couple sensitive files, I can understand and I'd say you're still using Git, but with some extensions.

If you're putting an entire sensitive subtree in LFS, I don't think you're really using Git any more, in the sense that many of your standard Git workflows will have to be different.

j / k navigate · click thread line to collapse