16:00:20 #startmeeting Fedora Board Meeting 16:00:20 Meeting started Tue Sep 13 16:00:20 2011 UTC. The chair is jsmith. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:32 #meetingname fedora_board 16:00:32 The meeting name has been set to 'fedora_board' 16:01:12 #chair jds2001 abadger1999 gomix jreznik ke4qqq kital pbrobinson rudi_ 16:01:12 Current chairs: abadger1999 gomix jds2001 jreznik jsmith ke4qqq kital pbrobinson rudi_ 16:01:21 #topic Roll call (for Board members) 16:01:27 * jreznik is here 16:01:28 Joerg Simon 16:01:29 * jsmith is here 16:01:35 * rudi_ is here 16:02:02 * nirik is around 16:03:05 Ok, looks like we have a few Board members around, and hopefully we'll have more show up in the next few minutes 16:03:05 * abadger1999 here 16:03:22 We now have a quorum :-) 16:03:34 #topic Updates 16:03:43 I have two quick updates 16:04:04 1) The primary hotel for FUDCon Milan is filling up fast. If you're going and need a room reservation, let me know ASAP. 16:04:15 Otherwise, you'll probably have to book in one of the secondary hotels 16:04:39 2) Fedora 17 naming opened today. You have until the 20th to add your suggestion to the wiki 16:04:56 #link https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_17 16:05:45 Anyone else have status updates they'd like to share, before we move onto Board business? 16:06:03 jsmith: for 1), has kparal contacted you today? 16:06:24 jreznik: Yes, we're working out his situation with hotel rooms for FUDCon 16:06:40 jsmith: great! thanks 16:06:48 jsmith: For 1) I know someone who had to book at a secondary hotel already. 16:07:01 jsmith: Is it worhtwhile for me to have them talk to you? 16:07:20 * jds2001 somewhat here, have $DAYJOB priorities to attend to though :( 16:07:30 abadger1999: They can surely talk to me -- I might have one or two rooms left at the primary hotel 16:07:40 * abadger1999 will check with them. thanks 16:08:02 No problems 16:08:37 If there are no other updates, let's go ahead and move on to Board business 16:09:19 #topic Board Business: Ticket 113: Request domain of [chinese].fedoracommunity.org for Fedora Chinese Community 16:09:57 This is a repeat of ticket 75 16:10:30 In ticket 75, the Board approved both cn.fedoracommunity.org (for China) and zh.fedoracommunity.org (for the Chinese language). 16:11:17 I think the only thing holding up formal approval from the Board is to see the logo usage 16:11:22 jsmith: was it not zn? 16:11:35 kital: I think "zn" was a typo... 16:11:42 kital: But I could be wrong. 16:12:57 ok #fedora-zh is the chinese irc channel so it seems indeed a typo 16:13:21 zn is apparently the country code for Zinaire 16:13:27 (not sure where that is, to be honest) 16:13:33 ah i have it 16:13:34 "zh" is the correct code to represent "Chinese". However, "cn" is just a subset of "zh" where "tw", "hk", even "sg", "my" (and all other location with Chinese population can share "zh" code. 16:13:44 from the ticket 16:14:19 Right... And to be honest, I'd rather avoid the politics of having cn + tw + hk 16:14:25 ;) 16:14:27 are most fedoracommunity sites per-country or per-language? 16:14:47 abadger1999: We've done both in the past 16:14:53 first link, sorry for msdn :) http://msdn.microsoft.com/en-us/library/ms533052(v=vs.85).aspx 16:15:17 with zh-xx it would be per country and language 16:15:41 This is kinda getting into details but it seems like zh.fc.o should be canonical and cn.fc.o should be the domain that redirects. 16:16:01 Either way, as long as they both redirect to the same site, I'm fine. 16:16:59 That's what we approved before, so I don't think it should be too controversial 16:17:09 in the spirit of avoiding politics :-) 16:17:17 yeah, I'm fine with thi. 16:17:34 +1 to use both/do redirection 16:18:32 OK, I'll leave the ticket open pending the addition of the Fedora logo to their theme, but otherwise I think we're set 16:18:37 Any other comments or concerns? 16:19:01 nope 16:19:07 #agreed As we agreed in ticket 75, we'll allow for both cn.fedoracommunity.org and zh.fedoracommunity.org, as long as they point to the same site 16:19:18 #topic Any other Board business? 16:20:27 If there isn't any other Board business to discuss, I'll open things up for a general question and answer session in two minutes 16:20:54 jsmith: i am not sure if this is the place to dicuss my question regarding 16:20:58 https://fedorahosted.org/board/ticket/11 16:21:04 Respond to Russian Fedora Initiative 16:21:18 Sure, let's go ahead and discuss it 16:21:30 i made a comment back in January 16:21:32 #topic Board Ticket 11: Response to Russian Fedora Initiative 16:21:48 as there is no progress i think we should close the ticket 16:22:45 I agree... 16:22:56 In fact, there are a bunch of tickets that can be closed -- I'll work on those this week 16:23:34 oki doki lets close it 16:24:48 #agreed close ticket 11 due to lack of response 16:24:56 OK, I've closed the ticket 16:27:07 nothing more from my side right now 16:27:19 OK 16:27:23 Shall we move on to Q and A? 16:27:33 +1 16:27:34 #topic Open question and answer session 16:27:53 As a reminder, we kindly ask participants to follow the protocol to help us keep our conversations from overlapping 16:28:05 Please type a question mark (?) if you have a question, and wait to be called on 16:28:18 If you have a comment on the current question, please type an exclamation mark (!) 16:28:34 ? 16:28:37 => nirik 16:29:15 I have a FYI / seeking feedback thing to bring up. 16:29:24 OK... go ahead! 16:29:55 Given the high profile security issues some Linux related sites have had in the news, we were thinking it might be good to require everyone to change passwords/keys/certs and review their security. 16:30:18 There's a thread on the infrastructure list about this, and we would welcome any feedback before deciding on anything. 16:30:19 ! good point 16:30:27 http://lists.fedoraproject.org/pipermail/infrastructure/2011-September/010803.html 16:30:41 +1 16:30:45 +1 from me 16:30:46 so, I thought I would bring it up here to increase visibility and bring it to the boards attention. 16:30:49 EOF 16:31:00 I think it's a good idea 16:31:14 My only concern is the affect it might have on the development schedule 16:31:27 That being said, security is important 16:31:28 ! I'm fine with password changes, but I think changing SSH keys is stupid. The entire point of them is so that if the public key is compromised, you are still safe. 16:31:29 ! 16:31:40 => sgallagh 16:32:09 (the idea is to type an exclamation mark and then wait to be called on) 16:32:19 (sorry, will behave next time) 16:32:27 => nirik 16:32:54 sgallagh: The idea is that attackers of these sites have been actively working on stealing ssh keys as their means of attacking hosts. 16:33:36 ? 16:33:37 I would hope that most if not all our contributors have good security handling, but this is more to make those who don't have such reconsider and hopefully do better moving forward. Ie, those people who may have private keys they shuffled around or left on old machines, or the like. 16:33:50 sgallagh: So changing ssh keys and reminding people to use a strong password to protect their private keys would negate any keys that the attackers have already stolen and are in the process of cracking the passwords on. 16:34:01 I'd like to also have a updated document to point people to when doing this on good security practices (CSI) 16:34:18 nirik: I think that's a great idea 16:34:21 also, I welcome concerns in the thread there. please do post them. 16:34:23 EOF 16:34:52 nirik: If you need help with the mechanics of getting CSI updated, I'm sure the docs team would be happy to help... sometimes DocBook/Publican can be a bit tricky if you're not used to it 16:35:08 +1 16:35:27 ? 16:35:33 => DiscordianUK 16:36:16 forcing everyone to change is gonna be problematic 16:36:36 From a technical standpoint? 16:36:37 ! 16:36:44 we will lose many along the way 16:36:53 => nirik 16:37:38 D 16:37:42 EOF 16:37:59 It shouldn't be hard from a technical standpoint. Basically mail everyone to change and point to docs, then require them to login to fas and change pass and upload new key. If the new key is the same as the old key, abort. ;) On the political side it's not too much time or work... I don't think too many people will refuse. 16:38:22 we also had the recent cla_fedora to cla_fpca change, and people seemed to handle that without too much issue. 16:38:25 ! 16:38:33 ? 16:38:41 ! 16:38:45 anyone who doesn't update is likely not really active anymore, and will need to relogin to start being active again. 16:38:46 EOD 16:38:50 EOF even 16:38:54 -! 16:39:39 => inode0 16:39:52 (then Sparks) 16:40:13 What will trigger these (over)reactions in the future? There is hacking 24 hours a day - every day. 16:40:31 ! 16:40:36 => nirik 16:41:11 inode0: the thing is - there's big chance our contributors have accounts on LiFo server with bigger prob. than any other server 16:41:34 some, but I suspect very few 16:41:42 sure, always is. Our last password reset was many years ago, so there may be people who are new or have not considered the issues... I don't see us doing this very often. Say every few years? but timing would be good to think about here also... 16:41:46 LiFo? 16:41:58 DiscordianUK: Linux Foundation 16:42:10 ah right 16:42:20 => Sparks 16:42:22 also, we might consider a way to inform people when they sign up for an account. 16:42:24 yes that is the backlog here 16:42:24 EOF 16:42:27 * inode0 doesn't want this to be the reaction whenever someone gets hacked :) 16:43:00 ! 16:43:09 Just my $0.02... this isn't an over-reaction. This, IMO, should be done on a *regular* basis. Changing passwords and crypto on a regular basis (annually?) is just good security. 16:43:13 EOF 16:43:13 doing it every other year as a matter of routine wouldn't bother me though 16:43:22 I think we should also be very careful with the way we message this -- we want to be clear that we're not aware of any compromises within Fedora at this time 16:43:24 => nirik 16:43:46 ! 16:43:47 ! 16:44:22 yes, there are no known issues related to other sites compromises. If you read the list thread, there's additional items we are talking about doing here too like changing the password requirements, so we want everyone to have a password that meets them. 16:44:31 (As a quick suggestion, you can type up your question in other window and then copy/paste when I call on you -- that will help speed things up) 16:44:45 => sgallagh 16:44:48 we don't want to do this too offten as it's a hassle, but every few years seems not too bad to me. Feedback welcome again. :) 16:44:50 END 16:45:29 It's a myth that changing passwords regularly improves security. It's quite the opposite. When you are forced to change your password, people end up very quickly in situations where they cannot remember them 16:45:39 This leads to the much less secure behavior of writing them down for reference 16:45:42 ! 16:45:43 +1 16:45:59 EOF 16:46:00 ! 16:46:05 => DiscordianUK 16:46:34 sgallagh, said what I was going to 16:46:37 EOF 16:46:49 => NiveusLuna 16:47:08 sgallagh does have a point. I've been there. But there's something there to help: secure password managers. 16:47:35 Examples like KeePass (KeePassX for Linux and OS X) with secure cryptography only require one password to use, but can generate and store many more. 16:47:47 for browser-based, there's also LastPass. 16:48:00 Keeping track of a lot is a hassle, but those utilities do help. 16:48:03 EOF 16:48:06 ! 16:48:56 This meeting probably isn't the best venue for the nitty-gritty discussion of exact tools and procedures -- I think the infrastructure thread is probably more appropriate 16:49:03 => sgallagh 16:49:12 jsmith: +1 16:49:20 The use of such password managers can be a recommendation (I use one), but it's not enforceable as a policy. 16:49:32 sgallagh: +1 16:49:46 let's get back to topic please 16:50:40 ? 16:50:58 => sgallagh 16:51:05 Is there any way we could subsidize a mass Yubikey purchase for our users? 16:51:17 ! 16:51:35 We've talked about it before -- but the logistics around distribution make it somewhat impractical 16:51:37 => nirik 16:52:36 Yeah, I don't think yubikeys for everyone would be practical. However, there are things like google authenticator / OAUTH that are coming up... we could possibly leverage those for 2-factor auth. 16:52:52 I'd love to see that down the road. 16:52:54 EOF 16:53:06 Assuming the Infra team is OK with it, we could certainly start with smaller groups (infra, provenpackagers, etc.) as a first good step on something like Yubikeys 16:53:17 ! 16:53:23 To be honest, though... that sounds like an Infra question more than a Board question 16:53:32 => sgallagh 16:53:39 At minimum, perhaps we should require that anyone with access to any of the actual infrastructure uses a yubikey. 16:53:44 jsmith, nirik: I thought we did deploy yubikeys to everyone in sysadmin-main before? 16:53:51 All members of sysadmin-* 16:53:58 ! 16:54:01 EOF 16:54:11 abadger1999: I think there was an effort to do that at one time, but FAS group memberships change 16:54:13 => nirik 16:54:21 abadger1999: I don't know if that's current or not 16:54:21 also, 16:54:40 I'd like to point out that our present yubikey infrastructure makes us less secure in some ways. 16:54:45 it's not two factor auth 16:54:50 it's either-or auth 16:54:52 abadger1999: +1 16:55:14 abadger1999: Could you explain in greater detail, please? 16:55:27 There was an effort to distribute them to sysadmin-main folks, but It was never completed I don't think. sysadmin is probibly too big... it has 122 people in it 16:55:31 it does allow me not to type my password into the web apps; but I still need to use the password for sudo. 16:55:52 yes, if we want to enforce yubikey, we need to improve its setup. 16:56:07 if I could use the yubikey everywhere, then we might have a tradeoff in security where my passwords could be a huge, random, unmemorizable string and I'd just use the yubikey. 16:56:07 ! 16:56:14 again tho, these may well be more infra questions that board. ;) I just wanted to bring this up here for more visibility/feedback. 16:56:15 EOF 16:56:30 but going two-factor might be better. 16:56:49 => DiscordianUK 16:57:03 yubikey is two factor 16:57:23 sgallagh: I can use either my fas password *or* my yubikey to authenticate myself. that means an attacker can either crack my password, or compromise my yubikey (compromise the yubikey server, steal my key, etc) 16:57:28 but it's tricky to get here in Europe 16:57:33 eof 16:57:52 It's not inherently two factor. 16:58:01 yubikey is a single factor (something I have) 16:58:02 abadger1999: (I'm out of turn, I know). That says to me that it's set up incorrectly, not that there's anything inherently wrong with yubikey. 16:58:21 ! 16:58:29 Proper configuration would be password concatenated with yubikey string 16:58:39 it's only two-factor if we set our auth up to require both yubikey and my password. (rather than or) 16:58:57 the project would not be impricwed 16:59:28 sgallagh: I'm not saying that there's anything wrong with yubikeys. I'm saying that the way we're using it does not give us added security (and in some ways, gives us less security). 16:59:36 the project would not be improved if we mandated yubikey IMHO and sorry 16:59:56 16:59:58 * nirik repeats " yes, if we want to enforce yubikey, we need to improve its setup." 17:00:56 DiscordianUK: We've (infra) thought about it and I think we'd have to do something like: if you register a yubikey then you *must* do two-factor wit hthe yubikey and password; otherwise, you only need your password. 17:01:16 OK, so I think we've probably talked about this topic enough for today's meeting 17:01:19 * inode0 has something to say about this but thinks we've carried on too long 17:01:27 inode0: Go ahead :-) 17:01:44 * inode0 will wait until the meeting closes 17:02:01 * jsmith encourages everyone to share their concerns and comments on the Infrastructure list thread that nirik pointed us to 17:02:52 #topic Any other questions or concerns? 17:03:16 We're at the top of the hour, but I'll stick around for a few more minutes if anyone has other topics they'd like to discuss. 17:03:33 If I don't see anything in the next couple of minutes, I'll close the meeting 17:04:43 quick ? 17:04:53 gholms: Sure, go ahead! 17:04:53 The next meeting is in two weeks, right? 17:05:01 gholms: The next public IRC meeting, yes 17:05:06 Cool. Thanks. 17:05:33 #info Next public IRC meeting will be on September 27th at 16:00 UTC 17:05:47 OK, if there's nothing else, I'll end the meeting 17:05:51 Thanks to everyone who participated! 17:05:55 thank you jsmith 17:05:55 #endmeeting