[xmonad-contrib] XMonad.Prompt.Pass patch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmonad-prompt-pass.dpatch
Type: test/x-patch
Size: 20525 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140614/3dfc5040/attachment-0001.bin>

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont
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,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmonad-prompt-pass-2.dpatch
Type: test/x-patch
Size: 21886 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140615/0118f962/attachment-0001.bin>
-------------- next part --------------

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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-xmonad-prompt-patch.dpatch
Type: test/x-patch
Size: 22156 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140619/18d1ae73/attachment-0001.bin>
-------------- next part --------------

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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Daniel Schoepe-2
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

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad


--
@ardumont

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Daniel Schoepe-2
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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont

Hello,

So I updated the code according to our last exchange.

Enclosed in this email, you will find the amended patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmonad-prompt-pass-3.dpatch
Type: test/x-patch
Size: 21910 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140723/9f15ddfc/attachment-0001.bin>
-------------- next part --------------

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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont
Hello,

Is there no one interested, ever?

Cheers,

ardumont writes:

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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Daniel Schoepe-2
In reply to this post by 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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont
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?

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

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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont
Hello,

Here is the latest patch according to remarks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-xmonad-prompt-patch.dpatch
Type: test/x-patch
Size: 24514 bytes
Desc: new-xmonad-prompt-pass.dpatch
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140829/2fda776a/attachment-0001.bin>
-------------- next part --------------

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/xmonad.hs#L183

- # 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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Zev Weiss

On Aug 29, 2014, at 9:26 AM, ardumont <eniotna.t at gmail.com> wrote:

> 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


Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont

Hello Zev,

Zev Weiss writes:

> On Aug 29, 2014, at 9:26 AM, ardumont <eniotna.t at gmail.com> wrote:
>
>> 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.

> (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

Reply | Threaded
Open this post in threaded view
|

XMonad.Prompt.Pass patch

Peter Jones
ardumont <eniotna.t at gmail.com> 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.  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


Reply | Threaded
Open this post in threaded view
|

XMonad.Prompt.Pass patch

ardumont

Peter Jones writes:

> ardumont <eniotna.t at gmail.com> 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/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?

> 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

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

>From the definition `Various modules for xmonad that cannot be added to
xmonad-contrib because of additional dependencies.`
pass is indeed an additional dependencies so it seems completely reasonable.

Thanks.

Cheers,
--
@ardumont

Reply | Threaded
Open this post in threaded view
|

XMonad.Prompt.Pass patch

Peter Jones
ardumont <eniotna.t at gmail.com> 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.  

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


Reply | Threaded
Open this post in threaded view
|

XMonad.Prompt.Pass patch

Daniel Schoepe-2
In reply to this post by ardumont
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

On Fri, 29 Aug 2014 21:31 +0200, ardumont wrote:

> Peter Jones writes:
>
>> ardumont <eniotna.t at gmail.com> 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/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?
>
>> 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
>
> I was not aware of this (I must have missed it on the main site).
>
> From the definition `Various modules for xmonad that cannot be added to
> xmonad-contrib because of additional dependencies.`
> pass is indeed an additional dependencies so it seems completely reasonable.
>
> Thanks.
>
> Cheers,
> --
> @ardumont
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad

Reply | Threaded
Open this post in threaded view
|

XMonad.Prompt.Pass patch

Peter Jones
Daniel Schoepe <daniel at schoepe.org> 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


Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Daniel Schoepe-2
In reply to this post by Zev Weiss
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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Zev Weiss
In reply to this post by ardumont

On Aug 29, 2014, at 12:56 PM, ardumont <eniotna.t at gmail.com> wrote:

>
> Hello Zev,
>
> Zev Weiss writes:
>
>> On Aug 29, 2014, at 9:26 AM, ardumont <eniotna.t at gmail.com> wrote:
>>
>>> 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.
>
>> (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


12