Develop clearly needs to be aware of whatever solution we come up with for activity updates. This means that Develop has to be able to do the signing. Right now, bitfrost does not give out the private key to activities (correctly) and does not allow activities to request a signature for something (wrongly - there is a P_IDENT bitfrost privilege which should allow activities which have it to sign things).<br>
<br>I raised this issue on IRC and got two responses.<br><br>1. neuralis/ ivan krstic was the security guy on the team and he has just left. Do not expect this to be fixed soon.<br><br>2. Do not try to fix this yourself, as security must be done right or not at all.<br>
<br>(apologies for stripping the nuances)<br><br>I disagree with #2. Security must not be done wrong, but it can be done partially if we think things through. Adding a hook so that activities with P_IDENT can request signatures, without seeing the private key, is IMO safe and simple enough to be worth doing if it helps us with activity updates.<br>
<br>(More summary from IRC: the tricky, unresolved issue is key trust - does a given public key mean what we think it means? This is separate from key security. Let me give a scenario.<br><br>Activities spread virally by sharing. Alicia codes a new activity V1 and signs it, it starts to spread. Bad Bob replaces Alicia's sig with his own and keeps spreading it. Now Bad Bob can add his malicious code to the activity later, and all the people who got the activity downstream from him will automatically update to the malicious version.<br>
<br>To me this is not a problem, because Bob could have added his code to the activity in the first place. It just lets him be a little lazier. It is 100% equivalent if Bob had added some general-purpose trojan to the app immediately, so auto-update has not created any new vulnerabilities. Also, if there are two versions of the same activity floating around with different signatures, noticeable things will start to happen - either someone downstream from Bob will get an update from Alicia that will mysteriously fail to autoinstall, or vice versa.)<br>
<br><div class="gmail_quote">On Wed, Mar 26, 2008 at 7:10 AM, Guillaume Desmottes <<a href="mailto:guillaume.desmottes@collabora.co.uk">guillaume.desmottes@collabora.co.uk</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Le mardi 25 mars 2008 à 16:02 -0400, Benjamin M. Schwartz a écrit :<br>
<div class="Ih2E3d">> This works, and will work for the proposed case.  For the future, I see<br>
> file transfer as precisely the sort of thing that should be handled<br>
> internally to Telepathy.  Perhaps Telepathy should implement XEP-0234<br>
> (file transfer)[2] or even XEP-0214 (file sharing)[3].<br>
><br>
<br>
</div>We have a draft of spec for file transfer (but it will be probably<br>
modified) and a Salut branch implementing it. So that's definitely<br>
something that could be done at some point.<br>
<font color="#888888"><br>
<br>
        G.<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Sugar mailing list<br>
<a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/sugar" target="_blank">http://lists.laptop.org/listinfo/sugar</a><br>
</div></div></blockquote></div><br>