[bug] Tauri 2.1.1 & 1.8.1 is affected by glib-rs 0.15 security vulnerability
Closed this issue · 6 comments
Describe the bug
The tauri 1.8.1 Rust package currently requires glib@0.15 on Linux, but versions of glib (the Rust bindings) >=0.15 and <0.20 are affected by GHSA-wrw7-89jp-8q8g . I believe (but am not sure) that the nightly version of Tauri 1 probably depends on glib@0.18, which is also bad.
GitHub informed me about this in https://github.com/ilyagr/diffedit3/security/dependabot/10.
Reproduction
No response
Expected behavior
It'd be great if there was a tauri 1.18.2 that could work with glib 0.20 :)
Full tauri info output
N/A
Stack trace
No response
Additional context
No response
Since the gtk3 bindings are unmaintained I think this is a wontfix sadly. (We don't use glib directly ourselves)
If the gtk3 bindings are never made compatible with glib 0.20, another option might be to downgrade to gtk 0.14.3. Unless, of course, another security bug appears that affects older versions of some gtk dependency...
Actually, Tauri 2.1.1 also seems affected. It seems to be using gtk v0.18.2 which seems to depend on glib v0.18. I'm surprised it's not showing up in the Security tab of this repo; I guess you didn't enable dependency-based security warning.
Cc: #7335
We do see them in the Security tab, but only those with repo access can see that (afaik github doesn't allow us to make this public?).
And I think there's no gh issue because this is still not resolved: rustsec/audit-check#8
I doubt anyone in the community would be interested in forking the gtk3 bindings so i'll close this in favor of #7335 (but only because this unsound issue doesn't seem to affect us)
Thanks for looking into this!
I didn't understand what you said about rustsec/audit-check#8 and how the check should be behaving, nor why this "wouldn't affect us", so I'd appreciate more details if you are feeling like explaining it. But you are the expert here, so I trust your conclusion that Tauri for Linux not on fire. Glad to hear it!
I didn't understand what you said about rustsec/audit-check#8 and how the check should be behaving
We have an audit workflow that opens public issues like this one #11641 but it's not working for unsound issues due to a bug in the linked github action.
nor why this "wouldn't affect us"
This was about the unsound issue itself. We've been using the affected glib versions for 3? years (since the day 0.15 was released basically) without any issues. This is good enough in my eyes to not have us spend resources that we really do not have on forking&maintaining the gtk3 crates.