Ok, here is the deal. I’m cloud, so we have some differences in the way we can program things that are different from on-prem users.
One of those differences is, we cannot add assemblies to the external assemblies folder and reference those in Epicor.
Prior to the move to the AKS environment, this was understandable, as this was a bit of a security issue, as there were semi-shared environments on one VM.
That is no longer the case, so the security issue is moot, for the most part. In the sense that now the issue only lies within that container.
Anyway, I started bending some ears at Insights.
I did not meet the resistance I was expecting. They wanted me to obviously make an Epicor Idea for it, so they could judge interest, and also they asked a few questions.
One of the questions was: If I could come up with ten or so libraries, that would be useful, so they could evaluate if this was a road they might go down, or at least may could be some type of compromise.
The second was how I wanted it to work.
My answer was of course, I want full access to add assemblies, as if I was on prem.
However, the second part of my answer was framed as even if we can’t get full access, at least have Epicor create a process for approval of external assemblies, so at least there was a path forward.
So what I’m asking you is:
What do you think of this idea in general?
If you had to come up with a list of libraries that would be useful, what would they be?
This one scares me. How many resources would they dedicate to it? How many of the current customer base would need something like this?
It is not a determining factor for me to switch to Cloud from On-Prem, but I wonder if they could entice enough other customers with this to make it worthwhile for them…
Because me, in general the more libraries we add, the greater risk of supply-chain attacks. Any library used in the crypto world is automatically suspect. Libraries that can open connections to Internet would make great exfiltration tools for example. So, I would be in the camp of having Epicor approve them instead of user installed.
I can certainly see people wanting logging/observability libraries; graphics libraries to reduce image sizes; QR Code generators; etc.
But like any library, taking on a dependency means staying up to date as the library is updated for security, features, or compatibility with underlying dependencies like the .NET version, operating system, etc.
All valid points, however I am in the camp of give me a fair and accurate warning, and then let me make my own decisions. It just puts us on the same footing as on-prem users.
On that point “fair and accurate warning”, I mean it. Guidance for best practices, caveats, risks, etc. Need to have enough info for informed decisions, and I would probably have it security manager only, so the company could make the decision, not some random dev who says, “hey I need this”, without weighing the consequences.
There’s very little I’ve added to the external assemblies. The main one was System.Net.Http so I could use HttpClient instead of the deprecated WebClient. This was back they hadn’t adopted .NET core yet, so this should not be needed anymore (I haven’t checked).
Maybe I’d ask for Microsoft.Identity.Client and Microsoft.Identity.Client.Extensions.Msal. I use those to authenticate to Microsoft Graph for a few of my functions. However if I was to do it again, I may look at something like Automation Studio to achieve the same result.
