[18:02] <mdeslaur> kees, jdstrand, sbeattie: meeting?
[18:03] <kees> mdeslaur: \o
[18:05] <sbeattie> mdeslaur: sure.
[18:08] <jdstrand> o/
[18:09]  * kees starts
[18:10] <kees> did a couple security fake-syncs.
[18:10] <kees> couchdb exploded due to autoconf-hate, so I've skipped it for now on jaunty
[18:10] <kees> been trying to keep up with kernel CVE triage; there have been a lot lately
[18:11] <kees> this week I'll likely spend time rebasing yama and nx-emut o natty's kernel
[18:11] <kees> s/ut o/u to/
[18:11] <kees> I've got 2 things unembargoed this week as well
[18:12] <kees> and I'll be poking at maverick final testing. might even update the colo to RC
[18:12] <kees> that's it from me
[18:12] <mdeslaur> ok, my turn
[18:13] <mdeslaur> So I'm trying to figure out a way of testing the lvm2 cluster daemon
[18:13] <mdeslaur> so I can test my lvm2 updates
[18:13] <mdeslaur> and am on triage
[18:13] <mdeslaur> I'll pick something from the list if I have time
[18:14] <mdeslaur> That's it from me
[18:14]  * sbeattie facepalms as he clearly can't read topic messages and thought he was on triage this week.
[18:15] <mdeslaur> lol
[18:16] <sbeattie> anyway, last week I spent some time on apparmor build issues and coping with copious gpg key changes.
[18:16] <sbeattie> I'm hoping to push out some patches to the apparmor list for review later today.
[18:17] <sbeattie> since I'm *not* triaging, I'll try to pick up some open issues this week.
[18:17] <sbeattie> I think that's it for me, jdstrand?
[18:19] <jdstrand> I'm on community
[18:19] <jdstrand> last week I did quite a bit of install auditing for maverick, and will continue that this week
[18:19] <jdstrand> the rng tests are still churning away
[18:20] <jdstrand> I got back into my libvirt update and am continuing to work on it
[18:20] <jdstrand> there is some upstream feedback that I need to tend to on libvirt not related to that update
[18:20] <jdstrand> I plan to start looking at moodle once libvirt is out the door
[18:20] <kees> oh, that reminds me, I'm happy with the dieharder results. it's got a few sensitive tests, but other than that, it looks good.
[18:20] <jdstrand> I'm not sure that will be this week or next, but that is the plan
[18:21] <jdstrand> kees: were you able to update the qrt test to be less sensitive? I saw some commits go by, but didn't look at them closely
[18:22] <kees> jdstrand: basically it came down to two specific tests complaining, so I set them to XFAIL. I didn't create anything more complex, as that seemed like overkill.
[18:22] <jdstrand> kees: sounds fine
[18:23] <jdstrand> wrt the rng tests, I'm doing collision testing and the kernel passed for both /dev/random and /dev/urandom
[18:23] <jdstrand> it is in the gnupg tests now
[18:23] <kees> excellent
[18:24] <jdstrand> I have one item for the end of the meeting, and stefanlsd may also have something (or may not, it is up to him)
[18:24] <jdstrand> that is it from me (until later)
[18:25] <jdstrand> we could mention that we've all done our gpg migration
[18:25] <kees> indeed!
[18:25] <jdstrand> https://wiki.ubuntu.com/SecurityTeam/GPGMigration
[18:26] <jdstrand> for those listening at home, we've tested various applications and how they deal with the new secure defaults from upstream gnupg
[18:26] <jdstrand> for lucid and maverick
[18:27] <jdstrand> we determined it was ok to migrate, and have instructions on what to do to migrate keys in that wiki link
[18:27] <jdstrand> (the wiki has the results of the investigations)
[18:27]  * jdstrand is really done, until the end
[18:28] <stefanlsd> I wanted to speak about community uploaded rights to -security for unseeded, but wanted to chat to a few more people, so i'll postpone till i have more info.
[18:29] <kees> sbeattie: oh, btw, can you update your reviews of mutt and gmail to use the review template?
[18:29] <sbeattie> kees: sure thing.
[18:30] <kees> jdstrand: the stuff you added about removing your old key...
[18:30] <kees> jdstrand: why not just specify a numerical id instead of email?
[18:30] <kees> e.g. debsign can use an id
[18:31] <jdstrand> kees: that is indeed the recommended and first method under the NOTE
[18:32] <kees> jdstrand: right, I guess I mean, why should the other method ever be used?
[18:32] <jdstrand> kees: they only (potential) problem with that is if you have several applications to change. you might want to instead change the order of your secret keyring so they all just get the default
[18:33] <jdstrand> kees: ie, what you suggest is for every application. the 2nd method will affect all applications but is a little trickier
[18:33] <kees> jdstrand: okidoky. I found one place in umt where it was using email instead of id, and fixed that. otherwise, everything else I found uses id
[18:33] <kees> right
[18:33] <jdstrand> the third is weird, and could be removed, but is listed for completeness
[18:34] <kees> okidoky. sounds fine; was just curious how it even came up as a need. :) sorry to derail!
[18:34] <jdstrand> I had to change quite a few things, but won't list them
[18:35] <kees> I changed it in 3 places. .devscripts .ubuntu-security-tools.conf .muttrc
[18:35] <jdstrand> kees: it came up because I kept finding stuff and wanted it to be changed in one spot rather than many
[18:35]  * kees nods
[18:35] <jdstrand> kees: it was rather evolutionary
[18:35] <kees> 4, .gnupg/gpg.conf
[18:35] <kees> anyway... you had another topic?
[18:35] <jdstrand> yes, it was for what to include in the lucid apparmor sru
[18:36] <jdstrand> I plan to perform the sru, but wanted to coordinate with jj-afk and sbeattie
[18:36] <jdstrand> jj-afk is still out, so maybe we'll discuss it in #ubuntu-hardened when he is online
[18:37] <jdstrand> (he mentioned he might pop in for the discussion)
[18:37] <sbeattie> okay.
[18:38] <jdstrand> so, that is it from me
[18:38] <kees> will we SRU 2.5.1 final to maverick first?
[18:40] <jdstrand> kees: that is part of the discuss I think
[18:40] <jdstrand> discussion
[18:40] <jdstrand> right now, we know we want 2.5.1, but there are also some attractive testsuite fixes in 2.5.2
[18:41] <jdstrand> maverick has most of 2.5.1 anyway, so... there is a lot to talk about :)
[18:41] <kees> heh
[18:42] <kees> well, getting lucid onto 2.5.1 will fix the kernel instabilities too, iirc.
[18:42]  * sbeattie was hoping someone would ack the rest of the 2.5 testsuite nominations he made. :-)
[18:42] <jdstrand> kees: but iiuc, you want to make sure that lucid isn't ahead of maverick. it won't be-- we will do a maverick SRU first, then lucid, depending on what we want
[18:43] <kees> cool
[18:43] <jdstrand> kees: actually, lucid should be solid now with just the kernel updates
[18:43] <kees> jdstrand: did the kernel updates actually make it into lucid?
[18:43] <jdstrand> kees: but the userspace will still generate some invalid cache entries, but the kernel dtrt
[18:43] <kees> bug 581525 seems to indicate lucid's kernel updates never happened.
[18:44] <jdstrand> kees: that is a good question. I thought so... we need to follow up with jj-afk
[18:44] <jdstrand> oh, indeed
[18:44] <jdstrand> hrm
[18:44] <kees> that's why I was hoping to get the lucid SRU sooner rather than later; that problem has been languishing
[18:44] <jdstrand> well, we need that in lucid regardless. the apparmor userspace would help avoid it, but we really want the kernel side
[18:45] <kees> sure, yeah
[18:45] <kees> okay, anyone have anything else for the security team?
[18:45] <jdstrand> kees: I was not suggesting 2.5.2 for lucid. I was wanting to identify what we want from 2.5.2 if anything, pull it in and then push
[18:45] <jdstrand> sorry if I was unclear
[18:46] <jdstrand> I would like to see the sru done by the end of the month
[18:46] <kees> cool
[18:49] <jdstrand> shall we call it a meeting?
[19:01] <kees> yawp, all done. thanks everyone!
[19:09] <jdstrand> thanks kees! :)