=== edson is now known as ecanto === mhall119|work is now known as mhall119|SCaLE8x [07:43] www.search2.net [07:44] Is that a typo or are you spamming us? [07:44] elky: spam [07:44] it does appear that now [07:45] elky: i'v just reported it to the ops, its been happening in several channels [07:46] Yeah, i noted. I was going to see if they were a human who could be reasoned with. [07:49] good morning === cypher_ is now known as czajkowski === jamie is now known as JamieBennett === ShadowChild is now known as lukjad86 === DJones_ is now known as DJones === fader|away is now known as fader_ === ikt_ is now known as ikt === fader_ is now known as fader|away === fader|away is now known as fader_ === fader_ is now known as fader|lunch === fader|lunch is now known as fader_ [18:00] jdstrand, kees: meeting? [18:01] mdeslaur: ah, yes. it's that time, isn't it? [18:01] jdstrand: ready? [18:01] kees: my calendar thinks it is :) [18:01] o/ [18:01] :) [18:01] yes [18:01] okidoky [18:01] this week, OOo publication, and then going to check for any low-hanging fruit [18:02] If there's time in the agenda, can I grumble a bit about community integration at the end? [18:02] I'd like to finish some of the qrt stuff I had on my plate (like the additional RNG tests) [18:02] persia: totally [18:02] persia: yes [18:02] THanks. [18:02] probably going to start another kernel update cycle soon too [18:03] looks like we made feature freeze pretty well. [18:03] that's it from me. mdeslaur, you're up. [18:03] I just published pidgin updates. I plan on attacking the new squid issue, and the ffmpeg updates next. [18:04] besides that, I'm on community, so have been going down the sponsoring list [18:04] that's pretty much it [18:04] * jjohansen fades in late [18:04] so I guess I'm up next [18:05] I am triager this week [18:06] I plan to talk to soren walk me through kvm-autotest to see how we can use it in QRT for our gui applications. it should be totally doable [18:06] oooh, I was just thinking about that today in the shower -- I wanted to see if I could build an OOo test [18:06] kees: exactly (though for me it was firefox) [18:07] I worry about use having different resolutions, languages, installed applications in our VMs, though. [18:07] wouldn't Mago be more appropriate for that? [18:07] I looked at it a it on my own last week, but it was not... [18:07] obvious... [18:07] yeah [18:07] how to use it in that capacity [18:07] soren gave that presentation at the sprint and seems to think it shouldn't be a problem-- so I'm hopeful :) [18:08] Mago requires accessibility support. kvm-autotest requires reliable display parameters (which kvm can provide). [18:08] mdeslaur: I looked at Mago a bit, but didn't find documentation on how to really get into it [18:08] plus what persia mentioned [18:08] * robbiew sneaks in the back door :/ [18:09] I'm just kind of afraid with kvm-autotest that it will be hard to always have a 100% reproducable environment [18:09] I plan to see what is next on the 'what CVE to fix next' list, and do that === noy_ is now known as noy [18:09] mdeslaur: I think we can with snapshots, etc [18:10] mdeslaur: anyway, I'm investigating right now, not integrating :) [18:10] ok, fair enough :) [18:10] jdstrand: don't forget, I run my VMs at 1920x1080 [18:10] mdeslaur: if you have some good resources for mago, I'd like them too [18:10] jdstrand: if you start getting somewhere with it, let me know and I can "reproduce locally" :) [18:10] mdeslaur: seriously? [18:10] kees: no [18:10] hah [18:11] mdeslaur: well, I take you point. these would likely have to be 'special' VMs anyway (ie, kvm-autotest and libvirt doesn't make sense afaict) [18:11] oh, okay [18:11] but anyway, we'll see-- I just thought there might be something there, and soren is willing to walk me through it [18:12] * kees hopes to re-use the libvirt-configured VMs [18:12] jdstrand: don't forget to bug soren as much as possible while he's still on the payroll :) [18:12] kees: me too... we'll see [18:13] I might be able to wrap stuff, etc, like I did with vm-tools. but like I said, I've barely looked at it :) [18:13] anyhoo [18:14] if I have time, I'd like to see if I can clean up the apparmor abstractions, esp for firefox/evince [18:14] that's it for duties. I do have two items to bring up-- one is I'm fairly sure related to what persia wants to talk about [18:14] persia: why don't you go ahead? [18:15] Probably :) [18:15] OK. jdstrand and I have been having a productive conversation in a thread at https://lists.ubuntu.com/archives/ubuntu-motu/2010-February/006550.html [18:15] Summarised, the TB and DMB have approved a proposal that significantly limits the scope of "MOTU". [18:16] So, since "MOTU" no longer maps well to "community supported", I'd like to see some initiative from the wider security team (potentially including current members of MOTU SWAT) to define a process that supports the entire archive wihout relying on the scope of MOTU. [18:19] sounds good to me. [18:19] that makes sense to me, but, tbh, it is clear to me how "community supported" is being defined in the new world. I guess "not in officially supported" is one definition, but there then is a team surrounding "not officially supported" [18:19] err [18:19] s/is/isn't/ [18:19] * persia much prefers "not supported by Canonical" to "not officially supported", but yes, this needs thought. [18:19] fair enough [18:19] we'll have the help of the Supported: tag in the packages files [18:20] It's going to be a bit before everything is implemented, so there's time, but it seems appropriate to start thinking about it now so that we don't get caught later. [18:20] yeah, that defines our responsibilities [18:20] persia: Is there anything you see that would need changing in our current process? [18:21] * kees mumbles something about syncSource ACLs in LP [18:21] persia: also, not pointing fingers or being judgemental, but motu-swat has not been active for a while. the reasons are numerous and in part due to lack of process from ubuntu-security (which should all be fixed now) [18:21] mdeslaur: Were I designing the process, and noting that my understanding of your process is entirely based on jdstrand7s email, I'd probably only do the following: [18:21] no amount of our process can reduce the bottleneck that is LP's lack of ACLs, though. [18:22] 1) declare an inclusive security group with responsibility for everything (although some members may concentrate in certain areas). [18:22] but, outside of that, I'd agree: we've tuned the process to eliminate human bottlenecks as much as possible [18:22] 2) encourage all members of that group to actively review and sponsor stuff. [18:22] kees: yes, but if more people submitted patches and more people joined ubuntu-security-sponsors, I think we could handle the publishing bits ok [18:22] 3) have a restricted set that is responsible for pocket copies and USN releases. [18:22] (I'd love to see the volume of community supported patches be a real problem for us) [18:23] I think that's mostly a matter of making sure submitters feel entitled as part of the team. [18:23] persia: this is the team that has responsibility of reviewing everything: https://launchpad.net/~ubuntu-security-sponsors [18:23] I know that when we do stuff in MOTU that involves telling people that submitting patches makes them Ubuntu Developers, we get more patches. [18:23] persia: 3 exists, 2's element of "encourage" hasn't happened, though we've asked the community team for help there. 1 exists as ubuntu-security-sponsors, IIUC [18:24] kees: I think you're right, and that it's just a matter of semantics and communication. [18:24] well, the ubuntu-security team itself is how it is due to ACLs and requiring the possibility for embargoed issues. [18:24] it could I guess be a subteam in this whole thing... [18:25] kees: your understanding is correct on '1' [18:25] persia: our problem has traditionally been that of motivating others; we're usually utterly slammed for time, and doing coaching, blogging, etc can be very time-consuming. [18:25] keep in mind, that the new process for sponsoring security uploads is just that: new this cycle. I personally wanted to see how it worked for a little bit to make sure it was sane [18:26] however, we are fully integrated into the MOTU pages now-- from dholbach's reports, to Sponsoring pages to how you can help [18:26] I understand entirely :) I just wanted to raise the point, because while I think all the process stuff jdstrand mentioned in the email was good, I found some of the phrasing and language exclusive, and based on previous meeting logs, though it was pervasive in the sematics of the team, rather than being jdstrand's email. [18:26] the only thing that wasn't done was an email to ubuntu-motu@ and ubuntu-devel@ [18:27] persia: right now, we always have one team member who is on active community-sponsoring duty, so if a bug is opened and a debdiff submitted, it will get reviewed and uploaded in a few days. [18:27] mdeslaur: Right. I think that's great. I just want to highlight that there are likely to be other groups than MOTU active in universe, and that this probably has implications related to the semantics of your communications. [18:29] persia: there is a difference between canonical supported and community supported, and a necessary exclusivity in some ways-- it is our team's job to take care of canonical supported pacakges. our name is on the USN, it is in the emails to bugtraq, etc. in some ways, submitting a debdiff for a package in main is a lot like just giving us a VCS link to a fix [18:29] persia: that said, I don't want to appear as exclusive [18:29] Heh. [18:30] I understand the difficulty, and don't want to complicate things :) [18:30] that didn't come out quite right [18:30] I want people involved, but there is very much a difference between a community supported package and a canonical supported, from our point of view [18:30] There are differences between the set of things that is done related to embargoes and USNs and pocket copies. [18:30] I'm not sure that matters though-- there is so much to do in community supported packages that just isn't happening now [18:31] I'm less confident there's a meaningful difference between "main" and "universe" for stuff that isn't embargoed. [18:31] (because any dev can upload it) [18:31] there is -- it's an SRU [18:31] persia: are we talking about stable releases or devel? [18:31] so, when something goes into main, we're responsible for it. [18:31] Don't you do both? [18:31] persia: stable and devel? yes [18:32] persia: but we are directly responsible for main/restricted [18:32] for stable [18:32] in fact, a supported configuration is running an Ubuntu system with -security but without -updates [18:33] Right. I think we havea close to common understanding of stuff. [18:33] I agree there needs to be a distinction for certain folks active in security. [18:33] sure-- I think it is perhaps a matter of perspective, and my language is tainted by my perspective [18:34] I just think there needs to be a distro-wide security team of some sort (which may well be ubuntu-security-sponsors) that is highlighted as a central team, rather than relying on each developer team to grow it's own security folk. [18:34] Mine too :) [18:34] I'm actually not convinced that's the right thing to do. [18:34] I think each developer team needs to know how to handle stable security updates. [18:35] they're much more familiar with the code and how to test [18:35] OK. How do we deal with security for stuff not handled by the restricted set of security developers then? [18:35] I'm not saying we shouldn't have a general security team, but I don't think we should discourage security work by devel teams [18:35] can we convince each team to grow a security representative? Or would we do better to have a central coordnation team that reached out when CVEs were published? [18:36] Just as a semantic note: I consider teams to be massively overlapped, so I'd hope that individual developers might participate in several teams. [18:36] I think each team should at least have a security representative -- perhaps the same person that deals with SRUs. [18:36] kees: I was not trying to discourage anyone, and would hope that people from the dev teams would provide patches for their stuff (with testing) [18:37] jdstrand: right, i was replying persia's "rather than relying on each developer team to grow it's own security folk." [18:37] OK. This could work. In that case, there *should* be a MOTU swat, but each developer team should also havea similar body. [18:37] ah [18:37] since I *do* want devteams to grow security folk [18:38] persia: I think that would be ideal, yes. however, we've had a very hard time growing either type of person. :) [18:38] I don't think we need to continue having a hard time :) [18:38] Just petition the tech board to add a requirement that devteams nominate some -security and -updates contacts. [18:38] the devel release is often much more exciting than a stable release for most people [18:39] persia: how would that be tracked in LP/ [18:39] And that those contacts are expected to participate in discussions with the central -updates and -security teams (so they'd be at this meeting). [18:39] s#/#?# [18:39] kees: Nominees would be added to ubuntu-security-sponsors and fill roles similar to that of motu swat today. [18:40] I'm looking for a way for an outsider to answer the question "who is the security contact for [team]?" when looking at LP. [18:40] persia: so anyone could provide the debdiff (including the devteam) and then the rep from the devteam in ubuntu-security-sponsors could ack it [18:40] ? [18:41] kees: A wiki page? [18:41] jdstrand: And with luck the security rep from the devteam helps in other ways, but yes. [18:41] persia: okay, seems disconnected from LP a bit, but it's the best we've got. [18:41] kees: The other alternative is to have special teams like ubuntu-desktop-security, but I don't think that scales. [18:41] the issue is finding someone that can help with testing. no one likes testing ancient stable releases. :( [18:42] LP needs to get smarter before we have that feature. [18:42] That's why you get the TB to require devteams to nominate someone :) [18:42] yeah, last stable is about as far back as people like to test [18:42] I want to avoid this person from becoming a bottleneck, though, and I worry that might become socially tricky. [18:43] "You never checked with me about this patch!" "You weren't online." etc [18:43] I can imagine an ack on a patch, but waiting on testing [18:43] kees: Could we work around that by a combination of "Ubuntu doesn't have maintainers" and allowing a devteam to nominate several members rather than one if coordination may be an issue? [18:43] kees: I think that should be solved be our sponsorship process [18:44] (it, ACKs, etc in LP) [18:44] I guess my entire opinion is best summarized by "I would love more people participating, but since that number is approaching zero, I see no reason to impose groups/lists/etc" [18:44] Fair. I'm just concerned about the packages that are no longer cared for by MOTU slipping through the cracks. [18:45] kees: I agree with that...once we actually _get_ debdiffs we can start looking how to increase sponsoring, etc. [18:45] wel, to be honest, they already are slipping through the cracks. [18:45] OK, maybe I'm approaching this from the wrong direction then. [18:45] (and feel free to change topic if time is short) [18:45] stefanlsd and jstrand helped a great deal to close the crack with the sync-finder and sync-doer, though [18:46] Perhaps we ought think about "How do we extend the security process to more actively encourage patch submissions from devteams to the security team?" [18:46] persia: that is the question [18:46] but, I mean, the list is huge even after that: http://people.canonical.com/~ubuntu-security/cve/universe.html [18:47] As long as we answer that question in a way that works with Archive Reorg, all my concerns about MOTU SWAT are resolved. [18:47] persia: that is what we tried to do with our recent procedural changes (so it isn't a wholly new process) [18:47] persia: right, I like that. I like _anything_ that'll get more people helping. [18:47] OK. So, I suggest that explicity expecting devteams to actively track at least open CVEs in their packagesets is a place to start. [18:48] Until MOTU's responsibility gets smaller, I'm unsure MOTU SWAT can keep up, but it sets a model that means that as new devteams are formed, they are already participating in the process. [18:48] integration with harvest could be a good idea [18:48] That also skips the requirement for specific nominees, etc. (although if you add a request to report in this meeting, a natural nominee will likely emerge) [18:50] persia: yeah, I do like the idea of solidifying "expecting devteams to actively track at least open CVEs in their packagesets" [18:51] I'm not sure what that will get us, but we'll see [18:51] kees: And would you be willing to add "expecting devteams to report on the progress of such tracking during the weekly security team meeting"? [18:51] persia: sure, I guess that would be good. [18:52] Well, that combination matches my preferred mental model well enough that I'm completely satisfied :) [18:52] persia: where should these suggested idea be presented? TB or DMB? [18:52] I assume TB [18:53] TB: it'S the TB that is responsible for approving devteams. The DMB only approves membership changes in devteams if so delegated. [18:53] * kees nods [18:53] jdstrand: did you have anything else on this, or shall we move to the second of your "two things"? [18:54] persia: I'm pretty much of the same mind as everyone-- more involvement is good. how we get there is rather secondary to me [18:55] persia: I've added this to the TB agenda now: https://wiki.ubuntu.com/TechnicalBoardAgenda [18:55] simply put, I don't have anything else [18:55] kees: Excellent :) [18:55] jdstrand: oh, I thought you had a second item, non-overlapping with persia? [18:56] kees: I do, I was letting go of persia's sleeve is all [18:56] hah, ok [18:56] the other thing is a bit of a clarification on security support in -backports [18:56] specifically bug #411849 [18:56] Launchpad bug 411849 in hardy-backports "Please backport security fix for USN-812-1 in subversion 1.5" [Undecided,In progress] https://launchpad.net/bugs/411849 [18:57] my understanding was that it is up to the backports team to do this type of thing [18:57] I agree 100% [18:58] alright, so, so I guess that is it on that then [18:58] ubuntu-security got dragged into that bug and it seemed at least worth reviewing [18:58] jdstrand: yeah, backports is not our problem in the least, IMO. [18:59] I agree (and responded as such in the bug) [18:59] if anyone feels differently, I'm all ears, but my operating principle has been to ignore -backports totally. [18:59] okay, cool [19:00] anyone have anything else? [19:00] not me [19:00] thanks everyone! [19:01] o [19:01] o/ === Pricey_ is now known as Pricey === fader_ is now known as fader|away