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

[Zev Weiss]

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