[Opensim-dev] Needing Mono.Security.dll on Windows at PostgreSQL module

Wed Oct 16 04:21:54 UTC 2013

Hi,

On Tue, Oct 15, 2013 at 11:27 PM, Teravus Ovares <teravus at gmail.com> 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
> <fernando at oliveira.eti.br> 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
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev