[sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

Jameson "Chema" Quinn jquinn
Wed Mar 26 12:05:19 EDT 2008


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).

I raised this issue on IRC and got two responses.

1. neuralis/ ivan krstic was the security guy on the team and he has just
left. Do not expect this to be fixed soon.

2. Do not try to fix this yourself, as security must be done right or not at
all.

(apologies for stripping the nuances)

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.

(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.

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.

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.)

On Wed, Mar 26, 2008 at 7:10 AM, Guillaume Desmottes <
guillaume.desmottes at collabora.co.uk> wrote:

> Le mardi 25 mars 2008 ? 16:02 -0400, Benjamin M. Schwartz a ?crit :
> > This works, and will work for the proposed case.  For the future, I see
> > file transfer as precisely the sort of thing that should be handled
> > internally to Telepathy.  Perhaps Telepathy should implement XEP-0234
> > (file transfer)[2] or even XEP-0214 (file sharing)[3].
> >
>
> We have a draft of spec for file transfer (but it will be probably
> modified) and a Salut branch implementing it. So that's definitely
> something that could be done at some point.
>
>
>        G.
>
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080326/d2af28c0/attachment.htm 



More information about the Sugar-devel mailing list