Re: [tlug] search for encrypted information exchange

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > At Starling we use individual PGP-encrypted-and-signed files, and ship
 > them around via subversion. Subversion is probably preferred to git
 > for this sort of thing because you very definitely want to minimize
 > conflicts.

What makes you think git would cause more conflicts than Subversion?
In fact, git might be preferable to Subversion on the grounds that if
there *is* a conflict, git guarantees that you have literal copies of
all the files involved in the conflict.  (Maybe Subversion does too,
but CVS does not, because you can update (merge) a local file with
changes, thus losing the original of those changes.  I would imagine
Subversion works the same way.)

 > Merging is a bit of a pain: you need to throw away the conflicting
 > version, load up the two versions that conflict, manually merge the two,
 > and then commit the new merged version. Good communication is essential,
 > lest another commit create a further conflict whilst you're doing this.

That's stupid. :-)  Just use a dVCS like git or Mercurial.  It's true
that one can run into further conflicts, but the urgency is much less
since one can just stay on one's branch until one feels like merging.
(FVO "one" != "Curt", since we know how Curt feels about branching.)

BTW, git allows you to specify a custom merge tool, which I would
guess would allow you to specify a script that gets the three versions
of the file (local, to-merge, common ancestor), decrypts them, then
invokes your favorite merge tool on them, and finally encrypts.

Of course this could get very hairy if multiple encryption keys or
signatures are involved.  But it should work in theory.

P.S. I don't claim that git *is* the best way to go here, but since
git can do all of the above, you should look for ways to get your
weapon of choice to do them, too.  There probably are ways, but don't
ask me -- I like git!