18:02:29 #startmeeting 18:02:29 Meeting started Mon Mar 5 18:02:29 2012 UTC. The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 18:02:29 18:02:29 Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired 18:02:47 [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting 18:02:49 \o 18:02:53 o/ 18:03:03 [TOPIC] Announcements 18:03:15 * Thanks 18:03:28 Kilian Krause (kilian) from Debian provided debdiffs for lucid for fex (DSAs 2414 and 2259) 18:03:33 Your work is very much appreciated and will keep Ubuntu users secure. Great job! :) 18:03:43 [TOPIC] Review of any previous action items 18:03:55 * jdstrand sbeattie to follow up on qrt bugs from QA team 18:04:39 Yep, did that (finally) 18:04:43 \o/ 18:04:46 sbeattie: thanks :) 18:05:08 [TOPIC] Weekly stand-up report 18:05:14 I'll go first 18:05:29 I finally got caught up on archive admin work 18:05:52 I'm in the happy place this week and hope to catch up on MIR security audits 18:06:02 there is an embargoed issue I am working on 18:06:31 and maybe I can pick back up some pending updates 18:06:48 if not by the end of the week, certainly next week 18:06:58 (assuming nothing else comes up) 18:07:02 mdeslaur: you're next 18:07:10 I'm on triage this week 18:07:28 I released lightdm updates this morning, and am currently testing flashplugin-nonfree 18:07:41 and then I have an embargoed issue I'm working on 18:08:04 I have a few security bugs to research 18:08:13 and then will pick other updates from the list 18:08:19 that's it from me 18:08:20 sbeattie: you're it 18:08:48 I'm in the happy place this week 18:09:28 I'm still working on my glibc update 18:09:55 Once that's done, I'll be focusing on apparmor userspace bugs/workitems 18:10:07 that's pretty much it for me. 18:10:29 is micahg back? 18:10:31 yes 18:12:08 micahg: it's your turn 18:12:12 I uploaded chromium earlier this morning and will be testing that, still trying to get the Firefox/icedtea crash fixed (now with new upstream commit :)), and time permitting webkit, this is also the week before Mozilla's rapid release day, so I'll be staging and testing anything that's available this week 18:12:29 jdstrand: I know, just a little slow typing :) 18:12:57 that's it for me I think, tyhicks? 18:13:08 I'm handling community this week 18:13:13 micahg: let me test chromium when it goes to -proposed again. 18:13:29 jdstrand: as you wish 18:14:06 I will start on a gnutls update 18:14:27 and work on an embargoed issue 18:14:34 that's it for me 18:14:41 jjohansen? 18:15:14 well, I need to post out the revisions to the upstream kernel patches 18:15:34 and debug some mount failures, that people are running into 18:16:01 I am testing the fix to minimization, and we should be able to get that uploaded today too 18:16:59 other than that /me wants to try picking off his remaining work items this week 18:17:50 thats it for me I think jdstrand back to you 18:17:55 thanks 18:18:06 micahg: I meant to ask: how is the webkit progress? 18:19:00 well, if I can spend a little bit of time on it, I should be able to start uploading some test builds to my PPA this week 18:19:32 awesome! 18:19:42 * jdstrand hopes the chromium testing helps there 18:19:51 [TOPIC] Highlighted packages 18:19:58 The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so. 18:20:02 See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved. 18:20:09 http://people.canonical.com/~ubuntu-security/cve/pkg/slim.html 18:20:12 http://people.canonical.com/~ubuntu-security/cve/pkg/icecast2.html 18:20:15 http://people.canonical.com/~ubuntu-security/cve/pkg/libdigest-perl.html 18:20:19 http://people.canonical.com/~ubuntu-security/cve/pkg/xfce4-session.html 18:20:22 http://people.canonical.com/~ubuntu-security/cve/pkg/djbdns.html 18:20:31 [TOPIC] Miscellaneous and Questions 18:20:47 we do have one topic to discuss: 18:20:54 * Discuss another non-native PPA for staging SRUs and development packages 18:21:09 this came up as a result of internal discussions 18:21:23 non-native? 18:21:33 the basic idea is this-- we have PPAs for our security updates, but not our dev work 18:21:44 actually, s/non-native// 18:21:51 no decisions are made (sorry) 18:22:16 would it be helpful to have a team ppa that we all have enabled, for the dev release or SRUs 18:22:30 we wouldn't have any mandatory process around it at this time 18:23:08 but, for example, if sbeattie was preparing an apparmor userspace upload, or jjohansen a kernel upload, or me a ufw upload and we wanted others from the team to test it, we upload there 18:23:20 and then everyone just gets it automatically 18:23:43 is it worthwhile? 18:24:05 jdstrand: This ppa would only be enabled on our machines that we do not use for security update testing, right? 18:24:19 tyhicks: yes. this is for dev work, not security updates 18:24:32 is it any better than having a separate ppa for each project? 18:24:39 tyhicks: ie, you might upload ecryptfs there 18:24:57 jjohansen: it is only better in that it is a one stop for all our dev work 18:24:58 gotcha 18:25:17 ie, we decide we all run with that ppa enable 18:25:20 enabled 18:25:35 as opposed to having 7 different ppas enabled 18:25:41 (or whatever) 18:25:59 hrmm, down side is you can't be selective about which ppa you have enabled 18:26:03 I don't have a staging ppa for ufw anyway, so I think it could help with that sort of thing too 18:26:36 jdstrand: this isn't for experimental stuff, right? this is for "I'm ready to upload, but want some more testing first"? 18:26:44 jjohansen: this is meant to be for fairly stable stuff-- we don't want to break our teammates machines. we can always do that in other ppas 18:26:47 ie: you wouldn't push apparmor dbus stuff in there 18:26:56 mdeslaur: correct 18:27:11 the idea is this is a 'testing' ppa for what is eventually going to hit the archive 18:27:35 experimental ppa' 18:27:37 whether it be the dev release or an SRU (I imagine this is less useful for SRUs since we typically run the dev release) 18:27:45 oops... experimental ppa's would be the daily build ppa's 18:27:55 tyhicks: yes, or soemthing else 18:28:03 again, this should be fairly stable 18:28:08 yep 18:28:12 jdstrand: well, some of us do have stable release machines around as well 18:28:19 * jdstrand nods 18:28:28 * sbeattie looks askance at his build server 18:29:09 * sbeattie is not sure he's got security-proposed enabled everywhere it could be. 18:29:39 generally, I'm in favor of this; I do think it should probably be a seperate ppa from security-proposed. 18:29:51 so, this isn't meant to be an administrative burden. it is meant to allow us to more easily and test the stuff we are uploading 18:30:00 sbeattie: you do know I upload completely untested stuff to security-proposed, right? :) 18:30:08 as do I :) 18:30:09 eg, my 2.8beta1 apparmor upload might have gone there 18:30:41 mdeslaur, micahg: and that's different from the stuff going into devel how? :-) 18:30:50 (it was something I did test and run, but might have been nice to have others run it for a bit before uploading to the archive proper) 18:31:22 I really wanted to test jjohansen's recent kernel-- this could have been something we all could have just gotten 'for free' 18:31:33 jdstrand: It makes sense to me. Instead of everyone being affected by a new bug, it would result in potentially just our team being affected. We would have been affected anyways, if we didn't have this buffer ppa to catch it early. 18:31:47 tyhicks: yes 18:32:03 jdstrand: uh kernel builds from ppas are an absolute pita 18:32:08 If we have systems that are a bit too critical for something like this, we just don't enable it on those systems. 18:32:21 yeah, the kernel is probably a bad example there 18:32:29 I am not advocating this running everywhere 18:33:02 I am only advocating is use for the dev release. we can use it for SRUs if people want. the stuff we upload should be solid in our minds, not experimental :) 18:33:38 re kernel> not sure why, we use to build them all the time in our ppa, but whatever. let's not get hung up on that detail 18:34:19 in other words> whatever machine you are running the dev release on, just enable this ppa too 18:34:42 (not necessarily testing VMs) 18:35:17 do we agree that it could be worthwhile? if we don't like it, we don't need to continue using it 18:35:45 I don't see any negatives. I would have gotten the update on my development release machines either way. 18:36:05 jdstrand: +1 from me. 18:36:34 The only possible negative is that it adds a bit of a delay to the update receiving testing from a wider audience, but I don't consider that a big issue 18:36:38 jdstrand: +1 from me 18:36:50 mdeslaur, micahg, jjohansen: ^ 18:36:54 * micahg wonders if jdstrand wants to cast an official vote :) 18:36:58 I'm indifferent to the idea, 0 from me 18:37:14 * jjohansen is indifferent too 18:37:16 tyhicks: well, keep in mind, we aren't defining process for using it now. if we need a quick upload, we can always do that straight to the archive still 18:37:22 +1 18:37:30 ok, then let's try it 18:37:53 +1 18:38:11 I know sbeattie and mdeslaur don't want it to be ubuntu-security-proposed. I really don't care, but if not ubuntu-security-proposed, what do you want to name it? 18:38:26 micahg: heh, I thought you voted already :) 18:38:28 ubuntu-security-testing? 18:38:34 ubuntu-security-devel 18:38:42 seems like dev/devel should be in there somewhere 18:38:49 mmm, yeah, that's probably better 18:38:57 ubuntu-security-devel-testing 18:39:04 this will have -updates enabled so we can also put SRU stuff in there? 18:39:08 mdeslaur expressed a desire to use it for SRUs 18:39:22 (even though he cast a '0' today :) 18:39:26 ubuntu-security-devel-testing-this-will-eat-your-filesytem-or-brain 18:39:33 jdstrand: watch it or I'll switch to -1 :) 18:39:36 sbeattie: it better not! :P 18:39:41 mdeslaur: makes sense as we have security-proposed for non-updates enabled, also there's the option to copy from security-proposed to this for wider testing as well 18:39:49 mdeslaur: we have enough votes already :P 18:40:06 updates should be enabled. these aren't security updates 18:40:42 cool 18:40:52 ubuntu-security-staging? 18:41:41 I have no problem with that 18:41:42 sure 18:42:21 * sbeattie is also okay with -staging 18:43:29 ok. cool. let's skip the native vs non-native bit for when its actually seen some usage 18:44:36 sure 18:44:36 Does anyone have any other questions or items to discuss? 18:44:42 oh 18:44:43 I've got a question for tyhicks 18:44:53 mdeslaur: shoot 18:45:02 [ACTION] jdstrand to setup ubuntu-security-staging ppa and communicate to team 18:45:02 * meetingology jdstrand to setup ubuntu-security-staging ppa and communicate to team 18:45:13 tyhicks: what's the status on #842647? It's unclear to me 18:45:53 mdeslaur: I tried off and on for several days to reproduce it and no longer can (despite being able to reproduce it in the past) 18:46:09 mdeslaur: So, I went ahead and wrote up a patch over the weekend 18:46:32 tyhicks: could you update the bug please in the next few days so everyone knows what's up with it? 18:46:55 mdeslaur: Yep, my plan is to do it today. I was up in the air while working on it over the weekend. 18:47:08 do it == update the bug 18:47:21 tyhicks: ok, cool...sorry :) 18:47:43 I deserve the questioning since I didn't get my activity report in :) 18:47:58 ehe 18:48:37 jdstrand: sorry, back to you 18:49:05 I don't have anything else 18:49:11 Does anyone have any other questions or items to discuss? 18:52:24 mdeslaur, sbeattie, micahg, tyhicks, jjohansen: thanks! :) 18:52:26 #endmeeting