set -e causes the xecho to not run if the xgrep fails. At least with OSX's
/bin/sh, which is:
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
This didn't happen on Linux with:
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Possibly a bug in bash, or an OSX-specific bug. However, disabling set -e
in the subshell seems a good idea anyway.
fixes https://github.com/blake2-ppc/git-remote-gcrypt/issues/15
This is to allow programs to determine if a repo uses gcrypt, per #6.
Since this program already knows the name of the manifest file and how to
download it and decrypt it, it makes sense to do the check here rather than
in, eg, git-annex.
This is needed by git-annex assistant when it sets up a gcrypt repository,
to ensure that the gpg key it was asked to use to encrypt the repo is the
same key used to sign it. If it's not, pulling from the repo won't work,
due to git-remote-gcrypt's "Only accepting signatories" check.
The user may have a global user.signingkey setting (I do), but be setting
up a different special-purpose key for encrypting their git repo. The
git-annex assistant cannot mess with the global value, so needs this to
override it.
Otherwise gpg may prompt to verify if we want to encrypt to users who
do not have a defined trust level. But, the participants setting
explicitly listed them, so we know we want to encrypt to them.
closes#3
Using a standard directory for temporaries buys us performance when the
user wants it (has configured tmpfs for /tmp) and configurability
(accepts TMPDIR=).
Moving /pack to a temporary directory gives safe concurrent remote
repacks.
There should be no difference if we use 32 random bytes or more, since
GPG's longest symmetric key is 32 bytes, but to just remove any doubt we
use a longer random passphrase.
