| === edson is now known as ecanto | ||
| === mhall119|work is now known as mhall119|SCaLE8x | ||
| Speedy2 | www.search2.net | 07:43 |
|---|---|---|
| elky | Is that a typo or are you spamming us? | 07:44 |
| vish | elky: spam | 07:44 |
| elky | it does appear that now | 07:44 |
| vish | elky: i'v just reported it to the ops, its been happening in several channels | 07:45 |
| elky | Yeah, i noted. I was going to see if they were a human who could be reasoned with. | 07:46 |
| dholbach | good morning | 07:49 |
| === 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_ | ||
| mdeslaur | jdstrand, kees: meeting? | 18:00 |
| kees | mdeslaur: ah, yes. it's that time, isn't it? | 18:01 |
| kees | jdstrand: ready? | 18:01 |
| mdeslaur | kees: my calendar thinks it is :) | 18:01 |
| jdstrand | o/ | 18:01 |
| kees | :) | 18:01 |
| jdstrand | yes | 18:01 |
| kees | okidoky | 18:01 |
| kees | this week, OOo publication, and then going to check for any low-hanging fruit | 18:01 |
| persia | If there's time in the agenda, can I grumble a bit about community integration at the end? | 18:02 |
| kees | I'd like to finish some of the qrt stuff I had on my plate (like the additional RNG tests) | 18:02 |
| kees | persia: totally | 18:02 |
| mdeslaur | persia: yes | 18:02 |
| persia | THanks. | 18:02 |
| kees | probably going to start another kernel update cycle soon too | 18:02 |
| kees | looks like we made feature freeze pretty well. | 18:03 |
| kees | that's it from me. mdeslaur, you're up. | 18:03 |
| mdeslaur | I just published pidgin updates. I plan on attacking the new squid issue, and the ffmpeg updates next. | 18:03 |
| mdeslaur | besides that, I'm on community, so have been going down the sponsoring list | 18:04 |
| mdeslaur | that's pretty much it | 18:04 |
| * jjohansen fades in late | 18:04 | |
| jdstrand | so I guess I'm up next | 18:04 |
| jdstrand | I am triager this week | 18:05 |
| jdstrand | 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 |
| kees | oooh, I was just thinking about that today in the shower -- I wanted to see if I could build an OOo test | 18:06 |
| jdstrand | kees: exactly (though for me it was firefox) | 18:06 |
| kees | I worry about use having different resolutions, languages, installed applications in our VMs, though. | 18:07 |
| mdeslaur | wouldn't Mago be more appropriate for that? | 18:07 |
| jdstrand | I looked at it a it on my own last week, but it was not... | 18:07 |
| jdstrand | obvious... | 18:07 |
| kees | yeah | 18:07 |
| jdstrand | how to use it in that capacity | 18:07 |
| jdstrand | soren gave that presentation at the sprint and seems to think it shouldn't be a problem-- so I'm hopeful :) | 18:07 |
| persia | Mago requires accessibility support. kvm-autotest requires reliable display parameters (which kvm can provide). | 18:08 |
| jdstrand | mdeslaur: I looked at Mago a bit, but didn't find documentation on how to really get into it | 18:08 |
| jdstrand | plus what persia mentioned | 18:08 |
| * robbiew sneaks in the back door :/ | 18:08 | |
| mdeslaur | I'm just kind of afraid with kvm-autotest that it will be hard to always have a 100% reproducable environment | 18:09 |
| jdstrand | I plan to see what is next on the 'what CVE to fix next' list, and do that | 18:09 |
| === noy_ is now known as noy | ||
| jdstrand | mdeslaur: I think we can with snapshots, etc | 18:09 |
| jdstrand | mdeslaur: anyway, I'm investigating right now, not integrating :) | 18:10 |
| mdeslaur | ok, fair enough :) | 18:10 |
| mdeslaur | jdstrand: don't forget, I run my VMs at 1920x1080 | 18:10 |
| jdstrand | mdeslaur: if you have some good resources for mago, I'd like them too | 18:10 |
| kees | jdstrand: if you start getting somewhere with it, let me know and I can "reproduce locally" :) | 18:10 |
| kees | mdeslaur: seriously? | 18:10 |
| mdeslaur | kees: no | 18:10 |
| kees | hah | 18:10 |
| jdstrand | 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 |
| mdeslaur | oh, okay | 18:11 |
| jdstrand | but anyway, we'll see-- I just thought there might be something there, and soren is willing to walk me through it | 18:11 |
| * kees hopes to re-use the libvirt-configured VMs | 18:12 | |
| mdeslaur | jdstrand: don't forget to bug soren as much as possible while he's still on the payroll :) | 18:12 |
| jdstrand | kees: me too... we'll see | 18:12 |
| jdstrand | 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 |
| jdstrand | anyhoo | 18:13 |
| jdstrand | if I have time, I'd like to see if I can clean up the apparmor abstractions, esp for firefox/evince | 18:14 |
| jdstrand | 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 |
| jdstrand | persia: why don't you go ahead? | 18:14 |
| persia | Probably :) | 18:15 |
| persia | 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 |
| persia | Summarised, the TB and DMB have approved a proposal that significantly limits the scope of "MOTU". | 18:15 |
| persia | 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:16 |
| kees | sounds good to me. | 18:19 |
| jdstrand | 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 |
| jdstrand | err | 18:19 |
| jdstrand | s/is/isn't/ | 18:19 |
| * persia much prefers "not supported by Canonical" to "not officially supported", but yes, this needs thought. | 18:19 | |
| jdstrand | fair enough | 18:19 |
| kees | we'll have the help of the Supported: tag in the packages files | 18:19 |
| persia | 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 |
| jdstrand | yeah, that defines our responsibilities | 18:20 |
| mdeslaur | persia: Is there anything you see that would need changing in our current process? | 18:20 |
| * kees mumbles something about syncSource ACLs in LP | 18:21 | |
| jdstrand | 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 |
| persia | 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 |
| kees | no amount of our process can reduce the bottleneck that is LP's lack of ACLs, though. | 18:21 |
| persia | 1) declare an inclusive security group with responsibility for everything (although some members may concentrate in certain areas). | 18:22 |
| kees | but, outside of that, I'd agree: we've tuned the process to eliminate human bottlenecks as much as possible | 18:22 |
| persia | 2) encourage all members of that group to actively review and sponsor stuff. | 18:22 |
| jdstrand | 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 |
| persia | 3) have a restricted set that is responsible for pocket copies and USN releases. | 18:22 |
| jdstrand | (I'd love to see the volume of community supported patches be a real problem for us) | 18:22 |
| persia | I think that's mostly a matter of making sure submitters feel entitled as part of the team. | 18:23 |
| mdeslaur | persia: this is the team that has responsibility of reviewing everything: https://launchpad.net/~ubuntu-security-sponsors | 18:23 |
| persia | 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 |
| kees | 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:23 |
| persia | kees: I think you're right, and that it's just a matter of semantics and communication. | 18:24 |
| jdstrand | well, the ubuntu-security team itself is how it is due to ACLs and requiring the possibility for embargoed issues. | 18:24 |
| jdstrand | it could I guess be a subteam in this whole thing... | 18:24 |
| jdstrand | kees: your understanding is correct on '1' | 18:25 |
| kees | 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 |
| jdstrand | 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:25 |
| jdstrand | however, we are fully integrated into the MOTU pages now-- from dholbach's reports, to Sponsoring pages to how you can help | 18:26 |
| persia | 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 |
| jdstrand | the only thing that wasn't done was an email to ubuntu-motu@ and ubuntu-devel@ | 18:26 |
| mdeslaur | 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 |
| persia | 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:27 |
| jdstrand | 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 |
| jdstrand | persia: that said, I don't want to appear as exclusive | 18:29 |
| persia | Heh. | 18:29 |
| persia | I understand the difficulty, and don't want to complicate things :) | 18:30 |
| jdstrand | that didn't come out quite right | 18:30 |
| jdstrand | 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 |
| persia | There are differences between the set of things that is done related to embargoes and USNs and pocket copies. | 18:30 |
| jdstrand | I'm not sure that matters though-- there is so much to do in community supported packages that just isn't happening now | 18:30 |
| persia | I'm less confident there's a meaningful difference between "main" and "universe" for stuff that isn't embargoed. | 18:31 |
| persia | (because any dev can upload it) | 18:31 |
| kees | there is -- it's an SRU | 18:31 |
| jdstrand | persia: are we talking about stable releases or devel? | 18:31 |
| kees | so, when something goes into main, we're responsible for it. | 18:31 |
| persia | Don't you do both? | 18:31 |
| jdstrand | persia: stable and devel? yes | 18:31 |
| jdstrand | persia: but we are directly responsible for main/restricted | 18:32 |
| jdstrand | for stable | 18:32 |
| jdstrand | in fact, a supported configuration is running an Ubuntu system with -security but without -updates | 18:32 |
| persia | Right. I think we havea close to common understanding of stuff. | 18:33 |
| persia | I agree there needs to be a distinction for certain folks active in security. | 18:33 |
| jdstrand | sure-- I think it is perhaps a matter of perspective, and my language is tainted by my perspective | 18:33 |
| persia | 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 |
| persia | Mine too :) | 18:34 |
| kees | I'm actually not convinced that's the right thing to do. | 18:34 |
| kees | I think each developer team needs to know how to handle stable security updates. | 18:34 |
| kees | they're much more familiar with the code and how to test | 18:35 |
| persia | OK. How do we deal with security for stuff not handled by the restricted set of security developers then? | 18:35 |
| kees | 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 |
| persia | 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:35 |
| persia | 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 |
| kees | I think each team should at least have a security representative -- perhaps the same person that deals with SRUs. | 18:36 |
| jdstrand | 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:36 |
| kees | jdstrand: right, i was replying persia's "rather than relying on each developer team to grow it's own security folk." | 18:37 |
| persia | OK. This could work. In that case, there *should* be a MOTU swat, but each developer team should also havea similar body. | 18:37 |
| jdstrand | ah | 18:37 |
| kees | since I *do* want devteams to grow security folk | 18:37 |
| kees | persia: I think that would be ideal, yes. however, we've had a very hard time growing either type of person. :) | 18:38 |
| persia | I don't think we need to continue having a hard time :) | 18:38 |
| persia | Just petition the tech board to add a requirement that devteams nominate some -security and -updates contacts. | 18:38 |
| jdstrand | the devel release is often much more exciting than a stable release for most people | 18:38 |
| kees | persia: how would that be tracked in LP/ | 18:39 |
| persia | 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 |
| kees | s#/#?# | 18:39 |
| persia | kees: Nominees would be added to ubuntu-security-sponsors and fill roles similar to that of motu swat today. | 18:39 |
| kees | 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 |
| jdstrand | 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 |
| jdstrand | ? | 18:40 |
| persia | kees: A wiki page? | 18:41 |
| persia | jdstrand: And with luck the security rep from the devteam helps in other ways, but yes. | 18:41 |
| kees | persia: okay, seems disconnected from LP a bit, but it's the best we've got. | 18:41 |
| persia | kees: The other alternative is to have special teams like ubuntu-desktop-security, but I don't think that scales. | 18:41 |
| kees | the issue is finding someone that can help with testing. no one likes testing ancient stable releases. :( | 18:41 |
| persia | LP needs to get smarter before we have that feature. | 18:42 |
| persia | That's why you get the TB to require devteams to nominate someone :) | 18:42 |
| jdstrand | yeah, last stable is about as far back as people like to test | 18:42 |
| kees | I want to avoid this person from becoming a bottleneck, though, and I worry that might become socially tricky. | 18:42 |
| kees | "You never checked with me about this patch!" "You weren't online." etc | 18:43 |
| jdstrand | I can imagine an ack on a patch, but waiting on testing | 18:43 |
| persia | 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 |
| jdstrand | kees: I think that should be solved be our sponsorship process | 18:43 |
| jdstrand | (it, ACKs, etc in LP) | 18:44 |
| kees | 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 |
| persia | Fair. I'm just concerned about the packages that are no longer cared for by MOTU slipping through the cracks. | 18:44 |
| mdeslaur | kees: I agree with that...once we actually _get_ debdiffs we can start looking how to increase sponsoring, etc. | 18:45 |
| kees | wel, to be honest, they already are slipping through the cracks. | 18:45 |
| persia | OK, maybe I'm approaching this from the wrong direction then. | 18:45 |
| persia | (and feel free to change topic if time is short) | 18:45 |
| kees | stefanlsd and jstrand helped a great deal to close the crack with the sync-finder and sync-doer, though | 18:45 |
| persia | 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 |
| jdstrand | persia: that is the question | 18:46 |
| kees | but, I mean, the list is huge even after that: http://people.canonical.com/~ubuntu-security/cve/universe.html | 18:46 |
| persia | 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 |
| jdstrand | persia: that is what we tried to do with our recent procedural changes (so it isn't a wholly new process) | 18:47 |
| kees | persia: right, I like that. I like _anything_ that'll get more people helping. | 18:47 |
| persia | OK. So, I suggest that explicity expecting devteams to actively track at least open CVEs in their packagesets is a place to start. | 18:47 |
| persia | 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 |
| james_w | integration with harvest could be a good idea | 18:48 |
| persia | 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:48 |
| kees | persia: yeah, I do like the idea of solidifying "expecting devteams to actively track at least open CVEs in their packagesets" | 18:50 |
| jdstrand | I'm not sure what that will get us, but we'll see | 18:51 |
| persia | 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 |
| kees | persia: sure, I guess that would be good. | 18:51 |
| persia | Well, that combination matches my preferred mental model well enough that I'm completely satisfied :) | 18:52 |
| kees | persia: where should these suggested idea be presented? TB or DMB? | 18:52 |
| kees | I assume TB | 18:52 |
| persia | 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 | |
| persia | jdstrand: did you have anything else on this, or shall we move to the second of your "two things"? | 18:53 |
| jdstrand | 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:54 |
| kees | persia: I've added this to the TB agenda now: https://wiki.ubuntu.com/TechnicalBoardAgenda | 18:55 |
| jdstrand | simply put, I don't have anything else | 18:55 |
| persia | kees: Excellent :) | 18:55 |
| kees | jdstrand: oh, I thought you had a second item, non-overlapping with persia? | 18:55 |
| jdstrand | kees: I do, I was letting go of persia's sleeve is all | 18:56 |
| kees | hah, ok | 18:56 |
| jdstrand | the other thing is a bit of a clarification on security support in -backports | 18:56 |
| jdstrand | specifically bug #411849 | 18:56 |
| ubottu | 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:56 |
| jdstrand | my understanding was that it is up to the backports team to do this type of thing | 18:57 |
| kees | I agree 100% | 18:57 |
| jdstrand | alright, so, so I guess that is it on that then | 18:58 |
| jdstrand | ubuntu-security got dragged into that bug and it seemed at least worth reviewing | 18:58 |
| kees | jdstrand: yeah, backports is not our problem in the least, IMO. | 18:58 |
| jdstrand | I agree (and responded as such in the bug) | 18:59 |
| kees | if anyone feels differently, I'm all ears, but my operating principle has been to ignore -backports totally. | 18:59 |
| kees | okay, cool | 18:59 |
| kees | anyone have anything else? | 19:00 |
| mdeslaur | not me | 19:00 |
| kees | thanks everyone! | 19:00 |
| jdstrand | o | 19:01 |
| jdstrand | o/ | 19:01 |
| === Pricey_ is now known as Pricey | ||
| === fader_ is now known as fader|away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!