https://bugs.kde.org/show_bug.cgi?id=520509
Daniil B <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |NEEDSINFO Resolution|--- |FIXED --- Comment #2 from Daniil B <[email protected]> --- (In reply to michaelk83 from comment #1) > While this may be a bug in ksecretd implementation, I think this is also a > bug in go-keyring, since binary data should not be marked as "text/plain". > Moreover, if it's specifically marked as "text/plain; charset=utf8", then it > shouldn't contain non UTF8 characters, and ksecretd can't really be faulted > for treating it as valid UTF8. Hey! So this is my first issue here and I’ve switched to Linux not so long ago so I’m sorry if anything’s wrong. I understand this is probably not the issue of `kwallet`. I personally had a problem with `acli` (https://developer.atlassian.com/cloud/acli/guides/install-linux/) But it seems (I'm not sure) to be working correctly with `gnome-keying` At least I was recommend to switch by Atlassian support: > Switch Secret Service Providers > Replacing `ksecretd` with a provider that handles binary data correctly will > resolve the corruption: But I'm pretty sure it's AI-generated response. I'm not sure I've checked issues in `go-keyring`. Also, `acli` is closed-source, so I can't check what's going on there. Should I check if `gnome-keying` handles this case correctly and create a bug in `go-keyring` if I can? -- You are receiving this mail because: You are watching all bug changes.
