5 ms·

I'm guessing that because this is encrypting the files to be stored, this means that you cannot view the files via Git forge web UIs, cannot merge conflicting e

by er4hn 2y ago

I'm guessing that because this is encrypting the files to be stored, this means that you cannot view the files via Git forge web UIs, cannot merge conflicting encrypted files, etc. Is that right?

cube2222 2y ago
It’s pretty transparent when used with local tooling that uses the git cli under the hood (i.e. editor integrations). Web UIs get a bunch of blobs of course, by design.
usr1106 2y ago
Only someone who has the keys can display the cleartext. I don't think any forge has support for that and it don't see the use case for first encrypting and then giving the key to the forge. I store only secrets in encrypted form, so I never had to merge anything. But I'd assume merging should be unaffected because it happens in the work area, i.e. in decrypted form. That it's a different storage format in the repo should not matter.
- ratorx 2y ago
  > don’t see the use case for first encrypting and then giving the key to the forge You might only want to keep the files secret from the broader internet, rather than a (trusted) forge, which can make the unencrypted secrets available via an UI for eg. authenticated maintainers. These cases would benefit from being able to see the secrets transparently in the UI when logged in. Also, forges having access to e.g. deployment secrets is not that uncommon (e.g. GitHub with deployments via GitHub actions).
  - remram 2y ago
    You're describing a private repo. GitHub/GitLab/... have that.
    - ratorx 2y ago
      Not exactly. A private repo is entirely private. You might have an open source project which has some deployment secrets etc that you want to check in to git. All the code and config is perfectly safe to expose to the internet, but you want to hide a specific file. I think this pattern was common for things like Ansible and Terraform configs and dotfiles.
      - remram 2y ago
        So a private submodule? My point is, don't use an end-to-end encryption scheme if you want more than the ends decrypting it.
      - richbell 2y ago
        I believe git-secret[0] does what you describe. The author of Lunar[1] uses it to hide the private elements in a public repo. [0]: https://sobolevn.me/git-secret/ https://sobolevn.me/git-secret/ [1]: https://github.com/alin23/Lunar/ https://github.com/alin23/Lunar/
    - erinaceousjones 2y ago
      We started using git-crypt hurriedly and out of necessity/paranoia from the time we heard that our GitLab instance could've been compromised due to a "anyone can be admin" class exploit that had just been disclosed. This must've been a fair few years ago. Don't trust private repos to be private!
arccy 2y ago
diffs and merges can use textconv to operate on the decrypted file
remram 2y ago
That's right. This is the entire point of an end-to-end encryption scheme, of you are ok with the forge having the key then you have regular private repos.

by er4hn 2y ago

I'm guessing that because this is encrypting the files to be stored, this means that you cannot view the files via Git forge web UIs, cannot merge conflicting encrypted files, etc. Is that right?

cube2222 2y ago

It’s pretty transparent when used with local tooling that uses the git cli under the hood (i.e. editor integrations). Web UIs get a bunch of blobs of course, by design.

usr1106 2y ago

Only someone who has the keys can display the cleartext. I don't think any forge has support for that and it don't see the use case for first encrypting and then giving the key to the forge. I store only secrets in encrypted form, so I never had to merge anything. But I'd assume merging should be unaffected because it happens in the work area, i.e. in decrypted form. That it's a different storage format in the repo should not matter.

ratorx 2y ago
> don’t see the use case for first encrypting and then giving the key to the forge You might only want to keep the files secret from the broader internet, rather than a (trusted) forge, which can make the unencrypted secrets available via an UI for eg. authenticated maintainers. These cases would benefit from being able to see the secrets transparently in the UI when logged in. Also, forges having access to e.g. deployment secrets is not that uncommon (e.g. GitHub with deployments via GitHub actions).
- remram 2y ago
  You're describing a private repo. GitHub/GitLab/... have that.
  - ratorx 2y ago
    Not exactly. A private repo is entirely private. You might have an open source project which has some deployment secrets etc that you want to check in to git. All the code and config is perfectly safe to expose to the internet, but you want to hide a specific file. I think this pattern was common for things like Ansible and Terraform configs and dotfiles.
    - remram 2y ago
      So a private submodule? My point is, don't use an end-to-end encryption scheme if you want more than the ends decrypting it.
    - richbell 2y ago
      I believe git-secret[0] does what you describe. The author of Lunar[1] uses it to hide the private elements in a public repo. [0]: https://sobolevn.me/git-secret/ https://sobolevn.me/git-secret/ [1]: https://github.com/alin23/Lunar/ https://github.com/alin23/Lunar/
  - erinaceousjones 2y ago
    We started using git-crypt hurriedly and out of necessity/paranoia from the time we heard that our GitLab instance could've been compromised due to a "anyone can be admin" class exploit that had just been disclosed. This must've been a fair few years ago. Don't trust private repos to be private!

arccy 2y ago

diffs and merges can use textconv to operate on the decrypted file

remram 2y ago

That's right. This is the entire point of an end-to-end encryption scheme, of you are ok with the forge having the key then you have regular private repos.