[OTR-dev] private messages on dbus
hyc at symas.com
Mon Feb 27 19:06:35 EST 2012
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
>> 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.
> 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/
More information about the Devel