Coffeehouse Thread

60 posts

What is your prediction for .NET framework 4.0?

Back to Forum: Coffeehouse
  • User profile image
    littleguru

    Anyway, .NET 4.0 is going to be about LINQ and the new more functional possibilities for C# and other languages... AFAIK.

  • User profile image
    Secret​Software

    littleguru wrote:
    
    SecretSoftware wrote:2) I want to do this :

    s = new Socket (), rather than Socket s = new Socket (),

    I know var kinda does this,but I want a variable to hold multiple types  in the course of execution. so I can set s = null, and assign it to a new instance of another object


    aaaah! I can already see the mess. s being Socket then Form then Foo then DateTime... Please no!


    Well, the run time still can make type checking. What I mean is that the compiler should just infer the type of s from what its value type is, without writing extra keywords. This can be done while maintaining the type checking.

  • User profile image
    Secret​Software

    littleguru wrote:
    
    SecretSoftware wrote:Basically integrate .NET with Directx libraries, so you can use them natively in the .NET framework and leverage these right there into your applications.


    Isn't that WPF?


    WPF is cool and all, but its not as rich as having Directx stuff in. There are things in Directx that are cool and should be there.

  • User profile image
    Secret​Software

    littleguru wrote:
    
    SecretSoftware wrote:12) Applications should be able to do self diagnostics and also be able to check their integrity on their own. The CLR should refuse to run applications whose compile time hash is different than their pre-runtime hash, or even during runtime hash. Find a way to make the application self-aware of its integrity as part of the services provided by the CLR. the Strongname while good, its still a mess because malicous hackers can sign the assembly themselves and the modify it.


    Is already there and called "strong name".


    As I already pointed out, Strong Name fails in its goal. Hackers can change the code and resign it again. So its useless. Strong name can protect against average users who no nothing in computers than just to move the mouse around.

    We need something more reliable than this. Something that will really raise the bar too high.

  • User profile image
    Secret​Software

    littleguru wrote:
    
    SecretSoftware wrote:13) I wish that the .NET framework and the Runtime in general would encrypt in memeory strings by default. No one should see whats in memory except the application itself (perhapse symmetric crypto between memory space and application?).


    Damn that gets slow... Next everybody would cry that .NET is so slow... Should be only optional and disabled by default (to avoid the crying)


    With multi-cores , I doubt this will be a problem. Slow is a thing of the past and let the Ghzs do background crypto stuff through some abstraction layer in the runtime. Plus symmetric crypto is faster.

  • User profile image
    Secret​Software

    littleguru wrote:
    
    SecretSoftware wrote:14) the compiler should be a smart compiler. Basically when you have repetitive code that is similar in manipulation of things, but is different in minor areas, that it groups the similar stuff together into new methods, and arrange for the flow to be correct at the same time. This would result in small size product and efficent code.


    The MSIL code you see when looking at it with ILDASM is the real code that gets executed... The runtime is inlining and removing vtables etc. (the jitter and managed runtime is also here for something). That happens all behind the scenes. The runtime does already a lot to make code faster and remove duplicate stuff.

    I wouldn't like the compiler to remove a piece of code an call another method that does the same, just because he thinks so. That's weird if you do performance checking etc. It looks non deterministic to the user. The developer might also have thought a little bit when putting the code not in the other method, when having it in two methods... Performance, for example, could be a reason.

    It's better to educate the developers to write better code then having the compiler to do it!



    Suppose you have

    void string Method1 {
       Do X manipulation
       Then do Y1 manipulation

    }

    void string Method2 {
        Do Z manipulation
        Then Do Y1' manipulation (very similar in technical implementation to Y1
    }

    So compiler sees this, and seperates  Y1' and Y1 into new method that supports the manipulations required by Method1 and Method2

    This can be extended to all code base. So similar stuff can be grouped together and so on.


    Devs can write good code but still they would have some repeating stuff that on first sight of code you see that they are different but in reality they are not that different. So precompile code analysis would detect this and the compiler should be enough to do stuff like this.

  • User profile image
    Sven Groot

    SecretSoftware wrote:
    As I already pointed out, Strong Name fails in its goal. Hackers can change the code and resign it again. So its useless. Strong name can protect against average users who no nothing in computers than just to move the mouse around.

    We need something more reliable than this. Something that will really raise the bar too high.

    The problem with this is that it's virtually impossible. If you embed the checking in the application, hackers would be able to remove the check when they modify the application. If it's part of the CLR, then the problem remains that the CLR doesn't know what signature an assembly should have. You can include that information in the assembly (as it is with strong names), but what's stopping the hacker from modifying that too? It's a catch-22.

    Strong naming is primarily meant to identify assemblies uniquely, kind of like GUIDs in COM, not as an anti-hacking tool. They have the benefit that if assembly X references assembly Y by its strong name, X can be sure it gets the exact version of Y it wants, not a different one that's incompatible. Here it works because it's X that knows what signature Y should have, but that won't help if a hacker also changes X of course. That plus the ability to assign trust to assemblies with specific signatures in the framework's CAS policy is basically all that it's meant for.

  • User profile image
    Secret​Software

    littleguru wrote:
    
    SecretSoftware wrote:8) Add Memory space randomization. So that when your application starts its memory space fingerprint looks different than last time. Making it hard for exploit code to work in .NET framework applications (This should be supported by the runtime).


    The GC is already collecting data if there is time and depending on how full the memory already is etc. This does mean also some randomization.

    If you do some interop and a native method relies on the location of an object in memory you have to pin it in C#. If you are not doing that the GC moves it around as he wants and the native method gets the wrong piece of memory.



    But this is not strong enough to prevent code exploitations and specially crafted in memory injection attacks. If the application is always changing its memory space location with each restart , then its hard to know where a given memory buffer is and hence attacks that are memory based would fail.

    MS already added this into Vista, so why not let devs also have it.

  • User profile image
    Secret​Software

    Sven Groot wrote:
    
    SecretSoftware wrote:As I already pointed out, Strong Name fails in its goal. Hackers can change the code and resign it again. So its useless. Strong name can protect against average users who no nothing in computers than just to move the mouse around.

    We need something more reliable than this. Something that will really raise the bar too high.

    The problem with this is that it's virtually impossible. If you embed the checking in the application, hackers would be able to remove the check when they modify the application. If it's part of the CLR, then the problem remains that the CLR doesn't know what signature an assembly should have. You can include that information in the assembly (as it is with strong names), but what's stopping the hacker from modifying that too? It's a catch-22.


    Well, if MS really wants to do it they can. They can use steganography or similar techniques to make it harder for hackers to find stuff in the assemly or what the CLR needs or want.

    Ultimately its a design problem. MS knows the system better than us, so they should find a way to solve this problem.

    The problem is that people need to ensure that their running application is not tampered with. I have seen zombie applications that look legitimate and they are not, and many people fall victims to it. Its really is a serious problem and a serious security concern.

    Sven Groot wrote:
    

    Strong naming is primarily meant to identify assemblies uniquely, kind of like GUIDs in COM, not as an anti-hacking tool. They have the benefit that if assembly X references assembly Y by its strong name, X can be sure it gets the exact version of Y it wants, not a different one that's incompatible. Here it works because it's X that knows what signature Y should have, but that won't help if a hacker also changes X of course. That plus the ability to assign trust to assemblies with specific signatures in the framework's CAS policy is basically all that it's meant for.


    Yes, and that is why its limited in terms of use. Things need to be better here.

    Yes MS cares about Security and all, but I have seen things that made me paranoid enough to ask about this every time I talk to any MS guy or any Tech guy I see.


  • User profile image
    Secret​Software

    Another thing I want to see is support for multi-language GUIs. So you can support many of the famous languages into your GUI directly.

  • User profile image
    AndyC

    SecretSoftware wrote:
    

    Well, the run time still can make type checking. What I mean is that the compiler should just infer the type of s from what its value type is, without writing extra keywords. This can be done while maintaining the type checking.


    if (someCondition)
    {
       s = new string();
    } else {
       s = new int32();
    }

    //what type is s here?

    Variant types like this are prone to misuse, bad for optimization and code analysis and just plain ugly.

    SecretSoftware wrote:
    
    Hackers can change the code and resign it again. So its useless.
    

    See Authenticode.

  • User profile image
    Secret​Software

    AndyC wrote:
    
    SecretSoftware wrote:

    Well, the run time still can make type checking. What I mean is that the compiler should just infer the type of s from what its value type is, without writing extra keywords. This can be done while maintaining the type checking.


    if (someCondition)
    {
       s = new string();
    } else {
       s = new int32();
    }

    //what type is s here?

    Variant types like this are prone to misuse, bad for optimization and code analysis and just plain ugly.


    s would be dependant on the condition. Initially s would be an object type and then its assigned to a string if someCondition is true, or if false would be assigned to a number.

    This is present in other programming languages too, so its not a new thing.


  • User profile image
    vesuvius

    Not too sure about predicting what might be available but you’re not asking for too much now are you. Go here to see Anders's video posted yesterday to see a few items on your "wish list" alluded to, like loops, code analysis, reducing the .NET imprint on the client and so on.

    Most of what he speaks about will be familiar too you all though, but he does disclose one or two "nuggets". I do agree with most of your "wish list" but feel that obfuscation etc will only be introduced for an additional surcharge regardless of whoever makes this universally available. Windows Vista has better security that should hopefully prevent the .dll injection attacks consequent to the program files folder requiring raised privileges via User Account Control. MS are aware of this and have introduced their Live OneCare product (at a cost!).





    .
  • User profile image
    Sven Groot

    SecretSoftware wrote:
    This is present in other programming languages too, so its not a new thing.

    It's a fundamental difference between type-safe languages (such as Java, C#, C++) and dynamic languages (Perl, PHP, Python, javascript). What you're proposing is a completely different paradigm and does not belong in a type-safe language.

    Fwiw VB.NET is somewhat capable of this with late binding, but it's dependent on reflection so very slow compared to regular virtual calls. And as thumbtracks points out, there's zero intellisense support when you do that.

  • User profile image
    Sven Groot

    SecretSoftware wrote:
    Well, if MS really wants to do it they can. They can use steganography or similar techniques to make it harder for hackers to find stuff in the assemly or what the CLR needs or want.

    Ultimately its a design problem. MS knows the system better than us, so they should find a way to solve this problem.

    That's real easy to say if you don't have to do it yourself. Yes, they can make it harder, but I'm of the opinion that they can never make it impossible. If it's made by a man it can be broken by a man. And security through obscurity is definitely not the way to do it.

    Authenticode does the job reasonably well, the only problem with it is that it's the user that has to make a trust decision. The reason for this is like I said, there's no way to let the system know what signature to expect that the hacker can't hack as well.

    The only ways I can think of to do this would require extensive and expensive public infrastructure where every piece of code that wants to do this is registered under a privately controlled system protected by known signatures (like Microsoft's own). It's just not worth it.

  • User profile image
    Secret​Software

    thumbtacks wrote:
    
    SecretSoftware wrote:
    AndyC wrote: 
    SecretSoftware wrote: 

    Well, the run time still can make type checking. What I mean is that the compiler should just infer the type of s from what its value type is, without writing extra keywords. This can be done while maintaining the type checking.


    if (someCondition)
    {
       s = new string();
    } else {
       s = new int32();
    }

    //what type is s here?

    Variant types like this are prone to misuse, bad for optimization and code analysis and just plain ugly.


    s would be dependant on the condition. Initially s would be an object type and then its assigned to a string if someCondition is true, or if false would be assigned to a number.

    This is present in other programming languages too, so its not a new thing.
    This is a great idea. But how would Intellisense handle such an issue? For instance, if you write up a function further down in your code starting with:

    s.

    How will the code completion part of the IDE know if you want a string there or an Int32? Wouldn't you also have to write code to handle whichever instance came up?


    Well when you start with s it will be just a null object holding nothing, and intellisese would just support it as being a null object. Once its assumed a new type intellisense would detect this and make available the stuff associated with that type.

    In the flow of the program you know that between point A and point B in the program execution plan that s will assume , say a stirng value, and your code would handle a string value. So you would have to use a switch here were you can handle the types that s assumes and ignore other types that you dont want to handle.

  • User profile image
    Secret​Software

    Sven Groot wrote:
    
    SecretSoftware wrote:This is present in other programming languages too, so its not a new thing.

    It's a fundamental difference between type-safe languages (such as Java, C#, C++) and dynamic languages (Perl, PHP, Python, javascript). What you're proposing is a completely different paradigm and does not belong in a type-safe language.

    Fwiw VB.NET is somewhat capable of this with late binding, but it's dependent on reflection so very slow compared to regular virtual calls. And as thumbtracks points out, there's zero intellisense support when you do that.


    What I propose is support for the kinds of stuff that Python has. C# takes from the good stuff in other languages so in a way its a mix of the good stuff in other languages.

  • User profile image
    Secret​Software

    Sven Groot wrote:
    
    SecretSoftware wrote:Well, if MS really wants to do it they can. They can use steganography or similar techniques to make it harder for hackers to find stuff in the assemly or what the CLR needs or want.

    Ultimately its a design problem. MS knows the system better than us, so they should find a way to solve this problem.

    That's real easy to say if you don't have to do it yourself. Yes, they can make it harder, but I'm of the opinion that they can never make it impossible. If it's made by a man it can be broken by a man. And security through obscurity is definitely not the way to do it.

    Authenticode does the job reasonably well, the only problem with it is that it's the user that has to make a trust decision. The reason for this is like I said, there's no way to let the system know what signature to expect that the hacker can't hack as well.

    The only ways I can think of to do this would require extensive and expensive public infrastructure where every piece of code that wants to do this is registered under a privately controlled system protected by known signatures (like Microsoft's own). It's just not worth it.


    MS can enable a Server/Client model between the Runtime that run in the customer's machine, and the developer. The .NET framework runtime would have a secret encryption key that only MS would have, between the .NET compiler and the framework. This secret key would not be easily compromised thorugh cracking of compiler or CLR.

    That way when you compile and sign your code, the compiler would then encrypt the assembly and it will only be decrypted by the CLR and verified then executed if all checkes.


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.