From Byrd.B at insightcom.com Wed Feb 1 10:09:08 2012 From: Byrd.B at insightcom.com (Byrd, Brendan) Date: Wed, 1 Feb 2012 15:09:08 +0000 Subject: [OTR-dev] OTR and Cold Boot Attacks In-Reply-To: <033e01cccd98$6a094fe0$3e1befa0$@cs.uwaterloo.ca> References: <033e01cccd98$6a094fe0$3e1befa0$@cs.uwaterloo.ca> Message-ID: Modifying Pidgin isn't out of the question, but a bug report would need to be added there. -- Brendan Byrd System Integration Analyst (NOC Web Developer) -----Original Message----- From: otr-dev-bounces at lists.cypherpunks.ca [mailto:otr-dev-bounces at lists.cypherpunks.ca] On Behalf Of Rob Smits Sent: Saturday, January 07, 2012 7:00 PM To: otr-dev at lists.cypherpunks.ca Subject: Re: [OTR-dev] OTR and Cold Boot Attacks Hi Justin, Unfortunately there are some complications with fixing this completely. In terms of libotr, it would be pretty simple to garble the memory it allocates for decrypted messages before freeing it (in otrl_message_free). However libotr can't guarantee that the contents weren't copied elsewhere. In terms of pidgin-otr, we are out of luck. It will in fact make a copy of the contents of a decrypted message and provide this copy to pidgin. Pidgin-otr then has no way to know when pidgin will free this memory. Without modifying pidgin I don't think there is a way around this. Regards, Rob > -----Original Message----- > From: otr-dev-bounces at lists.cypherpunks.ca [mailto:otr-dev- > bounces at lists.cypherpunks.ca] On Behalf Of Justin Bull > Sent: January-02-12 7:27 PM > To: otr-dev at lists.cypherpunks.ca > Subject: [OTR-dev] OTR and Cold Boot Attacks > > Hello otr-dev, > > I've been doing some minor research into cold boot attacks. I found > OTR quite susceptible to this type of attack. I propose that the code > is updated to > zero-out or garble the allocated memory used for storing the IM > conversations prior to freeing it back to the OS. This would mimic TrueCrypt's > strategy to mitigating success of such an attack. > > See TrueCrypt's acknowledgement here: > http://www.truecrypt.org/docs/?s=unencrypted-data-in-ram > > > "Keep in mind that most programs do not clear the memory area > > (buffers) > in which they store unencrypted (portions of) files [...] This means > that after > you exit such a program, unencrypted data it worked with may remain in > memory (RAM) until the computer is turned off (and, according to some > researchers, even for some time after the power is turned off*)." > > > "When a non-system TrueCrypt volume is dismounted, TrueCrypt erases > > its > master keys (stored in RAM)." > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev _______________________________________________ OTR-dev mailing list OTR-dev at lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev From nathan at guardianproject.info Thu Feb 23 14:21:55 2012 From: nathan at guardianproject.info (Nathan of Guardian) Date: Thu, 23 Feb 2012 14:21:55 -0500 Subject: [OTR-dev] Adding SMP to Gibberbot/OTR4J Message-ID: <4F4691D3.4030802@guardianproject.info> One of our core volunteers (devrandom) has implemented a patch for the OTR4J (http://code.google.com/p/otr4j/), which is used by our Gibberbot app, to add the Socialist Millionaire Protocol implementation used by the java-otr library. He has also created an API around the library by which we can integrate the user interface functions required to handle the interaction. You can review the pull request here if you have the time or inclination to do so. We would greatly appreciate any comments, especially from the original authors of java-otr: https://github.com/guardianproject/Gibberbot/pull/110 This is a sample command line app for testing: https://github.com/devrandom/Gibberbot/blob/163db8633f369b8ef9e7e2e3a38f0d0071fa28bf/otr-sample/src/info/guardianproject/otr/app/SampleApp.java We'll be doing a more integrated review and audit as we merge it into Gibberbot, and will keep you informed as we plan to release this function in the near future. Best, Nathan From gp at superpointer.com Thu Feb 23 18:35:43 2012 From: gp at superpointer.com (George Politis) Date: Fri, 24 Feb 2012 00:35:43 +0100 Subject: [OTR-dev] Adding SMP to Gibberbot/OTR4J In-Reply-To: <4F4691D3.4030802@guardianproject.info> References: <4F4691D3.4030802@guardianproject.info> Message-ID: <4F46CD4F.6000800@superpointer.com> Hello Nathan, This is very nice work and great news. SMP support had never been properly implemented in otr4j (I had barely started working on it) and was something I wanted to finish for a long time. I'll make sure changes are pushed upstream. Regards, George On 02/23/2012 08:21 PM, Nathan of Guardian wrote: > > One of our core volunteers (devrandom) has implemented a patch for the > OTR4J (http://code.google.com/p/otr4j/), which is used by our Gibberbot > app, to add the Socialist Millionaire Protocol implementation used by > the java-otr library. He has also created an API around the library by > which we can integrate the user interface functions required to handle > the interaction. > > You can review the pull request here if you have the time or inclination > to do so. We would greatly appreciate any comments, especially from the > original authors of java-otr: > https://github.com/guardianproject/Gibberbot/pull/110 > > This is a sample command line app for testing: > https://github.com/devrandom/Gibberbot/blob/163db8633f369b8ef9e7e2e3a38f0d0071fa28bf/otr-sample/src/info/guardianproject/otr/app/SampleApp.java > > We'll be doing a more integrated review and audit as we merge it into > Gibberbot, and will keep you informed as we plan to release this > function in the near future. > > Best, > Nathan > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev From nathan at guardianproject.info Thu Feb 23 20:01:38 2012 From: nathan at guardianproject.info (Nathan of Guardian) Date: Thu, 23 Feb 2012 20:01:38 -0500 Subject: [OTR-dev] Adding SMP to Gibberbot/OTR4J In-Reply-To: <4F46CD4F.6000800@superpointer.com> References: <4F4691D3.4030802@guardianproject.info> <4F46CD4F.6000800@superpointer.com> Message-ID: <4F46E172.9030603@guardianproject.info> On 02/23/2012 06:35 PM, George Politis wrote: > This is very nice work and great news. SMP support had never been > properly implemented in otr4j (I had barely started working on it) and > was something I wanted to finish for a long time. I'll make sure changes > are pushed upstream. Thanks for the feedback, George. We'll make sure to ping you once it is committed, and coordinate the push. Here is a related post, btw, on the work we are doing trying to create an OTR keystore converter. In short, people want to sync their Pidgin and Gibberbot keys, both private and verified public, and we are trying to figure out how to do that. https://guardianproject.info/2012/02/23/how-many-ways-to-store-5-numbers/ +n From dimitris at census-labs.com Sat Feb 25 11:19:59 2012 From: dimitris at census-labs.com (Dimitris Glynos) Date: Sat, 25 Feb 2012 18:19:59 +0200 Subject: [OTR-dev] private messages on dbus In-Reply-To: <4EF12D25.1040403@census-labs.com> References: <4EF05D3E.5020907@census-labs.com> <4EF12D25.1040403@census-labs.com> Message-ID: <4F490A2F.1030601@census-labs.com> On 12/21/2011 02:49 AM, Dimitris Glynos wrote: > On 12/21/2011 01:11 AM, khc at hxbc.us wrote: >> On Tue, 20 Dec 2011 12:02:38 +0200, Dimitris Glynos wrote: >>> Hello all, >>> >>> I was wondering if pidgin could allow for certain chat types >>> to be flagged as private and not transmit these over dbus. >>> I don't know how much dbus is hardwired to pidgin (is it used >>> also for capturing the messages displayed on the pidgin GUI?) >>> but the fact that a local attacker can access OTR plaintext >>> from a dbus session monitor is quite unnerving. >> >> a local attacker can already ptrace the pidgin process and do >> pretty much anything. > > Yes, the word 'local' is used incorrectly in the original post. > Consider a remote attacker that exploits some app running > in the same desktop session as pidgin. It is trivial > to fork-exec a dbus session monitor from there and retrieve the > sensitive info. > > Now, regarding ptrace although it was generally possible in > the past to attach to processes of the same user, this has > been restricted somewhat in modern distro's. Specifically, > distro's like Ubuntu allow (non-root) ptrace only to > processes that are children of the ptrace-caller. > > For more info on this, have a look here: > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection > > Hope this clarifies things a bit, Coming back to this after a while. You may now find an advisory and a proof-of-concept script for the DBUS info leak here: http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/ This issue has received CVE-2012-1257. It would be good to see this issue addressed in the next release of pidgin and pidgin-otr. Most users would be surprised to find that their private chatting is somehow accessible to other apps.. Best regards, Dimitris -- http://census-labs.com -- IT security research, development and services From Byrd.B at insightcom.com Mon Feb 27 12:28:14 2012 From: Byrd.B at insightcom.com (Byrd, Brendan) Date: Mon, 27 Feb 2012 17:28:14 +0000 Subject: [OTR-dev] private messages on dbus In-Reply-To: <4F490A2F.1030601@census-labs.com> References: <4EF05D3E.5020907@census-labs.com> <4EF12D25.1040403@census-labs.com> <4F490A2F.1030601@census-labs.com> Message-ID: Wait, are we talking about the potential for an attacker to: 1. Load a Trojan/Virus on their PC that allows remote access 2. ...Who the $^#% cares at that point?! Once security has been breached at point #1, it doesn't matter. The PC is already impacted. Re-format, restart, reload, and change all of your security information, passwords, keys, etc. The private key is already vulnerable. Hell, -memory- is already vulnerable. Everything is in plaintext if you find the right memory location. There's no way to fix that, especially if the attacker has admin/root access. Everything is compromised. There's no point in trying to lock down the app for that sort of critical security failure. "The best way to protect a server is to unplug the network cable, put it in a lock box, throw away the key, and bury it. Even then, there's still a small chance it might be compromised." -- Brendan Byrd System Integration Analyst (NOC Web Developer) -----Original Message----- From: otr-dev-bounces at lists.cypherpunks.ca [mailto:otr-dev-bounces at lists.cypherpunks.ca] On Behalf Of Dimitris Glynos Sent: Saturday, February 25, 2012 11:20 AM To: devel at pidgin.im Cc: otr-dev at lists.cypherpunks.ca Subject: Re: [OTR-dev] private messages on dbus On 12/21/2011 02:49 AM, Dimitris Glynos wrote: > On 12/21/2011 01:11 AM, khc at hxbc.us wrote: >> On Tue, 20 Dec 2011 12:02:38 +0200, Dimitris Glynos wrote: >>> Hello all, >>> >>> I was wondering if pidgin could allow for certain chat types to be >>> flagged as private and not transmit these over dbus. >>> I don't know how much dbus is hardwired to pidgin (is it used also >>> for capturing the messages displayed on the pidgin GUI?) but the >>> fact that a local attacker can access OTR plaintext from a dbus >>> session monitor is quite unnerving. >> >> a local attacker can already ptrace the pidgin process and do pretty >> much anything. > > Yes, the word 'local' is used incorrectly in the original post. > Consider a remote attacker that exploits some app running in the same > desktop session as pidgin. It is trivial to fork-exec a dbus session > monitor from there and retrieve the sensitive info. > > Now, regarding ptrace although it was generally possible in the past > to attach to processes of the same user, this has been restricted > somewhat in modern distro's. Specifically, distro's like Ubuntu allow > (non-root) ptrace only to processes that are children of the > ptrace-caller. > > For more info on this, have a look here: > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Pr > otection > > Hope this clarifies things a bit, Coming back to this after a while. You may now find an advisory and a proof-of-concept script for the DBUS info leak here: http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/ This issue has received CVE-2012-1257. It would be good to see this issue addressed in the next release of pidgin and pidgin-otr. Most users would be surprised to find that their private chatting is somehow accessible to other apps.. Best regards, Dimitris -- http://census-labs.com -- IT security research, development and services _______________________________________________ OTR-dev mailing list OTR-dev at lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev From paul at cypherpunks.ca Mon Feb 27 17:38:45 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 27 Feb 2012 17:38:45 -0500 (EST) Subject: [OTR-dev] Adding SMP to Gibberbot/OTR4J In-Reply-To: <4F46E172.9030603@guardianproject.info> References: <4F4691D3.4030802@guardianproject.info> <4F46CD4F.6000800@superpointer.com> <4F46E172.9030603@guardianproject.info> Message-ID: On Thu, 23 Feb 2012, Nathan of Guardian wrote: > Here is a related post, btw, on the work we are doing trying to create > an OTR keystore converter. In short, people want to sync their Pidgin > and Gibberbot keys, both private and verified public, and we are trying > to figure out how to do that. > > https://guardianproject.info/2012/02/23/how-many-ways-to-store-5-numbers/ I am pondering writing an RFC for a new DNS RRTYPE to store OTR fingerprints in DNS(SEC) where there is a similar issue. Depending on the compatibility of the algorithms, one can use the DNSKEY format, or the SubjectPublicKeyInfo format. Designing a new format seems like a less good idea. The DNSKEY one is simpler, but it is less flexible, for instance it has only one type of RSA, whereas the SPKI can define the different kind of RSA keys. Paul From paul at cypherpunks.ca Mon Feb 27 17:43:40 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 27 Feb 2012 17:43:40 -0500 (EST) Subject: [OTR-dev] private messages on dbus In-Reply-To: <4F490A2F.1030601@census-labs.com> References: <4EF05D3E.5020907@census-labs.com> <4EF12D25.1040403@census-labs.com> <4F490A2F.1030601@census-labs.com> Message-ID: On Sat, 25 Feb 2012, Dimitris Glynos wrote: >>>> I was wondering if pidgin could allow for certain chat types >>>> to be flagged as private and not transmit these over dbus. >>>> I don't know how much dbus is hardwired to pidgin (is it used >>>> also for capturing the messages displayed on the pidgin GUI?) >>>> but the fact that a local attacker can access OTR plaintext >>>> from a dbus session monitor is quite unnerving. >>> >>> a local attacker can already ptrace the pidgin process and do >>> pretty much anything. not neccessarilly. For instance with SElinux or AppArmor you can take that ability away from the process. > Coming back to this after a while. You may now find an advisory > and a proof-of-concept script for the DBUS info leak here: > > http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/ > > This issue has received CVE-2012-1257. > > It would be good to see this issue addressed in the next release > of pidgin and pidgin-otr. Most users would be surprised to find > that their private chatting is somehow accessible to other apps.. I am still a bit confused how serious this issue really is. If you can read as the uid of the user, you can already read the OTR keys from disk. Now PFS will prevent decrypting, but whether you listen in on dbus or the X11 channels doesnt really matter much. So I see value in protecting the pidgin process from reading OTR materials outside pidgin-otr, and hardening pidgin against network input, I see less value into closing the dbus from the user for themselves. Paul From dimitris at census-labs.com Mon Feb 27 17:53:10 2012 From: dimitris at census-labs.com (Dimitris Glynos) Date: Tue, 28 Feb 2012 00:53:10 +0200 Subject: [OTR-dev] private messages on dbus In-Reply-To: References: <4EF05D3E.5020907@census-labs.com> <4EF12D25.1040403@census-labs.com> <4F490A2F.1030601@census-labs.com> Message-ID: <4F4C0956.7040004@census-labs.com> On 02/28/2012 12:43 AM, Paul Wouters wrote: > I am still a bit confused how serious this issue really is. If you can > read as the uid of the user, you can already read the OTR keys from > disk. Now PFS will prevent decrypting, but whether you listen in on dbus > or the X11 channels doesnt really matter much. So I see value in > protecting the pidgin process from reading OTR materials outside > pidgin-otr, and hardening pidgin against network input, I see less value > into closing the dbus from the user for themselves. Paul the real problem here is broadcasting sensitive info over DBUS. If the sender chooses not to log this info so that they don't end up on the disk, there is no way for pidgin to enforce the same security policy to the 3rd party (possibly unrelated) apps that sit on the other end of DBUS. Such an app might accidentally log these messages because it cannot qualify that they were meant to be private. Hope this helps, Dimitris From hyc at symas.com Mon Feb 27 18:01:45 2012 From: hyc at symas.com (Howard Chu) Date: Mon, 27 Feb 2012 15:01:45 -0800 Subject: [OTR-dev] pidgin-otr rewrite In-Reply-To: <4EED7D4C.8030806@bleeter.id.au> References: <4EECB18F.9030305@symas.com> <4EED7D4C.8030806@bleeter.id.au> Message-ID: <4F4C0B59.7020103@symas.com> Peter Lawler wrote: >> I've spent a couple days rewriting the pidgin-otr-3.2.0 plugin to only use >> libpurple, so that the plugin will work with finch. I've just now gotten >> something running, so I thought I'd post a snapshot of my changes to get some >> early feedback. You'll also need the latest finch source with my patch here >> >> http://developer.pidgin.im/ticket/14818 > I've added some tags to that ticket and will try and catch up with the > GNT/Finch folks over the coming week and see how they feel about it. My > gut instinct is they'll be happy someone's supplied a patch to extend > Finch's plugin support capabilities. Whether they'll be happy to merge > it before 2.10.2, I can't possibly say. Will see how they feel about (as > per your comment on the ticket) where in the source it should go. Thanks again for your help. All of my pidgin/finch patches were merged upstream, so that's out of the way. Still looking for feedback from this group about the changes I made to the plugin, and whether/how it can be incorporated into the official source here. Has anyone here tried it out? Any reactions to the UI changes I made? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc at symas.com Mon Feb 27 18:09:59 2012 From: hyc at symas.com (Howard Chu) Date: Mon, 27 Feb 2012 15:09:59 -0800 Subject: [OTR-dev] private messages on dbus In-Reply-To: <4F4C0956.7040004@census-labs.com> References: <4EF05D3E.5020907@census-labs.com> <4EF12D25.1040403@census-labs.com> <4F490A2F.1030601@census-labs.com> <4F4C0956.7040004@census-labs.com> Message-ID: <4F4C0D47.1080600@symas.com> Dimitris Glynos wrote: > On 02/28/2012 12:43 AM, Paul Wouters wrote: >> I am still a bit confused how serious this issue really is. If you can >> read as the uid of the user, you can already read the OTR keys from >> disk. Now PFS will prevent decrypting, but whether you listen in on dbus >> or the X11 channels doesnt really matter much. So I see value in >> protecting the pidgin process from reading OTR materials outside >> pidgin-otr, and hardening pidgin against network input, I see less value >> into closing the dbus from the user for themselves. > > Paul the real problem here is broadcasting sensitive info > over DBUS. If the sender chooses not to log this info > so that they don't end up on the disk, there is no way > for pidgin to enforce the same security policy to the > 3rd party (possibly unrelated) apps that sit on the > other end of DBUS. Such an app might accidentally log these > messages because it cannot qualify that they were meant to be > private. That sounds like a bug in the 3rd party code then, since pidgin marks its messages with PURPLE_MESSAGE_NO_LOG if they should not be logged, and the otr plugin will turn off conversation logging if the user chooses that. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From dimitris at census-labs.com Mon Feb 27 18:35:00 2012 From: dimitris at census-labs.com (Dimitris Glynos) Date: Tue, 28 Feb 2012 01:35:00 +0200 Subject: [OTR-dev] private messages on dbus In-Reply-To: <4F4C0D47.1080600@symas.com> References: <4EF05D3E.5020907@census-labs.com> <4EF12D25.1040403@census-labs.com> <4F490A2F.1030601@census-labs.com> <4F4C0956.7040004@census-labs.com> <4F4C0D47.1080600@symas.com> Message-ID: <4F4C1324.4080906@census-labs.com> On 02/28/2012 01:09 AM, Howard Chu wrote: > Dimitris Glynos wrote: >> On 02/28/2012 12:43 AM, Paul Wouters wrote: >>> I am still a bit confused how serious this issue really is. If you can >>> read as the uid of the user, you can already read the OTR keys from >>> disk. Now PFS will prevent decrypting, but whether you listen in on dbus >>> or the X11 channels doesnt really matter much. So I see value in >>> protecting the pidgin process from reading OTR materials outside >>> pidgin-otr, and hardening pidgin against network input, I see less value >>> into closing the dbus from the user for themselves. >> >> Paul the real problem here is broadcasting sensitive info >> over DBUS. If the sender chooses not to log this info >> so that they don't end up on the disk, there is no way >> for pidgin to enforce the same security policy to the >> 3rd party (possibly unrelated) apps that sit on the >> other end of DBUS. Such an app might accidentally log these >> messages because it cannot qualify that they were meant to be >> private. > > That sounds like a bug in the 3rd party code then, since pidgin marks > its messages with PURPLE_MESSAGE_NO_LOG if they should not be logged, > and the otr plugin will turn off conversation logging if the user > chooses that. Well, actually it doesn't do that :-) I have logging disabled, but as you can see below the other end of DBUS only sees PURPLE_MESSAGE_SEND / PURPLE_MESSAGE_RECV switched on. signal sender=:1.11 -> dest=(null destination) path=/im/pidgin/purple/PurpleObject; interface=im.pidgin.purple.PurpleInterface; member=WroteImMsg int32 66666 string "anonymized at example.com" string "this is a test" int32 77777 uint32 1 <------------- PURPLE_MESSAGE_SEND ... signal sender=:1.11 -> dest=(null destination) path=/im/pidgin/purple/PurpleObject; interface=im.pidgin.purple.PurpleInterface; member=ReceivedImMsg int32 66666 string "anonymized at example.com" string "ok" int32 77777 uint32 2 <------------- PURPLE_MESSAGE_RECV And I mentioned logging only as an example. There is no way to make sure that the 3rd party apps on the other end of DBUS adhere to the same security policies enforced by the sender. So, a suggestion is to create a new type for private messages. By default private messages should not be broadcasted over DBUS or be logged. Users will have the option of changing this if they want to. Regards, Dimitris From hyc at symas.com Mon Feb 27 19:06:35 2012 From: hyc at symas.com (Howard Chu) Date: Mon, 27 Feb 2012 16:06:35 -0800 Subject: [OTR-dev] private messages on dbus In-Reply-To: <4F4C1324.4080906@census-labs.com> References: <4EF05D3E.5020907@census-labs.com> <4EF12D25.1040403@census-labs.com> <4F490A2F.1030601@census-labs.com> <4F4C0956.7040004@census-labs.com> <4F4C0D47.1080600@symas.com> <4F4C1324.4080906@census-labs.com> Message-ID: <4F4C1A8B.70406@symas.com> Dimitris Glynos wrote: > On 02/28/2012 01:09 AM, Howard Chu wrote: >> Dimitris Glynos wrote: >>> On 02/28/2012 12:43 AM, Paul Wouters wrote: >>>> I am still a bit confused how serious this issue really is. If you can >>>> read as the uid of the user, you can already read the OTR keys from >>>> disk. Now PFS will prevent decrypting, but whether you listen in on dbus >>>> or the X11 channels doesnt really matter much. So I see value in >>>> protecting the pidgin process from reading OTR materials outside >>>> pidgin-otr, and hardening pidgin against network input, I see less value >>>> into closing the dbus from the user for themselves. >>> >>> Paul the real problem here is broadcasting sensitive info >>> over DBUS. If the sender chooses not to log this info >>> so that they don't end up on the disk, there is no way >>> for pidgin to enforce the same security policy to the >>> 3rd party (possibly unrelated) apps that sit on the >>> other end of DBUS. Such an app might accidentally log these >>> messages because it cannot qualify that they were meant to be >>> private. >> >> That sounds like a bug in the 3rd party code then, since pidgin marks >> its messages with PURPLE_MESSAGE_NO_LOG if they should not be logged, >> and the otr plugin will turn off conversation logging if the user >> chooses that. > > Well, actually it doesn't do that :-) Ah you're right, my mistake. Sounds to me like, independent of any other issues, it *should* do that. > And I mentioned logging only as an example. There is no way to make > sure that the 3rd party apps on the other end of DBUS adhere > to the same security policies enforced by the sender. True. > So, a suggestion is to create a new type for private messages. > By default private messages should not be broadcasted over DBUS > or be logged. Users will have the option of changing this > if they want to. Unfortunately, the purple API only lets the receiving-*-msg handler touch the msgflags. For sending, the flags aren't passed along, so this would require another API change to accommodate that. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/