UX flow idea: automatic, without .secrets clutering your directory.

[adriangalilea]

Hello,

I was testing this project and I liked it, however, I think it would benefit from a more automatic workflow, I'd want to be able to:

1. define which files are secret.
2. .secrets being stored in a parallel structure under ~/.gitsecrets/* that doesn't pollute my original directory with 2 versions.
3. automatically replace the file when commiting.
4. automatically create the file in the original path when pulling.

I know this may not be feasible and/or out of the scope of the project, feel free to discuss. Note that the automatic flow and the secrets being stored in a parallel path are 2 independent ideas that may be individually implemented if the other is not viable, or obviously to make it easier to implement divided in 2 tasks.

Further study:
git-crypt may be similar, but never used and seems abandoned.

[sobolevn]

Hm, I am not sure about how we can potentially integrate this.
At this point this would be quite big API change, many people might rely on the file location path.

Providing an option? This option should be stored somewhere. Or we should detect where the files are and how to store them.

Do you have any ideas about it?

[adriangalilea]

Hm, I am not sure about how we can potentially integrate this.

At this point this would be quite big API change, many people might rely on the file location path.

I understand, I just wanted to write out what the ideal workflow would be, no intention to force change, just share thoughts :)

Providing an option? This option should be stored somewhere. Or we should detect where the files are and how to store them.

Do you have any ideas about it?

I think you may have the perfect API in place for what I'm suggesting, so concerns can remain separated and use what already is git-secret for it's API

Imagine we have computer-a with the following repo:

+ /foo.md 
/.gitsecret/

same repo on computer-b

/.gitsecret/

Then I decide to mark foo.md as secret.

I still have the same structure.

/foo.md
/.gitsecret/secrets/foo.md.secret

An encrypted file serves no purpose while it's encrypted so it's just clutter when I browse the folder or list its content.

foo.md.secret get's created in an isolated path, the original path is also stored somewhere.

Note the original filename and path can be obfuscated or directly encrypted in an sqlite db where you have all your files:

/.gitsecret/secrets.sqlite

Then some hooks are added to the git repo:

When you push, it ensures foo.md doesn't go into the repo, but the /.gitsecret/mirror/foo.md.secret or /.gitsecret/secrets.sqlite get's pushed.

Then on computer-b you pull and on your you get:

/foo.md
/.gitsecret/secrets/foo.md.secret

Of course git is not going to play very well with this, but I'm pretty sure this can be sorted in the future keeping an encrypted version control log. Ideally a git wrapper with 1:1 functions that adds a middleman of encryption transparent to the user if authorized, so you'd have a private version control inside a public version control.