Re:Introducing .NET Core
by MichaelGG on Thursday December 04, 2014 @10:29PM
(#8702902)
It's not much different from the situation with statically linking C, is it? This argument was the exact one MS used over a decade ago explaining why they couldn't ship a linker for .NET. (And 3rd parties, including MS employees, stepped up to fix it.)
On the flip side, there's been few (none?) exploits involving remote code execution, except for loading code from untrusted sources. The other large ones that come to mind were a few ASP.NET security bypass issues.
So it's not like, say, someone statically linking JPEG reading code that allows code injection. It could be, as nothing stops unsafe code being published, but it's far less of an issue with managed code than MS has made it out to be.
Re:Introducing .NET Core
by jameshart on Thursday December 04, 2014 @11:02PM
(#8702964)
It's also no different than the state with many bin-deployed libraries Microsoft has shipped for .NET in the past. But this is a radical change to the way .NET developers have to think about their dependencies on the .NET platform.
On the flip side, there's been few (none?) exploits involving remote code execution, except for loading code from untrusted sources. The other large ones that come to mind were a few ASP.NET security bypass issues.
So it's not like, say, someone statically linking JPEG reading code that allows code injection. It could be, as nothing stops unsafe code being published, but it's far less of an issue with managed code than MS has made it out to be.