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
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
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
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
--
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:
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
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
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
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
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
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
--
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
12 matches
Mail list logo
