Make SHA1 crate dependency feature gated

[hkr1990]

Zbus crate depends on a crate "SHA1" which is now flagged as "cryptographically broken" by most Rust Component governance tools in major software 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, it should be possible to make the DBUS_SHA1_COOKIE feature as optional feature (gated by a feature flag). This will make zbus crate not being flagged by compliance tools and improve its adoption in production.

Thanks,
Hemendra

[zeenix]

@hkr1990 zbus 4 already released so you missed the train on this one, I'm afraid. :( We'll have to wait till the next API break.

[hkr1990]

Sorry about that! When is the next API break expected? Also, I was planning to add the new gating feature as no-sha1, so by default (when no-sha1 feature isn't specified), zbus behavior will stay compatible to zbus 4. The SHA1_COOKIE mechanism will only get disabled when client explicitly specifies no-sha1 in their cargo.toml.

Will you still consider this behavior as API break?

[zeenix]

When is the next API break expected?

When enough issues require API break are accumulated. :) I honestly hope it won't be anytime soon though. Every break is a burden on the users.

Also, I was planning to add the new gating feature as no-sha1, so by default (when no-sha1 feature isn't specified), zbus behavior will stay compatible to zbus 4. The SHA1_COOKIE mechanism will only get disabled when client explicitly specifies no-sha1 in their cargo.toml.

I thought of that but it will still break existing code that disables default features and rely on cookie auth (on Windows, it's currently the only authenticated mechanism you can use with tokio). This would especially apply to tokio users (I think most of our users) as they disable default features to avoid depending on a bunch of smol-rs crates.

Will you still consider this behavior as API break?

Unfortunately, yes.

[zeenix]

Giving me thought to this, I don't think most people use cookies so even though it might break things for some people, I think it won't for most people and even for people for whom this will break, it's super easy to fix with a oneline change. So please do contribute the PR.

[hkr1990]

Sure. I will start working on it.

…

On Tue, Mar 19, 2024, 4:53 AM Zeeshan Ali Khan ***@***.***> wrote: Giving me thought to this, I don't think most people use cookies so even though it might break things for some people, I think it won't for most people and even for people for whom this will break, it's super easy to fix with a oneline change. So please do contribute the PR. — Reply to this email directly, view it on GitHub <#543 (comment)> or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMCRGX6W7SHUJU3H5TGVGDYZARLLBFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVI2TIOJQGM4TQNJSHCSG4YLNMWUWQYLTL5WGCYTFNSWHG5LCNJSWG5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KM5DPOBUWG44TQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJWGM4TGMBUGA2TNAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDEMBXG42TIMBZGE2IFJDUPFYGLJLMMFRGK3FFOZQWY5LFVI2TIOJQGM4TQNJSHCTXI4TJM5TWK4VGMNZGKYLUMU> . You are receiving this email because you authored the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .