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

[ardumont]

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