[xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch

Hello,

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

ardumont

2014-06-15 10:25:54 UTC

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

2014-06-19 19:57:26 UTC

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.

Daniel Schoepe

2014-07-20 13:42:53 UTC

Hi,

I think this is a nice idea, 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).

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
that it will always pretty-print passwords in the same way. Sadly pass
doesn't seem to provide a way to just list the names of the passwords
without any additional formatting.

Best regards,
Daniel

Post by ardumont
Hello,
- More explicit prompt labels for each `password` prompt
- Improved documentation (more concise + add improved links rendering)
Please, let me know if anything is wrong.

Post by ardumont
Hello,
- 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,

Post by ardumont
Hello,
You will find enclosed a patch to propose a new XMonad.Prompt.Pass.

ardumont

2014-07-22 15:36:52 UTC

Hello,

Post by Daniel Schoepe
Hi,
I think this is a nice idea,

Great!

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
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,

Post by Daniel Schoepe
Best regards,
Daniel

Post by ardumont
Hello,
- More explicit prompt labels for each `password` prompt
- Improved documentation (more concise + add improved links rendering)
Please, let me know if anything is wrong.

Post by ardumont
Hello,
You will find enclosed a patch to propose a new XMonad.Prompt.Pass.

Daniel Schoepe

2014-07-22 22:25:31 UTC

Hi,

Post by ardumont
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

2014-07-23 09:58:46 UTC

Hello,

So I updated the code according to our last exchange.

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

ardumont

2014-08-28 20:25:50 UTC

Hello,

Is there no one interested, ever?

Cheers,

Post by ardumont
Hello,
So I updated the code according to our last exchange.
Enclosed in this email, you will find the amended patch.
#+begin_src doc
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.
The password storage implementation is the password-store cli.
Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html
Synopsis
#+end_src
- 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,

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

n>>> And then, if it is approved and merged, see what users say about it.

Post by Daniel Schoepe

Post by ardumont
What do you think?

sounds good to me.
Best regards,
Daniel

--
@ardumont

Daniel Schoepe

2014-08-28 21:31:18 UTC

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

sounds good to me.
Best regards,
Daniel

--
@ardumont

ardumont

2014-08-29 11:56:44 UTC

Hello,

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
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?

Post by Daniel Schoepe
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?

Cheers,
Antoine

Post by Daniel Schoepe
Cheers,
Daniel

sounds good to me.
Best regards,
Daniel

--
@ardumont

ardumont

2014-08-29 14:26:19 UTC

Hello,

Here is the latest patch according to remarks.

Zev Weiss

2014-08-29 15:55:32 UTC

Post by ardumont
Hello,
Here is the latest patch according to remarks.
<new-xmonad-prompt-patch.dpatch>
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 (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.

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), 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. 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. (Also, the hubris of its author immediately declaring it "standard" is rather off-putting, and actually kind of laughable given how obviously-not-a-standard it is -- 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 -- 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.

Thanks,
Zev Weiss

ardumont

2014-08-29 17:56:10 UTC

Hello Zev,

Post by ardumont
Hello,
Here is the latest patch according to remarks.
<new-xmonad-prompt-patch.dpatch>
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.

Post by Zev Weiss
(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

Post by Zev Weiss
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.

Post by Zev Weiss
but rather to the 'pass' tool itself.

Peter Jones

2014-08-29 18:09:04 UTC

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. Since your
contribution depends on a non-standard package I think it would fit in
better with xmonad-extras:

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

--
Peter Jones, Founder, Devalot.com
Defending the honor of good code

ardumont

2014-08-29 19:31:37 UTC

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/default.nix#L17
- 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?

Post by Peter Jones
Since your contribution depends on a non-standard package

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

Post by Peter Jones
https://hackage.haskell.org/package/xmonad-extra

I was not aware of this (I must have missed it on the main site).

Peter Jones

2014-08-29 20:39:08 UTC

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.

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

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.

--
Peter Jones, Founder, Devalot.com
Defending the honor of good code

ardumont

2014-08-30 08:51:14 UTC

User-agent: mu4e 0.9.9.5; emacs 24.3.1

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.

Daniel Schoepe

2014-08-29 20:45:49 UTC

Hi,

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.

The same point can be made about all the modules to support dzen-based
status bars, (like Util.Dzen), for which dzen is needed for the modules
to be useful. In my view, it's up to the user to ensure these binaries
are present when they want to use what is clearly a module that's
supposed to integrate pass/dzen/whatever with xmonad.

Therefore I think that this module can go into contrib.

Cheers,
Daniel

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.

?
- 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/default.nix#L17
- 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?

Post by Peter Jones
Since your contribution depends on a non-standard package

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

Post by Peter Jones
https://hackage.haskell.org/package/xmonad-extra

I was not aware of this (I must have missed it on the main site).

Peter Jones

2014-08-29 20:51:32 UTC

Post by Daniel Schoepe
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

ardumont

2014-08-30 08:44:14 UTC

Post by Daniel Schoepe
Hi,
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.

Exactly.

Post by Daniel Schoepe
The same point can be made about all the modules to support dzen-based
status bars, (like Util.Dzen), for which dzen is needed for the modules
to be useful. In my view, it's up to the user to ensure these binaries
are present when they want to use what is clearly a module that's
supposed to integrate pass/dzen/whatever with xmonad.
Therefore I think that this module can go into contrib.

Ok, good.

Daniel, I did not see anything about xmonad-extras in the xmonad site,
it would be good to add a small page about it, don't you think?

In any case, thanks for the information sharing.

Post by Daniel Schoepe
Cheers,
Daniel

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.

Post by Peter Jones
Since your contribution depends on a non-standard package

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

Post by Peter Jones
https://hackage.haskell.org/package/xmonad-extra

I was not aware of this (I must have missed it on the main site).

Zev Weiss

2014-08-30 01:07:34 UTC

Post by ardumont
Hello Zev,

Post by ardumont
Hello,
Here is the latest patch according to remarks.
<new-xmonad-prompt-patch.dpatch>
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.

Post by Zev Weiss
(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...).

Post by Zev Weiss
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?

Post by Zev Weiss
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.

Post by Zev Weiss
(Also, the hubris

Yet another new expression, thanks.

Post by Zev Weiss
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

ardumont

2014-08-30 09:19:04 UTC

Hello,

Post by ardumont
Hello Zev,

Post by ardumont
Hello,
Here is the latest patch according to remarks.
<new-xmonad-prompt-patch.dpatch>
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.

Post by Zev Weiss
(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...).

Let me get this straight, I am not into flamewar either.

Next time you see a dude(ss) working on something you think problematic,
please, do tell him. If she/he is working on it, she might be unaware of
your insight.

Post by Zev Weiss
but rather to the 'pass' tool itself.

Zev Weiss

2014-09-02 07:08:22 UTC

Post by Zev Weiss
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 ;)

Post by Zev Weiss
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.

Post by Zev Weiss
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).

Post by Zev Weiss
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

ardumont

2014-09-03 08:36:20 UTC

ok, real standards, POSIX and all.
Definitions aligned now.
(See, it was apparent but not obvious at all to me ;)

Standard begins somewhere.
Sometimes, standard emerges with use.

Post by Zev Weiss
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 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.

Post by Zev Weiss
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.

Post by Zev Weiss
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.

Post by Zev Weiss
Zev

Cheers,
--
@ardumont

adam vogt

2014-09-09 14:49:12 UTC

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

ok, real standards, POSIX and all.
Definitions aligned now.
(See, it was apparent but not obvious at all to me ;)

Standard begins somewhere.
Sometimes, standard emerges with use.

Post by Zev Weiss
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 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.

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.

Post by Zev Weiss
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.

Post by Zev Weiss
Zev

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

ardumont

2014-09-09 17:59:53 UTC

Hello Adam,

Post by adam vogt
Hello Ardumont,
I've pushed your Aug 29 patch.

Great news!

Post by adam vogt
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.

No problem.

In the mean time, I believe the code got better :D
Thanks for your time!

Post by adam vogt
Regards,
Adam

ok, real standards, POSIX and all.
Definitions aligned now.
(See, it was apparent but not obvious at all to me ;)

Standard begins somewhere.
Sometimes, standard emerges with use.

Post by Zev Weiss
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 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.

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.

Post by Zev Weiss
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.

Post by Zev Weiss
Zev

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

Cheers,
--
@ardumont

Joachim Breitner

2014-12-18 22:25:51 UTC

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
***@joachim-breitner.de â¢ http://www.joachim-breitner.de/
Jabber: ***@joachim-breitner.de â¢ GPG-Key: 0xF0FBF51F
Debian Developer: ***@debian.org

Alexander Sulfrian

2015-01-05 14:22:30 UTC

Post by Joachim Breitner
Dear ardumont,

Hi,

Post by Joachim Breitner
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
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.

I use something like this to get a list of all passwords:

getPasswords :: String -> IO [String]
getPasswords passwordStoreDir = do
files <- runProcessWithInput "find" [
passwordStoreDir,
"-type", "f",
"-name", "*.gpg",
"-printf", "%P\n"] []
return $ map removeGpgExtension $ lines files

removeGpgExtension :: String -> String
removeGpgExtension file =
if isSuffixOf ".gpg" file then
reverse $ drop 4 $ reverse file
else
file

It is not relay nice, but it works.

Post by Joachim Breitner
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

Alex

Antoine R. Dumont

2015-07-21 09:00:04 UTC

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.

Post by Joachim Breitner
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
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.

Post by Joachim Breitner
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.

Indeed.
Thanks for pointing it.

Post by Joachim Breitner
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

2014-08-29 21:01:49 UTC

Hi,

Post by Zev Weiss
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.

Post by Zev Weiss
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

ardumont

2014-08-30 08:41:42 UTC

I am.

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
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.

Post by Daniel Schoepe

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.

Post by Daniel Schoepe
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.

Post by Daniel Schoepe
Cheers,
Daniel

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

--
@ardumont

d***@nomeata.de

2014-09-09 14:45:52 UTC