Open DemiMarie opened 5 years ago
We're not planning to implement such library, but if you really like, we'd accept good quality patches for it. In the meantime, it's easy enough to handle qrexec calls using separate process and communicate with it using pipes. There surely is some performance impact from such approach, but there are much easier ways to optimize qrexec performance, starting with increasing data chunk size and optimizing qrexec policy handling. https://github.com/QubesOS/qubes-issues/issues/4686 is also something worth working on (and in fact would be very useful for decent Admin API performance).
For maximum utility, the library should be fully asynchronous.
I find it especially painful in C libraries. Every single one I've seen uses different API, frequently encouraging "callback hell".
I agree, and would also add “increase the size of the pipe buffers in the kernel” to the list (it is just a single system call).
@marmarek Is the qrexec protocol considered stable? That is, is implementing it oneself supported?
I hope so, we're building things on top of it. :)
Qrexec protocol have version negotiation as part of handshake. Recently made it really negotiation, not only "gracefully reject mismatching version". So, yes, the protocol is stable.
Qubes OS version:
Qubes release 4.0 (R4.0)
Affected component(s):
domU qrexec
Steps to reproduce the behavior:
Look for a C library that implements qrexec
Expected behavior:
Qubes has such a library, and the qrexec client tools wrap it.
Actual behavior:
No such library.
General notes:
This would be quite useful for those who want to call qrexec services from their applications.
For maximum utility, the library should be fully asynchronous.
Related issues: