18:30:09 #startmeeting Fedora Board public IRC meeting 18:30:09 Meeting started Wed Jun 27 18:30:09 2012 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:19 #meetingname fedora_board 18:30:19 The meeting name has been set to 'fedora_board' 18:31:01 #topic Roll call (for Board members) 18:31:20 * inode0 waves 18:31:26 #chair jreznik rbergeron pbrobinson cwickert abadger1999 ke4qqq gholms 18:31:30 * gholms lurks, will read scrollback later 18:31:32 .fas cwickert 18:31:32 cwickert: cwickert 'Christoph Wickert' 18:31:40 * abadger1999 here 18:31:41 .fas jreznik 18:31:41 jreznik: jreznik 'Jaroslav Reznik' 18:31:46 #topic abcef 18:31:54 #chair inode0 18:32:05 jreznik: seems meetbot only accepts commands from you. make us chairs please 18:32:15 cwickert: ok, mmt 18:32:17 :) 18:32:30 #chair jreznik rbergeron pbrobinson cwickert abadger1999 ke4qqq gholms inode0 18:32:30 Current chairs: abadger1999 cwickert gholms inode0 jreznik ke4qqq pbrobinson rbergeron 18:32:31 * jds2001 sits in the cheap seats 18:32:37 :) 18:32:54 * Discordian hides in the back row 18:32:55 pbrobinson has an ARM talk at summit, rbergeron is there too 18:33:35 #info pbrobinson sent regrets, he has to give a talk at the RH summit. rbergeron is there, too 18:34:00 what about gomix and sparks? 18:34:02 #info jreznik inode0 gholms cwickert abadger1999 present 18:34:14 cwickert: no info 18:34:36 * jsmith talked with gomix about an hour ago, but he said he was in and out of his office 18:35:01 * jsmith hasn't seen Sparks online at all today 18:35:56 also nb, ping 18:36:45 ok, let's start, they can join us later 18:36:58 #topic Announcements 18:37:11 #action inode0, nb and gholms to update http://fedoraproject.org/wiki/Board#Members with their names and a short summary 18:37:22 #undo 18:37:23 Removing item from minutes: 18:37:32 #action inode0, nb, sparks and gholms to update http://fedoraproject.org/wiki/Board#Members with their names and a short summary 18:37:55 cwickert: +1 (I was about to do it after meeting, why not take responsibility :) 18:38:18 because I think they can do it themselves better 18:38:30 do we have any announcements? or can we go to the most important one - new Board member? 18:38:49 cwickert: usually it's a text from elections... but yeah, they can make it fit better 18:39:43 #topic New Board Member 18:39:58 well, let's welcome inode0 to the Board! 18:40:28 welcome to the dark side, inode0! :) 18:40:31 * inode0 is disoriented 18:40:32 #link http://lists.fedoraproject.org/pipermail/devel-announce/2012-June/000946.html 18:41:14 Welcome aboard, inode0! 18:42:11 and also thanks gomix for his work in a Board 18:43:08 Let's get to the good stuff :) 18:43:10 #info welcome inode0 to the Board 18:43:14 inode0: ok 18:43:35 as always, we're going to start with Open Q&A 18:43:38 #topic Open Q&A 18:44:11 Now that inode0's on the Board, who's going to ask us questions every week? 18:44:20 * inode0 was worrying about that too 18:44:35 open for community to ask Board, please - follow the protocol http://fedoraproject.org/wiki/Board/IRC 18:44:40 abadger1999: Looks like you're leading the charge! 18:44:52 inode0: you can still ask the questions! from Board member to Board :) 18:45:10 jreznik: you don't need to worry about that, I will 18:46:08 let's have a few minutes open floor, and in case of no questions we can skip directly to the rest of agenda... 18:47:06 not sure if this is in scope or not but am having difficulty hooking sssd to my LDAP infrastructure after following System Administrators Guide for F17. Looking for directions on who to talk to. 18:48:09 Sean_McG: Not in scope but you can ask support questions on #fedora or talk to the docs team in #fedora-docs to update the documentation. 18:48:26 (And if you know how the documentation needs to be changed, that would likely be helpful :-) 18:48:32 OK 18:48:58 also you can try to reach devels, looking for a good contact (in case it's not a docs problem) 18:50:37 #info Sean_McG asks about difficulty hooking sssd to my LDAP infrastructure after following System Administrators Guide for F17 -> out of the meeting scope, sent to the right channels :) 18:50:54 anybody else (not talking to inode0 now :) 18:52:47 waiting one minute -> board business 18:55:03 #topic Request for clarification on localization of Spins (#136) 18:55:31 cwickert: it's your turn as your action item from the last meeting was to ask spins sig for proposal how to handle it 18:55:35 any progress? 18:55:38 some 18:55:51 I have been working a little bit on the wiki page and on the guidelines 18:56:07 but I have not yet sent out the mail to the spins list, so there was no discussion yet 18:56:30 overall I don't think we need to change a lot, but still I need the SIG to officially confirm it 18:56:45 the next thing was the dorrie app 18:56:55 I sent out a mail but nothing has happened 18:57:02 need to poke the folks again 18:57:22 that's all for spins, or was there another action item? 18:57:59 #info cwickert has been working on wiki page and the guidelines, waiting for Spins SIG to officially confirm it 18:58:25 #action cwickert to send out a mail to start the discussion with the spins people 18:58:28 #info regarding the dorrie app - no updates yes, cwickert to poke folks 18:58:52 cwickert: thank you for updates 18:59:54 anything else for spins? 19:00:19 cwickert: do you have a llink to the wikipage? or is it the same one, just updates? 19:00:22 updated? 19:00:45 http://fedoraproject.org/wiki/Spins_Guidelines#Localized_Spins 19:01:13 cwickert: could you comment the status in the ticket? thx 19:01:50 ok 19:01:52 cwickert: If you have a different contact, you could also try contacting decause about dorrie 19:02:09 (He ran the program that had some students working on it) 19:02:20 abadger1999: I have his address, the problem is more about the old owners 19:02:24 19:02:36 #action cwickert to update #136 19:03:33 abadger1999: who has admin privileges for projects on fedorahosted? 19:03:46 I'd skip future of release names for today - no update from me and rbergeron is out too today 19:03:59 or do you have something on it? ^^^ 19:04:00 abadger1999: I mean, if I cannot reach them, should I just file a infra ticket? 19:04:36 cwickert: Yeah, please do 19:04:52 ok, I'll nag one more time and then file a ticket 19:05:12 basically they all agreed to accept new team members and merge the code 19:05:15 hi guys 19:05:18 it just never happened 19:05:30 the meeting is starting at 8 pm right? 19:05:48 ibancioiu: board meeting started at 7:30 :) 19:05:48 * thunderbirdtr think meeting time ? 19:06:15 yes 19:06:41 thanks 19:06:42 ibancioiu: 6:30 UTC to be correct 19:07:02 ibancioiu: you sent me a mail, right? about the Romanian ambassadors IIRC 19:07:15 it's overrun a bit I think 19:07:17 i think yes 19:07:32 btw. it leads to another topic - we have a new Board - what about the meeting schedules? is it ok for you all? 19:07:39 ibancioiu: ok, we can probably discuss this later in the EMEA ambassadors meeting 19:07:54 cwickert, ibancioiu: yes, please -> emea meeting 19:08:27 cwickert, emea meeting starting at 20:00 UTC 19:08:36 i'm not understanding :| 19:08:37 ibancioiu: right 19:08:40 ok 19:08:44 i understanf now ;) 19:08:46 pls guys :) 19:08:49 understand* 19:09:19 ok, lets move on, otherwise we'll be running late the the EMEA meeting 19:09:20 ok, let's move to something more juicy :) 19:09:40 #topic Secure boot (#138) 19:09:43 ! 19:10:07 cwickert: go on 19:10:25 * cwickert wonders if he wasn't supposed to do a status update on his board goals before we discuss this contriversial topic 19:10:50 cwickert: do we still do a goal status updates? 19:11:07 but if you have something important - then go on 19:11:21 not really 19:11:27 lets do secure boot then 19:11:29 if we have something exciting to share as I understood it 19:11:39 inode0: yep 19:11:53 * jreznik wants to hear exiciting news from cwickert! 19:11:57 I think we stopped doing updates afte the transition to rbergeron as FPL (unless you've accomplished something you want to report this week). 19:12:23 not really, I just thought I was to do it again 19:12:25 abadger1999: indeed 19:12:29 so lets move on 19:13:02 cwickert: it was even removed from meeting wiki page, so you have a good memory to remember the date :) 19:13:28 for secure boot 19:13:59 So regarding secure boot -- mmaslano (I believe on behalf of fesco) opened a ticket for us to look at it from a political perspective. 19:14:13 mmaslano asks, if there's consensus on Board that Secure Boot is or is not the future for Fedora - it was shortly discussed on FESCo before 19:14:54 #link http://fedoraproject.org/wiki/Features/SecureBoot 19:14:58 isn't the issue whether we should pay M$/verisign for a cert? 19:15:13 Discordian: no. 19:15:16 #info mmaslano asks, if there's consensus on Board that Secure Boot is or is not the future for Fedora 19:15:20 or rather -- payment is not the issue 19:15:53 its seems likely that the new generation of kit will use secure boot 19:15:56 yep, money are not an issue here... it's more question of freedom as one of the values of Fedora 19:16:30 ready for some questions about that specifically? 19:16:47 you can find our definition of freedom here - https://fedoraproject.org/wiki/Foundations 19:16:48 The question is more about whether we think we're sacrificing necessary freedoms if we proceed with the (or another) proposal for Fedora to run out of the box on Securre-Boot enabled hardware. 19:17:22 Regarding the FSF definition of software freedom who sees a conflict there? 19:17:25 I agree that the money is a minor issue 19:18:18 inode0: from FSF POV - ability to create remix? it probably goes against it 19:18:34 how? I don't see how that isn't allowed. 19:19:17 sorry, I don't understand what conflicts with the FSF definition here 19:19:23 you can remix and (a) use your own keys or (b) disable secure boot or (c) ask for 3rd party permission 19:19:54 so there is this mini boot loader, I assume the code is free, but the resulting binary will be signed, right? 19:19:56 * inode0 doesn't see any conflict with the FSF definition here either but if someone else does I'd like to understand. 19:20:00 clearly disabling secure boot would be what I'd do 19:21:05 is my assumption correct? 19:21:35 cwickert: I've made the same assumption but I asked in the Board ticket whether that was correct. 19:21:37 btw: I post FSF there as a reference... but yeah, we should check if this conforms to our freedom definition at first 19:21:42 Though I can see that might be a problem for stuff in secure environments that use say MLS 19:22:20 and are we allowed to distribute binaries? I think so. the only thing a random person cannot do is to build a new binary and have it signed 19:22:51 only Fedora would be able to request signing of new binaries through MS developer portal 19:22:54 what would, for arguments' sake, RMS' possible rejection do to all this? 19:23:07 they can do that too as it has been described, but reliance on someone else signing is arguably problematic 19:23:45 inode0: signing is an additional step, if the binary is unsigned turn of SecureBoot 19:23:50 cwickert: anyone paying $99 can do that just like Fedora 19:23:54 or that 19:24:22 * cwickert really cannot see a violation of any of the definitions 19:24:35 or they can sign it with their own key, they have three options 19:24:52 One thing I'm worried about is how the signed bootloader interacts with non-Fedora official OSs 19:24:52 the only thing I'd like to make sure is that people can disable secure boot and install just like they did in the good ol' times 19:25:16 abadger1999: it will only boot Fedora kernels? 19:25:21 Can you boot Ubuntu using Ubuntu's strategy for working with Secrue Boot, for instance. 19:25:34 I don't think so 19:25:34 * jreznik personally does not like the proposed plan how to do it and is not happy with it but understands it as probably the only viable compromise... 19:25:36 cwickert: It will at least boot Windows in addition, won't it? 19:25:45 don't know 19:26:08 I think we will require kernels to be signed 19:26:22 I think we cannot make *any* decision and I think we should first gather all our questions in the ticket 19:26:35 inode0: Sure... but by what and who? 19:26:37 and then as FESCo or mjg59 to respond 19:26:51 by something that keys exist for in the firmware :) 19:27:26 It'll boot anything that's either signed with the Fedora key or signed by a key the firmware trusts 19:27:29 It seems like our bootloader allows us to sign the Fedora kernels with a key owned by Fedora. I'm not so sure if it allows keys known to UEFI to be used as well. 19:27:33 So yes, you'll be able to dual boot 19:27:38 Or if it allows keys not known by UEFI to be used. 19:27:48 Or if it allows keys to be imported. 19:27:56 Cool. 19:28:14 for me - the board should support or not support it - as it's a political decision what affects one of our values -> then we should allow devels/fesco to find the right technical solution 19:28:23 If we need a way to add keys, we can build one, but it hasn't been clear that such a thing has any benefit yet. 19:28:47 mjg59: Now with the Ubuntu strategy... their kernel won't be signed, correct? So they can't dual boot? 19:28:53 They can dual boot 19:29:02 Their first stage bootloader will probably be the same code as ours 19:29:02 mjg59: Or does our mini-bootloader load their minibootloader which is signed? 19:29:13 They'll just swap out our key for their key 19:29:49 mjg59: Was that comment tangential to the question of dual booting? 19:29:52 pls avoid a technical issues/question now 19:29:53 Yes 19:29:54 Does that mean we will be using two stage 2 bootloaders? Or did they backpeddle? 19:30:00 Cool. 19:30:06 abadger1999: dual booting is really unrelated 19:30:19 From a technical perspective there'll be a small bootloader signed by Microsoft which will then launch grub 2 signed by us 19:30:20 pjones: Unrelated to what? 19:30:26 abadger1999: to secure boot at all? 19:30:33 It is related to the political/freedoms question I think... 19:30:52 If your hardware would otherwise boot an operating system, you'll be able to dual boot that operating system 19:30:56 I mean, secure boot doesn't really restrict your ability to dual boot. 19:30:59 I think we first need to understand the technical details to see if it affects the political question 19:31:04 cwickert: +1 19:31:05 It's not affected by it. 19:31:13 if I can no longer dual boot, then I loose some freedom 19:31:29 cwickert: Not sure I can say this any more clearly :) 19:31:55 pjones: Okay. So -- what's all this about making sure that hte kernel and hardware-touching drivers are trusted? 19:32:01 this is a pretty loose notion of freedom 19:32:06 pjones: Is that not actually a part of Secure Boot? 19:32:13 That is, but that's not about dual booting 19:32:36 cwickert: and we are again back to definition of "freedom"... for you dual boot is your perception of loosing freedom etc. 19:33:05 We're requiring a signed kernel because otherwise it's trivial to use our bootloader to attack other operating systems 19:33:06 that's why I think Board should decide not based on technical problem, but to endorse people to work on the issue... 19:33:31 abadger1999: the thing about that is that if you can take a windows box that's using secure boot and sneak in a signed version of linux under it, then if that version of linux doesn't stop you from doing certain things, it is effectively a bootkit exploit in itself 19:33:33 is it the whole kernel that needs signing, or just the bootloader? 19:33:44 abadger1999: and as such, we anticipate such a system to get blacklisted quite quickly 19:33:45 jreznik: I totally disagree. we cannot make an abstract decision without knowing the technical foundations 19:33:49 Sean_McG: The bootloader and the kernel are different things 19:34:01 I know 19:34:12 Sean_McG: with our proposal they' 19:34:18 Sean_McG: with our proposal they're both signed, but not with the same keys 19:34:25 Sean_McG: So when I say that we're requiring a signed kernel, that's because the kernel will need to be signed 19:34:42 pjones: yes, the ability to use an untrusted version of an OS to exploit the rest of the system seems pretty straightforward. 19:34:58 abadger1999: yeah, not at all a giant leap of the imagination. 19:35:06 pjones: What are the ramifications of getting blacklisted? 19:35:16 Our media no longer boots 19:35:29 mjg59: Can we have another key signed? 19:35:29 yikes 19:35:30 abadger1999: next time an update to the machine happens, we stop being an OS in its eyes. 19:35:31 If we don't have key transition processes in place, installed computers stop booting 19:35:53 pjones: By update to machine, you mean, an update to the UEFI blacklist? 19:35:54 abadger1999: Yes, the policies there are fairly well understood 19:35:57 so, in terms of process, what happens is that we get notified and there's a 30 day window where we get to fix the problem 19:36:05 mjg59: will I still be able to 1) do dual boot 2) run a custom kernel and 3) install Fedora with secureboot turned off and then directly boot to grub? 19:36:08 abadger1999: We need to make sure they're written down and that the relevant people know how to carry them out 19:36:16 cwickert: (1) yes (2) yes (3) yes 19:36:20 and then the next DBX update will happen, and it'll probably include a hash of our bootloader binary 19:36:28 thanks mjg59 :) 19:36:29 well, seems like cwickert and abadger1999 prefers to solve technical issues first - proposal - let fesco deal with the technical aspect and stamp the proposed solution later by board? 19:36:31 for a more severe problem it may include our key, and we'd be issued a new key 19:36:43 I'm really not sure this is a right place/meeting to try to solve it 19:36:46 or, you know, if we aren't interested in solving the problem, we wouldn't be issued a new key. 19:36:52 jreznik: Well... the thing is -- I'm not sure I'd stamp yes to any technical solution. 19:37:06 But I very well might stamp yes to certain technical solutions 19:37:30 jreznik: I am done with my questions. if these 3 conditions are met, I don't see how freedom is limited and am fine to make a 'political' decision 19:37:50 cwickert: we would probably still have you running shim and it running grub if you disabled secure boot, just because installation is easier that way 19:38:16 pjones: Is there any way to ask the signing authority whether the ubuntu contention that this is only meant to work on preboot is valid or not? 19:38:16 cwickert: but there's no fundamental reason that /has/ to be true, and shim would have no real effect in the case that SB is disabled. 19:38:22 pjones: shim is the mini-bootloader thing? 19:38:26 cwickert: yes 19:38:27 as opposed to us thinking one thing and them thinking another? 19:38:37 abadger1999: can I answer that in private? 19:38:42 pjones: k 19:38:45 err. 19:38:50 pjones: can you tell the whole Board? 19:39:00 pjones: I'll cc you on the ticket so you can answer there. 19:39:02 abadger1999: I'm working on getting some more public guidance 19:39:07 I can probably tell the board, but I don't know that I'm allowed to answer in public. 19:39:36 pjones: Board trac is private one 19:39:41 pjones: Sounds good. We can continue that part on the Board trac. 19:40:05 does any of the board members present see a real thread to our freedom foundation? or is anybody generally unhappy about the move? 19:40:54 is anyone generally happy about the move? 19:41:12 inode0: well, there are several things being fixed as a side effect that really we should have done years ago 19:41:24 inode0: so in a very limited sense, yes? 19:41:42 inode0: also I'm kinda happy about having a solution about bz#998 19:42:03 I don't really see this as freedom vs. convenience, mostly as this convenience vs. that inconvenience if that makes sense 19:42:36 * jreznik is not very happy but understand the compromise... I still see somehow the freedom violation here but I agree with inode0 19:43:02 booting will be easier, but there may well be more post-boot issues new users aren't comfortable with 19:43:24 I'm unhappy about this but I'm straddling the fence on considering this the "least bad" option. Gotta collect more information before I decide how I feel for sure. 19:43:29 remixes aren't thrilled, but still can happen 19:43:35 abadger1999: +1 19:43:57 I do worry about tens of thousands of dollars of pressed media going down the drain at some point. 19:44:57 same here. while don't see a real thread to our freedom, I am not totally happy. what I would like to see in a perfect world is that anaconda does a 'traditional' install if secure boot is off. and prehaps an easy way to install it, say a meta package that installs and enables everything 19:44:57 pjones, mjg59: do you think is there any (even small) possibility of having our own linux (generally open source) common signing authority? I read it will be difficult, expensive but... 19:45:06 inode0: additionally remixes can independently choose their own policy regarding users installing their keys or the signing service option. 19:45:36 jreznik: We've shopped that around and found /nobody/ even remotely interested in hosting such a thing. I don't think it'll happen. 19:45:45 jreznik: I'd be welcome to somebody proving me wrong. 19:45:54 pjones: exactly 19:46:37 cwickert: if the board tells us "don't install shim if SB is disabled", we can do that, but it has some implications 19:46:50 pjones: we are getting to the point when it affects everybody - maybe this can convince/force people to take an action? at it's going to affect everyone and everyone has to go through the same issues as we... 19:47:32 hey, we are out of time (actually 17+) - do we have any generic agreement/proposal ready? 19:47:33 cwickert: 1) it means the layout is variable, which makes debugging (slightly) harder in the general case, 2) it means if the user then enables SB, the system will just stop working for no apparent reason even though we support SB 19:48:05 have any SB devices shipped yet? 19:48:10 Maybe some action items: Board members should add their questions to the ticket. 19:48:24 mjg59 and pjones can answer there. 19:48:28 jreznik: the expense of setting up a CA is enormous, and AIUI (I am not a or your lawyer...) there's also pretty much unlimited tort liability for doing so. 19:48:33 #action Board members should add their questions to the ticket, mjg59 and pjones can answer there 19:48:52 limited devices have shipped to oem channels 19:48:52 If there's discussion to be had (beyond questions) we should probably do that on either fedora-devel or fedora-advisory-board 19:48:58 * inode0 is curious about earlier comment regarding ubuntu's use or the same shim 19:49:07 What's the url for the ticket? 19:49:07 pjones: yep, I understand it will be enormous but we are no longer poor community, there's the whole commercial ecosystem around... 19:49:10 inode0: I cna dig up the public thread about that 19:49:12 oh, I'll get an email I guess. 19:49:26 if they use efilinux loader when secure boot is enabled how could they use the same shim? 19:49:30 pjones: yep, you'll get email once on CC 19:49:40 yep, see it now 19:49:41 abadger1999: no, not on f-dl please. there will be too much noise. I only want info that is relevant for us making a decision 19:49:45 pjones: https://fedorahosted.org/board/ticket/138 19:49:59 cwickert: That's what the ticket is for :-) 19:50:02 Summarizing. 19:50:12 ok 19:50:14 But if we get discussion... I don't want that in the ticket :-) 19:50:24 alrighty 19:52:11 ok so the proposal - let's continue with technical discussion on list (f-d), Board member to summarize discussion in the ticket 19:52:24 inode0: https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html <= pieces of the Canonical discussion are all through this month but that's the main thread I found 19:52:30 jreznik: +1 19:53:33 #agreed interested parties to continue with technical discussion on list (f-d), Board member to summarize the discussion in the ticket 19:53:33 abadger1999: right, which sounds like a different shim but this isn't as important as why they are worried about using grub2 while we aren't?! 19:53:43 and I would add + cooperate with FESCo regarding technical issues 19:54:15 mjg59: btw, I especially liked this post: https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035397.html :-) 19:54:36 thanks guys for coming today - it was a little bit longer meeting, we have to end due to emea ambassadors meeting - I'm going to end meeting in one minute 19:54:48 inode0: s/grub.efi/efilinux.efi/ 19:54:57 sorry for the noise earlier 19:55:09 Sean_McG: No worries :-) 19:55:19 inode0: As far as their grub2 concerns - yeah, good question. Unclear. The FSF seem fine with it. 19:55:42 #endmeeting