diff options
author | Simon McVittie <simon.mcvittie@collabora.co.uk> | 2013-10-02 16:33:42 +0100 |
---|---|---|
committer | Simon McVittie <simon.mcvittie@collabora.co.uk> | 2013-10-02 17:41:36 +0100 |
commit | 17a5d31769e9da52797df968c8881732f29d0f45 (patch) | |
tree | a8268dde6bcc4ffd5c91d9ffa0ef4850393b3a4d /NEWS | |
parent | d0af8d654ae439a1a333c33f6e44084d3dad2afb (diff) | |
download | telepathy-mission-control-17a5d31769e9da52797df968c8881732f29d0f45.tar.gz |
NEWS: adjust note about ServerAuthentication handlers
rishi pointed out on IRC that ServerAuthentication still makes
passwords available to eavesdroppers on the session bus (if LOGIN,
PLAIN or X-TELEPATHY-PASSWORD are used). ServerAuthentication doesn't
allow arbitrary applications to ask MC "what is the password for
account X?", which is what I was thinking of.
The session bus is not generally modelled to be a security
boundary; if yours is, you will need to write a security policy,
then ensure that that policy is applied. Telepathy components are not
designed to be used unmodified on an untrusted session bus. (Starting
points include turning off eavesdropping, applying a "default-deny"
policy, preventing processes other than Mission Control from
calling HandleChannels on your ServerAuthentication client, and
preventing processes from subverting each other with ptrace.)
Diffstat (limited to 'NEWS')
-rw-r--r-- | NEWS | 3 |
1 files changed, 1 insertions, 2 deletions
@@ -38,8 +38,7 @@ Enhancements: (fd.o #56635, Simon) • Remove gnome-keyring integration in favour of recommending - ServerAuthentication Handlers, which have better UI and don't expose - passwords on D-Bus (fd.o #32578, Simon) + ServerAuthentication Handlers, which have better UI (fd.o #32578, Simon) • Internal cleanup related to the connectivity code (fd.o #68712, Simon) |