[OTR-dev] private messages on dbus

[Howard Chu]

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/