Martin Langhoff wrote: > On Thu, Feb 12, 2009 at 11:32 PM, Simon Schampijer <si...@schampijer.de> > wrote: >> Is your main request to get it into 0.82.1? Is this only a temporary >> solution and we get something else later? > > I think it'll be our "current" solution for a while... both branches? > >> PS: I am not a security person - so for this discussion of security impact >> you are better of asking someone else - I can only comment on the general >> layout of the patch. > > The main 'right way' in security terms is following the 'Plan A' that > I outlined in my other email.
_________ Plan A - HTTPS to the rescue Use HTTPS and client certs. On the Browse.xo, either create a client cert at first boot or derive one from the SSL priv key we already have. Lacking a PKI ( in this case XSs will have self-signed certs, and the whole network will often be offline), we will need to grab the cert from the XS at registration time so we can whitelist it for Browse.xo. This is safer, allows us to upgrade later to always using HTTPS if desired. It has downsides however - we'll have to change the registration protocol, and deal with up/downwards compat issues. - https is significantly more costly in terms of CPU on the XS ________ Just to understand better. Is the main issue that we have to change the protocol - or are you more worried about the CPU cost? So as I understand the process: At registration time with the XS the cert is created and transferred to the client. Probably stored than in the profile. Browse does than integrate it when it starts. The cert integration itself in Browse should not be hard. Thanks for clearing up, Simon _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel