[Spice-devel] [PATCH 1/2] Ensure that plugins cannot bypass version check

[Christophe de Dinechin]

> On 24 Apr 2018, at 18:21, Christophe Fergeau <cfergeau at redhat.com> wrote:
> 
> On Tue, Apr 24, 2018 at 05:01:33PM +0200, Christophe de Dinechin wrote:
>> But we still have the capability to reject a plugin (in a well
>> defined, non-crashing way) for other reasons.
>> [...]
>> To summarize, the purpose of the compatibility check is to guarantee
>> well-defined behavior on the entry points we call. It is not to
>> guarantee that a plugin will work, it may still be ruled out for a
>> variety of other reasons.
> 
> Are you suggesting adding some special-casing to the version checks?

No. I’m only saying that our version check guarantees binary compatibility, not “behavioral” compatibility. In other words, if we add “hasCapability” in version 12, it is OK to mark as “binary compatible with 12” something that does:

	if (!hasCapability(“superBeefy”)) {
		doAnything();
	}

where I would find it perfectly acceptable for “doAnything()” to unload the plugin or remove it from consideration. The goal of the binary compatibility check is to guarantee that “hasCapability()” is available, not that it returns true.


Thanks
Christophe

> 
> if (version >= 15) and (!hasEntryPoint("capability")) {
>    /* plugin is too old, don't load */
> }
> if (version >= 13) and (hasEntryPoint("oldEntryPoint") {
>    /* plugin is too old, don't load */
> }
> 
> Maybe I missed something, but this seems fairly close to what you wanted
> to avoid in the commit log:
> 
> "For example, the major.minor version checking assumes that agent 1.21
> is compatible with plugins 1.21, 1.13 or 1.03. If later testing
> shows that 1.13 actually introduced an incompatility, you have to
> special-case 1.13 in the compatibiliy check.
> An approach that does not have this problem is to rely on incremented
> version numbers, with a "current" and "oldest compatible" version
> number."
> 
> Christophe