Cannot handle \ in filename

General information

• Operating system + version: Ubuntu 18.04
• Browser + version: Firefox 67.0
• Information about the host app:
  • How did you install it? Downloaded a pre-built binary
  • If installed an official release, put a version ($ browserpass --version): % browserpass-linux64 --version Browserpass host app version: 3.0.6
  • If built from sources, put a commit id ($ git describe --always):
• Information about the browser extension:
  • How did you install it? Installed from mozilla webstore
  • Browserpass extension version as reported by your browser: 3.1.1

---

Exact steps to reproduce the problem

1. Create an entry in your pass storage with a \ in the filename. Remember that you might need to use \ to escape the filename. I used dom\\user for this example.

2. Try to open this entry through the add-on. You will receive an error message:

Error: Unable to fetch and parse login fields: Error: {"status":"error","code":24,"version":3000006,"params":{"action":"fetch","error":"open /home/user/.password-store/webpages/webpage.com/dom/user.gpg: no such file or directory","file":"webpages/webpage.com/dom/user.gpg","message":"Unable to decrypt the password file","storeId":"default","storeName":"pass","storePath":"/home/user/.password-store"}}

It looks like that the add-on is trying to fetch the file dom/user instead of dom\\user, but it displays the entry correctly in the pop-up. Just when clicking on it or pressing enter to actually fetch the password and insert it into the web form, this error pops up.

What should happen?

I expect the browserpass-extension to read the correct file on the filesystem including the backward slash.

What happened instead?

browserpass-extension tries to read a file with a forward slash in the place of the backward slash and rightly fails to do so.

[maximbaz]

we’ve chatted some more, @erayd has an interesting idea of detecting real separator based on first character of the full path, so let’s reopen to implement the proper fix. Remember to revert the commit above in the PR 😉

[erayd]

@vollkorn1982 We have discussed this further, and have come to the conclusion that the status quo is preferable. Putting path separators in a filename is extremely non-portable (even if technically legal), and considerably increases the potential for accidental bugs in our path-handling logic.

We won’t be changing this for you, sorry.