Making SHA1 crate dependency optional

[hkr1990]

Hi Devs,

I'm working on a Dbus related project in my company, and I would like to use Zbus crate. The only issue is that it depends on a crate "SHA1" which is now flagged as "cryptographically broken" by most Rust Component governance tools in major companies.

I see that SHA1 crate is used for DBUS_SHA1_COOKIE mechanism. I did some reading on the DBUS_SHA1_COOKIE mechanism and looks like it is only needed on legacy unix and windows systems. So, would it be possible to make the DBUS_SHA1_COOKIE feature as optional feature that gets only enabled via config switch. This will make zbus crate not being flagged by compliance tools and improve its adoption.

Thanks,
Hemendra

[zeenix]

I did some reading on the DBUS_SHA1_COOKIE mechanism and looks like it is only needed on legacy unix and windows systems.

That's sort of correct but for Windows, this is typically the only way to establish auth since only the latest Windows support unix credentials on unix sockets (even the unix sockets are relatively new on Windows) and current bus implementations haven't caught up yet AFAIK.

Having said that, I would have no objection in putting this behind a cargo feature flag. This is actually the best time for this change as we're in an API break. PR welcome!

[hkr1990]

Sure. I will send a PR. When is the next release schedule for the zbus crate?

[zeenix]

Only 2 issues remain. I'm hoping I can get it done before next week.