Static linking (again)
Hi Zeroc,
I realise this has been asked before ... just wondering if there are any plans whatsoever to support static linkage in the future? Aside from cleaner patch deployment, there's little benefit for me in using dynamic linking, but for internet-deployed Windows clients there's considerable risk.
My two concerns are 1. DLL substitution - ie Ice source is freely available so an attacker could rebuild and deploy ice30.dll hijacking application calls with their own to subvert application logic (eg. activation) - and 2. call sniffing with tools like stracent to reveal unprivileged information (eg. cleartext logons/passwords). These are real issues for an uncontrolled client environment but a static standalone binary would only expose the communication protocol (excluding universal Windows remote code injection risks) ...
Thanks
I realise this has been asked before ... just wondering if there are any plans whatsoever to support static linkage in the future? Aside from cleaner patch deployment, there's little benefit for me in using dynamic linking, but for internet-deployed Windows clients there's considerable risk.
My two concerns are 1. DLL substitution - ie Ice source is freely available so an attacker could rebuild and deploy ice30.dll hijacking application calls with their own to subvert application logic (eg. activation) - and 2. call sniffing with tools like stracent to reveal unprivileged information (eg. cleartext logons/passwords). These are real issues for an uncontrolled client environment but a static standalone binary would only expose the communication protocol (excluding universal Windows remote code injection risks) ...
Thanks
0
Comments
At this time, we have no plan to add static linking to Ice. The addition of such features really depend on requests from commercial customers.
Also, Ice-E supports static linking (and Windows); maybe you can use Ice-E instead of Ice for your internet-deployed Windows clients.
Best regards,
Bernard
I did look at Ice-E briefly, however I think I'll just port Ice to a static lib if you guys have no strong objections. I ported IceUtil as a test run without any significant drama and jotted down the process below if anyone's interested. I realise ZeroC won't support this, but to be fair it seems like a trivial addition since most of the supporting preprocessor directives and module structures are in place for this.
My notes below on how I did this for IceUtil - I intend to continue for the rest of Ice but might wait for 3.1 to save forking too early. My changes were based on Windows, specifically VC.Net 2003 build environment...
Static clients link against iceutilsd.lib and define macro as follows :-
Sample application with very basic thread test :-
I hope that the other libraries are similar, but haven't delved into your plugin code (PluginManager or DynamicLibrary) and suspect these are fairly involved... For now I'd be happy with a basic commentary on whether the above approach is workable for IceUtil alone (knowing of course that you don't support static linkage officially).
Thanks