However, if the kernel itself is exploitable, it no longer matters whether those setuid programs are present.
Actually some of the kernel exploits seen in the last few years were related to strace and suid executables. That means though the vulnurability was in the kernel, a suid root program was required to actually perform the attack. The suid root program didn't need to be vulnurable itself.
Then it might qualify as machine-readable. But there is another detail, because the GPL require it not only to be machine-readable, but also to be on a medium customarily used for software interchange, which I don't think applies to paper.
That could for example be a little slip of paper, saying "You can download the Linux kernel source at $company_url".
I'm not completely sure if that is enough. An offer to send a CD to you at the cost of a few dollars would OTOH be acceptable. What I said is, that a printout of the source is not acceptable.
Then wouldn't a scanner with OCR software be considered a machine??
Yes, maybe it would be considered a machine. But since all the OCR software I have seen wasn't able to read a printout, that really doesn't change anything.
why couldn't he just not run any services, and keep the kernel up to date?
Because with an exploitable client you are still at risk. If you don't keep your system updated you will surely have a privelege escalation hole somewhere. Of course you are not vulnurable to the fast spreading worms that exploits server bugs, but that doesn't keep you free from everything bad.
I would recomend taking a look on Kernel Traffic. At least read the headlines, they are available as RSS. Personally I have KNewsTicker showing headlines from Slashdot, LWN, KT, and a few Danish news sites. (BTW where do I send bug reports about KNewsTicker, is slashdot appropriate?:-)
No a heisenbug is a bug which disapears when you try to debug the code, and which shows up again as soon as you stop debuging. A heisenbug can be easy to reproduce without debuging. Of course hard to reproduce heinsenbugs also exists, and can be quite hard to track down. I was experiencing one with xterm on Solaris systems. Sometimes my xterm command executed during login didn't open an xterm. For months I tried running my xterm under truss (the Solaris equivalent of strace), but it never failed. As soon as I stopped using truss, they started failing again.
A hard-to-repeat bug is ALWAYS the worse.
An easy to reproduce bug can also be difficult to track down. A friend of mine have a computer, that will crash if soundcard and IDE controller are busy at the same time (this happens with every 2.4.x kernel). Depending on the amount of activity, it might take minutes before crashing, but eventually it will always crash. I tried printing messages through the kernel log on entry and exit from every interrupt. No cases of one interrupt getting interrupted by another, and the last interrupt handler invoked did indeed return. So the crash happened outside the interrupt handlers. And when the system crash it simply stops dead with the IDE activity light permanently on. The system no longer handles interrupts, neither timer, nor keyboard can produce an interrupt. This is easy to reproduce and not a heisenbug, but still hard to track down.
To me it seems stupid to install an OS over the net when you can burn a CD, then install it on a bunch of computers and even loan it out to friends to install on their computer(s). Seems like a real waste of network bandwidth.
You can download the ISO files and then install directly from the ISO files on your harddisk. If you later need to install it elsewhere, you just copy or burn the ISO files.
I see two possible scenarios which make this an unrealistic
solution
With an appropriate cryptographic solution the receipt doesn't have to reveal information about the actual vote. And still it is possible with the right algorithm to verify, that this vote was actually counted in the final result. Unfortunately I don't remember the rest of the details about how this should work.
Google like any decent web crawler respects the robot exclusion protocol. Google have a robots.txt file, and the cached pages are included in that listning. That means no crawler is allowed to download pages from the google cache. You would expect google to respects their own robots.txt listning, so a google cache page will never turn up as a search result or a cached page on google.
Other search engines have been less smart and on one I actually have seen cases where the top hit for some keyword was their own search page for that exact keyword. Unfortunately I don't remember which searchengine it was.
Not everybody who uses/contributes to Linux does so out of a burning desire to compete with windows.
Actually the original goal of the free software movement was more like creating an alternative to Unix. At that time I think Windows wasn't even an option. Today you have to compete with Microsoft whether you like it or not. Why? Because Microsoft is putting obstacles in the way of all your development. A lot of Hardware and software is only tested with Windows. Some hardware manufactors only provide Windows drivers, and documentation only to closed source developers. A lot of people try to produce data that can only be read by Windows programs. This is how the world looks today, Microsoft has way too much power already, that is the only reason they can get away with the crap they provide. It is something you simply have to fight, because Microsoft is directly or indirectly responsible for a lot of your problems with Linux, whether you like it or not.
Until somebody from thinkgeek.com or a similar company read your comment on slashdot. BTW can thinkgeek employes read slashdot when at work and call it market research?
There might be a lot of resources available for developing Linux. But Microsoft still have a few resources available whose value must not be underestimated:
Access to documentation of more different hardware
Third party driver developers with knowledge of each and every piece of hardware, sometimes even people who participated in development of said hardware.
Third party software developers.
A wide range of manufactors who more or less willingly test Windows on their own hardware products and install Windows on the computers before shipping to the customers.
Imagine how much quicker Linux 2.6 would mature if hardware manufactors considered it important that their hardware would work with 2.6.0 from day one, and thus actually started testing it already with 2.6.0-test1.
Cynics (like me) think this is exactly why SCO is refusing to identify infringing code; the repair would cripple their attempt to collect license fees.
Didn't SCO publicly admit, that is exactly why, they don't want to tell the truth?
I don't know if making "Redhat" a synonym of "Linux" is all MS's fault though.
At least Red Hat is doing what they can to change that. But I guess there will just come another synonym of Linux, the question just is what it will be. Fedora, SuSE, Debian, Mandrake, or possibly something else?
As noted on LKML, (current->uid = 0) was probably deliberately surrounded by brackets to avoid a gcc warning of an assignment within a test.
I'm not so sure about that. Personally I would have put the brackets there even in case of a normal test. They might not be necesarry, but I trust brackets more than I would trust my own ability to remember the precedence of every operator in C.
You may think you are anonymous, but you downloaded the bsod.c file from the reply page, so now I know your IP. Do you still feel anonymous? Anyway it is surprising to see how much interest people have in my bsod implementation for Linux. It has been downloaded almost 300 times since I wrote the comment. Does people really miss the bsod from Windows that much?
Now, an Open Source system gains an overwhelming market share, and this is considered a good thing???
Probably one of the reasons Apache is getting so large market shares is, that it never had the problems seen with other products with too large market shares. If major problems ever turns up with Apache, we will probably quickly see a fork. Until that happens just be happy with one free product with an excelent record.
Slashdot Mirror
This problem was found in September
But the latest Red Hat kernel security advisory is dated july 21st. Does that mean Red Hat Linux is still vulnurable? Or was Red Hat Linux never vulnurable?
However, if the kernel itself is exploitable, it no longer matters whether those setuid programs are present.
Actually some of the kernel exploits seen in the last few years were related to strace and suid executables. That means though the vulnurability was in the kernel, a suid root program was required to actually perform the attack. The suid root program didn't need to be vulnurable itself.
I'm unimpressed.
If it wasn't patented maybe somebody would soon have come up with something better. What a strategy to ensure your program stays the best of its kind.
What if it is in barcoded format?
Then it might qualify as machine-readable. But there is another detail, because the GPL require it not only to be machine-readable, but also to be on a medium customarily used for software interchange, which I don't think applies to paper.
That could for example be a little slip of paper, saying "You can download the Linux kernel source at $company_url".
I'm not completely sure if that is enough. An offer to send a CD to you at the cost of a few dollars would OTOH be acceptable. What I said is, that a printout of the source is not acceptable.
Then wouldn't a scanner with OCR software be considered a machine??
Yes, maybe it would be considered a machine. But since all the OCR software I have seen wasn't able to read a printout, that really doesn't change anything.
vendor is given 21 business days
How did you come up with those numbers? I'd say 2 business days to acknowledge the bug and another 5 to fix it - at the very most.
why couldn't he just not run any services, and keep the kernel up to date?
Because with an exploitable client you are still at risk. If you don't keep your system updated you will surely have a privelege escalation hole somewhere. Of course you are not vulnurable to the fast spreading worms that exploits server bugs, but that doesn't keep you free from everything bad.
kernel source printed out
The GPL says machine-readable source code. That could for example be a CD. But certainly not printed on paper.
Not everyone who reads slashdot reads LKML
:-)
I would recomend taking a look on Kernel Traffic. At least read the headlines, they are available as RSS. Personally I have KNewsTicker showing headlines from Slashdot, LWN, KT, and a few Danish news sites. (BTW where do I send bug reports about KNewsTicker, is slashdot appropriate?
I think they're called "Heisenbugs"
No a heisenbug is a bug which disapears when you try to debug the code, and which shows up again as soon as you stop debuging. A heisenbug can be easy to reproduce without debuging. Of course hard to reproduce heinsenbugs also exists, and can be quite hard to track down. I was experiencing one with xterm on Solaris systems. Sometimes my xterm command executed during login didn't open an xterm. For months I tried running my xterm under truss (the Solaris equivalent of strace), but it never failed. As soon as I stopped using truss, they started failing again.
A hard-to-repeat bug is ALWAYS the worse.
An easy to reproduce bug can also be difficult to track down. A friend of mine have a computer, that will crash if soundcard and IDE controller are busy at the same time (this happens with every 2.4.x kernel). Depending on the amount of activity, it might take minutes before crashing, but eventually it will always crash. I tried printing messages through the kernel log on entry and exit from every interrupt. No cases of one interrupt getting interrupted by another, and the last interrupt handler invoked did indeed return. So the crash happened outside the interrupt handlers. And when the system crash it simply stops dead with the IDE activity light permanently on. The system no longer handles interrupts, neither timer, nor keyboard can produce an interrupt. This is easy to reproduce and not a heisenbug, but still hard to track down.
To me it seems stupid to install an OS over the net when you can burn a CD, then install it on a bunch of computers and even loan it out to friends to install on their computer(s). Seems like a real waste of network bandwidth.
You can download the ISO files and then install directly from the ISO files on your harddisk. If you later need to install it elsewhere, you just copy or burn the ISO files.
I see two possible scenarios which make this an unrealistic solution
With an appropriate cryptographic solution the receipt doesn't have to reveal information about the actual vote. And still it is possible with the right algorithm to verify, that this vote was actually counted in the final result. Unfortunately I don't remember the rest of the details about how this should work.
Do you get a google cache within a google cache?
Google like any decent web crawler respects the robot exclusion protocol. Google have a robots.txt file, and the cached pages are included in that listning. That means no crawler is allowed to download pages from the google cache. You would expect google to respects their own robots.txt listning, so a google cache page will never turn up as a search result or a cached page on google.
Other search engines have been less smart and on one I actually have seen cases where the top hit for some keyword was their own search page for that exact keyword. Unfortunately I don't remember which searchengine it was.
Not everybody who uses/contributes to Linux does so out of a burning desire to compete with windows.
Actually the original goal of the free software movement was more like creating an alternative to Unix. At that time I think Windows wasn't even an option. Today you have to compete with Microsoft whether you like it or not. Why? Because Microsoft is putting obstacles in the way of all your development. A lot of Hardware and software is only tested with Windows. Some hardware manufactors only provide Windows drivers, and documentation only to closed source developers. A lot of people try to produce data that can only be read by Windows programs. This is how the world looks today, Microsoft has way too much power already, that is the only reason they can get away with the crap they provide. It is something you simply have to fight, because Microsoft is directly or indirectly responsible for a lot of your problems with Linux, whether you like it or not.
...Tux pissing on SCO?
Until somebody from thinkgeek.com or a similar company read your comment on slashdot. BTW can thinkgeek employes read slashdot when at work and call it market research?
- Access to documentation of more different hardware
- Third party driver developers with knowledge of each and every piece of hardware, sometimes even people who participated in development of said hardware.
- Third party software developers.
- A wide range of manufactors who more or less willingly test Windows on their own hardware products and install Windows on the computers before shipping to the customers.
Imagine how much quicker Linux 2.6 would mature if hardware manufactors considered it important that their hardware would work with 2.6.0 from day one, and thus actually started testing it already with 2.6.0-test1.Isn't that a little pessimistic?
Would you feel better about it, if they could guarantee that you will die within three years?
Cynics (like me) think this is exactly why SCO is refusing to identify infringing code; the repair would cripple their attempt to collect license fees.
Didn't SCO publicly admit, that is exactly why, they don't want to tell the truth?
I don't know if making "Redhat" a synonym of "Linux" is all MS's fault though.
At least Red Hat is doing what they can to change that. But I guess there will just come another synonym of Linux, the question just is what it will be. Fedora, SuSE, Debian, Mandrake, or possibly something else?
A GUI UI?
Yes, he said so. I'm just wondering, is it also graphical?
No more Linux for us
Yeah, because he'd rather like a closed source product where such attempts suceed unnoticed.
As noted on LKML, (current->uid = 0) was probably deliberately surrounded by brackets to avoid a gcc warning of an assignment within a test.
I'm not so sure about that. Personally I would have put the brackets there even in case of a normal test. They might not be necesarry, but I trust brackets more than I would trust my own ability to remember the precedence of every operator in C.
Way to go!
You may think you are anonymous, but you downloaded the bsod.c file from the reply page, so now I know your IP. Do you still feel anonymous? Anyway it is surprising to see how much interest people have in my bsod implementation for Linux. It has been downloaded almost 300 times since I wrote the comment. Does people really miss the bsod from Windows that much?
Now, an Open Source system gains an overwhelming market share, and this is considered a good thing???
Probably one of the reasons Apache is getting so large market shares is, that it never had the problems seen with other products with too large market shares. If major problems ever turns up with Apache, we will probably quickly see a fork. Until that happens just be happy with one free product with an excelent record.