Please describe the problem.
I seem to be hitting a problem with the way git annex encrypts the credentials for S3 remotes. I am creating an S3 remote with shared encryption and embedded credentials. If I create the remote on MacOSX, enableremote fails on Debian. If I create the remote on Debian, enableremote fails on MacOSX with a similar error. I can enable MacOSX created remotes on other MacOSX systems and Debian created remotes on other Debian systems. The enableremote creates a .git/annex/creds/uuid file, but the contents are garbled.
Could this be an issue with different versions of GPG on the systems?
What steps will reproduce the problem?
- New git annex remote on Debian.
- Clone and git annex init on MacOSX
- Create S3 remote on MacOSX with encryption=shared embedcreds=yes
- Git annex sync
- On Debian enable remote
Alternatively, create the S3 remote on Debian, sync and enable remote on MacOSX
What version of git-annex are you using? On what operating system?
MacOSX
gpg (GnuPG/MacGPG2) 2.0.30
libgcrypt 1.6.6
git-annex version: 6.20170101
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: 5
supported repository versions: 3 5 6
upgrade supported from repository versions: 0 1 2 3 4 5
operating system: darwin x86_64
Debian 7
gpg (GnuPG) 1.4.12
git-annex version: 6.20170101+gitg93d69b1-1~ndall+1
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: 5
supported repository versions: 3 5 6
upgrade supported from repository versions: 0 1 2 3 4 5
operating system: linux x86_64
Please provide any additional information below.
# Debian 7
$ git annex enableremote S3
enableremote S3 gpg: packet(2) with unknown version 13
gpg error above was caused by an old git-annex bug in credentials storage. Working around it..
git-annex: bad creds
CallStack (from HasCallStack):
error, called at ./Creds.hs:116:22 in main:Creds
# MacOSX
git annex enableremote S34
enableremote S34 gpg: [don't know]: invalid packet (ctb=6b)
gpg error above was caused by an old git-annex bug in credentials storage. Working around it..
git-annex: bad creds
CallStack (from HasCallStack):
error, called at ./Creds.hs:116:22 in main:Creds
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes! git annex has been enormously helpful. Thanks so much for this tool.
I guess this was caused by an old gpg, and so no point in keeping it open. done --Joey
The .git/annex/creds/uuid files for S3 special remotes are supposed to contain the S3 access credentials, the same values you set
AWS_ACCESS_KEY_ID
andAWS_SECRET_ACCESS_KEY
to. Since it's just some high-entropy credentials, perhaps that's why you thought it looked garbled?I doubt that the error message about the cause of the gpg error is right; that is a workaround for an old bug in git-annex 5.20140916. Unless you used such an old version to set up the special remote, it's probably not related to that problem at all.
The actual problem seems to be:
This probably points to an incompatability between the gpg versions. The easiest fix is probably to upgrade Debian to gpg 2.
With embedcreds, the S3 creds are symmetrically encrypted/decrypted using gpg --symmetric. This is a less common way to use gpg, and it could be that there's an incompatability with how different versions of gpg do it.