[00:32] <blueyed> Can somebody please clear vbox-ose-modules from NEW/hardy-proposed?
[00:45] <LaserJock> can anybody think of a reason why a package would just disappear from Hardy?
[00:47] <jdong> LaserJock: usually that involves sabdflatory processes ;-)
[00:47] <jdong> or launchpad magic.
[00:47] <LaserJock> I think perhaps something went boom
[00:47] <LaserJock> I don't see a removal bug
[00:48] <LaserJock> but a decently important science app is just gone
[00:48] <LaserJock> looking at the publishing history all the Hardy uploads are "superseded" and none are "published"
[00:51] <blueyed> btw: "hardy-proposed" is missing from http://ddebs.ubuntu.com/dists/
[00:59] <TheMuso> LaserJock: Has it been removed from Debian.
[01:00] <LaserJock> TheMuso: I seriously doubt it, let me check
[01:01] <LaserJock> oh, actually it appears it has!
[01:03] <bd_> heh, why was it removed?
[01:04] <LaserJock> RoQA; (very) RC-buggy
[01:05] <LaserJock> well that's kinda crappy
[01:05] <LaserJock> somebody was clearly trying to fix it up and they go and remove it
[01:07] <LaserJock> I don't suppose there's a way for us to get it back?
[01:09] <cjwatson> LaserJock: err, it could come back in intrepid, maaaaaaaaybe in hardy-proposed given an SRU
[01:10] <cjwatson> BTW the RoQA stuff typically only happens after the maintainer has been delinquent for some time, and is a reaction to many previous occurrences when people promised to fix things up and then forgot
[01:11] <LaserJock> I guess
[01:11] <cjwatson> for some reason, removing things seems to kick people into action ...
[01:11] <LaserJock> but why not orphan it for a while first
[01:11] <LaserJock> I can see removing it from testing
[01:11] <LaserJock> as it had problems with gcc 4.3
[01:12] <LaserJock> so instead I have users wondering where their app is
[01:12] <LaserJock> and turning to PPAs
[01:12] <LaserJock> which I guess is alright
[01:15] <LaserJock> but perhaps we should just get the PPA packages into Ubuntu and let Debian do whatever they're gonna do
[01:15] <LaserJock> cjwatson: would you just blacklist a package like that from syncing?
[01:16] <LaserJock> I guess there wouldn't be anything to sync anymore
[01:16]  * LaserJock shuts up for the moment :-)
[01:21] <cjwatson> LaserJock: usually we don't blacklist packages that have been removed from Debian, on the basis that if they get put back into Debian then we probably want to follow suit
[01:21] <cjwatson> the blacklist is for packages that have been removed from Debian but not for Ubuntu
[01:22] <LaserJock> yeah, makes sense
[01:22] <LaserJock> I'm sure we'll bring them back for Intrepid
[01:22] <LaserJock> I don't feel like trying an SRU for Hardy, especially when there are PPAs available for it now
[01:22] <cjwatson> LaserJock: what's the package name?
[01:22] <LaserJock> qgis
[01:23] <LaserJock> it's a very common/popular GIS gui
[01:23] <LaserJock> I've seen people who use Ubuntu soley for it
[01:24] <LaserJock> I was just reading a forum thread about people wondering where it went, that's how I found out
[01:24] <cjwatson> well, it'll come back if it gets accepted back into Debian before import freeze
[01:24] <cjwatson> or if somebody reuploads it manually to Ubuntu
[01:25] <LaserJock> I'll have to talk to the people who are running the PPA, I think they are upstream developers
[01:26] <LaserJock> maybe I can convince them to maintain it in Debian and/or Ubuntu
[02:11] <ScottK> LaserJock: If it gets into Intrepid, it can be backported to Hardy.
[02:12] <LaserJock> ScottK: good point
[03:30] <TheMuso> StevenK: Any objections to me doing your libsdl1.2 merge? I'm preparing an SRU for it for hardy, and need to get the same fix into intrepid, so I may as well merge while I'm at it.
[03:30] <StevenK> TheMuso: None.
[03:30] <TheMuso> StevenK: Thanks.
[04:38] <WhiteNoise> if anyone is good with cryptsetup and initramfs, please check out this confirmed bug exposed when upgrading to Hardy and the new kernel:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213279
[05:36] <doctormo> Hey is anyone here involved in the Remote-Support thread on the mailing list?
[05:40] <ScottK> I haven't noticed that any of the people significantly involved in it are regulars here (I commented once or twice).
[05:43] <doctormo> ScottK: Ah, i got this stomach turning dread when i noticed the thread; "Ah damn they're reinventing our project"
[05:44] <ajmitch> which project is that?
[05:46] <doctormo> https://launchpad.net/locoremotesupport/
[05:46]  * Hobbsee tends to get people who give her an ssh login, and hand over root access, and say "fix it"
[05:51] <fabbione> morning guys
[05:52] <Hobbsee> morning fabbione
[05:53] <ion_> "ciao a tutti".upcase.l337ize.mirc_colorize
[05:55]  * StevenK slaps ion_ with a large trout.
[05:55] <StevenK> If I can remember mIRC's default ...
[05:55] <ion_> :-)
[05:56]  * ScottK pan fries the trout in butter and has a late night snack.
[05:58] <ajmitch> late?
[05:58] <ion_> Yeah
[05:59] <doctormo> ScottK: I was curious as to what you would make of our project, you seemed interested
[06:05] <ScottK> doctormo: I'm mostly interested in we don't compromise security in order to 'help'.
[06:06] <doctormo> ScottK: yea, something that has brought about grave discussion in our irc channel. One of the reasons we decided to make it elective
[06:06] <Hobbsee> ScottK: oh, but why don't we give ppa access, and so put the correct versions of everything in there, and do an upgrade of critical packages, jus tto fix things?
[06:07] <Hobbsee> blah.  my brain's not doing thoughts in a coherant order, today
[06:07] <LaserJock> nifty idea
[06:08] <LaserJock> "download this package and it will fix everything up for you .. ;-)"
[06:10] <Hobbsee> LaserJock: it's called automatix3, and won't let you turn on your computer again.
[06:10] <ScottK> "download this package and you'll never need to worry about your data again."
[06:10] <StevenK> It melts the machine down and encases it in rapid-set concrete?
[06:12] <doctormo> StevenK: and drops it in a 27 foot hole and covers it with rocks and bolders?/
[06:12] <StevenK> doctormo: Not enough.
[06:13] <doctormo> StevenK: It was a weird-al quote from his "Virus alert" song
[06:13] <StevenK> Haha
[06:16] <doctormo> "Then burn any of the clothes you wore when you were online"
[06:16] <doctormo> hehe
[06:20] <ion_> Sorry if i'm being ignorant (i didn't read the mailing list thread or study the locoremotesupport project), but i'd just like to point out that it would be nice if there were an easy way for a helpee to *connect to me* so that i'd gain access to her system for a single session. She wouldn't need to have something listening to a port, and i would be the one to set up an open port etc.
[06:21] <LaserJock> ion_: that does seem more sane
[06:21] <doctormo> ion_: yes, that is what we're working on, elective ssh support
[06:22] <doctormo> it uses reverse ssh tunnels
[06:22] <ion_> Nice
[06:22] <RAOF> Heh.  That was my one contribution to the thread :)
[06:23] <doctormo> The idea is that it would work even if your on a weird PPoE or a McDonnelds Wifi, although weather you'd want to...
[06:23] <doctormo> RAOF: really? heh, you should have been in #ubuntu-us-ma about 2 months ago when we were talking about it
[06:24] <RAOF> Reverse ssh seems eminently sensible.
[06:26] <doctormo> RAOF: so far we have `ssh -o "StrictHostKeyChecking yes" -nNT -R %s:%s:%s %s@%s`
[07:06] <dholbach> good morning
[07:07] <Hobbsee> morning dholbach
[07:07] <dholbach> hiya Hobbsee
[07:14] <norsetto> heya dholbach
[07:15] <dholbach> heya norsetto
[07:18] <LaserJock> guten morgen dholbach
[07:18] <dholbach> heya LaserJock
[07:19] <nixternal> w00t, 1 more week of classes baby!
[07:19] <nixternal> now I just need to find a job and I will be good to go
[07:20]  * dholbach hugs nixternal
[07:20] <LaserJock> nixternal: job? what's that?
[07:20] <doctormo> programming?
[07:20] <nixternal> I have no clue...only job I have held the last 3 years is right here with all of you :)
[07:21] <nixternal> though I have taken the slacker route obviously
[07:21] <nixternal> I quit Microsoft to work with you LaserJock!
[07:21] <LaserJock> haha
[07:21] <nixternal> for real!
[07:22] <nixternal> people think I quit to go back to school...in all honestly it was you!
[07:22] <LaserJock> yes, my magnetic charisma stole you away from Ballmer ;-)
[07:23] <nixternal> that and he didn't pay worth a crap
[07:23] <nixternal> they hated us so much they gave us crappy office space and all...wouldn't even let us come near redmond
[07:24] <ajmitch> free copies of vista weren't enough for you?
[07:24] <nixternal> oh, you test ms products and linux.....no redmond for you!
[07:24] <ion_> And free chairs
[07:24] <nixternal> ajmitch: you still using that free copy aren't you :p
[07:24] <LaserJock> I've been to the Redmond campus, it's very beautiful
[07:24] <ajmitch> of course
[07:24] <nixternal> LaserJock: I have seen the redmond campus
[07:24] <nixternal> in 2 presentations and on google maps
[07:24] <ion_> laserjock: Any chairs flying around?
[07:25] <LaserJock> ion_: I was just outside waking through, never dared go inside the buildings
[07:25] <nixternal> they would have killed you..they have people dressed up like the imperial forces just waiting to get rid of your hippy ways
[07:25] <LaserJock> I was afraid they'd catch me and make me one of their code monkeys
[07:25] <LaserJock> I didn't have the lasers I have now for just such an occasion ;-)
[07:25] <nixternal> haha
[07:26] <nixternal> my 2 current job offers would require me to leave the community behind...and I can't deal with that honestly...I am to addicted
[07:27] <nixternal> plus mario lemonsquare owes me a drink
[07:28] <ajmitch> require?
[07:28] <nixternal> ya, as in I wouldn't be allowed to work on Ubuntu
[07:28] <superm1> lemonsquare?
[07:28] <ajmitch> harsh
[07:29] <nixternal> ya you superm1 :p
[07:29] <superm1> was that explicitly told to you?
[07:29] <superm1> that you'd have to leave them behind?
[07:29] <Yasumoto> nixternal: that's brutal.. :(
[07:29] <nixternal> superm1: ya
[07:30] <superm1> nixternal, yuck.  w/ what groups/companies are these offers?
[07:30] <nixternal> and the one, was the Red Hat job down there by you
[07:30] <nixternal> but that was business services type stuff...marketing..they would only allow me to use what I was to support/market/manage/whatever
[07:30] <nixternal> the other is my old MS job :p
[07:30] <Hobbsee> !visternal
[07:30] <Hobbsee> evil man.
[07:30] <nixternal> hehe
[07:30] <nixternal> only in your eyes!
[07:31] <nixternal> well, maybe a few others as well
[07:31] <superm1> nixternal, can they really dictate what you do on free time?
[07:31] <lucent> my evil sense is tingling
[07:31] <nixternal> I am hoping on a job opening with a local free software company that won't hamper anything but time
[07:32] <nixternal> superm1: not really, but it is easy for them to use it against you when you are sucking
[07:32] <Hobbsee> nixternal: then surely the solution is not to suck?
[07:32] <nixternal> most definitely, but everyone hits those times when they aren't 100%
[07:32] <nixternal> especially in business management
[07:33] <nixternal> I so wish I would just go ahead and complete my damn CS stuff and forget this business crap
[07:33]  * Hobbsee thought there was more to the range, rather than just '100%' or 'sucky'
[07:33] <nixternal> anything less than 90% is sucky in my books :)
[07:34] <nixternal> unless of course you are talking about the humidity in Chicago, then anything above 60% is sucky
[07:34] <pitti> Good morning
[07:34] <Hobbsee> right.
[07:34] <Hobbsee> morning pitti!
[07:34]  * Hobbsee hugs pitti
[07:34] <nixternal> mornin' pitti
[07:34]  * pitti hugs Hobbsee and nixternal
[07:34] <superm1> nixternal, yeah well down here if you are talking about any part of the year between the end of may and end of august, it's always sucky
[07:34] <Hobbsee> :)
[07:34] <superm1> temperature wise at least
[07:34] <jsgotangco> evil nixternal making this channel noisy again!
[07:34] <nixternal> oh no!
[07:34]  * jsgotangco goes back to work
[07:34] <superm1> haha
[07:34] <\sh> nixternal, you need a new job? overseas? come to germany ;)
[07:34] <ajmitch> hi pitti
[07:35] <nixternal> whatever jerome! you know you want to come back to Chicago
[07:35] <\sh> nixternal, you can work on ubuntu full time ;)
[07:35] <nixternal> \sh: I am on my way!
[07:35] <nixternal> I will FedEx myself in the morning
[07:35] <jsgotangco> nope i am getting an island soon :)
[07:35] <\sh> nixternal, hehe...
[07:35] <nixternal> Blue Island?
[07:35] <nixternal> Stoney Island?
[07:35] <jsgotangco> i was supposed to be in ubuntu live but i have a sched that week elsewhere sunddenly came out i had to decline the slot
[07:36] <\sh> nixternal, na really, I need an add here for the sysadmin stuff, deploying ubuntu on servers, fixing packages, pushing new crack in
[07:36] <StevenK> \sh: Your servers run Automatix?
[07:36] <lucent> jsgotangco: a goose island?
[07:36] <nixternal> \sh: Hobbsee will attest...I am the best crack pusher this community has ever witnessed!
[07:36]  * Hobbsee beats StevenK
[07:36] <\sh> nixternal, you are allowed to even fix flash ,)
[07:36] <Hobbsee> nixternal: no, jdong is.
[07:36] <nixternal> ooh, good one lucent, I forgot about the all important Goose Island
[07:36] <\sh> StevenK, what is automatix?
[07:36] <nixternal> damn, I need to start producing more crack then
[07:37] <StevenK> \sh: Something you should continue to ignore.
[07:37] <nixternal> which they are closing at the end of the year except for their one cruddy spot near wrigleyville
[07:37] <lucent> nixternal: I was going to say "312" but it doesn't make itself immediately obvious to outsiders
[07:37] <\sh> StevenK, i thought the dev of autocracknix told the world that automatix died
[07:38] <nixternal> lucent: where the heck are you at?
[07:38] <nixternal> the name definitely rings a bell living right down the street from lucent
[07:38] <nixternal> hehe
[07:39] <lucent> I'm Eric Shattow
[07:39] <nixternal> have we met?
[07:39] <hunger> So what is the recommended upgrade path hardy/intrepid? Should I just remove the gcc-4.2 stuff? What about perl?
[07:39] <lucent> I live north of Chicago, IL
[07:39] <lucent> I don't know
[07:39] <nixternal> groovy...I am out by Schaumburg
[07:39] <\sh> hunger, there is no upgrade path...there is only pain...real pain...it will hurt...yay...pain is good ,->
[07:39] <RAOF> hunger: The currently recommended upgrade path is "don't".
[07:40] <nixternal> Schaumburg, a nice German town with more Greek restaraunts than you could shake a stick at
[07:40] <Yasumoto> \sh: haha. so reassuring.. :P
[07:40] <RAOF> Incidentally, it's also the currently recommended debootstrap path :(
[07:40]  * \sh doesn't even no Schaumburg...and the story about more greek restaurants...
[07:40] <hunger> \sh, RAOF: I know unstable ubuntu distris. Have been using them since before breezy:-)
[07:40] <Hobbsee> nixternal: do my assignment for me, kthxbye.
[07:40] <Hobbsee> this thing looks woefully stupid.
[07:41] <nixternal> haha, Hobbsee I spent all day doing a bogus Business Needs Analysis
[07:41] <\sh> hunger, it's too early to upgrade...believe us
[07:41] <Hobbsee> nixternal: this assignment refers to the internet consistently as the "InterNet"
[07:41] <nixternal> I faked an interview from about 3 of you in this channel actually :p
[07:41] <Yasumoto> hunger: it's still too early to upgrade yet though. the toolchain isn't even up yet (right?)
[07:41] <\sh> hunger, just try latest debootsrtap from intrepid and try to create a chroot...
[07:41] <hunger> Yasumoto: gcc 4.3 is uploaded and a lot of packages are already build.
[07:41] <RAOF> Yasumoto: The toolchain is, and stuff's building.  The autosync hasn't finished yet IIRC, and it's not debootstrappable at the moment.
[07:42] <lucent> nixternal: I'm unemployed at the moment, work would be interesting
[07:42] <nixternal> hehe, you and I both :)
[07:42] <hunger> Yasumoto: gcc-4.3 transition does not seem done yet and perl is updated but not the perl addon libs.
[07:42] <lucent> I was doing some work as an installer for Allen Visual Systems in Buffalo Grove, IL
[07:43] <RAOF> Hobbsee: I suggest in your response you consistently capItalise rAndom chAracters.
[07:43] <\sh> yay..another re-installation of hardy in only 3 mins...ubuntu-minimal rocks
[07:43] <RAOF> hunger: If you know this, why are you asking how to upgrade?  Either it works or it doesn't, and if it doesn't we don't much care yet :)
[07:44] <lucent> \sh: are we talking about a "netinst" version of Hardy?
[07:44] <hunger> RAOF: I have just checked what aptitude would do. And was wondering whether there are workarounds for these problems.
[07:44] <lucent> my friend asked me today if there exists a netinst version of Ubuntu Server, I told him "no" thinking that there was none
[07:44] <Yasumoto> hunger & RAOFL: gotcha, thanks
[07:45] <\sh> lucent, nope..I'm taking about a nice tool of this Hetzner company...they have actually a nice little util named installimage...and it takes finally 5 mins to install ubuntu...including changing the installation template
[07:45] <Hobbsee> RAOF: heh
[07:45] <\sh> lucent, for simple installations over network you can use the netboot image...
[07:45] <\sh> lucent, for real life mass deployment I advise looking at FAI
[07:46] <lucent> good info, thank you
[07:46] <pitti> yay, intrepid is sane again, perl works
[07:46] <RAOF> hunger: I'm not sure if anyone in here has actually upgraded anything but a build-chroot to Intrepid yet.
[07:46] <\sh> that reminds me, my new two servers arrived...2x DL365, 16GB+16GB, 2x Quad Core Opterons...yay
[07:46] <hunger> pitti: It is? Aptitude still wants to keep back perl since all the libs are not upgradeable at this time.
[07:46] <\sh> 8 Cores for ESX...I'm a lucky guy
[07:47] <lucent> har... I saw a blog entry about "Completely Fucking Slow" (CFS) scheduler
[07:47] <hunger> RAOF: Where is the fun in waiting till everything works?
[07:47] <RAOF> pitti: Oh, does that make it debootstrappable?
[07:47] <pitti> hunger: hm, WFM now, I could dist-upgrade, and now build-essential (which includes perl) installed
[07:47] <\sh> pitti, you are my jesus with this message ;)
[07:47] <pitti> RAOF: should
[07:47] <RAOF> Yay!
[07:47] <pitti> intltool still seems to be broken, though
[07:47] <pitti> libxml-parser-perl
[07:47] <hunger> pitti: Well, I have a somewhat non-standard system, so maybe it is just additional stuff.
[07:47] <RAOF> hunger: Yeah, but where's the fun in installing before _anything_ works?
[07:48] <\sh> if only our a.u.c. servers were letting me sync intrepid..
[07:48] <hunger> pitti: Well, still 33 perl packages waiting to get build... lets see how things are once they are there.
[07:48] <lucent> intrepid?  what's so hot about that
[07:48] <RAOF> lucent: Goats are hot.
[07:48] <lucent> I've run debian unstable before, mostly because it was more or less stable
[07:49] <RAOF> The internet knows that!
[07:49] <pitti> hunger: ah
[07:49] <lucent> compared to say, any other OS I've used for the desktop
[07:49] <pitti> hunger: libxml-parser-perl is current, though
[07:50] <pitti> ah, it was built against the old perl
[07:50]  * pitti does another rebuild
[07:52] <stgraber> morning
[07:54] <\sh> waaaaaa
[07:54] <\sh> passwd -l root
[07:54] <\sh> apt-get install mysql-server
[07:54] <\sh> failed
[07:54] <\sh> Unpacking mysql-server-5.0 (from .../mysql-server-5.0_5.0.51a-3ubuntu5_amd64.deb) ...
[07:54] <\sh> Your account has expired; please contact your system administrator
[07:54] <\sh> chfn: PAM authentication failed
[07:54] <\sh> wth?
[07:55] <\sh> well, sudo su - <-- tells me the same, sudo -i doesn't
[07:55] <ion_> sh: Well, please contact your system administrator. ;-)
[07:55] <\sh> ion_, hehe
[07:55] <\sh> we do agree here, this shouldn't happen
[07:56]  * \sh looks at mysql this evening...
[07:56] <ion_> Do the passwd/shadow lines for root look ok?
[07:57] <\sh> ion_, root is enabled during installation from the rootserver provider...
[07:57] <\sh> ion_, passwd -l root locks root account and make it unusable...it should be the same as the default non-root install now
[07:58] <\sh> i am logged in via useraccount , sudo -i to become root, and install the package...
[07:58] <\sh> mysql-server does something during postinst..and runs into a pitfall, because passwd -l root is not the same as telling the passwd package somehow to not enable root
[07:59] <ion_> Yeah, i'd assume that, but have you actually looked at passwd/shadow? I mean, is passwd/shadow broken by passwd -l root or is e.g. PAM broken?
[07:59] <\sh> ion_, na passwd/shadow are looking sane
[08:00] <\sh> ion_, and no...pam is not broken ;) because in the end everything works.
[08:00] <pitti> yay, with that libxml-parser-perl upload, intltool becomes installable
[08:00] <pitti> and cdbs
[08:01] <TheMuso> The joys of the first weeks of a new release cycle.
[08:01] <pitti> so everyone who would like to see their intrepid upload build, please compile a list of source packages (NO commas in between) and toss it to me, I can give them back
[08:01] <pitti> (their uploads which FTBFSes because of intltool, that is)
[08:02] <Hobbsee> pitti: can't you just get someone to do a mass giveback for anything that didn't build in intrepid?
[08:02]  * \sh checks this afternoon after rollout of companies new product release
[08:02] <TheMuso> pitti: jack-audio-connection-kit
[08:02] <pitti> Hobbsee: yes, infinity can
[08:02] <pitti> (and will)
[08:02] <Hobbsee> pitti: right
[08:03] <pitti> TheMuso: noted, will do
[08:03] <TheMuso> pitti: oh and at-spi
[08:03] <TheMuso> pitti: Thanks.
[08:39] <norsetto> pitti: re. the intltool ftbfs, I only have gnome-radio to be given back
[08:39] <pitti> norsetto: noted down, will do
[08:39] <norsetto> pitti: danke
[09:31] <pochu> pitti: could you also put gstreamer0.10 and libbeagle on that list to give back? re: intltool uninstallable
[09:32] <pitti> pochu: done
[09:32] <pitti> I'm still waiting for the new libxml-parser-perl to become really published
[09:32] <pochu> sure, no hurry. thank you
[09:33] <Ng> pitti: is apport supposed to get disabled at release? or am I on crack? ;)
[09:33] <pitti> Ng: it is supposed to, and it's actually disabled for SIGSEGV-like crashes
[09:33] <pitti> Ng: it's not yet for Python crashes, that's bug 222260
[09:34] <Ng> pitti: ahh, that would explain why we're seeing python crash reports here, thanks :)
[09:35] <cylex> hello.. I am wondering if anyone's home
[09:36] <emgent> morning
[09:36] <cylex> I had a question... if I want to develop something for Xwindows.. like a small app
[09:36] <cylex> morning emgent
[09:36] <cylex> What language do I use?
[09:37] <cylex> C ok?
[09:38] <cylex> or better question.. what languages most packages are written in.. for Xwindows?
[09:41] <pitti> cylex: depends on which language you know and prefer; personally I find Python and pygtk rocking, and it's so easy and fast to develop small GUI apps
[09:41] <pitti> cylex: C works fine, of course
[09:42] <pitti> cylex: BTW, this is off topic here (not related to Ubuntu development, not even to Ubuntu in particular)
[09:43] <cylex> Are there mailing lists or any development places I can go for help
[09:43] <cylex> with this stuff
[09:44] <pitti> cylex: maybe try http://library.gnome.org/devel/gtk-tutorial/stable/ if you want GTK?
[09:44] <cylex> and is it difficult to code with C for GUI?
[09:44] <tseliot> cylex: try asking in the "Programming Talk" section of ubuntuforums:
[09:44] <tseliot> http://ubuntuforums.org/forumdisplay.php?f=39
[09:44] <pitti> cylex: in C it is not more difficult, but much less comfortable than in scripting languages like Python or Perl
[09:45] <lucent> cylex: Gnome lovers will strike me, but the Qt toolkit provides a solid multi-platform base of code in C++ language to work with for professional application development
[09:45] <pitti> cylex: (you need much more code, since C is a low-level language)
[09:46] <lucent> cylex: the other popular choice is Python language with Gtk+ bindings
[09:47] <cylex> ok thanks, you guys been great help :)
[09:51] <cylex> Is there chan on this network for programming talk?
[09:51] <Le-Chuck_ITA> Hi there, I would like to prepare a patch to dexconf, but I don't understand: in /etc/X11/xorg.conf it says that the file is regenerated whenever xorg is upgraded
[09:52] <Le-Chuck_ITA> on my system this does not happen even though I reconfigured X manually to get back the original file without my modifications
[09:52] <pochu> cylex: generally or for a specific language?
[09:53] <chmj> :'(
[09:53] <cylex> pochu: C/gtk for ubuntu
[09:53] <cylex> pochu: language specific
[09:54] <lucent> what the heck is ctrl+Y in irssi hmm
[09:56] <cylex> I think I got it.. I'll just join #c
[09:57] <broonie> Has the process for doing SRUs for main changed in the past 6 months or so?
[09:57] <pochu> cylex: and #gtk+
[09:57] <Le-Chuck_ITA> nobody can tell me how to force xorg.conf to be updated in a patched package for xorg or x11-common?
[09:58] <pitti> broonie: the procedure became a bit more streamlined, and we added a few acceptable cases
[09:58] <pitti> Le-Chuck_ITA: no, because packages must not touch xorg.conf
[09:58] <broonie> Hrm, right. Might be worth trying then.
[09:58] <broonie> Thanks.
[09:58] <pitti> broonie: see the current policy document
[09:59] <pitti> it has been rearranged quite a bit for readability
[09:59] <broonie> The last policy didn't look too bad either...
[09:59] <broonie> But yes, I'll have a look.
[10:03] <Le-Chuck_IT1> pitti: sorry for disappearing so suddenly, my laptop is breaking and sometimes it dies
[10:03] <Le-Chuck_IT1> You said packages shouldn't touch xorg.conf but when is dexconf triggered? Never?
[10:04] <pitti> Le-Chuck_IT1: oh, I just read your previous lines, when I replied I just saw the last one
[10:04] <xivulon> seb128, had a quick look at changing the bookmarks yesterday night
[10:04] <pitti> Le-Chuck_IT1: no, dexconf does not change xorg.conf automatically either
[10:04] <xivulon> but it seems that the default bookmarks are hardcoded :(
[10:04] <pitti> Le-Chuck_IT1: just if you manually do dpkg-reconfigure xserver-xorg
[10:05] <Le-Chuck_IT1> pitti so why in xorg.conf it says that the file is not regenerated when manually modified? Is it just an old comment and should be removed?
[10:05] <xivulon> seb128 would it be possible to change xdg-user-dirs-gtk so that it sources the default bookmarks from a config file?
[10:05] <xivulon> unless you have a better idea on how to do this, that is
[10:06] <pitti> Le-Chuck_ITA: ah, I think it might still be true
[10:06] <seb128> xivulon: I guess everything is possible, it just require somebody doing the changes
[10:06] <Le-Chuck_IT1> er... pitti: now it was pidgin that died
[10:06] <pitti> Le-Chuck_IT1: bryce and tjaalton would know better
[10:07] <xivulon> seb128 I guess by "possible" in this case I mean "appropriate for point release" :)
[10:07] <Le-Chuck_IT1> thank you pitti
[10:07] <pitti> Le-Chuck_IT1: ugh, what's wrong on your machine, that everythign crashes? bad rAM?
[10:07] <seb128> xivulon: well, depends what you suggest to do
[10:08] <Le-Chuck_IT1> pitti: this is a different laptop than the other one really :) This time I think it was a crash in pidgin since I pressed ctrl+w to close a tab
[10:08] <xivulon> seb128, as you know, I would need to change the default bookmarks generated on first login
[10:08] <Le-Chuck_IT1> pitti: the other laptop is dying for something related to temperature
[10:08] <xivulon> I guess my idea would be to have some file in /etc/xdg or such that contains a list of default boomkark types
[10:09] <seb128> xivulon: /etc/xdg/user-dirs.defaults for example?
[10:09] <xivulon> yep, that contains the dirtype <-> dir
[10:09] <xivulon> we need another similar file to give me a list of default dirtypes
[10:09] <\sh> pitti, we need something to ensure, that if some build-deps are name-changing all packages source-build-depending on them are recompiled automatically
[10:10] <xivulon> such as "VIDEOS PICTURES MUSIC... HOST"
[10:10] <pitti> \sh: how do you want to do that? you need actual uploads for that
[10:10] <seb128> xivulon: ok, so you suggest changing the way it's working
[10:10] <xivulon> yep update.c
[10:10] <pitti> \sh: and if the build deps actually change names, you need to modify the source
[10:10] <seb128> xivulon: I'm too busy to look at doing that but if you come with a reasonable patch why not
[10:11] <\sh> pitti: e.g. php5 -> php5-imagick , needs libWand.so.9 now (in hardy) but we have libmagick10 in our archives, and libmagick9-dev still available...
[10:11] <xivulon> seb128: I am not on my machine now (and not too familiar with gnome code) but I will think of something
[10:11] <\sh> pitti, php5 compiled against the old version, so the imagick extension does not work and failes to load
[10:12] <seb128> xivulon: ok, cool
[10:12] <xivulon> seb128 is there any xdg standard for bookmarks?
[10:12] <\sh> pitti, looks like that libmagick9-dev still available, but there is no libmagick10-dev ... I wonder what happend actually
[10:14]  * xivulon reading http://www.freedesktop.org/wiki/Specifications/desktop-bookmark-spec
[10:14] <pitti> \sh: yeah, that's very inconsistent and a broken name
[10:15] <\sh> s/php5/php-magick/ ;)
[10:17] <seb128> xivulon: not that I know about
[10:18] <\sh> pitti, src imagemagick still builds libmagick9-dev ... but somehow we really need to ensure a rebuild of all rdependant packages after such an upload...
[10:18] <xivulon> seb128: I suggest /etc/xdg/user-boomarks as a flat list of  dirtypes
[10:18] <xivulon> seb128: I /etc/xdg/user-boomarks.defaults
[10:19] <\sh> pitti, and kick the maintainer if imagemagick to not take care in the first place ;)
[10:19] <\sh> s/if/of/
[10:21] <\sh> now for an SRU for php-magick, to be just an rebuild ;)
[10:48] <Le-Chuck_ITA> Is there a channel for talking about xorg bugs in ubuntu?
[10:49] <dholbach> Le-Chuck_ITA: try #ubuntu-x or #ubuntu-bugs
[10:51] <Le-Chuck_ITA> thanks dholbach
[11:10] <\sh> hooray...I can create intrepid chroots ;) thx
[11:12] <\sh> pitti, can you give-back ddccontrol? (libxml-parser-perl ftbfs)
[11:23] <emgent> W: Failure trying to run: chroot /home/emgent/.chroots/intrepid dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10ubuntu3_i386.deb
[11:23] <emgent> argh..
[11:24] <emgent> italian mirror dont work fine
[11:25] <\sh> emgent, it's not updated...
[11:25] <\sh> emgent, this problem is resolved since yesterday/today
[11:26] <emgent> i will try to use international mirror :)
[11:28] <\sh> emgent, be careful of leningradskaya ;)
[11:28] <emgent> :)
[11:51] <calc> cjwatson: bug 186049 appears to be it was mentioned in the arstechnica review
[11:56] <cjwatson> calc: yeah, that was why I stuck an 8.04.1 milestone on it
[11:56] <cjwatson> I got to it from arstechnica
[11:57] <calc> ah ok
[11:57] <cjwatson> looks easy to fix and worth fixing
[12:04] <\sh> grmpf...a lot of stuff ftbfs because of this intltool/perl problem earlier on...more difficult that it hit on most of  auto-synced packages
[12:11] <cjwatson> that's what mass give-backs are for ...
[12:14] <\sh> cjwatson, for sure...but it's hard to tell now, if packages are already NEWed + building or NEWed + FTBFS ... the webfrontend is not as nice as it could be ;)
[12:18] <cjwatson> that much is pretty clear from the builds page for the relevant package version
[12:22] <asac> siretart: wpasupplicant 0.6.x - is it safe to just use the debian version or are there any changes you would like to add/keep?
[12:22] <\sh> cjwatson, yes..when you click on the version in <release> first...clicking through the buildlogs to find out why etc...quite long ways for a simple info ;) anyways..
[12:34] <siretart> asac: I was about to ask you, no, AFAIK we can and should just sync the debian package
[12:35] <siretart> asac: if you need to do some changes to the package, let's please do them to the debian package directly, okay?
[12:35] <cody-somerville> Is the UDS "business" or can I say I'm a "tourist"?
[12:37] <asac> siretart: sure. if i add you to ~network-manager team would you upload updates there for the next few weeks (until i have sorted some grave issues for NM 0.7)
[12:37] <asac> to PPA i mean
[12:37] <asac> siretart: i have a question though. how is wpasupplicant started? for me it first didn't start, but then (i don't remember exactly what i fixed) it started automagically
[12:38] <siretart> asac: it depends. from the wpasupplicant maintainers POV, the recommended way is via ifupdown
[12:38] <siretart> see /usr/share/doc/wpasupplicant/README.modes for details
[12:38] <siretart> NM however is starting it on its own behalf
[12:39] <siretart> and AFAIUI, NM 0.7 is supposed to use this dbus activation service thingy, which I haven't seen in action yet
[12:39] <siretart> does this answer your question?
[12:39] <asac> yes its dbus
[12:40] <asac> no, but i'll look closer and ask later i guess ;)
[12:40] <siretart> may I ask why you suggest uploading to the ~network-manager PPA first instead of directly into intrepid?
[12:40] <siretart> or do you want to develop in hardy first?
[12:40] <siretart> asac: if you want we can also phone about that
[12:40] <asac> i am on hardy still yes.
[12:40] <siretart> same here
[12:41] <siretart> I have uploaded a wpasupplicant package in my personal PPA. you should be able to just copy it from there
[12:42] <asac> siretart: cool, would you be available tomorrow? i still need to actually know for sure what i am talking about :)
[12:42] <asac> (phone call)
[12:42] <siretart> I should be. ping me on irc first to be sure
[12:42] <asac> awesome
[12:56] <pitti> \sh: noted; let's see whether it finally got published
[12:56] <pitti> \sh: ah, seems to
[12:58] <\sh> pitti, thx...
[13:00] <\sh> is zope3 working now with py2.5 or is it still only usable with 2.4?
[13:03] <pitti> \sh: I gave back one arch:all test package for now, building now; cross your fingers!
[13:07] <\sh> pitti, I'll pray to the mighty sbuild ... somehow right now everything is blocking my merges/syncs mostly because of missing new package releases ... and in the meantime fighting with stupid commercial software a la adobe flash media server is not even better
[13:07] <pitti> Status:   Successfully built
[13:07]  * pitti does the intrepid dance
[13:07]  * pitti flushes his give-back list
[13:10] <TheMuso> pitti: I've just discovered that ardour, a package that got autosynced, was hit by the libxmlparser-perl issue discussed earlier. That can be given back too while you're at it.
[13:11] <seb128> is launchpad down?
[13:11] <elmo> seb128: works for me?
[13:11]  * ogra points pitti to dia and italc while he is at it
[13:12] <TheMuso> seb128: No problem here.
[13:13] <seb128> elmo, TheMuso: thanks, looks like an url copy error, works now
[13:20] <pitti> TheMuso, ogra: done
[13:21] <ogra> gracias :)
[13:22]  * ogra wnders if we could/should drop hwdb-client from the archive in intrepid ... there are still bugs rolling in for it
[13:22] <TheMuso> pitti: thanks.
[13:24]  * ion_ hopes X in intrepid will gain input hotplug and MPX. I’m going to buy a remote mouse-keyboard combination for sofa usage and keep the current keyboard and mouse on the desk.
[13:25] <ogra> ion_, works for me since gutsy with a wirelesss usb media keyboard
[13:25] <ogra> and didnt break in hardy
[13:26] <ion_> ogra: I mean, i’d really love to have separate focus for both keyboard/mice pairs.
[13:26] <ogra> ah
[13:35] <jcwinnie> Hardy Heron is a marvelous OS and aptly named because it can stand there and do nothing for evah!
[13:35]  * cody-somerville blinks.
[13:36] <siretart> hm. since the upgrade to intrepid, my laptop heats up way more. did anyone notice that as well on his laptop?
[13:36] <ion_> This insight was provided by: having accidentally dropped the baby ten years ago.
[13:36] <cjwatson> ion_: I think that's needlessly harsh
[13:37] <ion_> cjwatson: Sorry, didn’t mean to be malicious.
[13:56] <pitti> seb128: btw, intltool buildd issue in intrepid is solved, happy uploading
[13:57] <Hobbsee> \o/
[13:57] <pitti> infinity: I think now is a good time for a mass-give back in main
[14:02] <infinity> pitti: Kay.  Doing so.
[14:02] <pitti> infinity: cheers
[14:03] <infinity> pitti: When you say "solved", you mean "completely published on drescher", right?
[14:03] <pitti> infinity: yes, I just gave-back some of the failed packages, and they worked
[14:03] <pitti> infinity: well, the Perl issue anyway
[14:04] <infinity> pitti: Alright.  The queues on /+builds just got a lot longer again.
[14:05] <pitti> :)
[14:05] <ogra> sigh
[14:06]  * ogra watches dia explode again on other missing packages now
[14:06] <ogra> i guess i'll wait a week asking for the next give back
[14:24]  * ogra sighs about tuxtype merge ....
[14:25] <Hobbsee> what about it?
[14:25] <ogra>   * use dh_desktop to add maintainer script fragments to call
[14:25] <ogra>     update-desktop-database
[14:25] <ogra> from the latest debian changelog
[14:25] <ogra> but there is no .desktop file in the whole package
[14:25] <ogra> (it never had one)
[14:26] <ogra> i'D love to drop our patch tat creates one if i knew debian added on
[14:26] <ogra> e
[14:26] <Hobbsee> interesting.
[14:27] <ogra> oh, debian uses ours in the same place
[14:27] <ogra> thats why it didnt show up in the patch
[14:51] <Riddell> "W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/intrepid/universe/binary-i386/Packages.bz2  Hash Sum mismatch" humph
[15:17] <cjwatson> testing germinate-update-metapackage changes is no fun with a loaded archive.u.c
[15:31]  * ogra wonders when mom runs again, all stuff i uploaded yesterday still shows up
[15:32] <andrew___> Hi, I'm Andrew Sayers.  Martin Owens wanted to talk to me - are any of you him?
[15:32] <cjwatson> andrew___: doctormo
[15:33] <cjwatson> ogra: stuck on archive.ubuntu.com coming up to date, which is having serious load trouble
[15:33] <ogra> ah, still ?
[15:33] <cjwatson> IS are aware, but we have those pesky users
[15:33] <ogra> i thought that was solved
[15:33] <andrew___> cjwatson, thanks.  I'll nudge him.
[15:34] <ogra> well, i using a localhos apt-proxy here in pbuilder and for the chroots so i dont really notice slowness anymore
[15:34] <ogra> s/i/i started/
[15:40] <doctormo> hey andrew___
[15:42] <doctormo> andrew___: thanks for popping by, email can be fustrating at times.
[15:43] <doctormo> So our plan is to have vnc-x11 running over the reverse ssh tunnel. my guess is that this is a similar plan as yours
[15:45] <doctormo> the ssh part is set up by creating a support user, creating a random password (putting it in .bashrc as an echo) using the helpers public ssh keys to get access over the tunnel. keys are transmitted over jabber (ssl)
[15:46] <andrew___> Yeah, our plans have gone a little further since then :)
[15:47] <andrew___> I've not really talked to Justin about this, but I'm personally most interested in the case of nearly-broken systems.
[15:47] <doctormo> As you may have noticed, I've been working on the support tool side of things.
[15:47] <andrew___> Busted video card, dist-upgrade cancelled halfway, etc.
[15:47] <andrew___> Where you really can't make many assumptions at all about the system.
[15:47] <andrew___> (e.g. Python working)
[15:47] <doctormo> andrew___: broken video card means a trip to the nearest techy, not a support call
[15:48] <andrew___> Yeah, once you've confirmed that's what it is.
[15:48] <doctormo> Anything that would undermine the system, we would ask users to load a live cd
[15:49] <andrew___> That's another thing - we're looking at the "technical friend" case...
[15:49] <doctormo> andrew___: meet leftyfb, a technical friend who is my case.
[15:49] <andrew___> As in, you get a phone call from a friend of yours saying "hey, you know something about Linux, right?  Well, my computer doesn't work.  Please fix it"
[15:49] <andrew___> Hey leftyfb.
[15:50] <leftyfb> hi
[15:50] <leftyfb> i've already done all this a few times using scripts ... works well
[15:50] <doctormo> andrew___: I'm sure we're all used to taking those calls, but leftyfb has a whole load of people doing that to him.
[15:51] <andrew___> leftyfb, are they available online somewhere?
[15:51] <leftyfb> nope, i write them up as needed .... all it does is ssh back to me and create a reverse tunnel
[15:51] <andrew___> Ah right.
[15:52] <doctormo> So, we were talking about the very broken case leftyfb, where the computer has a hardware fault or isn't software sane.
[15:52] <leftyfb> doctormo's project will simplify this with a nice gui, but also provide the ability to troubleshoot some things without needing full ssh access. It also audits the whole process with a ticketing system
[15:52] <leftyfb> oh
[15:52] <leftyfb> uh
[15:53] <leftyfb> nothing you can do there
[15:53] <andrew___> My original impetus for this was a friend that had a power cut (or similar) halfway through an upgrade to 8.04.
[15:53]  * Hobbsee wonders what happens if ssh is dead.
[15:53] <leftyfb> unless the tool is included on the live cd
[15:53] <leftyfb> or we put one out
[15:53] <doctormo> Hobbsee: we can still help via chat
[15:53] <Hobbsee> doctormo: i guess you can't do anything if nm decides to fall over.
[15:53] <andrew___> Hobbsee, use socat, or cryptcat, or netcat, or try to resurrect ssh with custom config files...
[15:53] <doctormo> Hobbsee: yep
[15:54] <leftyfb> Hobbsee: I think we talked about that ... doing some basic testing of an inet connection and either fixing it if it's absent or forcing one for the session
[15:54] <andrew___> The actual code we're looking to write is looking like it'll be a general mechanism for creating a session on one computer, accessible from another, using whatever tools are available/working.
[15:55] <leftyfb> what about adding in your own ssh daemon and making x11vnc a dependency of the tool?
[15:57] <andrew___> Again I haven't talked to Justin about this, but I'd like to have a tool with no explicit dependencies, then metapackages called something like technical-friend/nontechnical-friend that depend on a useful collection of tools.
[15:58] <doctormo> andrew___: I didn't want to get too far into the broken use cases, there is only so much you can mitigate before you end up http://xkcd.com/416/
[15:59] <andrew___> True.  I'm not planning to go nuts about that sort of thing until there's some evidence for what actual problems people have in real life.
[16:00] <doctormo> andrew___: there is no reason why a cli version of our support tool couldn't be made. your scripts could download deps if broken.
[16:00] <doctormo> but I'd want to mop up these things after the first release
[16:00] <andrew___> True, although it's overkill for a friend that you're already talking to on the phone.
[16:01] <andrew___> Would you agree with this general assessment:
[16:03] <andrew___> You want to create a Jabber-based support tool that makes it easy for a sitting group of experts to debug the computer of someone they don't know, and in order to do that, you need a tool to start SSH or VNC sessions, although that's not really where your technical interest lies.
[16:03] <doctormo> andrew___: not quite, leftyfb knows all the people he helps but would still use this tool
[16:04] <leftyfb> this tool is for people I already know, at home, who need help from me and need to give me access to logs/etc or full ssh/vnc access to help troubleshoot their problem. You don't create scripts for helping people over the phone.
[16:04] <doctormo> andrew___: and, past tense. Have created a jabber-based...
[16:04]  * Robot101 would like to point out that Telepathy and Empathy provide excellent infrastructure for such a tool...
[16:05] <leftyfb> jabber is more established
[16:05] <doctormo> leftyfb: er, they're just a set of gtk widgets and libs for chat
[16:05] <Robot101> yes, telepathy uses it, amongst other protocols
[16:06] <doctormo> leftyfb: imagen libpurple but for gnome ;-)
[16:06] <Robot101> we've actually got branches to Empathy which let you click a buddy and share your desktop with him
[16:06] <Robot101> telepathy deals with nat traversal etc for you, you just ask it for a "stream tube"
[16:07] <leftyfb> so this would be instead of using python to create the client which doctormo has already done?
[16:07]  * ogra just read steam tube above :)
[16:07] <Robot101> mm, well there are benefits to integrating with an existing mechanism of communicating with people
[16:08] <leftyfb> i'll let doctormo handle that part of it :)
[16:08]  * Robot101 thinks this is very much a use case we'd be interested in addressing
[16:08] <leftyfb> my only concern is the security and functionality of the tool, now how it's made :)
[16:08] <cody-somerville> crap
[16:08] <doctormo> Robot101: It's an interesting idea, I'd need convincing since I've spent time getting pyxmpp working with all the business logic we have.
[16:08] <Robot101> so you can be IM or VOIP chatting with someone and then they can say, oh yeah this pops ups, what do I do
[16:08] <Hobbsee> ogra: you can have steam if you want.
[16:09] <Hobbsee> ogra: but it's probably not useful.
[16:09] <Robot101> then you can just click share desktop, and the other guy gets a libnotify, clicks OK, and is then in the VNC viewer...
[16:09] <ogra> Hobbsee, telepathic steam :)
[16:09] <cody-somerville> If I cancel a dput upload in progress, what are the implications?
[16:09] <doctormo> ogra: sounds like a doctor who
[16:09] <ogra> haha
[16:09] <Robot101> also it works over link-local contacts using the bonjour backend
[16:10] <Robot101> that being somewhat the purpose of the abstraction :)
[16:11] <doctormo> Robot101: We're doing fancy stuff with ticket handeling, auditing and various other things. Useful for one to one help, though community help use case is not there.
[16:12] <Mithrandir> cody-somerville: it gets thrown away.
[16:13] <cody-somerville> Mithrandir, \o/ cheers.
[16:13] <doctormo> But it sounds interesting, maybe future versions could use it, though I'd not want to risk changing direction now that we're so close to finishing the first version
[16:14] <Robot101> doctormo: reading scrollback a bit, it sounds like you're solving a slightly different set of problems
[16:14] <leftyfb> remote support that's easy for the user to install and use to give us access to help them
[16:14] <Robot101> doctormo: but I just thought I should let you know there are some options for the p2p/interactive support case where you're already using IM/VOIP to talk to someone
[16:15] <Robot101> seems to me like adding new users to the system and requiring sshd to be installed is kinda overengineering isn't it?
[16:15] <leftyfb> nope
[16:16] <leftyfb> ssh = ability to fix anything
[16:16] <hunger> Robot101: Incoming connections are blocked in most home setups.
[16:16] <leftyfb> lots of other programs add users/groups ....   vmware for one
[16:16] <Robot101> hunger: exactly why you should leave this to the NAT traversal experts :D
[16:16] <leftyfb> hunger: this works off reverse ssh connections
[16:16] <leftyfb> no inbound ports needed
[16:17] <hunger> leftyfb: Oh, great:-) Then why do you need a sshd?
[16:17] <leftyfb> uh
[16:17] <Robot101> oh, maybe I misunderstood
[16:17] <doctormo> hunger: how would it do it otherwise?
[16:17] <leftyfb> you want me to answer that?
[16:17] <leftyfb> :)
[16:17] <Robot101> does the user's system need sshd installed?
[16:17] <leftyfb> yes
[16:17] <leftyfb> how else are you going to connect to them?
[16:18] <Robot101> so the helper ssh's to the user's system?
[16:18] <andrew___> leftyfb, ssh client != ssh daemon
[16:18] <hunger> Does the outgoing SSH do port forwarding so that somebody can via that?
[16:18]  * leftyfb sigh
[16:18] <Robot101> or the user ssh's somewhere, with a port forward, so the helper can ssh back?
[16:18] <doctormo> andrew___: can you create a reverse tunnel without sshd?
[16:18] <andrew___> What are you referring to as a "reverse tunnel" here?
[16:18] <Robot101> doctormo: (yes, use a stream tube from telepathy :D)
[16:19] <doctormo> hunger: no port forwarding
[16:19] <doctormo> Robot101: no steam tubes ;-)
[16:19] <Robot101> can you explain in terms of a sequence of connections (who connects to who) how it'd work?
[16:20] <leftyfb> customer ssh's to our remote/secure server using generated ssh keys using an account that doesn't have shell access. This creates a reverse tunnel back to their local sshd service. We, as support, login to the server and ssh to the localhost port created by the reverse ssh tunnel giving us access to the customers account. All automated. Customer see's a pretty chat windows with a "remote access button". We click connect and up comes gnome
[16:20] <leftyfb> -terminal with the connection open.
[16:20] <doctormo> Robot101: user -> server, helper -> server -> user
[16:20] <Robot101> this seems alarmingly overengineered. cool. :)
[16:21] <leftyfb> overly secure is the word you are looking for
[16:21] <Robot101> encrypting things more times isn't more secure, and nor is granting remote shell access to people without being able to supervise (or even understand) what it is they're doing
[16:21] <doctormo> Robot101: I'm larry wall lazy
[16:21] <andrew___> If you're assuming the user has a GUI fired up, why not use VNC?
[16:21] <Robot101> andrew___++
[16:22] <doctormo> I'll let leftyfb handle these questions
[16:22] <leftyfb> I use this method all the time just fine
[16:22] <leftyfb> we don't always need VNC access
[16:22] <leftyfb> in fact, VNC is just going to slow most troubleshooting down
[16:22] <leftyfb> most things can be fixed via ssh
[16:22] <Robot101> VNC has the benefit that the user can /see/ what the helper is doing
[16:22] <doctormo> We want to use vnc access to show the user how to do things, not to do things ourselves
[16:23] <leftyfb> if the user request that, then that's what we use
[16:23] <andrew___> Also, they can type in their passwords without telling you them.
[16:23] <leftyfb> but it's not the default method of troubleshooting
[16:23] <leftyfb> a lot of users don't care
[16:23] <leftyfb> we will have a local account with sudo access
[16:23] <leftyfb> we don't need their passwords
[16:24] <leftyfb> again, this isn't the first program to create local accounts/groups to get things done
[16:24] <andrew___> That's fair enough for people that know you, but training users to hand out root access to people online they've never met seems like a bad plan.
[16:24] <doctormo> Robot101: We use auditing, although users don't generally mistrust their geeky friends
[16:24] <Robot101> it's the first program I've heard of which automatically grants local root access to 3rd parties :P
[16:24] <Robot101> and also installing a sshd service behind the user's back, unless you bind it localhost only or something, seems extremely undesirable
[16:25] <doctormo> Robot101: who said anything about automatically?
[16:25] <Mithrandir> uh, is this a package which is going to go into the normal repositories?
[16:25] <leftyfb> andrew___: people give M$ compete access to their computer when doing remote support. This support tool is meant to be used by groups/companies providing support to a large customer base
[16:25] <Hobbsee> Mithrandir: supposedly.
[16:25] <leftyfb> it will be bound to localhost
[16:25] <Hobbsee> Mithrandir: i'm sure it will show up as forums crack for a while
[16:25] <leftyfb> the sshd
[16:25] <Robot101> doctormo: automatically as in "Do you want foo to fix your system? [ Yes ]" is sufficiently automatic
[16:25] <Hobbsee> fix == sudo rm -rf /
[16:25] <leftyfb> it'll be a custom sshd access only accessible via pregenerated keys and via localhost only
[16:26] <Robot101> oh well. I prefer the idea that you can hook these things into a conversation with someone, and not let them do things you can't see.
[16:26]  * Hobbsee grins maliciously
[16:26] <Robot101> which could be sharing a pty and exporting it over a socket, or VNC
[16:26] <doctormo> Robot101: that's because you know what your doing
[16:27] <Hobbsee> "i'm a core dev, of course i'll fix your getdeb'enated or automatixenated machine!"
[16:27] <Robot101> doctormo: yes, not letting 3rd parties cheese around with my system :P
[16:27] <andrew___> Robot101, speaking of PTYs, can Telepathy do that on its own?
[16:27] <doctormo> Robot101: Some people don't mind
[16:27]  * Mithrandir makes a mental note to get that package blacklisted from all his hosts.  Seriously, shipping a package that includes a) pregenerated ssh keys and b) new user with full sudo access?  Are you guys completely out of your mind?  What happens when you lose the private SSH key to a disgruntled employee or a cracker?
[16:27] <leftyfb> ssh access is preferable and MUCH quicker for someone that just wants to finish their report and doesn't care how the person is fixing their computer
[16:27] <Robot101> Mithrandir: yeah seriously
[16:27] <doctormo> Mithrandir: thanks for joinging the discussion constructivly
[16:27] <Robot101> andrew___: no, it'd be something the "support app" would hook up and provide to telepathy
[16:28] <Hobbsee> doctormo: the guy is an archive admin, FYI.  and also a core dev.
[16:28] <Mithrandir> to quote somebody much smarter than me, the interesting bit about security system is not how they work, it's how they fail.
[16:28] <Hobbsee> doctormo: you may not want to blow him off like that.  he might end up reviewing your package, fi it goes into ubuntu.
[16:28] <Hobbsee> it's called karma.
[16:28] <Robot101> andrew___: telepathy itself is plumbing, it abstracts different protocols and types of communication. one of them is "tubes" for plugging arbitrary apps together.
[16:28] <doctormo> Hobbsee: I'm not partial to being treated baddly even by karma gods
[16:29] <andrew___> Robot101, Yeah, I'm starting to understand.  You can rip on my idea later ;)
[16:29] <Hobbsee> Mithrandir: i'm assuming they generate the ssh keys on the fly, though.
[16:29] <Hobbsee> Mithrandir: they'd have to...
[16:30]  * cody-somerville is scarred to ask what is being discussed.
[16:30] <Hobbsee> cody-somerville: see ubuntu-devel-discuss ML
[16:30] <Robot101> cody-somerville: remote support tools
[16:30] <Mithrandir> Hobbsee: oh, how would you do that?  You'd need to do secure key exchange somehow, then.
[16:30] <Hobbsee> cody-somerville: system recovery by ssh, basically, for non-secure users.
[16:30] <Robot101> andrew___: in this case, telepathy would use XMPP to say you'd started a local VNC/whatever service (which could be "Share my desktop" or "Share a terminal" or such)
[16:30] <Hobbsee> Mithrandir: dunno - send by email / other IM is all i'm really coming up with.  But that's still better than pregenerated.
[16:31] <doctormo> Hobbsee: not seeing what you guys are talking about, maybe not required?
[16:31] <Mithrandir> Hobbsee: yes, it's better than pregenerated, but it didn't sound like what leftyfb/doctormo was talking about.
[16:31] <cody-somerville> I've never found it very difficult to tell someone how to install openssh-server and how to add a new account for me.
[16:31] <cjwatson> doctormo: if you guys are trying to solve the key exchange problem, I suggest reading the several decades' worth of cryptographic literature on the subject ... it's not a trivial problem
[16:31] <cody-somerville> Or how to get them to enable the remote desktop
[16:31] <doctormo> cjwatson: nope
[16:31] <Mithrandir> doctormo: prove me wrong by showing me a page with a thorough design and analysis of the security architecture, then.
[16:31] <Robot101> andrew___: and then when the remote user accepts, it'll signal over XMPP and do some negotiation (TCP, NAT traversal, tunnel via the server) to open the connection
[16:31] <doctormo> not trying to solve that
[16:32] <cjwatson> doctormo: it sounds like a necessary element
[16:32] <hunger> KDE has a system where a user generates invitations (valid for 60min) that can get submitted to "support guys" via mail or whatnot.
[16:32] <cjwatson> doctormo: if you aren't trying to solve it, the system seems fatally flawed ...
[16:32] <Mithrandir> cjwatson: either that or ship pregenerated keys with all the fun that entails.
[16:32] <Hobbsee> Mithrandir: true
[16:32] <hunger> Whoever has that invitation can get a VNC session.
[16:32] <Hobbsee> doctormo: you have to have some way of generating the key, and getting it to the clued user.
[16:32] <doctormo> Mithrandir: remind me what the keys are for again?
[16:32] <Hobbsee> doctormo: root access on the system.
[16:32] <ogra> doctormo, safety :)
[16:32] <Mithrandir> doctormo: you need to log into the localhost-only ssh?
[16:33] <Mithrandir> doctormo: technically, you could use a preset password, but that would be even worse.
[16:33] <doctormo> public key of the helper copied over to client on elective basis? must be missing something since you guys seem very concerned
[16:34] <ogra> well, without that you can as well use telnetd
[16:34] <Hobbsee> doctormo: because listing the private key in a publically available source is akin to suicide.
[16:34] <Hobbsee> doctormo: which appears to be what you're thinking about doing.
[16:34] <doctormo> Hobbsee: I didn't mention private key
[16:34] <Hobbsee> doctormo: so, how does the private, and public key, get generated?
[16:34] <doctormo> Hobbsee: what public private key?
[16:35] <cjwatson> doctormo: I think what we're missing is how the server gains access to the user's machine
[16:35] <Hobbsee> 2 keys.
[16:35] <Mithrandir> doctormo: yes, the public key.  How do you get it onto the system and copied into this brokensystem:~helper/.ssh/authorized_keys?
[16:35] <Mithrandir> s/this/the/
[16:35] <doctormo> Mithrandir: xmpp
[16:35] <Mithrandir> doctormo: so you're vulnerable to mitm attacks then.
[16:35] <doctormo> Mithrandir: jabber using ssl? odd
[16:37] <Mithrandir> to a host where you ship the ca certs used for the host in the package itself and do proper certificate validation, then?  In that case, who are running the CA?
[16:37] <leftyfb> the jabber connection is SSL and the ssh is encrypted. What mitm?
[16:37] <Mithrandir> SSL isn't magic powder you can sprinkle on a TCP connection to make it secure, it takes a little bit more than that.
[16:37] <hunger> Mithrandir: The community of course;-)
[16:38] <Mithrandir> but I have to go now.  Drop me a link to a design document about this and I might go poke at it and see if I can find weak spots.
[16:38] <doctormo> Mithrandir: your skill may be required
[16:38] <cjwatson> the CA here is a great big target for compromise
[16:38] <hunger> Who will do the support by the way?
[16:38] <Hobbsee> require all you like.
[16:38] <Hobbsee> hunger: them, methinks.
[16:38] <cjwatson> Hobbsee: easy ...
[16:38] <Mithrandir><EMAIL_ADDRESS>or just highlight me here.)
[16:38] <hunger> Hobbsee: Them, who?
[16:38] <Hobbsee> hunger: it's not an #ubuntu issue unless it gets in the archive, afaik.
[16:38] <leftyfb> the client generates their own private keys on installation, then sends the public key via xmpp to the server via our "bot" which places it in the proper ~/.ssh/authorized_keys for the session and removes it when the session is over
[16:38] <Hobbsee> hunger: those who are writing the system
[16:39] <Hobbsee> leftyfb: bot?
[16:39] <leftyfb> jabber client
[16:39] <doctormo> Now that we've struck fear into the hearts of ubuntu developers.
[16:39] <Hobbsee> leftyfb: how does that scale?
[16:39] <leftyfb> scale?
[16:39] <leftyfb> speak english please
[16:39] <hunger> doctormo: Assuming that the system is safe: Who will do the support?
[16:40] <cjwatson> leftyfb: "scale" is perfectly normal English in system design
[16:40] <Hobbsee> leftyfb: as in, how will it work with<PHONE_NUMBER> users, for eg?
[16:40] <doctormo> hunger: business is the main candidate
[16:40] <hunger> doctormo: Which business? Is there a company doing the support?
[16:40] <doctormo> hunger: That is probably the problem right there.
[16:40] <hunger> doctormo: Are you developing this for a company?
[16:40] <leftyfb> Hobbsee: what would the difference be with supporting 10 users as opposed to 1000? If it gets beyond 1000, of course you need to think about multiple servers and load balancing
[16:41] <cjwatson> doctormo: is the server capable of sending essentially arbitrary commands to the client (upon request by the helper)?
[16:41] <doctormo> hunger: no
[16:41] <doctormo> cjwatson: no
[16:41] <Hobbsee> leftyfb: right, so this would be a service you were charging to your users, running on your HW, i take it.
[16:41] <cjwatson> doctormo: is it capable of sending any commands to the client?
[16:41] <doctormo> cjwatson: no
[16:42] <hunger> How do you select the helpers if this is a community effort?
[16:42] <leftyfb> Hobbsee: for right now, i'll be using this to support my own customers who I do consulting for. We as a LoCo team will also use it as a group to support people we come in contact with.
[16:42] <leftyfb> hunger: carefully
[16:42] <cjwatson> doctormo: I think I'm missing how it's useful, then; I thought the point of this was to be able to remotely extract information from the client system
[16:42] <Hobbsee> cjwatson: it's to remotely fix it - adn to set up an ssh tunnel so they can.
[16:42] <leftyfb> signed pgp keys and CoC signing is required
[16:42] <doctormo> cjwatson: It's able to send information upon request, the supporter tool is able to send requests for information and requests for access.
[16:43] <cjwatson> doctormo: so it must be capable of sending some kind of command to the client, then? (Note I don't necessarily mean shell command here.)
[16:43] <doctormo> cjwatson: there is a difference between the server and the supporter client.
[16:43] <doctormo> which do you mean
[16:44] <cjwatson> err, I don't know your precise terminology. I mean the client as in the end user's system (as a whole) and the server as in the thing that both the client and the helper connect to.
[16:44] <doctormo> cjwatson: ok, the server is not able to send commands, it can send information to both the supporter (helper) and the suportee (client) upon request
[16:45] <doctormo> It's actually a bot program
[16:45]  * Hobbsee is greatful that e l m o has not been highlighted about this.
[16:45] <cjwatson> I'm not bothered about the implementation; I want a data and command flow diagram really
[16:45] <cjwatson> doctormo: how is information extracted from the client system?
[16:46] <doctormo> cjwatson: I see, supporter tool sends request to client tool, client tool asks user if it's ok. information is sent back.
[16:46] <cjwatson> what format do the requests take? They must have to be pretty general
[16:47] <doctormo> cjwatson: not that general, for instance to request logs: "@request logs xorg" would ask for xorg logs (various) which are pre-defined.
[16:48]  * Hobbsee assumes that's after the authentication.
[16:48] <cjwatson> I think what is confusing us is that you and leftyfb seem to be talking about radically different things
[16:48] <cjwatson> leftyfb is saying things like:
[16:48] <cjwatson> 16:23 <leftyfb> we will have a local account with sudo access
[16:48] <cjwatson> 16:23 <leftyfb> we don't need their passwords
[16:48] <cjwatson> 16:25 <leftyfb> andrew___: people give M$ compete access to their computer when doing remote support. This support tool is meant to be used by groups/companies providing support to a large customer base
[16:48] <cjwatson> 16:25 <leftyfb> it will be bound to localhost
[16:48] <cjwatson> 16:25 <leftyfb> the sshd
[16:48] <cjwatson> 16:25 <leftyfb> it'll be a custom sshd access only accessible via pregenerated keys and via localhost only
[16:49] <doctormo> cjwatson: I'm a programmer, leftyfb is a sysadmin we talk on different levels.
[16:49] <andrew___> doctormo, what does "@request logs ../../etc/shadow" do?
[16:49] <cjwatson> that isn't "different levels", that's a completely and utterly different designm
[16:49] <doctormo> andrew___: sends an error
[16:49] <leftyfb> i'm talking about ssh access
[16:49] <andrew___> doctormo, Good :)
[16:49] <cjwatson> leftyfb: so I think we should be interrogating you about your plans, rather than doctormo about his :-)
[16:49] <leftyfb> doctormo: is talking about the programs ability to send logs/etc to the helper without giving ssh access
[16:49] <cody-somerville> leftyfb, If you want ssh access to someones computer, get them to install the openssh server and create you an account. It is very very easy already. What use case are you trying to fullfill here?
[16:50] <cjwatson> leftyfb: how do you plan to arrange for safe authentication?
[16:50] <Hobbsee> cody-somerville: the 'user is clueless, can't do that'
[16:50] <leftyfb> I don't have much part in the design/implementation of the requesting logs part, only the giving ssh access part
[16:50] <Hobbsee> cody-somerville: the idea of one-click-authentication, etc.
[16:50] <Hobbsee> (i assume)
[16:50] <cody-somerville> Hobbsee, No matter how clueless the user is, they can type in what you tell them to pretty easily.
[16:50] <Hobbsee> s/authentication/implementation/
[16:50] <cjwatson> I'm much happier with what doctormo outlined above than anything that involves "type in what you tell them"
[16:51] <leftyfb> cody-somerville: my grandmother doesn't want to install ssh, generate keys, set it up for localhost access only, and ssh to me, creating a reverse ssh tunnel
[16:51] <doctormo> cody-somerville: I've done remote support a lot, it's not that easy behind a router.
[16:51] <Hobbsee> cody-somerville: actually, they can't.  i've seen all sorts of users doing strange things, when you tell them to type in some commands.
[16:51] <andrew___> cody-somerville, it's not so much a matter of clueless, as good at describing things.
[16:51]  * _MMA_ hates the idea that"users are clueless" and the dumbing-down that goes on because of it. But that's a topic for a different time.
[16:51] <Hobbsee> leftyfb: how does the localhost access only?
[16:51] <Hobbsee> er, stuff work?
[16:51] <cjwatson> type in what you tell them might involve "sudo apt-get install symlinks; sudo symlinks -d /" for example, which looks just as innocuous as many other commands one might request that a user issue, but will subtly screw up the user's system
[16:51] <Hobbsee> by definition, isn't the idea that it's remote, ssh'ing in?
[16:51] <cody-somerville> leftyfb, and all of that is required why
[16:51] <cody-somerville> ?
[16:52] <leftyfb> Hobbsee: you can configure sshd to only listen on localhost
[16:52] <cody-somerville> doctormo, true.
[16:52] <Hobbsee> leftyfb: yes, i know, but then, if you can't physically get to the box, you can do nothing.
[16:52] <andrew___> cody-somerville, For example, I was helping out a fairly technical friend lately, and we went round in circles for about 15 minutes because he hadn't understood that lines beginning with a '#' are comments
[16:52] <leftyfb> cody-somerville: security, simplicity as far as the user is concerned ... no firewalls to mess with
[16:52] <cjwatson> security is not achieved simply by adding ssh to the equation
[16:52] <Hobbsee> leftyfb: if you're going to do that, then why not just get the user to login, sudo -s, put in their password, then tell them to go make coffee for a while?
[16:52] <andrew___> (Or indeed that '#' is a character that needs spelling out)
[16:52] <cjwatson> which is why I asked the question above "how do you plan to arrange for safe authentication?"
[16:53] <leftyfb> cjwatson: security is achieved by ONLY allowing ssh to the customers machine via keys and a reverse ssh tunnel
[16:53] <cjwatson> leftyfb: how are those keys distributed?
[16:53] <doctormo> cjwatson: I'll get you a diagram, I think I have one
[16:53] <hunger> leftyfb: Where do the keys come from?
[16:53] <cjwatson> leftyfb: I'm interested in cases where there is no customer<->consultant relationship as well
[16:53] <Hobbsee> cjwatson: by the xmpp, which is vulnerable to mitm attacks, as Mithrandir said.
[16:54] <Hobbsee> hunger: presumably they get generated on first launch.
[16:54] <cjwatson> Hobbsee: please let them answer the questions I've posed, rather than answering for them
[16:54] <leftyfb> I already said that ... the ssh keys are generated at install time .. the public key is then sent via XMPP to the server where the "bot" on the server puts the keys into the proper place for the session and removes the keys after the session is closed
[16:54] <hunger> Hobbsee: Can't work... the consultant will need to have the private key so that he can authenticate.
[16:54] <Hobbsee> cjwatson: apologies, i was effectively regiving answers discussed above.
[16:54] <leftyfb> Hobbsee: the public key is sent to the server, not the private key
[16:55] <Hobbsee> leftyfb: i think that was directed at hunger
[16:55] <hunger> leftyfb: How does that allow the consultant to gain ssh access to the requestors computer?
[16:55] <doctormo> There are two instances were public keys are transmitted
[16:55] <cjwatson> leftyfb: the supporter needs to have a private key that grants authentication to the client system. How does the server ensure that the public key matches a trusted user?
[16:55] <cjwatson> s/user/supporter/
[16:55] <leftyfb> our public keys are either prepackaged or uploaded to the client at install and/or via xmpp for the session ... same drill
[16:55] <doctormo> leftyfb: not quite
[16:56] <leftyfb> sorry, not at install
[16:56] <cjwatson> leftyfb: what happens the first time the server is compromised and starts allowing evil public keys?
[16:56] <leftyfb> during the session
[16:56] <Hobbsee> hunger: er, the consultant generates the keypair, then sends it to the broken system, not the other way around.
[16:56] <doctormo> cjwatson: the public key for the supporter is transmitted over xmpp to the client.
[16:56] <hunger> Hobbsee: Yeap. But I do not get how it gets there.
[16:56] <Hobbsee> hunger: that's the discussion now
[16:56] <cjwatson> doctormo: that simply pushes the authentication problem one step back
[16:56] <doctormo> cjwatson: probably
[16:57] <hunger> Hobbsee: Yeap... that was what I was trying to ask, too:-)
[16:57] <cjwatson> you still have to trust that the supporter is Alice Aidgiver, not Evil Eye
[16:57] <cjwatson> s/Eye/Eve/
[16:57] <leftyfb> cjwatson: what happens when the support/client/server/canonical is compromised?  We work on not letting that happen.
[16:57] <cjwatson> so you have to authenticate that somehow
[16:57] <cjwatson> leftyfb: Canonical has a key rollover procedure for compromise of the central archive key
[16:57] <doctormo> cjwatson: The supporter doesn't send the public key, the server does. the server has a list of good guys
[16:57] <cjwatson> leftyfb: I expect the same of any similarly-critical system
[16:58] <cjwatson> doctormo: how is that list maintained?
[16:58] <Hobbsee> cjwatson: out of curiosity, is that documented publically anywhere?  i'd be interested in seeing what that is.
[16:58] <doctormo> cjwatson: at the moment, by hand
[16:58] <cjwatson> Hobbsee: no, though it probably should be (with the list of people you need to mug excised)
[16:58] <Hobbsee> cjwatson: heh, yes.
[16:59] <cjwatson> so I think this probably can be made secure, but it does need a competent security review, and for its proponents to be willing to make changes as a result of that review as necessary
[16:59] <doctormo> cjwatson: I agree
[17:00] <Hobbsee> oh, ffs.
[17:00] <doctormo> I'm not a security expert and I would a fool to sugest otherwise.
[17:00]  * Hobbsee goes off to rant elsewhere.
[17:00] <cjwatson> and you *will* encounter problems. At some point you have to assume that a supporter will go bad.
[17:00] <leftyfb> cjwatson: public keys will be flushed from the customer's system and the server each time a session is created and repopulated with the public key from the supporter uploaded via xmpp on the fly (yes doctormo ,this is new but doable)
[17:00] <doctormo> cjwatson: yes, I've thought about that.
[17:01] <doctormo> not enough to solve it though
[17:01] <leftyfb> that sound better?
[17:01] <cjwatson> leftyfb: the key rollover problem I refer to is that, when the server is compromised, you need to have a trusted way to re-secure all clients
[17:01] <cjwatson> because you will have to regenerate the keys used to authenticate the server to the client
[17:01] <leftyfb> if the server is compromised, they get nothing. No ssh private or public keys, no access to ssh to anywhere using passwords
[17:02] <cjwatson> err
[17:02] <doctormo> leftyfb: no, your suggestion won't work
[17:02] <leftyfb> ?
[17:02] <cjwatson> that can't be true, given what you've said
[17:02] <cjwatson> the client is given supporter keys by the server
[17:02] <cjwatson> ergo, the server has a means to authenticate its identity to the client
[17:02] <cjwatson> this further implies that a compromised server can feed evil supporter keys to the client
[17:03] <cjwatson> (only once a client connects of course, but that's just a matter of time0
[17:03] <cjwatson> )
[17:03] <doctormo> cjwatson: those keys are use once, if the server is recovered the effects are null
[17:03] <cjwatson> doctormo: we're talking about different keys
[17:03] <doctormo> I think so
[17:03] <cjwatson> I don't mean the session keys for an individual client<->supporter session
[17:03] <cjwatson> I mean the keys that protect the exchange that delivers new session keys
[17:04] <cjwatson> there must be such keys
[17:04] <doctormo> Over ssh or xmpp? just to be sure I understand
[17:04] <cjwatson> transport is unimportant
[17:04] <cjwatson> at the level of protocol design, details of transport are a distraction and best ignored
[17:05] <doctormo> cjwatson: no I mean not in tech terms. in our context where we are using ssh or where we are using xmpp.
[17:05] <cjwatson> I honestly haven't followed in enough detail to know and it doesn't matter to my question
[17:05] <xivulon> out of curiosity, is this a different problem from a (trusted) repo providing packages as opposed to keys?
[17:05] <cjwatson> xivulon: it's related
[17:05] <doctormo> cjwatson: true, it just matters for my understanding
[17:06] <xivulon> then couldn't similar techniques be applied in both cases?
[17:06] <cjwatson> xivulon: that's part of where I'm headed
[17:06] <cjwatson> but it's dangerous to make too many assumptions up front ...
[17:07] <doctormo> OK (this is implimetation detail), the client does have the configration for the server in a nice xml file, it has the servers public key which is used to confirm that the server is who it says it is.
[17:08] <doctormo> This I think is what you mean
[17:08] <cjwatson> doctormo: from what I recall I *think* you described this as being by xmpp but I am honestly not sure
[17:08]  * ogra finds the words "nice" and "xml file" in one sentence disputable :)
[17:09]  * cjwatson waves the "distraction" flag again
[17:09] <doctormo> cjwatson: So if the server becomes evil, the public key in the config is invalid and potentially evil?
[17:09] <cjwatson> doctormo: correct
[17:09] <doctormo> right
[17:10] <doctormo> So far we're only using that key for the ssh connection, we're not using it for xmpp which just connects using dns only. not very secure as it doesn't certify the server (afaik)
[17:10] <cjwatson> yes, that's horrible
[17:11] <cjwatson> no secure protocol may rely only on DNS
[17:11] <doctormo> As for public key updating... I'll have to think about the problem
[17:12] <doctormo> colin if you know of an existing solution, do tell
[17:13] <cjwatson> my suggestion would be that the server public key should reside in a package and only ever be updated out of band (i.e. by package updates, thus transferring the problem to that of archive signatures); furthermore, in order to ensure that clients are updated as quickly as possible after a compromise, there should be a way for the client to check whether newer versions of itself are available with newer keys, and refuse to run i
[17:13] <cjwatson> or something along those lines
[17:14] <cjwatson> if xmpp relies on DNS for authentication of remote identity, I think you should rethink your use of that problem
[17:14] <leftyfb> compromised server + customers broken package management = no support tool
[17:14] <cjwatson> err ... of that protocol
[17:14] <cjwatson> leftyfb: yes
[17:14] <leftyfb> and if this were to get into the main repositories, updating keys would be dependent on how quick canonical is with pushing the updates
[17:15] <cjwatson> yes
[17:15] <cjwatson> though not just Canonical
[17:16] <doctormo> cjwatson: I agree with your idea, I believe xmpp can be made to check validity of the server more rigerously
[17:16] <hunger> leftyfb: You do not want to have your own package repos for this? Is everybody supposed to get the same config (== end up on the same server)?
[17:16] <doctormo> hunger: indeed, very good question +1
[17:16] <hunger> Or will you modify the config for the users your company wants to support?
[17:17] <cjwatson> I think it is probably a good idea for commercial support offerings to run a separate server, or deliver separate configuration in some other way
[17:17] <doctormo> There is the possibility of having a number of servers available, both LoCo, canonical offical support maybe even system76 available from ubuntu repos and the tool could let the user decide
[17:18] <hunger> I really do not see the need for such a package in a distribution... Maybe in some enterprisy thingy with support contracts, etc.
[17:19] <hunger> "Community support" with access to the system in question does smell too much like inviting random idiots from the net to break install troyans to me.
[17:20] <hunger> Maybe that is just me... but I doubt it.
[17:20] <leftyfb> what about having a list of of server to join for remote support. The servers would be the different LoCo's willing to provide support, possibly Canonical, system76, Dell, etc
[17:20] <doctormo> hunger: that is a concern i have, I imagen the good name of a LoCo being the basis for community support. Those who lead such groups would have to be trusted to only allow trusted people in, as above PGP signed keys and CoC would be a good start
[17:21] <hunger> doctormo: LoCo? CoC? Sorry, my english sucks:-(
[17:21] <ogra> hunger, local communities
[17:22] <ogra> hunger, coc = code of conduct ... dude you hang around in this channel since how many years ?
[17:22] <leftyfb> LoCo - Local Community    CoC = Code of Conduct which all official ubuntu members need to agree to and sign
[17:22] <hunger> Well, in a support forum you can not post responses that will do bad-stuff since everybody can see it and will tell you.
[17:23] <hunger> With some single guy messing with your system via SSH: Who is ever to know?
[17:23] <doctormo> hunger: yes, there is an audit, but ultimatly root access is root access. If someone intentionally or mistakenly hurts a machine then it's the group that must make amends.
[17:24] <hunger> doctormo: Audit?
[17:24] <doctormo> hunger: nothing fancy, the ~/bash_history is sent to the server after disconnect. it could be removed if someone was malicious though.
[17:24] <leftyfb> again, who's to say a Microsoft support employee isn't going wipe your "My Documents" folder when he's doing remote support?
[17:25] <leftyfb> This is the nature of remote support
[17:25] <leftyfb> you assume the helper is to be trusted
[17:25] <leftyfb> there's no way to ensure it
[17:25] <doctormo> hunger: the only real barriers we can put in place are organisational, not technical
[17:25] <cjwatson> with a Microsoft support employee, you have a contractual relationship and can at the very least prove which legal entity was responsible for the breach
[17:25] <hunger> leftyfb: Sure, but with a MS support guy there is a company that gives its (good?) name and says "that guy will not mess up your system". And you can sue them if they misbehave;-)
[17:26] <cjwatson> this environment is different because it's quite possible you won't even know whom to prosecute under the Computer Misuse Act
[17:26] <cjwatson> which lays the server operator open to subpoenas for logs, etc.
[17:26] <doctormo> cjwatson: not a problem, subpoenas aren't always a bad thing
[17:27] <cjwatson> right, but I think it's important to bear in mind that "make amends" may be a little more than "we're sorry, we won't do it again"
[17:27] <cjwatson> the system has to be designed up-front to avoid problems
[17:27] <doctormo> cjwatson: i agree, it may be "get sued into bancrupsey"
[17:27] <hunger> doctormo: They do cause work that somebody has to do:-)
[17:27] <cjwatson> I liked the sound of a system that could only offer certain predefined classes of information on request
[17:27] <cjwatson> that's a lot better than "some guy gets a root shell by ssh"
[17:27] <hunger> doctormo: And that work will end up on the server admin's desk...
[17:28] <cjwatson> ~/.bash_history> unset HISTFILE; do malicious things
[17:28] <doctormo> cjwatson: It isn't some guy though, it's a person the server knows, who has a signed PGP key and who the server operators personally know.
[17:28] <cjwatson> I'd suggest keeping a connection trace instead
[17:28] <doctormo> cjwatson: I never found out how to do that, that was my first thought
[17:28] <cjwatson> personally know> that wasn't clear to me from the above. You mean somebody whom the server operators have met?
[17:29] <doctormo> cjwatson: yes
[17:29] <doctormo> But again, that is organisational
[17:29] <cjwatson> that doesn't sound like it will scale as people want
[17:29] <cjwatson> which means there'll be pressure to breach that
[17:29] <hunger> cjwatson: That is not a good idea either! Think what kind of info might end up in such a trace. Having that stored on the server does not sound too good an idea.
[17:29] <doctormo> cjwatson: I know, but it's important to organise the organisational scalling too
[17:30] <hunger> cjwatson: Plus the SSH connection is encrypted and not visible to the server anyway.
[17:30] <doctormo> hunger: the ssh is a double hop through the server
[17:30] <doctormo> couldn't the server trace from there?
[17:31] <hunger> doctormo: So I can put arbitrary info into any currently running ssh session streams if I gain access to the server?
[17:31] <cjwatson> hunger: logging just the supporter->client side of the exchange (and not client->supporter) wouldn't reveal anything private
[17:31] <cjwatson> or at least is unlikely to
[17:32] <doctormo> hunger: not sure, maybe
[17:32] <hunger> doctormo: No, from what I understand the supporter logs directly into SSH on the users box (going through port forwarded to the server).
[17:32] <cjwatson> hunger: port-forwarding on the server => server can snoop
[17:32] <cjwatson> actually, no, I suppose that isn't true
[17:32] <hunger> cjwatson: It can snoop an SSH stream...
[17:32] <cjwatson> yeah, end-to-end encrypted
[17:33] <hunger> cjwatson: Not very informative;-)
[17:33] <cjwatson> hunger: however, the client software could report a trace of what the supporter asked it to do
[17:33] <cjwatson> (obviously you can't trust a malicious supporter to do so)
[17:33] <hunger> So logging needs to be done either by the supporters system or by the users system. Both are under the control of the supporter...
[17:34] <cjwatson> that could still be nobbled by the supporter, but it would raise the bar, particularly if it were done immediately rather than at the end of the session
[17:34] <doctormo> hunger: at the moment it's set up so the supporter logs onto the server, then logs into a localhost port to log into the tunnel to the client
[17:34] <cjwatson> if it were done immediately, then the last thing in the trace would be <supporter nobbles reporting software> which would be a big alarm bell in itself
[17:34] <cjwatson> provided that you report all commands before execution
[17:35]  * ogra wonders if the landscape team couldnt give some hints on secure connecting remotely
[17:35] <hunger> cjwatson: SSH can force commands to execute... you could have that forward the commands back to the server before handing it to a shell.
[17:35] <hunger> s/SSH/sshd/
[17:36] <cjwatson> hunger: there's no obvious reason to do this by ssh alone. It should be something richer on the client side that can receive a command format, report them, and execute them as appropriate.
[17:36] <cjwatson> hunger: (p.s. I maintain our openssh packages)
[17:36] <doctormo> cjwatson: that would be interesting
[17:36] <hunger> cjwatson: Something we have not considered is that the supporter could set up SSH tunnels, bypassing your firewall configuration.
[17:37] <cjwatson> hunger: which is yet another reason allowing the supporter to execute arbitrary commands is an unwise design
[17:37] <cjwatson> DDTT
[17:37] <doctormo> cjwatson: although more alarm bells
[17:37] <hunger> So he can even attack the system or others...
[17:37] <Hobbsee> cjwatson: DDTT?
[17:37] <cjwatson> don't do that, then
[17:38] <leftyfb> If we aren't trusting the supporter, then this tool is useless
[17:38] <cjwatson> leftyfb: that's not true at all
[17:38] <doctormo> leftyfb: you just have to be able to catch supporters that go bad, auditing is good for that.
[17:38] <cjwatson> the supporter can be given the ability to ask for certain information and get it automatically, and then recommend certain courses of action under the control of the user
[17:39] <cjwatson> it's not an all-or-nothing thing, and presenting it as such is harmful
[17:39] <leftyfb> I need this tool for root ssh access to my customer box's when they have problems. Without this, I won't be using this tool. Simple as that.
[17:39] <cjwatson> leftyfb: so make the tool flexible enough that it can offer that to *you* where you have a contractual relationship with the customer, but don't turn that on for general user support over the Internet
[17:39] <doctormo> leftyfb: no reason it can't do both, if the server doesn't have ssh support, the client won't allow ssh
[17:40] <cjwatson> leftyfb: you don't have to make your requirements mandatory in the tool as a whole
[17:40] <hunger> leftyfb: I think it is a great tool for a company/customer relationship. I just do not think community support with root access is a good idea.
[17:41] <andrew___> It sounds like you guys are coming at this problem from different directions.   doctormo and leftyfb are starting with tech support for friends and scaling up, cjwatson is looking at a way of automating/real-timing some of the work of the Ubuntu forums.
[17:41] <doctormo> andrew___: both doable using the existing tool
[17:42] <leftyfb> we need to start small to support customers we have now
[17:42] <doctormo> cjwatson: I've organised the support tool so that commands can be added on quite easily.
[17:42] <cjwatson> andrew___: that's not an accurate representation of my position, FWIW
[17:42] <andrew___> cjwatson, what would be more accurate?
[17:42] <hunger> andrew___: I don't need such a tool to support friends and get supported by them. krfb is great for that:-)
[17:42] <cjwatson> andrew___: I have nothing to do with the forums; my interest is in ensuring a secure design for any software that is offered to users of Ubuntu
[17:43] <andrew___> cjwatson: Fair enough.
[17:43] <cjwatson> (and, FWIW, I would rather have no software than insecure software in this case; although I accept that it is a significant requirement and I suspect it can be made acceptably secure with some effort)
[17:43] <doctormo> cjwatson: and I thank you for your help.
[17:43] <leftyfb> hunger: the biggest advantage of this tool I see is not needing to open up ports on their firewall/router
[17:43] <leftyfb> cjwatson: i'm of the opposite opinion
[17:44] <cjwatson> leftyfb: that's fair enough, but part of my job is ensuring high standards of software in Ubuntu
[17:44] <hunger> leftyfb: Sure. But I can do that when I set up a system:-)
[17:44] <cjwatson> leftyfb: you are (obviously) entitled to do whatever you like within your customer relationships
[17:44] <leftyfb> hunger: i prefer not to poke holes in the customers network
[17:45] <hunger> leftyfb: In a commercial setting you will have a hard time to sell a firewall-bypass-tool.
[17:45] <cjwatson> leftyfb: but, when it gets offered to all Ubuntu users, it comes within my purview
[17:45] <cjwatson> (among others)
[17:45] <leftyfb> hunger: gotomypc, logmein, teamviewer
[17:46] <hunger> leftyfb: I found it much easier to ask them to open a port which is then documented in their security documentation than to "sneak in" some piece of software.
[17:46] <doctormo> leftyfb: there is no reason why we can't have the more advanced features enabled by us personally or by some simple option. Normal internet wide servers wouldn't do ssh but our own would.
[17:46] <hunger> leftyfb: Maybe we are talking about different kinds of customers here:-)
[17:47] <doctormo> hunger: It's not sneaking in,
[17:47] <ogra> there are many corporate environments where you cant get more than http and mail protocols through the firewall by policy and getting another port open can take you months to get approval fro from all parties involved
[17:47] <hunger> doctormo: If it is not approved by the IT department and documented in the security guidelines, then it is sneaking in.
[17:48] <hunger> ogra: Sure. But it can get you kicked out of the company if you get caught going round the firewall, too.
[17:48] <ogra> judging from myself, thats actually the majority of companies i have worked for doing it in such a way
[17:48] <hunger> doctormo: Well, that tool is probably not targeted at companies with a IT department anyway.
[17:49]  * hunger has to run.
[17:49] <ogra> run hunger run
[17:49] <ogra> :)
[17:50] <doctormo> ogra: remind me, were you at UDS "Boston"?
[17:50] <ogra> doctormo, yep., i think we met outside several times
[17:50] <doctormo> I think so too
[17:50] <ogra> you're the one from the local loco, right ?
[17:51]  * ogra refines to typo the name of the state he cant pronounce either :)
[17:51] <doctormo> Yes, Ubuntu-US-MA this might explain the development
[17:52] <ogra> ah, right there is an abbreviation i forgot :)
[17:52] <Amaranth> Massachusetts
[17:52] <ogra> Amaranth, :P
[17:52]  * Amaranth used spell check
[17:53] <ogra> i still cant pronounce it without getting knots in my tongue :)
[17:53] <LaserJock> hah
[17:53] <LaserJock> ogra: I feel the same about many German city names ;-)
[17:54] <doctormo> You get used to the spelling after a while
[17:54] <ogra> Amaranth, oh, while you are here, i put willow on the uds agenda :)
[17:54]  * Amaranth runs
[17:54] <doctormo> ogra: we were talking at uds about dohickey and hardware tools
[17:54] <ogra> LaserJock, yeah, understandable ... my hometown is easy though
[17:54] <ogra> doctormo, ah, yeah, cr3 is doing all that now
[17:55] <andrew___> Since there's a lull in the other debate, cjwatson: how come sshd allows password authentication by default?
[17:55] <andrew___> (I asked this in launchpad, but since you're here...)
[17:56] <doctormo> ogra: I thought canonical had dropped hardware information projects? I assume this because I heard nothing from anyone.
[17:56] <ogra> doctormo, we have a new tool that hooks in with LP now
[17:57] <ogra> hwtest-gtk
[17:57] <ogra> (had to look that up)
[17:57] <sladen> it died because nobody would share the data from the project
[17:58] <ogra> sladen, its still ongoing
[17:58] <ogra> just not 100% finished afaik
[17:58] <sladen> s/died/has not achieved its full potential/
[17:58] <doctormo> ogra: forgive me if i'm not hurt by being left out.
[18:01] <cjwatson> andrew___: well, it's the upstream default as well. I tend to think that it's sufficiently useful in many environments to be left on by default, though I'm not surprised by people turning it off
[18:03] <andrew___> Isn't it a serious security issue though?  It's alright for upstream, because OBSD users can be trusted not to use abc123 as a password ;)
[18:03] <cr3> doctormo: hiya, how's it been since last uds?
[18:04] <cr3> ogra: thanks for pimping my wares :)
[18:04] <ogra> :)
[18:04] <Hobbsee> andrew___: if they're that stupid and install an ssh server with such a p/w, don't they *deserve* to be rooted?
[18:05] <doctormo> cr3: Busy, very busy.
[18:05] <andrew___> Hobbsee: not if Ubuntu is supposed to be Linux for human beings, no.
[18:05] <cjwatson> andrew___: well, considering that we don't install an SSH server by default, it hasn't particularly worried me
[18:05] <mjg59> andrew___: There's no default username, and there's no default password
[18:05] <Hobbsee> andrew___: then remove all their input devices.
[18:06] <cjwatson> it was perhaps more of an issue when we did
[18:06] <doctormo> cr3: I was just talking to ogra about how I've not had any emails from you guys about hardware information and detection.
[18:06] <cjwatson> anyway, got to go ...
[18:06] <andrew___> Bye - thanks.
[18:08] <cr3> doctormo: the limiting factor here is mostly on the launchpad side where additional hardware detection would not supported by the relaxng schema.
[18:09] <cr3> doctormo: I would like to see the schema eventually evolve to support more clever hardware detection such as done by dohickey, but Launchpad should first provide an interface for the existing schema before evolving it.
[18:11] <doctormo> cr3: launchpad may be the wrong place to create a schema, although I'm sure you'd disagree at this point. it's too late.
[18:12] <doctormo> when I get back to dohickey, I'll come calling and see what you've learned that I could aply
[18:12] <cr3> doctormo: it is necessary for the schema to be defined server side in order to provide a form of validation before storing the information in a database
[18:14] <cr3> doctormo: consider any rpc system for example, it is the server which enforces somekind of api in the form of a schema, dtd, idl, etc.
[18:14] <pitti> seb128: hah! I now got one common fakechroot error case fixated in a test case, and I can perfectly reproduce it on my desktop, without mixing different chroots, etc.
[18:15] <pitti> seb128: I was afraid that the combination of dapper system + gutsy chroot + hardy fakechroot mixed shlibs in a way to break this
[18:15] <cr3> doctormo: I don't quite see how this could be debated so, perhaps I misunderstand what you mean by: launchpad may be the wrong place to create a schema
[18:16] <cr3> doctormo: did you mean another server should be used for displaying hardware results to the community such as the dohickey server or the smolt server even?
[18:21] <andrew___> doctormo: About LoCoRemote, it's worth having a poke about at http://popcon.ubuntu.com/ to see what package people tend to have on their systems.  For example, it looks like only about 20% of people have an SSH server already installed.
[18:26] <pitti> seb128: ah, and the test still succeeds in feisty and gutsy; that explains the regression in hardy; apparently hardy's rm uses a new stat()-like call which isn't recognized by hardy's fakechroot
[18:28] <andrew___> Speaking of popcon, does anyone know how there can be 541,530 submissions to popcon, only 540,735 of which had popularity-contest installed?
[18:29] <pitti> andrew___: apparently you can submit your system data several times?
[18:29] <ogra> it is an optional thing
[18:29] <ogra> so not really something to base actual statistics on
[18:29] <andrew___> Sure, but how do you submit data if you don't have the program to submit it?
[18:30] <pitti> andrew___: I mean, those wo do have it installed might have submitted more than once
[18:30] <andrew___> Yeah, but then popularity-contest would show up more than once.
[18:31] <andrew___> Maybe the other handful were installing popularity-contest from source or something.
[18:36]  * ogra tries to imagine a hand with 800 fingers
[18:37] <ogra> :)
[18:49] <andrew___> If two parties share a secret of, say, 10 or 20 characters, is there a security algorithm that could give you reasonable security for a few kilobytes of text, implementable in sed (or Perl with no modules)?
[18:50] <doctormo> cr3: What I meant was that the schema for hw information is not static, launchpad doesn't ahve the tools to deal with dynamic hardware schemas yet.
[18:52] <doctormo> andrew___: I wonder if it's worth having a seperate ssh package which is pre-configured for localhost, unsure of the solution with regards to sshd
[18:53] <andrew___> I'm not sure I follow - what would that involve?
[18:56] <awalton__> andrew___, depends on your definition of "reasonable."
[18:57] <andrew___> awalton__: unlikely to be cracked within 20 minutes?  At a guess.
[18:57] <awalton__> but then again, perl is turing complete, even without its modules, so I guess the answer is "yes"
[18:57] <andrew___> True.  Do you have any particular pointers for where I might look?
[18:58] <awalton__> google, wikipedia are often where I start.
[18:58] <ogra> andrew___, if you use ssh, then you surely have ssh-keygen installed?
[18:58] <awalton__> you could probably do a small blowfish implementaiton...
[18:58] <andrew___> ogra: if I've got SSH, I don't need to worry about such hacks :)
[18:59]  * andrew___ makes note to look for Blowfish implementations in Perl
[19:01] <andrew___> Basically, I'm browsing popcon and thinking that sed, perl and netcat are amazingly popular and can probably be convinced to work with just a binary...
[19:01] <awalton__> or if you want a really, really small implementation, something like xtea or RC4, but they're both substantially weaker :-/
[19:01] <andrew___> sed and netcat are even in /bin, so get around problems with /usr failing to mount.
[19:03] <andrew___> Not so much small as possible for me to verify (and write if absolutely necessary), given my lack of security training.
[19:04] <awalton__> is it even worth it though? does it matter?
[19:04] <andrew___> Depends how hard it is.
[19:05] <seb128> pitti: ah ok
[19:06] <pitti> seb128: currently digging in the fakechroot code to add an implementation for the missing newfstatat()
[19:06]  * seb128 hugs pitti, good work
[19:06] <andrew___> If I can put something together in an afternoon that's a guaranteed "download this and follow the instructions" solution for anything from a 90's NetBSD to a modern Leapord, I'd say yes :)
[19:06] <pitti> none of the new *at() functions are implemented :/ (http://lwn.net/Articles/164887/)
[19:17] <Riddell> doko: any idea what causes an error like this? http://paste.ubuntu.com/10990/
[19:23] <Riddell> doko: seems I have to add -ldl for some reason
[19:30] <lamont> mvo: is your util-linux change for #157763 something that should go in long-term upstream?
[19:36] <lamont> meh.  no mvo
[19:37] <pitti> seb128: BANZAI!
[19:59] <jdong> is archive.u.c under stress? it's responding very slowly to me
[20:00] <pitti> yes, it is
[20:00] <pitti> both mirroring drescher (master archive) and downloading from it take ages
[20:00] <jdong> oh
[20:00] <cr3> doctormo: perhaps a schema allowing for dynamic data could be proposed for launchpad. any suggestions?
[20:33] <LaserJock> geeze, 2 times in 2 days I find a package I'm interested has been removed from Hardy :(
[20:36] <bimberi> hi LaserJock, which one? iirc qgis was the other.
[20:36] <Mithrandir> andrew___: look at http://www.cypherspace.org/adam/rsa/perl-dh.html to get a key exchange going, then you have a session key and can use that with regular crypto.  I'd probably just use "openssl bf" or similar, though.
[20:38] <LaserJock> bimberi: ksynaptics
[20:39] <LaserJock> my touchpad has too many "features" on it that are very annoying so I was hoping to turn them off
[20:40] <LaserJock> I think I'll just do it in xorg.conf and see how that goes
[21:20]  * pitti uploads another fakechroot which now finally works again for hardy
[21:20] <pitti> \o/
[21:20] <pitti> bdmurray: ^ FYI, that means I can reactivate the retracers (will do tomorrow, too late now)
[21:23] <bdmurray> pitti: sweet!
[21:34] <Caesar> pitti: so I've got various small bugfixes I'd like to get into hardy-proposed
[21:35] <Caesar> I presume I can't upload there because my key's not in the keyring, so I'll need sponsorship?
[21:38] <jdong> Caesar: main or universe? (make sure it meets SRU policy and follows the SRU process)
[21:39] <geser> Caesar: yes, you'll need sponsorship. Have you already an ACK from the (correct) SRU team?
[21:39] <jdong> even developers must get approval from the appropriate SRU approval team to ACK the request before uploading
[21:42] <doctormo> cr3: I thought you'd seen dohickey, next UDS in mountin view I'll have to show you how it works
[21:46] <Caesar> jdong, geser, where/how do I get SRU team blessing?
[21:46] <Caesar> Point me at docs, I'll go read
[21:47] <geser> Caesar: https://wiki.ubuntu.com/StableReleaseUpdates
[21:47] <Caesar> thnx
[21:47] <cr3> doctormo: you showed me dohickey in person and I took the time to look at the code on the client side. I have to admit I didn't look at the server side but, apparently, I'm missing out :) thanks for pointing this out
[21:53] <doctormo> cr3: It has a schema for dynamic data using data pathing
[22:36] <cjwatson> andrew___: I'd second Mithrandir's recommendation of something pre-cooked. Designing your own cryptosystem without security training is a really bad idea, and 20 characters => 160 bits => probably worthless for security purposes
[22:39] <andrew___> Yeah, that link is a good idea (thanks Mithrandir).  Actually, I'm starting to think that it's better to use small, simple tools to make the whole "recovery from a nearly-broken system" idea redundant.
[22:40] <andrew___> Hence posting to ubuntu-devel-discuss about dealing with failed mounts.
[22:48]  * davidm is away: I'm busy
[22:54] <cjwatson> andrew___: to back up my "160-bit keys are worthless for security purposes" statement: I just tested msieve (http://www.boo.net/~jasonp/qs.html) on my laptop with a series of 160-bit numbers that were products of two random 80-bit primes. The mean time taken to factorise each was .67 seconds.
[23:01] <andrew___> Bearing in mind my lack of security training, does that mean that any amount of information that could usefully be transferred over the phone is only useful in the context of something like a password in an SSH session?
[23:05] <andrew___> (Where by "usefully transferred over the phone", I mean "dictated phonetically at one character per second for less than 30 seconds")
[23:16] <Mithrandir> andrew___: tbh, I'd recommend using SMS-es or a similar out-of-band medium for transferring a passkey, preferably with a very short time span (5 minutes)
[23:16] <Mithrandir> so you'd get an sms with "the server should tell you abcd1234 and you should tell it gargleblaster"
[23:17] <andrew___> That's still only 160 characters max. though?
[23:17] <Mithrandir> it's not foolproof, but it's probably one of the better key exchanges you can come up with today.  It has a cost associated, but if you're in a business relationship, that should't be a problem.
[23:18] <Mithrandir> that doesn't really matter so much, since you'd need to make it short-lived and lock the password on three wrong tries
[23:18] <Mithrandir> of course, an attacker can continually request new passwords, but you might notice that your phone keeps getting new passcodes and then react on that.
[23:19] <Mithrandir> but then, I think this is a good idea, so find somebody smarter than me to poke holes in it and tell you on what points I'm wrong.
[23:20] <andrew___> Yeah, part of the reason I prefer an actual phone call is because you can at least verify that they sound like the right person.
[23:20] <Mithrandir> social engineering is typically quite easy, especially in a business situation.
[23:21] <andrew___> My personal interest is in tech support for friends.  If I was looking at a business thing, the first thing I'd do would be to get them to pay for me to physically go there and set up a reasonably secure login.
[23:22] <Mithrandir> between friends, social engineering is harder, agreed.
[23:23] <Mithrandir> and between friends, well, I wouldn't want a bot to message me, since that probably meant the login was actually going through a third party I had no reason to trust.
[23:23] <Mithrandir> trust is bloody hard to manage and is not transitive, which makes this a problem.
[23:23] <andrew___> You're thinking of doctormo and leftyb, I'm looking at a completely different thing :)
[23:24] <Amaranth> hrm, i thought the bug squad had access to all ubuntu bugs
[23:25] <Mithrandir> Amaranth: not security ones, I'd have thunk.
[23:25] <Amaranth> security doesn't mean private though, apparently
[23:25] <Amaranth> although i guess if you set it private and security it might lock the bug squad out
[23:26] <Mithrandir> andrew___: true, but if you're serious about having some decent security in your system, sit down and make a design document explaining what and how and let people poke holes in it.
[23:26] <Mithrandir> after a few iterations, we might have something that none of us are clever enough to break, at least.
[23:27] <Mithrandir> and it's not the crypto that's going to be the hard part.  It's the procedures, the social engineering and how your components fit together and managing trust between them.
[23:27] <andrew___> Sure - as soon as I can get to the end of a sentence without falling through eight of those holes.
[23:27] <mneptok> Amaranth: you won;t have access to private bugs of paid Canonical customers.
[23:27] <Mithrandir> mneptok!
[23:27] <mneptok> Mithrandir!
[23:27] <Mithrandir> mneptok: crazy man, how are things?
[23:27]  * mneptok spews ponmies and glitter
[23:27] <mneptok> *ponies
[23:28] <Amaranth> some guy is complaining about aptoncd but his bug report is private
[23:28] <mneptok> not too bad. the jbailey replacement has finally arrived. that's quite nice.
[23:28] <mneptok> Amaranth: bug#?
[23:28] <Amaranth> bug 221839
[23:28] <Mithrandir> mneptok: ah, sounds good, and about time
[23:29] <wgrant> Amaranth: Security issues are private by default.
[23:29] <mneptok> Amaranth: no access here, either. not private because of a paid relationship.
[23:29] <mneptok> Mithrandir: no kidding. it's been too long.
[23:29] <doctormo> andrew___: some completly different remote support tool using reverse ssh tunnels then
[23:29] <mneptok> Mithrandir: keeping busy? reporting to your parole officer as expected?
[23:30] <Mithrandir> mneptok: keeping busy, yes, lots of fun and learning, which is good.
[23:30] <Mithrandir> mneptok: billing customers is kinda weird, though. :-P  Given that I didn't work in such a position at C
[23:30] <andrew___> doctormo: probably.  as of right now, I'm still trying to work out what the actual missing pieces are in the puzzle.
[23:31] <Mithrandir> andrew___: do you have a document explaining what the problem you are trying to solve is?
[23:31] <doctormo> andrew___: the main parts? well I see people as a missing part, people that can be trusted. but this may not be the same as your problem.
[23:31] <Mithrandir> and some rough sketches of your approach to solving it?
[23:31] <Amaranth> wgrant: Yeah but some guy set a compiz bug as a security issue just because he wanted someone to look at it
[23:32] <Amaranth> That's when I noticed security didn't automatically mean private
[23:34] <andrew___> Mithrandir: short answer - nothing worth reading yet.  As I say, I'm still getting my head around things.
[23:34] <Mithrandir> andrew___: ahkay.  Once you have that, tell me and I'll be happy to see what holes I can poke in your solution. ;-)
[23:34] <andrew___> Thanks :)
[23:36] <andrew___> I suppose the basic problem I'm looking at is: someone you know has a system that doesn't work, and your phone number exists somewhere in the list of things ways they know how to fix computer problems.  How do you get said friend's computer working?
[23:36] <Mithrandir> I would probably pull out my bike and bike over or ask them to bring the laptop to my place.
[23:37] <andrew___> Most of the people I know are not within biking distance :s
[23:37] <Mithrandir> hehe
[23:38] <andrew___> Plus, it's always been my opinion that Linux adoption is constrained mainly by the number of people in generation N that can be supported by the community from generations <N.
[23:39] <Mithrandir> conceivably, yes.
[23:39] <andrew___> Therefore, two key ways to increase the pace of Linux adoption are to reduce the support burden and increase the number of people that older generations can support.
[23:39] <lifeless> Mithrandir: in the deep of winter ? :)
[23:39] <Mithrandir> I think a solution using the telepathy framework and such might work well, but I'd start by having a good description of the problem and the requirements.
[23:39] <Mithrandir> lifeless: I live in Oslo, we don't get real winters any more. :-(
[23:39] <Mithrandir> lifeless: (yes, I bike the whole winter)
[23:40] <andrew___> I live in Britain.  We don't get real winters, but we're starting to get real summers :s
[23:40] <lifeless> Mithrandir: I knew where you lived :), I didn't know the climate had changed so noticably for you.
[23:41] <Mithrandir> lifeless: well, it's more about being downtown, I think.  I live basically at sea level about 1km from the ocean, so it doesn't get very cold for very long.
[23:41] <andrew___> What I'm thinking now is: there's lots that can be done with bullet-proofing the "mostly-broken" case.  I've mentioned two of what I think are the biggest issues on the ML: half-installed packages and FSs that won't mount...
[23:43] <andrew___> There's plenty of work already done in the "mostly working" case, and I'm starting to think that we need existing solutions to be promoted, rather than the likes of me adding another voice to the cacophony.
[23:44] <andrew___> But what about the intermediate case?  How common is it that someone will boot to a system that's not functional enough for Telepathy and friends, but too functional for automated special-case solutions?
[23:45] <Mithrandir> that's called "live CD", isn't it?
[23:45] <Mithrandir> and then have the support tools available from there and the "help from a friend" functionality available there
[23:45] <andrew___> Generally speaking, people with enough foresight to have a live CD lying about generally don't need my help :)
[23:46] <andrew___> Hmm.
[23:46] <andrew___> Should there be a recovery option to download and burn a live CD?
[23:47] <andrew___> From GRUB or similar?
[23:47] <Mithrandir> grub2 can give you netboot, and well, tftp can be routed, so theoretically you could boot over the internet
[23:47] <Mithrandir> it wouldn't be fast, though
[23:48] <Mithrandir> and would absolutely not be secure
[23:48] <andrew___> Yeah, and security becomes an issue again.
[23:50] <Nafallo> Mithrandir: wouldn't that depend on the speed of the connection? :-)
[23:51] <Mithrandir> Nafallo: no, it would probably more depend on the latency of the connection.
[23:51] <Nafallo> Mithrandir: point-to-point 10GbE wave? :-)
[23:51] <Mithrandir> Nafallo: most people don't have that at home though
[23:52] <Nafallo> Mithrandir: ...yet :-)
[23:57] <monic> can anyone tell me what is the graphics library people use for Ubuntu now; i gather it won't be SVGAlib