[18:10] <mdeslaur> \o
[18:10] <jdstrand> hi!
[18:11] <tyhicks> hello
[18:11] <jdstrand> wasn't setup yet to use the
[18:11] <jdstrand> The meeting agenda can be found at:
[18:11] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:11] <jdstrand> [TOPIC] Announcements
[18:11] <jdstrand> Chad Miller (chad) provided updates for lucid-quantal for chromium-browser (LP: #1099075)
[18:12] <jdstrand> there is still some work to do for armhf to compile, but i386 and amd64 for lucid-raring are now caught up with upstream :)
[18:12] <jdstrand> [TOPIC] Weekly stand-up report
[18:12] <jdstrand> I'll go first
[18:13] <jdstrand> I'm on triage this week
[18:13] <jdstrand> there is a firefox regression fix that is going out this week
[18:13] <jdstrand> I'm working on an embargoed issue
[18:14] <jdstrand> I've got another embargoed issue I'm working on
[18:15] <jdstrand> if I have time, I might look at the lxc mir this week
[18:15] <jdstrand> mdeslaur: you're up
[18:15] <mdeslaur> I'm on community this week
[18:16] <mdeslaur> I have a couple of pending updates to try and figure out how to test
[18:16] <mdeslaur> (jquery and xserver-xorg-video-qxl)
[18:16] <mdeslaur> and will continue going down the CVE list
[18:16] <mdeslaur> that's pretty much it
[18:16] <jdstrand> mdeslaur: xserver-xorg-video-qxl - ah, that is for spice, right?
[18:16] <mdeslaur> yeah, it's the spice xorg driver
[18:17] <mdeslaur> sbeattie: you're up
[18:17] <jdstrand> I wonder if that would help us with our unity 3d stuff
[18:17] <mdeslaur> jdstrand: no
[18:17] <jdstrand> hmm
[18:17] <jdstrand> someone else said it might
[18:17] <mdeslaur> eventually, I believe they are planning on writing a 3d enabled driver
[18:17] <mdeslaur> but, not currently
[18:18] <jdstrand> plus, looking at the spice server MIR last week, I thought it plausible since spice is supposed to use the best 'hardware'
[18:18] <jdstrand> ie, maybe the guest, maybe the host, but whatever. you know more than I at this point
[18:19] <mdeslaur> it.s more efficient than vnc, but it's not 3d
[18:19] <jdstrand> k
[18:19] <jdstrand> sbeattie: sorry, please go ahead
[18:19] <sbeattie> no worries
[18:20] <sbeattie> I'm working on apparmor this week
[18:20] <sbeattie> focusing on my blueprint work items
[18:20] <sbeattie> I also need to finish up my objectives rejiggering
[18:21] <sbeattie> that's pretty much it for me.
[18:21] <sbeattie> tyhicks: poke
[18:21] <tyhicks> My week looks similar to last week
[18:21] <tyhicks> Embargoed issue, AppArmor policy kernel interface, need to finish testing some changes to the AppArmor D-Bus mediation patches that I made last week and upload the new dbus package to dbus-dev PPA
[18:21] <tyhicks> that's it for me
[18:21] <tyhicks> jjohansen: you're up
[18:22] <jjohansen> I am plugging away on apparmor work items
[18:22] <jjohansen> instead of working on env var filtering, we have switched priorities a little bit I am going to be working on socket labeling so we can have get_peercon working and fix that issue in the dbus patches
[18:22] <jjohansen> oh and I suppose I need to finish up rebasing the compat patches on top of the base labeling/stacking patches today. So I can push an alpha2 kernel into the ppa and give sarnold something more to review
[18:22] <tyhicks> oh nice
[18:24] <jjohansen> thats it from /me sarnold
[18:25] <sarnold> I'm going to be working on workitems and objectives this week
[18:25] <sarnold> vde2 is waiting a main inclusion request audit, it'd be fun to work on that too, we'll see how jdstrand's teaching-time works out :)
[18:26] <jjohansen> sarnold will be reviewing patches this week too :)
[18:26] <sarnold> uh oh :)
[18:26] <sarnold> apparently' I'm also reviewing patches this week :)
[18:26] <sbeattie> hehe
[18:26] <sarnold> jdstrand: back to you :)
[18:27] <jdstrand> yes, that patch review should take priority :)
[18:27] <jdstrand> (unless asked otherwise)
[18:27] <jdstrand> [TOPIC] Highlighted packages
[18:27] <jdstrand> 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:27] <jdstrand> 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:27] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/firebird2.5.html
[18:28] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/sleuthkit.html
[18:28] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/phpldapadmin.html
[18:28] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/nusoap.html
[18:28] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libsocialweb.html
[18:29] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:29] <jdstrand> Does anyone have any other questions or items to discuss?
[18:32] <jdstrand> #endmeeting
[18:32] <jdstrand> mdeslaur, sbeattie, tyhicks, jjohansen, sarnold: thanks!
[18:32] <tyhicks> thanks
[18:33] <mdeslaur> thanks jdstrand!
[18:33] <sarnold> thanks jdstrand :)
[18:33] <sbeattie> jdstrand: thanks!
[18:33] <jjohansen> thanks jdstrand
[20:53] <cjwatson> kees,mdz,soren,stgraber: TB meeting in <10?
[20:54] <stgraber> yep, I'll be there
[20:54]  * pitti waves hello
[20:57] <smoser> o/
[20:59] <cjwatson> ah, soren sent apologies
[20:59]  * cjwatson does last-minute listadmin
[21:00] <cjwatson> #startmeeting
[21:00] <meetingology> Meeting started Mon Feb  4 21:00:05 2013 UTC.  The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[21:00] <meetingology> 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
[21:00] <stgraber> yeah, he then forwarded the e-mail with the right address
[21:00] <cjwatson> Agenda: https://wiki.ubuntu.com/TechnicalBoardAgenda
[21:00] <cjwatson> Who's here?
[21:00] <kees> \o
[21:00] <stgraber> o/
[21:00] <smoser> o/
[21:00] <pitti> me too
[21:00]  * smoser is standing in for roaksoax
[21:01] <cjwatson> Thanks.  Will just wait a minute for any latecomers ...
[21:01] <pitti> I met mdz at FOSDEM yesterday, he's presumably still travelling
[21:01] <cjwatson> Ah, yes, that would make sense
[21:02] <cjwatson> #topic Action review
[21:02] <cjwatson> None that I can see from the last minutes
[21:02] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-January/001007.html
[21:02] <cjwatson> #topic MAAS SRU
[21:02] <cjwatson> I followed up by mail a few minutes ago
[21:02] <pitti> FWIW, I found slangasek's reply quite on-the-spot
[21:03] <cjwatson> Me too.  I understand that Steve's recommendations are already being implemented?
[21:03] <cjwatson> (In fact, perhaps we should record the general principles he outlined somewhere more permanent)
[21:03] <smoser> cjwatson, hm... could you forward me your response? archive is not udpated, an di'm not subscribed.
[21:03] <pitti> I agree with bundling newer versions and new packages into the new maas
[21:03]  * kees nods
[21:03] <cjwatson> smoser: It wasn't anything interesting, just concurrence with Steve and otherwise general approval
[21:03] <smoser> yeah, we're perfectly fine to package the bits inside maas.
[21:03] <pitti> the three django fixes should be properly SRUed, though (at least at first look)
[21:04] <smoser> pitti, we're open to that.
[21:06] <cjwatson> I notice that ScottK has rejected bug 1081391 and bug 1081388 from the SRU queue
[21:06] <smoser> ScottK raised concern with some of the django changes, suggesting that furthre review (done here) was necessary. so surely he'd be OK  with that.
[21:06] <stgraber> I'm also happy with the proposal with slangasek's proposed changes. Personally I'd tend to prefer having yui3 and python-tx-tftp as new sources rather than bundled in, but I'm not an SRU team member and I can live with those sources being bundled.
[21:07] <stgraber> (I have a vague interest in that new tftp module for python which I may want to use for some projects I'm involved with, and having it in the archive for 12.04 would be convenient. I don't care much about yui3 though.)
[21:07] <cjwatson> I find it difficult to disagree with his review on the face of it.  Is it possible to work around the django problems in maas?
[21:07] <pitti> bundling them exposes them less to other "unintended"/unsupported usage, though
[21:07] <cjwatson> (And it is *definitely* true that the test cases in those bugs were incomplete.)
[21:08] <cjwatson> At the very least they'd need much more regression testing.
[21:08] <stgraber> pitti: right, the main advantage of just bundling them is that they will be able to push newer features or API changes to those in future SRUs. Which we wouldn't allow if those were individual sources.
[21:08] <stgraber> pitti: but if it's not likely to happen with those packages (and it doesn't appear it's), I'd prefer to have separate sources.
[21:09] <smoser> stgraber, i think i personally prefer slangasek's suggestion of bundling them in.
[21:09] <cjwatson> I'm not sure I know enough about django to be able to offer a confident review.  It would be nice if somebody non-maas-related who knew django well could investigate.
[21:09] <pitti> stgraber: I'd rather minimize the exposure of new packages, but I don't have a solid objection against introducing them as NEW ones, so I'm fine with letting the server team decide about that
[21:09]  * kees agrees with pitti
[21:09] <cjwatson> If they really are non-invasive then it probably isn't worth the hassle of trying to move the fix around; but I would like to have an unbiased assessment of that.
[21:10] <cjwatson> stgraber: I'd rather bundle too.
[21:10] <smoser> cjwatson, i'd have to look further to see which of the django changes are required.
[21:10] <stgraber> ok ;) As I said, I don't mind very much, I just have a vague interest in the tftp bit and it'd have the nice advantage of saving me an upload to my PPA, but that's about the extent of how much I care ;)
[21:10] <slangasek> the maas package currently in precise depends on the external python-django package; so switching it to bundle now would seem to be a bit of a regression on that score
[21:10] <cjwatson> Yes, I'm not currently offering an opinion on bundling or otherwise of django
[21:11] <cjwatson> I'd like to have the smallest change with lowest risk; it's not clear at this point where that lives
[21:11] <slangasek> while the python-django changes don't meet the letter of the SRU policy as ScottK says, it's not a wholesale backport or anything... I think the django SRU approach makes sense
[21:12] <cjwatson> And for the record I think the "my way or the highway" approach evidenced in bug 1081392 is entirely inappropriate for a technical discussion in a bug report.
[21:12] <cjwatson> (from the maas team)
[21:13] <smoser> clearly that could have gone better. i dont think anyone would disagree.
[21:13] <cjwatson> It may be the right thing to do, but let's try reasoning rather than assertion :-)
[21:14] <slangasek> if the TB generally feels it's warranted to override the SRU policy here, I'm happy to dig into the details of the python-django SRU and assess it (as I have some familiarity with django)
[21:15] <smoser> i can make sure the maas team offers help / guidance to slangasek there.
[21:15] <pitti> my gut feeling is that these sound small enough to warrant an SRU exception, but it hasn't been made clear how these can be regression-tested
[21:15] <cjwatson> I would like to have some notion of how we can regression-test this for other django users
[21:15] <pitti> i. e. with prominent python-django rdepends
[21:16] <kees> agreed. I only know the simplest of django uses, and I don't think that's sufficient.
[21:16] <pitti> and it would be great if these two SRU bugs could get patches attached for review
[21:16] <slangasek> pitti: I believe, but have not yet verified, that the new features don't change the behavior of existing code
[21:16] <pitti> it's always easier to judge regression potential by looking at what actually changd
[21:16] <slangasek> thats my recollection of the previous discussion around that SRU
[21:17] <pitti> e. g. if that just adds a new function to the API, it'd be harmless
[21:17] <pitti> which may very well be the case here
[21:17] <stgraber> At least the addition of GenericIPAddressfield sounds to me like it could be done in the maas code without requiring shipping a whole copy of django, so maybe that's another way to get the feature without having to SRU new features into a stable release?
[21:17] <cjwatson> Has GenericIPAddressField been security-reviewed (this is on a security boundary, right?)?  Does it handle database migration?
[21:18] <stgraber> I'm not terribly familiar with Django, but it sounds like this is just a convenience type which ends up being mapped to an int in the DB, so surely this can be done without patching the core?
[21:18]  * ScottK mostly felt django was a TB decision, not just ubuntu-sru.
[21:18] <ScottK> If you're happy, I'm happy.
[21:18] <cjwatson> I could see prefetch being suitable - it would improve perf for other users, presumably - but it's a fairly complex change I can't review
[21:18] <smoser> stgraber, you're probably correct. i'm sure we can find some way to get the same functionality inside of maas.
[21:18]  * pitti feels he has too little data to decide whether he should be scared or happy
[21:19] <cjwatson> If it's had qualified code review and has some kind of plan for regression-testing then I'd be OK with the prefetch change
[21:19] <smoser> the ipv6 code there, just ends up taking the same path as other suggested chaanges.
[21:19] <smoser> as to whether it should be shoved inside maas (and not available to others) or incorporated into sru for others to benefit.
[21:19] <cjwatson> I guess I'm more or less agnostic about GenericIPAddressField
[21:19] <cjwatson> "not available to others" shouldn't be a consideration we apply in SRUs, though
[21:20] <cjwatson> Least-risk is pretty much an overriding criterion
[21:20] <smoser> fair
[21:20] <cjwatson> Same logic as yui3/raphael
[21:20] <stgraber> right, prefetch seems way harder to keep inside maas, so I think this one may be fine for an exception provided sufficient testing and guarantee it won't affect existing code (that it's just an addition that only maas will use as far as packaged software goes)
[21:20] <smoser> right. which is what i was trying to say.
[21:22] <cjwatson> Any more comments?  I'd be happy to hand off detailed review to slangasek's judgement
[21:23] <smoser> only comment is that everyone involved is aware that this is not "traditional SRU"
[21:23] <smoser> the overriding interst is in getting something useful to ubuntu users to live on 12.04.
[21:24] <cjwatson> ScottK: FWIW (re 1081392) if you *wanted* to push for a wholesale update of owncloud on the basis that the old version is completely useless, I don't know that I'd be completely opposed; I actually wondered why nobody was doing that
[21:24] <ScottK> It would have required backporting a bunch of other packages.
[21:24] <kees> apologies, I have to run away early...
[21:24] <ScottK> If it was just owncloud, that's the direction we'd have gone.
[21:25] <cjwatson> maas was pretty immature in precise, which was a problem in itself at the time.  Indeed, it's not a traditional SRU; but I can see the value in it.
[21:25] <cjwatson> ScottK: Ah, fair enough
[21:25] <stgraber> ScottK: and I assume those are big/complex enough that you couldn't get away with the same bundling game as MAAS?
[21:25] <cjwatson> kees: thanks
[21:26] <smoser> the maas and ubuntu server teams will do whatever is necessary to do this right.
[21:26] <stgraber> anyway, for the actual discussion topic, I'm happy having this be a one-off thing for MAAS and I trust ~ubuntu-sru to enforce the rigorous testing this will require (especially for the django bits), so I'm happy having slangasek and the ubuntu-sru team do the review and have this move along
[21:27] <pitti> yeah, I agree for MAAS itself; that's sufficiently a "leaf" package, and the rationale makes sense to me for an LTS
[21:27] <cjwatson> Yep.  Do we need a vote (is there any dissent), or shall we carry this by acclamation?
[21:28] <cjwatson> kees sounded in general agreement
[21:28] <pitti> to me it seems we by and large agree; we all want to see a regression test plan for django and maas itself, and bundle the others
[21:28] <stgraber> I don't think I heard anyone being explicitly against it, we're really just discussing some of the implementation details which I'm sure the SRU team can take care of ;)
[21:28] <cjwatson> OK, let's move on then; I'll distil this into the minutes
[21:29] <smoser> thanks all.
[21:29] <pitti> ScottK: I want to say thanks for following the proper process here
[21:29] <ScottK> pitti: Thanks.
[21:29] <cjwatson> I see nothing new on the list
[21:29] <cjwatson> And no open bugs
[21:29] <cjwatson> #topic AOB
[21:31] <pitti> a quick FYI, no further responses to the brainstorm reviews
[21:32] <cjwatson> Oh, hell, I haven't done mine yet
[21:32]  * cjwatson sticks that on kanban in an attempt to remember
[21:33] <pitti> I'll send a followup reminder email
[21:33] <cjwatson> also:
[21:33] <cjwatson> #action cjwatson to amend SRU/MRE documentation to reflect slangasek's comments about bundling
[21:33] <meetingology> ACTION: cjwatson to amend SRU/MRE documentation to reflect slangasek's comments about bundling
[21:33] <cjwatson> if that's OK with everyone
[21:33] <pitti> oh, thanks
[21:33] <stgraber> yep, thanks
[21:34] <cjwatson> going once
[21:34] <cjwatson> going twice
[21:35] <cjwatson> sold to the developer in the orange hat
[21:35] <cjwatson> #endmeeting
[21:35] <meetingology> Meeting ended Mon Feb  4 21:35:44 2013 UTC.
[21:35] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-02-04-21.00.moin.txt
[21:35] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-02-04-21.00.html
[21:35] <cjwatson> I'll write up minutes when evening time permits
[21:35] <pitti> thanks everyone