Process separation was already in place. The PKCS#11 library is loaded by a long lived helper process, not ssh-agent itself.
> (Note to the curious readers: for security reasons, and as explained in
> the "Background" section below, ssh-agent does not actually load such a
> shared library in its own address space (where private keys are stored),
> but in a separate, dedicated process, ssh-pkcs11-helper.)
That didn’t help because the long lived nature of the helper process exposed it to the shared lib side effects such that they could be chained into a gadget. If I understand correctly, the long life is important for interacting with many smart cards and HSMs because of their APIs.
If you are suggesting that there should be an IPC API for this process and vendors ship a full program that speaks it, that seems reasonable at a glance, but not really something the OpenSSH project can dictate.
Indeed, my suggestion is zero dynamic libraries in security critical code/applications.
If security is a goal, loading in-process foreign code is already a lost battle.
Plugins as dynamic libraries made sense when we were fighting for each MB, not when people have hardware where they go to the extreme of running containers for every application they can think of.
If you are suggesting that there should be an IPC API for this process and vendors ship a full program that speaks it, that seems reasonable at a glance, but not really something the OpenSSH project can dictate.