VC 6 can disable this behavior, and I don't see how it affects MSs libraries (unless the STL that ships with them uses that construct? It's not even MS's STL, but okay...). MS kept with it because earlier versions of VC used it. It's an extension. If people in your project using it bother you, then disable it. It's a syntatical issue, one of coding style, not one of efficency.
Not to mention that the non-standard behavior (which pre-dates the standard that said it's wrong) is well known and was implemented in more compilers than VC++, and most of the compilers I know of have switches to support it.
Not directly, but inputting, say, the name of a function or command to call, looking that up in a table of function pointers, and executing the pointed-to function amounts to the same thing.
SCO claims (although they have not publically released this information) to have detailed, specific information about the code that was inserted. They would have to - this isn't something that you find out AFTER you file a billion dollar lawsuit. You do your own discovery first.
As I posted before - theoretically, both SCO upper management and SCO lawyers are aware of the implications of the GPL. If they aren't, then they're grossly negligent. In that case, they should be very aware of the fact that continuing distribution after they are aware of the existence of the offending code has at least the potential for signifigant legal problems - if every Joe Schmoe on Slashdot can see it, they certainly can. In this case, going public with thier accusations before cleaning house internally is again grossly negligent.
I would agree with almost everything you've said _if_ SCO hadn't been so free with both thier accusations and thier lawsuits - you shouldn't do that until AFTER you've cleaned house internally.
The parts I wouldn't agree with - that SCO wouldn't know if the offending code is in thier distro after they discovered it. Removing the code you're already aware of is the least of the obvious things to do before filing your lawsuit. Here's something even more important - assuming every single one of SCOs allegations is true, they have no legal right to distribute Linux at all. That's a very obvious consequence of the GPL, and continuing to illegally distribute your product, even a major one, after making very public and very offensive comments is a pretty major blunder.
MS provides BINARY compatability for programs written 5 years, 4 major versions, and 1 architecture change ago - more than that, if you count 16bit programs (support for that is bad enough that I won't hold it up as an example, though). That's a pretty fucking impressive achievement. I'm not sure where you get your "changes things completely every couple years" from.
MS doesn't give a shit about C#, they care about.NET. Pretend that.NET is the Win32 API and you'll see what I mean. They don't care what language you use, they just want you to target Win32. In the future, they don't care what language you use, they just want you to target.NET. Simple.
....except that C# actually works and D doesn't. mmmm. Inferiority!
Actually, I really like the idea of D and wish that it was more mature:P But I'd hardly say that, in it's present form, it's SUPERIOR to C#. Or even that they address the same problem space.
There's a signifigant inertia to overcome with the acceptance of any new language. One of the barriers is the creation of a useful runtime, porting that runtime to common platforms, keeping it supported, etc. There's a whole bunch of languages out there, but probably 90% of applications are written in less than a dozen of them (Java, VB, C, C++, Delphi... am I missing anything else major?).
One way to overcome that inertia is to provide bindings for your niche language against a major runtime - like compiling it to Java bytecode, or, in this case, IL.
Now,.NET has it's own inertia to overcome, but because it's Microsofts baby, it has alot of advantages that the language/runtime that Joe Programmer makes doesn't have.
This is interesting for a couple other reasons - it's been reported before that it should be easy to port functional languages to.NET - and that it's apparently hard to have them compile to Java (I don't know crap about functional languages, I'm just parroting here), so here's the proof of that. Also, like it or not,.NET is very big and is being very heavily pushed by the single most influential company in IT - and if you're a fan of functional languages, I don't see how this is a loss for you or why you're bitter about it.
It's a good thing you aren't a hiring manager, because you'd get someone sued. You think that the entire fucking sales force of SCO, which was aggressively marketing and selling Linux was operating "without authorization"?
If you're acting within the authority of your position, on behalf of your company, then yes, your company is liable for your actions. If you're a web admin, with write access to production webservers, and you replace your companies home page with, say, kiddie porn, you're damn right your company is going to get sued - especially if they didn't take IMMEDIATE action to remove you from your position and take the offending website offline.
You don't magically not represent your company anymore if you do something wrong - like not ensure that the code you know to be your trade secret (because you're filing a BILLION dollar lawsuit against one of the largest companies in the world) is removed from your anonymous FTP server, and that you continue distributing it under a license you know to be fundamentally opposed to the sort of controls you're trying to exert of this IP (because you're not a total fucking moron and had your lawyers read and explain the GPL). Yes, you're acting in your capacity as a company officer and within your authority as a representative of the company, and therefore you're actiing as a copyright holder.
Someone posting things to the official company website, assuming they have authority to do so (in general - IE, they aren't cracking the webserver) is acting in thier capacity as a representative of the company. It doesn't matter that the engineer doesn't personally own the code.
This doesn't apply to web forms, or ASP.NET, or even.NET ActiveX controls (for normal use, anyway. Someone intentionally trying to crack your ActiveX control probably can. If you're relying on them to be secured from the client machine they're running on, stop doing that). So as a web developer this has nothing to do with you.
There's nothing different about a "users code" and a libraries code - designing a VM such that there is is just asking for trouble. And yes, there is a signifigant overhead in a runtime security check. Java actually doesn't run the check at runtime - if you can get a pointer to a private method, you can call it. You just can't normally get one without either reflection or hacking your VM, and reflection provides the security check.
And, of course, it's NOT A SECURITY HOLE. You can't do anything in a private member you can't do in a public one. And if you're relying on VMs or libraries, either now or in the future to protect your code by making a private declaration a security measure you're in for a world of hurt. Use the OSes security measures, thats what they're for. As you say - it's possible to write a VM where all private data is kept apart from the users code, and, in fact, thats exactly what they do now! Except you don't use this feature with a private declaration. You use it by calling security APIs that the OS provides.
Or better yet, stop spending so much time trying to keep people from manipulating bytes on thier own machines.
You're confusing "protecing private data" with "protecting private data members". You certainly COULD go the the hard route, which involves a huge overhead of runtime checks (do you really want every single method call to have the overhead of RTTI, walking the inheritence heirarchy, etc, etc?). A much easier way, which both normal OSes as well as VMs do, is to have the VM(read OS) provide secure facilities for this sort of thing - and since enforcing process level seperation includes not letting processes step on itself, it works fine.
As most of the other posts here have mentioned - the.NET VM most certainly does provide data hiding and access control. It even provides the ability to prevent reflection, which is what all this is about, although it's a security policy, not something you set in client code (I'm not sure if assemblies can refuse to run in the absence of a security policy - I suspect they can).
I don't even know what the hell you just said. a VM _is_ an operating system (that's why it's called a virtual machine). It provides it's own process level memory protection (just like the OS it's running under does). Member visibility does not allow you to circumvent this. And member visibility doesn't have the slightest thing to do with memory protection anyway - I'm not aware of any language where theres "special" things you can do in private members but not public ones, or where you can do "unsafe" things in private members but not public members. In such a environment, yes, you would need to enforce member visibility, but.NET doesn't work that way.
The GPL allows dual licensing under other licenses that guarantee at least the rights the GPL provides - so if your hypothetical other license is "GPL compatible" - there's a list of them on the FSF website - then you can link code under said license with GPL code with no worries. If it's the OTHER license that says you can't link it with code licensed under any other license - well, thats not the GPLs fault:P
Also, re: choosing the GPL - I do it for a couple reasons. One is that I'm proud of my work and I want to see what other people do with it. Another is that I don't want anyone else directly making money off my code - supporting it yes, but making it better and selling that, no.
All that said, I also prefer to use the LGPL (at least for libraries), because while I want MY work to be maintained, I don't care if you call my code from yours.
Is it possible the GPL software running on the box hasn't been source modified, and therefore simply providing the address of the official download site is sufficent under the GPL?
You ensure that you won't access it by ACCIDENT. Private is to help you write clean code, not to protect your code from someone trying to break it.
Another place it's use is in design by contract (the Digital Mars C++ compiler has it), where you make "promises" about the state of an object, can you can only break that promise within a private member. Note, though, that like the private keyword this is a compiler enforced directive on the developer, NOT a security model! It's to help you write bug-free code, not to keep someone from accessing your private data.
A private member indicates that it's used to provide internal functionality to a class - that it shouldn't be used from outside that class. Private members are subject to change, because they're an implementation detail.
.NET provides access the OS security API for storing things like credit card numbers. There's certainly no reason for persisting it in a private member and then serializing it! And, in any case,.NET DOES provide a way of preventing reflection, just as Java does - the "exploit"[documented quite clearly on MSDN] only works if you're running under full trust.
Private members in.NET don't have any special exemption from the other security and access checks the runtime provides (just as public members in C aren't any more secure - calling sprintf without bounds checking is a flaw no matter where you call it from).
The most you can do with this flaw is violate APPLICATION security, and if you can even do that it's the application programmers fault.
Making a member private does not provide security. Nobody has ever said it does - in ANY language. Assuming it does means you're making naive and unsafe security decisions - it's YOUR fault, not the language or the runtimes.
Re:Stop the anti-MS BS all the damned time
on
Hijacking .NET
·
· Score: 1
Give me an example of using this flaw to do something "bad" to my machine (assuming that I've granted the applet permission to use reflection but not to, say, use p/invoke or run unsafe code).
You can't break anything except application level security with this. That means it might be good for defeating very naive copy protection or other forms of DRM. You can't use it execute unsafe code or adversely affect anything outside the sandbox - there's no security risk from it.
Re:More version incompatible program
on
Hijacking .NET
·
· Score: 1
As (dozens) of other people have said, it's a convenience. The.NET framework prevents unsafe code from running even in private members - they have no special rights - so it's only a "security" flaw as far as your application level security goes. Since application level security that's this primitive is trivially hackable in ANY language, people who do it should be smacked, and.NET shouldn't be bashed for it, since it's not a flaw.
Compiler enforcement of public/private seperation is gravy - it's main use is to notify client programmers that they are not to use those methods, and, in certain compilers/languages/frameworks/IDEs to remove the temptation by not even showing you the method.
Re:Slightly OT: Linking static libs w/GPL'd code?
on
What if SCO is Right?
·
· Score: 1
See, you say that like my job is satisfying user expectations. And it's slowness is certainly not a demonstrable fact - many pages render faster in Mozilla than IE. Some pages are the opposite. "Speed", especially of a web broswer, is highly subjective and something difficult to objectively test.
Slashdot Mirror
VC 6 can disable this behavior, and I don't see how it affects MSs libraries (unless the STL that ships with them uses that construct? It's not even MS's STL, but okay...). MS kept with it because earlier versions of VC used it. It's an extension. If people in your project using it bother you, then disable it. It's a syntatical issue, one of coding style, not one of efficency.
Not to mention that the non-standard behavior (which pre-dates the standard that said it's wrong) is well known and was implemented in more compilers than VC++, and most of the compilers I know of have switches to support it.
Not directly, but inputting, say, the name of a function or command to call, looking that up in a table of function pointers, and executing the pointed-to function amounts to the same thing.
From your source:
pl.n. (used with a sing. or pl. verb)
SCO claims (although they have not publically released this information) to have detailed, specific information about the code that was inserted. They would have to - this isn't something that you find out AFTER you file a billion dollar lawsuit. You do your own discovery first.
As I posted before - theoretically, both SCO upper management and SCO lawyers are aware of the implications of the GPL. If they aren't, then they're grossly negligent. In that case, they should be very aware of the fact that continuing distribution after they are aware of the existence of the offending code has at least the potential for signifigant legal problems - if every Joe Schmoe on Slashdot can see it, they certainly can. In this case, going public with thier accusations before cleaning house internally is again grossly negligent.
I would agree with almost everything you've said _if_ SCO hadn't been so free with both thier accusations and thier lawsuits - you shouldn't do that until AFTER you've cleaned house internally.
The parts I wouldn't agree with - that SCO wouldn't know if the offending code is in thier distro after they discovered it. Removing the code you're already aware of is the least of the obvious things to do before filing your lawsuit.
Here's something even more important - assuming every single one of SCOs allegations is true, they have no legal right to distribute Linux at all. That's a very obvious consequence of the GPL, and continuing to illegally distribute your product, even a major one, after making very public and very offensive comments is a pretty major blunder.
MS provides BINARY compatability for programs written 5 years, 4 major versions, and 1 architecture change ago - more than that, if you count 16bit programs (support for that is bad enough that I won't hold it up as an example, though). That's a pretty fucking impressive achievement. I'm not sure where you get your "changes things completely every couple years" from.
MS doesn't give a shit about C#, they care about .NET. Pretend that .NET is the Win32 API and you'll see what I mean. They don't care what language you use, they just want you to target Win32. In the future, they don't care what language you use, they just want you to target .NET. Simple.
quicksort in 3 lines of readable C++ code:
#include "quicksort.h"
Quicksort sorter;
sorter.Sort();
Actually, I really like the idea of D and wish that it was more mature :P But I'd hardly say that, in it's present form, it's SUPERIOR to C#. Or even that they address the same problem space.
One way to overcome that inertia is to provide bindings for your niche language against a major runtime - like compiling it to Java bytecode, or, in this case, IL.
Now, .NET has it's own inertia to overcome, but because it's Microsofts baby, it has alot of advantages that the language/runtime that Joe Programmer makes doesn't have.
This is interesting for a couple other reasons - it's been reported before that it should be easy to port functional languages to .NET - and that it's apparently hard to have them compile to Java (I don't know crap about functional languages, I'm just parroting here), so here's the proof of that. Also, like it or not, .NET is very big and is being very heavily pushed by the single most influential company in IT - and if you're a fan of functional languages, I don't see how this is a loss for you or why you're bitter about it.
If you're acting within the authority of your position, on behalf of your company, then yes, your company is liable for your actions. If you're a web admin, with write access to production webservers, and you replace your companies home page with, say, kiddie porn, you're damn right your company is going to get sued - especially if they didn't take IMMEDIATE action to remove you from your position and take the offending website offline.
You don't magically not represent your company anymore if you do something wrong - like not ensure that the code you know to be your trade secret (because you're filing a BILLION dollar lawsuit against one of the largest companies in the world) is removed from your anonymous FTP server, and that you continue distributing it under a license you know to be fundamentally opposed to the sort of controls you're trying to exert of this IP (because you're not a total fucking moron and had your lawyers read and explain the GPL). Yes, you're acting in your capacity as a company officer and within your authority as a representative of the company, and therefore you're actiing as a copyright holder.
Someone posting things to the official company website, assuming they have authority to do so (in general - IE, they aren't cracking the webserver) is acting in thier capacity as a representative of the company. It doesn't matter that the engineer doesn't personally own the code.
This doesn't apply to web forms, or ASP.NET, or even .NET ActiveX controls (for normal use, anyway. Someone intentionally trying to crack your ActiveX control probably can. If you're relying on them to be secured from the client machine they're running on, stop doing that). So as a web developer this has nothing to do with you.
And, of course, it's NOT A SECURITY HOLE. You can't do anything in a private member you can't do in a public one. And if you're relying on VMs or libraries, either now or in the future to protect your code by making a private declaration a security measure you're in for a world of hurt. Use the OSes security measures, thats what they're for. As you say - it's possible to write a VM where all private data is kept apart from the users code, and, in fact, thats exactly what they do now! Except you don't use this feature with a private declaration. You use it by calling security APIs that the OS provides.
Or better yet, stop spending so much time trying to keep people from manipulating bytes on thier own machines.
As most of the other posts here have mentioned - the .NET VM most certainly does provide data hiding and access control. It even provides the ability to prevent reflection, which is what all this is about, although it's a security policy, not something you set in client code (I'm not sure if assemblies can refuse to run in the absence of a security policy - I suspect they can).
I view selling it + source as "making it better", since the GPL prevents them from keeping the reciever from re-distributing it.
I don't even know what the hell you just said. a VM _is_ an operating system (that's why it's called a virtual machine). It provides it's own process level memory protection (just like the OS it's running under does). Member visibility does not allow you to circumvent this. And member visibility doesn't have the slightest thing to do with memory protection anyway - I'm not aware of any language where theres "special" things you can do in private members but not public ones, or where you can do "unsafe" things in private members but not public members. In such a environment, yes, you would need to enforce member visibility, but .NET doesn't work that way.
Also, re: choosing the GPL - I do it for a couple reasons. One is that I'm proud of my work and I want to see what other people do with it. Another is that I don't want anyone else directly making money off my code - supporting it yes, but making it better and selling that, no.
All that said, I also prefer to use the LGPL (at least for libraries), because while I want MY work to be maintained, I don't care if you call my code from yours.
Is it possible the GPL software running on the box hasn't been source modified, and therefore simply providing the address of the official download site is sufficent under the GPL?
Another place it's use is in design by contract (the Digital Mars C++ compiler has it), where you make "promises" about the state of an object, can you can only break that promise within a private member. Note, though, that like the private keyword this is a compiler enforced directive on the developer, NOT a security model! It's to help you write bug-free code, not to keep someone from accessing your private data.
A private member indicates that it's used to provide internal functionality to a class - that it shouldn't be used from outside that class. Private members are subject to change, because they're an implementation detail.
Private members in .NET don't have any special exemption from the other security and access checks the runtime provides (just as public members in C aren't any more secure - calling sprintf without bounds checking is a flaw no matter where you call it from).
The most you can do with this flaw is violate APPLICATION security, and if you can even do that it's the application programmers fault.
Making a member private does not provide security. Nobody has ever said it does - in ANY language. Assuming it does means you're making naive and unsafe security decisions - it's YOUR fault, not the language or the runtimes.
Give me an example of using this flaw to do something "bad" to my machine (assuming that I've granted the applet permission to use reflection but not to, say, use p/invoke or run unsafe code).
You can't break anything except application level security with this. That means it might be good for defeating very naive copy protection or other forms of DRM. You can't use it execute unsafe code or adversely affect anything outside the sandbox - there's no security risk from it.
Compiler enforcement of public/private seperation is gravy - it's main use is to notify client programmers that they are not to use those methods, and, in certain compilers/languages/frameworks/IDEs to remove the temptation by not even showing you the method.
See, you say that like my job is satisfying user expectations. And it's slowness is certainly not a demonstrable fact - many pages render faster in Mozilla than IE. Some pages are the opposite. "Speed", especially of a web broswer, is highly subjective and something difficult to objectively test.