Re: Sharing behavior in the core Read activity
John, This week I finally got everything in sugar-jhbuild to compile. The Browse activity is the only thing that doesn't work. It can't find a Mozilla library file. In any case, I was able to get my Read Etexts activity to share reliably. My activity saves the file to the journal if it knows that the file was shared by someone else instead of being loaded from the Journal. I am using exactly the same code, as far as I can tell, in the View Slides activity. That activity does not do sharing reliably at all. On the receiving side it complains that no tubes are available. On the sending side it complains about invalid parameters. Yet this activity is doing exactly the same thing that Read Etexts is doing: sending a Zip file from one copy of an Activity to another. The only difference I can see is that the size of the Zip file is much smaller in Read Etexts. The few times I have gotten sharing to work it has been with a smaller file (The Tale Of Miss Kitty). Even this file doesn't work every time. If you or anyone else has some insight into what might be failing here I'd love to hear it. At the moment I'm stuck. I have published a version of Read Etexts that has sharing code. I'd like to be able to do the same with View Slides. James Simmons John Watlington wrote: It is a known problem that the Read activity doesn't automatically store a copy of the shared document in the Journal. Read has bigger problems. I haven't been able to get it to share the document properly in test after test. ___ 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)
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
Sharing behavior in the core Read activity
I am trying to give Read Etexts the same sharing behavior that core Read has, using mostly the same code. Until this week I didn't have a good way to test sharing, but I have set up multiple instances of sugar-jhbuild on one of my computers so now I can test sharing. My sugar installation is missing squeak and another module (sugar-meta-something) but seems to work OK otherwise. As a sanity check, I tried to share a document between the two instances using the core Read activity. This seemed to work OK, at first. I was surprised at what happened when I resumed the activity from the Journal of the second instance. If the first instance was still running and sharing the document, it looked like the second instance would download the document again and resume on the page where the reader of that instance had left off. However, when the first instance was shut down and I tried to resume the activity on the second it displayed an empty document with zero pages. This wasn't what I expected to happen. I had assumed that sharing a document meant that the second kid got his own copy of the document, which would be saved in the Journal until he deleted it. Again, my sugar-jhbuild has flaws, so I cannot be sure that the behavior I'm seeing is what is intended. If any of you could confirm or correct my understanding of this I'd be obliged. Another thing I remember reading is that if two kids share an activity and one has an older version of the activity than the other, the older version gets updated so they both have the newer version. This doesn't seem to be happening. I have two test machines, one running xubuntu with the sugar RPMs and another running Suse with sugar-jhbuild. I was hoping to use this alleged ability of Sugar to update activities in my testing, so I can develop on the xubuntu machine and test on both without passing USB drives back and forth. If someone could improve my understanding of this I'd be grateful. Thanks, James Simmons ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sharing behavior in the core Read activity
Hi James, Another thing I remember reading is that if two kids share an activity and one has an older version of the activity than the other, the older version gets updated so they both have the newer version. This doesn't seem to be happening. I have two test machines, one running xubuntu with the sugar RPMs and another running Suse with sugar-jhbuild. I was hoping to use this alleged ability of Sugar to update activities in my testing, so I can develop on the xubuntu machine and test on both without passing USB drives back and forth. If someone could improve my understanding of this I'd be grateful. Yea, I'm not aware that this is implemented, just good intentions at this stage (such a great idea and only really possible on an open platform like the XO). Even worse though, as a new activity developer, the first thing I wanted to try once I got my new activity working nicely, was to share it and get some quick feedback – I soon discovered you can only see a shared activity if you already have it installed. So you can only really practically share the blessed selection of activities that you can assume another XO might already have installed, no 'viral' activity distribution model yet. Those kids better have access to an upto-date server, the internet, or spring some $$ for USB keys and start sneaker netting. The more I try to dig about in the code, and get involved where I can, the more I realise there is just _so_ much work required and massively too few developers to get the lower layers stable and robust for the target environments. From what I can tell, there's a very small group (in the single digit figures) of folks coding their socks off and trying to dealing with upstream politics. They've got an amazing amount done, all things considered. Just hope we can all hang in there, and contribute where ever we can, it's quite a bumpy ride. Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sharing behavior in the core Read activity
It is a known problem that the Read activity doesn't automatically store a copy of the shared document in the Journal. Read has bigger problems. I haven't been able to get it to share the document properly in test after test. wad On Mar 21, 2008, at 10:54 AM, James Simmons wrote: I am trying to give Read Etexts the same sharing behavior that core Read has, using mostly the same code. Until this week I didn't have a good way to test sharing, but I have set up multiple instances of sugar-jhbuild on one of my computers so now I can test sharing. My sugar installation is missing squeak and another module (sugar-meta-something) but seems to work OK otherwise. As a sanity check, I tried to share a document between the two instances using the core Read activity. This seemed to work OK, at first. I was surprised at what happened when I resumed the activity from the Journal of the second instance. If the first instance was still running and sharing the document, it looked like the second instance would download the document again and resume on the page where the reader of that instance had left off. However, when the first instance was shut down and I tried to resume the activity on the second it displayed an empty document with zero pages. This wasn't what I expected to happen. I had assumed that sharing a document meant that the second kid got his own copy of the document, which would be saved in the Journal until he deleted it. Again, my sugar-jhbuild has flaws, so I cannot be sure that the behavior I'm seeing is what is intended. If any of you could confirm or correct my understanding of this I'd be obliged. Another thing I remember reading is that if two kids share an activity and one has an older version of the activity than the other, the older version gets updated so they both have the newer version. This doesn't seem to be happening. I have two test machines, one running xubuntu with the sugar RPMs and another running Suse with sugar-jhbuild. I was hoping to use this alleged ability of Sugar to update activities in my testing, so I can develop on the xubuntu machine and test on both without passing USB drives back and forth. If someone could improve my understanding of this I'd be grateful. Thanks, James Simmons ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
