allow the backend to use other charsets instead of utf-8
mowgli opened this issue · 4 comments
General information
- Operating system + version: Linux (Gentoo)
- Browser + version: Vivaldi
- Information about the host app:
- How did you install it? Via emerge
- If installed an official release, put a version: 2.0.22
- Information about the browser extension:
- How did you install it? Well, every browser supports only install via such stupid webstores.
- Browserpass extension version as reported by your browser: 2.0.22
Exact steps to reproduce the problem
All my system is in latin1 encoding including my filesystem.
When using pass (the command line tool) that is perfect working. In browser with browserpass, the path has invalid characters.
As my locale environment is proper set (de_DE without any utf-8) it would be pretty easy for the native app to use the correct encoding for file system operations. Additionally it could/should convert usernames and (optionally) password to utf-8 encoding when sending to the browser.
This would be pretty difficult to reproduce, I won't be able to migrate my file system to latin1 encoding :) would you be interested in investigating how to fix this? Or can you think of simpler repro steps?
Please do create an archive for testing 👍 It would be awesome if we could come up with a unit test showcasing the problem. I encourage you to try your idea on how to solve it, feel free to ask for guidance 😉 I think right here we can put test_store_3.tar and create a new test method in disk_test.go trying to read credentials from that password store and validating that they are correctly encoded in utf-8.
CONTRIBUTING.md should also be of some help.
We've discussed this a bit futher via email a while ago, it's not possible to replicate the scenario with a tar archive and unfortunately I don't have an ability to reproduce this. We realized that in Go strings are already utf-8 encoded, and there are two places in the code where we get strings: when retrieving a list of files (this is done in go-zglob library, which already returns us strings) and when decrypting a pass file by executing gpg process.
Since I don't have a possibility to reproduce and I won't be working on this issue myself, I'll close it as non-actionable. But if someone wants to explore this further, please do so and I'll be happy to help. I'll only add, I don't want to introduce any configuration option for this, I'd rather see encoding correctly determined (since pass is able to decode the password entry correctly, there should be no reason why browserpass can't).