[07:01] <stochastic> Hi everyone.  Who all is here for the Ubuntu Studio Developer's meeting?
[07:02] <TheMuso> Hey stochastic.
[07:02] <stochastic> hey TheMuso
[07:03] <stochastic> TheMuso are we the only two here?
[07:03] <TheMuso> stochastic: So far.
[07:05] <stochastic> Well should we proceed with discussion of the agenda?
[07:05] <stochastic> https://wiki.ubuntu.com/UbuntuStudio/Meetings/2009Nov9
[07:06] <TheMuso> Since there is only the two of us atm, I don't really feel like going through it, since I've just had a day of work. If others were in attendance, I'd be ok with it however.
[07:06] <jussio1> ö/
[07:07] <TheMuso> stochastic: However if you want to, thats fine with me.
[07:07] <jussio1> stochastic: go for it
[07:07] <stochastic> hi jussio1
[07:07]  * jussio1 slaps whoever invented mornings...
[07:08] <stochastic> well since jussi is here now, I think it's worth at least skimming through the topics
[07:08] <TheMuso> ok
[07:08] <stochastic> so Discussion of Karmic
[07:09] <stochastic> are users happy?
[07:09] <stochastic> there were lots of upgrade issues I heard about
[07:09]  * TheMuso thinks so, overall. It doesn't help that we have some users giving bad information to help others out of a bind.
[07:09] <jussio1> as long as the RT kernel works, most users are happy.
[07:09] <stochastic> yeah, in general people like Karmic
[07:09] <TheMuso> stochastic: Well since we don't have enough man power to even test fresh installs, I am not surprised users have upgade issues, since we don't really test it.
[07:09] <jussio1> how is it running? whats the status?
[07:10] <stochastic> jussio1, you mean the RT kernel?
[07:10] <TheMuso> jussio1: Overall the RT kernel is doing very well. I think a few users are having issues with suspend/resume, but we don't promote that as something we support.
[07:10] <jussio1> yeah
[07:10] <jussio1> TheMuso: ok, great.
[07:11]  * jussio1 is a little bit out of stuff atm. 
[07:11] <stochastic> has any user reported the Swami thing?
[07:11] <TheMuso> Well I made a note during karmic that swami needed updating, but never got back to doing it.
[07:12] <stochastic> yeah, okay, I haven't heard anyone saying that the soundfont support is broken in any way
[07:13] <stochastic> anything else to say about Karmic?
[07:13] <TheMuso> not from me
[07:14] <stochastic> Okay Lucid:
[07:14] <stochastic> Jack into Main
[07:15] <stochastic> what are we needing to do at this stage?  wait for some debian syncs?
[07:16] <stochastic> TheMuso, jussio1, are you two planning on helping with this move of jack into main?
[07:17] <jussio1> stochastic: not overly, there are others who are interested. Ive many many things on my plate atm. Although I may be able to do some testing if required.
[07:17] <TheMuso> stochastic: Yes, I need to review all the pieces first, and take appropriate action, will take care of it once initial merges/syncs are out of the way.
[07:17] <stochastic> TheMuso, okay great.  I think libffado may need a sync request.
[07:18] <stochastic> TheMuso should a schedule be built for this project?
[07:19] <TheMuso> stochastic: I don't think so.
[07:20] <stochastic> okay, anything else need to be said about Jack in Main?
[07:20] <TheMuso> nope
[07:21] <stochastic> okay I put growth in Graphics and Video metas on the agenda because I'd like to see a more balanced userbase
[07:21] <TheMuso> No omment, not a user of these
[07:21] <TheMuso> comment
[07:21] <TheMuso> I just add/remove whats asked for.
[07:21] <stochastic> fair enough
[07:22] <jussio1> hrm
[07:22] <jussio1> I think we have to cater to the users out there.
[07:22] <stochastic> I'll consult with some people on what new possible tweaks we might offer.  The Video package might see some stable and user friendly editors coming in Lucid.
[07:23] <stochastic> jussio1, you mean our current userbase?
[07:25] <stochastic> okay, well constant meta package consultations need to be looked into anyway
[07:25] <jussio1> stochastic: I mean that we need to check that we have users actually using the features we offer. if not, we need to consider dropping some.
[07:25] <stochastic> true
[07:25] <TheMuso> jussio1: Agreed, disks are big as it is, if we can cut them down as much as possible, then that would be good.
[07:26] <jussio1> Perhaps some sort of user survey or something is in oreder. (havent really thought it through)
[07:27] <stochastic> Should we plan on sending an e-mail to the users list to gauge interest in applications?
[07:28] <stochastic> I'll happily do this.
[07:28] <TheMuso> sounds like a good idea
[07:28] <jussio1> stochastic: email might be a bit long, given how many apps we ship
[07:28] <jussio1> perhaps an email with a wiki link?
[07:28] <jussio1> or somethign similar.
[07:29] <stochastic> jussio1, okay that might work too
[07:29] <jussio1> but yeah, some sort of user feedback is important.
[07:29] <stochastic> okay anything else to say on this topic?
[07:30] <TheMuso> no
[07:30] <stochastic> I think we can safely skip over the next two agenda points "updated packaging whishlist" and "motin's suggestion regarding using the ubuntustudio ppa for jack package testing"
[07:31] <TheMuso> right
[07:31] <stochastic> anyone want to talk on those points?
[07:31] <stochastic> the next item is Kernel Plan
[07:31] <TheMuso> We don't know what mainline kernel will be used for lucid yet, so can't do anything else till we know that.
[07:31] <TheMuso> thats pretty much it atm.
[07:32] <stochastic> fair enough
[07:32] <stochastic> next item is Ubuntu Studio Controls
[07:32] <jussio1> is there a reason we cant stick with an older kernel?
[07:33] <TheMuso> jussio1: It breaks different pieces of the userspace stack in weird and wonderful ways.
[07:33] <jussio1> :(
[07:33] <jussio1> hrr
[07:33] <TheMuso> jussio1: We had a mis-aligned alsa stack in hardy, and it broke things in painful ways for some people.
[07:33] <jussio1> right. moving n then
[07:34] <stochastic> Alex has recently expressed in a need-packaging bug that he's too busy right now to devote much time to Ubuntu Studio so I don't imagine he'll be around to help with Controls updates
[07:34] <TheMuso> right
[07:34] <jussio1> alex?
[07:34] <stochastic> rexbron
[07:34] <TheMuso> s/alex/andrew/
[07:34] <stochastic> whoops
[07:34] <stochastic> sorry
[07:35] <TheMuso> np
[07:35] <stochastic> Is Luis knowledgeable in the Controls code?
[07:35] <TheMuso> I believe so.
[07:35] <stochastic> Cory was saying Luis and Andrew should be penned in to migrate Controls to GTKBuilder
[07:36] <jussio1> its python anyway, and not too large, so if we can find a new someone they could learn reasonably quick.
[07:36] <stochastic> but we also have a number of Controls bugs we need to tackle.
[07:36] <stochastic> I'm partially knowledgeable with the codebase
[07:36] <stochastic> a new developer would be a great thing
[07:37] <TheMuso> right
[07:37] <stochastic> jussio1, do you have anyone in mind?
[07:38] <jussio1> no
[07:38] <stochastic> okay, well in conversations with everyone keep this project in the back of your head
[07:38] <stochastic> anything else to say on Controls?
[07:40] <TheMuso> no
[07:40] <stochastic> Next on the agenda is the artwork to be used project-wide, but Cory isn't around.  I trust he has a plan.
[07:40] <stochastic> I sure am glad Cory has time to work on this
[07:41] <stochastic> last Lucid-specific topic is "What elements need to be added to https://wiki.ubuntu.com/UbuntuStudio/LucidTaskList "
[07:42] <stochastic> I think we need to announce this page a little bit and try to get new team members to chip in a bit through those projects.
[07:42] <jussio1> yes.
[07:42] <TheMuso> right
[07:42] <TheMuso> agreed
[07:42] <jussio1> and we need to be a little more open with "team membership". it needs to be a little less "exclusive" so people feel more comfortsble contributing.
[07:43] <TheMuso> The ubuntustudio-dev team? I don't agree.
[07:43] <TheMuso> The team has write access to seeds and packaging branches in bzr.
[07:43] <TheMuso> IMO one has to earn their access to that data.
[07:43] <jussio1> TheMuso: I dont mean adding people to it, but there needs to be something further for casual contributors - similar to erics testing team
[07:44] <TheMuso> jussio1: Ok thats fine then.
[07:44] <stochastic> speaking of the Testing Team, that's the final agenda topic
[07:44] <stochastic> Cory was the only one to speak out with any form of opposition/critique on the mailing list
[07:45] <TheMuso> I am fine with it.
[07:45] <jussio1> big +1 from me.
[07:45] <stochastic> Okay, I'll go ahead with the plan and we can talk about how successful it is as it progresses
[07:46] <TheMuso> Ok great.
[07:46] <stochastic> Can I assume I should subscribe ubuntustudio-dev as members of the testing team?
[07:46] <TheMuso> yup
[07:46] <stochastic> great.
[07:46] <stochastic> anything else to say before we ajourn the meeting?
[07:46] <TheMuso> not fro me
[07:47] <jussio1> nope
[07:47] <stochastic> oh, we need to sort out a re-scheduling of meetings
[07:47] <TheMuso> not enough of us here to make a decision on that
[07:47] <stochastic> I guess the Mailing List is the best medium for that
[07:47] <TheMuso> I can be flexible with those times, so I'd rather leave it up to others
[07:47] <TheMuso> s/those times/times/
[07:47] <stochastic> okay
[07:48] <stochastic> jussio1, you have any preferences?  talk was about moving the meetings to Sundays
[07:50] <stochastic> Well I think we can cal the meeting over now.  Thanks for showing up TheMuso and jussio1.
[07:50] <TheMuso> stochastic: np thanks guys.
[07:52] <jussio1> stochastic: this is ok. euro day is generally good.
[07:53] <stochastic> jussio1, okay I'm sure we can work around that.  Watch for announcements/discussions on the mailing list
[07:53] <stochastic> ttyl
[07:55] <dholbach> good morning
[18:05]  * robbiew waves
[18:05] <kees> heya
[18:05] <mdeslaur> hello
[18:05] <kees> oh
[18:06] <kees> ok, quick weekly review then to UDS topic/session/todo items?
[18:06] <kees> I've got openjdk-6 updates coming from doko, and will push for getting a kernel update rolling
[18:07] <kees> I'm going to be examining our CVE tracker data and tweaking a bunch of stuff to better reflect reality so the new graphs don't make it look like we're slackers
[18:08] <kees> and I'm on triage.
[18:08] <kees> that's it from me.  jdstrand up next
[18:08] <jdstrand> o/
[18:08]  * jdstrand for some reason thought the meeting was an hour from now...
[18:09] <jdstrand> I'm in the happy place
[18:09] <jdstrand> I plan to continue to follow-up on/file SRUs this week
[18:09] <jdstrand> poke at redhat-cluster, and a couple of other security updates assigned to me
[18:10] <jdstrand> I should have a firefox update again this week
[18:10] <jdstrand> and then UDS preparation
[18:10] <jdstrand> that's it from me
[18:10] <mdeslaur> my turn
[18:10] <mdeslaur> I'm working on openldap.
[18:10] <mdeslaur> that'll take a while
[18:11] <mdeslaur> and will spend some time preparing for UDS topics
[18:11] <mdeslaur> that's it.
[18:12] <kees> ok, cool.  robbiew before we hit the UDS idea list, do you have anything to add to it, or other topics to go over?
[18:12] <robbiew> nah..you're good ;)
[18:12] <jdstrand> I just added a bunch of non-session/work-items for me, so be sure to refresh the page
[18:12] <kees> okidoky
[18:12]  * kees refreshes
[18:12] <robbiew> I suppose I should work on a Security track for next UDS though :/
[18:13] <kees> robbiew: we had one at the last UDS.  :)
[18:13] <robbiew> hmm...let me check then on this one
[18:13] <kees> "apport hooks (vs https://bugs.edge.launchpad.net/~ubuntu-security/+packagebugs)"
[18:13] <kees> this is something that bdmurray had called attention to a while back
[18:13] <kees> basically, if there is an Ubuntu team doing triage for a set of packages, it likely makes sense for those packages to have apport hooks
[18:14] <kees> so, it might be worth having a session to review those package, and perhaps identify others, that we should build hooks for.
[18:14] <kees> thoughts?
[18:15] <mdeslaur> yeah, makes sense
[18:15] <mdeslaur> not sure it's uds-session worthy though
[18:15] <kees> i.e., too much time to discuss it?
[18:15] <jdstrand> I'm not sure it is security team specific
[18:15] <kees> right, bdmurray's call wasn't security team aimed, but I figured we could take on his call-to-action within our team
[18:15] <jdstrand> ie, we are already doing that for the packages we update
[18:15] <mdeslaur> kees: yeah...it's a 10 minute discussion
[18:16] <kees> mdeslaur: really?  I don't think we have hooks for anything listed here except apparmor: https://bugs.edge.launchpad.net/~ubuntu-security/+packagebugs
[18:16] <jdstrand> though, that reminds me, we should generalize and improve the apparmor hook
[18:16] <kees> (perhaps none are needed?)
[18:17]  * jdstrand added that
[18:17] <mdeslaur> kees: oh, well if you feel there's something to discuss, no problem. I thought it was more of a to-do.
[18:17] <kees> how should we define the work for hooks, then "Create list of packages that have been reviewed for apport hooks, with justification for why they lack a hook"?
[18:18] <jdstrand> seems fine
[18:18] <kees> mdeslaur: I figure it'd be nice to review packages that get a lot security bugs, and our subscribed list
[18:18] <kees> Ok, I'll draw up a session for it and dream of ways to fill 40 minutes.  ;)
[18:18] <mdeslaur> kees: oh, yeah, that's a good idea
[18:18] <mdeslaur> that'll fill 40 minutes
[18:18] <jdstrand> kees: well, really anything that ships an AA profile could benefit from a hook
[18:19]  * kees nods
[18:19] <jdstrand> we started to do that, but didn't retroactively add them
[18:19] <kees> "review sponsorship process and compare to security-sponsorship"
[18:19] <jdstrand> seems like a good sessino
[18:19] <jdstrand> session
[18:19] <kees> this is a request from dholbach to try to merge our sponsorship process to standard processes.
[18:20]  * jdstrand nods
[18:20] <kees> I'm really not sure the right approach to take with it, so I agree, face-to-face with dholbach and others would be valuable here.
[18:20] <kees> " http://fedoraproject.org/wiki/Features/LowerProcessCapabilities "
[18:21] <kees> I'd like to see us do this.
[18:21] <kees> I don't think it's a few subtle change...
[18:21] <jdstrand> I would to, but, aren't we always going to get push back for filestystems that don't support it?
[18:21] <kees> especially "the shadow file permissions have been changed to 000"
[18:21] <jdstrand> oh wait
[18:21] <jdstrand> that was fscaps
[18:21] <jdstrand> nm
[18:21] <mdeslaur> is it worth doing that, or getting apparmor profiles for those root daemons?
[18:22] <mdeslaur> that could be something we discuss
[18:22] <kees> I think we should pursue non-MAC methods of hardening along with MAC
[18:22] <jdstrand> kees: are these patches that fedora is planning to just carry ad infinitum? or are they pushing to upstreams?
[18:23] <kees> jdstrand: don't know, that would be worth investigating before the session
[18:23] <kees> is this session-worthy?  I think we'd need foundations in on it.
[18:23] <mdeslaur> we could have a session to determine if it's worth doing from a security point of vue
[18:24] <jdstrand> 000 for /etc/shadow
[18:24] <jdstrand> man, that is hardcore
[18:24] <jdstrand> we'd totally need foundations in on it
[18:24] <jdstrand> that could *totally* break things :P
[18:24] <jdstrand> 555 for /bin
[18:24] <kees> jdstrand: well, it would only break for daemons that had specifically dropped DAC_OVERRIDE
[18:24] <jdstrand> "neat"
[18:25] <kees> jdstrand: by default, a root-running process has DAC_OVERRIDE
[18:25] <jdstrand> I'd need to review it more to have a worthwhile opinion
[18:25] <mdeslaur> it seems the list of daemons that _can_ drop DAC_OVERRIDE is very limited
[18:25] <kees> in the interests of terrifying the foundations team, I think I'd like to make a session for this.
[18:25] <kees> mdeslaur: yeah
[18:26] <mdeslaur> kees: lol :)
[18:26] <jdstrand> sounds risky-- perhaps too risky for LTS, but maybe we could review the topic in general, the apps it might affect, and whether or not to pursue it  (whether for lucid or lucid+1)
[18:26] <mdeslaur> "the following apps are not confinable: console-kit-daemon, cups, postfix, rsyslog, auditd, audispd"
[18:26] <mdeslaur> those are the ones I _want_ to confine :(
[18:26] <ScottK> Insist it's essential for LTS and then reluctantly agree to defer it.  They'll owe you then.
[18:27] <kees> ScottK: heheh
[18:27] <mdeslaur> ScottK: ehehe
[18:27] <jdstrand> "all deps of ubuntu-desktop and applications in the server CD"\
[18:27] <jdstrand> kees: I think it is worthy of a session
[18:27]  * ScottK will once again opine that confining Postfix is likely more trouble than it's worth.
[18:28] <kees> okay, cool.
[18:28] <kees> ScottK: yeah, dovecot is proving painful too
[18:28] <kees> ' figure out better "screen lock does not work" bug triage process '
[18:28] <kees> our session from the last UDS on this topic, frankly, failed.
[18:28] <jdstrand> yeah *sigh*
[18:28] <kees> we have an ever growing number of reports about screen locking not working in a wide variety of cases
[18:29] <mdeslaur> kees: we need to get gnome-screensaver maintainers in the session
[18:29] <kees> we cannot fix them all, much less triage them all.
[18:29] <kees> mdeslaur: yes
[18:29] <jdstrand> much less reproduce them
[18:29] <kees> jdstrand: yeah, true
[18:29] <jdstrand> at least some seem hardware specific
[18:29] <kees> yeah
[18:30] <kees> so, I'd like to focus on getting the right people into that session.  I'm not sure who they are, though.
[18:30] <jdstrand> though, as an aside, I noticed gnome-screensaver won't look if a virt-viewer window has focus
[18:30] <mdeslaur> combination of 1- video drivers, 2- gnome-screensaver bugs
[18:30] <jdstrand> probably gtkvnc related
[18:30] <jdstrand> s/look/lock/
[18:31] <mdeslaur> jdstrand: oh? that's interesting
[18:31] <kees> jdstrand: yeah, I've seen that too.  I'd like to get bug triage involved too, as this sounds like a good candidate for a "DebuggingScreenLocking" or something
[18:31] <mdeslaur> kees: excellent idea...a session to get a DebuggingScreenLocking wiki page
[18:32] <mdeslaur> I suspect we can't reproduce some of the issues because people are running alternate window managers
[18:32] <kees> mdeslaur: oooh, yeah, that's the best way to frame it.  It really is the output we need.
[18:32] <kees> yeah
[18:32] <jdstrand> we'd need screensaver devs for gnome, kde and xfce, no?
[18:32] <kees> yeah
[18:32] <ScottK> If it's common enough, maybe also a session with the right people in the room for people to bring borked laptops to for diagnosis?
[18:32] <jdstrand> at list the first two
[18:32] <nxvl> seb should know who the maintainers are
[18:32] <kees> ScottK: yeah
[18:33] <nxvl> so having seb on the session will be of great benefit
[18:33] <nxvl> or pedro, the Desktop QA guy
[18:33] <mdeslaur> ScottK: excellent idea
[18:33] <ScottK> No one from KDE upstream at this UDS, so Riddell is probably your best bet.
[18:33] <ScottK> (he's going to thank me for that, I'm sure)
[18:33] <mdeslaur> hehe
[18:34] <kees> " filesystem capabilities "   uhm, I don't have anything more specific than last UDS, so I'm not sure its worth brining this up again.  Maybe it's just a TODO to get Debian to start doing it for things that can use it immediately/
[18:34] <mdeslaur> kees: can't we start it first?
[18:35] <jdstrand> kees: probably-- aiui, foundations we not too excited due to some filesystems
[18:35] <kees> mdeslaur: sure, though I'd like to get opinions from Debian, since it's kind of an architectural change, requires dpkg support maybe, tar patches, etc
[18:35] <jdstrand> mdeslaur: kees can just upload into Debian then do a sync request
[18:35] <jdstrand> kees: how does that work for you?
[18:35] <jdstrand> :P
[18:35] <kees> jdstrand: heh
[18:35] <mdeslaur> hehe
[18:35] <ScottK> I hear there are going to be a lot of Debian people at UDS.
[18:35] <jdstrand> ScottK: cool
[18:36]  * jdstrand was obviously kidding about the upload/sync thingie
[18:36] <mdeslaur> kees: well, wouldn't wine and dosemu be ideal first candidates for this? can't we put it into postinstall scripts at first?
[18:36] <mdeslaur> or initscripts
[18:36] <kees> mdeslaur: no, I don't think they should get CAP_SYS_RAWIO.
[18:36] <kees> mdeslaur: I'm thinking "ping" is the best
[18:36] <kees> it's already setuid and already drops privs/caps
[18:37] <kees> if it gets the CAP_NET_RAW it would work with no code changes
[18:37] <kees> since the kernel prefers fscaps over setuid bits
[18:38] <ScottK> Yokozar will be at UDS, so you can certainly talk to him about WINE.
[18:38] <mdeslaur> kees: well, we'd need a better use case than ping to convince people
[18:38] <ScottK> Please don't make him too sad as I'm rooming with him and I don't want to have to try to sleep while he's weeping.
[18:38] <kees> ScottK: yeah, I've been talking to Yokozar at length about the mmap_min_addr stuff.  He's going to the Wine conference, where he's bringing it up.
[18:38] <nxvl> mdeslaur: you need a safe sandbox to start playing with it anyway
[18:39] <kees> ScottK: hah
[18:39] <nxvl> mdeslaur: so first one, being a sandbox, and the second one your demo to convince people
[18:39] <kees> ScottK: at present, it seems like I'll be creating a debconf question that defaults to safe for wine.  and for dosemu, it's just be safe since they're emulating low memory now.
[18:40] <kees> ok, doing fscaps as a TODO, chat with Debian, PoC in Ubuntu, etc
[18:40] <kees> I'll make a blueprint for it, though, since it had some prereqs (tar patch)
[18:40] <ScottK> kees: You'll want to make sure that the default GUI package managers support answering debconf questions then (the Kubuntu one doesn't, although it's planned and should make Lucid)
[18:40] <mdeslaur> kees: sounds good
[18:40] <kees> " forwarding patches to debian BTS for security updates "  we're already doing this, iiuc.  anything more we need for UDS?
[18:41] <jdstrand> kees: we sort of do this
[18:41] <mdeslaur> kees: if debian people are there, it would be a good opportunity to ask what we could be doing better
[18:41] <jdstrand> I think we need to have a policy about how we do it, then state it somewhere
[18:41] <kees> mdeslaur: true.  how can we find out?
[18:41] <kees> (the people list, I mean)
[18:42] <mdeslaur> kees: #debian-security?
[18:42] <jdstrand> plus it would be a good opportunity to talk with Debian, and generally let people know we want to dtrt
[18:43] <jdstrand> kees: regardless of what they say in #debian-security, I personally think we should have a session, and if not a session, the 3 of us need to talk about it
[18:43] <kees> alright, perhaps we can make it a large-scope session "Working with the Ubuntu Security Team" or "how can the security team serve you better?"
[18:43] <robbiew> fwiw, I know Luk Claes from the debian release team will be there...don't know if anyone from debian-security
[18:43] <kees> jdstrand: ok
[18:44] <kees> robbiew: yeah
[18:44] <mdeslaur> a generic title like that may not attract the relevant debian folk, though
[18:44] <jdstrand> kees: eg, iirc, some people require a patch go to debian before they sponsor a patch
[18:45] <kees> "How can the Ubuntu Security Team help Debian (or other folks) better?"
[18:45] <robbiew> :)
[18:45] <jdstrand> if we are tying into the regular sponsorship process, then we might get more contributors and maybe more back to debian
[18:45] <kees> jdstrand: yeah, true
[18:45] <jdstrand> kees: who are 'the other folks'?
[18:45]  * jdstrand is slightly confused
[18:45] <ScottK> You might also consider giving community people upload rights for Universe security stuff.
[18:46] <nxvl> jdstrand: upstreams?
[18:46] <kees> jdstrand: Ubuntu community, anyway.  I was just trying to scope the session to "more than just Debian" in case no one from Debian is there/interested.
[18:46] <jdstrand> ScottK: it's been discussed, and that is the long term goal-- the infrastructure hasn't been there in LP
[18:46] <kees> ScottK: we're waiting for "real" ACLs in the sourceSync API
[18:46] <jdstrand> maybe that has changed, I haven't looked at it for some tme
[18:47] <jdstrand> time
[18:47] <kees> jdstrand: does that make sense?  (other people == anyone, Ubuntu, upstream, etc)
[18:47] <jdstrand> kees: I just want to make sure the discussion will be the one we want to have
[18:47] <ScottK> OK.
[18:47] <jdstrand> kees: eg, my personal objective for the session is Debian-specific
[18:48] <jdstrand> kees: the sponsorship session seems ubuntu-community specific
[18:48] <jdstrand> or, at least, the ubuntu-community bits are part of the sponsorship session
[18:48] <kees> jdstrand: true, point taken.  ok, we'll have it as Debian-specific, in the hopes that there is Debian folks, and if not, we can just brainstorm.
[18:48] <jdstrand> kees: but if you want it broader, that is fine be me (I just think we can accomplish a lot even without Debian)
[18:49]  * kees nods
[18:49] <kees> " protecting select() users when RLIMIT_NOFILE > 1024 http://sourceware.org/bugzilla/show_bug.cgi?id=10352 "
[18:49] <mdeslaur> kees: whoever's not attending can at least join in on irc
[18:49] <jdstrand> mdeslaur: are we doing irc this time around? ;)
[18:49] <kees> this is ... probably just a todo.  requires a source search and a massive bug-filing campaign.  I will do it via Debian, though it's not a high priority since most services don't run with RLIMIT_NOFILE > 1024.
[18:50] <mdeslaur> jdong: sorry...I don't get it
[18:50] <nxvl> mdeslaur: tab completion error?
[18:50] <kees> any thoughts on this goofy select bug?
[18:51] <mdeslaur> whoops
[18:51] <mdeslaur> jdstrand: sorry...I don't get it
[18:51] <nxvl> kees: so it will mean doing a source check for tons of packages?
[18:51] <jdstrand> mdeslaur: iirc, we didn't have irc input at our last UDS
[18:51] <ScottK> Yes, we did.
[18:51] <jdstrand> mdeslaur: perhaps I was the only slacker who didn't pay attention to it
[18:52] <mdeslaur> jdstrand: oh, your internets were busted :P
[18:52] <kees> nxvl: yeah, a) generate list of all sources that use select() with a listen()/accept()  b) see if they correctly deal with fd_set being >1024 fds.   c) file bugs
[18:52] <jdstrand> ScottK: I don't recall it in any of the session I attended (whether I, the security team, or someone else led it)
[18:52] <jdstrand> but sounds like I may have just been the only slacker
[18:52] <ScottK> Some sessions used it, some didn't.
[18:53] <nxvl> kees: yeah, the question is: is there anyway to check if it uses select() without actually looking at the source?
[18:53] <kees> nxvl: we could look at binaries.  :P
[18:53]  * nxvl smells nightmare
[18:53] <mdeslaur> nxvl: magic wand? :
[18:53] <kees> nxvl: indeed.  :P
[18:53] <kees> ok, onward
[18:53] <kees> " using lxc "
[18:54] <kees> that's LinuX Containers
[18:54] <nxvl> we can always get the full archive and run grep :P
[18:54] <mdeslaur> nxvl: we already have a tool that does that
[18:54] <nxvl> mdeslaur: yeah, that's what i was talking about :D
[18:54] <kees> nxvl: right, I have tools that can do this already.  it's just that the combo of listen/accept/select is hard to search for
[18:54] <kees> I have no idea what a session on Linux Containers would look like, but it seriously rocks -- chroot on crack.
[18:55] <mdeslaur> kees: as in using them for what?
[18:55] <kees> (without kernel patches)
[18:55] <nxvl> kees: well, searching only select, build a list, then reduce the scope of the search to just those will be really helpfull
[18:55] <kees> mdeslaur: yeah, brain storming, I guess.
[18:55] <kees> not really sure.
[18:55] <kees> nxvl: true, yeah
[18:56] <kees> but if there are no idea, we need to skip it.  :)
[18:56] <jdstrand> kees: I want to type something in response to 'using lxc', but don't know what
[18:56] <kees> jdstrand: heh, yeah, me either.  :P
[18:56] <jdstrand> well, I'll toss this out: libvirt has lxc support
[18:57]  * kees nods
[18:57] <jdstrand> that's all I have :)
[18:57] <mdeslaur> NEXT!
[18:57] <kees> " process limit unlimited (LP: #391761) "
[18:57] <jdstrand> kees: were you thinking of investigating lxc and perhaps documenting it somewhere?
[18:57] <kees> I think this might just be another TODO for me to poke foundations (specifically slangasek) about.  I was suggesting some ideas to slangasek about this recently
[18:58] <ScottK> In other news, I noticed today that it's been over half a year since the last clamav -security upload.  Who would have thought such a thing was possible?
[18:58] <kees> jdstrand: maybe, there's already plenty of docs on using it, though.  I was thinking about using it with schroot/sbuild (gains network isolation trivially)
[18:58] <jdstrand> ScottK: totally! I sure didn't :)
[18:58] <kees> ScottK: hah! whoa
[18:58] <ScottK> We ought to (at some point, not at UDS) discuss the timing for replacing clamav 0.94 in Dapper/Hardy/Intrepid.
[18:58] <kees> ScottK: will you be at UDS?
[18:58] <jdstrand> yeah, we did a little the other day
[18:58] <ScottK> Yes
[18:58] <mdeslaur> ScottK: excellent idea
[18:59] <kees> why not discuss at UDS?
[18:59] <ScottK> No reason not to.
[18:59] <ScottK> Just UDS tends to be busy and that doesn't really NEED a session.
[18:59] <jdstrand> it certainly wouldn't require a session, afaict
[18:59] <kees> ok, cool.
[19:00] <kees> " readdir_r stack smashing (LP: #392501) "
[19:00] <nxvl> with the previus experience, security "track" should have half-hour sessions
[19:00] <nxvl> :P
[19:00] <kees> this is... odd and needs investigation, not really a session.  TODO!
[19:00] <mdeslaur> kees: whoa, that again :)
[19:00]  * nxvl is confused
[19:00] <kees> mdeslaur: yeah, still not solved.  I suspect alignment fun in the kernel.... *pokes out own eyes*
[19:00] <nxvl> kees: are you talking about clamav or the proces limit thing?
[19:01] <kees> nxvl: talking about 19:00 < kees> " readdir_r stack smashing (LP: #392501) "
[19:01] <nxvl> ohh
[19:01] <mdeslaur> nxvl: the readdir_r thing
[19:01] <nxvl> i missed that one
[19:01] <nxvl> thnx
[19:01] <mdeslaur> kees: we should try it on karmic
[19:01] <mdeslaur> maybe it got magically fixed :)
[19:01] <kees> mdeslaur: that's be cool.
[19:01] <kees> " upstream NX-emu patch http://www.codemonkey.org.uk/junk/linus-es.txt "
[19:02] <kees> this is a TODO.  a laughable todo, as I don't think I will be even remotely successful, but I want to try.
[19:02] <mdeslaur> kees: good luck
[19:03]  * kees looks at his list for something that is NOT a todo...
[19:03] <nxvl> kees: hope is the last thing to lose
[19:03] <nxvl> :P
[19:03] <kees> nxvl: heh
[19:03]  * nxvl notices that it makes more sense in spanish
[19:03] <jdstrand> kees: did you skip the -Wl,-z,now stuff purposefully?
[19:03] <kees> ah, yes.  " grub2 + TPM "
[19:03] <kees> jdstrand: I did, they're todo items
[19:03] <jdstrand> k
[19:03] <kees> jdstrand: and now I just skipped a bunch more that I think are all TODO
[19:03] <kees> getting the TPM patches into grub might be interesting
[19:04] <mdeslaur> grub2+TPM?
[19:04] <kees> it could be used for people looking for an end-to-end secure system using the bios TPM bits.
[19:04] <kees> right now it's not possible because it requires out-of-tree grub changes.
[19:05] <kees> I look at this like SELinux -- it should be possible for people to do it, but it's not an Ubuntu default.
[19:05] <mdeslaur> and the TPM patch kills some grub functionality to fit
[19:05] <kees> eek!
[19:05] <kees> that I didn't know about
[19:05] <mdeslaur> yeah, it removes something...LBA support...or something
[19:05] <kees> well, perhaps a grub-tpm package or something
[19:05] <mdeslaur> would be interesting
[19:05] <kees> should this get a session, or is this more a "just work on it" kind of thing?
[19:06] <jdstrand> todo
[19:06] <kees> ok
[19:06] <kees> " http://people.canonical.com/~kees/nx-missing into pkg on server & desktop that has translations, preferably tied to x86/x86_64 arch. "
[19:06] <jdstrand> I'm not sure what else there is to discuss. there's a patch, it might break something. if it does, a different package, if it doesn't, a config option
[19:06] <kees> jdstrand: yeah
[19:06] <jdstrand> re grub2/tpm)
[19:07] <kees> so, http://people.canonical.com/~kees/nx-missing needs to actually call http://people.canonical.com/~kees/check-bios-nx as the latter is much more accurate
[19:07] <mdeslaur> kees: discuss where and how to display that warning?
[19:07] <jdstrand> kees: that nx-issing needs DX, now?
[19:07] <jdstrand> no?
[19:08] <kees> mdeslaur: basically, yes.  needs DX, and somewhere to live.  I draw a blank every time I try to pick a package to put it in.
[19:08]  * mdeslaur votes for gnome-games
[19:08] <kees> hah
[19:09]  * jdstrand votes for openoffice.org
[19:09] <mdeslaur> kees: sure, a session sounds good
[19:09] <jdstrand> it'll make it easy to test then
[19:09] <kees> and " should /proc/kallsyms and /boot/System.map be root-only "
[19:09] <kees> jdstrand: yeah
[19:09] <kees> so, this file is a map of kernel symbols.
[19:10] <kees> it can be used for kerneloops debugging
[19:10] <kees> and for loading kernel rootkits.  ;)
[19:10] <kees> that said, an attacker can just build the Ubuntu kernel to get these offsets.
[19:10] <jdstrand> yeah
[19:11] <kees> or log into their own system as root to get them for any release.
[19:11] <kees> I think it's not worth it.  neither TODO nor session.
[19:11] <mdeslaur> kees: right...
[19:11] <jdstrand> I don't see it particularly useful except where someone is using a non-default kernel
[19:11] <mdeslaur> although...automated worms could be cross-distro if they could read that...
[19:11] <kees> perhaps I can send a patch to the kernel and see it get NAKd, and then I'll be done with that item.  :P
[19:11] <jdstrand> heh
[19:12] <kees> mdeslaur: they could be cross-distro by carrying a matrix of version/symbol too.
[19:12] <kees> less future-proofed though
[19:12] <jdstrand> there are ways around that
[19:12] <mdeslaur> makes it harder, but yeah
[19:12] <kees> " Ubuntu and Debian security collaboration " -> "How can the Ubuntu Security Team help Debian better?"   yes?
[19:12] <jdstrand> actually, you should refresh the page again now
[19:13] <nxvl> well, at least you will be safe of dangerous script-kiddies that don't know what they are doing and can destroy your system :P
[19:13] <mdeslaur> sounds good to me
[19:13] <nxvl> +1
[19:13] <jdstrand> kees: I removed it cause I didn't see you line item
[19:13] <jdstrand> kees: so, yes
[19:13]  * kees reloads ah-ha
[19:13] <nxvl> jdstrand: what's the page? the roadmap?
[19:13] <jdstrand> https://wiki.ubuntu.com/SecurityTeam/UDS
[19:13] <mdeslaur> nxvl: https://wiki.ubuntu.com/SecurityTeam/UDS
[19:13] <kees> " apparmor abstractions cleanup "
[19:14] <jdstrand> I think it needs a session
[19:14] <nxvl> ah-ha
[19:14] <kees> this is a fun one.  I think it's session-worthy
[19:14] <nxvl> mdeslaur: thnx
[19:14] <mdeslaur> yep, I think it's session worthy also
[19:14] <kees> " apparmor usability "
[19:14] <jdstrand> we could talk conceptually about what we'd like to see, then go through profiles and see what could be better
[19:14] <kees> would this be a review of all the userspace tools, or a more general discussion?
[19:14] <jdstrand> there is a lot there, it needs a session
[19:14] <kees> ah, very wide.  excellent.
[19:15] <jdstrand> well, tunables on upgrades is a big one I want to solve for UDS
[19:15] <mdeslaur> yeah, I like it
[19:15] <kees> oooh
[19:15] <kees> " sort out apparmor upstream vs apparmor in ubuntu "
[19:15] <jdstrand> but there are other things like this applet I've heard about that could be discussed
[19:15] <jdstrand> kees: too fast!
[19:15] <jdstrand> :)
[19:16] <kees> jdstrand: sorry!  seemed like we agreed on the session.
[19:16] <jdstrand> also maybe thinking about how to report denials
[19:16] <jdstrand> ah
[19:16] <jdstrand> ok then
[19:16] <jdstrand> next!
[19:16] <jdstrand> sort out apparmor upstream vs apparmor in ubuntu
[19:16] <kees> jdstrand: actually, let's pass the baton... we should each drive our own lists...
[19:16] <jdstrand> thanks
[19:17] <kees> I think this is a TODO, we just need to merge back some changes.
[19:17] <jdstrand> so, this may not be session worthy-- but we should at least sit down and define how we want development to proceed
[19:17] <nxvl> unless there are apparmor upstreams at UDS, which i doubt
[19:17] <jdstrand> kees: well, I started that work already
[19:17] <jdstrand> nxvl: dude, there will be at least 5 upstreams
[19:17] <kees> jdstrand: yeah, I saw that
[19:17] <jdstrand> jj, sbeattie, kees, mdeslaur and myself :)
[19:18] <nxvl> jdstrand: well..
[19:18] <kees> jdstrand: let's have an "AppArmor upstream planning session" ?
[19:18] <jdstrand> kees: but I was more thinking about making sure we all follow how to work on it
[19:18] <jdstrand> kees: I like that
[19:18] <jdstrand> kees: it's broad and we can talk about whatever
[19:18] <jdstrand> kees: we may need/want a few of those
[19:18]  * kees nods
[19:18] <jdstrand> but maybe just schedule one then try to fit in others as we go?
[19:19] <nxvl> jdstrand: i was thinking about non-ubuntu people
[19:19] <jdstrand> nxvl: sure, but we have a lot of devs in one place, we need to take advantage of that
[19:19] <jdstrand> ok
[19:19] <jdstrand> ufw
[19:19] <nxvl> agreed
[19:20] <jdstrand> usability is all TODO
[19:20] <jdstrand> so is upstart stuff
[19:20] <jdstrand> I did want to talk to the server team about what they might want to see
[19:21] <jdstrand> I'm not sure that is session worthy though
[19:21] <jdstrand> I'm rooming with the virt lead, so will probably have this discussion out of band
[19:21] <jdstrand> regarding features-- I know what people want, I just need to do it
[19:22]  * kees nods
[19:22] <jdstrand> kees: are we planning on a catchall session like the last couple of UDSs?
[19:22] <kees> jdstrand: we should, yeah
[19:22] <kees> jdstrand: do you want to make a blueprint for ufw features, just for tracking?
[19:22] <jdstrand> we could just have it as a line item
[19:23] <jdstrand> kees: maybe-- need to think about it
[19:24] <kees> okay
[19:24] <jdstrand> "libvirt/apparmor features, polishing and maintenance "
[19:24] <jdstrand> while 9.10 is working quite well, there is stilla  surprising amount of work to be done
[19:24] <jdstrand> upstream libvirt is very active
[19:25] <jdstrand> almost all of this is TODO
[19:25] <kees> will libvirt folks be at UDS?
[19:25] <jdstrand> run qemu:///system VMs as non-root is now supported as of 0.7.0 (ie karmic)
[19:25] <jdstrand> kees: I don't know
[19:25] <jdstrand> however, I don't think we should diverge from Debian on qemu:///system
[19:26] <jdstrand> plus, since we have AA confinement, they are likely more interested in qemu:///system as non-root, so we can hopefully get it for free
[19:26] <kees> yeah, true
[19:26] <jdstrand> the rest are TODO
[19:27] <jdstrand> I'm not sure I can drive qemu:///system as non-root this cycle
[19:27] <jdstrand> (either)
[19:27] <jdstrand> that seems a big undertaking...
[19:27] <kees> yeah, no worries.  I'd kind of like us to focus on bug-fixes/LTSification this cycle more than features
[19:27] <kees> yeah
[19:27] <jdstrand> anyway, mdeslaur-- you're next
[19:28] <jdstrand> kees: totally
[19:28] <mdeslaur> I'd like to have a session on smartcard/hardware token two-factor authentication
[19:28] <kees> can we bring hardware for that?
[19:28] <jdstrand> kees: which I think the items I added reflect that (that was my intent anyway)
[19:28] <kees> jdstrand: absolutely
[19:28] <mdeslaur> ie: what the current status is, what people would like to see, what needs work, enterprise demand, etc.
[19:28] <kees> mdeslaur: I think it's worth it -- fingerprint reader I think should be included too
[19:29] <kees> mdeslaur: RFID, smartcard, USB dongle, fingerprint reader, etc
[19:29] <jdstrand> while I agree in spririt, I'm far less excited about the fingerprint reader :P
[19:29] <nxvl> mdeslaur: AFAIK kirkland had that working on california
[19:29] <mdeslaur> although it would be more a "discovery" and scope defining session, as I'm not up-to-speed on what we support right now
[19:30] <kees> mdeslaur: yeah, same for me.  I'm not sure who can help us there, perhaps soren?
[19:30] <jdstrand> I'd love a way to turn a regular ol' us key into a token for two-factor auth
[19:30] <nxvl> mdeslaur: i remember him talking about having his encrypted LVM key in an external storage
[19:30] <jdstrand> kees: soren probably would be very good for that
[19:30] <mdeslaur> maybe the pre-sales guys can talk about customer demand also
[19:30] <jdstrand> /us/usb/
[19:31]  * kees ponders USB stick with eCryptfs that has the mount passphrase for an LV  and then falls over crying
[19:31] <jdstrand> hehe
[19:32] <kees> mdeslaur: who does this 2-factor session differ from the Cert-on-USB auth idea?
[19:32] <kees> s/who/how/
[19:32] <mdeslaur> kees: it doesn't. the cert-on-usb stick is just an alternative to explore.
[19:32] <kees> ok, cool.
[19:32] <mdeslaur> that's all I have...the other topics I wanted were already in your lists
[19:32] <nxvl> so one session for your 2 items will be enough?
[19:32] <mdeslaur> yes
[19:33] <mdeslaur> the cert on a usb stick is more of a todo/proof of concept
[19:33] <jdstrand> I think a usb-token-creator app would be awesome
[19:33] <mdeslaur> (or shooting it down...)
[19:33] <jdstrand> something akin to the usb creator for isos
[19:34] <jdstrand> anyhoo
[19:34] <jdstrand> is there anything else?
[19:34] <kees> https://wiki.ubuntu.com/SecurityTeam/UDS has what I collected in rough notes as session
[19:34] <kees> s
[19:35] <kees> if that list looks good, we should claim/assign sessions
[19:35] <nxvl> oh
[19:35] <jdstrand> kees: should we do that here or somewhere else?
[19:36] <nxvl> kees: and ask for security tags so we don't need to biuld them again
[19:36] <nxvl> :P
[19:36] <kees> nxvl: what?
[19:36] <jdstrand> kees: for the name tags
[19:36] <mdeslaur> security badge ribbons
[19:36] <nxvl> kees: those tags for the badges
[19:36] <kees> nxvl, jdstrand: oh! haha
[19:36] <mdeslaur> so you guys don't need to do arts and crafts
[19:36] <jdstrand> that's a jono thing iirc
[19:36] <mdeslaur> jono: nxvl wants security badge ribbons
[19:37] <nxvl> last time rick was blamed
[19:37] <nxvl> so i suspect this time robbiew will be
[19:38] <kees> nxvl: email to clan sent.
[19:38] <jono> nxvl, we are not doing ribbons this time
[19:38] <nxvl> \o/
[19:38] <jono> :)
[19:38] <nxvl> that would do it
[19:38] <kees> jono: ah-ha, easy fix.
[19:38] <mdeslaur> jono: are we doing donuts instead? :)
[19:38]  * mdeslaur likes donuts
[19:38] <jdstrand> kees: you dropped lxc off the list? I was already looking forward to your demo :P
[19:38] <jono> mdeslaur, lol
[19:39] <kees> jdstrand: oh, er, it wasn't clear what we'd accomplish
[19:39] <kees> (with a session)
[19:39]  * jdstrand was kidding
[19:39] <kees> oh! *whew*
[19:39] <nxvl> yeah, i hope we have lot's of sugar and cokes to survive trough the week
[19:39] <nxvl> :P
[19:39] <jdstrand> :)
[19:39] <kees> any reason not to claim/assign sessions now?  that way we'll be totally done with this stage of planning
[19:40] <jono> kees, are you talking about scheduling sessions at UDS?
[19:40] <jdstrand> I guess not-- though there are also blueprints that need to be discussed
[19:40] <kees> jono: basically, yes.  we were reviewing ideas that we could make sessions out of.
[19:40] <nxvl> mmmm
[19:40]  * nxvl missed the catch-all session
[19:41] <nxvl> kees: what's that one about?
[19:41] <kees> I can take LowerProcessCapabilities, Notification of system BIOS failures, Catch-all, and screen lock does not work ?
[19:41] <nxvl> it smells like chat & e-mail :P
[19:41] <jono> kees, cool - when you are done and have registered the blueprints, let me know and I will approve them
[19:41] <kees> nxvl: it's about anything in general.  random idea, anything people want to see, etc
[19:41] <jono> kees, and then Robbie can schedule them for you on the foundations track
[19:41] <nxvl> ohh
[19:41] <jdstrand> I can take apparmor abstractions cleanup and apparmor usability in Ubuntu
[19:41] <nxvl> yeah, my nose was right :P
[19:41] <kees> jono: ok, excellent
[19:42]  * jdstrand feels like he is missing something
[19:42] <jiohdi> anyone here from the recent florida birthday bash?
[19:42] <nxvl> btw, i think a couple of general "Roundtable" sessions will be a good idea
[19:42] <jdstrand> jiohdi: we are in a meeting right now
[19:42] <jdstrand> ubuntu-security
[19:43] <nxvl> jiohdi: try #ubuntu-fl
[19:43] <jiohdi> thanks
[19:43] <RoAkSoAx> jiohdi, #ubuntu-us-fl
[19:43] <kees> nxvl: hrm, normally we can't fill the roundtable meetings.  :P  the catch-all tends to serve that purpose
[19:49] <nxvl> that reminds me
[19:49] <nxvl> i haven't had lunch still
[19:49] <nxvl> so, meeting adjourned?
[19:49] <nxvl> (or however it's spelled)
[19:50] <kees> aaah 3rd person!
[19:50] <kees> yeah, meeting done, thanks everyone!
[19:51] <zul> mmmm....timbits
[23:25] <Pretto> emma:  :D