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/
_______________________________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
