Hi, On Fri, 29 Aug 2014 17:55 +0200, Zev Weiss wrote:
The biggest (or at least most immediately obvious) problem is that keeping separate files/directories for each password (which I guess it doesn't strictly require, but is clearly geared toward) is a *massive* and completely unnecessary information leak.
I agree, this does leak information, namely the names given to the passwords, as well as their length, if the files contain just the passwords and nothing else. I raised the point about the length on the pass mailing list, but I didn't propose a patch either (http://article.gmane.org/gmane.comp.encryption.pass/766). However, I think that people who use pass are aware of these limitations and based on their assumptions and usage of the tool, they might be okay with them (this includes me). In favour of pass I have to say that I find reusing a well-audited tool like gpg to handle the encryption a lot nicer than rolling your own file format, thereby risking to use encryption primitives incorrectly, etc.. Moreover, the issues in pass can be fixed without changing it's interface, which I prefer to GUI-based password managers. More importantly however, I don't think that it's the job of the window manager libraries to tell the user what applications they should or shouldn't use. I think that there are more people besides me and ardumont who use pass, so I believe that this module is useful to people (I use something very similar to ardumont's Prompt module, based on dmenu). That is reason enough for me to argue for its inclusion.
If an alternate backend that didn't have these problems could be used to provide this xmonad interface instead I'd be all for it -- but as is I'm opposed to it if only on the grounds of it serving to encourage further adoption of 'pass', which I simply think is a bad idea.
I think one big part of the "idea" behind pass is that it's a command-line password manager as opposed to a GUI application. Reusing existing tools like gpg to handle encryption is also a good idea. Basically all the issues that I can see that make its current implementation problematic could be solved by encrypting a tar file with the password files instead of the password files themselves. However, given that there is some controversy about this now, I would be happy about other people's opinions on whether or not this should be included. Cheers, Daniel