[02:20] <haisam> hi guys
[02:20] <andrew___> Hi.
[02:20] <haisam> I have a small technical problem is that the right place to ask ?
[02:21] <andrew___> Depends how small and how technical - #ubuntu might be better.
[02:22] <haisam> it's small :)
[02:23] <andrew___> Well ask away, and we'll continue in private if necessary :)
[02:23] <haisam> I can't play rhythmbox and Totem simultaneously
[02:23] <haisam> that mutes my sound
[02:23] <haisam> same with firefox and totem
[02:24] <haisam> in brief can't use sound for one application
[02:24] <haisam> more than one application *
[02:24] <andrew___> But when you stop trying to use the second application, sound comes back?
[02:25] <haisam> yeah
[02:25] <haisam> when I close the other application
[02:25] <andrew___> Is this in Hardy?
[02:25] <haisam> yeah
[02:26] <haisam> 8.04 LTS
[02:26] <andrew___> At a guess, that's probably got something to do with the new audio system (PulseAudio), but that's way outside anything I can help with.
[02:26] <haisam> mmm
[02:26] <haisam> I guessed so
[02:27] <andrew___> #ubuntu might know more.
[02:27] <haisam> but when I disabled it it didn't help
[02:27] <haisam> anyway thx
[02:27] <andrew___> Sure, sorry I couldn't be more help.
[02:27] <haisam> thx
[03:45] <Bodsda> sorry for coming here for a support type question but         dpkg-reconfigure xserver-xorg         used to be able to configure video displays and devices, it no longer does that,.,. is there a new command for this or how can i reconfigure my display drivers when i cannot use a gui session?
[03:46] <RAOF> You should be _always_ able to use a GUI session.
[03:48] <Bodsda> RAOF, what about when my display drivers are 'missing' and i dont know the package name to set them nor can i connect to the internet to download anything -- is there another command for reconfiguring display?
[03:49] <RAOF> If you can't, it means that the vesa driver is broken on your system.
[03:49] <Bodsda> RAOF, so what would i do then -- besides reinstall?
[03:50] <RAOF> I'm not quite sure what your question is.  Or, rather, I'm not sure that the conditions in your question ever trigger.
[03:50] <Bodsda> ok il rephrase
[03:52] <Bodsda> RAOF, in Gutsy when i ran         dpkg-reconfigure -phigh xserver-xorg        i could reconfigure my display settings things like drivers and screen res, in Hardy this is not available with the same command,. is there another command that does the same thing or how can i make the command do what it did in Gutsy?
[03:53] <RAOF> Right.  The answers there are 'no' and 'no', respectively.
[03:53] <Bodsda> RAOF, why was the command changed?
[03:53] <RAOF> Because X no longer needs that configuration.  Most of the time.
[03:54] <RAOF> And writing _wrong_ information in xorg.conf is bad :)
[03:54] <RAOF> The only time you should need to specify a driver is in the restricted-drivers case, since these don't seem to hook into X's autodetect.
[03:54] <Bodsda> RAOF, and what should i do if i need to reconfigure my display settings and i dont know what conf files to look in nor do i have a useable gui session (because there is loads of lines accross my screen & my screen is overlapping itself 5 times)
[03:55] <RAOF> Bodsda: You can delete /etc/X11/xorg.conf :)
[03:55] <RAOF> Bodsda: Or, better, move it out of the way.
[03:55] <Bodsda> RAOF, how does that help?
[03:56] <ScottK> Another option is to reboot and pick the recover option.  It's got a try to fix X option.
[03:56] <RAOF> So, that makes X do it's funky autodetection thang, which should work.  If it doesn't, it's going to be a driver bug.
[03:56] <RAOF> ScottK: Which uses VESA, right?
[03:57] <Bodsda> ok so the nifty little tool to fix screen probs has been deleted -- why? and is it at all possible to get it back?
[03:57] <ScottK> RAOF: I'm not sure.  So far everytime I broke my xorg (and I did it a bunch patching displayconfig) it got me back to working.
[03:57] <RAOF> Why? A: Because it no longer fixes screen problems.  Not possible to get it back, at least easily.
[03:58] <RAOF> You'd have to look at the pre-Xorg-1.4 packages and merge the old debconf information with the new packages.
[03:58] <Bodsda> why would it no longer fix screen probs ?? it choose drivers and screen res
[03:59] <RAOF> Both of which can be accurately autodetected.
[03:59] <ScottK> Bodsda: X changed the way it deals with stuff a lot recently.  A lot of tools just don't work anymore.
[03:59] <Bodsda> ScottK, can we expect a similar tool in the future?
[04:00] <RAOF> Probably not, since the goal is to make such a tool unnecessary.
[04:00] <ScottK> Bodsda: I'm not sure what tool you're talking about.  If you want to fix a broken X config do the reboot to the recover option and pick the fix X choice.
[04:01] <Bodsda> ok, thankyou both -- ScottK doesnt the recover mode just give u a prompt?
[04:02] <ScottK> Bodsda: No.  It gives you choices and you can fix X and then reboot normally.
[04:02] <Bodsda> ScottK, ok cheers -- il let the guys in #ubuntu know --  cheers
[04:43] <fabbione> hmmm perl still broken?
[06:43] <dholbach> good morning
[07:31] <pitti> Good morning
[07:35] <dholbach> hi pitti
[07:35]  * pitti hugs dholbach
[07:36] <ion_> Hi
[08:02] <fabbione> hi pitti
[08:02] <pitti> Padre!
[08:02] <pitti> fabbione: Rocking the penguin cluster? :-)
[08:03] <fabbione> pitti: indeed :) getting ready for a new release today
[08:24] <StevenK> TheMuso: Hardy kernel?
[08:24] <TheMuso> StevenK: Only just upgraded this box to hardy.
[08:27] <StevenK> TheMuso: Ahh
[08:28] <geser> good morning
[08:30] <pitti> fabbione: oh, FC9 o'clock?
[08:30] <fabbione> pitti: there was an announce, but no.. it's not related to f9
[08:30] <fabbione> pitti: i am preparing 2.99.01 (that will eventually be 3.0) for f10
[08:33] <fabbione> but you might have noticed that the build-deps for 2.99.01 are already in intrepid :=)))
[08:59] <mathiaz> seb128: hello :)
[09:00] <seb128> lut mathiaz
[09:00] <mathiaz> seb128: re bug 228061 - I guess this is a duplicate of a nautilus bug - which bug number should I use ?
[09:01] <mathiaz> seb128: or should I just reassign it to the nautilus package ?
[09:01] <seb128> mathiaz: bug #207072
[09:01] <mathiaz> seb128: great - thanks
[09:01] <seb128> you are welcome
[09:11] <pitti> hey seb128
[09:19] <seb128> hello pitti
[09:23] <mrec> hi, how can I get a package included in Ubuntu?
[09:24] <mrec> tvtime with audio support might be a good candidate, as well as my em28xx drivers (compiled for 32/64bit ontop of the lum modules, including firmware)
[09:25] <Chipzz> I think #ubuntu-motu may be a good start
[09:26] <mathiaz> mrec: ^^ + https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[09:26] <Chipzz> though I'm not sure about the dirver
[09:26] <Chipzz> *driver
[09:27] <Chipzz> driver possibly should go into -restricted-drivers
[09:27] <mrec> I think it's better to keep the drivers out of the linux-ubuntu-modules package since I'll update it more frequently
[09:27] <Chipzz> which wouldn't be a seperate package per se
[09:27] <mrec> it's completly opensource and supported by the manufacturer
[09:28] <Chipzz> well even then; I'm not sure what the policy is on shipping drivers in seperate packages as opposed to in the big package
[09:32] <mathiaz> mrec: if you wanna take the path to maintain out of tree kernel modules, have a look at the virtualbox-ose-* packages
[09:33] <mathiaz> mrec: I'd suggest you to get your driver included in lum - it will be much easier to maintain and things won't break whenever there is a new kernel published.
[09:34] <mrec> mathiaz: the only thing is that there will be weekly updates again
[09:34] <mrec> I'm working at the driver and application side to provide best possible support for those devices (while not affecting/(breaking) other things)
[09:34] <mathiaz> mrec: make sure you push them in the lum git tree
[09:35] <Chipzz> mrec: I'm thinking, updating your driver frequently may not be a good idea anyway; well, at least not for stable releases
[09:35] <Chipzz> and for the development cycle, new kernels get pushed often enough
[09:35] <Chipzz> though maybe not as much as you want
[09:35] <mathiaz> mrec: the problem is that if you maintain your driver out of the tree, whenever there is a new kernel published things will break
[09:36] <mrec> mathiaz: I thought about that too the package could have a direct dependency to the lum package version, so upgrading the lum package would remove the driver
[09:36] <Chipzz> at least not for stable releases >> it simply will not happen for stable releases
[09:36] <mrec> I already have a Ubuntu build system for it
[09:36] <mathiaz> mrec: for ex, if you install virtualbox-ose-modules-*, which are in universe, you have to wait for the virtualbox-ose-* maintainer to uploader a new version of the vbox-ose-modules- when a new kernel is published.
[09:37] <mrec> I'm aware of something like that yes
[09:37] <mathiaz> mrec: so it's easier to get your module in the lum tree.
[09:38] <mathiaz> mrec: your module will be part of the standard kernel upload.
[09:38] <Chipzz> mrec: uhm, first of all, you would need to manually track the lum version. and second, how is it any good for the user (who may depend on your driver) that it gets removed when stuff breaks?
[09:38] <mrec> mathiaz: ok, well sounds like a reasonable way to go
[09:39] <mrec> Chipzz: the module overall has no dependency on something else it just adds stuff
[09:39] <mathiaz> mrec: if you still wanna maintained your own kernel-modules packages, you should have a look at the virtualbox-ose package.
[09:40] <mrec> I think the way you propose is fine
[09:40] <mrec> I could still provide packages on the webserver for those who want to test the bloody edge work
[09:40] <Chipzz> mrec: btw, one more thing... doing weekly updates will make bugtracking hell I think
[09:41] <mrec> Chipzz: it doesn't, it usually adds support for newer devices and newer chipdrivers
[09:45] <geser> pitti: Hi, is it ok to ask for give-backs to get to build order right or is some huge give-back planned?
[10:10] <pitti> geser: sure, just tell me; I guess infinity will do some more mass-givebacks, but it doesn't hurt to do some more coordinated ones manually
[10:15] <pitti> hi sjoerd
[10:15] <geser> pitti: do we need the cpio-win32 binary deb? it makes currently cpio depwait on mingw32 (universe)
[10:15] <sjoerd> pitti: morning :)
[10:35] <Riddell> pitti: KDE 4 MIRs available when you're able
[10:38] <pitti> geser: erk, does that come from cpio proper? no, we certainly don't want that in main
[10:38] <pitti> Riddell: ok, thanks
[10:40] <geser> pitti: cpio builds cpio and cpio-win32. according to the description cpio-win32 is used in the win32-loader of D-I
[10:41] <soren> ogra: I have a few questions about ltsp server, if you have a minute?
[10:41] <ogra> sure
[10:42] <soren> ogra: I see that the standalone package depends on dhcp3-server.
[10:42] <ogra> right
[10:42] <soren> I'm curious about how you handle configuration file changes in there.
[10:42] <ogra> see dhcpd's initscript ;)
[10:42] <soren> I suppose ltsp fiddles around with it to offer kernel images to clients.
[10:42] <soren> Oh, ok.
[10:42] <soren> Oh.
[10:42] <soren> Hah.
[10:43] <ogra> we have an override file so we dont touch existing configs
[10:43] <soren> So installing ltsp effectively disables any currently running dhcp server?
[10:43] <ogra> if an admin wants to use his existing file he just a) deletes ours or b) only installs ltsp-server
[10:44] <soren> Is the user notified about this when installing ltsp-server-standalone?
[10:44] <ogra> -standalone assumes you want ltsp to handle everything
[10:44] <ogra> ltsp-server is freely adjustable in all directions
[10:44] <ogra> well, only by the package description, we dont notify separately
[10:46] <ogra> soren, if you have any better sugestion how to handle the situation, i'm all open for a beer in prague to discuss it over ;)
[10:47] <soren> ogra: :)
[10:48] <soren> ogra: I'm really just working on something that'll need to do almost the same thing, so I was just looking for inspiration as to how to handle this.
[10:48] <soren> ogra: ...but let's have beer anyway :)
[10:49] <ogra> soren, we do a similar thing with syslog, if you need such overrides as well, we should consider generalizing on a /etc/overrides dir or so
[10:49] <ogra> currently its bound to /etc/ltsp and the files in there
[10:50] <soren> ogra: Yup.
[10:53] <soren> pitti: re: https://bugs.edge.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/223759.. Can't we just copy over ifenslave-2.6 from hardy-updates to intrepid?
[10:53] <pitti> soren: no
[10:53] <pitti> soren: we need a different version, since we have a different toolchain
[10:54] <soren> Er.. Yeah, but if this bug had been fixed before hardy released, the packages would have just been copied to intrepid anyway. We don't rebuild every package because we update the tool chain?
[10:55] <pitti> soren: right, but we still usually do it
[10:55] <pitti> can't hurt to test it properly in intrepid
[10:55] <soren> *shrug* Ok.
[10:55]  * pitti finishes testing of virt-manager and copies to -updates
[10:55] <pitti> ^ same case, btw, should be uploaded to intrepid
[10:58] <soren> pitti: Not entirely the same case. intrepid will have a new upstream version, too. But yeah, it's in my list :)
[10:59] <geser> has someone some time to sponsor bug #229877?
[11:00] <ogra> Keybuk, why is ltsp showing up on MOM but ldm isnt ? debian added an epoch to the ldm versioning, could that cause MOM to ignore it ?
[11:01] <dholbach> ogra: it's on http://merges.ubuntu.com/main-manual.html
[11:01] <ogra> oh, i only looked at main.html, thanks dholbach
[11:02] <Keybuk> ogra: no common base version between the two
[11:03] <ogra> well, just different versioning, the code i pretty much the same .... (in the new ltsp wold each distro decides on its own how to call the tarballs :/ )
[11:03] <ogra> s/i/is
[11:09] <ogra> tkamppeter, a big "thank you" from my mother ! (i brought her a new printer this weekend and she was massively impressed that she could intsall it herself (well or that it installed itself on its own rather :) ))
[11:40] <jordi> does anyone here use vnc4server loaded in xorg.conf and get X crashes as soon as a client connects?
[11:40] <jordi> in hardy
[11:45] <geser> pitti: a first batch for give-back: antlr axis hsqldb jakarta-log4j javacc jcommon-serializer jsch libbsf-java libcommons-collections3-java libcommons-lang-java libformula liblayout libloader libjaxp1.3-java libjakarta-poi-java librepository libpgjava liboro-java libmx4j-java libxerces2-java libxml-commons-resolver1.1-java libxml-java mysql-connector-java sacjava libxalan2-java
[11:46] <ogra> pitti, you have to use "sudo hal-disable-polling --enable-polling --device /dev/scd0" if something diabled cdrom polling (i.e. powertop has such an option) couldnt we make that command a wee bit more intuitive in its naming ?
[11:46] <ogra> :)
[11:46] <pitti> geser: hm, wierd, I get 403 forbidden on those now; yay LP rollout
[11:47] <pitti> ah, seems my stored cookie was invalidated
[11:48] <pitti> darn, how do I get one back now, with Firefox 3?
[11:48] <pitti> ogra: anything you have to type on the CLI is unintuitive...
[11:48] <pitti> ogra: the UI you used to switch it off should also allow you to switch it back on
[11:48] <ogra> pitti, true, but calling a command disable-foo with such a switch seems weird
[11:48] <geser> pitti: http://people.ubuntu.com/~kees/scripts/cookies-sql2txt
[11:49] <pitti> geser: \o/
[11:50] <pitti> hm, still forbidden
[11:52] <pitti> geser: no luck; I cannot even do it in the web ui
[11:52] <pitti> I'm still in lp-buildd-admins, but I don't even see the 'retry build' option any more :/
[11:52] <pitti> cprov: ^ any idea?
[11:59] <emgent> heya
[12:03] <tkamppeter> ogra, great to hear this positive feedback. Which printer model did you give to her?
[12:04] <ogra> a HP photosmart 53xx (forgot the exact namimg, sorry)
[12:08] <tkamppeter> ogra, this one is really completely supported. Connected to USB it sets up by iteslf and you can print and scan (if it has a scanner) immediately. If you were running Windows it would take you hours to get HP's CDs installed and you would need to reboot.
[12:10] <ogra> yeah, indeed i slightly ceated by buying a HP since i know its well supported :) but it was very impressing :)
[12:16] <wgrant> I had the painful experience of installing an HP PSC .* on a Windows box last week. Could they really make it any worse/
[12:19] <cprov> pitti: what's the problem ?  you use to be allowed to retry any builds and now you are not ?
[12:19] <pitti> cprov: right
[12:20] <cprov> pitti: even l.n not in edge.l.n ?
[12:20] <pitti> cprov: let me try
[12:21] <pitti> cprov: ah, lp.net still works
[12:22] <pitti> geser: ok, disabled redirection and gave back your packages
[12:23] <geser> pitti: thanks
[12:28] <pitti> soren: FYI, (LP #223759) does not work; you have to use LP: #; so please close the ifenslave bug manually
[12:29] <soren> pitti: Ah, yes. Force of habit. I remove the colon on purpose when doing merges (to not try to close the bugs /again/), but this time that was clearly wrong. Thanks for catching that.
[12:30] <pitti> soren: btw, IIRC LP does not try to close the bugs again, that was fixed
[12:30] <soren> pitti: Ah, lovely.
[12:30] <ogra> LP will make us all jobless some day
[12:30] <pitti> soren: (I do the same, though)
[12:30] <ogra> *g*
[13:19] <jordi> cjwatson: omg
[13:19] <cjwatson> jordi: ?
[13:19] <jordi> cjwatson: remember my partman-auto-raid troubles?
[13:20] <cjwatson> sort of :)
[13:20] <jordi> I was composing a detailed email to you and Simon
[13:20] <jordi> I thought it was very suspicious that the only error message I got was "No root partition defined", invariably of what I tried, and no debug messages
[13:21] <jordi> well, partman-auto-raid is in universe in Ubuntu
[13:21] <cjwatson> aha
[13:21] <cjwatson> yes, stuff in universe won't get used ...
[13:22] <jordi> yeah, it's not even in the CD
[13:22] <jordi> now, I've tried so many things that I don't know what's the correct config :)
[13:32] <jordi> cjwatson: *sigh*, the basic expert_recipe works
[13:32] <jordi> I'll try the more elaborate setup now. I can't understand why -raid isn't in main though
[13:32] <cjwatson> never got reviewed and promoted ...
[13:33] <jordi> cjwatson: what can I do to get this reviewed and promoted?
[13:34] <cjwatson> jordi: could you mail ubuntu-devel@ about it?
[13:34] <jordi> sure thing
[13:35] <jordi> from your partman-auto knowledge, do you think creating a "/ on raid1, two independent swaps and /srv/backup on ext3 on a single PATA disk" would be problematic?
[13:35] <jordi> +layout
[13:52] <fabbione> SCORE!!!!! WOWOWOWOOWOW
[13:52] <fabbione> Subject: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator
[13:52] <Tm_T> :)
[13:52] <cjwatson> aware, work in progress
[13:53] <fabbione> cjwatson: yeah i know...
[13:55] <stgraber> fabbione: scary title isn't it ? :)
[13:57] <virtuald> <random theobsd rant />
[13:57] <ScottK> Recovery looks to be a bit painful.
[13:59] <lool> So we will have to regenerate all our SSH keys?
[14:00] <fabbione> not all of them no
[14:00] <lool> Only DSAs?
[14:00] <siretart> what ubuntu releases of openssl are affected?
[14:00] <lool> siretart: >= 0.9.8c-1 I think
[14:00] <fabbione> siretart: wait for the USN
[14:01] <siretart> lool: which would mean all later and including dapper :/
[14:01] <lool> This would translate to anything post dapper if I understand correctly
[14:01] <siretart> err, s/dapper/feisty/
[14:03] <ogra> siretart, hey, i dont see you on the UDS attendees list, you dont come this time ?
[14:03] <siretart> ogra: oh, I do!
[14:04] <siretart> ogra: is that on launchpad?
[14:04] <ogra> yeah
[14:04] <ogra> great to hear :)
[14:04] <siretart> ogra: thanks for notice, fixed :)
[14:30] <\sh> pitti: I filed a new sync request for phpgroupware, where your sync script was not able to sync it last time...could you check if it does now succeed? (bug #229942)
[15:58] <pitti> \sh: yes, I'll have a look next time
[16:29] <tjaalton> ok, so the openssl bug is quite severe.. does it really mean that every key used on a buggy system should be changed? even if not generated there?
[16:31] <ogra> check the keys with the tool :)
[16:31] <ogra> (ssh-vulnkey that is)
[16:32] <jdong> tjaalton: quite severe is an understatement.
[16:32] <tjaalton> :/
[16:32] <jdong> tjaalton: all we need now is for GPG to be compromised and the galaxy will implode.
[16:33] <thom> um.
[16:33] <thom> openssh-server template parse error: Template #4 in /tmp/openssh-server.template.326872 has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.
[16:33] <thom> (gutsy)
[16:35] <tjaalton> jdong: actually I was asked about the possibility
[16:37] <Hobbsee> ogra: ssh-vulnkey?
[16:37] <ogra> Hobbsee, yes
[16:37] <kees> Hobbsee: see http://www.ubuntu.com/usn/usn-612-2 for details
[16:38] <cjwatson> thom: gutsy> argh
[16:38] <cjwatson> jdstrand: ^--
[16:38] <jdstrand> meh
[16:38] <ogra> kees, hmm, it would be clever if the first page of the USN somehow indicated there is a second one i guess
[16:39] <tjaalton> ogra: I know the hostkeys are fine, since they are generated on a rhel cluster during installation, but the debian report said that all keys used during authentication are compromised..
[16:39] <pitti> TheMuso, imbrandon, jdong: any chance somebody could approve my fakechroot SRU? (bug 228534)
[16:39] <ogra> kees, if you dont guess that by url ...
[16:40] <cjwatson> tjaalton: all *DSA* keys
[16:40] <cjwatson> tjaalton: RSA keys are only broken if generated on a buggy system
[16:40] <kees> ogra: it isn't explicit, you're right, but the 612-1 url is in the top header
[16:41] <tjaalton> cjwatson: argh
[16:41] <kees> cjwatson: the non-default DSA breakage requires traffic capture and additional computational expense to crack, though?
[16:41] <jdong> pitti: sorry, lemme take a look; been scrambling the morning with the SSL fun
[16:41] <cjwatson> kees: correct, though perhaps not actually all that much additional computational expense (maybe)
[16:41] <pitti> jdong: it's not utterly urgent, but it's sitting there for a week or so
[16:41] <cjwatson> the DSA one is not fully analysed yet, we just know that there is a weakness there
[16:42] <Hobbsee> ogra: which package is it in?
[16:42] <jdong> pitti: you've got it :)
[16:42] <pitti> jdong: wow, that was fast. thanks :)
[16:42] <Hobbsee> ahhh, more upgrades here now.
[16:42] <ogra> Hobbsee, openssh-server
[16:42] <Hobbsee> which probably means i have to regenerate again.  sigh.
[16:43] <Hobbsee> wait, no.
[16:43] <jdong> Hobbsee: the upgrade is apparently just Ubuntu sauce...
[16:43] <jdong> Hobbsee: i.e. regen vulnerable hostkeys on postinst, reject authenication from users with weak keys
[16:46] <cjwatson> thom: feisty and hardy are fine, for the record
[16:46] <cjwatson> jdong: Debian too
[16:47] <jdong> cjwatson: oh. what's the scope then?
[16:47] <cjwatson> jdong: err, sorry, not sure exactly what you're asking?
[16:47] <cjwatson> scope of what?
[16:48] <jdong> cjwatson: USN 612
[16:48] <jdong> cjwatson: I thought feisty and hardy are affected?
[16:48] <cjwatson> oh, you misunderstood me
[16:48] <jdong> cjwatson: sorry, seems like I did :)
[16:48] <thom> jdong: cjwatson was responding to my comment that the gutsy packages are bust
[16:48] <cjwatson> thom was pointing out a problem with the upgrades in gutsy-security
[16:48] <jdong> OH
[16:48] <jdong> ok
[16:48] <cjwatson> I noted that feisty-security and hardy-security don't have that upgrade problem
[16:50] <jdong> cjwatson: thansk for the clarification.
[16:53] <no0tic> I confirm what thom said
[16:54] <cjwatson> yep, we're working on it with all possible speed
[16:54] <tjaalton> cjwatson: so all DSA keys used (!) on a buggy system should be changed, not just those that were generated there?
[16:55] <cjwatson> tjaalton: it's a somewhat arguable case as yet; for complete safety, yes
[16:55] <cjwatson> compromising a DSA key used on a buggy system requires capturing a network trace, and it's not clear yet whether user keys are susceptible except by a malicious sshd
[16:55] <cjwatson> me? I've regenerated my DSA key
[16:56] <jdong> erring on the side of caution seems prudent when dealing with these matters :)
[16:57] <tjaalton> ok, maybe it's time to write an announcement for 20000 students :P
[16:57] <jdong> haha
[16:58] <maswan> ugh. I'm happy that almost all our servers are still on dapper. :)
[16:58] <jsgotangco> heh
[16:59] <maswan> also, kerberos meaning no ssh key auth. :)
[16:59] <jdong> maswan: yeah kerberos is saving my life right now
[16:59] <jdong> my campus server keys don't need any additional work atm
[16:59] <jdong> but on my personal system I need to regenerate some IMAPS/HTTPS certs later today :)
[17:00] <tjaalton> we are still fighting whether to use MIT or AD or both
[17:00] <maswan> tjaalton: heimdal! :)
[17:00] <tjaalton> maswan: that too :)
[17:00] <tjaalton> maswan: we actually have MIT already set up, but it's "unofficial"
[17:00] <jdong> use MIT </unbiased joking opinion> ;-)
[17:01] <tjaalton> and no trust between MIT <-> AD
[17:07] <jcastro> http://www.pastebin.ca/1016979
[17:07] <jcastro> anyone seeing that with the ssh update?
[17:07] <Ng> jcastro: gutsy?
[17:08] <jcastro> yeah
[17:08] <Ng> a new version is being prepared for gutsy
[17:08] <jcastro> (not my machine, just got asked by someone who did this)
[17:08] <jcastro> ok
[17:08] <jcastro> thanks
[17:10] <Mithrandir> ssh update?  You mean openssl or do you actually mean ssh?
[17:10] <cjwatson> Mithrandir: ssh
[17:10] <cjwatson> jcastro: known, in progress
[17:11] <Mithrandir> maswan: heimdal seems to be linked with openssl here.  Are you sure it's safe?
[17:11] <maswan> Mithrandir: no, it's likely broken just like mit kerberos. our kdcs etc are on dapper. :)
[17:12] <Mithrandir> ah, ok
[17:16] <Volans> Hi all, I have a problem with the update of openssh-server on Gutsy 64bit. I know that you are working on it, if I can help with some test feel free to ask me (output of apt-get -f install: http://pastebin.ubuntu.com/11878/)
[17:17] <cjwatson> Volans: known, we're on it
[17:17] <jcastro> Volans: I just asked the same question, it's being worked on
[17:17] <cjwatson> (you're number four ...)
[17:18] <emgent> hehehe :D
[17:18] <cjwatson> the fix is in the works
[17:18] <Volans> ok, better! :) just in case we can help you with some test
[17:25] <l3on> Hi all :)
[17:33] <kirkland> cjwatson: the ideal output of a "fixed" system when running "sudo ssh-vulnkey -a" is an exit code of 0?
[17:33] <cjwatson> no, the opposite
[17:33] <cjwatson> the exit code semantics are a bit tricky I'm afraid
[17:33] <cjwatson> but ssh-vulnkey exits 0 if it finds at least one vulnerable key
[17:34] <kirkland> cjwatson: interesting, okay.  output of "Not blacklisted" is optimal?
[17:34] <cjwatson> yes
[17:34] <cjwatson> "Unknown (no blacklist information)" means it's a key type/length for which we don't have a blacklist
[17:34] <cjwatson> "COMPROMISED" means regenerate the bugger now
[17:34] <sdh> anybody help me out with this related error please?
[17:34] <sdh> https://www.uptime.org.uk/tmp/apt.txt
[17:34] <kirkland> cjwatson: yup
[17:35] <kirkland> cjwatson: thanks.
[17:35] <sdh> looks like a package problem
[17:35] <cjwatson> sdh: we're on it
[17:35] <Volans> sdh: have you gutsy?
[17:35] <sdh> cjwatson: ah, it's known about?
[17:35] <sdh> Volans: yep, server
[17:35] <cjwatson> yes, this is gutsy only
[17:35] <thom> cjwatson: worth topic'ing?
[17:36] <sdh> i just update/upgraded to fix the ssl nightmare :)
[17:36] <sdh> s/fix/help start to fix/ :)
[17:36] <Volans> they are working on it, only Gutsy have this update problem on openssh-server due to the USN-612-1 fix
[17:36] <sdh> ok, cool, thanks
[17:36] <cjwatson> it's a single sodding blank line *sigh*
[17:36] <sdh> i'll hold off and keep an eye on here... then update/upgrade later
[18:05] <cjwatson> gutsy-security is fixed
[18:05] <Volans> thanks cjwatson :)
[18:05] <cjwatson> thom,no0tic,jcastro,Volans,sdh: ^--
[18:05] <jcastro> cjwatson: thanks, I'll let people know
[18:06] <sdh> thanks
[18:07] <no0tic> thanks
[18:07] <stgraber> thanks
[18:07] <Volans> cjwatson: just updated all worked fine
[18:07] <thom> ta
[18:08] <cjwatson> great
[18:08] <Pici> thanks, /me informs #ubuntu
[18:08] <stgraber> openssh upgraded correctly
[18:08] <stgraber> but not openvpn
[18:08] <stgraber> openvpn: Depends: openssl-blacklist which is a virtual package.
[18:08] <[reed]> kees, jdstrand, cjwatson: ping... looks like the openssl/openssh packages are wrong
[18:09] <geser> pitti: please give-back: libapache-htpasswd-perl libcrypt-hcesha-perl libcrypt-openssl-dsa-perl libhtml-fromtext-perl libgnome-java
[18:09] <[reed]> so, this was the "fix" Debian made in 2006
[18:09] <[reed]> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c
[18:09] <[reed]> and this was the back out 5 days ago:
[18:09] <[reed]> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c
[18:09] <[reed]> I see a problem!
[18:09] <cjwatson> [reed]: nah
[18:09] <[reed]> why not? PURIFY isn't used for compiling
[18:09] <cjwatson> [reed]: the first change to rand/md_rand.c was wrong - that was in 0.9.8b-1
[18:09] <[reed]> that code is still compiled
[18:10] <[reed]> cjwatson: that code is still there
[18:10] <cjwatson> [reed]: the PURIFY bit does not matter
[18:10] <cjwatson> ok, sorry, I thought you were asking about the filename difference, but in any case
[18:10] <cjwatson> [reed]: no, it's fine - one of those two diffs was acceptable, one was incorrect
[18:10] <cody-somerville> Would this vulnerability affect a red hat server if I used Ubuntu to generate the key?
[18:11] <cjwatson> cody-somerville: yes
[18:11] <pitti> geser: done
[18:11] <[reed]> cjwatson: why wasn't the entire change backed out?
[18:11] <cjwatson> because it didn't need to be
[18:11] <[reed]> looking at ssleay_rand_bytes() in Debian's svn repo, that other change is still there
[18:11] <[reed]> #ifndef PURIFY
[18:11] <[reed]> #if 0 /* Don't add uninitialised data. */
[18:11] <[reed]> 		MD_Update(&m,buf,j); /* purify complains */
[18:11] <[reed]> #endif
[18:11] <[reed]> #endif
[18:12] <jcastro> 3333333333333333333333333333333333333333333333333333333333333[A
[18:12] <jcastro> oops, sorry
[18:12] <jdong> jcastro: you sure held that right arrow key for a convincing period of time ;-)
[18:13] <cjwatson> [reed]: yes. we know. but that's ok.
[18:13] <[reed]> cjwatson: well, it doesn't make me feel very safe
[18:13] <cjwatson> [reed]: "buf" is something completely different there than in the other chunk.
[18:13] <[reed]> yeah
[18:13] <jcastro> jdong: the new package apparently doesn't fix ssh lag. :)
[18:13] <[reed]> well
[18:13] <[reed]> it's still a wrong change that Debian should have never made
[18:13] <cjwatson> [reed]: in the other chunk, buf is actual real initialised data
[18:13] <cjwatson> I don't dispute that
[18:14] <[reed]> so it doesn't make sense why somebody doesn't back it out now and submit new packages just to appease everybody that there isn't still some remnants left
[18:14] <[reed]> because when an openssl team member is pointing it out on his blog, I worry
[18:14] <cjwatson> [reed]: because there was actually a reason for the other bit - it made it more difficult to use automated tools to assure the correctness of other software that used openssl
[18:15] <cjwatson> I have read the blog entry in question, yes
[18:15] <[reed]> cjwatson: sure, that's what the PURIFY define is for
[18:15] <[reed]> you can define it if you want
[18:15] <cjwatson> let me explain
[18:15] <[reed]> instead of commenting out the code
[18:15] <cjwatson> (or you could go and read the original bug log!)
[18:16] <cjwatson> but if you don't want to read the original log, the reason why -DPURIFY wasn't used was that that would have to be applied to the non-debug build as well, otherwise the utility of the -dbg build just being separated symbols so that you can use it to investigate core dumps produced by the regular build would be lost
[18:17] <cjwatson> now, I'm not sure why PURIFY wasn't used across the board, because I haven't looked at what else it does to openssl
[18:17] <cjwatson> but if you have questions there you should address them to the Debian maintainer
[18:17] <cjwatson> divergence between Debian and Ubuntu here is unlikely to be helpful, and we've taken quite a lot of care to coordinate here
[18:17] <[reed]> I read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516, which doesn't mention PURIFY
[18:17] <[reed]> which bug # is this you're speaking of?
[18:17] <cjwatson> that's the one
[18:18] <cjwatson> it discusses it, even if not by name
[18:18] <cjwatson> as it happens, it looks like the only thing PURIFY does now is to compile out that code which is commented out
[18:18] <cjwatson> so what we have now is equivalent to (and uglier than) building with -DPURIFY
[18:18] <[reed]> ok, so, why did this take 5 days (at least) to go public?
[18:19] <cjwatson> because we needed to take care to get mitigation measures in place
[18:19] <[reed]> such as what?
[18:19] <[reed]> the script?
[18:19] <cjwatson> I do not wish to give people information on how to write an exploit just at the moment, I'm afraid
[18:19] <[reed]> dowkd.pl
[18:20] <cjwatson> dowkd.pl was written by a member of the Debian security team; I wrote ssh-vulnkey
[18:20] <[reed]> cjwatson: well, I think you should at least mention somewhere publicly why Debian/Ubuntu/etc. didn't back out the entire bad change
[18:20] <cjwatson> but the aim of both was the same; help people to lock down use of compromised ssh keys as soon as possible
[18:21] <cjwatson> I think you should address your concern to the Debian developer who made the change
[18:21] <cjwatson> (as I said above0
[18:21] <cjwatson> )
[18:22] <[reed]> ok
[18:22] <cjwatson> we have put a good deal of time into assisting with the job of mitigating this, but ultimately it is more valuable to Ubuntu not to diverge from Debian on critical issues such as this so that at least we share problems
[18:22] <cjwatson> we certainly aren't going to make the essentially cosmetic change of switching to using -DPURIFY
[18:22] <[reed]> do you recommend regenerating all keys made since the bad change was live, or just ones that are vulnerable?
[18:22] <cjwatson> now, personally, I think that would be the correct change to make
[18:22] <cjwatson> but it should be made in Debian
[18:22] <Chipzz> how does this affect ubuntu? http://www.debian.org/security/2008/dsa-1571
[18:23] <cjwatson> http://www.ubuntu.com/usn/usn-612-2 has detailed instructions
[18:23] <Chipzz> (OpenSSL vulnerability)
[18:23] <cjwatson> Chipzz: please see the corresponding Ubuntu security updates
[18:23] <jdong> Chipzz: USN 612-2
[18:23] <Chipzz> maybe best to put a warning in the topic?
[18:23] <cjwatson> [reed]: five days ago, we also didn't know the scope of the problem (e.g. whether it affected session keys), and needed time to investigate before the storm broke
[18:24] <cjwatson> five days is not an especially long embargo period for this sort of thing; in fact it was shorter than would have really been convenient to get everything ready
[18:24] <[reed]> I agree
[18:24] <[reed]> and my other question and regenerating keys?
[18:24] <sdh> hmm, i guess this affects https keys too?
[18:24] <[reed]> s/and/about/
[18:24] <sdh> as generated using openssl for apache
[18:25] <cjwatson> sdh: yes
[18:25] <sdh> that's unfortunate, given that people pay to get them signed
[18:25] <cjwatson> [reed]: for 2048-bit RSA keys or 1024-bit DSA keys, we have blacklists of compromised keys, and you can refer to those
[18:25] <cjwatson> [reed]: for other keys, I would advise regenerating unless you are confident that they were generated on non-vulnerable systems
[18:25] <cjwatson> sdh: yes
[18:25] <[reed]> k
[18:25] <[reed]> thanks
[18:27] <winjer> we've regenerated our server keys using the new ssl, and they're being reported as weak by the tool
[18:27] <winjer> any idea what's going on there?
[18:28] <cjwatson> winjer: which keys, which tool?
[18:28] <winjer> dowkd.pl, server host keys
[18:28] <cjwatson> I did not write dowkd.pl and can't support it; try ssh-vulnkey?
[18:28] <cjwatson> what does it say?
[18:29] <winjer> "weak key"
[18:29] <winjer> i'll keep digging
[18:29] <cjwatson> ssh-vulnkey doesn't say "weak key" :-)
[18:29] <winjer> oh sorry
[18:30] <stgraber> cjwatson: is the openvpn security update supposed to work with gutsy ?
[18:30] <cjwatson> stgraber: I believe so, though I haven't looked at it ... what's wrong?
[18:30] <stgraber> The following packages have unmet dependencies: openvpn: Depends: openssl-blacklist which is a virtual package.
[18:31] <cjwatson> openssl-blacklist may be in NEW or something
[18:31] <cjwatson> I'll check it out
[18:31] <cjwatson> yes, it is
[18:37] <sdh> good time to be a CA :)
[18:39] <norsetto> can someone please give back wsjt?
[18:40] <psusi> I do not understand the purpose of the watershed wrapper used by udev... could anyone explain?
[18:40] <cjwatson> https://wiki.ubuntu.com/UdevLvm was where it was introduced
[18:41] <psusi> I just read that ;)
[18:41] <psusi> not getting it for some reason
[18:42] <psusi> it says if 100 events come in, it will run the command at least twice, but probably not 100 times...
[18:42] <Mithrandir> psusi: in some cases, you have a process which takes a long while to finish and it holds a lock, but it's stateless and you just need it to run after a certain event.
[18:42] <psusi> if there are 100 events, then shouldn't the command be run 100 times?
[18:42] <psusi> OHH
[18:42] <cjwatson> no, because one run of the program is sufficient to clear all pending events
[18:42] <Mithrandir> not necessarily.
[18:42] <cjwatson> but what happens if an event arrives after the program started?
[18:42] <psusi> right... since you are telling it to scan ALL devices, if 12 devices come in, you don't need 12 scans
[18:42] <cjwatson> that's what watershed is for
[18:42] <psusi> just 1 scan after the last device
[18:42] <Mithrandir> psusi: correct.
[18:43] <psusi> why isn't lvm told only to scan the device which has arrived though?
[18:43] <cjwatson> in lvm's case, it may take several block devices to build up a full volume
[18:43] <cjwatson> basically it's a race fix IIRC
[18:44] <psusi> yea... but if you vol_id them as they come in, and you identify which volume they are a part of, then you can tell lvm exactly which devices have been identified as part of that volume so it can scan them and activate that volume
[18:44] <psusi> without disturbing any unrelated devices
[18:44] <sdh> cjwatson: is there a ssh-vulnkey equivalent for generic SSL keys ?
[18:45] <sdh> not sure im making sense
[18:45] <cjwatson> sdh: it's not possible for all keys
[18:45] <sdh> the sort of key that openssl spits out for use in apache
[18:45] <Mithrandir> psusi: theoretically, there's nothing wrong with that approach, apart from the fact that lvm doesn't work that way, I believe.
[18:45] <cjwatson> sdh: but I believe one is either done or in progress for some simple cases, in one of the other security updates
[18:45] <sdh> cjwatson: thanks
[18:46] <psusi> is the output of the scripts run by udev logged anywhere?  I'm trying to figure out why this server won't activate the root raid at boot
[18:56] <Keybuk> psusi: not normally
[18:56] <psusi> Keybuk: is there a switch or boot parameter you can throw to make it?
[18:56] <Keybuk> psusi: no
[18:57] <psusi> ;(
[18:57] <Keybuk> not to mention that syslog starts a long time after udev anyway
[18:58] <psusi> I was thinking just redirect to /var/udev.log instead of /dev/null ;)
[18:58] <Keybuk> udev.log is something else
[18:58] <Keybuk> it logs udevmonitor output
[18:59] <psusi> it's a shame that you no longer see the output of mdadm on the boot screen
[19:00] <RainCT> uhm.. I can't install libssl0.9.8_0.9.8g-4ubuntu3.1_i386.deb
[19:00] <cjwatson> RainCT: what is the problem?
[19:00] <RainCT> dpkg-deb (subprocés): llegida curta en buffer_copy (s'ha produït un error en escriure al conducte en la còpia)
[19:00] <RainCT> dpkg-deb: el subprocés paste retornà el codi d'eixida d'error 2
[19:01] <RainCT> cjwatson: translated that would be +/-: short read in buffer_copy (there was an error writing to the copy conduct)
[19:01] <cjwatson> "failed to write to pipe in copy" in fact
[19:01] <cjwatson> that's usually transient, or possibly out of disk space
[19:01] <cjwatson> check that you have enough free disk space? otherwise try again
[19:01] <cjwatson> but basically that's internal in dpkg, and not usually a problem with the package
[19:02] <cjwatson> unless there are other nearby errors which are more specific
[19:04] <RainCT> what can it be beside disk space (/ has 2.2GB free)
[19:04] <ogra> with /var on the same partition ?
[19:04] <RainCT> yes
[19:05] <RainCT>  /usr is in a different partition though, and has 12 GB free
[19:05] <RainCT> (yeh, I know I should repartition ^^)
[19:05] <cjwatson> would need an strace of dpkg really to see what's actually going wrong
[19:06] <cjwatson> errno 2 is no such file or directory
[19:06] <cjwatson> very weird
[19:06] <cjwatson> is anyone else seeing this problem?
[19:06] <cjwatson> RainCT: and could you put the entire output from dpkg somewhere?
[19:06]  * ogra had proper upgrades everywhere
[19:07]  * RainCT is trying with aptitude full-upgrade, hadn't noticed the new packages are already in the repos
[19:07] <cjwatson> RainCT: could you provide the full output, before you lose it?
[19:08] <RainCT> cjwatson: sure, but there's not much more
[19:09] <RainCT> cjwatson: http://paste.ubuntu.com/11906/plain/
[19:10] <cjwatson> out of interest, does the directory /usr/lib/i586 exist?
[19:11] <RainCT> cjwatson: yes, it contains the files libcrypto.so.0.9.8 and  libssl.so.0.9.8
[19:11] <cjwatson> very strange
[19:11] <ogra> oh, same here
[19:11] <cjwatson> of course you're doing a downgrade
[19:11] <cjwatson> which is not a great plan
[19:11] <cjwatson> so, while I can't imagine why, it could be something to do with that
[19:12] <ogra> whats the reason for that special dir ?
[19:12] <ogra> seems very libssl specific
[19:13]  * stgraber wonders why one of his 3 routers don't seem to accept the new OpenVPN key ... all three are dd-wrt with the exact same custom firmware :( let's wait and see if things improve by themselves :)
[19:13] <geser> isn't that dir used by packages with cpu-optimsation?
[19:13] <cjwatson> geser is correct
[19:13] <cjwatson> it is not openssl-specific, AFAIK; the linker looks at it
[19:13] <stgraber> ogra: btw, I guess italc is also concerned by the SSL thing no ?
[19:13] <ogra> stgraber, for sure :(
[19:14] <stgraber> ok, one more thing to add to the long list of keys to rebuild ...
[19:14] <ogra> ah, debian bug #139783 explains the dir thing apparently
[19:14] <l3on> Hi, is it solved open-ssh problem in gutsy release?
[19:15] <cjwatson> l3on: in gutsy-security, yes
[19:15] <l3on> someone said me that it was impossible install it forum security, apt returns an error
[19:15] <l3on> is it right?
[19:16] <cjwatson> l3on: that's fixed now
[19:16] <l3on> ok, tnx cjwatson
[19:17] <andrew___> cjwatson: what should I do if one of my public keys is listed as "COMPROMISED"?  Is there a page that goes into more details about this stuff?
[19:17] <cjwatson> andrew___: http://www.ubuntu.com/usn/usn-612-2
[19:17] <andrew___> But no special action beyond that?
[19:17] <stgraber> andrew___: revoke and generate a new one, that's basically it
[19:18] <awalton__> did launchpad autoreap the bad keys?
[19:19] <cjwatson> awalton__: not so much of the "auto", but I gather action has been taken there
[19:19] <andrew___> Fair enough - FWIW, the use of upper case lead me to assume there was something extra to be doing with that.  If anyone else is as jumpy as me, you might want to consider putting it in the man page/downcasing the message.
[19:20] <awalton__> cjwatson, all I needed to know. just wanted to know if it was going to take care of it or if I would have to.
[19:20] <awalton__> cjwatson, thanks.
[19:22] <cody-somerville> Does this mean I'm okay? Unknown (no blacklist information): <key stuff here> /home/cody-somerville/.ssh/id_rsa.pub ?
[19:22] <ScottK> cody-somerville: As I understand it, that's a don't know response.
[19:23] <andrew___> In anticipation of more panicky people, is there somewhere good to put together a FAQ?
[19:23]  * ScottK redid all his keys before the new SSH packages hit, so doesn't actually know.
[19:23] <stgraber> cody-somerville: yep, that's ok
[19:23] <cjwatson> andrew___: COMPROMISED absolutely deserves to be upper-case
[19:23] <cjwatson> andrew___: any such key must be regenerated
[19:23] <stgraber> cody-somerville: COMPROMISED: 2048 isn't
[19:23] <cjwatson> andrew___: http://www.ubuntu.com/usn/usn-612-2 is meant to be the FAQ, pretty much ...?
[19:24] <cjwatson> cody-somerville: that means there's no blacklist for that key type/size combination; you'll have to figure out from things like key generation time whether that key is vulnerable
[19:24] <andrew___> Well, there's already two Qs not explicitly A'd.  For panicky people, I don't mind putting in a bit of time to repeat the answer for peace of mind.
[19:26] <cjwatson> andrew___: it wouldn't hurt, but I'm exhausted and not able to set one up
[19:26] <cjwatson> however, I'd rather there not be a semi-official FAQ filled with possible misinformation
[19:26] <cjwatson> can this wait until tomorrow?
[19:26] <andrew___> If you'd rather I not do it, sure.
[19:26] <cjwatson> well, I'd rather the person that does it have authoritative information
[19:27] <andrew___> Fair enough.  In the mean-time, the standing advice is to regenerate your keys if there's any doubt, and not to do anything else?
[19:27] <cjwatson> yes
[19:28] <andrew___> Okay, thanks.
[19:28] <cjwatson> for paid-for SSL keys, I would understand people not wanting to regenerate them frivolously, but for SSH keys there's really little reason not to regenerate them if in doubt
[19:29] <cody-somerville> gah,  almost all my keys are compromised :(
[19:29] <LaserJock> ssh keys are rather cheap, at least compared to signed gpg keys
[19:30] <Keybuk> gpg keys are cheap :)
[19:30] <cjwatson> gpg, fortunately, is not affected
[19:30] <andrew___> I'll pass that on if anyone asks, with the appropriate I'm-not-worthy's :)
[19:31] <cjwatson> andrew___: I didn't mean to imply unworthiness, BTW, I'm just very conscious of how Chinese whispers tends to work
[19:32] <Keybuk> gpg --gen-key ... "lamont, sign my key" ... "gpg --send-key" - et voila, new gpg key and back in the well-connected set ;)
[19:32] <RainCT> cjwatson: (the debs from the repos worked)
[19:32] <Mithrandir> Keybuk: except when nine-tenths of the WoT is gone.
[19:32] <lamont> Keybuk: heh
[19:32] <Keybuk> Mithrandir: FIRESALE!
[19:32] <Mithrandir> since nearly all of them (well, except lamont) has DSA keys. :-P
[19:33] <stgraber> Keybuk: hmm, and if lamont's key would also be compromised ? :)
[19:33] <philsnow> cjwatson: i had never heard that term ('chinese whispers') until one of the latest episodes of dr who
[19:33] <Keybuk> stgraber: then o/~ with just a handful of men / we'll start / we'll start all over again
[19:33] <Keybuk> <fx: guitar solo>
[19:34] <andrew___> cjwatson: Yeah I completely agree.  I've no problem admitting I'm not a security professional, it's just a fact that needs to be passed on because of the aforementioned whispers.
[19:34]  * jdong is still unfamiliar with the term :)
[19:35] <andrew___> Chinese Whispers it's a game schoolchildren play, where they each whisper a message to the next.
[19:35] <jdong> are any non-mozilla browsers affected?
[19:35] <jdong> andrew___: is it like telephone?
[19:35] <andrew___> I don't know, I've not played that game :s
[19:35] <jdong> andrew___: n whispers to n+1, at the end the message is garbled?
[19:35] <andrew___> Yeah, that's the one.
[19:35] <LaserJock> I thought that was called Telephone
[19:36] <jdong> andrew___: ok so I guess I only know the politically castrated terminology then ;-)
[19:36] <jdong> LaserJock: ^^ :)
[19:36]  * andrew___ becomes old
[19:36] <LaserJock> I guess maybe the Chinese were whispering before the telephone was invented
[19:37] <cody-somerville> cjwatson, Should I put something on the fridge?
[19:37] <jdong> cody-somerville: yeah stock up on milk, we're running low
[19:37] <cjwatson> cody-somerville: if you do, please refer to the USN
[19:37]  * cody-somerville nods.
[19:37] <cjwatson> cody-somerville: we may be updating the web copy of the USN with more information
[19:40] <ogra> cjwatson, hmm, looks to me like that broken pipe dpkg error occurs if something tries to overwrite conflicting files, there was just a mail to ubuntu-de with the same error where a third party package claimed an already owned file
[19:48] <cody-somerville> Posted to the fridge.
[19:49] <[reed]> cjwatson: does ssh-vulnkey have a blacklist for 2048 keys?
[19:49] <LaserJock> cjwatson: the USN has no information on regenerating system keys, is there anything special that has to be done for that?
[19:49] <[reed]> 2048 bit keys, that is
[19:50] <geser> [reed]: look into /etc/ssh/
[19:50] <cjwatson> [reed]: RSA 2048-bit, yes (DSA is only valid for 1024-bit, technically)
[19:50] <cjwatson> LaserJock: vulnerable 2048-bit RSA and 1024-bit DSA keys will be regenerated automatically if necessary
[19:50] <[reed]> cjwatson: true, but that change to ssh-keygen for DSA is fairly recent!
[19:50] <[reed]> so, I'm seeing conflicting results
[19:50] <cjwatson> LaserJock: though not other keys; they're just ssh-keygen with empty password though
[19:50] <cjwatson> slangasek: ^--
[19:51] <[reed]> between ssh-vulnkey and dowkd.pl
[19:51] <cjwatson> [reed]: 1024-bit DSA has never been valid, FYI; the standard prohibits it
[19:51] <[reed]> cjwatson: you mean 2048
[19:51] <[reed]> I hope
[19:51] <[reed]> :p
[19:51] <cjwatson> [reed]: err, yes, I do
[19:51] <cjwatson> I mean any more than 1024 bits
[19:51] <[reed]> true, but for a long time, ssh-keygen would allow people to make >1024 bit keys
[19:51] <cjwatson> sure
[19:51] <cjwatson> [reed]: you're welcome to mail me about it; I'm going to do other things now
[19:51] <cjwatson> or file a bug report
[19:52] <slangasek> cjwatson: ack
[19:52] <[reed]> so, I'm finding it weird that ssh-vulnkey is warning about them while dowkd.pl is checking them and passing them
[19:52] <[reed]> :/
[19:52] <LaserJock> cjwatson: ok, I just noticed that on one of my machines the openssh-server upgrade regerated the system keys, but on the other it didn't. Should I assume if it didn't regenerate I'm ok?
[19:52] <cjwatson> [reed]: I need output from both in order to help
[19:52] <cjwatson> LaserJock: ssh-vulnkey will tell you the status of the host keys
[19:52] <[reed]> cjwatson: what's your e-mail address?
[19:53] <LaserJock> cjwatson: k, I guess I'll just go with that. I was just going to regenerate them all anyway.
[19:53] <winjer> dowkd.pl gives loads of false positives, and some false negatives too i think
[19:54] <cjwatson> [reed]: cjwatson@ubuntu.com
[19:56] <[reed]> cjwatson: which do you personally recommend? high-number of bits RSA key or a 1024-bit DSA key?
[19:57] <cjwatson> for high-security single-use keys, I use 4096-bit RSA keys
[19:57] <cjwatson> for routine use I normally use 2048-bit RSA, although I may change that
[19:57] <[reed]> and why RSA over DSA?
[19:57] <cjwatson> I don't think DSA is fundamentally broken though - it just happens to be weak in the presence of a weak RNG
[19:57] <cjwatson> ^- only reason
[19:57] <[reed]> k
[19:58] <cjwatson> I don't think use of DSA is insecure in general, at the moment
[19:58] <cjwatson> but at the moment I think ssh-keygen's default of 2048-bit RSA is fairly reasonable
[19:59] <[reed]> the DSA vs. RSA debate is almost as bad as the vi vs. emacs debate
[19:59] <[reed]> :/
[20:02] <psusi> is it as silly as the MD5 hash collision "attack"?
[20:03] <cjwatson> psusi: is what as silly?
[20:03] <psusi> the DSA/RSA debate you were talking about
[20:04] <cjwatson> err, apples and oranges? I'm not sure debates and cryptanalysis are comparable
[20:05] <psusi> the "debate" is whether MD5 is "broken"
[20:06] <psusi> because you can carefully craft two documents that differ but give the same hash.... still can't create a second document with the same hash as an existing one ( that you didn't carefully create )
[20:11] <cjwatson> psusi: it is broken in one sense, but not in another sense
[20:11] <cjwatson> (the debate is no doubt by people who don't understand a lot of crypto)
[20:11] <cjwatson> psusi: the collision attack is real, but as you observe it is not as bad as it could be; the name for the second case is a second-preimage attack
[20:12] <cjwatson> psusi: however, a demonstration of a collision attack is good evidence that a second-preimage attack is not all that far off, so there's no grounds for complacency either
[20:12] <k0p> hi all
[20:15] <cjwatson> psusi: similarly, the flaw in DSA in the presence of a weak RNG is real; grounds for not being too complacent, but not grounds for panic - except in the case of an advisory such as this
[20:50] <zul> I updated an apache2 to hardy-proposed but didnt get an email back can someone check on it?
[20:57] <andrew___> RainCT: do you actually use reportbug-ng to send bugs to Debian?
[21:05] <seb128> jwendell: <mneptok> for those with GNOME access and personal keys they no longer trust, please update your system, re-generate keys, and send mail to accounts@gnome.org with the subject "replace Debian/Ubuntu key"
[21:05] <seb128> jwendell: replying there since that was mentioned on the ubuntu chans ;-)
[21:06] <jwendell> seb128, thanks
[21:06] <seb128> you are welcome
[21:07] <jwendell> seb128, should I attach my id_rsa.pub file?
[21:07] <seb128> mneptok: ^
[21:08] <jwendell> will do..
[21:09] <seb128> jwendell: I guess so, id_rsa.pub or id_dsa.pub anyway
[21:10] <jdong> jwendell: also send a copy of id_dsa and $500 to paypal jdong@ubuntu.com
[21:10] <jdong> ;-)
[21:10] <jwendell> jdong, ah, you're not the guy who found out the issue...
[21:11] <RainCT> andrew___: no :P
[21:11] <jdong> jwendell: nah, I'm not nearly close to that skill level and I will likely not make it up there
[21:12] <andrew___> RainCT: Good, then you won't freak out about suggestions for having it removed :)
[21:12] <jwendell> we should take that money from the guy who patched ssh in the first place
[21:12] <jdong> jwendell: so much for the idea of code policing pedantic warnings in the first place :)
[21:13] <RainCT> andrew___: I still disagree with removing the option to use it to send bugs to Debian, though
[21:13] <jwendell> what make debian devs think they should patch upstream code in the first place?
[21:13] <andrew___> RainCT: if it stays in, I agree.  I just don't think it should be the default.
[21:14] <jdong> jwendell: they saw a valgrind "memory leak" and figured it's a good idea to patch it.
[21:14] <RainCT> andrew___: yeh, I don't mind wheter it's the default or not :)
[21:14] <jwendell> this is a good moment to rethink about patching upstream code at all...
[21:14] <andrew___> seb128: presumably accounts@gnome.org requires that all e-mail be PGP-signed?  (Sorry if that's a silly question)
[21:14] <jwendell> andrew___, nope
[21:15] <andrew___> So what's to stop me from saying I'm Miguel de Icaza and handing over my id_rsa.pub?
[21:16] <jdong> andrew___: your mail client is not Novell/Ximian evolution.

[21:16] <jwendell> hehe
[21:16] <jwendell> jdong, you're so funny today :P
[21:16] <jdong> lol
[21:16] <andrew___> Also, I'm guessing he speaks better Spanish than me :p
[22:10] <slangasek> zul: you would have not gotten an email because the publisher was down in deference to the openssl security updates; you should have gotten an email by this point, I think?
[22:24] <zul> slangasek: ok thanks
[22:34]  * mneptok waits for jwendell to answer e-mail
[22:44] <RainCT> good night
[23:37] <Riddell> evand: how come d-i asks if the time is set to UTC but ubiquity doesn't?
[23:42] <Keybuk> Riddell: u6y doesn't ask silly questions
[23:45] <Riddell> neither should d-i
[23:45] <Keybuk> d-i can get away with asking any that it likes ;)
[23:45] <Riddell> who has powers to close specs that people have randomly created?  e.g. https://blueprints.launchpad.net/ubuntu/+spec/kmilo-controls-kmix-selected-sound-card
[23:46] <Keybuk> more correctly
[23:46] <Keybuk> u6y knows whether or not you have a windows partition
[23:46] <Keybuk> so can make an intelligent judgement as to what your system clock should be
[23:46] <Keybuk> d-i doesn't have that knowledge in the right place, so has to ask
[23:46] <Riddell> ah, clever old ubiquity
[23:46] <Keybuk> and since it assumes a more expert user, it's safe to do so