[PATCH] stop using pwgen

[Antoine Beaupré]

[replying to a bunch of people at once, sorry for the confusion, but i
want to reduce the amount of emails here.]

On 2016-12-17 20:44:32, Allan Odgaard wrote:
> On 18 Dec 2016, at 6:40, Antoine Beaupré wrote:
>
>>> I like the idea of using /dev/urandom directly, but piping it into
>>> base64 is a terrible idea.
>>
>> […]
>> pwgen -ys, half the time, generates a password i can't copy-paste by
>> simply double-clicking on it (because of symbols like [>;.]).
>
> I’ve also had minor issues with characters like backslash, apostrophe, 
> double-quote, and backtick.
>
> As for BSD’s base64, I am on macOS with the man page for base64 
> stating February 8, 2011 (Mac OS X 10.7) and the default is to encode 
> input, no required argument.

Interesting. I was based my conclusions on:

https://www.freebsd.org/cgi/man.cgi?query=base64

OS X may not use the same base64 as FreeBSD? I must admit I don't have a
BSD box on hand to test this anymore... :/

On 2016-12-18 03:10:35, Lenz Weber wrote:
> Please use /dev/urandom for this, not /dev/random. It is an absolutely
> acceptable source of randomness and does not block, which will give a
> better user experience.
> (for better information see this talk:
> https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy )

/dev/urandom doesn't seem to exist in OpenBSD, as far as I could tell
when i did my research, but I don't have an OpenBSD box on hand to test
this either.

/dev/random is unlikely to block for the amount of data we're extracting
from the pool except in extreme circumstances (e.g. you're generating a
password immediately after boot). so i don't think it's harmful to use
/dev/random in this specific case. furthermore, /dev/random and
/dev/urandom are links on *BSD systems that support urandom, from what i
can understand...

and yes, i watched that talk, thanks. :)

> try triple-clicking - should work in most consoles ;)

triple-clicking selects the whole line, so includes a newline which will
break some sites/setups.

On 2016-12-18 04:41:30, Chris Warrick wrote:
> On 18 December 2016 at 00:40, Antoine Beaupré <anarcat at debian.org> wrote:
>> pwgen has a long history of generating insecure passphrases. up until
>> 2014 (pwgen 2.07, shipped only in Debian jessie, and Ubuntu Vivid)
>
> That was 2 years ago. And if you insist on using outdated distros, how
> secure can your gpg setup be?

Are you aware of pre-2014, Debian7-specific GnuPG vulnerabilities that
we don't know about?

Or am I supposed to regenerate all my primary keys every two years
because we're in the future now?

2 years may seem like a long time for you, but for me it's very short. I
know it's a controversial topic, but I happen to believe we're not
supposed to rewrite and/or reinstall all our software everything every 2
years.

I build software that lasts.

>> On 2016-12-17 18:08:16, Tobias Girstmair wrote:
>>> I'm against it. IMHO the `pass` philosophy is to utilize UNIX tools instead of rolling one's own.
>>
>> I believe that "head", "base64" and "tr" are UNIX tools.
>
> You are introducing a dependency on GNU coreutils, though.

I believe this dependency is already present in different forms
elsewhere in the code. And if you are refering to base64 when you refer
to coreutils, note that OS X's implementation seems to work similarly to
GNU coreutils. I was just being careful in the commit log in that it may
not work on other platforms, but I have (obviously) not been able to
test every base64 implementation out there.

But you are right, GNU is, litteraly, Not Unix, and deliberately so. I
meant UNIX in the wider "unixen" sense.

>> It's not like i implemented a password generator in pure bash (which
>> would be $RANDOM, and probably horrible).
>>
>>> `base64` is not compatible with any password rules that require a special character.
>>
>> actually, it is, often. i have observed that base64 will yield a + or /
>> sign in about one out of 3 generated passwords.
>
> Not nearly enough:
> * some places may dislike + or /
> * some places may insist on having one of a set of characters, and +/
> may not be part of this set
> * base64 cannot guarantee having a symbol/number/capital letter in output
> * controlling output length of base64 is hard

as others said: one algorithm can't fit them all, unfortunately. that's
why pwgen had all those knobs, which, i should not here, are not
actually all supported by pass.

i think you are setting an impossible criterion, that is not attained by
the current implementation:

1. pwgen -sy may also include + or / which some places may dislike (-n
   would work around that, but then wouldn't have any special character)

2. pwgen -sy *may* have the characters some places insist on having, but
   there's no garantee of that either

3. pwgen -sy cannot garantee having a symbol/number/capital letter in
   output either

4. it's true that pwgen output length is easier to control than
   base64...

... but I wouldn't call controling the length of base64 "hard". it's a
simple calculation (+33%) that a lot of people are aware of.

>> pwgen -ys, half the time, generates a password i can't copy-paste by
>> simply double-clicking on it (because of symbols like [>;.]). you might
>> argue that you're supposed to use -c, but that is optional and there are
>> reasonable use-case where you can't use the clipboard to transport the
>> password.
>
> Nonsense. If you want to copy-paste the password, then just use -c in
> the first place. If you don’t, then there’s nothing to complain about.

You may not be aware that -c sends the password to the non-default xclip
CLIPBOARD selection, instead of the usual XA_PRIMARY. This makes it
harder to copy-paste in terminals, for examples.

> Regarding your double-click issues, please send complaints to whoever
> wrote your terminal emulator.

Somehow I don't think it's productive to open bug reports against xterm
or rxvt because triple-click doesn't do what a password manager expects
it to do.

But then maybe that's all just me. I don't want to fight y'all for this,
it's just a suggestion, and I see there's a lot of resistance to
changing this, so I'll just move on to other greener fields.

Anyways, Jason said he didn't like my implementation (specifically that
"using bas64 is a horrible idea") and will work something on his own. So
it's probably pointless to debate this further at this point.

Have fun.

A.

-- 
People arbitrarily, or as a matter of taste, assigning numerical values
to non-numerical things. And then they pretend that they haven't just
made the numbers up, which they have. Economics is like astrology in
that sense, except that economics serves to justify the current power
structure, and so it has a lot of fervent believers among the powerful.
                        - Kim Stanley Robinson, Red Mars