#1668 Issue `closed`: duplicity backup fails with gpg error "There is no assurance this key belongs to the named user"¶

Labels: enhancement, support / question, fixed / solved / done

gdha opened issue at 2017-12-30 09:56:¶

rear version (/usr/sbin/rear -V): 2.3
OS version (cat /etc/rear/os.conf or lsb_release -a): CentOS7
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf): BACKUP=DUPLICITY
Are you using legacy BIOS or UEFI boot? BIOS
Brief description of the issue:

Creating duplicity archives on 'rsync://root@server//root/backup'
GPG_OPT =  --gpg-options "--cipher-algo AES" 
EXCLUDES =  --exclude /proc --exclude /sys --exclude /run --exclude /var/lib/ntp/proc --exclude /root/.cache --exclude /tmp --exclude /var/tmp --exclude /app --exclude /var/app
Checking backup-path at server ...
Removing the old stuff from server with CMD:
    duplicity remove-older-than 2M -v5 rsync://root@server//root/backup/client
Running CMD: duplicity -v5 --volsize 100 --encrypt-key A1A86DCB  --gpg-options "--cipher-algo AES"   --exclude /proc --exclude /sys --exclude /run --exclude /var/lib/ntp/proc --exclude /root/.cache --exclude /tmp --exclude /var/tmp --exclude /app --exclude /var/app      / rsync://root@server//root/backup/client >> /tmp/rear.UHtmwV9mPr9aObA/tmp/backup.log 
Import of duplicity.backends.webdavbackend Succeeded
....
Reading results of 'rsync -e 'ssh  -oBatchMode=yes '  root@server:/root/backup/client/'
Last full backup date: none
No old backup sets found, nothing deleted.
Using temporary directory /tmp/duplicity-StXZfl-tempdir
Command line error: Expected 2 args, got 3
Enter 'duplicity --help' for help screen.

Work-around, if any:
If we execute the duplicity by hand we see the real error message:

# duplicity -v5 --volsize 100 --encrypt-key A1A86DCB  --gpg-options "--cipher-algo AES"   --exclude /proc --exclude /sys --exclude /run --exclude /var/lib/ntp/proc --exclude /root/.cache --exclude /tmp --exclude /var/tmp --exclude /app --exclude /var/app      / rsync://root@server//root/backup/client
Using archive dir: /root/.cache/duplicity/f36802b37751bc2c49e3592121d6e6c9
....
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: 7581A802: There is no assurance this key belongs to the named user
gpg: [stdin]: encryption failed: Unusable public key
===== End GnuPG log =====

Resolution: https://www.hagen-bauer.de/2013/07/gnupg-there-is-no-assurance-this-key-belongs-to-the-named-user.html
And, seems to be correct as we see:

# gpg --edit-key A1A86DCB
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/A1A86DCB  created: 2017-12-28  expires: 2018-12-23  usage: SCEA
                     trust: unknown       validity: unknown
sub  2048R/7581A802  created: 2017-12-28  expires: 2018-12-23  usage: SEA 
[ unknown] (1). Root <root@localhost>

Perhaps is something we should verify as well in the prep phase?¶

PS: my GPG keys are generated automatically during the rear-automated-testing runs. With other words these are worthless to you.

gdha commented at 2017-12-30 10:24:¶

Solution to make the GPG key trusted is as follows:

[root@client default]# echo $(gpg --list-keys --fingerprint | grep A1A86DCB -A 1 | tail -1 | tr -d '[:space:]'| awk 'BEGIN { FS = "=" } ; { print $2 }' ):6 | gpg --import-ownertru
gpg: inserting ownertrust of 6
[root@client default]# gpg --edit-key A1A86DCB
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2018-12-23
pub  2048R/A1A86DCB  created: 2017-12-28  expires: 2018-12-23  usage: SCEA
                     trust: ultimate      validity: ultimate
sub  2048R/7581A802  created: 2017-12-28  expires: 2018-12-23  usage: SEA 
[ultimate] (1). Root <root@localhost>

Afterwards, by hand the duplicity command given above works fine.
The rear run still fails with Command line error: Expected 2 args, got 3 error.

gdha commented at 2017-12-30 12:17:¶

The problem comes from GPG_OPT= "--cipher-algo AES" when we leave it empty it seems to work. Must be the quotes somehow?
PR 9670264 fixed this.

gdha commented at 2018-01-03 12:38:¶

with duply the above problem was fixed by defining in the conf file:

GPG_KEYS_ENC="$(cat /root/root.gpgkey)"
GPG_KEY_SIGN='disabled'

If you insist of using the GnuPG signing key duplicity uses the sub key during the restore

gdha commented at 2018-01-10 09:59:¶

Full test has been performed successfully - https://gist.github.com/4f383510463e4c058d49da5d4ff7cf0d

[Export of Github issue for rear/rear.]

#1668 Issue closed: duplicity backup fails with gpg error "There is no assurance this key belongs to the named user"¶