If it's
BugTraq ID 1634
then it's passing format strings into a localized program (using gettext and cousins) via specifying your own translation catalog.
I'm not an expert in security, but the first 10 posts
posted inaccurate information, so I thought I'd
add my 2 cents.
Yeah, that must be the BugTraq item, as it's credited to Ivan Arce of CORE SDI.
According to the article, the heart of the matter is that you attack the locale libraries by using
your own message catalog.
Is it the end of the world? Not really, people are working on it. A user has to be on your machine to exploit it.
The article also complains that Debian, RedHat and Conectiva announced fixes prior to the Sept 11th announce date for the bug. Normally you want a co-ordinated release for large bugs to not nail slower to fix software products.
When I worked for TurboLinux, we jumped from version 4 to version 6? Why? Cool features, better product? Well, yeah, I was the build engineer....
But the real reason is that we kept getting calls like this:
CUSTOMER: "What version is TurboLinux?" TL: "The current version is 4." CUSTOMER: "Oh, well, then I'll go get Red Hat; it's version 5 and therefore newer." TL: "No, wait! Ours just came out and is...." *click*
Can someone point me to a good book or paper explaining how peer-to-peer works? I've got a good idea how client server works, but how can a group of peers get together without one behaving as a server some how?
I built that CD (I work for TurboLinux), and I remember putting the files under a directory on the CD as SMC requested.
I'm sorry to say that I don't remember the name of the directory, but it was in the root of the CD and not too hard to figure out (I think). I did this quite a while ago (5 months? Not sure.)
I am not responsible for the boxes, though. Sorry.
Last time I checked, Cristian Grafton is the Red Hat Kernel Manager (i.e. same job as me at Red Hat).
Christian does a great job. They use Alan Cox to the fullest, to keep their kernel up-to-date and stable.
Our kernel has different slightly different goal, and has different patches. We want our kernel to be stable of course, but we include (naturally) our cluster support, IBM ServeRAID, drivers for companies that we have agreements, etc.
But neither one of us is forking the kernel. Both of us want to see the good stuff go into the mainstream kernel. However, we will support what we need to in the form of patches, in the SRPM.
Actually, I don't think its too bad, all press is good press. And this is one of the first time the posts for a TurboLinux story were mostly positive on SlashDot (that I remember).
Maybe we should get someone to slam us every so often. Since the positive articles never got very positive responses on SlashDot.
As far as the six to eight months thing. I (personally) have no clue. If no one cares to write the software, then we might be millions of years. As we all know, if you get enough determined people together, things happen quickly.
We were just the determined people in this case.:-)
I am the kernel maintainer for TurboLinux. Your email hasn't arrived in my mail box yet. I suspect that you sent others in my organization. Most of us are at ISPCon, so it hasn't filtered to me yet.
We have no intent of packaging and maintaining a seperate linux kernel tree. It would be too much work for no benefits.
Our kernel RPMs includes the base standard kernel tarball and additional patches. You can get all the additional patches out of the.src.rpm file. You can build a complete kernel from the.src.rpm file.
I have not put up a web-page or submitted it to Linus et al as I have not had time. Our primary concern is getting a quality product to our customers.
We are overworked as is. I will not, as TurboLinux's Kernel Maintainer (Kernel Colonel?), fork the kernel off. Having Alan Cox, and the wonderful crew in Linux-Kernel maintian the core stable kernel makes my life *much* easier.
The Cluster Module is just a module! It can be compiled in later after the kernel is done. It cannot (yet, as far as I can see) be compiled into the kernel as a non-module.
I am the kernel maintainer for TurboLinux. I'd like to dispell a few myths here:
The kernel isn't "forking" from what Linus distributes anymore than Debian, Redhat, SUSE, etc. do. We add extra patches for enhanced functionality, like raid, IBM Serveraid, etc.
The actual kernel patch that is used by TurboCluster is *in the kernel rpm*. You can grab the source rpm and look at it.
The TurboCluster was based upon the Virtual Server in the beginning. Since then we have hired a company to re-write it from scratch. There is nothing left of VS in the Cluster code, except some concepts (but none of their code). Did I mention it is GPL'ed in the source.
Did I mention that all the patches are available from the kernel source RPM?
At some point, the Cluster module will be submitted to Linus. However, we only know it works for 2.2.x. I *will* submit it for 2.3 and 2.5 (if it doesn't make 2.3), but I am in the process of re-writing the kernel RPM and am very busy. It needs to have all the CONFIG options and such added in, and checked to work in 2.3.x.
The TurboClusterD (the only non-GPL part of TurboCluster) will be OpenSource'd in the future. Our current plan (this is *not* an official commitment) is to release it as the next version comes out. The next version will be much better, of course.
I hope this addresses some people's concerns. Don't worry, I am **very** pro-GPL and am responsible for sanity checking these choices.
I would like to qualify that last paragraph (if I may). There is no advantage in DSK vs. QWERTY as far as speed is concerned. But in the time it took to standardize on QWERTY vs other keyboards, I doubt that RSI became an issue and therefore didn't become a factor is the ultimate decision. Though it is interesting to note that worse designs were rejected.
Currently, I'd say that the biggest advantage (which may not be much, depending on how much you type) is that DSK might be better for you. (Studies! We need more studies!)
I would hypothosize that 2b is the closest to the truth, but since the cause of the cost (choice of keyboard layout, made at the beginning of employment) is so far 'time wise' from the cost it self (2-5 years later, Carpel Surgery, etc.). In addition, the source of the cost is masked as a very small hike in medical care cost per person.
I would therefor think that most *businesses* don't consider the worth of changing to DSK (or any other layout).
Finally, the average home user doesn't switch because their employer hasn't making it difficult for person to change.
All in all, the article simply said that DVORAK isn't much faster (3-5%), alphabetic layouts are much slower (9%) and that no good impartial scientific studies have been done.
This article doesn't answer these questions, though:
Is Dvorak better for you?
What *is* the real speed increase (with real scientific studies)?
What is the real economic breakdown of cost/benifit? Especially if one or the other is better for you.
Is there a better keyboard?
Those are the questions I really wanted answered. I have read all this info before, and I still decided to go with DSK.
My speed hasn't increased, and neither has my error rate (still 40-50 WPM, 95% error). But my rate improves (in QWERTY or DSK) if I practice with a typing program (I have an old Mavis Beacon with DSK support).
Fun Notes
The QWERTY keyboard was also designed to allow the word typewriter to be typed all on the top row, increasing the speed of salesmen who only knew how to hunt and peck.
Sholes invented a keyboard after the QWERTY keyboard became popular, and it looked very similar to the DSK (vowels seperated, etc.)!
DSK isn't actually what I use, I use a modified DSK keyboard, with the {} keys relocated, and CapsLock mapped to control. I think the *real* benifit is to have a configurable keyboard.
Regarding Trolling, perhaps it needs to be a different system. Since the "point" system seems to aimed at articles that are more relavent or less relavent, articles that are completly off the scale should probably have a different method of being delt with.
After all, if one tests for the quality of eggs, you throw out the rocks!
Hmmm....on second thoughts, I'm not sure I'd impliment this practically. A seperate "de-troll" allowance, and if so many moderators (2 or more) use a de-troll point on the article, then the article is blasted to -100?
That wouldn't be bad with the meta moderation to help nail over enthusastic moderators. Though I think someone who is good at de-trolling may not be good at moderating up/down and vice-versa. So maybe removing one privlege shouldn't automatically remove the other.
This is more like someone showing where you can get a chocolate bar and saying, "If you feed this to your dog, it will make it sick and probably kill it."
The cDc is not installing this. It *is* available, but using the idea that if they didn't write it and make it *obviously* available, then someone would do it silently or such that it would take a while for everyone else to figure it out.
Why is anyone concerned, anyway? When I ran NT, I kept this off my machine (and other annoying trojans) by following simple security proceedures. Things that most people should follow.
My computers have never had a virus. I have been handed one floppy with material on it that I needed that was infected. And I found it right away and removed it.
Because I'm lucky? No, because I am reasonably cautious. I never trust my semi-skilled boss to be virus free. I never trust those "run this little program. It's cute." emails.
As for the argument as to why cDc released it; If MS doesn't care about the quality of their product (which they are only in as such it keeps their image good and makes them money) then their customers must be made aware.
I don't expect this to sway anyone. It seems most people are very biased into their opinions on MS and their win products. I really don't much care except to say that use the tool that fits and that is comfortable (in that order).
Would you consider putting these rules onto a web page so that gamers could look at them? Both game players and writers could use this kind of information.
A good place would be the Linux Game's site. If they won't host it, I will. This is the kind of "real" info that makes games and such very useful. Like the how to do a real autopsy page (vs. X-files' version).
With the Tandem hardware and OS, this wouldn't be a problem. You can swap it on the fly (and I've done it). It's extreamely cool stuff.
MS has been working with Tandem to get NT to do some similar stuff. I suspect that Tandem will no longer have such an advantage in the future as MS uses this in NT.
Ebay should have been put on Tandem hardware a while ago.
Interesting. It would never have occurred to me that the previous post meant to Open Source the virus (or trojan horse as in this case), which make's little difference. I assumed that he meant the exchange server, and the MAPI programs.
I don't think that Open Source'ing Outlook would fix this as the MAPI service is actually a nice feature of WinXX. Having the ability to disallow.exe files from being sent and attached would help. So would having enforced PGP signatures (with no caching of the password).
All in all this is more a failure of intellegence in the part of a large number of users and of corporate policies.
This could have been worse for exchange users and have been like melissa, agressively sending mails to people on the Global Address List (randomly) and setting up things like this.exe behind the scenes.
That would be more defensible by having the source, as you could see where the code was automatically setting things up.
Yes, but if I buy Stephen King's latest novel, I can photocopy it, color it, loan it to a friend, sell it, take it apart and otherwise do what I want with a copy that I bought.
If I "buy" your software; I cannot copy it, I cannot take it apart, I cannot loan it, I cannot do anything against the licence included with all software.
These are not comparable situations. "Bought" software is so much more than IP. The IP portion is hidden away in most (commercial) software, unavailable for anyone to appreciate or even notice.
You aren't the only one, but I'd like to point out that if my leech-puter goes rouge on me, I have a solution.
Specifically, my solution is 1 part salt, 3 parts water. Stir, then pour on the effected computer. All problems will go away.
AI is something different than this. This is biological fuzzy processing. It should be much more effecient than using silicon to do fuzzy stuff.
If (or when) we create AI computers, then there remains the issue of what will their outlook be like. I mean, if I took your brain at stuffed you in my computer case, you'd be unhappy.
But these would be lifeforms who grew up this way. Their culture would be different. They may consider being what they are honorable or desirable.
They wouldn't have the hormonal problems we, as a race, have. They wouldn't need to be teritorrial with us. They wouldn't even compete for the same resources!
I'm not afriad of AI's exploiting us. Though the reverse is possible and more likely.
Slashdot Mirror
Ciao!
I'm not an expert in security, but the first 10 posts posted inaccurate information, so I thought I'd add my 2 cents.
Yeah, that must be the BugTraq item, as it's credited to Ivan Arce of CORE SDI.
Ciao!
Is it the end of the world? Not really, people are working on it. A user has to be on your machine to exploit it.
The article also complains that Debian, RedHat and Conectiva announced fixes prior to the Sept 11th announce date for the bug. Normally you want a co-ordinated release for large bugs to not nail slower to fix software products.
Ciao!
http://docwhat.gerf.org/software/per l/barscan/
It includes my and a friend's Perl code, and our C code and a copy of other people's stuff including Pierre's first version of the kernel driver.
Have fun!
But the real reason is that we kept getting calls like this:
CUSTOMER: "What version is TurboLinux?"
TL: "The current version is 4."
CUSTOMER: "Oh, well, then I'll go get Red Hat; it's version 5 and therefore newer."
TL: "No, wait! Ours just came out and is...."
*click*
Of course, I'm not saying whether this is a good thing to say or not, but just adding some more context.
Just Curious.
I'm sorry to say that I don't remember the name of the directory, but it was in the root of the CD and not too hard to figure out (I think). I did this quite a while ago (5 months? Not sure.)
I am not responsible for the boxes, though. Sorry.
Regards to Robin Williams whose quote I just badly mangled.
Christian does a great job. They use Alan Cox to the fullest, to keep their kernel up-to-date and stable.
Our kernel has different slightly different goal, and has different patches. We want our kernel to be stable of course, but we include (naturally) our cluster support, IBM ServeRAID, drivers for companies that we have agreements, etc.
But neither one of us is forking the kernel. Both of us want to see the good stuff go into the mainstream kernel. However, we will support what we need to in the form of patches, in the SRPM.
Ciao!
Maybe we should get someone to slam us every so often. Since the positive articles never got very positive responses on SlashDot.
As far as the six to eight months thing. I (personally) have no clue. If no one cares to write the software, then we might be millions of years. As we all know, if you get enough determined people together, things happen quickly.
We were just the determined people in this case. :-)
Ciao!
I am the kernel maintainer for TurboLinux. Your email hasn't arrived in my mail box yet. I suspect that you sent others in my organization. Most of us are at ISPCon, so it hasn't filtered to me yet.
We have no intent of packaging and maintaining a seperate linux kernel tree. It would be too much work for no benefits.
Our kernel RPMs includes the base standard kernel tarball and additional patches. You can get all the additional patches out of the .src.rpm file. You can build a complete kernel from the .src.rpm file.
I have not put up a web-page or submitted it to Linus et al as I have not had time. Our primary concern is getting a quality product to our customers.
You may get the TurboLinux Cluster Kernel Patch here (You'll need to hold shift to download):
cluster-kernel-4.0.5-19991009.tgz
Does this answer all your questions?
Ciao!
We are overworked as is. I will not, as TurboLinux's Kernel Maintainer (Kernel Colonel?), fork the kernel off. Having Alan Cox, and the wonderful crew in Linux-Kernel maintian the core stable kernel makes my life *much* easier.
The Cluster Module is just a module! It can be compiled in later after the kernel is done. It cannot (yet, as far as I can see) be compiled into the kernel as a non-module.
Feel free to grab the cluster module and see for yourself (You'll need to hold shift):
cluster-kernel-4.0.5-19991009.tgz
Ciao!
I am the kernel maintainer for TurboLinux. I'd like to dispell a few myths here:
I hope this addresses some people's concerns. Don't worry, I am **very** pro-GPL and am responsible for sanity checking these choices.
Ciao!
(aka Christian Holtje docwhat@turoblinux.com>)
Currently, I'd say that the biggest advantage (which may not be much, depending on how much you type) is that DSK might be better for you. (Studies! We need more studies!)
This still leaves the Economic argument intact.
Ciao!
I would therefor think that most *businesses* don't consider the worth of changing to DSK (or any other layout).
Finally, the average home user doesn't switch because their employer hasn't making it difficult for person to change.
Ciao!
This article doesn't answer these questions, though:
Those are the questions I really wanted answered. I have read all this info before, and I still decided to go with DSK.
My speed hasn't increased, and neither has my error rate (still 40-50 WPM, 95% error). But my rate improves (in QWERTY or DSK) if I practice with a typing program (I have an old Mavis Beacon with DSK support).
Fun Notes
Ciao!
After all, if one tests for the quality of eggs, you throw out the rocks!
Hmmm....on second thoughts, I'm not sure I'd impliment this practically. A seperate "de-troll" allowance, and if so many moderators (2 or more) use a de-troll point on the article, then the article is blasted to -100?
That wouldn't be bad with the meta moderation to help nail over enthusastic moderators. Though I think someone who is good at de-trolling may not be good at moderating up/down and vice-versa. So maybe removing one privlege shouldn't automatically remove the other.
The cDc is not installing this. It *is* available, but using the idea that if they didn't write it and make it *obviously* available, then someone would do it silently or such that it would take a while for everyone else to figure it out.
Why is anyone concerned, anyway? When I ran NT, I kept this off my machine (and other annoying trojans) by following simple security proceedures. Things that most people should follow.
My computers have never had a virus. I have been handed one floppy with material on it that I needed that was infected. And I found it right away and removed it.
Because I'm lucky? No, because I am reasonably cautious. I never trust my semi-skilled boss to be virus free. I never trust those "run this little program. It's cute." emails.
As for the argument as to why cDc released it; If MS doesn't care about the quality of their product (which they are only in as such it keeps their image good and makes them money) then their customers must be made aware.
I don't expect this to sway anyone. It seems most people are very biased into their opinions on MS and their win products. I really don't much care except to say that use the tool that fits and that is comfortable (in that order).
Ciao!
A good place would be the Linux Game's site. If they won't host it, I will. This is the kind of "real" info that makes games and such very useful. Like the how to do a real autopsy page (vs. X-files' version).
MS has been working with Tandem to get NT to do some similar stuff. I suspect that Tandem will no longer have such an advantage in the future as MS uses this in NT.
Ebay should have been put on Tandem hardware a while ago.
Oh yeah, Tandem is now owned by Compaq.
I don't think that Open Source'ing Outlook would fix this as the MAPI service is actually a nice feature of WinXX. Having the ability to disallow .exe files from being sent and attached would help. So would having enforced PGP signatures (with no caching of the password).
All in all this is more a failure of intellegence in the part of a large number of users and of corporate policies.
This could have been worse for exchange users and have been like melissa, agressively sending mails to people on the Global Address List (randomly) and setting up things like this .exe behind the scenes.
That would be more defensible by having the source, as you could see where the code was automatically setting things up.
Ciao!
If I "buy" your software; I cannot copy it, I cannot take it apart, I cannot loan it, I cannot do anything against the licence included with all software.
These are not comparable situations. "Bought" software is so much more than IP. The IP portion is hidden away in most (commercial) software, unavailable for anyone to appreciate or even notice.
Ciao!
Specifically, my solution is 1 part salt, 3 parts water.
Stir, then pour on the effected computer. All problems will go away.
AI is something different than this. This is biological fuzzy processing. It should be much more effecient than using silicon to do fuzzy stuff.
If (or when) we create AI computers, then there remains the issue of what will their outlook be like. I mean, if I took your brain at stuffed you in my computer case, you'd be unhappy.
But these would be lifeforms who grew up this way. Their culture would be different. They may consider being what they are honorable or desirable.
They wouldn't have the hormonal problems we, as a race, have. They wouldn't need to be teritorrial with us. They wouldn't even compete for the same resources!
I'm not afriad of AI's exploiting us. Though the reverse is possible and more likely.
Ciao!