After looking at references such as [1], I believe that the best course of action is to add <loadFromRemoteSources
enabled="true"/> to all config files.
This is because the intention of the existing loads within OpenSimulator are not to sandbox the code. If the user
downloads a separate DLL add-on, then they have already made the decision to trust it. Making them uncheck an extra box
won't achieve much and will generate a lot of painful support issues which we are not in a position to handle.
Code Access Security appears never to have been completely implemented in Mono (and so presumably not enabled) so this
does not apply there.
[1]
http://blogs.msdn.com/b/shawnfa/archive/2009/05/22/sandboxing-in-net-4-0.aspx
[2] http://tirania.org/blog/archive/2007/Aug-08.html
On 19/11/13 05:27, Zadark Portal wrote:
Included the following with Mantis 6853
Information relating to exception:
An attempt was made to load an assembly from a network location which
would have caused the assembly to be sandboxed in previous versions of
the .NET Framework.
Attachment Manager included in Microsoft Windows attaches security policies
to files downloaded from a network location. Normally this effects only files
contained in compressed zip format (.zip) though other file types can be
affected depending on the local computer group
security policies (thinking machines registered to a domain though not
exclusively)
The effect of the policy can be observed by opening the properties dialogue for
a downloaded file, under the 'General'
tab (default) and towards the lower section of the dialogue an additional
button is displayed 'Unblock'. Click this
button and exit the dialogue using the 'ok' button.
This procedure effectively changes all the files within the zip. If however the
unzipped contents are used prior to the procedure, the each file will require
'Unblock' to be selected.
Changing this policy would be a significant security reduction, so best policy
is, any file downloaded be inspected
using the procedure above.
Issue coming to light now is due to CAS policy changes within .NET 4
It would be useful if people evaluating this procedure reported their findings.
On 18 November 2013 16:15, Ai Austin <[email protected]
<mailto:[email protected]>> wrote:
From: Zadark Portal <[email protected] <mailto:[email protected]>>
Further to my previous email, and to ensure the existing solution is
clean
can you from within the opensim solution directory (same as compile.bat)
run:
C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln
/t:clean
C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln
/t:rebuild
C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln
Amend the Microsoft.NET path accordingly.
Okay, got it. Zadark. Understood now.
On my Win 8.1 84 bit setup I did that to a fresh download of r/24051
without adding the extra line to the
<resources> section of the Robust.exe.config file.
Then just amended the password for the database connection string in to
make a Robust.ini file, and startup up
Robust.exe with that.
I get exactly the same error about the addin scan ... so for some reason
the remote assembly load extra line in
Robust.exe.config (and openSim.exe.config) seem to be required in all my
environments (Vista 34 bit, Win7 32 bit,
Win7 64 bit and Win8.1 64 bit)
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
