cryptpad uses a technique where the key for a given pad is put into the URL into the hash fragment. Browsers never send this to the server, so it provides an easy way to share a link which includes end to end encryption, without the user necessarily having to understand that.
Is there a way we could put the key into the git remote URL in a similar fashion?
git remote add enc encrypted::git@host:path/repo.git#key
I think the # symbol signifies branches in some context, at least in the git-remote-gcrypt context. Perhaps if the git client doesn't understand the significance of the # then it will send that part also to the server, obviously a bad idea in this case.
Perhaps there's another approach like encrypted::key::url where a client that didn't understand the format would try to connect to a hostname which is the key? Perhaps encrypted::key::${key}::url instead where key is a literal string before the key.
Maybe this approach is simply too risky, in that the potential to expose the key is too high.
Another option would be for the git-remote-encrypted helper to remove the key from the remote after it has been written to .git/encrypted-keys/. So the risk of divulging the key exists only until successful push. Hmm, this is probably a bad idea in the case of a user with an unsupported client trying to fetch an encrypted repo.
More research...
cryptpad uses a technique where the key for a given pad is put into the URL into the hash fragment. Browsers never send this to the server, so it provides an easy way to share a link which includes end to end encryption, without the user necessarily having to understand that.
Is there a way we could put the key into the git remote URL in a similar fashion?
I think the
#symbol signifies branches in some context, at least in the git-remote-gcrypt context. Perhaps if the git client doesn't understand the significance of the#then it will send that part also to the server, obviously a bad idea in this case.Perhaps there's another approach like
encrypted::key::urlwhere a client that didn't understand the format would try to connect to a hostname which is the key? Perhapsencrypted::key::${key}::urlinstead wherekeyis a literal string before the key.Maybe this approach is simply too risky, in that the potential to expose the key is too high.
Another option would be for the
git-remote-encryptedhelper to remove the key from the remote after it has been written to.git/encrypted-keys/. So the risk of divulging the key exists only until successful push. Hmm, this is probably a bad idea in the case of a user with an unsupported client trying to fetch an encrypted repo.More research...