I see the point of replacing bash with another programming language, that being said, I feel the urge to say something about this without falling into the trap of ranting about programming languages. One of the key points of pass that was really the selling point for me was, apart from perfectly solving the problem it was designed to solve, the transparency of the implementation. The ability to just open a file and understand what is going on is really convenient. I can just prepend a "set -x" to the top of the script and observe/debug every single bit during execution. I developed pass-extension-copyq <https://github.com/vy/pass-extension-copyq> in minutes without consulting to any manuals, but just reading the source code. I did not need to compile anything, just made my changes and there I go. It is not a black box, it is not a magic ball. It is a freaking awesome single-file bash script.
Long story short... *Please, please, please, do not replace bash with a compiled language.* Let it be Python, let it be Ruby, etc. I don't care. (Actually I do care, availability across a wide range of platforms is a great plus. Though I love pass so much that I can install scheme48 if pass just happens to depend on it.) Please go with a scripting language and keep this awesome implementation transparency intact. On Thu, Jun 14, 2018 at 5:11 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Hey list, > > After discussing pass and GPG with Marcus Brinkmann at FOSDEM this > year, and then witnessing the amazing bugs in Enigmail a while back, > Marcus went and had a look at how our shell script is actually dealing > with GPG output. He discovered (1) that our parsing of gpg command > line output with regexes isn't anchored to the beginning of the line, > which means an attacker can generate a malicious key that simply has > the verification string as part of its username, which fixed in pass > 1.7.2. This has a number of nasty consequences: a) an attacker who > manages to write into your ~/.password-store and also inject a > malicious key into your keyring can replace your .gpg-id key and have > your passwords encrypted under additional keys; b) if you have > extensions enabled (disabled by default), an attacker who manages to > write into your ~/.password-store and also inject a malicious key into > your keyring can replace your extensions and hence execute code. This > has been assigned CVE-2018-12356. > > Marcus also points out two secondary problems related to integrity. > The first secondary problem (2) is that while we try to preserve gpg's > exit code, in case of a decryption failure, the gpg tool has a > deficiency that it always writes to stdout before verification, which > is mitigated in pass 1.7.2 by simply buffering the output ourselves > (ugh). The second secondary problem (3) is that pass does not sign its > files, which means an attacker who manages to write into your > ~/.password-store and also inject a malicious key into your keyring > can display the wrong password. Problem (3) is not a new finding at > all for pass, and I group it together with the well-known related > aspect, which is that the directory tree itself doesn't have any > integrity: you can add, remove, and rename files trivially, if you're > not using git with commit signing. Pass's direct use of GPG has always > focused on secrecy without a lot of focus on authenticity, blaming the > GPG tooling again. Our recommendations for authenticity and integrity > continue to be to enable git commit signing, which pass has built-in > support for. > > One way to add this directly to pass without relying on git to handle > it for us is by adding signatures to each file, which I've long > resisted for a variety of reasons, both due to the GPG tooling > boogieman, as well as semantic issues with then verifying against user > ids that have been removed from .gpg-id. Perhaps a different way would > be for pass to use its own keyring, rather than the default ~/.gnupg > keyring; we can discuss ideas like these for 1.8. Either way, if > you're managing and sync'ing your password store using git, you really > should be signing those git commits. Perhaps we can also consider > _enforcing_ git signatures. > > I remember Marcus and my funny conversation at FOSDEM, during which he > asked me my ideas on the GPG interface and what it provides and what > pass might need from it, which provoked what was evidently a lot of > pent-up frustration in me with the command line tools. I recall > mentioning how pass is this ever-sprawling bash script filled with > impossible to understand regular expressions, because GPG doesn't > provide a more precise interface for verifying and extracting the > information we need. I'm quite happy he looked into it for us. > > There are two reasons why my presence on this list is fairly minimal > these days: I'm extremely hesitant to add new junk to pass, as I don't > think feature bloat is actually a real feature with tools like this, > which are supposed to be simple, and I've been fantasizing about some > rearchitecting for a long time. One plan for that would be to simply > use a cleaner subset of bash -- no use of sed, only bash regular > expressions. The other would be to rewrite this in a real programming > language and link to the gpgme library, which ostensibly gives us > fine-grained verification and checking. The argument against the > latter has been that the appeal of pass is that it's "just" a simple > bash script; however, as Marcus' findings have pointed out, is it > actually possible to use the GPG command line utility from bash in a > way that is both safe and simple? Seems like it might be a "choose > one" situation, and the result will always be fragile at best. On the > other hand, the prospect of investing energy into byzantine interfaces > like GPG seems perhaps misguided, and we might consider alternatives. > Either way, I will do some significant reworking for pass 1.8, to > cleanup a rather elementary script into something as robust as > possible. > > So with that said, please upgrade to pass 1.7.2, and don't hesitate to > email me directly if you find additional issues. > > Regards, > Jason > _______________________________________________ > Password-Store mailing list > Password-Store@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/password-store >
_______________________________________________ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
