--nextPart1276587.GGCSDKFPjy
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 13 July 2006 01:50, David Jarvie wrote:
> KAlarm and kalarmd need to interact via D-Bus. If some other
> application made certain D-Bus calls, alarms could be lost.=20

Only if those applications were malicious. If you expect things to get=20
lost due to bugs, I suggest you take a long look at the interaction you=20
have via dbus since that may need some work ;)

> So it seems=20
> a sensible precaution to check the sender (just as was done in KDE 3
> using DCOP).

Well, in this case I can see how someone might want to write a kalarm=20
replacement in their own way. There are lots of things I can think about=20
where this is usefull. For example one of the online TVGuide providers=20
that have a Java swing client might want to add an alarm to kalarmd=20
instead of inventing their own alarm daemon.

What you are suggesting is to close the alarms modification to one client=20
only. I think this is fundamentally the wrong path to walk down.

If you are concerned with trojans that remove the alarms, then I don't=20
know what to answer except that there are a lot easier way to corrupt the=20
alarms. Simply killing the daemon might be one of them.

=2D-=20
Thomas Zander

--nextPart1276587.GGCSDKFPjy
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBEthL3CojCW6H2z/QRAsvHAJsEYOHVNKpgJyGyLZK32Y/Cjwmx6ACdGpiG
Fs7Lp5wdDsrOht0MHdCnsVM=
=nAZY
-----END PGP SIGNATURE-----

--nextPart1276587.GGCSDKFPjy--