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

[Christophe de Dinechin]

> On 18 Apr 2018, at 17:04, Christophe Fergeau <cfergeau at redhat.com> wrote:
> 
> On Tue, Apr 17, 2018 at 06:39:05PM +0200, Christophe de Dinechin wrote:
>> When does this kind of scenario happen? Imagine we added support for
>> loading/unloading plugins. Version 13 adds a new interface to unload
>> plugins, and a new “unloadable plugin” entry point. Therefore,
>> starting with version 13, the agent would try the new entry point
>> first, and if it’s there, assume it can unload the plugin, otherwise
>> fallback to the old method and mark the plugin as not-unloadable.
>> Therefore, the change in version 13 would still be binary compatible
>> with version 3. Years later, in version 21, we decide to drop support
>> for non-unloadable plugins. So now the agent refuses to load a plugin
>> if it does not have the new entry point. In that case, we’d want to
>> bump the “compatible version” to 13, since all plugins after 13 have
>> that new entry point. The key win here is that we’d not have to force
>> the last compatible version to be 21. 
>> 
>> This could mean years of differences in terms of binary compatibility.
>> We could deprecate things slowly and offer graceful transitions.
> 
> This would work if all that is needed to use the new interface is a
> recompile, and not active porting, or if we make sure plugins using the
> old interface can no longer be built when version 13 comes around.
> If we are instead considering a method used in version 10 which is
> called 'my_method'. version 13 deprecates 'my_method', and replaces it
> with 'my_new_method', but API/ABI compatibility is kept with version 10,
> so I can rebuild my plugin calling 'my_method' against version 13. I
> assume the plugin ABI version would become 13 after being recompiled?
> Then in version 21 I decide to remove 'my_method' because it's been long
> obsolete, but my plugin recompiled against version 13 will no longer
> work.
> Am I missing something, or misusing this?

You are not misusing it, but you are describing a different scenario than I am describing, where the last compatible version would not be 13 because there would be no guarantee of compatibility with version 13. So in your scenario, we probably would have to bump the last compatible version to 21.

There is no easy way to test if a method is there. There is, however, an easy way to test if a C entry point is there in a shared library. This is the difference between your scenario and mine. In mine, I can explicitly test if the new C entry point is there, and since it has been added, I know the plugin is aware of the new semantics. So I can then decide to remove the old entry point later, and then I know that a version 13 plugin that has the new entry point follows that new semantics (in the example I gave, that it knows how to unload).

(Also, you may have been thinking about backporting, and I’m not sure I understood that aspect of your comment fully. This obviously adds more complications)


Thanks,
Christophe

> 
> Christophe