Hi, > The problem with (b) is, that iirc the way b was implemented in the past > was still the big blob approach, but then pass the blob through the client, > which means an evil client could modify it, causing all sorts of > "interesting" > behavior inside spice-server. Since we're re-implementing this to me the > send a blob through the client approach is simply not acceptable from a > security pov, also see my previous mail in this thread.
Agree. It should be a normal spice message which goes through the spice marshaller for parsing & sanity checking. > I disagree. Note that there is more info to send over then just which > surfaces / images are cached by the client. There also is things like > partial complete agent channel messages, including how much bytes must > be read > to complete the command, etc. Is there a complete list of the session state we need to save? > IMHO (b) would only be acceptable if the data send through the client stops > becoming a blob. Using (a) to send a blob isn't better. > Instead the client could simply send a list of all > surface ids, > etc. which it has cached after it connects to / starts using the new > host. Note > that the old hosts needs to send nothing for this, this is info the > client already > has, also removing the need for synchronization. Yes, some session state is known to the client anyway so we don't need a source <-> target channel for them. > As for certain other > data, such > as (but not limited to) partially parsed agent messages, these should be > send through the regular vmstate methods IMHO. That isn't easy to handle via vmstate, at least as soon as this goes beyond a fixed number of fields aka 'migrate over this struct for me'. Think multiple spice clients connected at the same time. > 1) Do (a), sending everything that way > 2) Do (a) sending non client state that way; and > let the client send state like which surfaces it has cached > when the new session starts. I think we have to look at each piece of state information needed by the target and look how to handle this best. cheers, Gerd
