<div dir="ltr"><div dir="ltr">Hi there<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 18, 2022 at 2:23 AM Thiago Macieira <<a href="mailto:thiago@kde.org">thiago@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, 12 April 2022 04:15:56 PDT Marc-André Lureau wrote:<br>
> Any other idea? (of course, the protocol change would need to be negotiated<br>
> first!)<br>
<br>
Negotiating FD passing is already done on Unix in the preamble section of <br>
authentication done before D-Bus messages start being exchanged. So having to <br>
negotiate it on Windows would not be a new thing. Passing a slightly different <br>
structure would, but so long as it's done behind a negotiation it should be <br>
fine.<br>
<br>
</blockquote><div><br></div><div>I have made some progress on this front, but could use some help or feedback. <br></div><div><br></div><div>Similar to fd-pass, it's using a negotiation to determine whether the peers have support and capabilities, and a new field to indicate the presence and size of a "handle array" that is attached to a message. The array elements have the handle type & value or details for SOCKET. The body 'H' arguments index the array, similar to 'h' FDs values. The sender has to DuplicateHandle/WSADuplicateSocket when sending the message and build that "a{yv} handle array" (for each receiver). The receiver then imports back the handles and substitute handle values.<br></div><div><br></div><div>With glib & zbus, I can simply append the array after the message, and parse it back. The array size in bytes is easy to retrieve. It seems to work fine.</div><div><br></div><div>But with dbus reference implementation, it's a bit more complicated and makes me wonder about this design.</div><div><br></div><div>It seems the D-Bus protocol was designed so that the message size can be computed from the header alone, with header + body + fields array size. The reference implementation relies on that (_dbus_header_have_message_untrusted for ex). The choice I made so far imply that the message size depends on those + reading the WIN32_HANDLES field & if set, read *after* the body the "handle array" size. This is a bit tricky to handle in dbus reference implementation today, but if this is the right option, I can probably make it work. But maybe I am missing something in the original design, about message processing, locality etc<br></div><div><br></div><div>1) Would it be a better design to add a 3rd UINT32 to the message header, to indicate the size of the handle array?<br></div><div><br></div><div>2) Or change the header body length to be message body + "handle array" sizes. This would make importing handles a bit tricky, as you would need to first parse the body to be able to know the offset of the handle array. </div><div><br></div><div>3) Add a new message type, with the "handle array" associated with the next message.</div><div><br></div><div>That 3rd option is appealing, even if it has some overhead and extra complications too.<br></div><div><br></div><div>For now, I will try to continue with the original design, see if I can teach it to the dbus reference implementation. But I welcome any suggestion, ideas etc</div><div><br></div><div>thanks!<br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">Marc-André Lureau<br></div></div>