0

I'm a software developer and our entire code of the project is stored in a single git repository. A small part of this now needs to be made available to a customer. He does not need to push to the repo nor does he need to pull currently. I would like to use the sparse-checkout feature of git to download the part of the repository which we would like to hand over to the customer. However, I have security concerns about this method.

  • Can this method be considered secure such that only the files meant to be exposed are actually downloaded by git?
  • Does the sparse checkout also exclude the git meta files (e.g. commit history, etc.)? If the change history is available, I would be concerned, that the entire code could be reconstructed from that.

This question is related to the answers on stackoverflow about the sparse checkout. The topic with the meta files however is not thoroughly covered in that post: https://stackoverflow.com/questions/4114887/is-it-possible-to-do-a-sparse-checkout-without-checking-out-the-whole-repository

There are other solutions apart from the sparse-checkout. I prefer this method, because the customer can further develop the code (incl. versioning) and we could merge those changes back into our repository one day without much extra work. Furthermore we are always able the pull/push during the development phase by entering the credentials by our-self on the premises of the customer.

Update: What currently seems to do the work:

git clone --filter=blob:none --no-checkout --depth 1 --sparse https://path/to/repo.git ./somedir
git sparse-checkout set /some/dir/inside/the/repo
git checkout
Improve this question
3
  • 1
    why not just give them a zip that excludes all the git files?
    – Jasen
    Mar 2 at 13:00
  • For the reasons I have written in the question, starting at "There are other solutions apart from..."
    – SeVe
    Mar 2 at 13:02
  • 2
    My understanding is that the sparse checkout is meant to reduce the volume of data transferred or to avoid mistakenly changing unrelated files. What to include or not in a sparse checkout is decided by the user who is cloning the repository, and as such, it is completely insecure for your scenario. I'd go with submodules and appropriate permissions instead. Also, your proposed method will fetch all the top level files which may not be what you always want.
    – Margaret Bloom
    Mar 2 at 15:08

2 Answers 2

Reset to default
1

Git does not have per-file or per-directory access control. You grant (read or write) access to the entire repository. The sparse checkout is a performance feature and nothing more.

Can this method be considered secure such that only the files meant to be exposed are actually downloaded by git?

No.

  1. Nothing prevents your customer from executing git clone without the extra filtering at some later time. Either intentionally or by mistake.
  2. git clone --filter=blob:none downloads the entire directory structure presented in the HEAD commit. File contents will not be downloaded, but their names will. You can limit that with other filtering options but, due to the way directories are stored in Git, names of sibling objects will still be transferred (like /some/dir/outside) so don't bother.
  3. The server is not forbidden from sending more that requested. Can you tell whether some future version would not decide to behave differently?

Does the sparse checkout also exclude the git meta files (e.g. commit history, etc.)? If the change history is available, I would be concerned, that the entire code could be reconstructed from that.

Sparse checkout does not limit the commit history. This is done by the shallow checkout you tried with the --depth 1 clone option. This is also trivial to discard later with, for example, git fetch --unshallow.

What sparse checkout does is to postpone the downloading of some objects (be it file or tree blobs). Git will happily connect to the server and fetch any postponed object the instant someone asks for it.

What to do?

Don't cut corners. Create another repository and put the content you can safely give to your customer there.

Not sure if this is useful advice, but your life might be easier if you keep the same folder structure in the new repository (so that it has your /some/dir/inside/the/repo from the original repository). Then add this repository as another remote. Cherry-picking between the two should be relatively painless. Just make sure you never merge commits from the original repository and push them to the customer one.

Improve this answer
2
  • Thank you NonNumeric for your detailed explanation. What I have missed to say in the Question was, that the Repo was cloned through https. Every time git fetches something from the server, it requires the credentials. Thus, a bare git clone without extra filtering would require the credentials first. There is no SSH key installed.
    – SeVe
    Mar 3 at 8:21
  • Don't assume that the credentials for the https connection will not be cached. Git supports credential managers. When I fetch via https I don't need to reenter the password until it is changed. You also have the risks @Jasen mentioned.
    – NonNumeric
    Mar 3 at 12:35
0

Entering the credentials yourself on the premises of the customer is most definitely not secure. there may be a camera. their system may be compromised. they may have installed a keylogger themselves etc...

[ several possible other ways to do this deleted because "There are other solutions apart from..."]

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .