[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


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

Reply | Threaded
Open this post in threaded view
|

XMonad.Prompt.Pass patch

ardumont
In reply to this post by Daniel Schoepe-2


Daniel Schoepe writes:

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

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

> 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


--
@ardumont

Reply | Threaded
Open this post in threaded view
|

XMonad.Prompt.Pass patch

ardumont
In reply to this post by Peter Jones
User-agent: mu4e 0.9.9.5; emacs 24.3.1
In-reply-to: <87a96n81zn.fsf at pmade.com>

Peter Jones writes:

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

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont
In reply to this post by Zev Weiss
Hello,

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

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.

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

Point taken.

Like Daniel pointed to, there are means for users to improve security over this.

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

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?

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

Exactly.
`Sometimes, standard emerges with 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.

First, I can also make the contrary claim based also on my experience
(without sources I mean).

Second, (again) where is it written, in the xmonad contribution page, that the
xmonad-contrib extension needed to be build upon `standard` software?

Granted, it's better but it's not required.
Maybe the xmonad team could update the documentation for latter
contributions. (This will surely loosen the difficulties to
contribute...)

When I took upon myself to make this, I read multiple times the
XMonad documentation (great by the way) and saw nothing of the sort.
I believe I did respected everything asked for.

> Availability != adoption, and I'd say widespread
> adoption is kind of a prerequisite for de facto standardization.

And last, what about xmonad itself?
Don't you think the same could be said of xmonad?

And still we are using it.
Because, whatever other people say about their computer use, we think we
know better (from first class use). And the hell with standard/adoption
and whatnot! XMonad rocks!

Also, I never used dmenu and all those excellent tiny helpers to ease
xmonad learning etc... before using XMonad (on StumpWM, from where I came from, there is a
basic native shell launcher and I was quite happy with it).
At the time, I never asked myself, is this standard?
I was more, "if I install this and use it, will I be able to
reproduce my machine if it ever dropped dead"? And since the answer is yes, I gave it a shot.

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

Cool.

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

Do not forget, pass is an implementation detail that can be abstracted away when people
feel the need for it.

Still, you have good points.
Maybe, you can contribute in some ways, to:
- pass to remove what's `frivolous, unnecessary, and/or absurd stuff`
- propose to SUS to integrate pass as standard when you will feel it is ready
- improve this code (or create a new one) to propose an alternate password manager
- improve this code to abstract away the password manager and provide
both a `standard` password manager and pass as possible implementations

You could also, if you are not happy with pass, do not use this.
Like Daniel said, even if it's installed the module will do nothing if
the user does not install the needed software.

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

>
>
> Zev

Cheers,
--
@ardumont

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Zev Weiss

On Aug 30, 2014, at 4:19 AM, ardumont <eniotna.t at gmail.com> 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


Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

ardumont

Zev Weiss writes:

> On Aug 30, 2014, at 4:19 AM, ardumont <eniotna.t at gmail.com> 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

Reply | Threaded
Open this post in threaded view
|

Applied: Re: [xmonad-contrib] XMonad.Prompt.Pass patch

darcswatch@nomeata.de
In reply to this post by ardumont
This 1-patch bundle was just applied to http://code.haskell.org/XMonadContrib:

20140829131928  eniotna.t at gmail.com
 * add-new-xmonad-prompt-pass
 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 at .
 
 
 Source:
 
 - The password storage implementation is <http://git.zx2c4.com/password-store the password-store cli>.
 
 - Inspired from <http://babushk.in/posts/combining-xmonad-and-pass.html>


--
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html#bundle-efac04c49e9b480dfc4e4e9bdf957316d272b660

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Adam Vogt
In reply to this post by ardumont
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 <eniotna.t at gmail.com> wrote:

>
> Zev Weiss writes:
>
>> On Aug 30, 2014, at 4:19 AM, ardumont <eniotna.t at gmail.com> 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 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 Adam,

adam vogt writes:

> Hello Ardumont,
>
> I've pushed your Aug 29 patch.

Great news!

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

>
> Regards,
> Adam
>
> On Wed, Sep 3, 2014 at 4:36 AM, ardumont <eniotna.t at gmail.com> wrote:
>>
>> Zev Weiss writes:
>>
>>> On Aug 30, 2014, at 4:19 AM, ardumont <eniotna.t at gmail.com> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad

Cheers,
--
@ardumont

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Joachim Breitner-2
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 at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20141218/9a3a3df3/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

[xmonad-contrib] XMonad.Prompt.Pass patch

Alexander Sulfrian
On Thu, 2014-12-18 at 23:25 +0100, Joachim Breitner wrote:
> Dear ardumont,

Hi,

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

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.

> 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


Reply | Threaded
Open this post in threaded view
|

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

ardumont
In reply to this post by ardumont
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 <[hidden email]> 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

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

signature.asc (834 bytes) Download Attachment
12