The importance of code signing plugins

ecently at the Full Access conference, there was a discussion about AI and plugins. For the last 40 years the art of making a plugin was pretty difficult. You had to be a decent C++ developer, have some interest in FileMaker and work yourself through the plugin SDK.

Today you can ask your favorite AI agent to read in the SDK and produce you a plugin. This may enable a lot of people to make their own custom plugin. And since AI helps, they may vibe code it and we may see a flood of new plugins.

With a lot of plugins, we need to think about where you get it, how they are distributed and how to make sure you got the plugin. Especially how to avoid someone to provide you an imposter plugin that steals your credentials.

The solution is probably to check the code signatures. On macOS the dmg is code signed as well as the application. For Windows the application is also signed, but Linux is still kind of a problem. We started years ago to publish the SHA256 hashes for our files, maybe Claris could do the same for theirs? At least you need to make sure you download the files via your ESD website directly from Claris web server and our plugin from our website.

A few improvements were suggested at the conference related to plugins and we'll see if Claris can implement a few:

For the server admin console:

1. Show the path of the three plugin folders.

2. Show which plugins are installed.
   This is currently only there for Script Engine, but could be added for Web Direct and Data API.

For FileMaker in general the Get(InstalledFMPluginsAsJSON) function should list the plugin folder for the current engine. Also it could list the code signing identity for the certificate used and who issued it for each plugin. In my case this would be Christian Schmitz Software GmbH.

In FileMaker Pro the plugin section in the preferences dialog could also display the signing identity, so you could see who signed the plugin.

There could also be an option for both Server and Pro to only allow signed plugins at all. The key here is to prevent AI made imposter plugins.

An even more strict thing could be the option for assistive installation to disable unsigned plugins. And the possibility to have FileMaker only install a new plugin if it is code signed and if the plugin is updated, the old and new signing identity matches. You know, to catch someone modifying a plugin and resigning it with their own signature.

Anyway, we'll see what Claris does with future updates to strengthen the security level on code signatures. For our plugin we recently added Files.CheckSignature and Files.SignatureInfofunctions.