DYN-3320: Add basic standard library support #11383
Conversation
| var error = PathHelper.CreateFolderIfNotExist(DefaultPackagesDirectory); | ||
|
|
||
| if (error != null) | ||
| Log(error); | ||
|
|
||
| packagesDirectoriesToVerifyCertificates.Add(StandardLibraryDirectory); |
There was a problem hiding this comment.
so I'm curious about this decision?
There was a problem hiding this comment.
@mjkkirschner do you mean packages that we own do not really need to be signed?
There was a problem hiding this comment.
I'm not sure, I want to discuss it, if other teams will use this loading mechanism then it's an additional cost for them, also they may load custom nodes from this location - I'm not sure if our currrent cert checks actually check all files or only .dlls - I'm also not sure if our build steps sign all files or only .dlls
Definitely we should consider the security of this loading location given that this package loading location is local to dynamo and so could be anywhere - not in a protected folder like %appData% or %programData% that requires user or admin permissions.
In addition, if we want to "protect" this loading location perhaps there are better ways - or additional mechanisms.
There was a problem hiding this comment.
another thought - we may not want anything but ADSK packages to be loaded from here - if that was the case how would we enforce it?
There was a problem hiding this comment.
These points bring another question to my mind - will we be telling integrators that they could save their product-specific packages to this loading location if they want those packages to be loaded at startup or will we give them an option to add custom package paths in addition to this one?
There was a problem hiding this comment.
I imagined we would reuse this location - but I guess ultimately that depends what type of restrictions we want to put on this location, and if those same restrictions are acceptable/sensible for both use cases. Off the top of my head it seems to make sense to use the same set of rules because they'll have the same security concerns and many overlapping requirements - and if we can simplify, why not.
There was a problem hiding this comment.
Well, these are binaries that we ship and they should always be signed. That was my thinking. And dynamo binaries will always live in a protected location when an integrator use it because they will install Dynamo in some way or another. So they need to sign any binaries they add to this location regardless.
This needs more discussions.
Purpose
Packages should be loadable/shippable with core runtime zip and daily builds.
This pull request does:
Standard Library\Packagesfolder that lives in the same folder as theDynamoPackages.dllPackageLoaderconstructor.Declarations
Check these if you believe they are true
*.resxfilesReviewers
(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)
(FILL ME IN, optional) Any additional notes to reviewers or testers.
FYIs
(FILL ME IN, Optional) Names of anyone else you wish to be notified of