Allow plugin nuget dependencies

[Seb-stian]

Allow Obsidian plugins to have nuget dependencies. They should be correctly:

• detected
• checked for duplicity
• downloaded
• loaded

There might be a problem with versioning?

Related StackOverflow post
MSDN

[Craftplacer]

Is it required though? I mean, we could load foreign assemblies (DLLs) too that the user installs part of a plugin. They should only be loaded if the assembly is being depended upon by another plugin.

I can only imagine being useful if the user loads a "source code" plugin.

[Seb-stian]

"Source code" plugins are the main target of this issue.

[Naamloos]

In all honesty, don't source code plugins have like- a security concern?

[Seb-stian]

Don't all of them?

[Craftplacer]

More like the opposite, because you can be sure you're not running hidden code, cause you compile the plugin yourself.

[Naamloos]

Fair, but an update on a github repo would mean the new version would get compiled. A new update can introduce malicious code. Unless they don't auto update, of course.

[Seb-stian]

Well, at the moment, the way we deal with malicious code is that we disallow referencing certain assemblies. I don't know if it's possible to, for example, remove local files without System.IO, System.Reflection or System.Runtime.InteropServices (or other assembly that references those). We can still provide all the functionality via services, but without security risks, that's the idea. However, I don't call myself a security expert, so my thinking may be flawed.

In the past I've worked on other projects involving uMod, which is doing something similar. I think that they used Regex on the source code, to detect if any blacklisted namespaces were present, but the implementation is not as important here.

[Seb-stian]

@Naamloos Maybe you could add "Server development" category to GitHub discussions and open "Plugins security concerns"? Or just open another issue specifically for it.

[roxxel]

can i get assigned to this issue?