Re: Gedit plugin



On 27.04.2013 09:35, Pietro Battiston wrote:
Il giorno ven, 26/04/2013 alle 21.48 +0200, Stef Walter ha scritto:
On 26.04.2013 16:38, Pietro Battiston wrote:
[...]

When I use the DBus method EncryptText(), I am asked for a list of keys.
Assume I give some key of a friend of mine. When I try to decrypt the
resulting text, I would expect the process to fail - I don't have her
private key.
Instead, gpg decrypts it without problems, because the text is encrypted
both with my friend's key and _my_ key.

I think if you have a default key it'll be automatically included in the
recipients.


OK.

Fair enough, it can make sense, in principle, that I'm able to decrypt
any text I encrypted. But then, I would expect EncryptText() to also
accept an empty list of keys: it should then encrypt using only my key.
Instead, it refuses, pretending some recipients.

Most likely a bug. This is implemented in libcryptui, which doesn't have
much maintenance. but I would include a patch (and help you get started
with building it) if you like.

Well, that's not crucial for me (and anyway I can't rely on it if it
doesn't get distributed, so that wouldn't help). I just wanted to be
sure I wasn't missing something.

Instead I have another question: of all the keys I get with the
"ListKeys" function of org.gnome.seahorse.Keys, some have a "raw-id"
looking like "04E29C73", some like "B0894B0104E29C73:2". All of my tests
seem to show that those of the first kind are able to encrypt, those of
the second are not
(org.freedesktop.DBus.GLib.UnmappedError.Org.gnome.seahorse.Error.Failed.Code1: Key is not a valid 
recipient for encryption). But can I reliably establish that I can drop all keys with the "raw-id" longer 
than 8 digits when asking the user for a key to encrypt? Or is there a better method to do this filtering?

Again, looks like a bug to me. It's hard to know how to answer this
question off hand. libcryptui and that DBus interface is really old and
not really in use anymore. But happy to help integrate patches if you do
find the bug.

Cheers,

Stef



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]