I want to raise something from the user side of the house, since I think this forum is the right place for it.
I’ve been following the discussion about moving modules out of core and the thinking that external modules should be installed via the command line rather than through a UI, for security reasons. I want to say first that the security concern makes complete sense to me. Running third-party code inside a live EMR full of patient data is not something to be casual about, and I don’t think anyone wants a one-click path to installing untrusted code.
My worry is just about who ends up on the wrong side of a CLI-only approach. A lot of us running OpenEMR are small practices without dedicated IT. For that group, “install it from the command line” can be the difference between using a module and not being able to touch it at all. I’d hate to see us end up in a place where core modules are available to everyone but everything else is effectively developers-only.
Where I’m hoping the conversation can go: I think the real security concern is trusting the code, not the UI itself — and there might be ways to keep that trust gate without closing the door on non-technical users.
The approach that seems most promising to me is a curated, signed module list — where the UI will only install modules that have been vetted and signed. What I like about it is that it answers the security concern at the root: the install path simply can’t run arbitrary untrusted code, so even a compromised admin account can’t use it to pull in something malicious. The trust comes from the vetting and the signature, not from asking a non-technical user to make a judgment call. It’s roughly the “reviewed app store” model, and it’s been floated for OpenEMR before in one form or another.
I’ll be upfront that this is more work than just requiring the command line — it needs signing infrastructure, a vetting process, and someone to own the ongoing review. But that’s infrastructure the project would arguably benefit from having regardless of how this particular decision goes, since a way to vouch for module integrity is valuable on its own. So I’d gently push back on treating “more effort” as a reason to default to CLI-only — it’s a reason to scope the work, not necessarily to skip it.
There are other middle paths too — letting a server admin approve trusted sources once, or shipping the UI but off by default behind an admin flag — but to me the signed list is the cleanest, because it doesn’t lean on someone making the right trust decision at install time.
I’m not wedded to the implementation details, and the admins know the codebase and the threat model far better than I do. Mostly I want to make sure that whatever we land on, we don’t leave smaller practices unable to install modules at all.
I am curious as to whether others running smaller setups feel the same, and whether any of these middle paths seem workable to the people doing the work.
David Eschelbacher MD