Hello, Here are the latest updates about this new XMonad.Prompt.Pass: - More explicit prompt labels for each `password` prompt - Improved documentation (more concise + add improved links rendering) Please, let me know if anything is wrong. ardumont writes:

Hello,

Here is an amended patch featuring: - typo fixes in header description (`helloWorld` instead of the right function `passPrompt`, missing XPConfig instance on the binding example -- thanks OODavo on #irc) - another prompt `passGeneratePrompt` to generate a password for a given entry (update already existing entry) - another prompt `passRemovePrompt` to remove a password for a given entry

I forgot to explicit that all those prompts auto-complete on existing entries.

Thanks for considering adding this. Any suggestions on improvments is more than welcome.

Cheers,

ardumont writes:

...

Hello,

You will find enclosed a patch to propose a new XMonad.Prompt.Pass.

From the header description documentation:

-- Provides a shell prompt to lookup passwords in a password-storage (located on user's home @$HOME\/.password-store@). -- The password storage used is <http://git.zx2c4.com/password-store the password-store cli>. -- -- When one validates its input, the corresponding password is loaded -- in the clipboard for a limited period of 45 seconds. -- -- Greatly inspired from http://babushk.in/posts/combining-xmonad-and-pass.html

I'm open to any suggestions on how to improve on this.

Cheers, -- @ardumont

-- @ardumont

-- @ardumont

Hello, Daniel Schoepe writes:

Hi,

I think this is a nice idea,

Great!

but maybe you should get the list of passwords from the directory specified by the environment variable $PASSWORD_STORE_DIR like pass does (falling back to ~/.password-store if it's empty).

Good idea, this way people can specify another storage folder if they want to.

Another idea would be to run `pass ls' and try to remove the pretty-printing it adds; this would avoid duplicating what pass does for finding the password directory, but would require assuming

Yes, another idea which abstracts away again from where it is stored and avoid code duplication.

that it will always pretty-print passwords in the same way.

At the moment, `man pass` specify `tree` program as the implementation. This one needs a little extra work because of the parsing output though.

Sadly pass doesn't seem to provide a way to just list the names of the passwords without any additional formatting.

Indeed. I propose to improve the existing code with the first implementation suggestion as a first step. And then, if it is approved and merged, see what users say about it. What do you think? Best regards,

Best regards, Daniel

On Thu, 19.06.2014 21:57 +0200, ardumont wrote:

...

Hello,

Here are the latest updates about this new XMonad.Prompt.Pass: - More explicit prompt labels for each `password` prompt - Improved documentation (more concise + add improved links rendering)

Please, let me know if anything is wrong.

ardumont writes:

...

Hello,

Here is an amended patch featuring: - typo fixes in header description (`helloWorld` instead of the right function `passPrompt`, missing XPConfig instance on the binding example -- thanks OODavo on #irc) - another prompt `passGeneratePrompt` to generate a password for a given entry (update already existing entry) - another prompt `passRemovePrompt` to remove a password for a given entry

I forgot to explicit that all those prompts auto-complete on existing entries.

Thanks for considering adding this. Any suggestions on improvments is more than welcome.

Cheers,

ardumont writes:

...

Hello,

You will find enclosed a patch to propose a new XMonad.Prompt.Pass.

From the header description documentation:

-- Provides a shell prompt to lookup passwords in a password-storage (located on user's home @$HOME\/.password-store@). -- The password storage used is <http://git.zx2c4.com/password-store the password-store cli>. -- -- When one validates its input, the corresponding password is loaded -- in the clipboard for a limited period of 45 seconds. -- -- Greatly inspired from http://babushk.in/posts/combining-xmonad-and-pass.html

I'm open to any suggestions on how to improve on this.

Cheers, -- @ardumont

-- @ardumont

-- @ardumont _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

-- @ardumont

Hello, So I updated the code according to our last exchange. Enclosed in this email, you will find the amended patch. The documentation has been updated as well: #+begin_src doc This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove): one to lookup passwords in the password-storage. one to generate a password for a given password label that the user inputs. one to delete a stored password for a given password label that the user inputs. All those prompts benefit from the completion system provided by the module XMonad.Prompt. The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store. Source: The password storage implementation is the password-store cli. Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html Synopsis #+end_src An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: - without the environment variable. Pass does look into the `~/.password-store`. I have completion proposed on the prompt (my password store is stored there) - with the environment variable (in xmonad's main function, I added an ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I have no completion on the prompt because there is nothing there. Cheers, Daniel Schoepe writes:

Hi,

On Tue, 22.07.2014 17:36 +0200, ardumont wrote:

...

I propose to improve the existing code with the first implementation suggestion as a first step.

And then, if it is approved and merged, see what users say about it. What do you think?

sounds good to me.

Best regards, Daniel

-- @ardumont

Hi again, I'm very sorry that it took so long for me to respond. The patch looks good now; however it causes a conflict with a change to the cabal file (just some trivial formatting stuff). The dependency on filepath is fine since it's a library that's shipped with GHC anyway (and xmonad depends on it already), so you can remove that comment on that import statement from the patch. If you resubmit the patch with the comment removed and the conflict resolved, I'll apply it ASAP and I promise it won't take a month this time. :) PS: Could you also provide a more verbose commit message for the patch? Cheers, Daniel On Wed, 23 Jul 2014 11:58 +0200, ardumont wrote:

Hello,

So I updated the code according to our last exchange.

Enclosed in this email, you will find the amended patch.

The documentation has been updated as well:

#+begin_src doc This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove):

one to lookup passwords in the password-storage. one to generate a password for a given password label that the user inputs. one to delete a stored password for a given password label that the user inputs.

All those prompts benefit from the completion system provided by the module XMonad.Prompt.

The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store.

Source:

The password storage implementation is the password-store cli. Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html

Synopsis #+end_src

An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: - without the environment variable. Pass does look into the `~/.password-store`. I have completion proposed on the prompt (my password store is stored there) - with the environment variable (in xmonad's main function, I added an ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I have no completion on the prompt because there is nothing there.

Cheers,

Daniel Schoepe writes:

...

Hi,

On Tue, 22.07.2014 17:36 +0200, ardumont wrote:

...

I propose to improve the existing code with the first implementation suggestion as a first step.

And then, if it is approved and merged, see what users say about it. What do you think?

sounds good to me.

Best regards, Daniel

-- @ardumont

Hello, Here is the latest patch according to remarks. Below I detail some steps I took. Hope everything is alright. Thanks for your time. ardumont writes:

Hello,

Daniel Schoepe writes:

...

Hi again,

I'm very sorry that it took so long for me to respond. The patch looks good now; however it causes a conflict with a change to the cabal file (just some trivial formatting stuff).

No problem.

...

The dependency on filepath is fine since it's a library that's shipped with GHC anyway (and xmonad depends on it already), so you can remove that comment on that import statement from the patch.

Ok good to know. I'll remove them then.

...

If you resubmit the patch with the comment removed and the conflict resolved, I'll apply it ASAP and I promise it won't take a month this time. :)

Ok, cool.

I just need to adapt the code and amend the patch right?

Actually I did (I am not darcs fluent yet), from XMonadContrib local repository: - darcs unrecord # only my last patch without touching anything - darcs revert # to revert only some part of my last working copy - darcs pull # to fetch and apply the new patches - # undid to take into account what you asked for - cabal install - # reload xmonad configuration - https://github.com/ardumont/dot-files/blob/use-xmonad-prompt-pass/.xmonad/xm... - # check everything still works as before (it does!) - darcs record - darcs send -o new-xmonad-prompt-patch.dpatch

...

PS: Could you also provide a more verbose commit message for the patch?

Is it ok for you if I use the documentation description for the commit message then?

I did that.

Cheers, Antoine

...

Cheers, Daniel

On Wed, 23 Jul 2014 11:58 +0200, ardumont wrote:

...

Hello,

So I updated the code according to our last exchange.

Enclosed in this email, you will find the amended patch.

The documentation has been updated as well:

#+begin_src doc This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove):

one to lookup passwords in the password-storage. one to generate a password for a given password label that the user inputs. one to delete a stored password for a given password label that the user inputs.

All those prompts benefit from the completion system provided by the module XMonad.Prompt.

The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store.

Source:

The password storage implementation is the password-store cli. Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html

Synopsis #+end_src

An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: - without the environment variable. Pass does look into the `~/.password-store`. I have completion proposed on the prompt (my password store is stored there) - with the environment variable (in xmonad's main function, I added an ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I have no completion on the prompt because there is nothing there.

Cheers,

Daniel Schoepe writes:

...

Hi,

On Tue, 22.07.2014 17:36 +0200, ardumont wrote:

...

I propose to improve the existing code with the first implementation suggestion as a first step.

And then, if it is approved and merged, see what users say about it. What do you think?

sounds good to me.

Best regards, Daniel

-- @ardumont

-- @ardumont

Cheers, -- @ardumont

Hello Zev, Zev Weiss writes:

On Aug 29, 2014, at 9:26 AM, ardumont wrote:

...

Hello,

Here is the latest patch according to remarks.

Below I detail some steps I took.

Hope everything is alright.

Thanks for your time.

Hi,

Much as I hate to be a wet blanket here

I learned a new expression, thanks.

(and obviously don't speak from a position of any authority or influence on xmonad), I'd just like to voice my from-the-sidelines preference that this patch *not* be applied.

It would have been good to hear this before I patched it thrice. :D

This is not due to any objection to the patch itself, nor to the functionality it adds (which I think could be quite genuinely useful),

Good.

but rather to the 'pass' tool itself. From the description on its web site (http://www.passwordstore.org/), it seems in my opinion rather poorly designed. 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.

Do not use it online then.

Further, its dependencies (http://git.zx2c4.com/password-store/tree/README#n15) seem to me rather bulky for something that should/could be a very simple, lightweight thing.

I think it simply aligns with the the Unix' sphilosophy to reuse what's already there. Using brick composition to provide higher functionalities. In that way of seeing thing, this sounds standard to me.

(Also, the hubris

Yet another new expression, thanks.

of its author immediately declaring it "standard" is rather off-putting, and actually kind of laughable given how obviously-not-a-standard it is --

It's all perception. For example, I for one, dislike the term `obvious` (even more in my native language which sounds pretentious). So I become suspicious when people uses it (and you used it twice already). I am sorry but nothing for me is that `apparent` except that you sound pretty much like what you described. Like I said perception. In any case, how is it apparent for you that this is not standard? It's free software, and it's available for multiple GNU/Linux distributions (even some are not referenced, NixOS for one), Mac OS X and FreeBSD. (from its dependencies, it seems there may be even ways to make it work on windows platform, though it's not referenced.) Yet other qualities that sounds standard to me.

perhaps that's just some dry humour, but I get the sense it's meant sincerely.)

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

I provided something to start with, you may provide an alternate backend (if you know some or intend to write some) from there. The code is attached to this thread if you want to improve on it, feel free.

-- but as is I'm opposed to it if only on the grounds of it serving to encourage further adoption of 'pass',

It is not my intention to encourage further adoption of pass. I thought this use case was very interesting and tried it. I got confident about it being useful. And as it did not exist on xmonad-contrib, acted on it to permit others to benefit from it.

which I simply think is a bad idea.

Thanks,

Thanks too

Zev Weiss

Cheers, -- @ardumont

Peter Jones writes:

ardumont writes:

...

In any case, how is it apparent for you that this is not standard?

It's not a default package on any distro that I'm aware of.

? Like I said, from pass's documentation (I just added the links): - Ubuntu - https://launchpad.net/ubuntu/+source/password-store - Debian - https://packages.debian.org/source/sid/password-store - Gentoo - http://packages.gentoo.org/?search=pass&bgresponse= - Arch - https://www.archlinux.org/packages/community/any/pass/ - NixOS - https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/security/pass/defaul... - FreeBSD - http://svnweb.freebsd.org/ports/head/sysutils/password-store/ - ... This is all `default` (it's in the main repository distribution) so I do not understand. Also, I believe those distributions are the main linux families (every other in a way or another deriving from one of those). So I must misunderstand the term `default` package, can you explicit it for me?

Since your contribution depends on a non-standard package

Can you please, clarify the term non-standard package?

I think it would fit in better with xmonad-extras:

https://hackage.haskell.org/package/xmonad-extra

From the definition `Various modules for xmonad that cannot be added to xmonad-contrib because of additional dependencies.`

I was not aware of this (I must have missed it on the main site). pass is indeed an additional dependencies so it seems completely reasonable. Thanks. Cheers, -- @ardumont

User-agent: mu4e 0.9.9.5; emacs 24.3.1 In-reply-to: <87a96n81zn.fsf@pmade.com> Peter Jones writes:

ardumont writes:

...

Like I said, from pass's documentation (I just added the links): -

[...snip...]

This is all `default` (it's in the main repository distribution) so I do not understand. Also, I believe those distributions are the main linux families (every other in a way or another deriving from one of those).

So I must misunderstand the term `default` package, can you explicit it for me?

Maybe I'm splitting hairs but when I think of a "standard" or "default" package I think of things like coreutils that are installed automatically when I installed my operating system. --text follows this line-- Ok. I understand what you mean now. From this definition, neither is xmonad then.

Think about it this way: since xmonad is in the "main repository distribution" for many operating systems, would you call it a "standard" package?

With my definition (something like `available for install in standard distribution's packages repository`), I give earlier, yes. With your definition (which clarifies thing), no. (By the way, a subject for another time, it would be good to have a distribution which proposed xmonad as default.)

Just because I can install a package doesn't mean it's a "standard" package. I'm sure my operating system has dozens of password managers to choose from, just like it has dozens of windows managers. I would only call one of them the "standard" package if it was automatically installed by the base system.

Ok. Let me put it this way, using your definition: - XMonad/XMonad-contrib are not standard packages - pass is not standard package - XMonad.Prompt.Pass uses pass (as implementation) Conclusion: We are not standard, we do not integrate this contribution because you are not standard. Do you think it's reasonable? I do not. We have an expression in France for that: `l'hopital qui se moque de la charite` :D The translation is: `it's the pot calling the kettle blackSee`. (I learned a new expression) -- Also, to clarify, the name `XMonad.Prompt.Pass` is named like `pass` but is not named after `pass`. It's just I prefer conciseness where I can and `password` was too long. Also, the names in XMonad seems pretty concise too. Cheers, -- @ardumont

Daniel Schoepe writes:

the intention for xmonad-extras was to house modules requiring additional Haskell libraries as dependencies to prevent pulling in a lot of other stuff just for compiling xmonad and xmonad-contrib. This is not a problem here, the module just won't do anything.

Good point. I concede. -- Peter Jones, Founder, Devalot.com Defending the honor of good code

On Aug 29, 2014, at 12:56 PM, ardumont wrote:

Hello Zev,

Zev Weiss writes:

...

On Aug 29, 2014, at 9:26 AM, ardumont wrote:

...

Hello,

Here is the latest patch according to remarks.

Below I detail some steps I took.

Hope everything is alright.

Thanks for your time.

Hi,

Much as I hate to be a wet blanket here

I learned a new expression, thanks.

...

(and obviously don't speak from a position of any authority or influence on xmonad), I'd just like to voice my from-the-sidelines preference that this patch *not* be applied.

It would have been good to hear this before I patched it thrice. :D

Sorry about that; for a while it was looking like it was just going to fall through the cracks, so I thought maybe it would be easiest for everyone to just let that happen rather than potentially inciting a flamewar over it (which I'm trying to avoid here...).

...

but rather to the 'pass' tool itself. From the description on its web site (http://www.passwordstore.org/), it seems in my opinion rather poorly designed. 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.

Do not use it online then.

Huh? If the threat model is that the attacker doesn't have access to the local filesystem, why bother with encryption at all?

...

Further, its dependencies (http://git.zx2c4.com/password-store/tree/README#n15) seem to me rather bulky for something that should/could be a very simple, lightweight thing.

I think it simply aligns with the the Unix' sphilosophy to reuse what's already there. Using brick composition to provide higher functionalities.

In that way of seeing thing, this sounds standard to me.

...

(Also, the hubris

Yet another new expression, thanks.

...

of its author immediately declaring it "standard" is rather off-putting, and actually kind of laughable given how obviously-not-a-standard it is --

It's all perception. For example, I for one, dislike the term `obvious` (even more in my native language which sounds pretentious). So I become suspicious when people uses it (and you used it twice already).

I am sorry but nothing for me is that `apparent` except that you sound pretty much like what you described. Like I said perception.

In any case, how is it apparent for you that this is not standard?

It's free software, and it's available for multiple GNU/Linux distributions (even some are not referenced, NixOS for one), Mac OS X and FreeBSD. (from its dependencies, it seems there may be even ways to make it work on windows platform, though it's not referenced.)

Yet other qualities that sounds standard to me.

When people say things like "ed is the standard text editor", they're typically (hopefully, if they're using the term correctly) referring to actual, real standards, like SUS. For example, here's the SUS entry for ed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html If you (or anyone else) can point to a real standard that specifies the inclusion and behavior of 'pass', I'll retract my statement -- though I sincerely doubt such a standard exists. If you want to try get 'pass' into SUS, you can file a bug at http://www.austingroupbugs.net (I won't be holding my breath). There are also so-called "de facto" standards, which are not technically, officially standardized, but whose use is sufficiently widespread that their presence/behavior can to some extent be assumed -- for example in the Haskell world, I think it'd be fair to say that GHC is the de facto standard implementation of the language. Perhaps an even better example would be GCC as the de facto standard in the world of *nix C compilers -- it's not really officially standardized, but is so well-established that other C compilers (Clang, and icc as well I think) are essentially forced to mimic its command-line flags and language extensions if they want to have a chance of seeing any significant real-world use. Here again I don't think 'pass' has anywhere *near* the adoption or general familiarity to have any reasonable ground to stand on in claiming to be even a de facto standard. I for one don't recall having ever once encountered it "in the wild" on any system I've ever logged in to. Availability != adoption, and I'd say widespread adoption is kind of a prerequisite for de facto standardization. And on the issue of dependencies -- I probably should have been a bit clearer there. GPG seems entirely fine here (certainly preferable to hand-rolled-and-probably-buggy crypto, as pointed out by Daniel elsewhere in the thread); I have no objection to that. Implementation as a shell script also doesn't strike me as inherently unreasonable, though if the author's intent is really to create something "standard", I'd think a standard shell (Bourne) would be a much more sensible choice than bash. The rest, however, seem to me to be an assortment of frivolous, unnecessary, and/or absurd stuff. All that said, it of course does not actively *harm* XMonad to have this support, so if the maintainers feel it's a good fit, go right ahead. But from my perspective, all the existing instances I can see of support for external software packages in xmonad{,-contrib} are for substantially better-designed programs. Might pass's contrib/ directory be another (better, in my opinion) place to consider putting this code? Zev

On Aug 30, 2014, at 4:19 AM, ardumont wrote:

...

When people say things like "ed is the standard text editor", they're typically (hopefully, if they're using the term correctly) referring to actual, real standards, like SUS. For example, here's the SUS entry for ed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html

ok, real standards, POSIX and all. Definitions aligned now.

(See, it was apparent but not obvious at all to me ;)

...

If you (or anyone else) can point to a real standard that specifies the inclusion and behavior of 'pass', I'll retract my statement -- though I sincerely doubt such a standard exists.

Standard begins somewhere. Sometimes, standard emerges with use.

...

If you want to try get 'pass' into SUS, you can file a bug at http://www.austingroupbugs.net (I won't be holding my breath).

I am not the one requiring this. Furthermore, I checked requirements to contribute and I do not recall seeing one about this.

So, if it's the main issue at hand, please, can someone update the requirements in the xmonad site?

I don't think anyone's claimed that being officially standardized is a requirement for anything as far as xmonad is concerned (I certainly didn't mean to imply that). I was just pointing out that the "standard" claim on the website of the program in question was quite a stretch, and didn't give me an impression of great clueful-ness on the part of its author(s).

...

Might pass's contrib/ directory be another (better, in my opinion) place to consider putting this code?

I am sorry I did not understand this sentence. What's pass's contrib/ directory?

I was referring to this: http://git.zx2c4.com/password-store/tree/contrib (contrib/ being where interoperability code with other stuff often lives in various projects' source trees). Zev

Hello Ardumont, I've pushed your Aug 29 patch. Sorry about the months-long delay: it's not supposed to be this difficult to get your code into contrib, and I hope we can be more responsive in the future. Regards, Adam On Wed, Sep 3, 2014 at 4:36 AM, ardumont wrote:

Zev Weiss writes:

...

On Aug 30, 2014, at 4:19 AM, ardumont wrote:

...

...

When people say things like "ed is the standard text editor", they're typically (hopefully, if they're using the term correctly) referring to actual, real standards, like SUS. For example, here's the SUS entry for ed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html

ok, real standards, POSIX and all. Definitions aligned now.

(See, it was apparent but not obvious at all to me ;)

...

If you (or anyone else) can point to a real standard that specifies the inclusion and behavior of 'pass', I'll retract my statement -- though I sincerely doubt such a standard exists.

Standard begins somewhere. Sometimes, standard emerges with use.

...

If you want to try get 'pass' into SUS, you can file a bug at http://www.austingroupbugs.net (I won't be holding my breath).

I am not the one requiring this. Furthermore, I checked requirements to contribute and I do not recall seeing one about this.

So, if it's the main issue at hand, please, can someone update the requirements in the xmonad site?

I don't think anyone's claimed that being officially standardized is a requirement for anything as far as xmonad is concerned (I certainly didn't mean to imply that).

Ok.

...

I was just pointing out that the "standard" claim on the website of the program in question was quite a stretch, and didn't give me an impression of great clueful-ness on the part of its author(s).

Ok! But it also drove you `to voice *your* from-the-sidelines preference that this patch *not* be applied`...

Is it that much of a problem as to prevent a patch from being applied?

Again, if the patch is applied, people who wants this could use it. Others who are not interested simply ignore it.

...

...

...

Might pass's contrib/ directory be another (better, in my opinion) place to consider putting this code?

I am sorry I did not understand this sentence. What's pass's contrib/ directory?

I was referring to this: http://git.zx2c4.com/password-store/tree/contrib (contrib/ being where interoperability code with other stuff often lives in various projects' source trees).

Ok. I see now.

But I am not interested to provide this to pass. As said before, I believe this could be extended to use with other password manager. It has better chance to be improved in xmonad-contrib than in pass.

I also believe the use case is interesting enough to be integrated (otherwise, I would not have proposed it).

Then again, as you said, neither of us are qualified to apply or dismiss the patch :D

In any case, thanks for clarifying Zev.

...

Zev

Cheers, -- @ardumont _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

Dear ardumont, I started using pass and was about to implement a prompt on my own when I noticed that you already did something in that direction. But from reading the code, I have a some worries: I’d expect the getPasswords :: String -> IO [String] getPasswords passwordStoreDir = liftM (map takeBaseName) $ getDirectoryContents passwordStoreDir to break if the passwords are stored in subdirectories. I believe you need to recursively traverse the directory. It would be cleaner if you could simply ask pass for the list of passwords, but that does not seem to be possible. Maybe you should contact the author and suggest a new parameter to "pass list" that would change the output to be a simple list, instead of the tree output. Also, code like selectPassword passLabel = spawn $ "pass --clip " ++ passLabel could be a problem if the password label contains shell characters. You probably want to use safeSpawn from XMonad.Util.Run. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Hello, First, sorry for the delay in response Joachim. And sorry for xmonad ml for potentially messing up the timeline. I do not seem to find Joachim's original mail in my box nor do I know how to rattach to it. So I copied/pasted from archive the email's content to which I reply below. ardumont writes:

Dear ardumont,

I started using pass and was about to implement a prompt on my own when I noticed that you already did something in that direction. But from reading the code, I have a some worries:

I’d expect the getPasswords :: String -> IO [String] getPasswords passwordStoreDir = liftM (map takeBaseName) $ getDirectoryContents passwordStoreDir to break if the passwords are stored in subdirectories. I believe you need to recursively traverse the directory.

Of course you are right. I did not see it at the time because I did not use subdirectories. Now this need is staring right at me :D Some people saw this shortcoming too http://blog.tarn-vedra.de/posts/xmonad-password-store.html.

It would be cleaner if you could simply ask pass for the list of passwords, but that does not seem to be possible. Maybe you should contact the author and suggest a new parameter to "pass list" that would change the output to be a simple list, instead of the tree output.

Recently, it got back to my todo list.

Also, code like selectPassword passLabel = spawn $ "pass --clip " ++ passLabel could be a problem if the password label contains shell characters. You probably want to use safeSpawn from XMonad.Util.Run.

Indeed. Thanks for pointing it.

Greetings, Joachim

Sorry for the delay, got sidetracked by so many stuff I did not even see your email. I think you fixed all this https://mail.haskell.org/pipermail/xmonad/2015-February/014554.html. Thanks! Cheers, -- tony / @ardumont ----------------------------------------------------------------- gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8

Daniel Schoepe writes:

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).

I am.

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.

+1

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.

Thank you. I believe so too.

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.

+1

...

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.

+1

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.

This seems reasonable.

Cheers, Daniel

Thanks Daniel for such clear, complete, concise answers. I am completely aligned with your points. -- @ardumont