this post was submitted on 14 Oct 2025
9 points (90.9% liked)
Open Source
41415 readers
139 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
No? It doesn't seem to be a use case they target.
If you want to use git to store sensitive data, you should encrypt it before committing / pushing it.
The problem is that making a repository private makes users think their data can't be seen so they may upload that kind of information.
I'll look into that.
Usually you don't accidentally open a git repo and set up a ssh key and push your own credentials to a foreign repo. Usually that involes reading a manual. If those tutorial don't cover keys, then the tutorials need to be improved. imo
Generally if you want to combine full encryption with version control, your best bet would be instead to not use something like Forgejo, and instead do something like init a local git repo, commit like usual, then set up scripting that will tar.gz archive the entire repo, PGP encrypt the archive, and then upload that to a cloud provider's file storage. That way, it's got privacy (the archive is encrypted), it's got version control (once decrypted and decompressed it goes back to being a folder with a git repo in it), and it's backed up (via cloud file storage provider).