16:42 #startmeeting 16:42 Meeting started Mon Mar 17 16:42:12 2014 UTC. The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 16:42 16:42 Available commands: action commands idea info link nick 16:42 The meeting agenda can be found at: 16:42 [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting 16:42 [TOPIC] Review of any previous action items 16:42 [ACTION] chrisccoulson send oxide and qtwebkit benchmark results to mailing list 16:42 * meetingology chrisccoulson send oxide and qtwebkit benchmark results to mailing list 16:43 that's done 16:43 chrisccoulson: cool. where did that go? I haven't gone through all of my email yet from being off friday 16:44 jdstrand, https://lists.launchpad.net/oxide/msg00003.html 16:44 awesome! 16:44 * jdstrand hugs chrisccoulson :) 16:45 [TOPIC] Weekly stand-up report 16:45 I'll go first 16:45 I have pending updates 16:45 and an embargoed issue 16:46 mdeslaur: you're up 16:46 I'm on triage this week 16:46 I just published a couple of usns, and I have a few more that are at the testing stage 16:47 mdeslaur: (fyi, sb eattie is off today) 16:47 that's about it, I'll be going down the list after that 16:47 tyhicks: you're up 16:47 I submitted v2 of the dbus-daemon patches upstream last friday 16:48 \o/ 16:48 so now I'm looking at kdbus and helping out with apparmor work items this week 16:48 if I can get to it, taking another look at the test-kernel-security.py failures on powerpc would be good, too 16:48 that's it for me 16:49 jjohansen: you're up 16:49 I'm pulling my hair out, err working on apparmor again this week. 16:49 heh :) 16:50 There where some qrt test failures that sarnold reported at the end of the week that we need to finish looking in to. 16:50 jjohansen: that is 2.8.95 related? 16:50 and there are still issues around ipc, with sockets 16:50 jdstrand: yes 16:50 hrm 16:51 do we expect 2.8.95 to land this week? 16:51 (that is for sarnold and jjohansen) 16:52 jdstrand: I think so 16:52 jdstrand: I think so, there were more QRT failures on the nexus 4 than I expected, but it was rough even getting it to run there, so perhaps itshouldn't be a surprise 16:53 hmm 16:53 jdstrand: 2 of the failures are due to things not being supported in the test environment/platform and not being properly detected as such. The others I haven't looked into yet 16:53 tyhicks: didn't you do qrt on the nexus 4? 16:53 I thought it was working 16:53 but might be misremembering 16:53 jdstrand: .. and I think the 2.8.0 apparmor packaging on the nexus 4 fails your test plan in the same ways as the new 2.8.95 apparmor fails it, so I'm hopeful there :) 16:53 jdstrand: I'm pretty sure that I did 16:54 but I'd guess that sarnold is talking about testing 2.8.95 on the nexus 4 16:54 sarnold: I'm interested in hearing more specifics about that 16:54 tyhicks: yes, but just said that 2.8.0 fails similarly 16:54 oh 16:54 sarnold: we can discuss outside of the meeting 16:55 yep 16:55 I think that is it from me, sarnold your up 16:56 I'm on community this week 16:56 also landing apparmor this week 16:56 and I still have juju, schroot, strongswan, glusterfs, and cgmanager MIRs to start and finish. 16:57 so I'm really hoping we can land apparmor today :) 16:58 I think that's it for me, chrisccoulson you're up :) 16:58 this week, i've got mozilla updates 16:58 also planning to land oxide in the archive 16:59 and finish my ever growing list of oxide code reviews :) 16:59 and hopefully get https://code.launchpad.net/~chrisccoulson/oxide/network-callbacks merged, which has turned in to quite a significant chunk of work now 16:59 i think that's me done :) 17:02 chrisccoulson: network-callbacks is the lion's share of the UA overrides work you mentioned in the oxide meeting? 17:03 jdstrand, it is. but it also contains hooks for storage access permissions (well, currently only cookies, but this is going to be extended to local storage, appcache, indexeddb and webdb as well) too 17:03 and it has support for third party cookie blocking 17:03 ack 17:03 [TOPIC] Highlighted packages 17:03 he 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. 17:03 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. 17:03 http://people.canonical.com/~ubuntu-security/cve/pkg/slurm-llnl.html 17:04 http://people.canonical.com/~ubuntu-security/cve/pkg/gksu-polkit.html 17:04 http://people.canonical.com/~ubuntu-security/cve/pkg/lib3ds.html 17:04 http://people.canonical.com/~ubuntu-security/cve/pkg/google-authenticator.html 17:04 http://people.canonical.com/~ubuntu-security/cve/pkg/libdigidoc.html 17:04 [TOPIC] Miscellaneous and Questions 17:04 I have some questions related to our major deliverables for 14.04 17:06 based on the oxide standup today, oxide should be landing in the archive this week. webbrowser-app will follow after that and there is still quite a bit to do, but it is still believed that we will deliver oxide (and other teams webbrowser-app, UbuntuWebView and webapp-container) 17:06 that is awesome 17:07 apparmor 2.8.95 seems like it is close and sounds like it should land this week. We really need to make sure it does to pave the way for the next update 17:07 jjohansen: you mentioned that there is a bug related to ipc, with sockets. is that the remaining known bug? 17:07 the as in singular? no 17:08 its one of the remaining problems 17:08 v5 behavior (old kernel should be fine) 17:08 jjohansen: assuming 2.8.95 was fixed and landed in the archive, what is left for landing ipc? 17:08 new kernel has issues 17:09 jdstrand: there needs to be some revisions around ptrace, signals, and other policy 17:10 there needs to be some fixes to the network code 17:10 I think its doable this week 17:10 jjohansen: the network code is doable this week? 17:11 I think so 17:11 is the sockets ipc bug for this week? 17:11 yes I plan to fix that this week 17:12 jjohansen: 'new kernel has issues' - is that the network code, v5 behavior, or something else? 17:14 * jdstrand meant to add to his items this week to comment on the ipc policy 17:14 jdstrand: there are a few things, network code, there is a replacement issue around compound labels, there needs to be a versioning behavior change around the xtrans table in the parser that is fed into the kernel 17:15 ok. so, I'm just trying to create a list so I better understand where we are 17:15 jdstrand: lets put it this way, its good enough to pass the current regression tests, but issues are known (which just means we need to add more tests) 17:16 cause I'm starting to get nervous about ipc landing 17:16 * jjohansen too 17:16 oh and I need to do testing of it as a backport on precise and make sure its working right there 17:17 jjohansen: is the versioning change for this week? 17:17 some that should be working but I haven't tested yet with the latest kernel 17:17 jdstrand: yes it is needed 17:18 jjohansen: is the replacement issue around compound labels the socket issue or something else? 17:18 jdstrand: it is something else 17:18 is the replacement issue for this week? 17:18 jdstrand: I have a patch to fix it, but applying that patch causes the kernel to die for a different but related reason so I need to fix that 17:19 ok 17:19 jdstrand: the replacement issue can be put off, as things can work with out it. 17:19 jjohansen: were you able to upload test packages to the ppa based of sarnold's 2.8.95 from last week? 17:19 compound labels just don't get updated correctly after replacement 17:19 jdstrand: I have not, yet. I can do that today 17:20 jjohansen: re ppa> well, only if it helps people. perhaps wait until you have the final packages we plan to upload since they may land tomorrow 17:20 personally, I won't be able to install them today 17:21 but could tomorrow 17:21 okay 17:21 sb eattie is off today, so delaying to at least tomorrow makes sense to me 17:22 jjohansen: 'there needs to be some revisions around ptrace, signals, and other policy' - are you talking about policy language? 17:23 yes, its minor 17:23 the actual work won't take long 17:24 ok, so known issues. iirc, no one really responded to the policy language changes in the thread 17:24 of course, we worked through a lot of that before 17:24 do we feel like the policy language is in good shape (other than this minor issue)? 17:25 jjohansen: ^ 17:26 I don't even know that I'd call it an issue, as looking for clarification, so we are happy with a final syntax 17:26 I see-- so, "yes, the final syntax is very close" 17:26 something that needs input from more than just me 17:27 yes we are close 17:27 we are talking about sugar, not functionality 17:27 right. perhaps respond to the list saying the lack of response is blocking it landing? 17:27 can do 17:28 jjohansen: does this look about right> http://paste.ubuntu.com/7109323/ 17:28 oh, I forgot to ask about testing 17:28 jjohansen: do you know where we stand on coverage for these new features? 17:29 ptrace is pretty good, signal less so 17:30 jjohansen: I know that is a lot in sb eattie's domain, but curious if you knew 17:30 ok' 17:31 ok 17:31 that said, signal is not as bad as it may seem. It is actually getting tested in several of the other regression tests 17:31 so, I think I captured all that. I'd like outside of this meeting to discuss a plan to land this, with assigning people to do different things 17:32 tyhicks: should we push the v2 dbus patches once upstream ACKs them? 17:32 tyhicks: push to trusty that is 17:32 jdstrand: that's something I've been wondering 17:32 jdstrand: I think it would be a good idea 17:32 trusty is 5 years LTS 17:33 it seems like it would be 17:33 jdstrand: I feel confident in them and have tested them a considerable amount 17:33 I think so 17:33 ok, we need to come up with a plan for all this stuff 17:33 Does anyone have any other questions or items to discuss? 17:33 yeah I think that its a good idea, to push them in 17:34 all except for the last 2 patches in the series are a drop-in replacement 17:34 we wouldn't push those last 2 patches, becaues they depend on a dbus-daemon method that isn't in trusty's dbus-daemon 17:34 tyhicks: what's special about the last to? 17:34 oh 17:34 mdeslaur: it is a new method to get a peer's security credentials 17:35 ok 17:35 we would live with our current distro-patched org.freedesktop.DBus.GetConnectionAppArmorSecurityContext() method 17:36 that's no big deal 17:38 mdeslaur, tyhicks, jjohansen, sarnold, chrisccoulson: thanks! 17:38 #endmeeting