You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all thanks for sharing this little handy tool.
There are some sensitive files which are still valid for storing as a part of dotfiles repo, but should be encrypted so that only after sync they are of any use.
If you think it would be a valuable addition I can try contribute, even though I don't know that much about python yet ;)
The text was updated successfully, but these errors were encountered:
At this point, I think encryption is a bit beyond the scope of what this tool is trying to do and likely what I'll have time to review and maintain with where I'm at in my life right now. That said, you're certainly free to write it and keep it in your own fork - if it's good and enough people support it, I would consider it. Are any of the other dotfile utils supporting encryption? My initial thought is that an encrypted filesystem or subdirectory (via ecryptfs) would be a drop-in solution - that would solve the local problem. Without encryption at the filesystem or block layer, you'd have to store the unencrypted contents somewhere on the filesystem which would open you to potential exploit.
The problem you're trying to solve, is the ability to store private dotfile contents in a pubic repo or on a site you do not control?
First of all thanks for sharing this little handy tool.
There are some sensitive files which are still valid for storing as a part of
dotfiles
repo, but should be encrypted so that only after sync they are of any use.If you think it would be a valuable addition I can try contribute, even though I don't know that much about python yet ;)
The text was updated successfully, but these errors were encountered: