Minimize transitive dependencies (including dev dependencies)

[DemiMarie]

Minimizing dependencies is highly desirable, as it reduces the trusted computing base and the risk of supply chain attacks. This is especially important for Qubes OS, as security is Qubes OS’s entire reason for existence, but is also more and more and more important for other systems too.

Smithay appears to have dependencies that are not required. Specifically:

• The XML parsing code can be replaced by raw FFI bindings to libxml2, which is already available almost everywhere, including Qubes OS. xml-rs is only used to parse Wayland protocol definitions, which are trusted, so there is no security risk here.
• winapi is not necessary unless Smithay intends to support Windows. Additionally, it can (and should) be replaced by the windows crate, which is a Microsoft product, and even then, it should not be built unless targeting Windows.
• wasi and redox_syscall should not be required by default.

[elinorbgr]

Regarding winapi and redox_syscall, as far as I can tell they are platform-specific dependencies (likely from winit) which are not used by Smithay: a cargo build from a clean state does not compile them. So if you encountered them, I guess this is cargo erroneously downloading unneeded dependencies?

xml-rs is used both in wayland-scanner and as a transitive dependency of gl_generator. I am not thrilled at the idea of introducing ffi bindings in wayland-scanner, even though as you pointed this is not a very sensitive context, however we do not have control over gl_generator, so this does not seem very actionable.

[DemiMarie]

Qubes OS does not need gl_generator at all, BTW.

[PolyMeilex]

293 would solved winapi and wasi problems, but as far as I know those are behind cfg or platform flags already so it's weird that cargo downloads them at all.

[PolyMeilex]

Qubes OS does not need gl_generator at all, BTW.

It is behind renderer_gl flag already, you can drop it easily (as far as I remember)

So you would be left with scanner xml dependency only.

[i509VCB]

Assuming #293 with my current implementation for the x11 backend here https://github.com/i509VCB/smithay/tree/x-client, that does not seem to introduce too many things - x11rb, gethostname (transitively libc) and nix when using RustConnection. I doubt I will need to use libxcb in the case of smithay's x11 backend, but I still don't know yet.

Looking at x11rb the windows side uses winapi there, so you would have to talk to psychon there.

[elinorbgr]

Qubes OS does not need gl_generator at all, BTW.

I understand that, but I'm not thrilled at the idea of adding and maintaining FFI bindings to libxml2 in wayland-scanner: it would force me to add a significant amount of unsafe code in wayland-scanner and basically rewrite the whole parsing code of the crate, and it introduces a compile-time dependency that cannot be handled by cargo.

[psychon]

Looking at x11rb the windows side uses winapi there, so you would have to talk to psychon there.

Yeah, it uses winapi just for a single function: WSAPoll. Which is Microsoft's version of poll and is needed to wait for "is the socket readable" and "is the socket writeable" at the same time. I even published a tiny crate, winapi_wsapoll, that provides safe bindings for WSAPoll just so that I can pretend "look ma, no unsafe code in the crate" (unless you enable the allow-unsafe-code feature which smithay shouldn't do if it does not use XCBConnection). ;-)

Also: Just don't build on Windows. Most likely "anything wayland" does not work there anyway plus I doubt anyone uses X11 on Windows anyway.

[DemiMarie]

Looking at x11rb the windows side uses winapi there, so you would have to talk to psychon there.

Yeah, it uses winapi just for a single function: WSAPoll. Which is Microsoft's version of poll and is needed to wait for "is the socket readable" and "is the socket writeable" at the same time. I even published a tiny crate, winapi_wsapoll, that provides safe bindings for WSAPoll just so that I can pretend "look ma, no unsafe code in the crate" (unless you enable the allow-unsafe-code feature which smithay shouldn't do if it does not use XCBConnection). ;-)

Also: Just don't build on Windows. Most likely "anything wayland" does not work there anyway plus I doubt anyone uses X11 on Windows anyway.

Oh that is not an issue at all, but given that you only need one function, winapi is complete overkill compared to copy-and-paste of the function declaration 🙂.