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. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
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 [EMAIL PROTECTED] 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@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
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. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
On Fri, Mar 21, 2008 at 12:11 PM, Gary C Martin [EMAIL PROTECTED] wrote: 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. It's true, at present this is nothing more than a good idea. It's so good, however, that I would like to hear some more discussion about how it might be reasonably accomplished. The abilities to a) transparently update to a newer version of an activity you already have and b) find and download entirely new activities on the mesh by joining would be fantastic. 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. 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? Can we transfer it directly from someone who is in the activity we join? If so, can we still ask the next activity participant for the remainder if the first one leaves? 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. What do people think? - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
Eben, I've got more questions than answers for you, but perhaps my smaller questions will make the overall problem easier to analyze. Michael Questions: First, how will we discover that a code exchange is needed? Three straw-man options include: a) include adequate information in a presence notification or in a resource discovery URL [1] to permit us to calculate decide protocol compatibility [1]: http://lists.laptop.org/pipermail/devel/2008-February/011108.html b) add a new handshake to the join a shared instance protocol to establish this information. c) leave it up to the activity to figure out (perhaps with assistance from a system service or library) Next, let us assume that a code or data exchange is necessary in order to provide protocol compatibility. How do I figure out what bits are needed? How do I figure out where to go in order to get the requisite bits? I think it would be wise to add some indirection here so that people who are not in physical proximity can acquire the bits from low-cost sources when possible and to fall back on direct exchange of bits when necessary. Also so that we can extend the bit-acquiry software with new protocols as they become available. (For a first draft, we might as well copy Read's use of HTTP-over-Tubes, since it's already conveniently available to us.) NB: If we ever want to imagine running Sugar on platforms other than XOs, (or even between XOs running significantly different builds), then we'd better consider system-dependency issues up front. (We can ignore this question temporarily while doing feasibility studies on our own platform, but if this idea is going to rock the world like I want it to, then we need to think early on about giving the humans operating our technology access to information adequate to debug and work around incompatibilities between their respective systems.) After acquiring the bits, there's a small question of what to do with them. Do they go into the Journal as a new entry? Are they immediately unpacked alongside the user's other activities? If so, do they obscure older versions of the same activity? Should the older version be removed? I'm particularly concerned by Pippy-generated bundles here because they seem like they might be particularly subject to edit wars simply by being so easy to create and modify! (Should Pippy-generated bundles stake claims to their names in the fashion proposed in [2]?) [2]: http://dev.laptop.org/git?p=users/krstic/installer;a=tree; Naturally, there are some security concerns, but those could be easily addressed, They are far from easily addressed, but there's a good argument that they're _worth_ addressing because, in my opinion, easy and safe code sharing is one of the most attractive UI goals of our project! I believe, with the usual signing mechanisms. Updates to activities would only be transparent if the update was signed, etc. Information assurance mechanisms primarily deal with spoofing attacks and network hanky-panky. Isolation mechanisms are what we're using to make it generally safer to run code, regardless of whether we know where it came from. Both are necessary to make this easy code sharing policy more safe to pursue. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
