<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 18, 2016 at 4:19 PM, Antoine Beaupré <span dir="ltr"><<a href="mailto:anarcat@debian.org" target="_blank">anarcat@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[replying to a bunch of people at once, sorry for the confusion, but i<br>
want to reduce the amount of emails here.]<br>
<span class="gmail-"><br>
On 2016-12-17 20:44:32, Allan Odgaard wrote:<br>
> On 18 Dec 2016, at 6:40, Antoine Beaupré wrote:<br>
><br>
>>> I like the idea of using /dev/urandom directly, but piping it into<br>
>>> base64 is a terrible idea.<br>
>><br>
>> […]<br>
>> pwgen -ys, half the time, generates a password i can't copy-paste by<br>
>> simply double-clicking on it (because of symbols like [>;.]).<br>
><br>
> I’ve also had minor issues with characters like backslash, apostrophe,<br>
> double-quote, and backtick.<br>
><br>
> As for BSD’s base64, I am on macOS with the man page for base64<br>
> stating February 8, 2011 (Mac OS X 10.7) and the default is to encode<br>
> input, no required argument.<br>
<br>
</span>Interesting. I was based my conclusions on:<br>
<br>
<a href="https://www.freebsd.org/cgi/man.cgi?query=base64" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/<wbr>man.cgi?query=base64</a><br>
<br>
OS X may not use the same base64 as FreeBSD? I must admit I don't have a<br>
BSD box on hand to test this anymore... :/<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>I just wanted to point out that your search ( at least the link ) includes ports, which is where base64 is. In FreeBSD base there is b64encode and b64decode which are synonymous with uuencode/uudecode -m</div><div><br></div><div>Something like the following would work</div><div>head -c 18 /dev/urandom | b64encode -r - </div><div><br></div><div>Best regards</div><div>Andreas</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
On 2016-12-18 03:10:35, Lenz Weber wrote:<br>
> Please use /dev/urandom for this, not /dev/random. It is an absolutely<br>
> acceptable source of randomness and does not block, which will give a<br>
> better user experience.<br>
> (for better information see this talk:<br>
> <a href="https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy" rel="noreferrer" target="_blank">https://media.ccc.de/v/32c3-<wbr>7441-the_plain_simple_reality_<wbr>of_entropy</a> )<br>
<br>
</span>/dev/urandom doesn't seem to exist in OpenBSD, as far as I could tell<br>
when i did my research, but I don't have an OpenBSD box on hand to test<br>
this either.<br>
<br>
/dev/random is unlikely to block for the amount of data we're extracting<br>
from the pool except in extreme circumstances (e.g. you're generating a<br>
password immediately after boot). so i don't think it's harmful to use<br>
/dev/random in this specific case. furthermore, /dev/random and<br>
/dev/urandom are links on *BSD systems that support urandom, from what i<br>
can understand...<br>
<br>
and yes, i watched that talk, thanks. :)<br>
<span class="gmail-"><br>
> try triple-clicking - should work in most consoles ;)<br>
<br>
</span>triple-clicking selects the whole line, so includes a newline which will<br>
break some sites/setups.<br>
<br>
On 2016-12-18 04:41:30, Chris Warrick wrote:<br>
<span class="gmail-">> On 18 December 2016 at 00:40, Antoine Beaupré <<a href="mailto:anarcat@debian.org">anarcat@debian.org</a>> wrote:<br>
>> pwgen has a long history of generating insecure passphrases. up until<br>
>> 2014 (pwgen 2.07, shipped only in Debian jessie, and Ubuntu Vivid)<br>
><br>
</span>> That was 2 years ago. And if you insist on using outdated distros, how<br>
> secure can your gpg setup be?<br>
<br>
Are you aware of pre-2014, Debian7-specific GnuPG vulnerabilities that<br>
we don't know about?<br>
<br>
Or am I supposed to regenerate all my primary keys every two years<br>
because we're in the future now?<br>
<br>
2 years may seem like a long time for you, but for me it's very short. I<br>
know it's a controversial topic, but I happen to believe we're not<br>
supposed to rewrite and/or reinstall all our software everything every 2<br>
years.<br>
<br>
I build software that lasts.<br>
<span class="gmail-"><br>
>> On 2016-12-17 18:08:16, Tobias Girstmair wrote:<br>
>>> I'm against it. IMHO the `pass` philosophy is to utilize UNIX tools instead of rolling one's own.<br>
>><br>
>> I believe that "head", "base64" and "tr" are UNIX tools.<br>
><br>
</span>> You are introducing a dependency on GNU coreutils, though.<br>
<br>
I believe this dependency is already present in different forms<br>
elsewhere in the code. And if you are refering to base64 when you refer<br>
to coreutils, note that OS X's implementation seems to work similarly to<br>
GNU coreutils. I was just being careful in the commit log in that it may<br>
not work on other platforms, but I have (obviously) not been able to<br>
test every base64 implementation out there.<br>
<br>
But you are right, GNU is, litteraly, Not Unix, and deliberately so. I<br>
meant UNIX in the wider "unixen" sense.<br>
<span class="gmail-"><br>
>> It's not like i implemented a password generator in pure bash (which<br>
>> would be $RANDOM, and probably horrible).<br>
>><br>
>>> `base64` is not compatible with any password rules that require a special character.<br>
>><br>
>> actually, it is, often. i have observed that base64 will yield a + or /<br>
>> sign in about one out of 3 generated passwords.<br>
><br>
</span>> Not nearly enough:<br>
> * some places may dislike + or /<br>
> * some places may insist on having one of a set of characters, and +/<br>
> may not be part of this set<br>
> * base64 cannot guarantee having a symbol/number/capital letter in output<br>
> * controlling output length of base64 is hard<br>
<br>
as others said: one algorithm can't fit them all, unfortunately. that's<br>
why pwgen had all those knobs, which, i should not here, are not<br>
actually all supported by pass.<br>
<br>
i think you are setting an impossible criterion, that is not attained by<br>
the current implementation:<br>
<br>
1. pwgen -sy may also include + or / which some places may dislike (-n<br>
   would work around that, but then wouldn't have any special character)<br>
<br>
2. pwgen -sy *may* have the characters some places insist on having, but<br>
   there's no garantee of that either<br>
<br>
3. pwgen -sy cannot garantee having a symbol/number/capital letter in<br>
   output either<br>
<br>
4. it's true that pwgen output length is easier to control than<br>
   base64...<br>
<br>
... but I wouldn't call controling the length of base64 "hard". it's a<br>
simple calculation (+33%) that a lot of people are aware of.<br>
<span class="gmail-"><br>
>> pwgen -ys, half the time, generates a password i can't copy-paste by<br>
</span><span class="gmail-">>> simply double-clicking on it (because of symbols like [>;.]). you might<br>
>> argue that you're supposed to use -c, but that is optional and there are<br>
>> reasonable use-case where you can't use the clipboard to transport the<br>
>> password.<br>
><br>
</span>> Nonsense. If you want to copy-paste the password, then just use -c in<br>
> the first place. If you don’t, then there’s nothing to complain about.<br>
<br>
You may not be aware that -c sends the password to the non-default xclip<br>
CLIPBOARD selection, instead of the usual XA_PRIMARY. This makes it<br>
harder to copy-paste in terminals, for examples.<br>
<br>
> Regarding your double-click issues, please send complaints to whoever<br>
> wrote your terminal emulator.<br>
<br>
Somehow I don't think it's productive to open bug reports against xterm<br>
or rxvt because triple-click doesn't do what a password manager expects<br>
it to do.<br>
<br>
But then maybe that's all just me. I don't want to fight y'all for this,<br>
it's just a suggestion, and I see there's a lot of resistance to<br>
changing this, so I'll just move on to other greener fields.<br>
<br>
Anyways, Jason said he didn't like my implementation (specifically that<br>
"using bas64 is a horrible idea") and will work something on his own. So<br>
it's probably pointless to debate this further at this point.<br>
<br>
Have fun.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
A.<br>
<br>
--<br>
People arbitrarily, or as a matter of taste, assigning numerical values<br>
to non-numerical things. And then they pretend that they haven't just<br>
made the numbers up, which they have. Economics is like astrology in<br>
that sense, except that economics serves to justify the current power<br>
structure, and so it has a lot of fervent believers among the powerful.<br>
                        - Kim Stanley Robinson, Red Mars<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
Password-Store mailing list<br>
<a href="mailto:Password-Store@lists.zx2c4.com">Password-Store@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/password-store" rel="noreferrer" target="_blank">https://lists.zx2c4.com/<wbr>mailman/listinfo/password-<wbr>store</a><br>
</div></div></blockquote></div><br></div></div>