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.
The people who don’t know this (i.e. target audience) will think otherwise. Correcting others that are making a point can be counterproductive. To reach those under the spell of fantasy, speak the language of fantasy.
Perhaps you can give me an example of "speak the language of fantasy". While I can see your point, I can't really see how to put it into practice.
Edit: I didn't realise you were the person I responded to. I see what you mean, but I still think it's an important thing to discuss. It just won't be relevant to those people, which I can live with.
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.
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.
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 going to be your competitor it makes to store your data encrypted on their platforms.
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.