OpenID - status?
Hi devel, hi server-devel, I am working on Moodle's openID auth plugin. While there is an openID plugin of sorts for v1.6 I've reviewed it and it's less than stellar, so I'm tackling a new one. Questions: - Are we still happy with OpenID -- is Ivan still happy with it? I've done a bit of review of the protocol itself, and a quick chat with Mark Piper here in NZ reinforced my concerns - the whole thing has several weak points, a notable one being its blind trust of DNS. Will DNS be reasonably stable/trustable in our network env? - Moodle will initially know how to behave as a client. Do we want it to be an OpenID server too? I think we do but just to check where the thinking is at. cheers, martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OpenID - status?
On 7/10/07, Ben Laurie [EMAIL PROTECTED] wrote: The blind trust in the relying party is more of a concern to me: http://www.links.org/?p=187. Good point -- that's even easier than hacking the DNS. A bit of a spoof IDP site and done. And those shared secrets between the IDP and the user can be proxied through to the user as the IDP cannot know that the user is legitimate. All I've seen so far are phrases and images -- both look pretty, and useless. So we have - Blind trust in the relying party - DNS weaknesses -- fixed by the PKI in HTTPS -- will the laptops shipped to a school have loaded the school server's PKs? Or trust a big OLPC-signing-cert-in-the-sky? - A comment in your blog mentions MITM attacks against Diffie-Helmann. I'm not versed enough in the matter to judge the actual risk here. Google led me to http://www.itillious.com/insight/articles/maninmiddle.html cheers, martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OpenID - status?
On 7/10/07, Martin Langhoff [EMAIL PROTECTED] wrote: On 7/10/07, Ben Laurie [EMAIL PROTECTED] wrote: The blind trust in the relying party is more of a concern to me: http://www.links.org/?p=187. Good point -- that's even easier than hacking the DNS. A bit of a spoof IDP site and done. And those shared secrets between the IDP and the user can be proxied through to the user as the IDP cannot know that the user is legitimate. All I've seen so far are phrases and images -- both look pretty, and useless. So we have - Blind trust in the relying party - DNS weaknesses -- fixed by the PKI in HTTPS -- will the laptops shipped to a school have loaded the school server's PKs? Or trust a big OLPC-signing-cert-in-the-sky? - A comment in your blog mentions MITM attacks against Diffie-Helmann. I'm not versed enough in the matter to judge the actual risk here. Google led me to http://www.itillious.com/insight/articles/maninmiddle.html So, D-H is trivially MitMable. AFAIK, all known defences are patented, sadly. cheers, martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On 7/10/07, Mitch Bradley [EMAIL PROTECTED] wrote: Decompression is fast, but the signature verification is not so fast, especially since there are several different algorithms. Can't we just SHA1 the kernel+initrd bundle and sign the hash? SHA1 should be fast enough... --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OpenID - status?
I'm jumping in without having a full understanding of OpenID here, so forgive me if I get some points wrong, but: As I understand the BitFrost specification, OpenID is only used to extend the local authentication mechanisms (XO-to-school server) to the outside world (Google backups, etc). See: http://dev.laptop.org/git.do?p=security;a=blob;hb=HEAD;f=bitfrost.txt#l1028 The actual authentication of XOs and users is done by us outside OpenID. So the DNS weakness and MiM attacks are only valid outside our scope. For example, someone can spoof Google and/or insert themselves in between Google and the school server, and proxy the authentication and look at all the data going past. But the backups are encrypted, which mitigates this problem. They can't attack OpenID on the mesh, because OpenID isn't used there. It's impossible to get perfect security. We should look at the possible threats in the context of our uses, and perhaps the dangers are (or can be) mitigated. Local MiM attacks on the wireless network may be easy (until we implement IPv6 SEND, at least), but wired MiM attacks between (say) an IPv6 tunnel endpoint and Google will require large amounts of resources to accomplish. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
updatinator benchmarking (Was: rsync benchmarking)
On Wed, 2007-06-27 at 16:02 -0400, C. Scott Ananian wrote: Anyway, here are some quick stats, for upgrades from build 464 to 465 to 466: I've been doing some more work on updatinator. Now it stores the release info as a simple key-value file that contains the manifest sha1 value, and the actual manifest is just a blob like the other. This way we automatically get gzip and bsdiff support for the manifest files (which tend to be around 2 meg for a full olpc devel image). Here are some stats using bsdiffs and gzip. I don't have any byte counter in the app, so i just looked at interface RX/TX stats. It counts the full packet size instead of the tcp stream byte count, and it might have data from other apps running on the system, but it should give a somewhat correct maximum limit at least. 464-to-465: Full contents of tree: 429,302,610 bytes rsync --whole-file: sent 32,034 bytes; received 13,153,813 bytes. Standard rsync: sent 96,720 bytes; received 10,047,524 bytes. 9.0s user, 64.9s real Rsync-with-manifest: sent 79,192 bytes; received 9,139,515 bytes. 4.3 user, 11.5s real. Updatinator: sent 596,681 bytes recieved 7,545,281 bytes 465-to-466: Full contents of tree: 458,828,206 bytes rsync --whole-file: sent 21,990 bytes; received 25,826,516 bytes. Standard rsync: sent 141,948 bytes; received 23,981,423 bytes. 14.0s user, 68.5s real Rsync-with-manifest: sent 125,158 bytes; received 23,171,430 bytes. 10.4 user, 28.5s real. Updatinator: sent 1,263,885 bytes recieved 20,718,744 bytes I haven't looked into why we're sending so much data, perhaps its due to other traffic on my box, or perhaps the http accesses are just too chatty. But even taking that into consideration we're doing 1.2 meg less total network traffic in the 465-466 case than the best rsync case (and we're not doing a lot of local disk i/o). I'm also creating an updatinator repository at http://olpc1.redhat.com/updatinator/ so that people can start test it, and eventually use it to easily update their XOs. Another interesting piece of stats here is the size of this repository. A repository with all the ext3 and jffs2 developer images from version 400 to 450 has a blobs directory of 1.3 gigs. The estimated size for just the tarballs of these revisions is around 12 gigs. This is a pretty good compression ratio. This is good for the school server disk use and means it can easily store all old releases. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OpenID - status?
On Jul 10, 2007, at 9:37 AM, C. Scott Ananian wrote: As I understand the BitFrost specification, OpenID is only used to extend the local authentication mechanisms (XO-to-school server) to the outside world (Google backups, etc). The actual authentication of XOs and users is done by us outside OpenID. So the DNS weakness and MiM attacks are only valid outside our scope. That's correct. OpenID, in a vacuum, is a fine mechanism. It's the way people are doing authentication to their OpenID IDPs on the wider Internet that's problematic and dangerous; we can generally avoid the issues entirely by authenticating transparently to the school server in the background. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updatinator benchmarking (Was: rsync benchmarking)
Alex, On Jul 10, 2007, at 10:21 AM, Alexander Larsson wrote: I've been doing some more work on updatinator. I'm happy to see this work continuing, but I want to set clear expectations for FRS. I will not give security signoff for the FRS update system, in my mind one of the most critical subsystems on the machine, to be based on new code. I want to explore other update mechanisms after we ship, and updatinator tops the list. I don't want to discourage your work. But given where we are with our software and where we need to be a couple of months from now, we don't have the in-house resources to give updatinator the kind of scrutiny that would put my professional paranoia at ease. We take various software risks at different places in our stack precisely because we're relying on the update system to work flawlessly. With existing, well-known tools, I can make reasonable guarantees about that being the case. With new ones, despite your obvious talent and attention to this problem, I can't. An rsync-based solution, possibly without even Scott's wrapping manifest code, is the only update approach I will support for FRS. After that, we can revisit the issue. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On Jul 10, 2007, at 8:46 AM, C. Scott Ananian wrote: Can't we just SHA1 the kernel+initrd bundle and sign the hash? SHA1 should be fast enough... The hashes we have available in OFW through the LTC code are Whirlpool and SHA-512. It's non-trivial to amend the list at this time. The current crypto code uses a slow(ish) and paranoid combination of the two hashes with two signature systems because it was designed to verify BIOS updates, where maximal paranoia is justified. We will want to adjust the system to drop down to a single hash algorithm and signature system for the normal boot integrity verification, which should make it quite a bit faster. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: RC2 and New bugs
Scott, Activation we are still counting on... but we believe the update feature you are working on is NOT in Trial-2. The testing we'll do with 100 laptops, etc. for updates is for next release (which we'll probably call Trial-3, btw). So let's talk about this and make sure that you aren't putting code in the Trial-2 repository that we really don't want in there for now. Thanks, Kim On 7/10/07, C. Scott Ananian [EMAIL PROTECTED] wrote: On 7/10/07, Kim Quirk [EMAIL PROTECTED] wrote: We are 2 weeks past feature freeze. If you are working on a feature that you think is supposed to go into Trial-2, please talk to Jim or me asap. We probably need to push it out. In order to stabilize this build, we can't check in any new code, without a good, detailed discussion. Trial-2 is in 'bug fix' mode now. Activation and upgrades aren't in the current builds yet. Activation should be minimally-invasive (there's a separate initrd that we boot into if the machine isn't yet activated), but upgrades may need to move stuff around in the filesystem -- the current design pushes the filesystem root from / to /a (or /b) to allow recovery to a backup system after the upgrade. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] RC2 and New bugs
On 7/10/07, Zack Cerza [EMAIL PROTECTED] wrote: Is this the same update feature as Manual XO updates, don't lose user data from http://dev.laptop.org/roadmap ? If so, maybe it should be removed from there. No, updating from a USB key is a separate feature. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Trac #1049] Rotating in reverse and/or better feedback for the rotate button
I think #2 is the simplest... I agree, actually. I have two further comments on #2. First, the only reason I considered 3 a better option is because I wasn't sure which vertical orientation would be preferred. It may be easier for kids to operate the controls with their dominant hand. Or perhaps, to the contrary, they would prefer to hold it with the handle in their dominant hand. I wasn't sure if we should remove that choice or not. As a plus, it would make the controls orientation consistent... Second, I actually think that #3 is a good idea even if we choose to make it a toggle. The feedback is more immediate that way, and it would allow a short delay period in which to press the button again, essentially canceling the rotation request. - Eben On 5/9/07, Zarro Boogs per Child [EMAIL PROTECTED] wrote: #1049: Rotating in reverse and/or better feedback for the rotate button -+-- Reporter: pengo | Owner: jg Type: defect | Status: new Priority: normal | Milestone: BTest-4 Component: sugar | Version: Resolution: |Keywords: -+-- Changes (by Eben): * summary: Holding the rotate button = Rotating in reverse and/or better feedback for the rotate button Comment: Hmm, good question. I see a few possible approaches to this issue, and I'm not sure what will work best. 1) Hold the rotate button for an extended time (1 sec?) to rotate backward [[BR]][[BR]] 2) Support only 1 vertical and one horizontal orientation, so the button is actually just a toggle, eliminating the problem altogether [[BR]][[BR]] 3) Implement a delay on the actual rotate action, but show a small, centered onscreen graphic immediately when the button is pressed indicating the direction up will take once the rotation occurs. Then, pressing the button 3 times quickly would have the effect of rotating the indicator graphic 270CCW (-90CW), and after short delay a single rotation event can occur. I think the latter two are the better options, since they are clearly discoverable. The last may actually be the best, since it provides more immediate feedback about the button's function. Thoughts? -- Ticket URL: http://dev.laptop.org/ticket/1049#comment:4 One Laptop Per Child http://laptop.org/ -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list [EMAIL PROTECTED] http://mailman.laptop.org/mailman/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
