Ok, the funny thing is that until I added mono.security into the referenced libraries, it showed me on link stage:
error CS0122: 'Mono.Security.Cryptography.CryptoConvert' is inaccessible due to its protection level error CS0117: 'Mono.Security.Cryptography.CryptoConvert' does not contain a definition for 'FromCapiPublicKeyBlob' error CS0122: 'Mono.Security.StrongName' is inaccessible due to its protection level error CS1729: 'Mono.Security.StrongName' does not contain a constructor that takes 1 arguments Thats the reason why I thought it was unavailable. Next, the assemblies are indeed not validated upon load (i've used Assembly.LoadFrom). So if anybody want to make sure dll are the original, the manual checks should be done. Igor On Wed, Jul 4, 2012 at 6:32 AM, Igor Russkih <iruss...@gmail.com> wrote: > > >> > Moreover, Mono.Security assembly is shipped stripped, in particular it >> misses StrongName class - so even manual validation is not possible. >> Odd; my Mono.Security.dll contains it. >> > > Hm, it seems I've checked the assembly from release folder - and it was > stripped in there. > In object browser I actually see it, thanks, I'll check this. > > >> I don't know why strong named assemblies aren't validated for you; we'd >> need a test case for this. >> > > I understand there is no strict requirement to do valiation upon load, but > may be that is the thing which could be configured in future? > > The test is simple: loadup a strong signed assembly which is manually > hijacked (modify in hex editor f.e.). I see it can successfully be loaded > with Assembly.LoadFrom >
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
