Please wait...
Not bitten (that I can tell yet). Patched with the second round of bash package updates. Good to see that Slackware released patches back to 13.0 were released around 2 pm CST. That would have saved me a bit of time fussing if Debian / Ubuntu was that fast :-) They did come in a close second at around 4:50 pm CST, but a one man shop should probably come in second. Just kidding, I realize he has minions dedicated to testing. I appreciate all the folks doing the heavy lifting and discussions today as well. Hated that the mess existed, but loved the response and frank discussions of the patches - all in the open !!!.
Thu Sep 25 19:55:13 UTC 2014
a/bash-4.3.025-i486-2.txz: Rebuilt.
Patched an additional trailing string processing vulnerability discovered
by Tavis Ormandy.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169
(* Security fix *)
ap/lxc-1.0.6-i486-1.txz: Upgraded.
Fixed bash completion file. Thanks to dunric.
------------------------------------------------------------------------------------------------------------------------
Ubuntu notice:
Thu Sep 25 21:50:16 UTC 2014
bash (4.1-2ubuntu3.2) lucid-security; urgency=medium * SECURITY UPDATE: incomplete fix for CVE-2014-6271...
I'm sure you can appreciate the security implications of such a beast.
Yes and no. There's a bit of a sliding scale: obviously if you provide the ability to load that library from every random $HOME, and gdk+ were to load that even for setuid binaries, that would be a serious problem. But if gdk+ will only load it from a system location after verifying that its path-writable only by root, I don't see any problem.
Do you think that would provide enough security?
Thoroughly verify path-writability (each directory in the chain) only by root and there should be no problem. Hell, even that is unnecessarily paranoid: if the path to the extention library is hardcoded, and it's a location that's typically only root-writable, then that's enough.
and/or refuse to load the hooks for setuid/setgid binaries.
Okay, that is pretty much along the lines of what I was thinking, although I forgot about testing the uid/gid on the extention itself. That would be wise. It might also be wise to ensure that the file for the library is owned by someone in the 'root' family or somesuch, although that might be a tad paranoid.
well, is this something which if of use to anybody else then you?
else I would rather have a git repo with that patch, and rebase it to every new release and not bother upstream.
I suspect this is something useful beyond what I need to do with it. If you wanted to research the way messages were working within the gdk for some particular reason (chasing down a problem, for example), you might find something like this rather handy. For normal, average use, no, this isn't the sort of thing I would think should get compiled into the toolkit by default.
It might be handy for recording/playback, although X11 itself already has software for that sort of thing so you don't have much of a need for it. Ergo, I think this would be useful more for research purposes.
http://www.theregister.co.uk/2014/10/06/poettering_says_linux_kernel_community_is_hostil/
There was more in a german article, where Poettering claims he received death threats and that people were collecting bitcoins to hire a contract killer.
In other words: Welcome to the Internets! Being threatened with death is kind of an internet baptism rite, I thought.
I understand that people would rather have a soft and friendly language on mailing lists, forums and in comments everywhere. But I can also understand why Torvalds reacts how he reacts, you can not lead a big project without getting angry. Especially if it is not a business/money project, but your brainchild.
Also, systemd can go straight to hell.
Straight? Really?
I dunno... maybe.
The problem systemd sought to address that supposedly sysvinit fails to handle well is the bit about starting several services simultaneously while still having some sense of order. Supposedly, systemd helps get your OS up and running faster than the traditional sysvinit process.
But, I thought Gentoo managed to achieve the same results using a sysvinit-style process, just slightly evolved (which is more the Linux tradition, from what I understand, than coming up with something completely new). Is that true?
Tue Oct 07 2014 08:17:53 EDTfrom fleeb @ Uncensored
Straight? Really?
The problem systemd sought to address that supposedly sysvinit fails to handle well is the bit about starting several services simultaneously while still having some sense of order. Supposedly, systemd helps get your OS up and running faster than the traditional sysvinit process.
But, I thought Gentoo managed to achieve the same results using a sysvinit-style process, just slightly evolved (which is more the Linux tradition, from what I understand, than coming up with something completely new). Is that true?
That is true. Gentoo uses OpenRC which has the capability to run init scripts in parallel. That is disabled by default, but who uses an "out of the box" Gentoo anyway? It is disabled because it might lead to a deadlock/livelock situation, which I never encountered.
You can tell init scripts that they "need" some service, "provide" some service or should start before/after some service. Citadel for example provides "mta", syslog provides "logger". net.ppp0 can provide "net", but that is optional, you can say that net.lo is sufficient as "net" service. You can also activate interactive booting, so you can hit "i" during boot in order to mess around. http://en.wikipedia.org/wiki/OpenRC
My server always start unparallel since they only start about twice a year. My laptop/desktops always booted in parallel and were lightning fast, even before this whole upstart/systemd "zomg I boot with the speed of a farting ray of light shot out of a plasma gun" thing became hip.
Who wants/needs to boot anyway?! My MBA boots once a month at max, my linux netbook rebooted when I installed a new kernel. I dunno if a full reboot/halt is more energy efficient as keeping the computer ready in standby/hibernation.
Yeah, I can see where, from a server's perspective, such things seem a little silly.
But if you're creating an embedded system that someone might turn on or off without any sense of celebration, a fast boot time is desirable.
Straight? Really?
No, not really. He's just talking out of his ass, like most social justice vigilantes. And as is usual with that type, they conveniently classify Asians as "white" because Asians are pretty darn good at getting along with everyone else.
Meanwhile... fucking Unity.
I went to some effort to use the GTK+ library so what I wrote in Windows should work identically in any Linux running a Gnome desktop.
Ah, but Ubuntu isn't exactly running a Gnome desktop now, are they? No, they invented Unity, which doesn't really use the gtk_status_icon that I'm using because it "is more and more difficult for users to interact with [it]."
They cite the fact that each application behaves differently, etc.
I get it... but fucking hell, their approach to resolving this perceived issue is to make it even less possible to use this than before. They've concocted (and I do mean con-cock-ted) this fucking 'app indicator' bullshit to take its place. Now, I'm supposed to write other code that won't have a fucking thing in common with the code that I got working in Windows just because it "is more and more difficult for users to interact with [it]."
Fuck the users. I know my users, and they want what I'm trying to shove down their grubby throats.
Fuck the users. I know my users, and they want what I'm trying to
shove down their grubby throats.
weren't we talking about hubris? You found the hubris pills. Congratulations.
lol
Joking aside, the status icon did exactly the right thing from what I can tell, and now I have to figure out what Unity deems is right for that interface.
But, this also means I have to break with any sense of commonality between the two software sets.
I need a way to present to the user that we're recording what they're doing on the desktop, or not recording, depending on whether they told us to record or not. A status icon living in the command bar or task bar or whatever the hell you want to call it strikes me as the perfect place for something like this. Unusually so, frankly.
To dedicate an entire window's real-estate to the task breaks from the idea that we're recording your interaction with the desktop. It doesn't give you as much of a sense of that. Yet, the Fucking Unity guys would want you to do that, as best as I can tell. Because they "know [their] users, and they want what [they're] trying to shove down their grubby throats."
*grin*