💥 zb: Drop support for DBUS_COOKIE_SHA1 auth mechanism
#1039
Conversation
* It drags the `sha1` crate as a dependency, which can be [problematic for some users]. * It makes the handshake more complex, not allowing to pipeline all the commands. * It's not widely used. If `EXTERNAL` is not an option, you might as well just use `ANONYMOUS`. Fixes dbus2#727. [problematic for some users]: dbus2#543
This was only needed for `DBUS_COOKIE_SHA1` auth mechansim, which was just dropped so we can happily drop this. Fixes dbus2#543.
Since we just dropped the support for it.
This is in preparation for zbus dropping it in 5.0: dbus2/zbus#1039 Besides, I added this support mainly for hopes of possibly using it for a remote transport. However, due to lack of time and funding, I decided to drop those plans from the roadmap.
|
@zeenix When is the next release which has SHA1 dependency removed? |
|
@zeenix this breaks the connection with GIO GDBusConnection / GDBusServer on win32. This makes connection with auto-spawned servers on windows with shm "DBusDaemonAddressInfo" address, using "nonce-tcp" difficult, as the EXTERNAL mechanism is not implemented there: https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdbusauthmechanismexternal.c?ref_type=heads#L234 Not being able to connect with GDBus servers is an annoying regressions. It breaks win32 support for qemu-display for example. |
All these points could have been brought up in the months between #727 (note the "RFC" prefix) and it being actually dropped. 😞 For Windows, we still support TCP and last I checked external works there? If anyone really needs windows support, they should work on making UDS with external auth working there. Windows support has been one of the hardest. I don't even have a Windows machine and have been relying on the CI to tell me each time I had to made changes in windows-specific parts of the code. So at the point, it'd be a lot more easier to convince me to drop Windows support completely then re-adding complexity to support an old auth mechanism that drags in problematic dependencies (see #543). |
|
It's easy to cross-build zbus with --target x86_64-pc-windows-gnu. There isn't much win32-specific code afaik, so he burden should be low, while the benefits are big for cross-platform projects. I use free-for-developpers VMs, the download has been officially down for a while, although you can still grab it from https://aka.ms/windev_VM_vmware, then convert it to qemu/libvirt with virt-v2v. (https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ ) The lack of COOKIE_SHA1 auth means that with zbus 5.0, qemu-display can no longer connect to qemu -display dbus. I will attempt to work around it in future qemu releases to allow ANONYMOUS on win32 with p2p. If I have time left, I will try to implement EXTERN for win32 glib. |
As the guy who did the (maintainance) work, I can assure you that is not the case. :) Sure, if you don't touch the code and the windows-specific deps don't change, there is nothing much to do. However, as soon as you try to do some refactor or introduce any new feature that touches that code, you've a problem. I explained the rationale for this change in the description here and in #727. I'm afraid the ship is sailed on this one. |
sha1crate as a dependency, which can be problematic for some users.EXTERNALis not an option, you might as well just useANONYMOUS.Fixes #543, #727.