Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
On Wed, Mar 26, 2008 at 10:05:19AM -0600, Jameson Chema Quinn wrote: I disagree with #2. I disagree with both #1 and #2 and, as the current maintainer of Rainbow, that should tell you something. More bluntly, please experiment and please publish your work with a public solicitation of criticism. It's true that, these days, I lack the uninterrupted time for serious attacks on our really security hard problems (X, communications security, and making isolation available on other platforms come to mind), but I'll _make_ time for patch review, discussion, and writing on these topics. (Understand that, like any occasionally capricious maintainer, I may or may not like your work, may or may not demand changes in your work before I decide to merge it with mine, and probably won't agree with you about the Right Way Forward. However, don't let that stop you!) 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. It's a certainly a place to start - in other words, it may be independently useful and it will certainly give us better understanding of the overall problem. Please try it. 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. As I said in my previous email, Bitfrost clearly states (correctly, in my mind) that even justified belief that code originates from some known individual implies no trust relationship with that code. Period. Use isolation to make it safer to play with code and use signing to help reduce attackers' abilities to lie to you about what code you're going to be running. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
As I said in my previous email, Bitfrost clearly states (correctly, in my mind) that even justified belief that code originates from some known individual implies no trust relationship with that code. Period. Use isolation to make it safer to play with code and use signing to help reduce attackers' abilities to lie to you about what code you're going to be running. If you take this to the extreme, then you would reset manually-granted bitfrost privileges on every activity update, and even remove the default resume behavior from the journal for instances of that activity (if it is not the same code, it cannot be trusted to handle to handle the same data without an explicit resume with new version choice by the user). I think new versions which are from the same source should get an implied trust level - the same trust as prior versions, which, in general, will be strictly limited by Bitfrost. I think that the fact that such same source may be the same corrupted source does not affect this. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
On Tue, 2008-03-25 at 13:46 -0400, Eben Eliason wrote: Naturally, there are some security concerns, but those could be easily addressed, I believe, with the usual signing mechanisms. Updates to activities would only be transparent if the update was signed, etc. I agree. For a first implementation, only basic signing is required. Eventually, we may have activities written by teams of children in which new members come and go, and the projects occasionally fork. This requires a more complex signing/upgrade system. I sketched one proposal at [1]; it is not perfect. The bigger question is really determining how to make the whole transfer process work smoothly in these cases. Can we use a torrent model to make it easy to get activities from the mesh, even as people come and go on an unreliable network? For a first implementation, this is not necessary. Most Activity Bundles (.xo's) are about 100 KB or less. Over a direct mesh link, transferring small bundles takes about a second. Only with very large activities, and very bad links, will simple transfers be insufficient. Can we transfer it directly from someone who is in the activity we join? This seems the simplest solution. If so, can we still ask the next activity participant for the remainder if the first one leaves? Yes. However, for a first implementation, the download should probably just restart. This optimization will only be important for activities with exceptionally high turnover. As there has been interest expressed in developing basic OS integrated object transfer as a GSoC project, I wonder if those efforts could also be applied to this problem, or if this should be offered as another distinct project alternative. Current implementations of file transfer (Read, and therefore Distribute) work by getting a Stream Tube from Telepathy, and then running a HTTP server on this tube. Any near-term implementation of transferring Journal Entry Bundles or Activity Bundles is likely to use the same mechanism. 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]. What do people think? I think it would not be too hard, and should definitely be on the to-do list. It would be a major user-visible milestone in the journey toward Complete Sugar. There are several things that have to happen first: 1. Basic activity signing. 2. Pushing SVG files through Presence, so that I can see the icon in the mesh for an activity I don't have. 3. Sane activity storage: What if the shared session is a newer version of an installed activity, but it's been modified by someone other than the original author? I should then be able to join, but it should be treated as a new activity, not an upgrade, even though it has the same name. This means we need an activity storage mechanism that can handle multiple activities with the same name. Also, all installed .xo bundles must be kept around, or Sugar must be able to reconstitute them on demand without invalidating the signatures. --Ben [1] http://lists.laptop.org/pipermail/security/2007-December/000341.html [2] http://www.xmpp.org/extensions/xep-0234.html [3] http://www.xmpp.org/extensions/xep-0214.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
