Hi, On Tue, Oct 15, 2013 at 11:27 PM, Teravus Ovares <[email protected]> wrote: > While I don't have an issue with this after thinking about it. It > seemed to me that making this call of distributing the mono dll would > require more then just my opinion ;). My understanding is it's > LGPL, which is fine and the license isn't the issue. It's more about > a couple of other questions that I have.. > > What can we expect when dealing with upgrading mono as a result of > this?
If we don't depend on any other Mono DLLs, and this one DLL is only supposed to be there on Windows running the .NET Framework, then it shouldn't matter what version of Mono the DLL is from, as long as it has the functionality expected by Npsql. Although, considering it's *security* in particular, keeping it up-to-date is probably a very good idea. > (we've typically had mysterious issues when dealing with > Mono.Addins, does Mono.Security have that potential also?) > Since Mono.Security includes cryptographic functions, what sort of > export rules do we have to adhere to? Export rules on strong crypto -- at least the type that's used in SSL -- are largely a thing of the past, especially in the US and other countries that have similar information policy to the US (Australia, UK, Canada, to name a few). Worth a look to see if anything in Mono.Security seems like it falls outside that domain, but I suspect that all of it is publicly documented open standard crypto algs like RSA, DSA, MD5, SHA, HMAC, ECDSA, RC4, etc. > What sort of platform issues might arise from including this? > (Fernando looks like he did a good job of separating it from Mono on > *nix installations so maybe none... and, some other devs probably > know better then I do on the full range of effects ) Rigging up the paths and/or launcher scripts to ignore the directory with the Mono.Security.dll on non-Windows will be sufficient. Or we could dynamically load the DLL in code in Main after detecting the platform at runtime, thus eliminating the problem with launcher scripts, paths, environment, etc. An Assembly.Load() prior to calling any DB functions should do it. > > I could be completely over-thinking this, and as it stands now, the > Postgres database connector doesn't work in Windows without it.. so > please comment, I'd like input :). I don't like the idea of shipping compiled binaries in the OpenSim git source tree. Compiled binaries have many more potential problems, from patents, to linkage, to bloating the repo size, to licensing, to an increased risk of trojans due to reduced visibility into the functionality -- issues that, while they don't disappear, are much less likely to occur when doing a pure source build of OpenSim and all dependencies (i.e., discarding all the binaries in the repo and building them from scratch). Unfortunately, there is a strong precedent for having binaries in OpenSim git master in the bin/ directory, including natives (for OpenJPEG, ODE, Bullet, and SQLite). This makes OpenSim easier to "build" from source on supported platforms, at the cost of making it more brittle, and harder to get going if you're running a different platform. A cmake-based build system using the detected platform's preferred compiler and automatically pulling in external deps' sources, would be a more robust approach. But I digress -- that's neither here nor there, and doing such a thing would be a huge effort and require a complete rewrite of the build system -- so the way that OpenSimulator is now, adding one more DLL probably won't be fatal. It's important to keep it updated, but that's about it. To provide robust support for keeping the security DLL patched, commercial distros of OpenSim using PGSQL would have to monitor the appropriate CVE alerts or Mono mailing lists to be made aware of any security updates, and deploy them as quickly as possible to customers and/or commit an updated built DLL to OpenSim. All this is just to say, I don't think there are any particular barriers that I can see (but I'm not a core developer) to shipping Mono.Security.dll and conditionally loading it if running Windows, based on current practices. However, the commit of Mono.Security.dll would need to be attached to a patch that conditionally loads Mono.Security.dll very early in startup, before any attempt to use any functionality from Npsql. The safest place to do this is in Main, but that's probably pretty cluttery as it is... maybe it would be OK in the PGSQL module's startup before creating any Npsql objects, though. Specifically, the patch should somewhere add an event handler to AppDomain.CurrentDomain.AssemblyResolve: http://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve.aspx What will happen is this: The AppDomain will attempt to resolve Mono.Security.dll in the default paths; fail to do so because the "windows" directory isn't in the default resolver paths; then call the delegate attempting to resolve it. In the delegate, you perform your OS check using e.g. System.Environment.OSVersion: http://msdn.microsoft.com/en-us/library/system.environment.osversion.aspx If the OS check indicates you're running Windows, you then go ahead and open a FileStream to the relative path "windows/Mono.Security.dll" (relative to the entry assembly), and call Assembly.Load on the stream. Then you're done. Hope that pseudocode helps. -Sean > > Best Regards > > Teravus > > On Tue, Oct 15, 2013 at 10:08 PM, Fernando Francisco de Oliveira > <[email protected]> wrote: >> Hello >> >> I was investigating the bug >> (http://opensimulator.org/mantis/view.php?id=6803) found that >> Mono.Security.dll which is packaged with Npgsql.dll library is needed on >> Windows, but can't be distributed on Linux, because mono already have it and >> gives conflicts error. >> >> I would like to discuss about distributing the Mono.Security.dll on a folder >> above bin like "bin/windows" folder, which could contains the libraries that >> only is needed on windows. >> >> I did a change on PGSQL project to load dynamicaly Mono.Security only if >> it's running on Windows, and from that folder. >> If it running on Mono, it load it from GAC (if available) and don't load the >> windows dll. >> >> http://pastebin.com/WdzfmbSr >> >> Let's talk about it ? >> >> Fernando Oliveira >> http://oliveira.eti.br >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
