No, but they know if the judge isn't an idiot, they're toast anyway. So they follow the working hypothesis that the judge is an idiot, because it's their only hope.
Perfectly logical, and you can't say that often about SCO.
Yeah, and you'd have to be damn careful when writing the software which manages that to avoid a DOS attack. First, now you have to log every single knocking, second, you have to track the sequences of every single IP adresses "knocking". Since, I believe, this knocking can be easily spoofed, it should be possible to start ugly DOS attacks just by sweeping the victim with IP packets for every port, with alternating src adressess.
No, we are not talking about some semantic games here ("application" vs. "os" level), we are talking about ring 0 vs. ring 3.
See for instance http://en.wikipedia.org/wiki/Ring_0 for a short description. The point is that code running inside the kernel just doesn't have to abide to the os rules (like file permissions, or capabilities, etc.). That's why rootkits have to manipulate the kernel. Tcpwrappers and inetd are running outside the kernel, the tcp/ip stack runs inside.
I'm not sure I understand. Tcpwrappers or (x)inetd are exactly what you are looking for, and they proof that this kind of security at the application level doesn't lead to code duplication.
(And about your kernel code thing, that's not the issue. Complicated server code that does crypto and spawns processes is more likely to be buggy than a program that listens for 5 pings, with no buffers to overflow, and opens a port to SYNs for 5 minutes. That's what makes port knocking slightly more reliable even if not more secure)
But the point is that you can't stop using "Complicated server code that does crypto and spawns processes", because "port knocking" is as secure as a telnet connection, is this so hard to understand??
Except that each program wanting to use this technique would not have to implement it at the application level, as it would be taken care of at the OS level.
You can take care of that problem at the application level (see tcpwrappers and inetd), and this is without doubt - and every kernel hacker I'm sure would agree - more secure than doing that on the kernel level.
Ok, let me rephrase what I wrote in another message.
Open ports per se are not insecure!
The whole point behind port knocking is the wrong impression that "open" ports are more insecure than "closed" ports. This is totally bogus. It's about the applications behind the open ports, and it's not more complicated to write code which listens to a specific port and drops the connection if it doesn't recieve some secret number as the only payload of the first packet, than it is to write the kernel tcp/ip stack.
That brings me to another mantra
Kernel code is not intrinsically more secure than application level code!.
There are many examples for buggy and overflowing tcp/ip stacks (ping-o-death comes to mind if you're somewhat older).
No, you are allowing yourself to be confused by the fact that there's just a shift of complexity, not a removal of complexity.
If, say, the Openssh programmers liked this idea and wanted to implement something analogous, they would just insert a step at the very start of their protocol where the client just has to send, unencrypted, a tcp data packet containing just a secret number. Now the server would check if this secret number was correct, and if not, would just drop the connection. Do you really think they wouldn't be able to implement this as securely as the kernel code needed for the "port knocking"? If yes, look at tcpwrappers and inetd.
So if we came to the conclusion that something like "port knocking" might be a sensible idea, it surely wouldn't be design as "port knocking".
It isn't more secure. It's just more obfuscated, because it's more complex. But that doesn't make it more secure, it makes it potentially _less_ secure. It's like saying that if sshd asked consecutively for two passwords before granting access, that would be more secure. It's simple: a) for every admin, the time he can dedicate to security is finite b) every minute the admin cares about "port knockin" lowers the time he can spend for something else c) because of the weakness of this "protocol" (non-encyptable, easyly spoofable source IPs), it doesn't save any time somewhere else. E.g. you can't relax any other real security measure because you now use "port knocking" It follows that the first effect of using "port knocking" is that there's less time for the other security measures, therefore potentially weaking them.
Not that I concur with your parent post, but at least the 68020 is used" in military applications. Yes, I know, that's not the G4, but at least this is a chip which has been used in a Mac, and you sound as if you were interested in that stuff.
Yeah, and Boies has a contract that says he gets 20%.
Arguably, since SCO contractually has to transfer the full 100% to Novell, and then gets then 5% back, one could argue that Boies would only get 20% of 5% == 1%. I'd like to see that happen.
Ah, ok. Thought your "clever comments" related to clever "hey, this is a dupe" comments. OTOH, comments of this type aren't clever, so sorry for the misunderstanding;).
The problem with this theory is that it will strengthen linux and therefore hurt microsoft in the end. If this is really initiated by MS, they are really panicking about linux.
You have my sympathy. I just hope the people who are responsible for the bad image Real has here on slashdot are still there at Real, and are confronted with the mess they created. That really was avoidable, at the core your product was ok, without the many bad decisions of the past I think Real would be a loved company around here (MS foe, Linux player etc.). While that doesn't make money on itself, it might have helped. Now you really are in an uphill battle with public perception of the technology community. I hope you succeed.
Thanks for the answer, I have coded in perl, that's why I asked, and I meant it really not as an flamebait;).
Anyhow - would you have learned this if you didn't ask? Keep attempting to offend, man:)
Heh, it served a purpose. Maybe I should've mixed in some python evangelism for better balance - which is btw. all you praise about perl, without the ugly and hacky parts - but I digress.
Seriously, interesting to know that java seems even to be inferior to perl in most aspects. LOL, see I can even offend two camps of language followers in one sentence;).
In the app we develop here at work, we are highly conscious of performance and scalability. [...] We use Perl [...]
Huh? This is not meant as an offense, or a troll, but that really, really doesn't fit together. Have you considered using something faster (no, not C)? This should have a much bigger effect than a HT proc.
You are wrong. QT is under the GPL. The GPL doesn't place restrictions on calling the API, it restricts derived works. Linking is derived work, calling the API is not.
Though, since QT is only a library, I don't see where one could just interfere with some part of QT by just "calling" the API.
Dopn't forget trolltech is a canopy company. Yarro sits on trolltech's BOD. Canopy and canopy companies have already sued msft, and ca. Scox, another canopy company is now suing IBM. All over IP violations. This is Canopy's real business.
Once you start mixing code, you open yourself up to lawsuits. Especially if you are mixing code with the lawuit-happy canopy. Canopy's entire existance is based on these kinds of lawsuits.
Arrgh, why does this awful legend still exist? Canopy owns a very, very small stake in Trolltech, while the employees hold more than 2/3 (IIRC) of the stock. OTOH, Sun, a major sponsor of Gnome development, has seemingly filled SCO's war chest with a good amount of money (if what is said on groklaw is true), but nobody whines about that. And, there's still this if Trolltech might be bought out.
Now, here's a question. Let's say Microsoft is doomed, and Sun, by having enourmous success with some Gnome based desktop offering, replaces them in market dominance. The dangers of this scenario combined with the fact the Gnome is LGPL'd are left as an excercise to the reader.
See, both scenarious are very unlikely, but I see no reason why I should trust Sun more than Trolltech.
Well maybe I missed somthing, but last time I checked, it's free only if you use it in free software.
Yeah, just like the linux kernel...
For other software, they are just like any other commecrial software company.
... which doesn't even have this option.
Btw. it seems you are talking about QT, not KDE. I sense you should inform yourself about KDE and what some people (rightly or wrongly) suppose to be its problems. Funnily, the FSF should be more satisfied with QT's licensing than with GTK's, but what do I know.
Slashdot Mirror
Try Ultimate Boot CD.
Really, a great tool, includes a _load_ of hardware testing tools (like vendor tools for harddisks, memtest, etc.).
Wow, that's really funny, thanks for the info ;).
But, when I first choose this link, it showed _no_ search results and maybe around 10 sponsored links. I think I should try to find another search.
I wonder how this spam site got to the phrase I used, I doubt it's coincidence.
Do the SCO lawyers think the judge is an idiot?
No, but they know if the judge isn't an idiot, they're toast anyway. So they follow the working hypothesis that the judge is an idiot, because it's their only hope.
Perfectly logical, and you can't say that often about SCO.
Yeah, and you'd have to be damn careful when writing the software which manages that to avoid a DOS attack. First, now you have to log every single knocking, second, you have to track the sequences of every single IP adresses "knocking". Since, I believe, this knocking can be easily spoofed, it should be possible to start ugly DOS attacks just by sweeping the victim with IP packets for every port, with alternating src adressess.
No, we are not talking about some semantic games here ("application" vs. "os" level), we are talking about ring 0 vs. ring 3.
See for instance http://en.wikipedia.org/wiki/Ring_0 for a short description. The point is that code running inside the kernel just doesn't have to abide to the os rules (like file permissions, or capabilities, etc.). That's why rootkits have to manipulate the kernel.
Tcpwrappers and inetd are running outside the kernel, the tcp/ip stack runs inside.
I'm not sure I understand.
Tcpwrappers or (x)inetd are exactly what you are looking for, and they proof that this kind of security at the application level doesn't lead to code duplication.
(And about your kernel code thing, that's not the issue. Complicated server code that does crypto and spawns processes is more likely to be buggy than a program that listens for 5 pings, with no buffers to overflow, and opens a port to SYNs for 5 minutes. That's what makes port knocking slightly more reliable even if not more secure)
But the point is that you can't stop using "Complicated server code that does crypto and spawns processes", because "port knocking" is as secure as a telnet connection, is this so hard to understand??
Except that each program wanting to use this technique would not have to implement it at the application level, as it would be taken care of at the OS level.
You can take care of that problem at the application level (see tcpwrappers and inetd), and this is without doubt - and every kernel hacker I'm sure would agree - more secure than doing that on the kernel level.
Ok, let me rephrase what I wrote in another message.
Open ports per se are not insecure!
The whole point behind port knocking is the wrong impression that "open" ports are more insecure than "closed" ports. This is totally bogus.
It's about the applications behind the open ports, and it's not more complicated to write code which listens to a specific port and drops the connection if it doesn't recieve some secret number as the only payload of the first packet, than it is to write the kernel tcp/ip stack.
That brings me to another mantra
Kernel code is not intrinsically more secure than application level code!.
There are many examples for buggy and overflowing tcp/ip stacks (ping-o-death comes to mind if you're somewhat older).
Because instead of running the port open ALL THE TIME TO THE ENTIRE WORLD [...]
Who or what gives you the idea that open ports per se are insecure?
No, you are allowing yourself to be confused by the fact that there's just a shift of complexity, not a removal of complexity.
If, say, the Openssh programmers liked this idea and wanted to implement something analogous, they would just insert a step at the very start of their protocol where the client just has to send, unencrypted, a tcp data packet containing just a secret number. Now the server would check if this secret number was correct, and if not, would just drop the connection.
Do you really think they wouldn't be able to implement this as securely as the kernel code needed for the "port knocking"?
If yes, look at tcpwrappers and inetd.
So if we came to the conclusion that something like "port knocking" might be a sensible idea, it surely wouldn't be design as "port knocking".
It isn't more secure. It's just more obfuscated, because it's more complex. But that doesn't make it more secure, it makes it potentially _less_ secure.
It's like saying that if sshd asked consecutively for two passwords before granting access, that would be more secure.
It's simple:
a) for every admin, the time he can dedicate to security is finite
b) every minute the admin cares about "port knockin" lowers the time he can spend for something else
c) because of the weakness of this "protocol" (non-encyptable, easyly spoofable source IPs), it doesn't save any time somewhere else. E.g. you can't relax any other real security measure because you now use "port knocking"
It follows that the first effect of using "port knocking" is that there's less time for the other security measures, therefore potentially weaking them.
Not that I concur with your parent post, but at least the 68020 is used" in military applications. Yes, I know, that's not the G4, but at least this is a chip which has been used in a Mac, and you sound as if you were interested in that stuff.
Yeah, and Boies has a contract that says he gets 20%.
Arguably, since SCO contractually has to transfer the full 100% to Novell, and then gets then 5% back, one could argue that Boies would only get 20% of 5% == 1%. I'd like to see that happen.
Looky here and search for mikerowesoft
Ah, ok. Thought your "clever comments" related to clever "hey, this is a dupe" comments. OTOH, comments of this type aren't clever, so sorry for the misunderstanding ;).
That are two different interviews, Watson.
The problem with this theory is that it will strengthen linux and therefore hurt microsoft in the end. If this is really initiated by MS, they are really panicking about linux.
...
Who knows
You have my sympathy.
I just hope the people who are responsible for the bad image Real has here on slashdot are still there at Real, and are confronted with the mess they created.
That really was avoidable, at the core your product was ok, without the many bad decisions of the past I think Real would be a loved company around here (MS foe, Linux player etc.). While that doesn't make money on itself, it might have helped. Now you really are in an uphill battle with public perception of the technology community.
I hope you succeed.
Thanks for the answer, I have coded in perl, that's why I asked, and I meant it really not as an flamebait ;).
:)
;).
Anyhow - would you have learned this if you didn't ask? Keep attempting to offend, man
Heh, it served a purpose. Maybe I should've mixed in some python evangelism for better balance - which is btw. all you praise about perl, without the ugly and hacky parts - but I digress.
Seriously, interesting to know that java seems even to be inferior to perl in most aspects.
LOL, see I can even offend two camps of language followers in one sentence
In the app we develop here at work, we are highly conscious of performance and scalability. [...] We use Perl [...]
Huh? This is not meant as an offense, or a troll, but that really, really doesn't fit together. Have you considered using something faster (no, not C)? This should have a much bigger effect than a HT proc.
You are wrong. QT is under the GPL. The GPL doesn't place restrictions on calling the API, it restricts derived works. Linking is derived work, calling the API is not.
Though, since QT is only a library, I don't see where one could just interfere with some part of QT by just "calling" the API.
Dopn't forget trolltech is a canopy company. Yarro sits on trolltech's BOD. Canopy and canopy companies have already sued msft, and ca. Scox, another canopy company is now suing IBM. All over IP violations. This is Canopy's real business.
Once you start mixing code, you open yourself up to lawsuits. Especially if you are mixing code with the lawuit-happy canopy. Canopy's entire existance is based on these kinds of lawsuits.
Arrgh, why does this awful legend still exist? Canopy owns a very, very small stake in Trolltech, while the employees hold more than 2/3 (IIRC) of the stock.
OTOH, Sun, a major sponsor of Gnome development, has seemingly filled SCO's war chest with a good amount of money (if what is said on groklaw is true), but nobody whines about that.
And, there's still this if Trolltech might be bought out.
Now, here's a question. Let's say Microsoft is doomed, and Sun, by having enourmous success with some Gnome based desktop offering, replaces them in market dominance. The dangers of this scenario combined with the fact the Gnome is LGPL'd are left as an excercise to the reader.
See, both scenarious are very unlikely, but I see no reason why I should trust Sun more than Trolltech.
Well maybe I missed somthing, but last time I checked, it's free only if you use it in free software.
...
... which doesn't even have this option.
Yeah, just like the linux kernel
For other software, they are just like any other commecrial software company.
Btw. it seems you are talking about QT, not KDE. I sense you should inform yourself about KDE and what some people (rightly or wrongly) suppose to be its problems. Funnily, the FSF should be more satisfied with QT's licensing than with GTK's, but what do I know.