[13:52] <pitti> hello everyone
[13:52] <Hobbsee> pitti!
[13:54] <mvo> hey pitti
[13:57] <Riddell> hi
[13:57] <pedro_> hello
[13:59] <pitti> hm, I can't find Ted online, is he on vac?
[13:59] <MacSlow> hi
[13:59] <MacSlow> hi seb128
[13:59] <MacSlow> hi mvo
[13:59] <mvo> hey MacSlow
[13:59] <MacSlow> hi Riddell, Hobbsee
[13:59] <seb128> hello
[14:00]  * Hobbsee waves to MacSlow
[14:00] <pitti> hm, Ted is not on vac
[14:00] <kwwii> hi
[14:00] <MacSlow> hi kwwii
[14:00]  * pitti phones
[14:00] <MacSlow> no idea what's with ted
[14:01] <MacSlow> ah :)
[14:01] <pitti> ted2: ah, that's *the* Ted?
[14:01] <ted2> pitti: good morning :)
[14:01] <pitti> ah :)
[14:02] <pitti> ted2: welcome
[14:02] <mvo> hello ted2
[14:02] <pitti> ted2: it's your evil twin brother!
[14:02] <pitti> https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-05-08 FYI
[14:02] <ted2> Yeah, I'm trying to use Empathy to learn it's flaws... it seems that "tedg" and "ted1" are among the flaws :)
[14:03] <pitti> I didn't see anyone else posting agenda items; did I miss any?
[14:03] <pitti> did everyone have a chance to review their assigned bugs on https://edge.launchpad.net/ubuntu/+milestone/ubuntu-8.04.1 ? Any problems with those?
[14:04] <pitti> we should solve them soon, we won't have any time in Prague, and towards the end of June we want to start building hardy.1 CD candidates
[14:04] <seb128> doh, that's short
[14:05]  * MacSlow feels like an idiot working on integrating mipmapping in clutter only to see that yesterday something from elsewhere was pushed upstream
[14:05] <pitti> seb128: well, we still have about six weeks to hammer at it
[14:05] <mvo> pitti: when do we get daily CDs again?
[14:06] <mvo> (for hardy .1)
[14:06] <MacSlow> so much for wasting time... especially nobody from O-Hand told me they are working internally on it
[14:06] <pitti> mvo: unsure; do you think they'd be useful already?
[14:06] <pitti> mvo: I don't think they are hard to set up, need to talk to Colin
[14:06] <mvo> for me at least yes
[14:06] <pitti> ACTION: pitti to set up daily hardy CDs with Colin
[14:06] <mvo> I have a SRU open with the cdromupgrade script on the server cd
[14:06] <Riddell> 18:00 < slangasek> evand: no ETA yet on hardy CD builds
[14:06] <ted2> MacSlow: That sucks, any clue on why?  Seems like something they'd be against also.
[14:06] <pitti> mvo: right, we also have some installer fixes
[14:07] <pitti> MacSlow: who's O-Hand?
[14:07] <mvo> thanks pitti
[14:07] <MacSlow> ted2, no idea... especially since I blogged about it and chatted a bit with Matthew Allum (Opened Hand boss) about the API
[14:07] <MacSlow> pitti, that's "Opened Hand" the upstream of clutter
[14:07] <pitti> ah, ok
[14:08] <ted2> They also do "dates" and a couple other embedded (sorry mobile) things.
[14:08] <Hobbsee> pitti: enomootbot?
[14:08] <pitti> Hobbsee: don't worry, just convention; I'll trawl through the log anyway afterwards
[14:09] <Hobbsee> pitti: ahhh
[14:09] <ted2> MacSlow: So I guess at o-hand the right hand doesn't talk to the left? :)
[14:09] <MacSlow> ted2, while the pure GL-side of things was easy for me making a patch out of this against clutter wasn't that easy... spent several days on this... then cogl (internal OpenGL-abstraction of clutter changed) had to move stuff over...
[14:10] <mvo> how do you feel about upgrade failures (maintainer scripts) in universe packages? I would like to still milestone those on the grounds that even they are universe they may break upgrades and give a bad user experience - how is your feeling about this?
[14:10] <MacSlow> ted2, no clue... but I feel misable trying to work upstream (thus neglecting direct work on the face-browser) just to see that I wasted about two weeks for nothing
[14:10] <pitti> mvo: yeah, that makes sense
[14:11] <pitti> mvo: I recently watched a friend doing a dist-upgrade which was completely wrecked due to python-numpy failing to install
[14:11] <ted2> MacSlow: Yeah, for sure.  Are there going to be any o-hand folks at FOSSCamp/UDS?
[14:11] <pitti> mvo: btw, on that occasion u-m immediately crashed/aborted, so that the system was left in a 80% upgraded state
[14:11] <MacSlow> ted2, yes... Matthew will be there... I will bring that up when talking with thim
[14:11] <pitti> mvo: but there was no possibility to finish the upgrade, nor do the cleanup, etc.
[14:11] <mvo> pitti: was that a server upgrade?
[14:11] <Hobbsee> mvo: how many are we talking about?
[14:11] <mvo> pitti: for the desktop it should continue
[14:11] <pitti> mvo: no, standard ubuntnu desktop
[14:12] <mvo> Hobbsee: so far not that many
[14:12] <pitti> mvo: it didn't :/, it just went away after the failure
[14:12] <mvo> pitti: oh? it skips the cleanup, but it should go on, could you ask him to sent me the logs?
[14:12] <Hobbsee> mvo: as in, 5, 10, 20, 50?  And how long do you think i'tll take to find out the rest?
[14:12] <mvo> pitti: went-away == crashed
[14:12] <mvo> Hobbsee: in the range of 10-20 I would say
[14:12] <pitti> MacSlow: argh, that sucks; communication problem? i. e. you didn't know about each other working on the same ting?
[14:13] <MacSlow> pitti, no... I blogged about that I missed mipmapping in clutter... showed that I had the needed GL-stuff already done and planned to write a patch for clutter
[14:14] <MacSlow> pitti, I also emailed the clutter-ml regarding how to go about exposing it in the clutter-API
[14:14] <pitti> mvo: sure, I'll ask him
[14:14] <MacSlow> pitti, so they cannot have missed that I was working on it
[14:14] <pitti> mvo: /var/log/<where>?
[14:14] <pitti> MacSlow: they read your blog?
[14:14] <mvo> pitti: /var/log/dist-upgrade/* please
[14:15] <pitti> mvo: TODOed
[14:15] <mvo> thanks again pitti
[14:15] <pitti> MacSlow: oh, nevermind, ML
[14:15] <MacSlow> pitti, well I pointed them to it and it gets  to p.g.o and p.u.c so there's plenty of exposure
[14:16] <Hobbsee> mvo: so easy enough to hit in one go, if we have a list.  *nod*
[14:17] <pitti> MacSlow: how do you think can we avoid that in the future? they didn't take you serious enough or so?
[14:17] <mvo> Hobbsee: some of the failure seem to be a bit icky (haskell for example)
[14:17] <pitti> mvo: oh, we still need to finish the /etc diff for dapper->hardy, too
[14:18] <MacSlow> pitti, I'll write Matthew an email and ask him
[14:18] <pitti> MacSlow: can you talk to them again and ask him how to avoid that in the future?
[14:18] <pitti> ah, good
[14:19] <pitti> ok, so I went throug the unassigned hardy.1 milestone list and picked out a few which look like falling into our team
[14:19] <pitti> shall we just quickly go through them?
[14:19] <pitti> https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/206998
[14:19] <seb128> sure
[14:19] <seb128> iz mvo bog ;-)
[14:19] <pitti> it's not entirely clear whether it's a compiz or an xrandr bug
[14:20] <seb128> I get the issue too
[14:20] <mvo> pitti: right, I worked a bit trying to eliminating some of the noise, I will run another one soonish
[14:20] <pitti> mvo: do you think you can care for coordinating this between the X and compiz upstreams?
[14:20] <seb128> the cursor can go in the area, clicking work etc
[14:20] <pitti> mvo: etc diff> me too
[14:20] <seb128> but compiz consider the vertical line as the viewport limit
[14:20] <pitti> ah, right, I think I noticed that, too
[14:20] <seb128> so I would say it's a compiz bug
[14:20] <mvo> pitti: I can look into it yes
[14:20] <pitti> thanks
[14:21] <pitti> bug 213081
[14:21] <pitti> cupsish, I'll take that one
[14:21]  * mvo looks at till
[14:21] <pitti> bug 150187
[14:22] <seb128> I don't think this one will be fixed easily
[14:22] <pitti> mvo: I have a much better connection to upstream nowadays, I'll manage :)
[14:22] <seb128> it seems to be cairo or poppler
[14:22] <pitti> seb128: right, that seems like a tricky poppler bug, I guess?
[14:22] <pitti> seb128: is that actually a regression from gutsy?
[14:22] <seb128> no it's not
[14:22] <seb128> gutsy had the issue
[14:22] <seb128> it might be a regression from dapper
[14:23] <pitti> I mean, the bug in that generality seems weird to me
[14:23] <seb128> where we were using the splash poppler version and not cairo
[14:23] <pitti> I print out PDFs very often (well, my wife does), and they look fine
[14:23] <pitti> so it affects only some?
[14:23] <seb128> right
[14:23] <seb128> you can assign it to me
[14:23] <MacSlow> yeah... I never saw issues with PDFs too
[14:23] <mvo> they generally look ok for me too (also I don't pint that much)
[14:23] <seb128> but I don't guaranty it'll be fixed for hardy
[14:24] <seb128> I'll try to talk with upstream about it
[14:24] <pitti> seb128: no, I'd just like milestoned bugs to have someone who is looking into it
[14:24] <seb128> I'm looking at this one
[14:24] <pitti> seb128: if it ends up being unmilestoned because we can't do anything, that's fine
[14:24] <seb128> ok
[14:24] <pitti> seb128: can you assign it to you? thx
[14:24] <pitti> bug 184238
[14:24] <pitti> *violently agreeing*
[14:24] <seb128> pitti: done
[14:25] <pitti> oh, apparently fixed upstream!
[14:25] <seb128> pitti: mvo has been assigned to the sponsor request before hardy, not sure why he didn't upload though
[14:25] <seb128> pitti: I got jdong to submit the debdiff before hardy, it's just waiting for sponsoring
[14:25]  * seb128 looks at mvo
[14:25] <mvo> *cough*
[14:25] <mvo> ...
[14:25] <pitti> ah
[14:25] <pitti> mvo: can you take this? or shall I?
[14:26] <mvo> sure, happy to take it now
[14:26] <ted2> seb128, pitti: It might also be the printer.  The cairo ouput changed to the point of pushing some printers in the new release.
[14:26] <mvo> sorry - I must have overlooked it before the release
[14:26] <seb128> ted2: that's not a new bug, it was already there in gutsy
[14:26] <pitti> mvo: thanks, assigned now
[14:26] <seb128> mvo: that's alright, that was a string change so tricky, but now let plenty of time to translators to do a good work
[14:27] <MacSlow> hi OgMaciel
[14:27] <pitti> bug 208097
[14:27] <pitti> darn, too late to remove the package from hardy final now
[14:27] <Hobbsee> pitti: even if it doesn't build?
[14:27] <OgMaciel> hey there MacSlow
[14:27] <pitti> IMHO we should just remove it from intrepid and ignore hardy; any objection?
[14:27] <seb128> +1
[14:27] <pitti> Hobbsee: hardy is frozen, we cannot remove stuff from it
[14:27] <pitti> ok, I'll deal with it
[14:28] <Hobbsee> pitti: oh, i thought you could - as in, that there were reasons why it wasn't a good idea, rather than a technical limitation against it
[14:28] <mvo> +1
[14:28] <pitti> for reasons like that I like milestoned bugs to have a clear assignee
[14:28] <pitti> Hobbsee: that's pretty much the case, yes
[14:29] <pitti> (I believe, anyway -- who knows how soyuz breaks if someone woudl actually attempt it :-P)
[14:29] <pitti> bug 204770
[14:29] <Hobbsee> pitti: on second thoughts, i suspect it's a *very* good idea not to try.
[14:29] <pitti> seb128: you commented on this, do you have a quick summary?
[14:29] <pitti> Hobbsee: *chuckle*
[14:29] <seb128> pitti: gtkfileselector has a search item which uses tracker
[14:30] <pitti> ooh, that one again
[14:30] <Hobbsee> pitti: :)
[14:30] <pitti> right
[14:30] <seb128> and libtracker api for "is tracker running" autostart this one
[14:30] <seb128> which is completly broken if you ask me
[14:30] <pitti> sudo time-admin or other program, and there goes tracker driving you mad?
[14:30] <seb128> yes, but tracker is disabled in hardy so I'm not sure why that's happening
[14:30] <seb128> I'll consider dropping the gtk tracker support if the tracker guys don't fix the issue
[14:31] <pitti> it doesn't just start tracker, but also gvfs daemons, etc., doesn't it?
[14:31] <pitti> seb128: could we just make the file selector not triggering autostart?
[14:31] <pitti> so that people coudl still manually enable tracker, but it wouldn't start magically any more?
[14:31] <seb128> yeah, I was considering that as well
[14:32] <pitti> not sure whether it's possible
[14:32] <seb128> well, just stop installing /usr/share/dbus-1/services/tracker.service
[14:32] <pitti> seb128: the gdm task is bogus, right?
[14:32] <seb128> easy enough
[14:32] <seb128> pitti: yes, that's an upstream one
[14:33] <pitti> seb128: ah, but that's just the trigger, not the actual bug, right?
[14:33] <seb128> pitti: I think we should just remove the dbus service file, this way tracker is started by the session or the user or not
[14:33] <seb128> I don't like the "is autostarted when random program check if tracker is running"
[14:33] <pitti> seb128: that sounds reasonable
[14:33] <seb128> right
[14:34] <pitti> seb128: ok, let's discuss this offline
[14:34] <pitti> do we have someone inclined to bluetooth in the team?
[14:34] <seb128> ok
[14:34] <pitti> bug 220269
[14:34] <seb128> I would say to ask the mobile team
[14:35] <pitti> ok, I'll do that
[14:35] <seb128> or mithrandir
[14:36] <pitti> mvo: bug 221920 looks like a simple blacklist addition to compiz
[14:36] <mvo> pitti: yes
[14:36] <pitti> seb128: yes, I mean 'ask the mobile team/Tollef'
[14:36] <pitti> mvo: can I hand that to you?
[14:36] <mvo> sure
[14:37] <pitti> bug 211388
[14:38] <pitti> that sounds pittiish
[14:38] <seb128> ;-)
[14:38] <pitti> (unless someone jumps at it :) )
[14:38] <pitti> heh, I reported it
[14:38] <pitti> fallout from the /etc diff trawling
[14:39] <pitti> mvo: btw, any chance we could have an updated /etc/ diff for dapper->hardy current?
[14:39] <pitti> mvo: we fixed some issues in the last weeks
[14:39] <pitti> bug 209520
[14:39] <pitti> argh the suck argh
[14:39] <pitti> that sounds like gvfs fallout
[14:40] <mvo> pitti: yes, I worked on the code to remove some noise and plan to rerun it soonish
[14:40] <pitti> ACTION: mvo to produce an up to date dapper -> hardy-proposed /etc/ upgrade diff
[14:40] <seb128> pitti: that's part of the giant gvfs smb mess we have
[14:40]  * pitti hugs mvo, thanks
[14:41] <seb128> and the bug title is not accurate
[14:41] <pitti> seb128: who's on that? Steve and you, I suppose?
[14:41] <seb128> yes, for some value of being on it
[14:41] <pitti> seb128: btw, it seems that SMB connection icons on your desktop disappear on upgrade; is that already known as well?
[14:41] <seb128> but I really need to look at those for 8.04.1 and steve offer to help on those too
[14:41] <seb128> pitti: it's in the milestone list somewhere, search for gnomevfs there
[14:42] <seb128> or gnome-vfs
[14:42] <pitti> seb128: ah, thanks
[14:43] <pitti> hm, bug 186049
[14:43] <pitti> beagle search? galago? that doesn't sound very mainish to me?
[14:43] <seb128> no it's not
[14:44] <pitti> ok, so let's not worry about assigning it now
[14:44] <pitti> that's the list for our team as far as I can see
[14:44] <pitti> anything else?
[14:45] <seb128> not from me
[14:45] <kwwii> nope
[14:45] <pitti> I'll take the task of finding/fixing some more /etc upgrade bugs
[14:45] <pitti> mvo already has his hands full, according to the milestone list
[14:45] <Riddell> pitti: I'll probably have a load of main inclusion reports
[14:45] <Riddell> needed for kde 4
[14:46] <pitti> Riddell: ah, for intrepid?
[14:46] <Riddell> pitti: yes
[14:46] <Riddell> just to warn you (or doko)
[14:46] <pitti> Riddell: will intrepid drop kde3?
[14:46] <Riddell> pitti: as much as possible yes
[14:46] <pitti> Riddell: right, I'm all for a package review, but we usually don't do MIRs for version upgrades?
[14:46] <pitti> (which, in a way, that is)
[14:46] <doko> Riddell: warn about what?
[14:46] <Riddell> pitti: right but there's new dependencies
[14:47] <pitti> e. g. I did not submit MIRs for a new postgresql release either, etc.
[14:47] <pitti> Riddell: ah; those should have MIR bugs, yes
[14:47] <Riddell> pitti: and some new kde modules, which may or may not count as new packages
[14:47] <pitti> but I don't think that we need an MIR for e. g. kdelibs -> kdelibs-kde4
[14:48] <Riddell> doko: that I'll need various MIRs for kde 4
[14:48] <pitti> Riddell: sure; let's not waste our time with busywork for the standard components which had a KDE 3 counterpart, and the rest gets MIR bugs; do you think that's reasonable?
[14:48]  * mvo_ is sorry - disconnected
[14:48] <pitti> ... so that we can hand off the remaining 3242 bugs to mvo
[14:48] <pitti> mvo_: oh, welcome back!
[14:48] <seb128> ;-)
[14:48] <Riddell> pitti: yes, although it's not always clear what had a kde 3 counterpart
[14:48] <Riddell> e.g. the new kdepim server
[14:49] <pitti> Riddell: well, common sense, I think
[14:49] <Riddell> yep
[14:49] <pitti> Riddell: if you introduce new networking libraries or ffmpeg, we better MIR them :)
[14:49] <pitti> good, anything else we should talk about?
[14:50] <seb128> pitti: any news about fixing the retracers?
[14:50] <pitti> ugh, that
[14:50] <seb128> pitti: we could use debug stacktraces for some crashers
[14:50] <seb128> and autoduplicates closing too
[14:50] <pitti> ok, so tomorrow will probably keep me busy with my archive day and SRU
[14:51] <pitti> I'll try to reproduce these problems with fakechroot on my box this afternoon
[14:51] <pitti> I have no idea why it suddenly falled apart so badly :(
[14:51] <pitti> s/falled/fell/
[14:52] <pitti> ACTION: pitti to look into fakechroot problems for apport retracers
[14:52] <pitti> AOB?
[14:53] <pitti> ok, then let's all give seb128 a big hug to spend his free day with us
[14:53] <pitti> and enjoy having an ice cream now!
[14:54] <Keybuk> pitti: thanks very much!
[14:54] <seb128> ice cream yeah ;-)
[14:54] <pitti> Riddell: hm, speaking about it, surprisingly few KDE bugs on the milestone list; does it just work? :-)
[14:54] <pitti> ah, hi Keybuk
[14:54] <cjwatson> pitti: all the code is there for hardy CDs to be enabled; somebody just needs to start running and testing them
[14:55] <cjwatson> DIST=hardy cron.daily-live etc.
[14:55] <pitti> cjwatson: oh, yay; they'll automatically use -proposed?
[14:55] <cjwatson> "automatically" in the sense that I've already told them to do so, yes :-)
[14:55] <pitti> right, that's what I meant cjwatson-proactive-automatically
[14:55] <pitti> cjwatson: awesome, thanks!
[14:55] <pitti> I'll set up the cronjobs then
[14:56] <pitti> thanks everyone!
[14:56] <Riddell> pitti: well KDE 3.5 is pretty stable after three releases
[14:56] <pitti> Riddell: lucky you! :)
[14:57] <pitti> Riddell: kde 3.5.10 should *so much* be ported to gvfs *duck*
[14:57] <Keybuk> thought of the day ...
[14:57] <Keybuk> did we decide whether to do Kubuntu 8.04.1 or not?
[14:57] <pitti> oh, is that decision our's?
[14:57] <Keybuk> do we _want_ to?
[14:57] <Keybuk> Riddell: ?
[14:57] <cjwatson> marilize was asking me about that (by implication); I dodged the question because I wasn't sure :-)
[14:58] <cjwatson> I think what I said was that I saw no reason not to release CDs for anything that gets suitably tested
[14:58] <pitti> my feeling, too ^
[14:58] <Riddell> Keybuk: I don't think it's been discussed
[14:58] <Keybuk> Riddell: do you think it's a good idea?
[14:58] <cjwatson> there will probably be changes that affect Kubuntu, even if there's little in the way of specific work on KDE
[14:58] <Keybuk> Riddell: do you think we'll get enough test coverage for it?
[14:58] <cjwatson> i.e. kernel and platform changes
[14:58] <cjwatson> s/probably/definitely/
[14:59] <Keybuk> kubuntu people will get the large -updates collection the first time they install updates anyway
[14:59] <Riddell> Keybuk: yes I think we can get test coverage, it seems like a good idea to me
[14:59]  * cjwatson would rather take the opportunity to reduce mirror load, personally
[14:59] <cjwatson> by shipping roll-ups of updates
[15:00] <Keybuk> just the Kubuntu CD?
[15:00] <Keybuk> or the KDE 4 remix as well?
[15:01] <Riddell> there's not been any kde 4 updates (unless we move 4.0.4 to -updates)
[15:01] <cjwatson> Riddell: same comment re kernel+platform changes
[15:01] <Riddell> yep
[15:02] <Riddell> so if we can get it tested, may as well
[15:04] <pitti> Riddell: ok, so I'll set up daily CDs for kubuntu and k4buntu, too?
[15:04] <Riddell> pitti: please do
[15:11] <cjwatson> k4buntu> :-)
[21:01] <kees> #startmeeting
[21:01] <kees> err
[21:01] <kees> no mootbot?
[21:01] <kees> well, I can paste logs manually.  :)
[21:01] <mra> heh
[21:02] <kees> so, who all is here for the security team meeting?
[21:02] <propagandist> heyya ;o]
[21:02] <mra> I am
[21:02] <jdstrand> o/
[21:02] <kees> alright, let's get started.  Current Agenda is here:
[21:03] <kees> https://wiki.ubuntu.com/SecurityTeam/Meeting
[21:03] <kees> I don't see emgent, so I'll dropped the whitehat topic for now.
[21:03] <kees> [topic] CVE review
[21:04] <kees> we've got a bunch of things cooking
[21:04] <kees> any CVEs anyone is interested in working on?
[21:05] <jdstrand> I might suggest https://bugs.launchpad.net/ubuntu/+source/speex/+bug/218652
[21:05] <jdstrand> I am handling xine-lib, gstreamer, speex and vorbis-tools, but there are a lot of universe packages that need it
[21:06] <kees> yeah, it's a pretty long list.
[21:06] <jdstrand> it's an easy patch
[21:06] <jdstrand> but a lot of packages
[21:07] <kees> also on the horizon is a kernel update, probably early next week.  it's being built currently.
[21:07] <kees> in an effort to increase CVE visibility, jdstrand and I have built a web area that is exported regularly from the ubuntu-cve-tracker bzr tree:
[21:07] <kees> http://people.ubuntu.com/~ubuntu-security/cve/open.html
[21:08] <jdstrand> kees: do you want to advertise that link, since it's a symlink?
[21:08] <kees> (and some graphs as well: http://people.ubuntu.com/~ubuntu-security/cve/open-cves.png)
[21:08] <jdstrand> (I don't care, but I thought since it isn't official yet, we could use the real one)
[21:09] <kees> jdstrand: an index.html needs to be built up, but it's a reasonable starting point for the moment.
[21:09] <jdstrand> fair enough
[21:09] <mra> it looks good so far
[21:10] <kees> any help with open CVEs (especially testing) is, of course, greatly appreciated.  :)
[21:10] <jdstrand> absolutely!
[21:11] <jdstrand> :)
[21:11] <kees> okay, moving on...
[21:11] <kees> [topic] SELinux status
[21:12] <kees> propagandist: how goes selinux in the final hardy release?  I haven't seen many complaints.
[21:12] <propagandist> kees: other than a few bugs, its going well
[21:13] <mra> is there any way to see how many people have switched over to it?
[21:13] <propagandist> That would be interesting to know...
[21:14] <jdstrand> popularity-contest could give a relative idea
[21:14] <jdstrand> but I don't know how many people use that
[21:14] <kees> http://popcon.ubuntu.com/
[21:14] <kees> I'm not sure how to examine just hardy, though
[21:16] <kees> 42 people are using it says popcon.  :)
[21:16] <kees> so, I suspect that's not a useful number.
[21:16] <mra> that's pretty good for how new it is
[21:16] <kees> propagandist: any specific plans for intrepid?
[21:17] <propagandist> kees: some additional policies for maybe apache and xguest (just suggestions) and some work to sync up with debian as much as possible
[21:18] <kees> propagandist: sounds good.
[21:18] <propagandist> I'm open to suggestions as well
[21:18] <jdstrand> propagandist: I'm surious as to what you'll come up with to contain apache, especially wrt virtual hosts, php and perl
[21:18] <jdstrand> s/surious/curious/
[21:19] <kirkland> kees: sorry, missed the roll call, belated, "here"
[21:19] <kees> propagandist: btw, is anyone from tresys coming to UDS?
[21:19] <kees> heya kirkland, no worries.  :)
[21:19] <propagandist> jdstrand: ;o] me too... I'll be using the current refpol as a starting point, but after that we'll see
[21:19] <propagandist> jdstrand: I'll try to keep everyone updated on the plan for that
[21:20] <propagandist> kees: I don't think so. It's in Prague yes?
[21:20] <jdstrand> propagandist: I mention that, because I was hoping at some point to do the equivalent with apparmor, but the way apache is packaged now doesn't really help with profiling :?
[21:20] <jdstrand> mathiaz and I started a conversation on it, but we may talk about it more at UDS
[21:21] <kees> propagandist: yea, prague
[21:21] <jdstrand> propagandist: it might be a several release process to get apache in shape-- especially since we would want to get Debian involved
[21:21] <propagandist> jdstrand: true true
[21:22] <kees> okay, moving on...
[21:23] <kees> [topic] hardy review
[21:23] <kees> while CVEs should really cover stuff in hardy, is there anything people wanted to talk about relating to the release?
[21:23] <kees> anything to do better/different for intrepid, etc?
[21:23] <SEJeff> Blog about the proactive security work
[21:24] <SEJeff> We have smack and we also have capabilities support in the kernel
[21:24] <SEJeff> Why not work on cutting down on suid root binaries?
[21:24] <mra> that one can be tough because you can quickly cause usability problems
[21:24] <kees> SEJeff: I've tended to blob about the things I'm directly involved in.  are those other two areas ones you could blog about?
[21:24] <SEJeff> I started work on this awhile back: https://wiki.ubuntu.com/Security/Investigation/Setuid
[21:25] <kees> SEJeff: it looks like a pretty short list so far, which is good.
[21:25] <SEJeff> kees, If we start writing patches to make some of those utilities only check the caps instead of the uid, would the patches get accepted into ubuntu if it takes awhile for upstream to adopt?
[21:26] <kees> SEJeff: yup -- as long as there was no loss in functionality, I'd be happy to see them in Ubuntu.
[21:26] <jdstrand> SEJeff: seeing that list, cupsys shouldn't be as big of a concern-- it is protected via apparmor by default (pitti purposely dropped the extensive derooting patch IIRC because of the use of apparmor)
[21:26] <SEJeff> Here's the email about this I initially sent: https://lists.ubuntu.com/archives/ubuntu-hardened/2007-October/000227.html
[21:26] <kees> I'd prefer they get passed up through Debian and upstream too, of course.
[21:26] <SEJeff> Of course
[21:27] <SEJeff> THats the goal, but gnu utilities maintainers are notorious for taking a LONG time for stuff like that. It took ages for the selinux folks to get the -Z options into upstream
[21:28] <kees> yeah, understood, but having a LP bug linked to the upstream bug with the patch will go a long way towards being able to show where things stand for each package.
[21:28] <kees> (and those LP bugs could be linked to from the wiki page)
[21:28] <SEJeff> I also still owe you guys a version of ubuntu-cve-tracker that supports tablesorting. tablekit was just too heavyweight because of prototype.js
[21:28] <SEJeff> I got it working and didn't like it so dropped it
[21:28] <kees> heh
[21:29] <jdstrand> SEJeff: oh yea-- I reworked the table slightly-- shouldn't affect too much based on what I saw of your previous work
[21:29] <kees> I think we've gotten into intrepid so...
[21:29] <kees> [topic] intrepid
[21:29] <jdstrand> s/yea/yeah/
[21:30] <kees> besides working on what interests people from the roadmap (and/or adding more things to the roadmap), there's at least one area I'd like to cover here: hardened compiler options
[21:30] <kees> the testing done with the hardening-wrapper was a success, and as a result, the majority of its features were put directly into the gcc defaults
[21:31] <kees> due to the need for a central place to document this, I wrote up: https://wiki.ubuntu.com/CompilerFlags
[21:31] <jdstrand> \o/
[21:31] <jdstrand> *awesome* work and tenacity kees! :)
[21:31] <kees> *whew* thanks.  I have to thank infinity and doko as well.  :)
[21:31] <kees> and of course, everyone else who did testing of the wrapper
[21:32] <SEJeff> Thats a huge win
[21:32] <jdstrand> yea infinity and doko !
[21:32] <kees> -D_FORTIFY_SOURCE=2 is by far going to be the biggest glitch-causer, but the result will be better code overall
[21:32] <kees> now, as far as PIE, there were many good concerns raised, so we'll discuss it further at UDS.  I'm pushing for PIE-by-default on amd64.
[21:33] <jdstrand> it's for the mergers to fix right? ;P
[21:33] <SEJeff> Ubuntu needs a page just like this: http://fedoraproject.org/wiki/Security/Features that is "marketed"
[21:33] <kees> jdstrand: heh.  well, and anyone else watching the automated import build failures...
[21:33] <kees> SEJeff: absolutely.  I actually have something a little like it, but it was rather ... bare ... until recently.
[21:33] <jdstrand> SEJeff: http://www.ubuntu.com/products/whatisubuntu/serveredition/features/security
[21:34] <kees> the URL from jdstrand is a result of some of that "marketing" work
[21:34] <kees> I want a matrix, though, too.
[21:34] <jdstrand> nijaba wrote a lot of that
[21:34]  * jdstrand nods
[21:35] <kees> another area of work I'd like to see is on getting PIE-by-default for various daemon's builds.  it's the same list that was put together before, but the goal here would be to make it part of the build system, and to avoid the need for a wrapper.
[21:36] <kees> specifically: https://wiki.ubuntu.com/Security/HardeningWrapper#targets
[21:36] <jdstrand> kees: you mean debian/rules?
[21:36] <kees> jdstrand: yeah.
[21:36] <kees> there is some example of how to do this in openssh, and is rather painful.
[21:36] <jdstrand> a lot of those are already quite different from Debian, so that shouldn't be a big deal
[21:37] <kees> while the wrapper is an easy way to test that the build and execution would work, I'd like to get a common "configure" macro or something to do it.
[21:37] <jdstrand> (just the act of carrying the diff that is)
[21:37]  * kees nods
[21:37] <jdstrand> kees: what about dh_hardening
[21:37] <jdstrand> ?
[21:37] <kees> hunh.  probably more of a makefile include, but yeah, that's a great idea.
[21:38] <kees> while not hugely popular yet, 10 debian source packages are using the hardening wrapper -- including quagga.
[21:40] <jdstrand> IIRC, there seems to be quite a bit of interest though
[21:40] <kees> yeah, even those few packages really put it through its paces.
[21:41] <kees> wrung out a few odd-ball bugs
[21:41] <kees> anyway...
[21:41] <jdstrand> my main focus in terms of intrepid development is more work on ufw
[21:41] <kees> we'll have more of an idea about the 'official' focus on security work after UDS.
[21:41] <jdstrand> specifically package integration-- which is one of the topics at UDS
[21:42] <SEJeff> Zelut has been working on ufw support for kickseed
[21:42] <kees> I'm excited about that.  It should be very interesting.  :)
[21:42] <SEJeff> indeed
[21:42] <SEJeff> But for it to get into debian, that will probably have to use iptables
[21:42] <jdstrand> SEJeff: yep-- been talking to him a bit about it
[21:42] <jdstrand> SEJeff: ? ufw is just a front-end for iptables
[21:42] <SEJeff> We'll work more on kickseed later on.
[21:43] <jdstrand> oh, the kickseed part
[21:43] <SEJeff> jdstrand, yes, and kickseed is in debian-installer
[21:43] <SEJeff> but is ufw in debian by default? not so much
[21:43]  * jdstrand doesn't think it's in Debian at *all* yet...
[21:44] <kees> jdstrand: couldn't hurt to find a DD (*cough*) to sponsor it...
[21:44] <jdstrand> heh
[21:44] <jdstrand> it's on my todo list
[21:44] <kees> :)
[21:45] <jdstrand> I think I'd like to separate out debian/ from the bzr branch, but need to think about it some more
[21:45] <kees> anything else to cover?  anything to bring up at UDS that isn't already in the roadmap?
[21:45] <jdstrand> (I could look at what lamont does with bind9 for inspiration)
[21:45] <SEJeff> kees, Focus on proactive security more. You've been doing a heck of a job so far. Don't stop
[21:46] <kees> thanks; I'd like to do more.  :)
[21:46] <jdstrand> SEJeff: that's another thing I hope to do-- add some more default enforcing apparmor profiles
[21:47] <kees> [topic] next meeting
[21:47] <kees> two weeks would be UDS.
[21:47] <SEJeff> kees, Speaking of that. 1 last thing from me
[21:48] <kees> how about we push to the 29th, so we can review UDS discussions?
[21:48] <kees> SEJeff: sure
[21:48] <SEJeff> Seeing as how Apparmor getting upstream still is stalled... and Smack is a MAC framework "aligning with Ubuntu's use cases"
[21:48] <SEJeff> Why not look into migrating to SMACK
[21:48] <SEJeff> It might seem radical, but you don't get the weird errors with things like the btrfs bug I sent to the list
[21:48] <jdstrand> I'm on vacation on the 29th
[21:49] <jdstrand> (that whole week actually)
[21:49] <kees> SEJeff: true, it's worth looking into.  the main benefit with AA currently is the help we're getting from AA upstream with bugs, etc.
[21:49] <SEJeff> Sure, because you are 1 of 2 users
[21:49]  * kees nods
[21:50] <SEJeff> SMACK upstream would have similar responses /me thinks
[21:50] <kees> agreed.  there's a price to switching, but intrepid would certainly be a good time to examine that.
[21:50] <SEJeff> ANd smack is upstream, so it causes less problems than anything out of tree
[21:50] <mra> Casey is pretty good, the only real drawback is there is only one of him
[21:51] <SEJeff> mra, and Crispin Cowan works for Microsoft now.
[21:51] <mra> yes, but he hasn't been the one pushing patches for a while now
[21:51] <kees> SuSE still has developers on AA, so I'm not freaking out just yet.
[21:51] <mra> I'm just saying AA has less to worry about from freak bus accidents
[21:52] <SEJeff> kees, They have commercial support contracts in place. Of course they will support it
[21:52] <kees> but I'm quite glad to have the tresys folks working with Ubuntu too.  :)
[21:52] <propagandist> What about SELinux (perhaps stating the obvious here)?
[21:52] <propagandist> kees: :o)
[21:53] <kees> propagandist: yup, that would be on the list too.  I've personally been more interested in "choice", but obviously we needed to pick something originally to run with.
[21:53] <SEJeff> If I ever get time (maybe maybe not) I'll work on setroubleshootd
[21:53] <jdstrand> propagandist: I am super excited about the selinux work that's happened so far
[21:53] <propagandist> SEJeff: that would be awsome, I think joejaxx had a working/almost working package of it
[21:53] <jdstrand> :)
[21:54] <SEJeff> noted
[21:54] <SEJeff> What about polgen-gui?
[21:54] <SEJeff> ANyone working on that?
[21:54] <kees> okay, so proposed meeting time: 2000 UTC, here, June 5th.
[21:54] <SEJeff> You give them that and people can't say SELinux is hard anymore
[21:54] <jdstrand> kees: wfm
[21:54] <propagandist> kees: sounds good to me
[21:55] <propagandist> SEJeff: ;o]
[21:55] <mra> kees: that works
[21:55] <propagandist> SEJeff: I don't think anyones started on that (maybe joejaxx though)
[21:56] <kees> alright.  thanks everyone!
[21:56] <kees> #endmeeting
[21:56] <jdstrand> thanks kees!
[21:56] <propagandist> thanks ;o]
[21:56] <SEJeff> propagandist, Can we carry a bit more convo on in #ubuntu-hardened?
[21:57] <propagandist> SEJeff: sure
[23:02] <emgent> @now rome
[23:02] <emgent> argh!