GNOME Bugzilla – Bug 301865
Pidgin Plugin
Last modified: 2020-06-06 08:52:26 UTC
This bug will be used to track the progress of a Gaim plugin.
So far so good. I've edited the make files so that a make file is built for plugins/gaim and checks are made by ./configure. I may need some help with the version checking before the plugin is committed. I came up with a few questions while I was thinking about how to code it all up: * How can the user be presented with information about a key (Name, Fingerprint, trust level, etc) before it's imported so that the user can decide if they want to import it or not? * Is there a way to query seahorse for a key given a char string? * I was also wondering what a good way was to inform the user about the status of their IM's security. It seems like gaim-encryption resorts to icons at the bottom of the IM window. I don't think this is the best way for us to go since it will be easy to have one message encrypted and not the next. I've thought about prepending a header on to the IM such as: Receiving: ***Encrypted and Verified From <key name>*** ***Encrypted NOT Verified*** Sending: ***Encrypted and Signed*** ***Encrypted*** I'm worried this will add a lot of noise to the conversation though. I want to tie the alias/nick to the encryption key which is why I asked about the search thing, but I could also implement a known_keys type file like gaim-encryption and query the user with the select keys dialog and then associate that public key with that user and protocol. Thoughts?
> I came up with a few questions while I was thinking about how to code > it all up: * How can the user be presented with information about a > key (Name, Fingerprint, trust level, etc) before it's imported so > that the user can decide if they want to import it or not? This is an interesting question. I've wondered this myself. I don't thing GPG allows this, and if it does then GPGME doesn't expose it. You could ask on the gnupg lists, I'd be interested in their response. > * Is there a way to query seahorse for a key given a char string? We haven't had a need to implement this yet, but we could. It would be a method added to the seahorse_key_source base class. Once in place, the current key server key sources would need to use this method as well. > * I was also wondering what a good way was to inform the user about > the status of their IM's security. It seems like gaim-encryption > resorts to icons at the bottom of the IM window. I don't think this > is the best way for us to go since it will be easy to have one > message encrypted and not the next. I've thought about prepending a > header on to the IM such as: > > Receiving: > ***Encrypted and Verified From <key name>*** > ***Encrypted NOT Verified*** > > Sending: > ***Encrypted and Signed*** > ***Encrypted*** > > I'm worried this will add a lot of noise to the conversation though. This is something very bad. Something we need to be aware of. A mistake that *many* cryptography implementations (including PGP corp, which really sucks) make, and I don't want ours to be one of them. I hope you don't mind me pointing it out. Putting the verification text inside or next to the the body of the encrypted/signed plain text, allows simple spoofing by an attacker. An attacker can make it *look* like his message was signed by 'xxxx' or was encrypted, but in fact it was clear. Like I said, don't feel bad about suggesting this, it's a very common mistake. Note that even changing the color, size, etc... of the text may not be enough. It allows an attacker to make something that 'looks close enough', and is still an attack vector. The user should not be used to looking in the plain text for their verification status. > I want to tie the alias/nick to the encryption key which is why I > asked about the search thing, but I could also implement a known_keys > type file like gaim-encryption and query the user with the select > keys dialog and then associate that public key with that user and > protocol. We haven't implemented it yet, but one of the big features in the DBUS interface allows just this. It allows the associating of a string with one or more keys in a simple way. This feature needs a bit of thought, and should 'just work' for the user.
> This is something very bad. Something we need to be aware of. A mistake that > *many* cryptography implementations (including PGP corp, which really sucks) > make, and I don't want ours to be one of them. I hope you don't mind me pointing > it out. > Putting the verification text inside or next to the the body of the > encrypted/signed plain text, allows simple spoofing by an attacker. An attacker > can make it *look* like his message was signed by 'xxxx' or was encrypted, but > in fact it was clear. I understand this, but I'm not sure how to indicate status since our encryption is asynchronus instead of negotiated and always on. Maybe a scrolling status label could be added above/below the IM buttons?
Checking out gaim-encryption their icons indicate next message sent will or will not be encrypted and last message received was encrypted. This might be the way to go. I took a screen shot of their key acceptance dialog and will attach it below. I'll see about asking the gpg devs that question tomorrow.
Created attachment 45810 [details] screenshot of key acceptance dialog
-------- Original Message -------- Subject: Re: Key Info Before Import Date: Fri, 29 Apr 2005 11:12:46 +0200 From: Stephan Beyer <s-beyer@gmx.net> To: gnupg-devel@gnupg.org References: <4271B345.6080102@clemson.edu> Hi, >> Is it possible to extract data about a Best regards,key (Name, Fingerprint, >> Signatures, Expiration Date, Email, etc) before the key is imported into >> the key ring? "gpg -v filename" or "gpg -vv filename" gives you information about the packets in the OpenPGP file (for example, a key or a keyring). Should tell you everything you want except the fingerprint. Btw: I guess, -devel isn't the right list for this question. Best regards, Stephan I've emailed back asking if there is a way not using the gpg executable.
>> * Is there a way to query seahorse for a key given a char string? > We haven't had a need to implement this yet, but we could. It would be a method > added to the seahorse_key_source base class. Once in place, the current key > server key sources would need to use this method as well. I imagine the method to be added would be like libseahorse/seahorse-pgp-source.c:seahorse_pgp_source_get_key but how would the Name from the key be inserted into the hash table? Should the function simply be made more general so that a fingerprint or name could be passed in and the key returned? Then all that would need modifying is the method that loads up the hash table. It might be useful to hash the comment anr or email address as well. I presume then in operation the plugin would query all local sources with a string and a key would be returned or not. If not the user would be presented with a dialog asking if they wanted to search remote key sources. Of course there would be an option for the remote search to always take place without user intervention.
> I imagine the method to be added would be like > libseahorse/seahorse-pgp-source.c:seahorse_pgp_source_get_key but how would the > Name from the key be inserted into the hash table? Well presumably you'd want to be able to search for parts of names, so you couldn't use a hash table per se. I think you'd just want to search through the names of all the loaded keys. > Should the function simply > be made more general so that a fingerprint or name could be passed in and the > key returned? Well for now let's keep it seperate. seahorse_key_source_get_key is used for other things, and this is more of a 'find' match function you're proposing. A question though, what happens when more than one key matches? Do you return them all? That's probably the best. The caller can then choose to discard any extras. > I presume then in operation the plugin would query all local sources with a > string and a key would be returned or not. This occurs in seahorse_multi_source.c. It takes multiple sources and multiplexes function calls and results across them. So you'd need to implement your function for any key source classes we have currently. Probably: seahorse_key_source.c seahorse_pgp_source.c seahorse_server_source.c seahorse_multi_source.c Note that seahorse_hkp_source and seahorse_ldap_source derive from seahorse_server_source and only provide their unique lookup stuff, so you wouldn't need to modify those. > If not the user would be presented > with a dialog asking if they wanted to search remote key sources. Of course > there would be an option for the remote search to always take place without user > intervention. Perhaps leave this out for now. I'm looking into a way to unify this in a way that makes sense for the user. We also need this for looking up signers and stuff, and for the DBUS API. Cheers, Nate
Created attachment 46150 [details] [review] Starts to add find_keys capability This modifies seahorse-key-source{.h .c} and seahorse-pgp-source.c to add find capability.
Created attachment 46156 [details] [review] Same as before Adds find capability to all of the files Nielsen described and builds to boot. This is wholly untested as nothing uses it yet so it should go in HEAD if it's checked in. Should this be called from plugins using the multi-source function?
*** Bug 337162 has been marked as a duplicate of this bug. ***
From Bug 337162: Michael Monreal had a pretty good idea about using eds to link IM accounts and gpg keys. However, eds doesn't need to be extended as it already contains the information needed. Each contact already can store multiple IM accounts and multiple email addresses. When sending a message, query for a list of emails for an IM account, then check the keyring for one or download it from a keyserver. The gaim-eds integration plugin can already be used to link accounts to email addresses.
First, apologies for filing the dupe. Second: nice to see a gaim plugin is considered, but what exactly is the status on this? Is someone actively working on this? If yes, what is the timeframe, is gaim 1.x or 2.x targeted and is there working code to build on?
Another question that popped up is conversation history: will conversations be saved encrypted or decrypted? This is perhaps a very subjective question and should be left open as an option. As for the "what to do to show that a conversation is encrypted", in the case of gaim 2.x I would modify the window/tab title to not only show "$NICK" but "$NICK [secure]" or something like that, perhaps overlaying a small icon to the protocol/buddy icon as well. Additionaly, I imagine a button added to the formatting toolbar, something like an open lock to show encryption is off. The user can press this button and after the peer's gpg key is set (or found via eds), we will send messages encrypted. The button will then have a "pressed" state and the icon will be changed to a closed lock. In the case of a non-encrypted message, a dialog should pop up telling the user that the peer probably doesn't want/can't handle encryption and give the options to either stay in encryption mode or return to cleartext mode. There is also the possibility of taking an approach similar to what firefox does for showing that security is in place: visit a https:// url, firefox will change the background in the location entry field from white to yellow. This could also be done in gaim's conversation window.
Created attachment 62738 [details] Mockup This is a mockup I made some time ago... shows integration into gaim in the case that gaim can find a matching pubkey for the person you chat with using EDS.
>First, apologies for filing the dupe. No worries. >Second: nice to see a gaim plugin is considered, but what exactly is the status >on this? Is someone actively working on this? If yes, what is the timeframe, is >gaim 1.x or 2.x targeted and is there working code to build on? No, it's not actively worked on. Before you reminded me of eds, I was blocking on our DBUS implementation. With eds the plugin can be built within the seahorse source tree and use libseahorse. I can't imagine targetting it at 1.x at the moment. No working code, but gaim plugins are relatively simple creatures. >Another question that popped up is conversation history: will conversations be >saved encrypted or decrypted? This is perhaps a very subjective question and >should be left open as an option. That's the subject of an entirely different plugin. I think like gaim-encryption, logs will be clear text. >As for the "what to do to show that a conversation is encrypted", in the case >of gaim 2.x I would modify the window/tab title to not only show "$NICK" but >"$NICK [secure]" or something like that, perhaps overlaying a small icon to the >protocol/buddy icon as well. Additionaly, I imagine a button added to the >formatting toolbar, something like an open lock to show encryption is off. The >user can press this button and after the peer's gpg key is set (or found via >eds), we will send messages encrypted. The button will then have a "pressed" >state and the icon will be changed to a closed lock. In the case of a >non-encrypted message, a dialog should pop up telling the user that the peer >probably doesn't want/can't handle encryption and give the options to either >stay in encryption mode or return to cleartext mode. I imagine something like gaim-encryptions UI would be needed. Changing the text in the tab could make it uselessly long especially with long aliases already. >There is also the possibility of taking an approach similar to what firefox >does for showing that security is in place: visit a https:// url, firefox will >change the background in the location entry field from white to yellow. This >could also be done in gaim's conversation window. This is bad, see comment #2.
> With eds the plugin can be built within the seahorse source tree and > use libseahorse. I can't imagine targetting it at 1.x at the moment. > No working code, but gaim plugins are relatively simple creatures. So - are you planning to work on this in the near future or not? Even a "raw" version (eg, missing the "hard" parts like when keys can't be found via EDS) would be nice =) and if there was a base I could even have a look at it and perhaps contribute something useful. I would target gaim 2.0, too... gaim 1.x is basicly dead now. > That's the subject of an entirely different plugin. I think like > gaim-encryption, logs will be clear text. What I had in mind was storing the encrypted text into the logs but thinking about it, that's nonsene anyway... > I imagine something like gaim-encryptions UI would be needed. > Changing the text in the tab could make it uselessly long > especially with long aliases already. Right, or in the case where many tabs are used... But I think changing the icon (stock protocol icon with lock overlayed looks quite nice; I used jimmac's tanto icon for network-manager for this¹ As for gaim-encryptions UI, Gaim 2.x doesn't have the toolbar Game 1.x had, so you are basicly forced to use the formatting toolbar like shown in my mockup. Also, I think dividing incoming and outgoing like gaim-encryption does is not needed: if someone sends a gpg'ed message to us and we can decrypt it, we can also (and want to!) send back encrypted. If we send encrypted and the other side can decrypt, then he is also able to answer encrypted. If he choses to reply unencrypted anyway, popping up a dialog asking us what to do (keep sending encrypted or revert to sending plain text) is the right thing to do. [1] http://jimmac.musichall.cz/wipicons/NetworkManager/16x16/nm-vpn-lock.png
(In reply to comment #17) > So - are you planning to work on this in the near future or not? Even > a "raw" version (eg, missing the "hard" parts like when keys can't be > found via EDS) would be nice =) and if there was a base I could even > have a look at it and perhaps contribute something useful. I would > target gaim 2.0, too... gaim 1.x is basicly dead now. I'm a graduate student, so a plugin of this magnitude would have to wait till after finals at the beginning of next month. > Also, I think dividing incoming and outgoing like gaim-encryption > does is not needed: if someone sends a gpg'ed message to us and we > can decrypt it, we can also (and want to!) send back encrypted. If > we send encrypted and the other side can decrypt, then he is also > able to answer encrypted. If he choses to reply unencrypted anyway, > popping up a dialog asking us what to do (keep sending encrypted > or revert to sending plain text) is the right thing to do. There will need to be some key request/fetching capability. I think it will need to be split somehow.
Development thoughts using libcryptui, DBUS and libebook: http://live.gnome.org/Seahorse/GaimPluginDevelopment At the moment I've only created the automake framework required to build any future work.
Created attachment 67991 [details] [review] Autoconf/make magic
Created attachment 67992 [details] Gaim Dir This archive needs to be extracted in plugins/. After applying the build patch above, extracting the archive, one should rerun ./autogen.sh. The code will build and install. GPG Encryption should now be available as a gaim plugin. *status* * Plugin loads and unloads * Preferences frame loads correctly - Prefs load and save - Signer can be set - Associations can be deleted * Window UI is partially completed but not finished enough to warrant calling these functions in load yet. * Encryption is totally unimplemented (aside from the existing DBUS interface) I will accept unified diffs against this tarball as attachments to the bug and will then post a new tarball until this hits cvs.
Howdy -- I had a couple concerns about the cryptographic integrity of this system, and so I wanted to ask some questions. Is this system going to be using the PGP key to generate a one-time session key? I only suggest this because using a PGP key as the cipher for creating lots of really short ciphertext (e.g. LOL, ROFL, WTF, OMG) does diminish the overall cryptographic integrity of a PGP key. This may be an irrelevant concern since a public key is public so cyphertext can be generated by anybody. If not a session key, since anybody can generate valid ciphertext with a person's public key, I wanted to make sure you're considering how to avoid replay attacks with timestamps, random bits, and such. Finally, I hope you're going to be digitally signing the messages as well to ensure non-repudiation of messages. Anyways, looking forward to a standardized encryption scheme for IM. Cheers. -jag
You mean... similar to what (I think) silc does? No, from what I can make out after qickly scanning trough the code, you select a private key from the system keyring. Well, you are right that this is not 100% secure. But could someone explain how easy (or even possible) it is for a attacker to reconstruct a full 4096 bit private key from a few known messages? Signing is an option. How do other IM apps handle this? Does e.g. Kopete sign encrypted messages? If those other apps do, the preference to sign should perhaps be removed and always be used. In the end, this approach is not the greatest, but it's perhaps the only way to get some degree of security into the existent protocols. But the problem remains that only the actual text part is encrypted and the rest of the message is unchanged
In talking with Alan Humpherys of the Fire project, they simply encrypt and sign the message text. To keep the length of the bug down, I'll add their implementation details to the development document on l.g.o. As far as I can tell, the only IM client/plugin combo that has used a session key is gaim-e which is long since dead. My goal is compatibility with the other FOSS GPG IM encryption systems because the system is useless if you can't use it to talk to somebody else. The problem with short text may not be a problem. If I recall correctly, OpenPGP already uses a session key of sorts. That is why you can encrypt a mesaage or file to multiple people. The message is encrypted with the session key and then the session key is encrypted with the person's public key.
The issue lies not in attacks against the key itself, but rather in GPG-signing messages like "Yes", "No", "Go ahead", "Sounds good", and so on. If you don't include some form of replay prevention mechanism (unique session key and timestamp, for example), people can use such signed messages to fake the same responses from you. The informal nature of IM makes this more likely to occur, as compared to emails which typically include much more context.
Because gpg signatures already contain a time stamp, would checking that with some threshold based on the current time be sufficient even though the timestamp isn't independently verified? This will at least limit the vulnerability to a replay attack to within the threshold. If the message wasn't signed within the threshold, a warning dialog would be displayed. Some changes to the DBUS interface will be necessary.
Just a note to say that this has moved in a new direction and I am working on implementing this functionality as part of gaim-encryption.
Oh... how does that fit with gaim-encryption's current approach? Will gaim-encryption offer a gpg mode that is compatible with other client's gpg plugins or will this be gaim only again? Also, is there already code for this somewhere?
gaim-encryption has always had gpg stubs as an example of how to add an additional encryption protocol. This is sadly at the moment gaim only, but any client can easily implement the same protocol g-e has. This could in fact be split out into a seperate library, Bill Tomkins the g-e maintainer welcomes such patches. I'll attach my latest diff, but there are a few caveats: * Encryption doesn't work see bug #348594 * Key selection UI isn't quite where I'd like it yet, we're not actually generating keys so the dialog doesn't quite fit. Suggestions/patches welcome. That's about it, the key to use is passed using our D-Bus interface's identifier and it's found useing the DiscoverKeys method on the other end (not yet called asychronously).
Created attachment 69670 [details] [review] patch against gaim-encryption CVS HEAD
So it's more than half a year now and gaim-encryption doesn't seem to be interested in GnuPG integration. On the other hand, Gaim (now Pidgin¹) development is speeding up again and judging from IRC, Psi-etc compatible GPG support seems to be high on the wishlist of many users (I've seen the topic coming up multiple times a week). Usually people are pointed to this staled effort or either gaim-encryption or gaim-otr (both of which are not compatible with other clients) So, is there a reason why seahorse doesn't provide a very simple Gaim/Pidgin plugin which does the basic GPG encryption so many clients (Kopete, Gajim, Psi, Miranda, just t o name a few) support out of the box? I would really love to see this finally happening after all... [1] http://developer.pidgin.im/
Welcome to the club, unfortunately while a large portion of the gaim-encryption architecture in place is good, how they do the actual encryption and signing is not amenable to how gpg works. I searched around and tried to find some documentation for Psi's implementation and couldn't find it. From [1] it looks like they may be just passing std encrypted messages across the line. Is there someone in particular that uses this psi client and gpg that wants to work on this with me? I found a link [2] that claims that psi and Jabber in general use [3] as their protocol. If this is the case, I'm not sure how it could be extended to other protocols cleanly (perhaps there's someone more familiar with the various im protocols that could weigh in) and quite frankly I'm not interested in supporting just Jabber because no one I chat with uses it. Which leaves option 3 which involves creating a new line protocol that's incompatible with current implementations. Why oh why can we not just send regular encrypted text blocks and add a UID to our keys with appropriate screen names/nicks? *shakes fist at XML/Jabber stupidity* [1] http://dev.psi-im.org/websvn/filedetails.php?repname=Psi&path=%2Ftrunk%2Fsrc%2Fpgputil.cpp [2] http://trac.adiumx.com/ticket/559 [3] http://www.xmpp.org/extensions/xep-0027.html
seahorse-plugins is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/257 It had its last code changes many years ago: https://gitlab.gnome.org/GNOME/seahorse-plugins/-/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.