[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] strategy for error: sign+encrypt failed: unusable p
From: |
Kenneth Loafman |
Subject: |
Re: [Duplicity-talk] strategy for error: sign+encrypt failed: unusable public key |
Date: |
Wed, 22 Oct 2008 06:22:08 -0500 |
User-agent: |
Thunderbird 2.0.0.17 (X11/20080925) |
address@hidden wrote:
> Hello all,
>
> somebody switching from an old to the recent ftplicity version came up
> with an error similar to this...
>
> gpg: FFFFFFFF: There is no assurance this key belongs to the named user
> gpg: [stdin]: sign+encrypt failed: unusable public key
> gpg: encrypted with 2048-bit ELG-E key, ID FFFFFFFF, created 2007-12-17
> "duplicity"
> gpg: FFFFFFFF: There is no assurance this key belongs to the named user
> gpg: [stdin]: sign+encrypt failed: unusable public key
>
> this was because the selected key was not trusted, he didn't know why it
> suddenly happend, because the former combination of ftplicity
> 1.1.1/duplicity 0.4.9/gpg-1.4.5-24.4 worked fine.... but still this can
> happen when installing/switching machines or accounts - so it should be
> prevented .. especially as the gpg error message only comes up with
> verbosity 5 or more
>
> ... this made me think of ways to prevent this error .. as I didn't find
> a way to let gpg show the trust state of a key, the only way for now is
> to test-sign+encrypt something and to check if that throws an error
> e.g. > echo "$PASS" | gpg --passphrase-fd 0 -e -r FFFFFFFF --batch -o
> /tmp/mktemp.file test.txt
>
> the other solution I think of is a bit more straight forward ... why not
> setting gpg --trust-always .. as the user selects a key that he/her
> obviously wants to use and therefore has to trust
> I am interested in opinions about this idea .. as there is currently no
> scenario I can imagine, except of a hacked backup user account (but then
> everything is lost already, so it doesn't matter), where the
> --trust-always could be security problematic
>
> on the other hand .. if there is an easy way to doublecheck if a key is
> trusted ultimately, I still would think about this way, as test
> encrypting someting does not seem very elegant to me
Thanks for the heads up on this one. I'll look into it.
...Ken
signature.asc
Description: OpenPGP digital signature