Am 15.01.24 um 13:00 schrieb Marc-André Lureau: >>>> >>> >>> The trouble is when qemu_clipboard_update() is called without data & >>> without a request callback set. We shouldn't allow that as we have no >>> means to get the clipboard data then. >>> >> >> In the above scenario, I'm pretty sure there is data when >> qemu_clipboard_update() is called. Just no request callback. If we'd >> reject this, won't that break clients that do not set the >> VNC_FEATURE_CLIPBOARD_EXT feature and only use non-extended >> VNC_MSG_CLIENT_CUT_TEXT messages? > > If "data" is already set, then qemu_clipboard_request() returns. > > Inverting the condition I suggested above: it's allowed to be the > clipboard owner if either "data" is set, or a request callback is set. >
Oh, sorry. Yes, it seems the problematic case is where data is not set. But isn't that legitimate when clearing the clipboard? Or is a VNC_MSG_CLIENT_CUT_TEXT message not valid when len is 0 and should be rejected? In my testing KRDC does send such a message when the clipboard is cleared: > #1 0x0000558f1e6a0dac in vnc_client_cut_text (vs=0x558f207754d0, len=0, > text=0x558f2046e008 "\003 \002\377\005") at ../ui/vnc-clipboard.c:313 > #2 0x0000558f1e68e067 in protocol_client_msg (vs=0x558f207754d0, > data=0x558f2046e000 "\006", len=8) at ../ui/vnc.c:2454 Your suggestion would disallow this for clients that do not set the VNC_FEATURE_CLIPBOARD_EXT feature (and only use non-extended VNC_MSG_CLIENT_CUT_TEXT messages). Best Regards, Fiona
