duplicity-talk
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]