Git integration

[kousu]

How does pass-tomb interact with git? One of the things I like so much about pass is that it can handle merging encrypted files. It looks like pass git push would only work once the tomb is opened? And in that case, the remote server gets an untombed password store? Thanks in advance.

[roddhjav]

Short: It does not.

Long: Git works when the password store tree is visible. The whole purpose of pass-tomb is to hide this tree. Therefore git can be used as local versionning system but not as a way to sync the password store with a remote server. If you use git pull/push feature on an opened tomb, you will push an untombed password store.

As of today, they is no solution to use both tomb and git on a remote server. I might implement a solution in the future. However, it would require an important amount of work.

[fritz-k]

To sync my tomb, I placed my tomb-file and tomb-key in my pass-dir and commit only when the tomb is closed. Merging changes from multiple hosts isn't trivial with this setup, but syncing on multiple hosts works quite nicely. Do you see problems with this approach?

Unfortunately, tomb modifies .last, .host, .tty and .uid every time you unlock the tomb, which is a pain when trying to version/sync this file via git. Are these files strictly necessary for operation?

[amerlyq]

Alternative approach if you use only single PC at a time -- always keep tomb (without key) on some cloudsync. Then do "pass open" on local db, manually open tomb from cloud sync, add git remote upstream to this manually opened tomb and manipulate git as you always do. Then close this local copy of cloudsync tomb and wait until new version is uploaded to cloud. Repeat on second PC.

Pros: git diff / merge / etc -- working as without tomb. Cons: copy 10MB to cloud each time you simply open/close it.

[jerabaul29]

A few thoughts about this.

• People using git with pass-tomb would do actually 2 things: use git within opened tomb to allow history tracking etc. (git use level 1, similar to git + pass), vs. using a remote private repo for example on github for hosting / saving their data (git use level 2). This second use is not optimal maybe (the 10MB commit size, and not too good to put stuff on the cloud, even private cloud), but since a strong encryption is used it is a fair enough way to keep things saved in the cloud.

Therefore, could this be a reasonable workflow to integrate git with pass tomb:

• the pass git works as usual (git level 1); we do not want to push it to another place though, as would be a security risk (would show what is committed through the commit messages)

• the pass tomb git allows to use and set up a second level of git repo, corresponding to the git level 2. This is only for saving and synchronization of level 2 git repo, which is a git tracking of the tombed, encrypted whole thing, including the underlying git level 1.

This is not very efficient from the point of view of github, and no meaningful merge etc will take place at level 2 ie on the github repo, but this is not a problem: github is used only for syncing / archiving of strongly encrypted files, and meaningful merging will take place at the level 1. However this is not too problematic: if a tomb is 10MB, and a repo is 100GB, we can expect to be able to push 10,000 times, which is a lot, before hitting max repo size (by then github will probably have extended a bit the max repo size anyways).

In this case should we consider implementing:

pass tomb git push2 which would be different from pass git push:

• IF the level 2 repo is in a state that is a direct descendant of remote/HEAD, we can just push

  • close the tomb (if opened; this is because need to push at level 2)
  • git add and commit the closed tomb at level 2
  • git push the closed tomb, with UTC as commit message, at level 2
  • open the tomb (if was initially opened; to end in the same state)

• ELSE, the level 2 repo is not in a state that is a direct descendent of remote/HEAD. This mean we have to git merge at level 1, otherwise some stuff may be lost

  • open the tomb (if closed; this is because need to merge at level 1)
  • git clone the remote in a separate folder at level 2
  • untomb the clone, this gives us the remote at level 1
  • add the clone at level 1 as a remote of the local at level 1
  • do the merge at level 1, commit at level 1
  • remove the remote clone at level 1 (both from HDD and from remote list of local git level 1)
    • close the tomb (need to merge at level 2)
    • commit at level 2
    • pull from the remote at level 2
    • resolve the conflict by using the local version
    • push at level 2
    • open the tomb
  • close the tomb (if was initially closed)

Does that make sense / do you agree on the logics behind? This actually may be quite ok to implement, what do you think?

[amerlyq]

@jerabaul29, sorry, I see only cons in your approach. Isn't my approach described above much greater ? :)

pass git init
sudo install -m 700 -o "$USER" -g "$USER" -d -- /media/tomb
sshfs -f --debug -o "umask=0077,noexec,no_readahead,allow_root,compression=yes,port=$port,IdentityFile=$id" "$host:tomb" /media/tomb
tomb open /media/tomb/pass.git.tomb -k ~/tomb/pass.git.tomb.key -g
pass git remote add origin /media/pass.git
pass git fetch --prune --all
pass git branch master -u origin/master
pass git push -u --all
tomb close pass.git
umount /media/tomb

• bare git is kept inside opaque remote tomb
• you mount encrypted tomb directly through ssh as filesystem
• you keep gpg-encrypted key only locally
• you decrypt this container only locally
• size of tomb is always ~10-20MB
• you can sync git history as always without any overhead when tomb is opened
• minimal traffic over network with small overhead of pasing filesystem blocks metainformation

And that's how you create remote tomb without passing key over network:

# REMOTE
mkdir -m700 ~/tomb
chattr +C ~/tomb
tomb dig -s 20 ~/tomb/dev.tomb
# LOCAL
sudo mkdir -m700 /media/tomb && chown "$USER:$USER" /media/tomb
sshfs -d -o "umask=077,noexec,no_readahead,allow_root,port=22,IdentityFile=$id" user@host:tomb /media/tomb
tomb lock /media/tomb/dev.tomb -k ~/tomb/dev.tomb.key -gr "$gpgid"

[jerabaul29]

No worries, always good with a healthy discussion :)

I am not sure that we talk about the same problem / that we solve the same problem? What I want is to use github as a backup from my tomb, with no information about the tomb content (other than the closed tomb itself) on github. Is it what your solution does too? In this case, the solutions should be more or less equivalent - as there is no way to circumvent that you need to push a closed tomb of 10 MB each time you do a pull.

[amerlyq]

Nope, my setup is for personal VPS, or any file-sync solution like dropbox/googledisc. Because what I really need is only secure central syncpoint between my many devices, and underlying full-functioning git inside of it to merge changes. GitHub/GitLab don't fit this modus operandi at all, and using other services for it is much easier. Ask yourself -- why do you want to use GitHub for this, if the only thing you want -- secure sync point, and not tracking history, smart merges, social publicity and codebase reuse? Without aforementioned requirements GitHub is rather awkward storage for non-textual information.

[jerabaul29]

• I simply dislike dropbox / googledisk. I have a pro github account, and I am very used to using it in command line, I just do not really want to setup and use something else.

• For small files, I use github as a file-sync solution. Maybe not optimal, but works fair enough.

• Github forces me to be careful about not erasing anything. For example in my suggested workflow, as long as you use the pass tomb git push2 command, you cannot break anything / erase a previously stored password as you will not be able to push a non-merged file.

[aikooo7]

Don't want to hit the dead horse but this is still open so I don't see a needing to open other issue.

A suggestion of mine is not use a script that detects changes on .pass.tomb and if so also awaits the pass close key and if both are received does what pass git push do?