hi! hi welcome to another round oh, it's that time again :) cjb: heh http://wiki.laptop.org/go/Sugar_dev_meeting#Topics * erikos wonders how to interpret cjb's comment tomeu: looks like it is me and you and a funny chris is it starting now? I can never get the timezones straight I guess it is now. well, you have me for a minute or two * tomeu waits for hardy, which will have an international clock bemasc: hey you should get latest gnome http://library.gnome.org/misc/release-notes/2.22/#rnusers bemasc: International Clock that is m_stone: you know about policykit? or well, anybody here knows about it? tomeu: why do you ask? erikos: oh, you mean because of the Clock activity? m_stone: have you seen the meeting topics? ;) bemasc: no of the timezones bemasc: but the clock activity would have worked as well :) erikos: ok... why are you telling this to me? is it starting now? I can never get the timezones straight m_stone: maybe policykit can make easier for the control panel to set some parameters without having to become root? oh! tomeu: I strongly recommend avoiding that altogether. bemasc: the intl clock? tomeu: just move the timezone logic into Sugar, so that it doesn't require root permissions bemasc: don't know if we can do that for all the cases like that erikos: in which case we need to do things that the olpc user cannot currently? s/case/cases tomeu: timezone and... * erikos checks erikos: xkb also, yes? m_stone: why do we need keyboard config? m_stone: keyboard settings that is ? bemasc: different layouts erikos: the layouts are autodetected. you need to be root for that? in ubuntu I can change it without fuss bemasc: walter thinks we need to be able to change it from somewhere. argh. Why? bemasc: he's actually presently interested in setting it via customization key bemasc: some people like to change that The last thing we need is 9-year-olds setting their Arabic keyboards into Spanish Dvorak and not being able to figure out how to set it back. bemasc: well if you have a gui it should be fine bemasc: at least easier than the command line only bemasc: this is an option I would recommend only in the gui present - if we think it is worth m_stone: would there be an issue to use a system call to use sudo for the timezon for example? erikos: fine. Setting keyboard layout doesn't require any privileges bemasc: you mean if we do the same than with the language bemasc: having a conf file in home erikos: I don't understand you. bemasc: well to store the settings - for the keyboard bemasc: they live in /etc/sysconfig at present erikos: All I know is that, in Gnome on CentOS, I just changed my keyboard layout in the System menu without escalating privileges I don't even _have_ root on this machine well, perhaps no such privilege is required. or perhaps there's a setuid wrapper lying around somewhere. I have not yet investigated carefully. might be or they place the settings somewhere where there is write access we had that once for the kbd as well ok - so people think that we can avoid using root in the control panel at all? * mchua (n=mchua@cpe-66-108-80-238.nyc.res.rr.com) has joined #olpc-meeting * bemasc does besides bemasc :) i am not sure we should move all of the stuff in sugar erikos: we may know better if we have a list of the system setting we want to put in there s/want/may want bemasc: why you don't like policykit? tomeu: the list os for the moment color jabber language nick radio timezone keyboard and i guess some more network settings like mcast-rate and likely with time *most of* the settings you find on other desktops as well erikos: you have to assume that the user _doesn't have root access_ * olpc_wad (n=wad@wireless-19-195.media.mit.edu) has joined #olpc-meeting I hope we manage to keep it much simpler bemasc: I don't like that line of thinking. bemasc: well system settings will likely ask for priviligues tomeu: me too - but as you know We shouldn't assume that Security stops us from doing things to the point where we don't try. We should aim for what we need, and ask the security team to help us achieve it inside their goals. Running things as root is bad. UNIX is concerned almost entirely with how to let users do things without having to escalate to root. right, so maybe we end up chown()ing some files away from root. In any case, the ask for erikos *right now* is probably not "don't do that, it would require root" but instead "let's make it work". cjb: agreed. However, when we can achieve things without escalating to root, we should do so. * m_stone is bemused. s/ask/answer/ i agree that we should aim at make non root settings possible - that is what we tried so far already I'm much more concerned by "unbounded" use of root access than I am by use of root access in a controlled fashion by a small control panel. but it should make sense - if we move away from the current model m_stone: nice point erikos: I can't think about this so abstractly. For this reason, I have some desire that the UI for the control panel be separate from the priveleged portion of code, but other than that, it's not a big deal. bemasc: you mean i should elaborate? feel free to solicit my input at your convenience. All I'm saying is; I think timezones should really be per-user anyway. If you've got a multi-user system, every user might want to be in a different timezone bemasc: that is a valid point agreed So I regard systemwide timezone settings as a bug. bemasc: It's a good job it's *One* Laptop *per* Child, then. ;-) And also a security risk, if users are to be altering the system timezone themselves cjb: hehe So I think it would be nicer if Sugar (and even Gnome) kept the timezone state themselves ~/.timezone actually, the same is also true of setting the clock but that's another discussion m_stone: the separation you described is what i read in the PolicyKit manual today bemasc: well clock is likely a setting in the panel as well no? bemasc: or selecting ntp server etc i guess this is another setting that would - in the current model - need root privilueges erikos: then that may be an appropriate way to go. (unfortunately, I need to run off to lunch) m_stone: sure talk to you later erikos: right. This is the problem with use system-level clocks for everything using yup there's no reason that NTPd couldn't run as olpc, writing settings to ~/.clock_offset and that way every user could sync to a different NTP server bemasc: cjb's comment if we have multiple users was valid somehow as well and there would be no long-running, net-facing daemons running with write-access to root files erikos: right. The danger is that these mechanisms will be co-opted into an exploit. bemasc: co-opted -> passed around? no right now, policykit isn't necessary at all. Control Panel can just su to root whenever it wants to do something dangerous. that would be a bad idea, because in the future, we don't want Control Panel to be able to do that. so you'd have to rewrite it all. PolicyKit has the same problem. ok so the reason 'having multiple user' is not really valid i guess at the moment there is a reason to say you like to make the interaction from the user to not have root privs bemasc: maybe we should rediscuss with m_stone when he is around? erikos: maybe. bemasc: he likely has a lot of input on this as well true but a nice start - thanks for everyones' input next item: Sugar-Control-Panel - language yeah, we don't need a definite answer for this now * how to generate the list of languages and their translation best) * desired output: current locale, language in language itself, territory * example: ingles/english, frances/francais, aleman/deutsch * do we make the same for the territory than what we do for the language? Just to repeat myself, I suggest not blocking on The Perfect Security Model. We have a real need for a control panel right now, and the rest of the system isn't behaving perfectly with regard to security right now either. We can live with something that works until we have time to make it work securely. Oh, I thought we were going with language in its localized form only. cjb: we just needed some topics to put in the topic list for this week. we are not trying to solve the future of the cp yet ;) Oh. :) cjb: either way we have to handle the list of available langs no need to take any decision about that yet, I think tomeu is Mediterranean today bingo! http://www.gnu.org/software/libtool/manual/libc/TZ-Variable.html i looked in what libc offers but did not really find a good answer yet the locale does only offer the english names * garycmartin (n=urk@user-514d598f.l1.c1.dsl.pol.co.uk) has joined #olpc-meeting maybe i just put the english names there for now erikos: that's too bad. http://unicode.org/cldr/ is database for this ok that's it from my side for now it has translations of country names, language names, and time zone names. I don't know if it's built into the system somewhere. * z3p has quit (Read error: 104 (Connection reset by peer)) bemasc: i look at it bemasc: i thought i get this data with nl_langinfo - but not really understood it yet - have to read more * bertf (n=root@p4FD5A52F.dip0.t-ipconnect.de) has joined #olpc-meeting erikos: I don't know much about this, but I don't see how nl_langinfo gets you this: http://www.unicode.org/cldr/data/charts/by_type/names.time-zone-cities.html (That's the names of all the time-zone cities, translated into all different languages) Did I miss the meeting, or am I early? Am in the UK and we just BST time shifted :-) bemasc: looks great agreed garycmartin: eeeh you are late i think garycmartin: hi btw :) erikos: Sorry. Hi! garycmartin: date -d '2008-04-01 17:00 UTC' garycmartin: not to worry :) I thought 1700 UTC was 10 min ago ... bertf: hmm not when i believe the output of the date command i posted bertf: or was i wrong? I think you are wrong indeed bertf: yes it was. UTC isn't affected by any DST effects. * Val`hw` is now known as Ngref uff confused now [erikos@localhost tmp]$ date -d '2008-02-18 17:00 UTC' Mon Feb 18 18:00:00 CET 2008 [erikos@localhost tmp]$ date -d '2008-04-01 17:00 UTC' Tue Apr 1 19:00:00 CEST 2008 For me (UK) we just hit our DST so we are now BST (British Summer Time) which is UTC +1 garycmartin: damn i see it now sorry see the switch from CET - CEST in my output bertf: yup - you are right * dirakx (n=dirakx@190.24.129.6) has joined #olpc-meeting so let's do this again :) Yea, and you try calculating a lunar eclipse for any time zone, N hundered days from now :-) (Moon activity) all the people that attended the meeting one hour ago - think of it as a april's fool * erikos knew it all the time erokos: :-) garycmartin: do you want to elaborate on the lunar eclipse in the real sugar meeting today ? :) No, noooo. My head hurt enough doing the code. garycmartin: always good to have an ace in the sleeve heh ok bertf: did you have any questions, comments? * eben (n=eben@1cc-dhcp-178.media.mit.edu) has joined #olpc-meeting * homunq just got here, late hi homunq * eben did too * homunq would have added a discussion of activity bundle format to the minutes if he could have erikos: no, not really * homunq means agenda * erikos fooled himself today with the sumer time homunq: you can ask if you want? homunq: or keep it for next week like you wish I think the agenda is pretty much empty * homunq wants but in its place, don't want to interrupt Ok if that is so... * olpc_wad has quit () this is in relation to my email about MANIFEST any objections to me taking it away ? I think that the .xo bundle format is not good homunq: as I think you've noticed by now, MANIFEST is only used by bundle-builder to know which files to include yes homunq: I must be there for a reason? I? homunq: I think knowing which files to include is a very reasonable thing to have in a MANIFEST file I routinely build my bundles in unclean directories full of things like "activity.py~" and "activity.pyc" OK, but there is no standard, having it optional is a headache homunq: I assumed it was for future security, and for activity sharing (activity transfer to another XO) it would be annoying to have to exclude those manually every time, and I wouldn't want to start loading heuristics into the bundle-builder bemasc and garycmartin: these are two good reasons for a standard homunq: what do you mean by "a standard" for security, you need to be able to define a binary-identical bitstream which is signable homunq: maybe .jar does it by having that be a manifest-like file with hashes homunq: _a_ bitstream, but not necessarily the bitstream of the bundle itself * _bernie has quit (simmons.freenode.net irc.freenode.net) * cahalan has quit (simmons.freenode.net irc.freenode.net) * CanoeBerry has quit (simmons.freenode.net irc.freenode.net) * gnu{- has quit (simmons.freenode.net irc.freenode.net) * h01ger has quit (simmons.freenode.net irc.freenode.net) (MD5 - broken) * _bernie (n=bernie@cable-85.28.85.62.coditel.net) has joined #olpc-meeting * cahalan (n=albert@user-142gbaf.cable.mindspring.com) has joined #olpc-meeting * CanoeBerry (n=Canoe@1cc-dhcp-112.media.mit.edu) has joined #olpc-meeting * gnu{- (n=gnu@quiet.toad.com) has joined #olpc-meeting * h01ger (n=holger@socket.layer-acht.org) has joined #olpc-meeting bemasc: exactly. homunq: that is, I suspect, the intent homunq: as you may recall, package signing was supposed to start in late december and bundlebuilder was supposed to acquire the necessary features it just never happened My proposed design: 1. some ignore functionality options: gitignore in top-level dir, gitignore with hard-coded default, hard-coded 2. signable bitstream is the gitignore not working at present? I think that, with options to supress mtime, user, group erikos: no, I mean that bundle-builder would become gitignore aware i mean .pyc ~ are not in a bundle homunq: ok i see I mean, dump the MANIFEST yup I think that, with options to supress mtime, user, group, the bitstream could be the output from gnu tar homunq: why aren't you happy with a whitelist? What's wronk with the white list (MANIFEST), much better than blacklists? Bemasc: +1 (sorry xo keyboard and fat fingers here) bemasc: it is too easy with a whitelist to have a bundle that won't rebundle to the same thing develop depends on being able to rebundle homunq: then it's a buggy bundle anyone can make a non-compliant bundle I can make a tarball that's semi-corrupted too. yeah, well a large fraction of current bundles are like that now. homunq: well that's the problem and maybe sugar should enforce the MANIFEST homunq: so we need to get on and make sure developers know this and fix this. If sugar started copying only files in the MANIFEST to /home/olpc/Activities, those bundles would get fixed right quick. It will also be possible to create corrupt activities very easily with a whitelist, not as common with a blacklist. I have no problem with that that's actually the point of a whitelist I mean, I just copy a new file into the directory, and "why does it work for me but not when I share it" right. Students using Develop should not have to handle MANIFEST; Develop should deal with it for them for ease-of-use for beginning developers, I think a blacklist is friendlier. just like it will deal with signing for them. homunq: blacklists just premote lazy work. Better to know what should be in a bundle, and nothing else. If Develop is not running? * mvn071 (n=mvn071@vijn.xs4all.nl) has joined #olpc-meeting homunq: what do you mean? then I need to make a dialog to say "something is wrong" I mean, they use cp to put the file in. from terminal. homunq: well, then it's their own fault homunq: alternatively, Develop should simply regenerate the MANIFEST which is trivial to do bemasc: that defeats the purpose of a MANIFEST * bertf is for whitelist too then I just have to code the blacklist back into the regeneration code. you don't need a blacklist There are several distinct issues here 1. Bundle format. 2. Bundle creation in the context of Develop what is the problem? Does anybody really want to be excluding files other than *.pyc, *~, and *.bak? 3. Bundle creation not in the context of Develop whether or not bundle-builder uses a whitelist is orthogonal to the issue of whether such a whitelist appears in the bundle. bemasc: bundle creation in the context of develop, in the context of activity sharing, in the context of creating a signable bitstream they are completely separate issues why not have the same logic cover all three? indeed In the context of Develop, the user should be interacting with the bundle exclusively through the Develop UI. which means that if develop automatically picks up new files, we by definition are using some system that is not a pure whitelist Therefore, Develop can easily handle adding files to the whitelist. no, Develop is but bundle-builder is not but why not have the same bundle creation logic for all three use cases? why make Develop a special case? If blacklists let us not? because I don't want bundle-builder to behave that way, and I am the target audience for bundle-builder. as an Activity developer Why not? because it would be inconvenient for me in what use case? I honestly don't understand. for example, when I'm designing icons, I routinely keep a few variants around, and add the one I want to the MANIFEST oh also, the bundle format that you're proposing necessarily contains a list of all the files in the bundle so providing a MANIFEST to bundle-builder simplifies bundle-builder. exactly. my activity develop directory is cluttered with random stuff too really. did not expect that answer. hm and I want to know exactly what goes in a bundle homunq: as for bundle format, it sounds like pure JAR is almost exactly right for the first pass. do you really think that that is easier for you? don't want to ship my passwd by accident ;) bemasc: but JAR, AFAICT, uses MD5 only for signatures homunq: it's standard engineering wisdom that being explicit is better homunq: MD5 is safe, despite what you have heard homunq: it is possible to collide MD5, but only if generate both strings with the intent to collide them I understand that current attacks are collision-only, not reverseing but it is down to a few minutes on a laptop. sort of like, even git does not automatically commit everything you may have in your working dir but given a string A, it's impossible to find a string B that collides with A. bertf: yup i like git for this what's possible is to find a pair (A,B) that collide, but only if you control both A and B. think of a kid learning to program homunq: a kid learning to program should not be interacting with the filesystem directly anyway I guess one problem is that this is a data loss possibility the interface should provide them with a way to create new .py files, and to import objects from the journal homunq: a kid would be starting with something Pippy like or Turtle/Logo like. homunq: bundle-builder is using a whitelist, and that is not going to change. If you want blacklist behavior, it is trivial for you to implement it yourself in Develop. Let's talk about something else. OK. Then we should start enforcing MANIFEST. We should also be clear about whether MANIFEST includes itself. Such a solution is my second choice, but fine with me. We could start by outputting some nasty log/error warnings MANIFEST does not include itself a lot of them do. that would lead to a serious problem with MD5sums :-P I have no problem with making the system stricter OK. Ooops, think MANIFEST is listed in my activity. I develop ...I develop on a non sugar platform and made my own MANIFEST creation script. Need those errors/warnings when installing et al. garycmartin: exactly, that's what everybody does, and why I think the system needs fixing. As it is, bundlebuilder is capable of a lot of things (git, etc) which are not really meant for doing on the XO What I found confusing was how the files were listed. Top level paths, // is sometimes seen ./ all kinds of fluff. garycmartin: exactly! because everyone does what you did, writes their own. There's no clear description of what should be there other than a few min examaples in the wiki. We should have a bundlebuilder for non-sugar bundlebuilder should not depend on sugar so that everyone can use it. bemasc: exactly but bundlebuilder is also going to have to be changed substantially, in order to accomodate signing and we should encourage all activity developers to use it. the real question is: who wants to do it? bemasc: this problem is in my lap right now, with Develop. I can do it, probably before GSoC summary: MANIFEST is good. tomeu: sugar meeting still going (we had it at the wrong time) ouch I thought you were procrastinating bundlebuilder should not depend on sugar we want signing that 's pretty much it signing options : "tar `cat MANIFEST`" or something (obviously with signing-related stuff filtered out, maybe also filtering out .po files) what? or META-INF and jar-style manifests and .sf the latter option (jar-style) means that many files would have to go in 3 different manifest lists I haven't seen much actuall detail on signing. This would seem to be a pretty big security feature to get right... garycmartin: there is some consensus that we will first create a system where each bundle is signed by a single party, based on the usual simple signing techniques that are used for e-mail and such. MANIFEST, META-INF/manifest , META-INF/activity.sf (which would be signed with META-INF/activity.rsa) garycmartin: then we can debate the details of shared authorship and such. My assumption is that each file in the MANIFEST gets MD5ed (or some such) and the sums all end up in some file in the bundle. garycmartin: correct bemasc: agreed, put signatures in a directory and later add second-level of signatures of who-can-sign. in same directory garycmartin: OK, that is clear. I can do that. And that sum file is magically included, just like MANIFEST? what about the signatures on that sum file? are they magically included in MANIFEST or magically excluded from being MD5ed themselves (which would obviously break everything)? coding on the hoof... dangerious. Needs careful planning and intent. garycmartin: that is what I am trying to get towards here. Obviously there'd be a spec before code. So. A sum for each file in MANIFEST and a sum for the sums file. That will detect an edit of either the file content or the sums file. I repeat: are sig files in MANIFEST but not in sums file, or in neither? neither they are meta one consideration: a developer might want to sign a version of an activity, but not care about changes to .po OK, everything in some meta dir is picked up, no need for blacklist OR whitelist? Is this not the time? I have already gotten enough to move forward. (Don't dump MANIFEST, we will enforce it) no, it would be implicit in the signing procedure, basically hard-coded guess so - just deal with MANIFEST for now:) has no one made spec for activity signing before? This surly can't be a new invention? it is ... but m_stone may have ideas of course I have seen a draft idea of the properties it should have, with no discussion of implementation. I think it was m_stone's So it has just been a proposal so far in OLP? No actual details, rough or not? so I am guessing that there is no spec. draft idea was like "people sign activities, eligible signers sign the list of eligible signers" no discussion of where to keep files or what signature protocol. homunq: big ouch. Lots to consider then... I will have bundlebuilder have a list of things to recursively magically include in MANIFEST to start out, the list will be just MANIFEST itself. later can add HASHES and signatures/ I mean, include as if they were in MANIFEST even though they never will be. I will also make bundlebuilder emit warnings for everything it ignores, with an option to shut up (you could pass gitignore to the shut-up option). I mean, for everything not in MANIFEST