You make it sound as though the GPL imposes requirements on corporations that it does not impose on natural persons. I find that bizarre, and don't understand where that reading is coming from.
What the GPL would prevent is having someone take a government-contracted GPLed product, slap a gui front end on it (maybe even with a few silly interface pattents), and then sell the result with a do-not-copy, do-not-reverse-engineer license. I'll grant you, that's an action corporations are more likely to take than individuals, but the corporate discrimination angle you're trying to play up is downright silly.
Frankly, the no GPL rule makes no sense without a similar rule against standard proprietary licenses; government contractors routinely develop code and then incorporate it into their own do-not-reverse-engineer programs. What happens in that case is that the government gets the code and a license to use it wherever they want internally, but they can't release it to non-governmental institutions.
Certainly the public gains less from that arrangement than it does from an identical arrangement that also allows the government to release said code to the public under the GPL.
Please, please do not use the words "secure application" when what you really mean is "approved application".
What I suspect you really mean is "an application that is doing only what the user intends that application to do". However, that is not necessarily the same as "approved application". (Since software vendors can stick all sorts of cruft and spyware into their "approved" applications) Some Palladium supporters would like everyone to assume that they are the same, and the use of "secure application" supports this confusion.
"Secure application" presumably means, among other things, "an application that is not vulnerable to attempts to make it misbehave". This is also not what "approved application" means.
I wonder - if an approved application contained a buffer overflow or other vulnerability, would it be possible to write a trojan that would operate entirely through that vulnerability as though it were a trusted application? (e.g. a trusted server could be exploited remotely and then the trojan code loaded into memory, running as a thread of the trusted server process) Tricky perhaps, but I've not heard anything that makes me think that Palladium will avoid that scenario.
And it shows how little you understand about the above reply, but I guess you said that when you said "makes no sense". The point was that by the age of 60, the person who has saved $100 a month since age 20 (note the 40 years bit?) will have only $255,225.08, while the "sap" who waited until 30 to start saving and then put away more will at the age of 60 have $1,196,170.35. In other words, the exact OPPOSITE of what the "you CAN do it" guy is claiming. Compound interest is certainly a powerful force, but it's not that powerful, at least not at a mere 6.9% interest rate.
By the way, if you wish to repeat these calculations, here are a few perl lines that'll do the math for you:
# 40 years of $100/month, compounded monthly at 6.9% perl -e 'print ("100\n" x (12*40))' | perl -lne '$a *= 1 + (0.069/12); $a += $_; END {print $a;}' # 30 years of $1000/month, compounded monthly at 6.9% perl -e 'print ("1000\n" x (12*30))' | perl -lne '$a *= 1 + (0.069/12); $a += $_; END {print $a;}'
Especially if you read the article, it states that the real problem was in China and India; as a result there will be no CS GRE in those countries this academic year. So not only will students from those countries face the generally tougher requirements that international students face when applying to US schools, but for this year they won't have the advantage of a GRE score which shows that they know what's what.
So no, it's not a tragedy because it doesn't affect students coming from the US, only those dirty foreigners.
I live in a nice little city here in the Philadelphia suburbs. Looking up and down my block, it's not that different from any other middle- (or possibly lower-middle-) class neighborhood in America.
However, DSL is apparently uneconomical for anyone to offer to this area. I'd pay for it; it sure beats having my computer dialed in from midnight to 5 am each night trying to keep current with Debian testing and unstable. Unfortunately, everywhere with a decent user agreement says that offering me DSL isn't possible at this time. And that's the real point - the user agreement. I will not surrender control of my computer to my upstream provider by installing their specialized, over-branded spyware. (Not that I could anyway, given that I don't run windows on the main machine) I will run whatever servers I feel like running for whatever legal purpose I choose. I will use encryption and VPN-foo to connect to systems at work.
This is simply not an option with the only broadband game in town (Comcast). It's not the money that broadband providers want from me that holds me back - it's the control they want.
Regardless of whether my mail server used to be "open" or not, I stand by the legal analysis that placed fault on the blackhole operators who forged their identity.
But you did ask the blackhole list people to check your server, yes? You do have the right to access your server in any way you see fit and to permit others the same access, correct?
If I contracted with a security testing firm to test the security of my office, I'd be severely annoyed with them if they did not try to lie their way past the office manager who watches the front door.
Whether I have the ide-scsi module installed or just the ide-cd module, my CDs are accessible at/dev/cdroms/cdrom0 and/dev/cdroms/cdrom1
Which drive is which does indeed switch depending on the order in which I choose to load the modules, but anyone who's installed a removable disk driver on windows will tell you that all the disks there jump around too. (e.g.: my wife installed the driver for a compactflash reader on her windows 98 machine, and the CD rom was moved from D: to E: to make room for the compactflash device. Later, we had to re-install it and D: and E: swapped places again)
Anyone saying that linux requires you to use the scsi names hasn't tried devfs lately.
Come on, someone stop commenting on the religion question and answer this one.
The closest thing I found was on http://outerbody.com/ruby/ruby-man-1.4/syntax.html #operator, which seems to say that in Ruby one can do foo(*[1,2,3]) instead of foo(1,2,3) From what I can tell, in Ruby [] is the standard make-a-list operator, and lists in Ruby seem to operate similarly to lists in Python and array references in perl.
However, this doesn't seem like anything new to perl; doing foo(@array) is the same as calling foo with each of the elements of @array as arguments. If $a is an array reference, this becomes: foo(@$a) So I don't think that this Ruby operator is what was meant.
in the uk we've had the ira, funded by?, for years, after each blast you'd just shrug, hey what can you do?
While I really hate some of the exaggeration that gets played up in the US media (comparing the WTC disaster to Hiroshima, for example), what's the largest loss of life that an IRA attack has ever caused? 29, right? ("Real IRA" car bomb in 1998)
Have one hundred incidents that bad and then tell me that the UK has had comparable experience.
NetBIOS (I admit that the name has meant a few different things as it evolved) is not the same as NetBEUI. NetBEUI is a layer 2 protocol, and is not propogated by most routers. (unless the "router" is really an ethernet bridge in disguise)
NetBIOS is a programming interface implemented as a bunch of packet types which can be sent out either over NetBEUI or over IP. (sitting mostly on top of TCP, though I think some packets are sent out with UDP). IP is extremely routable.
I cannot believe that you have ever used wordperfect's equation editor if you made the above statement. (Maybe you've only used it after Corel broke it by trying to make it graphical the way word's is)
I remember using it with old dos-based wordperfect in high school, (circa 1992) and it was miles beyond even current generations of word's equation editor. Basically, it was a stripped-down version of tex that let you just type what you wanted, and have it come out right. Not only that, but I never had to watch the screen to make sure my mouse pointer is over just the right one of twenty different buttons arranged in a little grid. I cannot imagine anyone wanting to use word's interface unless equations represent less than about 5% of the article's vertical space. Until I got to college and learned about TeX, I thought it was clearly the greatest thing ever for producing technical output. I still don't understand those people who would write up physics lab reports, complete with rather verbose equations, in word using the equation editor; I don't know how they could stand it.
> yeah hes insane and believes everyone went to private school like he did lol.
Where did it say he went to private school?
Also, this is not even all that unusual - I got a 1280 on the SAT when it was taken in 7th grade and found myself very, very surprised at how shocked/impressed people were. It honestly wasn't that difficult, and I suppose that with more practice and dedicated training I could have hit 1600 by 10th grade. (getting that 800 in English would have been a royal pain, but I don't see it as having been impossible had I made it a major goal) And oh, I went to a public school. Granted, that district was on the wealthy side.
This makes me think that there's something very fundamental about the test-taking mindset (at least as applies to most standardized tests) that most people just don't get - I'll grant that I was probably better at some subjects than my peers, but not to the amount my standardized test scores would indicate.
However, I'm not of the camp that thinks this testing mindset is useless. Rather, I wonder whether the testing mindset boils down to being able to focus closely on the task at hand to the exclusion of other distractions while under pressure. If so, then this is a valuable skill, and the current system both fails to teach it and punishes students for not acquiring it - the worst possible scenario.
Your comment about tiny text made me wonder - could a user unable to read the EULA (because of the type font size) call up a software company and ask for them to read them the EULA out loud? Is this not a reasonable accomodation to a common disability (inability to read 6pt type, or whatever is used)? Is there some reading disability that would make it impossible to read and understand something presented only one line at a time (because of a really small scroll window)?
Most EULA dialogs I've seen have been very limited in functionality - no chance to, say, copy the EULA text into a program and change the font size. That being said, they usually appear to be in about ten-point type. This is much better than the font that used to be used on the break-this-seal-to-agree envelopes. (Which I actually had to pull out a magnifying glass to read)
Compare to a bank. You pay fees to be able to pay via check. OF course, nobody prevents you from walking or driving a couple hundred kilometers each month to be able to pay in person, in cash.
One of the reasons I am soon to be leaving my bank, as they have piled on fees on top of fees for the last time. Every time I've had a credit union account, I've been very happy with the service and fee schedule; my only issue was the limited ATM availability. (Because federal banking laws prohibit credit unions from growing too large) This experience with a large commercial bank, however, has just made me feel used.
This is however seriously off-topic, and no longer relevant to internet ad revenue.
Exactly - my point was that one doesn't need write access to code that is also marked as executeable in order to alter the program's execution. Of course function pointers have no need to be on executeable pages; however, if they are writeable at all, we have a problem. One just needs write access to something that is used in determining the path of execution. The phrack article pointed out that the GOT (which is essentially a whole load of function pointers - one for every function called in a dynamic library) is loaded to a page that is left writeable. Without adjusting things so that ld-linux.so is much more tightly tied to the kernel, I don't see how it's possible to avoid that. (I suppose there could be some kernel call that would remove the writeable bits from a given page of memory so that that process could never make the pages writeable again - is there such a call?)
While function pointers are the most flexible variable used in determining execution flow, even in a scenario without a writeable GOT or any function pointers (which would require major redesign of at least libc and gcc), you may still be in trouble. As long as a variable that can be overwritten is used in a decision (i.e. if or switch) or as an array index a buffer overrun can affect the program flow. For example, it might be possible in some poorly written program to overwrite some piece of the program's configuration information through a complicated buffer overflow attack - many of even the most secure programs can be made insecure by a bad configuration.
The only absolute solution to containing the potential damage from buffer overflows is to avoid buffer overflows altogether. Each of these steps simply minimizes the number of ways to exploit buffer overruns, which raises the bar and may even shrink the pool of potentially exploitable programs.
So what about function pointers? These need to be on the heap, right? What if you want to call one function but the function pointer is corrupted, causing you to call something else?
Granted, this would severely narrow the window that the Phrack article mentioned, (it talked about overwriting function pointers in the GOT, which in your scheme would presumably be on a read-only page) but so long as buffers are overrunable, there will be some code that experiences some type of exploit.
Looking at the patch, it doesn't seem that this patch fully addresses this issue - it deals with reordering local variables to avoid some of the less desireable effects of overruns, but what about function pointers stored in classes or structs? Those can't be reordered.
So what you mean is that/GS behaves the way StackGuard does. (calling the cookie a canary is not a practice Microsoft initiated).
If you read the phrack article linked to in the story, they discuss situations where this manner of buffer overrun protection is insufficient. True, most exploits out there today do use straight overruns onto the return address, but that's only because they can.
That being said, I imagine that the conditions described in the phrack article for getting a manipulable pointer are less common than the authors would like to think.
Well, there is already a.deb that contains every developer's public key, and in fact developers do send a gpg-signed message to the debian-devel-changes list when an upload is made, so some of the pieces are there.
As I said before though, the glue to hold all this together keeps getting bogged down by the stuff it won't fix.
Slashdot Mirror
You make it sound as though the GPL imposes requirements on corporations that it does not impose on natural persons. I find that bizarre, and don't understand where that reading is coming from.
What the GPL would prevent is having someone take a government-contracted GPLed product, slap a gui front end on it (maybe even with a few silly interface pattents), and then sell the result with a do-not-copy, do-not-reverse-engineer license.
I'll grant you, that's an action corporations are more likely to take than individuals, but the corporate discrimination angle you're trying to play up is downright silly.
Frankly, the no GPL rule makes no sense without a similar rule against standard proprietary licenses; government contractors routinely develop code and then incorporate it into their own do-not-reverse-engineer programs. What happens in that case is that the government gets the code and a license to use it wherever they want internally, but they can't release it to non-governmental institutions.
Certainly the public gains less from that arrangement than it does from an identical arrangement that also allows the government to release said code to the public under the GPL.
Please, please do not use the words "secure application" when what you really mean is "approved application".
What I suspect you really mean is "an application that is doing only what the user intends that application to do". However, that is not necessarily the same as "approved application". (Since software vendors can stick all sorts of cruft and spyware into their "approved" applications) Some Palladium supporters would like everyone to assume that they are the same, and the use of "secure application" supports this confusion.
"Secure application" presumably means, among other things, "an application that is not vulnerable to attempts to make it misbehave". This is also not what "approved application" means.
I wonder - if an approved application contained a buffer overflow or other vulnerability, would it be possible to write a trojan that would operate entirely through that vulnerability as though it were a trusted application? (e.g. a trusted server could be exploited remotely and then the trojan code loaded into memory, running as a thread of the trusted server process) Tricky perhaps, but I've not heard anything that makes me think that Palladium will avoid that scenario.
The point was that by the age of 60, the person who has saved $100 a month since age 20 (note the 40 years bit?) will have only $255,225.08, while the "sap" who waited until 30 to start saving and then put away more will at the age of 60 have $1,196,170.35.
In other words, the exact OPPOSITE of what the "you CAN do it" guy is claiming. Compound interest is certainly a powerful force, but it's not that powerful, at least not at a mere 6.9% interest rate.
By the way, if you wish to repeat these calculations, here are a few perl lines that'll do the math for you:
Especially if you read the article, it states that the real problem was in China and India; as a result there will be no CS GRE in those countries this academic year. So not only will students from those countries face the generally tougher requirements that international students face when applying to US schools, but for this year they won't have the advantage of a GRE score which shows that they know what's what.
So no, it's not a tragedy because it doesn't affect students coming from the US, only those dirty foreigners.
I live in a nice little city here in the Philadelphia suburbs. Looking up and down my block, it's not that different from any other middle- (or possibly lower-middle-) class neighborhood in America.
However, DSL is apparently uneconomical for anyone to offer to this area. I'd pay for it; it sure beats having my computer dialed in from midnight to 5 am each night trying to keep current with Debian testing and unstable. Unfortunately, everywhere with a decent user agreement says that offering me DSL isn't possible at this time.
And that's the real point - the user agreement. I will not surrender control of my computer to my upstream provider by installing their specialized, over-branded spyware. (Not that I could anyway, given that I don't run windows on the main machine) I will run whatever servers I feel like running for whatever legal purpose I choose. I will use encryption and VPN-foo to connect to systems at work.
This is simply not an option with the only broadband game in town (Comcast). It's not the money that broadband providers want from me that holds me back - it's the control they want.
Quoth the poster:
But you did ask the blackhole list people to check your server, yes? You do have the right to access your server in any way you see fit and to permit others the same access, correct?
If I contracted with a security testing firm to test the security of my office, I'd be severely annoyed with them if they did not try to lie their way past the office manager who watches the front door.
You're not getting it, are you?
There are people in this world who will in fact refuse to kill another person even when their own life is in danger.
Really.
Even when they actually have to make the choice in real life.
Furthermore, there are people who can kill another person out of necessity without being happy about it.
Frankly, I'd much rather live in a world populated by those people than by people hyped up on the idea of pre-emptive strikes.
Whether I have the ide-scsi module installed or just the ide-cd module, my CDs are accessible at /dev/cdroms/cdrom0 /dev/cdroms/cdrom1
and
Which drive is which does indeed switch depending on the order in which I choose to load the modules, but anyone who's installed a removable disk driver on windows will tell you that all the disks there jump around too. (e.g.: my wife installed the driver for a compactflash reader on her windows 98 machine, and the CD rom was moved from D: to E: to make room for the compactflash device. Later, we had to re-install it and D: and E: swapped places again)
Anyone saying that linux requires you to use the scsi names hasn't tried devfs lately.
Come on, someone stop commenting on the religion question and answer this one.
l #operator,
The closest thing I found was on http://outerbody.com/ruby/ruby-man-1.4/syntax.htm
which seems to say that in Ruby one can do
foo(*[1,2,3])
instead of
foo(1,2,3)
From what I can tell, in Ruby [] is the standard make-a-list operator, and lists in Ruby seem to operate similarly to lists in Python and array references in perl.
However, this doesn't seem like anything new to perl; doing
foo(@array)
is the same as calling foo with each of the elements of @array as arguments. If $a is an array reference, this becomes:
foo(@$a)
So I don't think that this Ruby operator is what was meant.
While I really hate some of the exaggeration that gets played up in the US media (comparing the WTC disaster to Hiroshima, for example), what's the largest loss of life that an IRA attack has ever caused? 29, right? ("Real IRA" car bomb in 1998)
Have one hundred incidents that bad and then tell me that the UK has had comparable experience.
I'm glad someone else got around to reading those amendments that follow the first ten.
Oh, I do have it. I had just forgotten to recheck the box.
I had turned popups on (a blog comment page required them) and forgotten about it. Visiting Netscape's page pops up a BIG HUGE ad for Netscape 7.
NetBIOS (I admit that the name has meant a few different things as it evolved) is not the same as NetBEUI. NetBEUI is a layer 2 protocol, and is not propogated by most routers. (unless the "router" is really an ethernet bridge in disguise)
NetBIOS is a programming interface implemented as a bunch of packet types which can be sent out either over NetBEUI or over IP. (sitting mostly on top of TCP, though I think some packets are sent out with UDP). IP is extremely routable.
I cannot believe that you have ever used wordperfect's equation editor if you made the above statement. (Maybe you've only used it after Corel broke it by trying to make it graphical the way word's is)
I remember using it with old dos-based wordperfect in high school, (circa 1992) and it was miles beyond even current generations of word's equation editor. Basically, it was a stripped-down version of tex that let you just type what you wanted, and have it come out right. Not only that, but I never had to watch the screen to make sure my mouse pointer is over just the right one of twenty different buttons arranged in a little grid. I cannot imagine anyone wanting to use word's interface unless equations represent less than about 5% of the article's vertical space. Until I got to college and learned about TeX, I thought it was clearly the greatest thing ever for producing technical output. I still don't understand those people who would write up physics lab reports, complete with rather verbose equations, in word using the equation editor; I don't know how they could stand it.
> yeah hes insane and believes everyone went to private school like he did lol.
Where did it say he went to private school?
Also, this is not even all that unusual - I got a 1280 on the SAT when it was taken in 7th grade and found myself very, very surprised at how shocked/impressed people were. It honestly wasn't that difficult, and I suppose that with more practice and dedicated training I could have hit 1600 by 10th grade. (getting that 800 in English would have been a royal pain, but I don't see it as having been impossible had I made it a major goal) And oh, I went to a public school. Granted, that district was on the wealthy side.
This makes me think that there's something very fundamental about the test-taking mindset (at least as applies to most standardized tests) that most people just don't get - I'll grant that I was probably better at some subjects than my peers, but not to the amount my standardized test scores would indicate.
However, I'm not of the camp that thinks this testing mindset is useless. Rather, I wonder whether the testing mindset boils down to being able to focus closely on the task at hand to the exclusion of other distractions while under pressure. If so, then this is a valuable skill, and the current system both fails to teach it and punishes students for not acquiring it - the worst possible scenario.
Your comment about tiny text made me wonder - could a user unable to read the EULA (because of the type font size) call up a software company and ask for them to read them the EULA out loud? Is this not a reasonable accomodation to a common disability (inability to read 6pt type, or whatever is used)? Is there some reading disability that would make it impossible to read and understand something presented only one line at a time (because of a really small scroll window)?
Most EULA dialogs I've seen have been very limited in functionality - no chance to, say, copy the EULA text into a program and change the font size. That being said, they usually appear to be in about ten-point type. This is much better than the font that used to be used on the break-this-seal-to-agree envelopes. (Which I actually had to pull out a magnifying glass to read)
Ok; could you tell us what your company does do, or at least give us a link to your company's site?
We may not be interested in the service your company offers but I would at least be interested in knowing what that service is.
One of the reasons I am soon to be leaving my bank, as they have piled on fees on top of fees for the last time. Every time I've had a credit union account, I've been very happy with the service and fee schedule; my only issue was the limited ATM availability. (Because federal banking laws prohibit credit unions from growing too large) This experience with a large commercial bank, however, has just made me feel used.
This is however seriously off-topic, and no longer relevant to internet ad revenue.
Exactly - my point was that one doesn't need write access to code that is also marked as executeable in order to alter the program's execution. Of course function pointers have no need to be on executeable pages; however, if they are writeable at all, we have a problem. One just needs write access to something that is used in determining the path of execution. The phrack article pointed out that the GOT (which is essentially a whole load of function pointers - one for every function called in a dynamic library) is loaded to a page that is left writeable. Without adjusting things so that ld-linux.so is much more tightly tied to the kernel, I don't see how it's possible to avoid that. (I suppose there could be some kernel call that would remove the writeable bits from a given page of memory so that that process could never make the pages writeable again - is there such a call?)
While function pointers are the most flexible variable used in determining execution flow, even in a scenario without a writeable GOT or any function pointers (which would require major redesign of at least libc and gcc), you may still be in trouble. As long as a variable that can be overwritten is used in a decision (i.e. if or switch) or as an array index a buffer overrun can affect the program flow. For example, it might be possible in some poorly written program to overwrite some piece of the program's configuration information through a complicated buffer overflow attack - many of even the most secure programs can be made insecure by a bad configuration.
The only absolute solution to containing the potential damage from buffer overflows is to avoid buffer overflows altogether. Each of these steps simply minimizes the number of ways to exploit buffer overruns, which raises the bar and may even shrink the pool of potentially exploitable programs.
So what about function pointers? These need to be on the heap, right? What if you want to call one function but the function pointer is corrupted, causing you to call something else?
Granted, this would severely narrow the window that the Phrack article mentioned, (it talked about overwriting function pointers in the GOT, which in your scheme would presumably be on a read-only page) but so long as buffers are overrunable, there will be some code that experiences some type of exploit.
Looking at the patch, it doesn't seem that this patch fully addresses this issue - it deals with reordering local variables to avoid some of the less desireable effects of overruns, but what about function pointers stored in classes or structs? Those can't be reordered.
So what you mean is that /GS behaves the way StackGuard does. (calling the cookie a canary is not a practice Microsoft initiated).
If you read the phrack article linked to in the story, they discuss situations where this manner of buffer overrun protection is insufficient. True, most exploits out there today do use straight overruns onto the return address, but that's only because they can.
That being said, I imagine that the conditions described in the phrack article for getting a manipulable pointer are less common than the authors would like to think.
An interesting theory, but I think that you should read this section of the GPL faq.
In short, both static and shared linking are treated the same way.
Well, there is already a .deb that contains every developer's public key, and in fact developers do send a gpg-signed message to the debian-devel-changes list when an upload is made, so some of the pieces are there.
As I said before though, the glue to hold all this together keeps getting bogged down by the stuff it won't fix.
Suppose I find a vulnerability in some random company's web site. After telling them about it, whom else do I tell? The NIPC?
And same for a widely used piece of software - after the software company, who in the government gets the report?